이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
기술 문서에서 가장 중요하게 생각하는 건 읽는 사람이 다음 행동을 할 수 있게 만드는 것입니다. 정보를 나열하는 문서가 아니라 독자가 무엇을 알고 싶어서 이 문서를 열었는지를 먼저 생각하고 구조를 잡습니다. 수업 팀 프로젝트에서 API 연동 가이드를 작성했는데, 처음에는 파라미터 설명 위주로 작성했다가 팀원들이 어디서 시작해야 하는지 모르겠다는 피드백을 받았습니다.
빠른 시작 예시를 첫 번째로 두고 이후에 상세 설명을 배치하는 방식으로 구조를 바꾸니 바로 쓸 수 있다는 반응이 나왔습니다. 문서의 업데이트 시점과 적용 범위를 명확히 표시하는 것도 중요합니다. 버전이 바뀐 뒤 문서가 안 맞는 경우가 생기면 신뢰가 떨어집니다.
틀린 문서보다 없는 문서가 낫다는 말이 있는데, 그게 문서 관리를 지속하는 이유가 됩니다.
기술 문서에서 제가 특히 중요하게 보는 건, 무엇을 하는지뿐 아니라 왜 이렇게 설계했는지를 남기는 일입니다. 문서가 'What'만 적고 'Why'를 빠뜨리면, 나중에 코드를 고치는 사람이 설계 의도를 몰라 같은 실수를 반복합니다. 그래서 저는 어떤 결정을 적을 때 그 배경과 대안, 왜 이걸 골랐는지를 함께 적으려 합니다. 그러면 문서가 단순 설명서를 넘어, 미래의 수정자가 판단할 근거가 됩니다. 다만 제 한계도 인정합니다. 저는 수업 규모의 문서를 다룬 수준이라, 아키텍처 결정 기록처럼 'Why'를 체계적으로 남기는 방법을 실무에서 운영해 본 경험은 없습니다. 또 모든 결정에 이유를 다 적으면 문서가 무거워져, 어느 결정까지 기록할지 가르는 감각도 부족합니다. 그래서 기술 문서를 What 나열이 아니라, 설계 의도를 남겨 미래의 수정자가 헤매지 않게 하는 일로 보되 그 기록의 균형을 더 익히려 합니다.
기술 문서에서 제가 가장 중요하게 본 건, 읽는 사람이 다음 행동을 할 수 있게 만드는 일입니다. 수업 팀 프로젝트에서 API 연동 가이드를 쓸 때, 처음엔 파라미터 설명 위주로 썼다가 팀원들이 어디서 시작해야 할지 모르겠다는 피드백을 받았습니다. 그래서 저는 빠른 시작 예시를 첫 번째로 두고 상세 설명을 뒤에 배치하는 방식으로 구조를 바꿨더니, 바로 쓸 수 있다는 반응이 나왔습니다. 독자가 무엇을 알고 싶어 이 문서를 열었는지를 먼저 생각해 구조를 잡은 셈입니다. 또 문서의 업데이트 시점과 적용 범위를 명확히 표시하는 것도 중요했습니다. 버전이 바뀐 뒤 문서가 안 맞으면 신뢰가 떨어지기 때문입니다. 다만 제 한계도 인정합니다. 저는 작성자라 완성도를 제 관점에서 판단하기 쉬워, 실제 독자에게 이해되는지 리뷰받는 과정은 충분히 거치지 못했습니다. 또 코드가 바뀔 때 문서를 자동으로 갱신하는 구조도 다뤄 보지 못했습니다. 그래서 독자 행동 중심으로 구조를 잡되, 리뷰와 최신성 유지 역량을 더 키우려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.