Year in Review

개발팀의 설계 및 개발 산출물

기록의 중요성

현재 회사에서 개발팀은 애자일하게 일하기 위해 스크럼 프레임워크(스프린트)를 이용하고 있다.

그리고 스프린트는 전반기/후반기로 나누어서 진행을 하고 있고, 후반기에는 배포를 위해 업데이트 테스트까지 포함해 진행을 하고 있다.

전반기 스프린트로 현재 개발팀이 일하는 방식을 설명하자면, 항상 상시로 기획된 백로그들 중에서 이번 스프린트에 들어갈 스프린트 백로그를 우선순위 매트릭스를 기반으로 기획팀에서 선정한다. 보통 Business Impact가 큰 내용들이 주가 되지만 해당 프로젝트 개발에 들어가는 개발 리소스도 우선순위 매트릭스의 한 요소로 있기 때문에 개발팀장/파트장도 참여를 하게 된다.

이렇게 스프린트를 위한 만반의 준비가 끝나면 스프린트 백로그로 선정된 기획서가 개발팀으로 전달이 되고 개발팀의 스프린트가 시작된다.

예전의 경우 바로 개발을 들어갔었지만 지금의 경우 항상 개발전에 설계주를 7일동안 진행하며 각 스프린트 백로그에 대한 스토리 포인트 산정을 진행한다. 이때 기획 내용이 가끔 변경되기도 한다. 그리고 설계가 모두 끝나면 산정된 스토리 포인트와 열심히 개발팀내에서 논의해서 만든 개발 설계 산출물과 함께 스프린트 개발을 진행한다. 해당 설계 산출물은 프론트 팀과 백엔드 팀이 소통할때도 필수적이지만 QA팀분들이 테스트 설계를 할 때도 매우 중요한 자료의 기반이 된다.

지금까지는 설계 결과 산출물의 필요 조건으로는 API나 Config 설정 변경 등에 대해 지라 티켓으로 적어서 공유하는 정도였기에 정확한 기준이 필요하다고 판단이 되었다. 이 기준을 세움으로써 모든 개발자 분들의 최소 개발 설계 기준을 제시할 수 있다고 생각했고, 이 기준대로 차곡차곡 쌓이는 설계 문서들은 나중에 들어오시게 될 개발자분들에게도 큰 도움을 줄 수 있는 온보딩 자료가 될 수 있겠다는 생각이 들었다.

그리고 현재 개발팀에서 백엔드 기술 스택으로 go + protobuf + connect기반의 기술 스택으로 통일하고 있어 이런 부분들도 설계 결과 산출물로 고려했다.

그래서 아래와 같은 기준을 CTO님과 이야기해 세워볼 수 있었다.

해당 설계 결과 산출물은 설계주 동안 팀내에서 피드백 받은 최종 설계 내용물로 작성하며 설계주 마지막날에 공유를 한다.

그 다음에 개발을 약 2주간 (근무일 기준 10일)을 진행한다. 개발주가 모두 끝나면 다음과 같은 개발 결과 산출물을 만든다.

여기서 go-doc이나 ts-doc과 같은 툴을 사용하여 코드와 주석으로부터 만들어낸 문서도 따로 관리하면 좋지 않을까 생각이 들었지만 코드 자체에 이미 있는 내용들이라 굳이 따로 또 문서로 관리할 필요는 현재 당장 없을 것이라고 판단해 보류했다.

프론트팀의 경우 현재 디자인 팀과 같이 디자인 시스템을 만들고 있는 중인데, 우선 디자인 시스템이 만들어지면 컴포넌트 기반으로 storybook을 만들 예정이다. 그리고 이게 잘 운영된다면 각 프로젝트별로 page까지 포함한 storybook이 개발 결과 산출물로 들어갈 것 같다.

그리고 SBOM의 경우 개발 결과 산출물로 꼭 필수적인데, 2021년 log4j 오픈소스에 대한 보안 문제로 SW 공급망 보안 관리를 위해 SBOM의 필요성이 최근 급부상했다. 기존에도 SBOM을 위해 CycloneDX를 이용해 만들고 있었지만 이번에 gitlab enterprise를 사용하기로 하면서 gitlab enterprise에서 지원해주는 SBOM 분석 기능을 이용해 만들기로 했다.

설계 결과 산출물의 기준을 세우는 것에 대해서는 각 파트장님들도 공감을 많이 해주시고 있어 빠르게 발표자료를 만들어 공유해 다음 스프린트부터 적용해보려고 한다.