예시 답변 1
약 65초
경험 기반 구체화
문서화와 베스트 프랙티스를 보장하기 위한 노력에서 가장 중요하게 여기는 것은 작성 타이밍입니다. 코드를 다 짜고 나중에 쓰면 이미 구현 맥락을 잊어서 설명이 얕아지기 때문에, 작업 중 중요한 결정이 생길 때 바로 남기는 습관을 갖고 있습니다. 학교 팀 프로젝트에서 아키텍처 결정 기록(ADR)을 간단히 남기는 방식을 써봤는데, '왜 이 방식을 선택했는가'를 짧게 기록해두자 한 달 뒤 팀원이 코드를 수정할 때 훨씬 빠르게 맥락을 파악했습니다. 코드 주석은 무엇을 하는지가 아니라 왜 이렇게 구현했는지를 쓰는 것이 원칙인데, 이름이 명확한 함수라면 주석 없이도 읽히는 코드를 목표로 합니다.
README는 프로젝트 진입점이라고 생각해서, 처음 보는 사람이 5분 안에 실행해볼 수 있을 정도로 구체적으로 쓰는 것을 기준으로 삼습니다.
이 결의 특징
문서화와 표준 관행을 별개로 보지 않고 하나의 순환 구조로 연결한 흔적이 보입니다. 프로세스를 문서에 담고, 그 문서가 다음 프로세스 개선에 입력되는 방식으로 설명하는 패턴이 통합니다.
이 결이 통하는 자리
팀 내 표준화나 온보딩 자료 정비가 필요한 자리에서 이 결이 자주 보입니다. 문서를 '한 번 쓰는 결과물'이 아닌 '살아있는 기준'으로 바라보는 시각이 있는 자리에서 통합니다.