아키텍처

GitLab 프론트엔드 개발에서 아키텍처 결정을 문서화하고 공유하는 방법과 적절한 도구 선택 기준을 설명합니다.

GitLab에는 전담 "소프트웨어 아키텍트"가 없습니다. 모든 구성원이 스스로 결정을 내리고 적절하게 문서화하도록 권장됩니다. 이러한 결정을 어떻게, 어디에 문서화할지 알아보세요. 결정 문서화 # 새로운 기능을 구축할 때는 구축하려는 작업의 범위와 규모를 고려하세요. 그 답에 따라 작업을 지원할 수 있는 여러 도구나 프로세스가 있습니다. 우리는 기능 구축 프로세스를 가능한 한 효율적으로 유지하는 것을 목표로 합니다. 일반적인 규칙으로, 더 많은 시간이 소요되는 솔루션의 추가적인 지원과 구조가 필요하지 않은 한 가능한 한 가장 간단한 프로세스를 사용하세요. 머지 리퀘스트 # 변경 사항이 그룹 내로 제한되거나 단일 기여자가 있는 경우, 아키텍처 결정에 대한 가장 작은 문서화는 커밋이며, 이를 확장하면 머지 리퀘스트(MR)입니다. MR 또는 커밋은 병합된 후에도 참조할 수 있으므로, 나중에 참조해야 할 경우를 대비하여 특정 결정을 설명하는 좋은 설명, 코멘트, 커밋 메시지를 남기는 것이 중요합니다. 그룹 내에서 리뷰될 의도로 만들어진 MR이라도 모든 관련 의사결정을 명시적으로 포함해야 합니다. 아키텍처 이슈 # 작업 단위가 그룹 전체의 방향에 영향을 미칠 만큼 커지면, 기술적 방향을 논의하기 위한 아키텍처 이슈를 생성하는 것이 좋습니다. 이 프로세스는 비공식적이며 공식적인 요구 사항이 없습니다. GitLab 프로젝트 내에서 이슈를 생성하여 수행할 작업에 대한 계획을 제안하고 협업자를 초대하여 함께 제안을 다듬어 나갈 수 있습니다. 이 구조를 통해 그룹은 제안된 변경 사항을 검토하고, 피드백을 수집하고, 반복할 수 있습니다. 또한 기능 이슈의 코멘트 스레드나 MR 자체가 아닌 이슈를 단일 진실 공급원(Single Source Of Truth, SSOT)으로 사용할 수 있습니다. 논의를 원활하게 하기 위해 스키마와 같은 시각적 자료를 추가하는 것을 고려해보세요. 예를 들어, 이 CI/CD Catalog의 아키텍처 이슈 를 참고할 수 있습니다. 디자인 문서 # 앞으로의 작업이 단일 그룹, Stage 또는 잠재적으로 전체 부서(예: 프론트엔드 팀 전체)에 영향을 미칠 수 있는 경우, 디자인 문서 가 필요할 가능성이 높습니다. 이는 핸드북에 잘 문서화되어 있지만, 간략히 말씀드리자면, 디자인 문서는 대규모 변경 사항을 제안하고 진행에 필요한 피드백과 지원을 수집하는 가장 좋은 방법 입니다. 이러한 문서는 버전 관리가 되고, 시간이 지남에 따라 계속 발전하며, 조직 전체에 복잡한 이해를 공유하는 훌륭한 방법입니다. 또한 코치가 필요하며, 이는 대규모 변경 사항에 많은 경험이 있는 사람을 참여시키는 훌륭한 방법입니다. 이 프로세스는 모든 엔지니어링 부서가 공유하며 CTO가 소유합니다. 모든 디자인 문서를 보려면 GitLab 아키텍처 페이지 를 확인할 수 있습니다. 프론트엔드 RFC (더 이상 사용되지 않음) # 과거에는 프론트엔드 RFC 프로젝트 가 있었으며, 이 프로젝트의 목적은 대규모 변경 사항을 제안하고 전체 부서의 의견을 수렴하는 것이었습니다. 이