1. 토스플레이스 Technical Writing Partn.hwp
2. 토스플레이스 Technical Writing Partn.pdf

그래서 문서를 만들 때도 '잘 썼는가'보다 '누가 이 문서를 보고 무엇을 더 정확하게 할 수 있게 되는가'를 먼저 생각합니다.
저는 이런 유지·관리의 감각이야말로 실제 조직에서 기술문서를 살아 있게 만드는 핵심이라고 생각합니다.
저는 TechnicalWritingPartner의 역할이 단순히 문서를 많이 만드는 것이 아니라, 사람들이 실제로 참고하 고 신뢰하는 문서 환경을 만드는 것이라고 생각합니다.
제가 생각하는 좋은 기술문서는 많이 설명하는 문서가 아니라, 읽은 사람이 바로 같은 기준으로 움직일 수 있게 만드는 문서입니다.
저는 기술문서가 중요한 이유도 바로 여기에 있다고 생각합니다.
저는 문서를 쓰는 사람인 동시에, 문서가 실제로 어떻게 사용되는지를 살피는 사람이어야 한다고 생각합니다.
토스플레이스처럼 빠른 조직에서는 최신성을 유지하는 일이 곧 문서의 신뢰를 지키는 일이라고 생각하며, 저는 그 기준을 꾸준히 관리하는 방식으로 문서를 운영하겠습니다.
저는 결과적으로 "문서를 잘 쓰는 사람"보다"문서 덕분에 조직이 더 명확해졌다고 느끼게 만드는 사람"으로 일하고 싶습니다.

제가 기술문서에 끌린 이유는 글쓰기 자체보다 정확한 이해를 만드는 힘 때문입니다.
누군가가 말한 내용을 예쁘게 옮기는 것이 아니라, 실제로 무엇이 핵심인지 파악하고, 그 핵심이 누구에게 어떤 방식으로 전달되어야 하는지를 판단할 수 있어야 하기 때문입니다.
토스플레이스는 단순한 결제 단말기나 운영도구를 제공하는 조직이 아니라, 오프라인 사업환경에서 가게 운영의 복잡함을 줄이고 더 매끄러운 경험을 만드는 조직이라고 생각합니다.
하나는 "이 내용의 진짜 핵심은 무엇인가"이고, 다른 하나는 "이 내용을 처음 보는 사람이 어디서 막힐 것인가 "입니다.
당시에는 각자 맡은 역할이 있었고 필요한 자료도 어느 정도 존재했지만, 실제 진행 과정에서는 반복적으로 같은 질문이 나왔고 최신 정보가 무엇인지 헷갈리는 일이 잦았습니다.
하지만 자세히 보니 문제는 자료의 양이 아니라 구조였습니다.
어떤 문서가자 주바뀌는지, 어떤 문서는 기준 문서로 유지되어야 하는지, 어떤 문서는 폐기되거나 통합되어야 하는지를 판단할 수 있어야 합니다.
기술문서는 기술만 설명하는 문서가 아니라, 기 술이 실제 비즈니스와 고객 경험으로 연결되는 방식을 설명하는 문서가 되어야 한다고 생각합니다.
어떤 문장을 쓸 때도 멋있게 들리는 표현보다 오해 없이 이해되는 표현을 더 중요하게 생각합니다.
제가 토스플레이스에서 하고 싶은 일도 바로 그것입니다.
개발자는 구현과 운영이 더 선명하게 연결되었다고 느끼고, 기획자는 정책의도가 더 정확히 전달된다고 느끼며, 새로운 구성원은 더 빠르게 적응할 수 있고, 현장 운영 조직은 같은 질문을 덜 반복하게 되는 상태를 만드는 데 기여하고 싶습니다.
장기적으로는 토스플레이스 안에서 문서가 신뢰 가능 한기준으로 작동하도록 만드는 TechnicalWritingPartner가 되고 싶습니다.
대신 복잡한 것을 분명하게 만드는 사람, 흩어진 것을 연결하는 사람, 조직이 더 적은 혼선으로 더 멀리 갈 수 있게 돕는 사람으로 기억되고 싶습니다.
토스플레이스의 TechnicalWritingPartner는 바로 그 역할을 가장 밀도 있게 수행할 수 있는 자리라고 생각합니다.
저는 토스플레이스에서 읽기 좋은 문서보다 쓰이는 문서, 예쁜 문서보다 믿을 수 있는 문서, 남는 문서보다 실제 실행을 바꾸는 문서를 만 드는 사람으로 일하고 싶습니다.
제가 토스플레이스 TechnicalWritingPartner 직무에 지원한 이유는, 제가 가장 잘할 수 있는 방식으로 조직의 실행력을 높일 수 있는 역할이라고 생각했기 때문입니다.
또한 저는 TechnicalWritingPartner를 단순히 글을 잘 쓰는 사람의 자리가 아니라, 개발자와 기획자, 운영조직이 같은 그림을 보게 만드는 파트너 역할이라고 생각합니다.
제가 생각하는 좋은 기술문서는 많이 설명하는 문서가 아니라, 읽은 사람이 바로 같은 기준으로 움직일 수 있게 만드는 문서입니다.
기술문서는 종종 정보량이 많을수록 좋다고 생각되지만, 실제 현장에서는 정보가 많아도 핵심이 보이지 않으면 오히려 더 큰 혼선을 만들 수 있다고 생각합니다.
그래서 좋은 기술문서의 핵심은 풍부한 설명보다 구조화된 이해라고 봅니다.
또한 좋은 기술문서는 한번 읽고 끝나는 문서가 아니라, 실제로 자주 참고되고 업데이트 되는 문서 여야 한다고 봅니다.
특히 여러 사람이 동시에 움직이는 프로젝트에서는 같은 내용을 두고도 각자 이해 수준과 관심사가 다르기 때문에, 단순히 정보를 전달하는 것만으로는 협업이 잘 이루어지지 않는 경우가 많았습니다.
협업 과정에서 개발자와 기획자, 운영조직의 요구가 다를 때는 먼저 각 직군이 무엇을 기준으로 말하고 있는지부터 구분하겠습니다.
어떤 문서는 모든 직군이 공유해야 하는 공통 개념과 정책을 담아야 하고, 어떤 문서는 특정 직군의 실행을 위해 더 상세한 기술적 설명을 포함해야 할 수 있습니다.
어떤 문서가 자주 바뀌는지, 누가 업데이트 책임을 갖는지, 변경이 생겼을 때 문서에 어떻게 반영되는지가 정해져 있지 않으면 문서는 금방 신뢰를 잃게 됩니다.
또한 최신성은 기술적인 업데이트만으로 유지되지 않는다고 생각합니다.
토스플레이스처럼 빠른 조직에서는 최신성을 유지하는 일이 곧 문서의 신뢰를 지키는 일이라고 생각하며, 저는 그 기준을 꾸준히 관리하는 방식으로 문서를 운영하겠습니다.
저는 그런 지점을 먼저 발견하고, 조직이 실제로 더 빨라질 수 있는 문서를 만드는 데 기여하고 싶습니다.

문서, 사람, 생각, 조직, 기준, 만들다, 실제, 이해, 어떻다, 더, 운영, 싶다, 이다, 때문, 보다, 기술, 되어다, 정책, 레이스, 전달