28장: 구현 관리
28장: 구현 관리
- 구현 관리는 일반적인 프로젝트 관리 전체가 아니라, 좋은 코드를 지속적으로 만들기 위한 변경·일정·측정·사람의 관리에 집중함.
- 품질 목표와 프로젝트 규모에 따라 필요한 관리 방식의 무게가 달라짐.
28.1 좋은 코딩 장려
- 관리자가 세세한 기술 표준을 강제하면 반발과 형식적 준수가 생기기 쉬움.
- 관리자 대신 휼륭한 아키텍트의 역할
- 표준은 팀이 신뢰하는 기술 리더와 개발자가 함께 만들고, 필요하면 엄격한 규칙 대신 지침·제안·좋은 예시를 사용함.
- 좋은 코딩을 장려하는 실천 방법은 다음과 같음.
- 페어 프로그래밍, 멘토-멘티, 버디 리뷰처럼 두 사람이 코드를 함께 책임짐.
- 모든 코드를 리뷰하여 결함을 줄이고 팀이 자연스럽게 공통 기준을 만듦.
- 코드가 완료되기 전에 선임 기술자가 검토하고 서명하게 하여, 기술적으로 타당하고 결함이 없다는 책임을 분명히 함.
- 좋은 코드 사례를 검토 대상으로 회람하거나 공유하여, 추상적인 규칙보다 목표 품질을 구체적으로 보여 줌.
- 코드는 개인 소유물이 아니라 프로젝트의 공용 자산으로 보고 누구나 읽고 유지보수할 수 있게 만듦.
- 기술적으로 뛰어난 코드를 인정하고 보상함. 판단 역량이 없다면 팀의 평가를 따르는 편이 나음.
- 쉬운 표준: 프로그래밍 배경이 있는 관리자는 “프로젝트의 어떤 코드라도 읽고 이해할 수 있어야 한다”는 기준을 제시해, 지나치게 기교를 부린 난해한 코드를 억제할 수 있음.
이 책의 역할
- 이 책은 경직된 코딩 표준이나 규칙집이 아니라, 팀이 좋은 프로그래밍 실천법을 논의하고 각 환경에 맞는 방식을 고르는 참고 자료로 사용함.
28.2 형상 관리
- 형상 관리는 소스 코드뿐 아니라 요구사항·설계·테스트·빌드 환경의 변경을 통제하고, 특정 시점의 제품을 재현·복구할 수 있게 하는 활동임.
- 절차가 개발을 방해하지 않도록 프로젝트 규모에 맞는 수준으로 운영함.
요구사항과 설계 변경
체계적인 변경 통제 절차를 따름
- 변경 요청을 정해진 절차로 받고, 개별 요청이 아니라 프로젝트 전체에 가장 이로운 선택인지 판단함.
변경 요청을 묶어서 처리함
- 쉬운 변경이라고 떠오르는 즉시 구현하지 말고 모두 기록해 둔 뒤, 그룹으로 묶고 비교하여 효과가 큰 변경을 선택함.
변경마다 비용을 추정함
- 구현 시간뿐 아니라 요구사항·설계·코드·테스트·사용자 문서까지 이어지는 파급 효과를 포함해 비용·일정·품질 영향을 추정함.
변경량이 많아지는 것을 경계함
- 큰 변경이 반복된다면 구현 문제가 아니라 요구사항, 아키텍처, 상위 수준 설계가 충분하지 않다는 신호일 수 있음.
- 필요한 경우 구현을 계속 반복하기보다 요구사항이나 아키텍처 작업으로 되돌아감.
변경 통제 위원회 또는 그에 준하는 역할을 둠
- 기능 추가, 기능 변경, 오류 보고 등 모든 변경 요청을 검토해 승인·보류·거절할 책임자를 정함.
- 프로젝트 규모에 따라 위원회, 제품 기획 그룹, 담당자 한 명 등 가벼운 형태로 운영할 수 있음.
관료주의는 경계하되 변경 통제를 포기하지 않음
- 절차는 간소화하되, 기록되지 않은 변경이 쌓여 일정·위험·진척 파악을 흐리지 않도록 함.
- 변경 통제의 이름과 형식보다 실제로 변경을 검토하고 결정하는 기능이 중요함.
소프트웨어 코드 변경
- 현재 기준으로는 Git 같은 버전 관리 도구를 사용해, 변경 뒤 생긴 결함을 이전 버전과 비교하며 추적함.
- 버전관리 소프트웨어는 한 사람이 파일을 수정하는 동안 잠그거나, 여러 사람의 변경을 병합하는 방식으로 동시 작업의 충돌을 조정함.
- 변경 이유를 남기고 최신 파일을 동기화하며, 필요하면 모든 과거 버전의 차이를 확인하거나 정상 버전으로 되돌릴 수 있어야 함.
- 팀 프로젝트에서는 사실상 필수이며, 결함 추적·변경 관리와 연결하면 변경의 맥락을 더 쉽게 추적할 수 있음.
도구 버전
- 특정 버전의 소프트웨어를 재현해야 한다면 컴파일러, 링커, 라이브러리, 빌드 도구도 함께 버전 관리함.
하드웨어 구성
- 개발 장비의 도구와 설정을 표준화하여 개인별 환경 차이에서 생기는 문제를 줄임.
- 표준 구성은 새 장비 준비도 빠르게 만듦.
백업 계획
- 소스뿐 아니라 문서, 그래픽, 메모 등 모든 프로젝트 자료를 주기적으로 백업하고 외부 저장소에도 보관함.
- 실제 복구 절차를 시험해 백업에 필요한 자료가 모두 들어 있고 복구 가능한지 확인함.
- 프로젝트가 끝나면 소스, 도구, 요구사항, 설계, 문서를 포함한 보관본을 만들어 제품을 재현할 수 있게 함.
형상 관리 체크리스트는 책 722쪽에서 확인.
28.3 구현 일정 추정
예측 방법
- 프로젝트 규모와 완료에 필요한 노력을 예측하는 방법에는 추정 도구·모델, 외부 전문가, 워크스루 회의, 작업별 합산, 과거 프로젝트 자료 등이 있음.
- 초기 예측은 본질적으로 부정확하므로, 실제 결과를 반영하며 점차 범위를 좁히는 활동으로 다룸.
목표 설정
- 무엇을, 왜 예측하는지 먼저 정함. 구현만인지 전체 개발인지, 휴가·교육 등 비프로젝트 시간도 포함하는지, 필요한 정확도와 확신 수준은 어느 정도인지 확인함.
예측을 위한 시간 확보와 계획
- 성급한 예측은 부정확함. 큰 프로젝트라면 예측 자체를 작은 프로젝트처럼 계획하고 필요한 시간을 배정함.
소프트웨어 요구사항 구체화
- 정의되지 않은 소프트웨어의 작업량을 신뢰성 있게 예측할 수 없음.
- 요구사항을 구체화하거나, 예측 전에 탐색 단계를 계획함.
낮은 수준의 세부 사항으로 예측
- 프로젝트 활동을 가능한 작은 단위로 나누어 예측함.
- 큰 작업 하나의 오차보다 작은 작업 여러 개의 오차가 서로 상쇄될 가능성이 커 정확도가 높아짐.
여러 예측 기법 사용과 결과 비교
- 작업별 합산, 담당자 추정, 과거 자료, COCOMO II 같은 산식 기반 추정 등 여러 방법을 함께 사용해 결과 차이를 검토함.
- 방법마다 다른 결과가 나오는 이유를 살피면 놓친 가정과 위험을 발견할 수 있음.
주기적인 재예측
- 실제 진척과 초기 예측을 비교하고, 새로 얻은 정보를 반영해 남은 작업의 예측을 갱신함.
구현 작업량 예측
- 구현은 상세 설계, 코딩·디버깅, 단위 테스트를 포함함.
- 전체 개발에서 구현이 차지하는 비율은 프로젝트와 조직 규모에 따라 달라지므로, 자체 프로젝트 이력을 쌓아 다음 예측에 사용함.
일정에 영향을 주는 요인
- 프로그램 규모가 가장 큰 영향 요인이지만, 제품 복잡도, 신뢰성 요구, 요구사항 변동성, 인력 역량과 이직률, 팀 응집도, 도구·기술 경험, 고객·사용자 참여, 문서화 수준도 일정을 크게 바꿈.
- 예측은 코드 크기만으로 계산하지 않고 이러한 조건을 함께 고려해야 함.
예측과 통제
- 납기와 제품 범위가 정해진 뒤에는 초기 예측의 정확성보다, 사람과 기술 자원을 통제해 목표를 달성하는 일이 더 중요함.
일정이 늦어질 때
나중에 따라잡을 것이라는 낙관적 기대
- 일정이 늦어진 이후 다음 단계인 구현·테스트에서 자연스럽게 만회할 수 있다고 기대하는 것은 흔한 반응임.
- 하지만 여러 프로젝트 자료에서 일정이 밀리기는 보통 후반으로 갈수록 커졌으므로, 근거 없는 낙관은 대응책이 될 수 없음.
팀 확대
- 늦은 프로젝트에 인력을 추가하면 새 인력의 학습과 기존 인력의 교육·의사소통 비용 때문에 더 늦어질 수 있음.
- 다만 작업을 독립적으로 나눌 수 있다면 늦은 시점의 인력 추가도 도움이 될 수 있음.
프로젝트 범위 축소
- 기능 하나를 제외하면 그 기능의 설계·구현·테스트·문서화와 다른 기능과의 인터페이스 작업도 함께 줄어듦.
- 처음부터 기능을 필수, 있으면 좋은 것, 선택 사항으로 나누고 지연되면 중요도가 낮은 기능부터 제외하거나 더 저렴한 수준으로 제공함.
28.4 측정
측정의 필요성
어떤 프로젝트 속성이든 측정하지 않는 것보다 나은 방식으로 측정할 수 있음
- 측정값이 완벽하지 않고 시간이 지나며 개선되어야 하더라도, 측정이 있어야 개발 과정을 관찰하고 개선할 수 있음.
- 개발 방법의 효과를 판단할 때는 ‘더 생산적인 것 같다’가 아니라 수량화한 근거가 필요함.
측정에 반대하는 것은 프로젝트에서 실제로 일어나는 일을 알지 못하는 편을 택하는 것임
- 결함 수, 수정 시간, 비용처럼 측정 대상으로 정한 항목이 증가·감소·유지되는지 볼 수 있음.
- 측정이 불완전하다는 이유로 포기하지 말고, 목적에 맞게 점차 개선함.
측정의 부작용
측정의 부작용에 유의함
- 사람은 평가에 쓰인다고 생각하는 측정값에 집중하고, 측정하지 않는 일은 소홀히 하기 쉬움.
- 따라서 지표는 개인을 줄 세우는 채찍이 아니라, 질문에 답하고 프로세스를 개선하는 관찰 도구로 사용함.
측정 항목
- 책 원문은 크기, 전체 품질, 결함 추적, 유지보수성, 생산성의 다섯 범주를 제시함.
- 이 지표들은 개별 루틴을 미세하게 순위 매기기보다, 복잡도나 변경 빈도가 유난히 높은 이상치(outlier)를 찾아 추가 검토하는 데 유용함.
측정 시작 방식
- 처음부터 모든 지표를 수집하지 말고, 결함 수·작업 시간·총비용·코드 규모처럼 단순한 지표부터 시작함.
- 프로젝트마다 같은 정의로 측정하고, 이해가 쌓이면 지표를 다듬고 추가함.
- 목표를 정하고, 목표 달성에 필요한 질문을 고른 뒤, 그 질문에 답하는 데 필요한 정보만 수집함.
28.5 프로그래머를 사람으로 대하기
프로그래머는 시간을 어떻게 쓰는가?
- 프로그래머의 시간은 코딩만으로 이루어지지 않으며, 읽기·기록·회의·교육·대화·생각과 비기술적 활동에도 쓰임.
- 오래된 시간 연구의 세부 비율을 일반화할 수는 없지만, 관리자는 코딩 시간만으로 개인의 생산성을 판단하지 않아야 함.
성과와 품질의 차이
개인 차이
- 프로그래머 사이에는 품질, 구현 속도, 디버깅 시간에서 큰 차이가 나타남.
- 경력 연수만으로 생산성이나 코드 품질을 예측할 수 없으므로, 역량을 단일 지표로 판단하지 않음.
팀 차이
- 팀 사이에도 품질과 생산성 차이가 크며, 좋은 개발자는 서로 모이는 경향이 있음.
- 채용과 인력 유지에 투자하면 새 인력의 효과뿐 아니라 팀 전체의 역량과 유지에도 영향을 줌.
종교적 쟁점
- 신앙적인 문제
- 프로그래밍 언어, 들여쓰기, 중괄호, IDE, 주석, 명명 규칙, 방법론, 전역 변수, 생산성 지표처럼 개인 취향이 강한 문제는 종교 논쟁이 되기 쉬움.
민감한 문제임을 인식함
- 강제하기 전에 팀의 입장과 갈등 가능성을 먼저 파악함.
규칙보다 제안과 지침을 사용함
- 품질에 직접 영향을 주지 않는 취향 문제는 강제 규칙으로 정하지 말고, 제안과 지침 수준으로 다룸.
분명한 지시 대신 도구와 리뷰를 사용함
- 들여쓰기와 중괄호는 formatter로 통일하고, 주석과 가독성은 코드 리뷰에서 확인해 불필요한 논쟁을 줄임.
개발자가 자신의 표준을 만들게 함
- 관리자가 세부 규칙을 정하기보다, 팀이 중요한 영역의 표준을 직접 합의하도록 함.
- 전역 변수의 무분별한 사용이나 읽기 어려운 코드처럼 프로젝트 전체 품질을 해치는 문제에는 필요한 마찰을 감수하고 개입함.
물리적 환경
- 조용함, 사생활, 충분한 공간, 전화·사람의 방해를 줄일 수 있는 환경은 생산성과 강한 관련이 있음.
- 작업 환경에 투자하는 일은 복지가 아니라 집중과 품질을 높이기 위한 관리 활동임.
28.6 관리자 관리
관리자(상사) 관리의 의미
- 기술적으로 최신이 아닌 관리자와 일할 때는, 개발자가 필요한 선택과 정보를 관리자가 이해하고 결정할 수 있는 방식으로 제시해야 함.
대응 방법
원하는 방향을 제안하고 관리자가 받아들일 여지를 둠
- 하고 싶은 일을 먼저 제안하되, 관리자가 그 방향을 자신의 판단으로 받아들이도록 기다릴 수 있음.
관리자를 지속적으로 교육함
- 더 나은 개발 방식과 그 이유를 설명함. 관리자는 이동·승진·교체될 수 있으므로 일회성 설명이 아니라 지속적인 소통이 필요함.
관리자의 관심사에 맞춰 설명함
- 불필요한 구현 세부사항을 모두 쏟아내기보다, 관리자가 실제로 중요하게 보는 위험·일정·비용·결과에 연결해 설명함.
- 자신의 일을 적절히 캡슐화해 필요한 수준의 정보만 전달함.
지시를 거부하고 올바른 방식을 고집함
- 품질이나 직업적 책임을 해치는 지시라면, 마찰을 감수하고 다른 방식을 주장해야 할 수 있음.
다른 일을 찾음
- 개선 가능성이 없고 핵심 원칙을 지킬 수 없다면, 이직도 선택지임.
장기적인 해법
- 가장 지속 가능한 방법은 신뢰를 바탕으로 관리자를 교육하는 것임.