이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 회고 문서와 기능 명세서 두 가지 유형의 문서화를 경험하면서 목적에 따라 방식이 달라야 한다는 점을 배웠습니다. 기능 명세서는 개발팀이 판단 없이 실행할 수 있도록 구체적이고 조건 중심으로 써야 했고, 회고 문서는 다음에 이 맥락을 모르는 사람도 이해할 수 있도록 배경과 결정 이유 중심으로 써야 했습니다. 저는 기능 명세서에는 케이스별 표를 선호하고, 회고 문서에는 결정 → 이유 → 결과 세 단락 구조를 사용합니다. 이 방식으로 작성한 온보딩 개선 회고가 팀 위키에 올라가 이후 입사한 팀원이 맥락 파악에 썼다는 피드백을 받았습니다. 문서화는 지금 함께하는 팀이 아니라 미래의 나와 다음 팀원을 위해 쓰는 것이라는 관점이 제 방식의 기준입니다.
문서화에서 제가 또 의식하는 건 찾기 쉽게 구조화하는 것입니다. 잘 써도, 나중에 못 찾으면 없는 거나 마찬가지였습니다. 그래서 제목과 항목을 일관된 규칙으로 통일해, 검색되게 했습니다. 회고 문서는 결정 → 이유 → 결과 세 단락으로, 기능 명세는 케이스별 표로 구조를 정했습니다. 그러면 누가 봐도 어디에 무엇이 있는지 예측됐습니다.
문서는 한 번 쓰고 끝이 아니라, 계속 찾아 쓰는 자산이라 검색성이 중요했습니다. 그래서 쓸 때부터 일관된 구조와 제목 규칙을 챙겼습니다. 찾기 어려운 문서는 안 읽혔습니다.
문서화에서 제 선호가 안 맞을 때 제가 푸는 방식은 목적에 맞게 구조를 바꾸는 것입니다. 케이스별 표가 좋아도, 회고처럼 맥락이 중요한 문서엔 표가 안 맞았습니다. 그래서 기능 명세는 표로, 회고는 단락 구조로 나눠 썼습니다. 한 번은 익숙한 방식을 고집하다, 읽는 사람이 헷갈린 적이 있습니다. 그 뒤로 내 선호보다, 그 문서를 누가 왜 보는지에 맞췄습니다.
한 방식이 모든 문서에 맞지는 않았습니다. 그래서 문서 유형에 따라 구조를 갈아입혔습니다. 문서화는 미래의 나와 다음 팀원을 위해 쓰는 것이라, 그들이 읽기 쉬운 게 우선이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.