이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
복잡한 백엔드 로직을 PRD나 Spec 문서로 작성할 때 가장 중요한 건 예외 케이스를 빠짐없이 정의하는 것입니다. 정상 흐름은 누구나 쉽게 정의할 수 있지만, 에러 상황이나 경계 조건에서 어떻게 동작해야 하는지를 명확히 적지 않으면 개발자마다 다르게 구현할 수 있습니다. 용어 정의도 중요합니다.
'완료 상태', '취소 상태' 같은 용어가 비즈니스 팀과 개발 팀에서 다르게 해석될 수 있어서 문서에서 명확히 정의해두는 것이 오해를 줄입니다. 검증 기준을 함께 쓰는 것도 도움이 됩니다. 어떤 조건에서 이 로직이 올바르게 작동한 것인지를 테스트 케이스 형태로 정의해두면 개발자가 스스로 검증할 수 있습니다.
문서는 로직을 설명하는 것이 아니라 구현자와 기획자가 같은 것을 생각하게 만드는 것입니다.
수업 과제로 복잡한 백엔드 로직을 명세 문서로 쓸 때, 제가 가장 부딪힌 건 같은 용어를 서로 다르게 이해한다는 점이었습니다. '완료 상태'라는 말을 저는 결제까지로, 개발 쪽은 발송까지로 받아들여, 다 합의한 줄 알았는데 구현이 어긋났습니다. 그래서 저는 닥치는 대로 로직을 적기보다, 문서 앞에 핵심 용어의 정의를 먼저 못 박는 절차로 돌아갔습니다. '완료'가 정확히 어느 시점인지를 적고 나니 해석 차이가 줄었습니다. 다만 이걸 혼자 정하진 못했습니다. 비즈니스 팀과 개발 팀이 그 용어를 어떻게 쓰는지 양쪽에 확인해 합의했습니다. 문서는 로직을 설명하는 게 아니라 구현자와 기획자가 같은 걸 생각하게 만드는 일이라는 걸 그때 배웠습니다. 이후로는 명세를 쓸 때 용어 정의부터 맞추는 걸 절차로 남겼습니다.
복잡한 백엔드 로직을 문서로 쓸 때 제가 중요하게 본 건, 정상 흐름보다 예외와 경계 조건을 빠짐없이 적는 일입니다. 정상 동작은 누구나 같게 이해하지만, 에러가 나거나 값이 경계에 걸렸을 때 어떻게 동작해야 하는지를 안 적으면 개발자마다 다르게 구현한다는 걸 봤습니다. 그래서 저는 각 로직에 '어떤 조건에서 올바르게 작동한 것인가'를 테스트 케이스 형태로 함께 적었습니다. 그러면 개발자가 스스로 검증할 수 있고, 기획 의도와 구현이 어긋나는 걸 미리 잡습니다. 다만 제 한계도 인정합니다. 저는 수업 규모의 로직을 다뤘을 뿐, 실제로 얽힌 시스템에서 모든 예외를 빠짐없이 떠올리는 건 더 어렵다는 걸 압니다. 그래서 예외를 혼자 다 잡으려 하기보다 개발자와 함께 점검하려 합니다. 문서는 같은 것을 생각하게 만드는 도구라는 시각을 두려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.