회고
[우테코] 3편 : 1주차 프리코스 회고
안녕하세요! 팡일입니다.
어느덧 프리코스 1주차를 시작하고 마무리 되었습니다!
오늘은 1주차 프리코스가 어떤 방식으로 진행되었는지 회고하며, 그 과정에서 느낀 점과 배운 점을 함께 나누어보려 합니다.
| 시작 과정
가장 먼저 Discord 채널을 통해 1주차 미션에 대한 공지가 올라왔습니다.
안내에 따라 지원 플랫폼의 과제 페이지로 이동하니, ‘과제’ 섹션이 새로 추가되어 있었어요.
과제 제출 기간은 10월 14일(화) 오후 3시부터 10월 21일(화) 자정까지였습니다.
‘과제 보기’를 클릭하면 프리코스 1주차 과제의 세부 설명이 자세히 나와 있었고, 다음과 같은 진행 방식이 제시되어 있었습니다.
1) 진행 방식
: 미션은 크게 세 가지로 구성되어 있었습니다.
과제 진행 요구 사항
기능 요구 사항
프로그래미이 요구 사항
주요 유의사항으로는 다음과 같았습니다.
기능을 구현하기 전에는 기능 목록을 만들고, 기능 단위로 커밋하는 방식으로 진행해야 한다.
기능 요구사항에 기재되지 않은 내용은 스스로 판단하여 구현한다.
제출은 일요일 오후 3시부터 가능하며, 정해진 시간을 지키지 않으면 미션 미제출로 간주한다.
이 점들을 염두에 두고 미션을 진행했습니다.
2) 미션 제출 방법
미션 구현을 완료한 후에는 GitHub을 통해 제출하는 방식이었습니다. 제출 절차는 다음과 같습니다.
프로젝트를 자신의 계정으로 fort하기
for한 저장소를 자신의 컴퓨터로 clone하기
git clone {fork한 자신의 저장소 URL}
기능 구현을 위한 브랜치 생성하기
git checkout -b {본인의 아이디}
통합 개발 환경(IDE)으로 가져오기 (웹 프론트엔드는 Visual Studio Code)
기능 구현하기
기능 구현 후 add, commit하기
본인의 원격 저장소에 올리기
github 서비스에서 Pull Request 보내기
PR 제목 : [$미션제목] $이름 미션 제출합니다. (ex. [숫자 야구 게임] 김광일 미션 제출합니다.)
PR을 보낸 뒤에는 우아한테크코스 지원 플랫폼의 내 지원 현황 페이지에서 '제출하기' 버튼 누르기
Github ID, Pull Request 주소, 진행 소감을 모두 입력하고 제출하기
미션을 진행하면서 느끼고 배운 점, 많은 시간을 투자한 부분 등도 포함하면 더 좋을 것 같다.
한 번 제출한 뒤에도 해당 주차 프리코스 기한 내에는 수정 가능하다.
제출한 PR을 기반으로 코드가 정장적으로 동작하는지 확인할 수 있다.
'예제 테스트 실행' 버튼을 눌러 테스트를 시작한다.
'테스트 중'이라는 문구가 나오면, 정상적으로 테스트가 실행된 것이다.
3) 커밋 컨벤션
(1) 작성 규칙
현재 시제, 명령형으로 작성→ “change” ✅ / “changed” ❌ / “changes” ❌
첫 글자는 소문자로 시작
마침표(.) 금지
한 줄 100자 이하
(2) 커밋 유형
Type | 설명 |
feat | 새로운 기능 추가 (feature) |
fix | 버그 수정 |
docs | 문서 수정 (README, 주석 등) |
style | 코드 포맷팅, 세미콜론 누락 등 (로직 변화 없음) |
refactor | 코드 리팩토링 (기능 변화 없음) |
test | 테스트 코드 추가/수정 |
chore | 빌드, 패키지 설정 등 유지보수용 작업 |
| 문자열 덧셈 계산기 - 문제 설명
과제에 대한 안내 사항은 기능 요구사항, 입출력 요구사항, 프로그래밍 요구사항 이렇게 크게 3가지로 구분되었습니다.
1) 기능 요구사항
(1) 문제 설명
: 입력한 문자열에서 숫자를 추출하여 더하는 계산기를 구현한다.
쉼표(,) 또는 콜론(:)을 구분자로 가지는 문자열을 전달하는 경우, 구분자를 기준으로 분리한 각 숫자의 합을 반환한다.
"" => 0, "1,2" => 3, "1,2,3" => 6, "1,2:3" => 6
앞의 기본 구분자(쉼표, 콜론) 외에 커스텀 구분자를 지정할 수 있다.
커스텀 구분자는 문자열 앞 부분의 "//"와 "\n" 사이에 위치하는 문자를 커스텀 구분자로 사용한다.
"//;\n1;2;3;" -> 커스텀 구분자는 ;이며, 결과값은 6이 반환되어야 한다.
사용자가 잘못된 값을 입력할 경우 "ERROR"로 시작하는 메세지와 함께 Error를 발생시킨 후, 애플리케이션은 종료되어야 한다.
(2) 입출력 요구 사항
입력
구분자와 양수로 구성된 문자열
출력
덧셈 결과
결과 : 6
실행 결과 예시
덧셈할 문자열을 입력해 주세요.1,2:3결과 : 6
2) 프로그래밍 요구 사항
Node.js 22.19.0 버전에서 실행 가능해야 한다.
프로그램 실행의 시작점은 App.js의 run()이다.
package.json 파일은 변경할 수 없으며, 제공된 라이브러리와 스타일 라이브러리 이외의 외부 라이브러리는 사용하지 않는다.
프로그램 종료 시 process.exit()를 호출하지 않는다.
프로그래밍 요구 사항에 달리 명시하지 않는 한 파일, 패키지 등의 이름을 바꾸거나 이동하지 않는다.
자바스크립트 코드 컨벤션을 지키면서 프로그래밍 한다.
@woowacourse/mission-utils에서 제공하는 Console API를 사용해서 구현해야 한다.
사용자의 값을 입력 및 출력하려면 Console.readLinAync()와 Console.print()를 활용한다.
| 스터디 1차
10월 21일 자정을 기준으로 1주차 과제가 마감된 후, 스터디원들과 함께 약 2시간 반 동안 회고 및 코드 리뷰 시간을 가졌습니다.
이 시간을 통해 다양한 인사이트를 얻었고, 더 나은 사고 방식을 배울 수 있었습니다.
1) 그중 인상 깊었던 피드백 몇 가지를 공유하면 다음과 같습니다.
(1) 상수값만 대문자로
핵심 원칙: 프로그램 전역에서 절대 바뀌지 않는 상수 값만 UPPER_CASE 사용
불변 값(숫자, 문자열, 설정값 등) → UPPER_CASE
런타임 시 내부 상태가 변할 수 있는 객체, 함수, 인스턴스 → camelCase
가이드라인
const MAX_COUNT = 10; // ✅ 상수
const calculator = new Calculator(); // ✅ camelCase (객체 참조)(2) 내부 로직 캡슐화 (Class Encapsulation)
핵심 아이디어: 외부에서 호출될 필요 없는 내부 메서드는 # 기호를 사용하여 private 메서드로 선언
문법: #메서드명()
효과
외부 코드에서 내부 구현(parse, validate)을 직접 호출하는 실수 방지
클래스의 책임이 명확해지고, 유지보수성 향상
내부 로직 변경 시에도 외부 영향이 최소화됨 (Loose Coupling)
class StringCalculator {
#parse(input) { ... }
#validate(numbers) { ... }
add(input) {
const numbers = this.#parse(input);
this.#validate(numbers);
return numbers.reduce((a, b) => a + b, 0);
}
}(3) 상수 파일 구체화 (Constants Modularization)
핵심 아이디어: 코드 내에서 자주 반복되거나 여러 파일에서 공유되는 상수들을 한 파일로 분리
분류 기준:
정규식(Regex) — 입력 포맷, 구분자 패턴 등
Input / Output 텍스트 — 콘솔 메시지, 안내문, 결과 출력 형식
숫자형 상수 — 최대/최소 범위, 초기값 등
에러 메시지 상수 — 일관된 예외 처리 메시지
효과
상수의 중앙 집중 관리로 유지보수 용이
의미적 분리로 코드 가독성 향상
테스트 및 리팩토링 시 안정성 확보
(4) 폴더 단위 모듈화 (Directory Entry Point Pattern)
핵심 아이디어: 여러 파일로 분리된 상수(constants)나 유틸 함수들을 index.js에서 한 번에 모아 export 하여, 외부에서는 폴더 단위로 import 가능하게 만드는 구조
문법: 폴더에 index.js 파일을 생성하고 하위 모듈을 export * from 문으로 통합
효과
import 경로를 간결하게 유지 (import {...} from './constants')
constants 내부 파일 구조가 바뀌어도 외부 코드는 수정할 필요 없음
공통 상수나 설정을 중앙 집중식으로 관리할 수 있음
유지보수성과 확장성이 높아짐
// ? constants/
// ├── calculatorConfig.js
// ├── messages.js
// └── index.js
// constants/calculatorConfig.js
export const DEFAULT_SEPARATOR = [',', ':'];
// constants/messages.js
export const INFORMATION_MESSAGE = '결과 :';
export const ERROR_MESSAGE = '[ERROR] 잘못된 입력입니다.';
// constants/index.js
export * from './messages.js';
export * from './calculatorConfig.js';
// app.js
import { INFORMATION_MESSAGE, DEFAULT_SEPARATOR } from './constants';
console.log(INFORMATION_MESSAGE, DEFAULT_SEPARATOR);
// → "결과 :" [",", ":"](5) 의미 있는 네이밍 작성 (Meaningful Naming)
핵심 아이디어: 이름을 통해 의도와 역할이 명확히 드러나도록 짓는다. 좋은 네이밍은 코드 자체가 문서처럼 읽히게 하며, 협업과 유지보수를 쉽게 만든다.
규칙
의도를 드러내는 이름 사용
: 이름만 봐도 "무엇을 하는 함수인지", "어떤 데이터를 담는 변수인지"를 유추할 수 있어야 한다.축약하지 않는다 (Don’t Abbreviate)
: 길더라도 의도를 정확히 드러내는 이름을 사용하자.문맥 중복 피하기 (Avoid Context Duplication)
: 클래스나 객체 이름에 이미 문맥이 담겨 있다면, 메서드 이름에 같은 단어를 반복할 필요가 없다.불용어 사용 금지 (Avoid Meaningless Words
: Data, Info, Value, Helper 같은 단어는 정보가 거의 없기에, 대신 구체적인 역할을 드러내는 단어를 선택한다.
// (1) 이름을 통해 의도를 드러낸다
const parsedNumbers = extractNumbers(userInput); // ✅ 명확
const a = parse(u); // ❌ 모호
// (2) 축약하지 않는다
const separatedNumbers = numberString.split(SEPARATOR_REGEX); // ✅
const splitList = numStr.split(REX); // ❌ 축약
// (3) 문맥 중복 피하기
class Order {
ship() {} // ✅ order.ship()
shipOrder() {} // ❌ order.shipOrder() — 중복된 맥락
}
// (4) 불용어 사용 금지
const errorMessage = '[ERROR] Invalid input'; // ✅
const errorInfo = '[ERROR] Invalid input'; // ❌ 의미 모호이러한 점들을 바탕으로, 더 좋은 결과물을 만들어낼 수 있도록 2주차 과제에 몰입해보려고 합니다.
2) 팀원들과의 회고
또한, 팀원들과 함께 한 주 동안 회고를 진행하면서, 어떤 점을 유지하고 개선하고 노력할지에 대해서 이야기 나눌 수 있었습니다.
스스로와 팀원들의 회고를 같이 공유하면서, 더욱 동기부여와 자극이 됐던 부분이 인상 깊었습니다.
Notion을 활용해서 아카이빙했습니다.
제가 작성했던 KPT 회고 내용입니다.
3) 코드 리뷰
또한, 팀원들과 함께 각자 코드를 설명하고, 좋았던 점과 개선해야 할 점들에 대해서 리뷰하는 시간도 가졌습니다.
감사하게도 팀원들의 적극적인 리뷰 덕분에 개선해야 할 점들을 많이 배울 수 있었습니다.
반대로, 저도 리뷰를 통해서 서로에게 윈윈이 되는 피드백을 주고 받을 수 있어서 유익한 시간이었습니다.
| 1주차 전반적인 회고
실제로 제출했던, 그리고 제가 한 주간 깊게 느꼈던 전반적인 회고 글도 공유해보려고 합니다.
? “전반적인 경험”
과제 설명을 처음 봤을 때, 전반적으로 구조가 정말 탄탄하다고 느꼈습니다. 과제 진행 요구 사항, 기능 요구 사항, 프로그래밍 요구 사항 하나하나가 구체적이어서 과제를 해나가는 데 실질적인 도움이 되었습니다. 그동안 백준이나 프로그래머스 같은 곳에서 문제를 풀 때는 단순히 알고리즘 자체에만 집중했었는데, 이번에는 커밋 단위, 개발 환경, 코드 컨벤션까지 고민하며 문제를 푸는 과정이 새롭고 흥미로웠습니다. 또, 과정 중에 ‘알아두면 좋을 팁’들이 Discord 채널에서 자유롭게 공유되는 분위기 덕분에 막힐 때마다 도움을 많이 받았습니다.
과제나 미션이 주어지고 진행되는 흐름도 매끄러웠습니다. 과제 설명을 꼼꼼히 읽고 구현할 기능을 먼저 문서로 정리한 다음, 하나씩 구현하고 다시 수정·개선하거나 테스트해보는 과정이 물 흐르듯 자연스럽게 이어졌습니다. 특히 리팩토링을 하면서 “어떤 오류가 터질 수 있을까?”, “어떤 가능성까지 생각해야 할까?”를 고민했던 과정이 가장 기억에 남습니다.
무엇보다 좋았던 점은 흥미와 재미를 놓치지 않고 끝까지 갈 수 있었다는 것입니다. 문제를 파악하고 어떻게 풀지 고민하며 부딪힌 어려움이나, 리팩토링하며 더 나은 코드를 고민하는 과정이 쉽지는 않았지만 오히려 도전 의식을 자극했습니다.
반면, 아쉬운 점도 있었습니다. Airbnb JavaScript Style Guide 같은 코드 컨벤션 스타일을 좀 더 일찍 꼼꼼히 읽고 준비했다면 불필요한 수고를 덜 수 있었을 텐데 하는 아쉬움입니다. 물론 이 과정 역시 배우고 성장하는 데 도움이 되었기에, 좋았던 경험과 아쉬웠던 경험 모두 다음번에는 더 잘해내기 위한 밑거름으로 삼고 싶습니다.
? “배운 점”
이번 주차에서 특별히 크게 배운 점 두 가지를 꼽아보자면 다음과 같습니다.
첫째, 지속적으로 리팩토링하며 코드를 개선해 나가는 자세를 배웠습니다. 개발에는 정답이 없지만 최선은 있다고 생각합니다. 그래서 이전보다 더 나은 코드를 만들려는 노력이 중요하다는 것을 깨달았습니다. 특히 예외 처리와 오류 처리 부분을 더 깊이 고민했던 것이 실제 개선된 결과로 나타날 때 크게 와닿았습니다. 예를 들어, 오류가 났을 때 단순히 ’throw문으로 메시지를 띄우는 데 그치지 않고, 그 메시지를 상수로 관리하도록 바꿨던 경험이 기억에 남습니다.
둘째, 테스트 코드의 역할과 중요성을 새롭게 이해하게 되었습니다. 이전까지는 테스트 코드를 직접 짜보거나 도입해 본 경험이 거의 없었고, 주어진 테스트 케이스만 통과하면 끝이라고 생각하곤 했습니다. 하지만 직접 테스트 코드를 작성해보니 예외 상황을 미리 따져보고 프로그램 구조를 더 탄탄하게 설계하는 게 얼마나 중요한지 알게 되었습니다. 덕분에 더 확장성 있는 구조에 대해 고민해보게 되었습니다.
제가 평소에 잘하던 부분 또는 익숙하지 않던 부분 중에서 스스로 성장했다고 느끼는 점은 다음 두 가지입니다.
첫째는, Class 기반의 메소드 사용이 한결 익숙해졌습니다. 예전에는 ’for’문이나 ’while’문을 쓰는 등 복잡하고 비효율적으로 코드를 짜곤 했습니다. 클래스 기반의 메소드 사용이 낯설기도 했고, 배우려다 미룬 적도 많았습니다. 이번 과제를 통해 코드 간결화나 JavaScript 문법과 메서드를 잘 쓰는 것이 더 클린한 코드로 이어진다는 걸 느꼈고, 기본 메서드들을 찾아보며 간단한 예제로 구조를 이해하려 했습니다. 그 결과 이번 주차 미션에서는 여러 메소드를 적극적으로 활용하게 되었습니다.
둘째는, 정규식을 활용한 문자열 파싱이 전보다 훨씬 익숙해졌습니다. 문자열을 파싱할 때 ’split’, ’substr’, ’replace 같은 메서드만 쓰곤 했는데, 여러 메서드를 중복으로 쓰거나 다양한 경우를 고려하다 보니 코드가 길어지고 비효율적이라고 느꼈습니다. 정규식을 쓸 수 있다는 건 알았지만 어떻게 쓰는지는 잘 몰랐는데, 이번에 정규식을 공부하고 실제로 적용해보면서 점점 익숙해졌습니다. 이제는 앞으로 문자열을 파싱할 때 정규식 사용도 우선적으로 떠올릴 만큼 자신감이 생겼습니다.
이런 배움들이 앞으로의 성장에 어떤 도움이 될지 생각해봤습니다. 이번 주차 미션을 통해 겪고 시도했던 경험들이 앞으로 새로운 도전을 만났을 때 큰 도움이 될 거라고 생각합니다. ‘어떻게 기능을 구현할지 먼저 나열하고, 하나씩 구현해 MVP를 만든 뒤, 개선할 점을 찾아 고쳐나가는 과정’을 몸으로 익혔습니다. 개발자에게는 ‘0에서 1을 만드는’ 역량도 중요하지만, ‘1을 2로 만드는’ 개선 및 유지보수 능력도 꼭 필요하다고 생각합니다. 많은 현업에서 이 역량을 중요하게 본다는 것도 이번에 깨달았습니다. 이 과정에서 느꼈던 흥미, 재미, 성취감, 뿌듯함을 기억하며 남은 프리코스 기간의 미션과 고민에도 이 경험을 잘 적용해보고 싶습니다.
? “어려웠던 점”
과제를 하면서 가장 아쉬웠던 부분은 앞서 말했던 코드 컨벤션 스타일을 미리 제대로 숙지하고 적용하지 못한 점입니다. 구체적으로, Airbnb 스타일 가이드 등을 좀 더 빨리 꼼꼼하게 읽고 적용했다면, 초기 개발 단계에서 불필요한 수정이나 리팩토링을 줄일 수 있었을 텐데 하는 아쉬움이 듭니다. 또한, 리팩토링 과정에서 고려할 점들을 미리 충분히 생각해두었다면, 초기 설계 단계에서 조금 더 안정적인 구조를 잡고 진행할 수 있었겠다는 아쉬움이 남습니다.
이런 경험을 통해 제 부족한 점을 알게 되었습니다. 익숙하지 않은 도구나 스타일 가이드에 대해서는 좀 더 미리 준비할 필요성을 느꼈고, 기능 구현 이후의 리팩토링과 테스트 설계까지 고려해서 미리 큰 틀을 잡아두는 습관을 들여야겠다고 다짐했습니다.
? “앞으로의 각오 및 계획”
남은 프리코스 기간 동안 저는 다음과 같은 목표를 세웠습니다.
목표: 남은 기간 “기능 구현 → 테스트 및 개선 → 코드 컨벤션 적용 및 리팩토링” 순서를 자연스럽게 체득하는 것을 목표로 삼겠습니다. 또한, 제가 지향하는 개발자의 방향성에 맞춰, 코드의 구조화, 재사용성, 가독성에 좀 더 집중하려 합니다.
성장하고 싶은 개발자의 모습: 저는 앞으로 “사용자가 직관적으로 이해할 수 있는 UI/UX를 구현하고, 내부적으로는 깔끔한 구조와 견고한 코드로 유지보수가 쉬운 애플리케이션을 만드는 React 프론트엔드 개발자”가 되고 싶습니다. 이번 프리코스 경험을 바탕으로, 단순히 기능을 만드는 것을 넘어 코드를 읽기 쉽고 설계하기 좋은 구조로 만드는 역량을 기르고 싶습니다.
| 결론
이번 프리코스 1주차는 단순한 과제 수행을 넘어 “개발자로서의 사고방식”을 배울 수 있었던 의미 있는 시간이었습니다.
다음 주차에서는 배운 점들을 적극적으로 적용하며 더 나은 결과물을 만들어가겠습니다.
https://github.com/woowacourse-precourse/javascript-calculator-8/pull/172