회사를 다니기 전에는 개발이라고 하면 자연스럽게 코드를 먼저 떠올렸다.
하지만 실무에 들어와 보니, 실제 개발은 코드를 작성하기 전 단계에서 이미 절반 이상 결정되고 있었다.
입사 후 한 달 동안 나는 실제 구현에 앞서 다음 4가지 문서를 작성해보았다.
- 유스케이스
- 플로우 차트
- 시퀀스 다이어그램
- 단위 테스트
이 문서들을 작성하면서 “왜 개발 전에 정리가 필요한지”를 체감할 수 있었다.
유스케이스 (Use Case)
- 사용자의 행동을 기준으로 시스템이 어떻게 반응해야 하는지 정리하는 문서
누가, 어떤 상황에서, 무엇을 하며, 그 결과는 무엇인가?
라는 질문에 답하는 과정이다.
예를 들어 ‘로그인’이라는 기능 하나만 보더라도
- 로그인 성공
- 로그인 실패
- 최초 로그인
- 조건에 따른 분기
처럼 생각보다 많은 경우의 수가 존재한다.
유스케이스를 먼저 작성하면서
기능을 단순히 ‘있다 / 없다’가 아니라, 흐름과 조건으로 바라보게 되었다.
플로우 차트 (Flow Chart)
- 유스케이스를 시각적으로 풀어낸 문서
텍스트로만 정리했을 때 놓치기 쉬운:
- 조건 분기
- 반복되는 흐름
- 예외 케이스
를 한눈에 확인할 수 있었다.
특히, “이 단계에서 실패하면 어디로 돌아가야 하지?”
같은 질문이 자연스럽게 생겼고, 불필요한 분기나 복잡한 흐름을 미리 정리할 수 있었다.
시퀀스 다이어그램 (Sequence Diagram)
- 시간의 흐름에 따라 시스템 간의 상호작용을 정리하는 문서
- 사용자
- 프론트엔드
- 서버
- 외부 시스템
이 각각이 어떤 순서로 요청하고 응답하는지를 명확히 표현할 수 있다.
이 문서를 작성하면서
- 이 로직은 프론트 책임인지
- 서버에서 처리해야 하는지
- 언제 API가 호출되는지
같은 경계가 훨씬 또렷해졌다.
단위 테스트 (Unit Test)
- 말 그대로 코드의 가장 작은 단위(함수/모듈/컴포넌트)가 의도대로 동작하는지 검증하는 테스트
단위 테스트 관점에서 기능을 정리하다 보니
- 정상 케이스
- 실패 케이스
- 경계 조건
을 자연스럽게 생각하게 되었고,
그 과정에서
“이 기능은 이렇게 구현하면 안 되겠구나”
라는 생각이 구현 전에 먼저 들었다.
단위 테스트가 중요한 이유는 다음과 같다.
- 구현 전에 요구사항의 빈틈이 보인다
- 코드 변경과 리팩토링이 쉬워진다
- 버그를 더 빠른 단계에서 발견할 수 있다
테스트는 단순한 검증이 아니라, 기능을 정확하게 정의하는 도구라는 느낌을 받았다.
문서를 먼저 쓰며 느낀 점
이 네 가지 문서를 작성하며 공통적으로 느낀 점은 다음과 같다.
- 구현 전에 고민할수록
- 코드 작성 속도는 오히려 빨라진다
- 질문의 질이 달라진다
- “왜 이렇게 구현했는지” 설명할 수 있게 된다
문서 작성은 개발의 부수적인 작업이 아니라 개발 사고를 정리하는 핵심 과정이라는 걸 실감했다.
