RFC(Request for Comments) 작성, 비동기적 검토, 의사 결정 회의, ADR(Architecture Decision Record) 작성의 4단계 프로세스 제시
RFC 작성 시 문제 정의, 제안된 솔루션, 이해관계자 태깅 등을 명확히 해야 함
비동기적 검토 기간을 통해 더 나은 피드백을 얻고, 의사 결정 회의 효율성을 높임
ADR 작성을 통해 결정 사항을 영구적으로 기록하고, 추후 참조 가능하도록 함
RFC 작성은 아키텍처 결정 프로세스의 핵심 단계로, 문제 정의와 해결 방안 제시를 통해 의사 결정의 기반을 마련한다. 특히, Context, Proposed Solutions, Recommendation, Stakeholders, Open Questions, Timeline 등 구체적인 항목을 포함하여, 관련자들의 이해를 돕고 효율적인 피드백을 유도한다. 또한, 이해관계자를 명확히 태깅하여 의사 결정 과정의 투명성을 확보한다.
비동기적 검토 기간은 RFC에 대한 심층적인 피드백을 얻는 데 중요한 역할을 한다. 댓글을 통해 질문, 우려 사항 제기, 대안 제시 등 다양한 의견을 수렴할 수 있으며, RFC 작성자는 이에 적극적으로 응답하여 합의를 형성해야 한다. 이러한 과정을 통해 의사 결정 회의의 효율성을 높이고, 을 가능하게 한다.
의사 결정 회의는 RFC와 댓글을 기반으로 진행되며, 프레젠테이션 형식이 아닌 워킹 세션(Working Session) 형태로 운영된다. 회의 시간은 30~60분으로 제한하고, 오픈 질문 해결, 옵션 토론, 의사 결정 순으로 진행한다. 또한, 소규모 인원(5~8명)으로 제한하여 집중도를 높이고 효율적인 의사 결정을 유도한다.
ADR은 결정된 아키텍처 사항을 영구적으로 기록하는 문서로, RFC와는 다른 목적을 가진다. ADR은 결정 사항, 결과, 고려 사항 등을 간결하게 요약하여, 향후 참조 및 유지보수에 활용된다. ADR 작성을 통해 아키텍처 결정의 일관성을 유지하고, 팀 내 지식 공유를 촉진한다.
최근 LLM(Large Language Models)은 RFC 작성 과정에서 유용한 도구로 활용될 수 있다. 기술 간의 트레이드오프(Trade-offs) 조사, 장단점 목록 생성, 기술 문서 요약, 엣지 케이스(Edge Cases) 식별 등 다양한 작업을 지원한다. 하지만, LLM이 RFC 전체를 작성하는 것이 아니라, 생각의 파트너(Thought Partner)로서 활용하는 것이 중요하다.