이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
기술 지원 문서를 작성할 때 가장 주의한 건 독자의 기술 수준을 먼저 파악하는 것입니다. 엔드유저를 위한 안내서와 개발자를 위한 기술 가이드는 쓰는 방식이 전혀 다릅니다. 전문 용어를 쓸 경우 간략한 설명을 병기하거나, 아예 일상 언어로 바꿔 쓰는 것이 사용자 혼란을 줄입니다. 또 단계별 절차를 번호 리스트로 명확히 구분하고, 각 단계에서 무엇을 확인해야 하는지를 구체적으로 씁니다. 스크린샷이나 예시 코드를 함께 제공하면 이해도가 높아집니다. 인턴 경험에서 지원 문서를 업데이트하면서, 실제 지원 문의가 줄어드는지를 기준으로 문서 품질을 판단하는 것이 효과적임을 배웠습니다.
좋은 기술 문서는 문의가 오기 전에 문제를 해결합니다.
기술 문서를 올리고 나면 끝이라고 생각했는데, 같은 질문이 계속 들어오면서 문서가 읽혀도 해결이 안 되는 부분이 있다는 걸 알게 됐습니다. 인턴 때 FAQ 문서를 담당하면서 문의 내용에 자주 등장하는 키워드를 정리해 어느 항목이 부족한지를 역으로 추적했습니다.
특정 오류 메시지에 대한 문의가 반복되면 해당 항목 예시가 부족하다는 신호로 봤습니다. 특정 오류 코드에 관한 문의가 줄었는지로 수정 전후 효과를 비교했습니다. 문서를 냈다가 아니라 문의가 줄었다를 목표로 설정하면 뭘 고쳐야 하는지가 분명해집니다. 어떻게 효과를 확인할지를 문서 초안 단계부터 같이 생각하는 것, 그게 이후 기술 문서를 쓸 때 항상 넣는 요소가 됐습니다.
기술 문서를 처음 썼을 때 너무 꼼꼼하게 쓰려다 아무도 안 읽는 문서를 만든 적이 있습니다. 모든 예외 상황을 다 넣었더니 8페이지가 됐고, 팀원이 어디서 찾아야 하는지 모르겠다고 했습니다. 길면 정확하다는 생각이 오히려 접근성을 낮춘다는 걸 그때 처음 알았습니다. 문서를 반으로 줄이면서 자주 쓰는 케이스 3개만 상단에 두고 나머지는 아래로 내리는 구조로 바꿨습니다.
그다음 주부터 같은 내용 질문이 눈에 띄게 줄었습니다. 문서는 읽히는 구조가 내용보다 먼저입니다. 이후에는 새 문서를 쓸 때 처음 보는 사람이 30초 안에 원하는 항목을 찾을 수 있는지를 기준으로 초안을 검토합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.