조금 더 전문가처럼 문서를 만들어줄 수 있나요?

어떤 피드백은 오래 남는다.

특히 최선을 다했다고 믿은 결과물에 대해 들은 말이라면 더 그렇다.

입사한 지 석 달쯤 되었을 때였다.
회사에서 곧 릴리즈될 제품을 주제로, 사내 엔지니어들을 대상으로 기술 교육을 진행해 달라는 요청을 받았다.

음… 제가요?

그 시점의 나는, 이 회사에서 제품 이해도가 가장 낮은 사람 중 한 명이었을 것이다. 겨우 제품별 대표적인 차이점과 주요 용어를 알아듣기 시작했을 뿐, 내부 컴포넌트나 로직에 대해서는 모르는 것이 훨씬 더 많던 시기였다.

그래도 하라면 해야지. 나는야 월급쟁이.

그로부터 2주 남짓한 시간 동안, 나는 제품과 함께 씨름했다. 제품 설치 파일을 구하는 것부터 쉽지 않았고, 어렵사리 확보한 패키지를 익숙하지 않은 OS에 설치하는 과정에서도 수많은 오류를 마주했다.

무엇이 기존 기능이고 무엇이 신규 기능인지조차 명확히 구분하지 못한 상태에서, 신규 기능을 테스트하기 위해 같은 팀 동료들에게 수시로 질문하며 자료를 준비했다. 발표 당일 오전까지도 슬라이드를 고치고 또 고쳤다.

며칠 동안 거의 발표 내용을 외우다시피 공부했다. 학창 시절 시험 공부보다 더 하면 더 했지, 덜 하지는 않았을 것이다. 모국어가 아닌 영어로 진행되는 교육이었고, 나보다 훨씬 오래 이 회사에 몸담은 ‘준전문가’들을 청중으로 두고, 입사 3개월 차 신입이 제품을 설명해야 한다는 부담감도 컸다. 결국 발표 전날은 거의 밤을 새웠다.

급하게 준비한 교육이었지만, 팀 동료들은 잘했다며 격려해 주었고, 나 역시 큰 사고 없이 마무리했다는 점에서 나름의 성취감을 느꼈다. 며칠 후, 팀장과의 면담에서 예상하지 못한 피드백을 들었다.

정확한 워딩은 기억나지 않지만 요지는 이랬다.

수고 많으셨어요. 그런데 교육 자료가 조금 덜 전문가처럼 보이는 부분들이 있네요.
예를 들면, 제품 컴포넌트 간 데이터 흐름을 나타낸 다이어그램에서 화살표의 각이나 간격이 맞지 않는 부분 같은 것들이요.
제품 이해나 내용의 정확성뿐 아니라, 이런 미적인 부분까지 기대하는 게 회사의 욕심일까요?

다다익선이라는 말이 있고, 이왕이면 다홍치마라는 말도 있다. 하지만 시간과 인적 자원이 제한된 회사 업무에서 이런 피드백은 사람을 끝없는 완성도의 궤도로 밀어 넣는다.

시간만 충분하다면 완성도를 더 높이지 못할 이유는 없다. 포토샵이나 일러스트레이터를 활용할 수도 있고, 요즘은 이미지 생성 AI 툴도 넘쳐난다.

문제는 현실이다.

개발팀 산출물을 최소한의 검증만 거쳐 빠르게 시장에 내놓아야 하는 스타트업 환경에서, 사내 직원용 교육 자료에 사용되는 이미지의 화살표 간격 하나하나에까지 정성을 들일 여유는 없다. 그 상황에서 내가 가장 중요하게 지켜야 한다고 생각했던 기준은 오직 하나였다.

이 문서의 내용이 정확한가.

(여기까지 적고 보니, 나의 프로페셔널하지 못함과 부족한 섬세함에 대한 장황한 변명처럼 보일 수도 있겠다.)

그럼에도 불구하고, 내가 생각하는 기술 문서의 핵심 조건은 명확하다. 딱 두 가지다.

1. 문서의 정확성

문서에 기재된 글과 그림이 독자에게 혼란을 주지 않고, 기술적으로 정확한지를 최우선으로 판단해야 한다.
이를 위해서는 문서 작성 이후 반드시 사내 전문가의 검토 과정을 거쳐야 한다. 이는 기술 문서의 기본 중의 기본이다.

2. 문서의 유효성

내용이 틀리지 않았더라도, 어떤 제품과 어떤 버전에 유효한 문서인지 명시되어 있지 않다면 그 문서는 사실상 사용 가치가 없다.
예를 들어 v1.0을 기준으로 작성된 문서를 v1.1에서도 사용하려면, 해당 버전과의 호환 여부를 반영한 수정이나 추가 설명이 반드시 필요하다.

다이어그램 속 화살표 간격이나 정렬은 정식 배포되거나 외부에 남는 문서라면 분명 중요한 요소다.
하지만 배포의 시급성과 사내 엔지니어용 문서라는 특수성을 고려한다면, 문서의 미적 완성도보다 제품에 대한 정확한 이해와 표현에 더 큰 무게가 실리는 것이 자연스럽다고 생각한다.

기술 문서는 결국 ‘보기 좋은 자료’가 아니라,

필요한 순간에 정확하게 작동하는 도구여야 한다고 나는 믿는다.