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

 
드디어 프리코스 1주차가 끝이 났다.
우테코를 시작하기 전 준비과정으로 JS 문법 공부, Git 사용법 공부를 2주간 하고 시작했다.
하지만 1주차 과제를 받아보고 당황했다.
Js에 대한 기본적인 문법만 조금 아는 정도였는데, Node.js 로 구성된 파일을 받았기 때문이다.
ApplicationTest.js, App.js, index.js 파일이 들어있었는데 각각이 무슨 역할인지 조차 파악하기 힘들었다.

 
그런데 디스코드 잡담방에서 다른 사람들은 "1주차라 그런지 과제가 쉽네요" 와 같이 고수 스멜이 물씬 나는 사람이 수두룩 빽빽이었다..
시작부터 위축되었지만, 일단 파일구조부터 파악해보기로 했다.
 
우테코는 TDD(Test-Driven Development) 방법론을 지향한다.

TDD 방법론이란?

코드를 작성하기 전에 먼저 테스트 코드를 작성하고, 그 테스트를 통과하는 최소한의 코드를 작성해나가는 소프트웨어 개발 방법론이다.
 
내가 처음 과제 폴더를 받았을 때 ApplicationTest.js 파일만 코드가 작성 되어있었는데 이 파일이 바로 테스트 코드를 작성하는 파일이다.
그래서 테스트 방법은, ApplicationTest.js에 여러가지 테스트 케이스를 부여하고 Jest라는 테스팅 프레임워크를 사용하여 테스트를 돌리는 식이다.
 
프로그램의 시작점인 App.js 파일에 문제 해결을 위한 코드를 작성하기 시작했다.
 

🛸 1주차 과제에 대한 피드백

 
🔗 1주차_PR_링크
 

README.md

파일 구조화

첫 번째로 나는 App.js 파일 하나에 모든 기능을 때려박았다.
알고리즘을 푸는 느낌으로 생각해서 아무 생각 없이 그랬던건데, 
유지보수나 테스트, 가독성을 위해서 함수 단위로 기능별, 책임별로 파일을 분리해야 한다는 것을 배웠다.
 

JS 스럽게

두 번째로 Js 스럽지 않은 코드 스타일이다.
나는 이런 문제를 푸는 언어로는 파이썬이 제일 익숙하다.
그래서 for문을 주로 사용하며 문제를 해결했는데, 받은 피드백 중 하나가 for문 대신 reduce 함수를 사용해서 의도를 더 간결하게 표현해보라는 의견이 있었다.
실제로 다른 분들의 PR을 확인해보니 대부분이 reduce함수를 사용했다.
 

주석

세 번째로 불필요한 주석이다.
누가봐도 의도가 보이는 코드에 주석을 다는 행위는 불필요하다는 지적을 받았다.
try catch 를 써서 누가봐도 예외처리를 하는 코드인데, 예외처리를 한다고 주석을 달았다.

import App from "./App.js";
import { Console } from '@woowacourse/mission-utils';

try {
  const app = new App();
  await app.run();
} catch (error) {
  // 1. App.js가 던진 에러를 여기서 잡음
  // 2. 에러 로그없이 메시지만 출력하도록 try...catch -> index.js의 app.run()이 코드의 실행의 시작점이기 때문에 여기서 잡으면 됨
  Console.print(error.message);
}

 

상수명

마지막으로 상수명이다.
상수명은 SNAKE_CASE로 대문자를 사용해서 적용하라는 조건이 있었다.
나는 아무 생각없이 모든 const로 지정하는 상수를 대문자에 SNAKE_CASE를 적용하여 정의했다.
입력을 받는 상수까지도 말이다.

const STRING_INPUT = await Console.readLineAsync('덧셈할 문자열을 입력해 주세요.\n');

 

하지만 STRING_INPUT은 이 코드를 볼 때는 아직 값이 뭔지 모른다.
사용자가 값을 입력해야 값을 비로소 알 수 있는데 즉, 런타임에 정해지는 변수이기에 대문자로 쓰지 않는것이 좋다.

const stringInput = await Console.readLineAsync('덧셈할 문자열을 입력해 주세요.\n');

이렇게 camel case로 재정의 했다.
 

느낀점

이번 문자열 계산기 과제를 수행하면서 가장 크게 느낀 점은 예외처리의 중요성과 테스트 주도 개발의 복잡함이었습니다.
과제의 겉모습만 보면 단순히 문자열을 계산하는 기능을 구현하는 일처럼 보였지만, 실제로는 프로그램의 구조 설계, 입력값 검증, 예외처리, 테스트 환경 이해 등 다양한 요소가 유기적으로 연결되어 있었습니다. 기능이 동작하기만 하면 되는 것이 아니라, 그 기능이 어떤 상황에서도 안정적으로 작동해야 한다는 점을 절실히 깨달았습니다.
 
가장 먼저 마주한 어려움은 입력값 검증 과정이었습니다. “소수는 입력할 수 없습니다”라는 조건을 구현하는 중에, 커스텀 구분자로 마침표(.)를 지정했을 때 소수점으로 인식되어 에러가 발생하는 문제가 있었습니다. 처음에는 단순히 정규식을 수정하여 해결하려 했으나, 예외 케이스가 점점 늘어나면서 코드의 가독성과 유지보수성이 급격히 떨어졌습니다. 그때 문제의 근본 원인은 ‘로직의 복잡성’이 아니라 ‘구조의 비일관성’에 있다는 것을 깨달았습니다. 이를 해결하기 위해 입력 검증을 가장 먼저 수행하는 단계로 분리하고, 커스텀 구분자 처리와 기본 구분자 처리 블록을 명확히 나누었습니다. 이후 동일한 검증 함수를 각 블록 내부에서 재사용하도록 구조를 변경하자 코드의 흐름이 한결 단순해지고, 예외처리가 체계적으로 작동하기 시작했습니다. 이 과정을 통해 단순히 오류를 잡는 것이 아닌, 프로그램의 신뢰성과 안정성을 높이는 방향으로 설계해야 한다는 점을 배웠습니다.
 
또한 이번 과제에서는 Jest 테스트 환경을 처음 접해보았습니다. 로컬에서 App.js를 직접 실행할 때는 코드가 정상적으로 작동했지만, npm test 명령어를 실행하면 Jest 테스트에서 지속적으로 실패했습니다. 문제의 원인을 분석한 결과, 제가 작성한 코드 중 process.exit(1) 구문이 테스트 환경과 충돌을 일으키고 있었습니다. 이 코드는 프로그램을 즉시 종료시키기 때문에 Jest가 app.run() 내부에서 발생하는 예외를 제대로 감지하지 못했습니다. 사실 과제 조건에 “process.exit(1)을 사용하지 말 것”이라는 문구가 명시되어 있었지만, 이를 충분히 숙지하지 못한 채 기능 구현에만 집중했던 점이 문제였습니다. 해당 코드를 throw new Error()로 변경한 뒤 테스트를 다시 실행하자 새로운 문제가 발생했습니다. Jest가 단순히 콘솔 출력 여부가 아닌 MissionUtils.Console.print 메서드 호출을 감시하고 있었던 것입니다. 모든 console.log를 Console.print로 수정한 후에야 비로소 테스트를 통과할 수 있었습니다. 이 과정을 통해 테스트는 단순히 오류를 검증하는 도구가 아니라, 개발자의 의도와 프로그램의 일관성을 확인하는 기준임을 깊이 깨달았습니다.
 
테스트를 통과한 이후에도 예상치 못한 문제가 있었습니다. 의도적으로 잘못된 입력값을 주었을 때, 제가 지정한 에러 메시지와 함께 Node.js의 내부 에러 로그가 함께 출력되는 현상이었습니다. 사용자가 볼 필요 없는 시스템 로그가 노출되는 것은 불필요할 뿐 아니라, 보안적인 측면에서도 바람직하지 않았습니다. 이를 해결하기 위해 index.js에서 App.js를 호출하는 구문을 try...catch 문으로 감싸고, 에러가 발생하더라도 오직 지정한 메시지만 출력되도록 구조를 변경했습니다. 결과적으로 프로그램이 보다 사용자 친화적이고 안정적인 형태로 완성되었으며, 단순히 기능이 돌아가는 것에서 그치지 않고 사용자의 경험을 고려한 설계의 중요성을 체감했습니다.
그 과정에서 저는 코드의 가독성 또한 기능 구현만큼 중요하다는 사실을 배웠습니다. 초반부에 입력값의 첫 글자를 검사하기 위해 다음과 같은 로직을 작성했습니다.
 
if (!stringInput || (!stringInput.startsWith('//') && !(stringInput[0] >= '0')))
자바스크립트에서는 자료형이 유연하게 적용된다는 점을 알고 있었기에, stringInput을 Number 타입으로 치환하는 것은 불필요하다고 생각했습니다. 그러나 기능 구현을 마치고 제 코드를 다시 살펴보니, 문자열을 부등호로 비교하는 로직이 직관적이지 않아 가독성이 떨어진다는 것을 깨달았습니다. 그래서 코드를 다음과 같이 수정했습니다.
if (!stringInput || (!stringInput.startsWith('//') && !(Number(stringInput[0]) >= 0)))
이렇게 변경하니 조건문의 의도가 훨씬 명확해졌고, 코드를 읽는 사람 입장에서 이해하기 쉬워졌습니다. 단순히 “돌아가는 코드”가 아니라, “읽히는 코드”를 작성해야 한다는 개발 철학을 몸소 느낄 수 있었습니다.
 
이번 과제를 진행하며 자바스크립트 언어 자체에 대한 이해도 크게 향상되었습니다. 저는 이전까지 자바스크립트의 기본 문법만 아는 수준이었기 때문에, Node.js 환경에서의 파일 구조나 테스트 프레임워크인 Jest 등은 모두 새로 배우는 과정이었습니다. 처음에는 단순한 문법 오류로 인해 프로그램이 정상적으로 실행되지 않는 일이 잦았지만, 문제를 하나씩 해결해 나가면서 코드의 동작 원리를 체계적으로 이해하게 되었습니다. 특히 파일 간의 의존성과 실행 흐름을 스스로 구성해보는 과정에서 “개발자의 사고방식”이 무엇인지 명확히 느낄 수 있었습니다. 이전까지는 코드가 단순히 실행되면 ‘성공’이라고 생각했지만, 이제는 코드가 왜 그렇게 동작해야 하는지를 스스로 설명할 수 있어야 비로소 완성된 프로그램이라고 생각하게 되었습니다.
 
이번 문자열 계산기 과제를 통해 얻은 가장 큰 성과는 단순한 기술 습득이 아니라 문제 해결 과정에서의 논리적 사고력과 태도였습니다. 오류가 발생했을 때 단순히 원인을 찾는 것이 아니라, 왜 그러한 오류가 생겼는지를 구조적으로 이해하려 노력했습니다. 또한 기능 구현만으로는 부족하며, 사용자 경험과 프로그램의 안정성, 그리고 테스트 환경까지 고려해야 진정한 의미의 완성된 코드가 된다는 사실을 깨달았습니다.
이번 문자열 계산기 과제는 단순한 과제가 아니었습니다. 그것은 프로그래밍의 본질을 되돌아보게 한 소중한 경험이었습니다. 코드 한 줄 한 줄이 쌓여 프로그램을 완성하듯, 이번 경험 또한 제 개발자로서의 기반을 단단히 다져준 과정이었습니다. 앞으로도 시행착오를 두려워하지 않고, 문제의 본질을 끊임없이 탐구하며 성장해 나가겠습니다.