본문 바로가기
카테고리 없음

[우테코 8기] 프리코스 1주차 회고

JungCw 2025. 10. 24. 14:55

지난주에 우아한 테크코스 프리코스 1주차를 경험해보았다.
그 과정에서 얻은 것을 기록하고 공유하고자 5주차까지의 여정을 회고글로 남기려한다.

 

1주차

이번 주차에는 일정이 많아 시간을 오래 투자하지 못할 것 같았다.
그래서 첫 주차에 내가 하고자 하는 목표를 명확히 설정하기로 하였다.

우선, 1주차 미션 내용을 살펴보았다.
1주차 미션은 문자열 덧셈 계산기 구현이었다. '구분자'를 이용해서 문자열에서 양수를 걸러내어 덧셈 결과를 반환하는 프로그램을 만드는 것이다.

언뜻 보니 미션 내용이 복잡하지 않았다.
공식적으로 "미션 수행 외에도 여러 가지를 함께 익혀야 하는 시기"라고 언급한 만큼, 구현에 필요한 최소한의 시간을 제외하고 나머지에 집중하기로 하였다.

집중한 4가지
이번 미션에서는 README, 코드 컨벤션, 예외처리, MVC패턴 이렇게 네 가지에 집중해보았다.

 

1. README

README에 구현 전 기능 목록을 정리하는 것이 과제 진행 요구 사항이었다.

README에 서비스 소개나 기술 스택과 같은 내용을 담아본 적은 있어도 기능 목록을 먼저 정리해본 적이 없었기 때문에 굉장히 생소하게 느껴졌다. 구현할 기능 목록을 README에 적는 것이 어떤 의미가 있는지 모르기 때문에 이번 주차에서는 README의 내용 자체에 집중하기 보단, 구현 과정에서 어떤 의미가 있는지 찾는데에 집중하였다.

 

 

README는 간결하게 해야할 목록을 정리해두었다.

기능을 구현하면서 느낀 바로는 README를 구현 전에 작성하면 좋은 점과 아쉬운 점이 있었다.

 

장점으로는 구현 과정에서 명료한 목표와 깔끔한 커밋이었다.
보통 큰 기능 단위로 목표를 잡게되면, 구현과정에서 발생하는 필요한 기능을 꼬리물기 식으로 구현하기도 한다. 물론 나쁘다고 생각하지는 않지만, 이렇게 구현하게 되면 중간중간 누락하는 기능도 생기기 마련이다. 대화도 꼬리물기 식으로 대화하다보면 무슨 대화를 하고 있었는지 잊어버리는데, 구현할 때는 오죽할까?
이런 점을 방지하는 데에 있어서 README가 일종의 가이드 역할을 해주기에 편안하다는 느낌을 받을 수 잇었다. 동시에 기능 구현 과정에 중구난방으로 튀지 않기 때문에 커밋도 기능 단위로 깔끔하게 할 수 있었다. 이는 아마도 리뷰하는 입장에서 흐름을 파악하고 이해하는데 큰 도움이 될 것이라고 생각한다.

 

반대로 단점은 README를 작성의 부족함이었다.
README가 기능명세서의 역할을 하며 구현 과정을 따라가면 되는 장점이 반대로 단점이 되기도 하였다. README를 작성할 때 모든 내용을 누락하지 않고 담기란 어려운 작업이었다. 또, 구현과정에서 더 나은 방법이 보일 때도 있었다. 이럴 때마다 README를 수정하는 것이 옳은가에 대해 의문이 들었다.

정답은 모르지만 나름대로 내린 결론은 처음 README를 작성할 때엔 MVP 기능 위주로 초기 기능 개발에 초점을 맞춰 작성하는 것을 목표로 설정하였다.


기능 구현 과정에서 더 나은 방법이 떠오르는 것은 어쩔 수 없지만, 예외나 세부 기능 설계의 오류나 누락으로 인한 README 수정은 별로 이상적이지 못하다고 생각되었다. 그렇기 때문에 초기 README에는 필수적으로 구현되어야할 기능 위주로 작성하고, 필요한 부분을 리팩토링 과정에서 추가할 수 있도록 구성하기로 하였다.


또한, 구현 과정에서 작은 기능 단위로 역할을 분리하는 것처럼, README에서도 많은 역할을 담고있거나 겹치지 않도록 작은 단위로 분리하여 기능 목록을 작성하기로 하였다.

 

 

2. 코드 컨벤션

프리코스 과정에서 전주차 공통되는 프로그래밍 요구 사항 중 하나가

package.json 파일은 변경할 수 없으며, 제공된 라이브러리와 스타일 라이브러리 이외의 외부 라이브러리는 사용하지 않는다.


이다.


주로 코드 컨벤션을 관리하기 위해 Eslint와 Prettier, Husky 등을 사용하는데, 프리코스 과정에서는 이를 사용할 수 없다. 사용할 수 있는 특별한 방법이 있다고 들었던 것 같은데, 이참에 코드 컨벤션에 대해 다시 한 번 정독해보기로 하였다.

 

영문으로 작성된 스타일 가이드도 있지만, 빠른 이해를 위해 국문 버전 스타일 가이드를 참고하였다.
다시 읽으면서 인상 깊었던 부분은 3가지 정도 였던 것 같다.

 

  1. #18.7 문의 앞과 블록의 뒤에는 빈행을 남겨 주십시오.
    항상 어렴풋이 기억하고 있었기에 빈행을 추가해야하나 고민했던 부분이다. if문이나 for문 등 앞뒤로 빈행을 넣자니 공백때문에 코드가 너무 길어지는 거 같아보이고, 안넣자니 가독성이 떨어져 보여서 고민했던 부분이다.
  2. #3.1 리터럴 구문을 사용하십시오.
    전반적으로 JS에서는 리터럴 구문을 권장한다. 이것이 new 연산자에 익숙하지 않은 이유이기도 하다.
  3. #5.1 구조화 대입
    복수의 프로퍼티를 access할 때는 구조화 대입({ a, b })을 권장한다.
    이 부분은 react에서 전역상태 등을 사용할때는 리랜더링을 고려해 분리하여 사용하기도 하기 때문에 좀 더 깊은 탐색이 필요하다고 생각되었다.

 

 

3. 예외처리

기능이 간단한 만큼 예외에 신경을 더 쓰기로 하였다.
생각보다 적은 기능에 많은 예외가 존재한다는 사실에 놀랐던 경험이다.
처리한 예외 목록은 다음과 같다.

  • 빈 문자열('')이 입력된 경우
  • 커스텀 구분자 정의시 마침 표현('\n')이 없는 경우
  • 구분자에 숫자가 포함된 경우
  • 합산할 배열에 숫자가 아닌 문자가 포함된 경우
  • 합산할 배열에 음수가 포함된 경우

이 외에도 예외 출력을 하지 않고 내부적으로 처리하도록 한 기능들도 있었다. (공백 제거, 구분자 연속 등)

이번에 예외 처리를 하며 느낀점은 예외 처리를 좀 더 효과적으로 하려면 예외 문구를 따로 상수화하여 모아두는 것도 좋겠다는 생각이 들었다. 또, README에도 크리티컬한 예외가 아니라면(기본 기능이 작동한다면) 별도로 분리해서 작성하는 것이 좋아보였다.

 

 

4. MVC패턴

프론트엔드로 웹 구현을 하다보면 보통 자주 접하지 않는 아키텍처라고 생각한다.

프리코스 과정에서 '여러 역할을 수행하는 큰 함수를 단일 역할을 수행하는 작은 함수로 분리한다.'라는 목표가 설정되어 있기 때문에, 작은 단위의 역할을 가진 함수로 관리하는 아키텍처로 MVC패턴을 고려하게 되었다.

 

MVC란 model, view, controller 이렇게 세 가지 역할로 앱을 나눈 패턴을 의미한다.

  • model: 데이터와 비즈니스 로직 담당. DB와 직접 연결되거나 데이터 처리 관련 기능 수행
  • view: 사용자에게 보여지는 화면
  • controller: 사용자 입력 처리 및 Model ↔ View 연결. 요청을 받아 데이터 처리 후 View에 전달

이렇게 정의되지만, 솔직히 이 내용이 와닿지도 않았고, 너무 생소한 패턴이기에 적용이 제대로 되지도 않았다.
실제로 1주차 코드를 보면

import { isNumber } from "./validators.js";

export function sumElements(elements) {
const numbers = elements.map((element) => isNumber(element));
const result = numbers.reduce(
(accumulator, current) => accumulator + current,
0
);

return `결과 : ${result}`;
}


이렇게 하나의 모델안에 두 가지 이상의 역할을 담기도 하였다.

 

실제로 역할 분리에 대한 코드 피드백을 받았다.

 

여전히 "기능별로 작게 나눈다"에만 초점이 맞추어져 있었기 때문이었다.
다른 분들께 코드 리뷰를 받아보고, 스스로 코드를 다시 살펴보며 MVC패턴에 대해 재정의하였다.


아직 완벽하지 않지만 더 나은 코드를 작성하기 위해 몇가지 기준을 생각해두었는데,

  • model에는 가장 작은 조각으로 이루어진 기능들을 담아둔다.
  • controller는 이 작은 조각들을 결합해서 플로우 명세를 만들어낸다.

이렇게 두 가지만을 기준으로 세워두고 다음 주차에 적용을 해볼 생각이다.

 

 

회고

간단한 내용이었지만, 구현 외적으로 배울 것이 많은 1주차였다.


리드미의 의미부터 아키텍처까지 구현에서 주로 느끼는 성공이라는 감각이 아니라 왜 그렇게 하는지를 이해하는 공감의 감각으로 배운 점이 많았다. 전부 실제로 겪어보면서 필요성을 이해할 수 있어야 학습되는 것들이었다고 생각한다.
그리고, 처음에는 코드리뷰를 받아서 부족한 점을 채우고자 다른 사람의 코드를 리뷰해보았지만, 돌이켜보니 다른 사람의 코드를 보는 것이 가장 도움이 많이 되었던 것 같다.


다른 분들은 어떤 예외처리를 했는지, 어떤 방식으로 검증이나 구현을 했는지도 도움이 되었고, 그 중에서도 특히 아키텍처 같이 본인이 잘모르는 영역을 볼 때 가장 큰 도움이 되었다. 보다 나은 결과를 보며 감각을 익혀본달까..?
더불어 전혀 다른 스타일의 코드를 보게 되면, 왜 그런 스타일을 선택했는지 추측해보기도 하고 반대로 나는 왜 이런 스타일을 선택했는지 그 이유를 생각해볼 수 있는 시간이기도 했다.

 

 

 

 

 

티스토리툴바