도메인 이해 후 모델링 경험
약 90초
비즈니스 요건을 먼저 충분히 이해하고 데이터 모델을 설계한 경험
팀 프로젝트에서 쇼핑몰 주문 관리 API를 설계할 때, 처음엔 바로 테이블 구조부터 잡으려 했습니다. 나중에 '교환·반품 처리는요?'라는 질문이 나오면서 초반 설계가 전부 바뀌는 상황이 됐습니다.
그 이후로 코드 전에 '주문이 가질 수 있는 모든 상태를 나열하고, 각 상태 전이 조건을 팀과 함께 정리'하는 단계를 먼저 밟게 됐습니다. 상태 다이어그램을 그리고 나서 테이블을 설계하니 이후 변경이 거의 없었습니다.
API 설계도 비슷하게 접근했습니다. 리소스 관점으로 먼저 정의하고, 각 리소스에 필요한 액션을 HTTP 메서드로 매핑했습니다. '클라이언트가 어떤 화면에서 이 데이터를 쓰는가'를 먼저 물으면 불필요한 필드를 줄이는 데도 도움이 됐습니다. 요건 이해가 설계보다 앞서야 한다는 걸 그때 배웠습니다.
이 결의 특징
테이블부터 잡았다가 교환·반품 처리 질문에 설계가 뒤집힌 실패를 겪고, 이후 상태 다이어그램을 먼저 그리는 습관으로 전환한 흐름이 담겨 있습니다. 리소스 관점의 API 설계로 이어진 지점도 구체적입니다.
이 결이 통하는 자리
설계가 뒤집혔던 구체적 순간과 이후 상태 다이어그램 작업 방식이 함께 남아 있을 때 통합니다. 요건 이해가 설계보다 앞서야 한다는 결론이 실패에서 나온 것임이 드러나면 면접관이 신뢰하는 결이 보입니다.