2. 개발 품질 향상과 협업 체계 가이드라인: SW 개발산출물 거버넌스 사례

Q 트랙의 두 번째 발표를 맡아주신 황재성 님의 발표 내용을 정리해 보겠습니다 :)

QA의 역할 중 중요한 소통을 체계적으로 진행하기 위해 개발산출물 관리 부분에 대해 설명해 주시는 발표였습니다.
개발 산출물의 품질 관리도 QA의 영역이라는 것을 배울 수 있던 발표였습니다!

개인 블로그이기 때문에 주관적인 의견이 담겨있을 수 있습니다. 해당 포스팅은 컨퍼런스 참고용으로만 사용해 주세요
QA 컨퍼런스에 참여하시면 더 많은 자료를 보실 수 있으니, 다음 회차에서 직접 참여하시고 많은 정보를 받아가시는 것을 추천드립니다!

2025 QA 컨퍼런스 링크 : https://www.qa-korea.com/qaconference2025
컨퍼런스 전체 리뷰 : 2025 4th QA 코리아 '오프라인' 컨퍼런스 후기
2024 QA 컨퍼런스 황재성 님 발표 : 8. Intelligent Automation : 효율적인 Test를 위한 Test case priority

Q 트랙 두 번째 발표는 황재성 님이 발표해 주셨고, 개발 산출물에 대한 이야기를 중심적으로 발표해 주셨습니다.

QA의 핵심 역량인 소통을 더욱 체계적으로하여 협업 시 다르게 이해할 수 있는 부분을 최소화하기 위해 산출물을 근거로 협업하는 방식을 주제로 발표해 주셨고, 산출물의 품질도 챙기는 방안에 대해 설명해 주셨습니다.

 

개발 담당자와 품질 담당자는 주로 담당하는 영역과 관점이 다르기에 소통에서 차이가 있을 수 있고, 이런 소통의 차이를 좁히기 위해 QA 담당자는 코딩이나, 디자인 패턴 등 CS(Computer Science) 능력이 있다면 소통 능력이 더 향상될 수 있다고 알려주셨습니다.

 

 

개발 담당자와 품질 담당자는 주로 담당하는 영역과 관점이 다르기에 소통에서 차이가 있을 수 있고, 이런 소통의 차이를 좁히기 위해 QA 담당자는 코딩이나, 디자인 패턴 등 CS(Computer Science)능력이 있다면 소통 능력이 더 향상될 수 있다고 알려주셨습니다.

 

그리고 조직 간 소통을 진행할 때 구두나 다른 매체로 전달하는 경우에는 의사소통 차이가 있을 수 있으며, 위험 요소를 최소화하기 위해 근거 기반의 산출물로 소통하는 것을 권장하셨고, 근거 자료가 있어야 서로가 다르게 생각할 수 있는 부분들을 최소화할 수 있기 때문에 산출물의 중요성을 강조해 주셨습니다.

 

저는 타 팀에게 요청할 산출물이라고 생각해 본다면 API 개발 이력 문서나, 기획 요구사항문서 정도만 생각되었는데, 생각보다 많은 산출물을 기반으로 소통한다고 하셨습니다. 

 

그리고 조직 간 소통을 진행할 때 구두나 다른 매체로 전달하는 경우에는 의사소통 차이가 있을 수 있으며, 위험 요소를 최소화하기 위해 근거 기반의 산출물로 소통하는 것을 권장하셨고, 근거 자료가 있어야 서로가 다르게 생각할 수 있는 부분들을 최소화할 수 있기 때문에 산출물의 중요성을 강조해 주셨습니다.

 

저는 타 팀에게 요청할 산출물이라고 생각해 본다면 API 개발 이력 문서나, 기획 요구사항문서 정도만 생각되었는데, 개발 계획서나 코드, 단위 테스트, 정적분석 보고서 등 생각보다 많은 산출물을 기반으로 소통한다고 하셨습니다. 

 

 

LG 전자의 CTO 부문에서 활용하고 있는 소프트웨어 개발 산출물 거버넌스를 구축한 사례를 공유해 주시면서 사례 기반으로 설명해 주셨습니다.

 

사례를 설명하기 위해 많은 자료들을 추가해서 설명해 주셨는데, 개인 블로그에서 다루기엔 조심스러운 부분도 있어서 발표 때 기억나는 부분을 글로 옮겨보도록 하겠습니다.

 

우선 각 조직과 프로젝트 별로 수행하고 관리하는 프로세스와 산출물이 상이하기 때문에 공통의 기준을 수립하는 것이 가장 우선 과제였다고 알려주셨습니다.

 

선행 개발 프로세스의 기준이 있지만, 상황에 따라 이를 지키기 어려운 환경도 있기 때문에 여러 센터나 연구소에서 이것만큼은 공통적으로 지켜져야 한다! 하는 항목들을 선정하여 필수 활동 및 산출물을 정의하는 것을 선별하셨다고 하셨습니다.

 

SW 개발 진행 시 필수 산출물은 아래 목록으로 설명해 주셨습니다.

• 개발 계획서
• 요구사항 문서
• 설계 문서
• 코드
• 단위 테스트
• 요구사항 테스트
• 정적분석
• 보안 규정 준수
• 오픈 소스 규정 준수

이 항목들은 SW 개발 진행 시 필수 산출물로 정한 내용이며, 각 산출물마다 체크리스트를 제시하고 개발자의 자체 점검을 통해 검수된 산출물을 전달받을 수 있는 환경을 구성하셨다고 하셨습니다.

 

개발자의 자체 점검이 끝나면 거버넌스 3자 점검을 통해 산출물들의 성숙도 레벨을 측정하여 팀에게 제공하는 방식으로 수행된다고 알려주셨습니다.

 

 

거버넌스 점검을 통해 각 프로젝트의 산출물들은 어느 정도의 성숙도 레벨을 가지고 있는지 확인할 수 있으며, 각 조직에서 어떤 부분이 부족한 지 대시보드를 통해 확인할 수 있다고 하셨습니다.

 

레벨의 측정 방식은 산출물 체크리스트 기준으로 산출물의 내용이 적합하게 작성되었는지 확인하여 레벨이 높을수록 퀄리티가 높은 산출물을 제공하고 있는 것이라고 설명해 주셨습니다.

 

그리고 위의 대시보드를 행(가로)으로 보는 프로젝트 별 산출물 현황으로 보는 시각도 있지만, 열(세로)로 보는 기준도 중요하다고 알려주셨습니다. 

열 기준으로 확인해 보면 바쁜 개발 공수로 인해 전체적으로 테스트 부분인 단위테스트나 요구사항 테스트가 부족하다는 것을 알 수 있었고, 이를 개선할 수 있는 방법도 고민해보고 있다고 하셨습니다.

 

대시보드를 통해 프로젝트 별 성숙도 평가에 그치는 것이 아닌, 어떤 방식으로 부족한 부분을 개선할 수 있을지를 생각해 본다는 것이 인상 깊었습니다.

 

 

상세한 결과로 각 산출물이 어떤 기준으로 성숙도 평가를 받았는지 볼 수 있었으며, N(Not Achieved), P(Partially Achieved), L(Largely Achieved), F(Fully Achieved)로 구분하여 평가하고 있다고 설명해 주셨습니다.

 

각 프로젝트 조직에서는 대시보드를 확인하고 발생되는 산출물의 품질을 개선할 수 있도록 안내받을 수 있을 것 같았습니다.

 

하지만 산출물 관리라는 것도 시간이 들어가고 이는 곳 비용이기 때문에 이를 줄여보기 위해 최근에는 AI 기술을 도입하여 각 산출물의 초안을 LLM을 통해 만들 수 있도록 사내 시스템을 만들고 있다고 하셨습니다.

 

명확한 소통을 위해 체계적인 산출물 관리도 중요하지만 관리를 위해 들어가는 비용도 만만치 않을 것이기에, 이를 효율적으로 지킬 수 있는 방법을 연구하는 것도 인상 깊었습니다. 

 

---

 

사실 작년 발표를 통해 품질 개선이나 품질 지표 수립을 위해 많은 기여를 하고 계신 분이라는 것을 알고 있었고, 그 과정을 설명해 주시려다 보니 내용이 조금 어렵게 느껴졌었습니다. 

 

하지만 이번 발표는 최대한 쉽게 설명해 주시려는 느낌도 받았고, 두리뭉실한 내용보다 실제 사례를 근거로 설명해 주셔서 거버넌스를 구축한 이유를 보다 쉽게 알 수 있었습니다.

 

산출물 체크리스트를 만드는 과정도 궁금해지게 되었고, 어떤 방식으로 체크리스트에 맞게 작성되었는지 검증하는 방식도 궁금해지는 발표였습니다. 알면 알수록 깊이 빠져드는 품질의 세계랄까...?

 

근거 기반의 소통을 하기 위한 노력부터, 산출물 검증과 이 부분의 생산성을 높이기 위한 AI 기술 도입까지 많은 영역에서 고민한 흔적들이 많았던 발표였습니다. 

 

컨퍼런스에는 블로그에 추가하지 않은 발표 자료도 많고, 오프라인의 강점인 현장에서 즉흥적으로 질의를 하시는 분도 있었기 때문에 참여하지 못한 분들은 다음 컨퍼런스에 참여하셔서 직접 들어보시는 것을 강력 추천합니다 👍