adr

2 개의 포스트

toss3분 읽기큐레이션 요약

5. Technical Writer, 사라질 결심

AI 시대에 문서는 조직의 맥락을 AI에 전달하는 핵심 수단이므로, AI가 문서를 잘 만들고 관리하도록 문서화 원칙과 사례를 학습시켜야 한다. 토스는 소수의 Technical Writer(TW)만으로 수천 명의 문서를 관리할 수 없다는 문제를 해결하기 위해, TW의 역할을 AI Skill로 자동화하려 했다. 하지만 Skill을 만들어 공개하는 것만으로는 사용률이 높아지지 않았고, 사용자가 직접 설치·호출하고 자료를 준비해야 하는 불편함이 주요 장애물로 드러났다. ## AI에게 TW의 암묵지 전달하기 - 기존 TW의 리뷰 코멘트를 분석해 문서를 바라보는 관점과 테크니컬 라이팅 원칙을 추출했다. - 기존 가이드를 AI가 기계적으로 적용하지 않도록 각 원칙에 다음을 함께 제공했다. - 잘못된 예시 - 올바른 예시 - 왜 그렇게 작성해야 하는지에 대한 설명 - 자주 작성하는 문서 유형별 템플릿을 만들었다. - ADR 템플릿에는 다음과 같은 필수 섹션을 명시했다. - 개요 - 맥락 - 고려한 선택지와 장단점 - 최종 결정 - 결정 근거 - 반드시 들어가야 하는 섹션에는 `(required)`를 붙여 AI가 핵심 정보를 누락하지 않게 했다. - 문서 유형과 템플릿을 함께 제공해 AI가 구조와 작성 목적을 이해하도록 했다. ## 문서 작성 Skill 구축 TW가 문서 작성을 지원하는 과정을 네 단계로 분해해 AI Skill에 반영했다. - **목적과 배경 확인** - 서비스·프로젝트명 - 문서 목적 - 대상 독자 - 필요한 상세 수준 - 참고 자료 - 예상 문서 구조를 질문한다. - **문서 구조 결정** - 템플릿이 없으면 개요, 핵심 내용, 부가 정보 순서로 기본 구조를 만든다. - 적합한 템플릿이 있으면 온보딩 가이드, 회의록, PRD 등 문서 유형별 템플릿을 참고한다. - **본문 작성** - 테크니컬 라이팅 원칙과 MDX 규칙에 따라 내용을 채운다. - 템플릿은 문서의 목적과 유형에 맞을 때 보조적으로 사용한다. - **점검** - 어색한 표현이나 누락된 정보를 확인한다. - 필수 정보가 부족하면 추측하지 않고 질문이나 주석으로 남긴다. - 선택 항목은 근거 자료가 없을 경우 빈 섹션으로 만들지 않는다. 사용자는 AI가 묻는 질문에 답하기만 하면 되므로, TW와 대화하듯 문서 초안을 완성할 수 있도록 설계했다. ## 문서 리뷰 Skill의 시행착오 처음에는 기존 리뷰 코멘트를 체크리스트로 바꿔 AI가 모든 항목을 점검하게 했다. 그러나 AI가 중요한 문제는 놓치고, 실제로 필요하지 않은 코멘트를 억지로 생성하는 문제가 발생했다. - 잘 작성된 문서의 기준은 어느 정도 정형화할 수 있다. - 반면 잘못된 문서의 문제는 문서마다 다르게 나타난다. - 목적은 명확하지만 논리 흐름이 어색한 경우 - 논리는 자연스럽지만 독자에게 전달할 가치가 빠진 경우 - 따라서 고정된 체크리스트만으로는 다양한 문서 문제를 효과적으로 찾기 어려웠다. 이를 해결하기 위해 AI가 원칙을 참고해 자율적으로 판단하는 리뷰 워크플로를 만들었다. - 테크니컬 라이팅 원칙 파일을 먼저 읽는다. - 문서를 원칙에 비추어 스스로 검토한다. - 문제라고 판단한 이유와 수정 초안을 코멘트로 작성한다. - 마지막에 체크리스트로 누락을 한 번 더 확인한다. 기존 리뷰 코멘트는 단순 점검 목록이 아니라, 원칙이 실제 문서에 어떻게 적용되는지 보여주는 예시로 활용했다. 예를 들어 `date: string`처럼 이름과 타입만 적는 대신, 의미·허용 형식·사용 예시까지 함께 작성하도록 가르쳤다. ## Skill만 공개해서는 충분하지 않았다 두 가지 Skill을 만들어 사내에 공개했지만, 기대만큼 사용되지 않았다. - 사용자가 직접 Skill을 다운로드하고 설치해야 했다. - 비개발자에게 CLI 기반 설치 과정이 낯설고 어려웠다. - Skill을 설치한 뒤에도 문서를 작성할 때마다 사용자가 AI Skill을 떠올리고 직접 호출해야 했다. - 문서 작성에 필요한 코드, 기획서, 기존 문서, Slack 링크 등의 자료도 사용자가 직접 찾아 AI에게 전달해야 했다. - 결국 자동화된 기능이 있어도 실제 업무 흐름과 분리되어 있으면 사용자가 추가로 수행해야 하는 일이 많았다. 따라서 문서 자동화의 핵심은 좋은 프롬프트나 Skill을 만드는 데서 끝나지 않는다. 사용자가 별도로 설치하거나 기억하거나 자료를 수집하지 않아도, 실제 업무 과정에서 자연스럽게 AI가 문서 작성과 리뷰를 지원하도록 연결해야 한다.

원문 읽기(새 탭에서 열림)
woowahan원문

우리는 코드처럼 문화도 리팩토링한다 (새 탭에서 열림)

배달의민족 커머스웹프론트개발팀은 조직 규모 확대에 따른 복잡도와 비효율을 해결하기 위해 문화를 코드처럼 리팩토링하며 '경계 없는 파트' 구조를 도입했습니다. 특정 도메인이나 서비스에 갇히지 않고 책임을 확장하는 R&E(Responsibility & Expandability) 원칙을 통해 기술적 통합과 조직의 유연성을 동시에 확보했습니다. 이러한 시도는 서비스 간 장벽을 허물고 구성원들이 커머스 전반을 조망하는 엔지니어로 성장하며, 비즈니스 요구에 기민하게 대응하는 결과로 이어졌습니다. ### 경계 없는 파트와 R&E 중심의 조직 구성 * **전통적 분할 방식의 탈피**: 프로젝트, 페이지, 서비스(B마트/배민스토어) 단위로 조직을 나눌 경우 발생하는 리소스 불균형과 도메인 파편화 문제를 해결하기 위해 고정된 경계를 제거했습니다. * **R&E(Responsibility & Expandability) 도입**: 단순히 주어진 역할만 수행하는 R&R을 넘어, 문제 해결을 위해 업무 영역을 스스로 확장하고 동료를 돕는 'Own It' 정신을 조직 구조에 이식했습니다. * **유연한 리소스 배분**: 약 20명의 프론트엔드 개발자를 3개 파트로 나누되, 특정 도메인에 종속시키지 않고 팀 상황에 따라 업무를 배분하여 병목 현상을 최소화했습니다. ### 기술적 통합을 통한 도메인 확장성 확보 * **통합 아키텍처 구축**: B마트와 배민스토어의 상품 카드 및 상세 화면 등 유사한 UI/UX를 공통 모듈로 추상화하고 API 구조를 맞춤으로써 코드 베이스의 일관성을 확보했습니다. * **엔지니어링 역량 강화**: 개발자들이 고객 서비스의 UX부터 어드민의 데이터 흐름까지 전방위적인 도메인을 학습하게 하여, 특정 기능 담당자가 아닌 커머스 전체를 이해하는 전문가로 성장하도록 유도했습니다. * **리스크 관리(Bus Factor 개선)**: 특정 인원이 부재하더라도 다른 팀원이 맥락을 즉시 이어받을 수 있는 구조를 만들어 프로젝트 중단 위험인 '버스 팩터'를 획기적으로 낮췄습니다. ### 지속적인 개선을 위한 소통과 기록의 리팩토링 * **의사결정 자산화(ADR)**: 단순한 기획 공유인 1Pager 방식에서 나아가, 기술적 결정의 배경과 맥락을 기록하는 ADR(Architecture Decision Record)을 도입해 팀의 지식을 체계적으로 관리합니다. * **루틴의 재설계와 자동화**: 반복적인 업무나 귀찮은 과정을 레거시로 남기지 않고, 자동화와 프로세스 개선을 통해 개발 효율성을 지속적으로 높입니다. * **심리적 안전감 기반의 협업**: '불판'과 같은 자유로운 논의 문화를 통해 실패를 과정으로 수용하고, 질문이 스터디로 이어지는 선순환 구조를 구축했습니다. 성장하는 조직에서 발생하는 비효율을 방치하지 않고, 코드 리팩토링과 같은 관점에서 구조와 문화를 끊임없이 개선하는 태도가 중요합니다. 특히 도메인 간 경계를 허무는 시도는 대규모 서비스 통합이라는 복잡한 비즈니스 과제를 해결하는 데 매우 강력한 전략이 될 수 있습니다.