이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
문서를 쓸 때 독자가 아무것도 모른다고 가정하고 시작하는 것이 제 기본 방식입니다.
캡스톤 프로젝트에서 팀 내 환경 설정 가이드를 작성했을 때, 저는 당연히 알 것이라고 생각하고 파이썬 설치 단계를 생략했습니다. 그런데 팀원 한 명이 파이썬 자체를 처음 사용하는 상황이어서 첫 단계부터 막혔습니다. 그 경험 이후로 대상 독자가 어느 수준인지를 먼저 확인하고, 그보다 한 단계 더 아래에서 시작하는 방식을 택하게 됐습니다.
이후 같은 문서를 모든 단계를 포함해서 다시 쓰니, 팀원이 혼자 설정을 완료했습니다. 문서는 완성하고 나서 직접 따라해 보는 사람에게 검토를 부탁하는 것이 가장 효과적인 피드백 방식이라는 것도 배웠습니다.
문서에서 이해도를 높이는 데 가장 효과적이었던 것은 설명보다 예시를 먼저 보여주는 방식이었습니다.
프로젝트 보고서를 쓸 때 원리 설명을 먼저 길게 적고 예시를 뒤에 붙이는 방식을 자주 썼는데, 피드백을 받아보면 예시 부분만 읽고 이해했다는 사람이 대부분이었습니다. 반대로 예시를 먼저 보여주고 그 아래에 원리를 짧게 설명했더니 이해가 더 빠르다는 반응이 늘었습니다.
다만 예시만 있고 원리가 없으면 응용이 안 된다는 피드백을 한 명에게 받았습니다. 이후로는 예시 먼저, 짧은 원리 설명 순서로 구성하는 방식을 기본으로 쓰고 있습니다. 독자마다 이해 방식이 달라서 둘 다 넣는 것이 안전하다고 생각합니다.
문서 이해도를 높이기 위해 항상 초안을 완성하면 실제 독자에게 먼저 보여주는 방식을 씁니다.
졸업 논문 초안을 스스로 읽을 때는 문제가 없다고 느꼈는데, 친구에게 보여줬더니 첫 두 문단이 무슨 말인지 모르겠다는 반응이 나왔습니다. 제가 당연하게 사용한 전문 용어들이 문제였습니다. 그 이후로 용어를 쉬운 말로 바꾸거나 괄호 안에 설명을 추가했더니 같은 친구가 훨씬 이해하기 쉽다는 피드백을 줬습니다.
그 경험으로 문서 작성자는 자신의 글이 명확하다고 느끼는 경향이 있어서 독자의 피드백이 반드시 필요하다는 것을 배웠습니다. 한 명의 피드백이라도 받으면 놓쳤던 문제가 보입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 에디터·작가 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.