웹 개발 소모임에서 부원들과 함께 "우아한프리코스"에서 출제된 지난 회차 문제들을 풀면서 객체지향 설계에 대해 함께 탐구하며 학습하고 있다.

이전에는 매번 주먹구구식으로 개발을 시작했지만, 이렇게 기능 목록을 작성하며 내가 구현해야 할 기능들을 세분화하여 정리하니 빠뜨리는 것도 줄고 우선순위도 명확해졌다.

덕분에 해당 기능 구현 시에 그것에만 몰두할 수 있어 좋은 품질의 코드와 개발 속도라는 두 가지 고민을 단번에 해결할 수 있었다.

하지만, 이제 처음 배우며 작성하는 만큼 어떻게 해야 좀 더 명확하고 보기 좋은 기능 목록이 되는지 헷갈린다.

이번 기회에 기능 목록의 작성법과 장점에 대해 함께 알아보자.

❓ "기능 목록" 이란?

사람 마다 기능 목록, 기능 명세, 구현 목록 등등 여러 이름으로 불리는 것 같지만, 해당 포스팅에서는 "기능 목록"이라는 용어로 통일하겠다.

기능 목록이란, 본격적으로 코드를 작성하기 전에 README에 먼저 적어두는 할 일 체크리스트이자 기능 명세서이다.

즉, 이번 과제(구현)을 어떤 기준으로, 무엇부터, 어디까지 만들 것인가를 한 눈에 보이도록 정리한 문서인 것이다.

❓ 왜 작성해야 할까?

1. 요구사항 오해 방지
기능을 문장으로 쪼개며 해석하니, 빠뜨리거나 잘못 이해할 가능성이 줄어든다.

2. 작게 나눠서 개발 → 작은 커밋
항목 단위로 구현/커밋/리팩터링 흐름이 명확해져 Git 기록이 깔끔해진다.

3. 테스트 기준이 생김
“어떤 입력 → 어떤 출력/행동이어야 한다”를 적어두면 테스트가 쉬워진다.

4. 우선순위와 일정 관리
중요한 것부터 체크하고, 시간이 부족하면 덜 중요한 항목을 뒤로 미룰 수 있다.

5. 리뷰/피드백이 쉬움
리뷰어가 “무엇을 기준으로 완성했는지” 빠르게 파악 가능하다.

❓ 어떻게 쓰면 좋을까? (간단 가이드)

• 사용자 관점 문장으로 작성하기.

  → “사용자는 …할 수 있다”, “프로그램은 …해야 한다”

• 관찰 가능한 완료 기준 포함하기.

  → 예) “잘못된 입력 시 IllegalArgumentException 발생 및 메시지 출력”

• 입·출력, 예외, 경계값, 상태 변화를 빠뜨리지 말기.

• 구현 방법(예: for문/Stream) 같은 코드 세부는 적지 않기.

  → 무엇을 먼저, 왜 하는지가 핵심

• 진행하며 수정/체크 표시해도 됨 (작게 계획 → 학습하며 업데이트).

  → 이것이 프리코스에서 말하는 "살아있는 문서 작성"의 핵심
  
  

💡 기능 목록 작성 시 고려사항

고려 사항 1️⃣ : 기준 (완료 조건, Success Criteria)

이 기능이 끝났다고 판단할 수 있는 객관적인 조건

이때 '코드가 어떻게 짜였는지'는 상관이 없고, 요구사항을 분석하여 사용자가 볼 수 있는 동작 결과가 기준이 되어야 한다.

즉, 출력(문)이나 상태 변화, 흐름 변화 등이 기준이 되어야 한다.

틀린 예:
"예외 처리를 한다"
(너무 추상적임. 뭘 어떻게 해야 끝난건지 알 수 없음)

"for문으로 자동차를 전진시킨다"
(for문을 쓰던 while문을 쓰던 간에 결과만 맞으면 됨. 구현 방법은 기준이 아님)

"System.out.println()으로 결과를 출력한다”
(출력 방법이 아니라, 어떤 메시지가 출력되는지가 기준이어야 함.)

올바른 예:
“자동차 이름이 6자 이상 이면 IllegalArgumentException 발생"
"자동차 전진 여부는 난수가 4 이상일 때만 참으로 판정된다"
"결과 메시지는 라운드마다 [자동차이름]: --- 형식으로 출력된다"

개인적으로는 'A이면-B이다' 와 같은 형식의 직유법 느낌이 강하게 들었다. 이처럼, 조건-결과의 형식으로 작성하면 모호함이 줄고 의미가 명확해진다.

---

고려 사항 2️⃣ : 무엇을 (해야 할 기능, What)

과제에서 요구한 동작이나 규칙을 기능 단위로 쪼갠 목록

요구사항들을 내가 실제로 구현해야 하는 작은 동작들로 바꿔 정리해 놓은 것이다.

글로 서술된 조건들을 작게 쪼갬으로써 내가 구현해야 할 기능이 명확해지고, 전체적인 흐름을 파악하기에도 수월해진다.

예시:
"사용자 입력 받기”
“랜덤 숫자 생성하기”
“입력값 검증하기(중복/범위/자리수)”
“스트라이크·볼·낫싱 판정하기”

---

고려 사항 3️⃣ : 어디까지 (범위, Scope)

이번 과제에서 포함해야 하는 것과, 포함하지 않아도 되는 것을 구분하는 선

한마디로, 요구사항에 명시된 필수 기능까지만 구현하고 불필요한 확장은 하지 않는다는 것이다.

(실제로 프리코스에서는 "요구사항에서 벗어난 기능은 점수에 반영되지 않는다"는 이유도 있음)

예시:
포함 - 입력 예외 처리, 결과 출력 형식 등..
제외 - UI 꾸미기, DB 저장, 로그 기록 등..

💡 자주 하는 실수 정리

모호한 표현 금지: “예외 처리한다” → “IllegalArgumentException 발생 후 안내 문구 출력, 재입력 루프 진입”처럼 구체화한다.

출력 포맷을 정확히 명시: 띄어쓰기, 한글/영문, 쉼표 위치 등의 형식을 빠뜨리지 않고 명시한다.

랜덤·시간 같은 변동 요소 제어: 코드에서 바로 쓰지 말고, 교체할 수 있도록 설계 → 테스트 시 원하는 값으로 고정하여 사용한다. (예: 인터페이스 주입으로 테스트)

README는 살아 있는 문서: 처음엔 거칠게 써도 OK → 구현하며 계속 다듬고 고쳐나간다.

💡 기능 목록 - 커밋 간 연결

프리코스에서 말하는 것 처럼, 기능 구현 목록의 한 항목 = 한 커밋이 이상적이다.
이렇게 하면, 리뷰어가 목록을 보고 어떤 기능 구현이 충족 되었는지와 구현 흐름/기능을 쉽게 파악하여 피드백 해줄 수 있다.

정리

막상 기능 목록에 대해 정리하고 보니, 그동안 프리코스 문제를 풀면서 기능 목록을 가벼이 여기며 작성했던 지난 날을 반성하게 되었다.
기능 요구사항에 맞춰 대충 작성했던 목록인 만큼, 다른 사람들이 바라본 나의 커밋 메시지 또한 얼마나 더럽고 보기 힘들지는 짐작조차 되지 않는다..

앞으로 남은 두 문제에서는 이와 같은 문제점은 깨끗이 해결되어 있는, 좀 더 성숙한 개발자로 성장해 있길 바란다.