개발 단계에서 진짜로 관리되는 것

한 줄 요약

SI 개발 단계에서 실제로 관리되는 것은 코드 품질이 아니라 표준·형상·진척 세 가지이며, 이유는 이 시스템을 만든 사람이 2 년 뒤에는 없기 때문이다.

왜 표준이 먼저인가

개발자가 20 명이면 스타일이 20 가지 나온다. 각각은 다 나름대로 합리적이지만, 3 년 뒤 유지보수하는 사람은 그 20 가지를 전부 읽어야 한다. SI 시스템의 수명은 보통 7~10 년이고 만든 사람은 대개 2 년 안에 없으므로, 읽는 사람의 시간이 쓰는 사람의 취향보다 훨씬 비싸다.

그래서 표준은 좋은 코드를 만들기 위한 것이 아니라 예측 가능한 코드를 만들기 위한 것이다. 어떤 파일을 열어도 같은 자리에 같은 것이 있으면, 처음 보는 모듈도 30 분이면 고칠 수 있다.

개발 표준이 먼저 온다

SI 프로젝트의 개발 첫 주는 코딩이 아니라 개발 표준 정의서를 읽는 것으로 시작한다.
패키지 구조, 클래스 명명 규칙, 로그 레벨 사용 기준, 예외 처리 방식, 공통 코드 사용법,
쿼리 작성 규칙(동적 쿼리 허용 범위, 힌트 사용 여부)이 거기 적혀 있다.

이유는 단순하다. 개발자가 20명이면 20가지 스타일이 나오고, 3년 뒤 유지보수하는
사람은 그 20가지를 전부 읽어야 한다. SI 시스템의 수명은 보통 7~10년이고,
만든 사람은 대개 2년 안에 없다.

공공 사업이면 여기에 전자정부 표준프레임워크가 얹힌다. 스프링 기반이고,
공통 컴포넌트(로그인, 파일 업로드, 게시판, 코드 관리)를 제공한다.
버전과 JDK 조합이 사업 공고에 명시되므로, "더 최신 버전이 좋은데요"는 통하지 않는다.

형상관리 — 브랜치보다 '태그와 릴리스 노트'

요즘은 SI 도 Git 을 쓴다. 하지만 오픈소스 프로젝트식 브랜치 전략을 그대로 쓰면
잘 안 맞는다. 이유는 배포 단위가 '기능'이 아니라 '차수' 이기 때문이다.

• 1차 오픈: 회원/주문
• 2차 오픈: 정산/통계
• 안정화 패치: 매주 목요일 야간

그래서 실제로 중요한 건 세 가지다.

1. 배포된 것과 소스가 일치하는가 — 태그 없이 배포하면 3개월 뒤 롤백할 대상을 못 찾는다.
2. 누가 언제 무엇을 왜 바꿨는가 — 커밋 메시지에 요구사항 ID 나 결함 ID 를 넣는 이유다.
fix bug 이라는 커밋 메시지는 유지보수 담당자에게 아무 정보도 주지 않는다.
3. 운영 반영 이력 — 소스 이력과 별개로 "언제 어떤 버전을 운영에 올렸는가"의 대장이 필요하다.

폐쇄망 프로젝트라면 외부 GitHub 이 안 되므로 사내 GitLab 이나, 심하면
파일 서버 + zip 이 형상관리다. 그런 환경에서도 태그 = 배포 산출물 스냅샷이라는
원칙만 지키면 최악은 면한다.

단위테스트 — SI 에서 이 단어의 실제 의미

용어를 정확히 알아야 한다. 학교에서 배운 단위테스트(JUnit)와 SI 산출물로서의
'단위테스트'는 겹치지만 같지 않다.

| 구분 | 대상 | 산출물 | 누가 |
| --- | --- | --- | --- |
| 단위테스트(UT) | 프로그램/화면 1개 | 단위테스트 시나리오·결과서 | 개발자 본인 |
| 통합테스트(IT) | 업무 흐름, 시스템 간 연동 | 통합테스트 시나리오·결함관리대장 | QA/PL, 양쪽 시스템 |
| 인수테스트(UAT) | 고객 업무 시나리오 | 인수테스트 결과서, 검수확인서 | 고객 현업 |

SI 의 단위테스트 결과서는 보통 이런 표다.

TC-207 | 주문 조회 - 정상 | 조건: 고객ID=C001, 기간=2026-01~2026-06       | 기대: 12건 조회, 응답 3초 이내       | 결과: 12건, 1.8초 | 판정: Pass | 시험일: 2026-08-11 | 시험자: 김영주

중요한 건 '예외 케이스가 몇 개인가' 다. 정상 케이스만 있는 단위테스트 결과서는
검토에서 반려하는 게 맞다. 최소한 이건 있어야 한다.

• 필수값 누락
• 길이 초과 / 타입 불일치
• 권한 없는 사용자
• 조회 결과 0건
• 동시 수정(낙관적 락 충돌)

코드 리뷰와 정적 분석

대형 사업에는 보통 품질 항목이 계약에 들어 있다. 정적 분석 도구(SonarQube 등)로
치명적 결함 0건, 보안 취약점 0건 같은 목표치가 잡힌다.

여기서 신입이 자주 겪는 일: 마감 직전에 정적 분석을 처음 돌렸더니 2,000건이 나온다.
초반부터 매일 돌려야 한다. 규칙은 프로젝트 시작 때 팀이 합의해서 잠그고,
그 이후 새로 생긴 위반만 막는 방식(신규 코드 기준)이 현실적이다.

진척률의 정직함

주간 보고에 쓰는 진척률은 대개 '완료 프로그램 수 / 전체 프로그램 수'다.
그래서 프로그램목록이 정확해야 진척률이 의미를 갖는다.

그리고 한 가지 규칙: 단위테스트 결과서가 없으면 완료가 아니다.
"코딩은 다 됐고 테스트만 남았어요"가 쌓이면 마지막 2주에 전 인원이
테스트 결과서를 소급 작성하게 된다. 그 문서에 무슨 가치가 있는지는
누구나 알지만 아무도 말하지 않는다.

현장에서 만나는 모습

진척률 보고가 이 단계에서 가장 자주 왜곡된다. "80% 완료" 라는 보고가 몇 주째 80% 에 머무는 것이 전형적인 신호다.

원인은 대개 셀 단위가 없어서다. 프로그램목록이 있으면 진척은 "전체 118 개 중 92 개 단위테스트 통과" 처럼 셀 수 있는 숫자가 되지만, 목록이 없으면 각자의 체감을 평균 내게 된다. 그리고 체감은 늘 90% 근처에서 멈춘다.

형상관리도 같은 이유로 어긋난다. 브랜치 전략을 아무리 잘 짜도 배포 단위가 '차수' 인 프로젝트에서는 무엇이 언제 나갔는지가 더 중요하다. 태그와 릴리스 노트가 없으면, 장애 때 "지금 운영에 올라가 있는 게 어느 시점 코드인가" 를 아무도 확답하지 못한다.