18. PSP (Personal Software Process) / TSP (Team Software Process)

핵심 인사이트 (3줄 요약)

  1. 본질: PSP와 TSP는 개발자 개인의 작업 습관을 정량적으로 측정하고 개선하여(PSP), 이를 기반으로 자율적인 고성과 팀을 구축하는(TSP) 상향식(Bottom-up) 프로세스 개선 프레임워크다.
  2. 가치: 조직 차원의 거시적 관리(CMMI)가 놓치기 쉬운 '엔지니어 개인의 코드 품질과 일정 예측력'을 통계적으로 극대화하여 결함 주입을 원천 차단한다.
  3. 융합: 현대 개발 환경에서는 PSP의 엄격한 측정 지표(Metrics)를 자동화 도구(IDE Plugin, SonarQube)로 대체하고, TSP의 팀 관리 방식을 애자일(Scrum)과 결합한 'TSP+Agile' 형태로 융합하여 사용한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

소프트웨어 품질의 궁극적인 원천은 결국 코드를 직접 작성하는 '개발자 개인'이다. CMMI와 같은 하향식(Top-down) 프로세스 모델은 조직 차원의 표준(OSP)을 제시하지만, 정작 책상에 앉아 코드를 짜는 엔지니어에게 "어떻게 결함을 줄이고 일정을 지킬 것인가?"에 대한 구체적인 개인 단위의 지침은 주지 못했다. 그 결과, 조직은 CMMI 고레벨 인증을 받았음에도 불구하고 개별 개발자의 나쁜 코딩 습관이나 비현실적인 일정 추정으로 인해 프로젝트가 무너지는 역설적 상황에 직면했다.

이러한 한계를 극복하기 위해 SEI의 와츠 험프리(Watts Humphrey)는 PSP (Personal Software Process)와 TSP (Team Software Process)를 고안했다. PSP는 개발자가 자신의 작업 시간과 결함 데이터를 기록하여 스스로를 관리하게 만들고, TSP는 이렇게 훈련된 PSP 엔지니어들이 모여 스스로 계획을 수립하고 통제하는 자기 조직화(Self-organizing) 팀을 만드는 것이 목적이다.

이 도식은 기존의 하향식 통제 구조가 가진 한계와 PSP/TSP를 통한 상향식 품질 확보 구조의 차이를 보여준다.

┌───────────────── 하향식 통제(CMMI) vs 상향식 품질(PSP/TSP) ─────────────────┐
│                                                                           │
│ [하향식: CMMI 중심]                     [상향식: PSP/TSP 결합]            │
│  조직(CMMI) ──(지시)──▶                 조직(CMMI) ◀──(품질 보장)──       │
│        ▼                                       ▲                          │
│  팀 리더 ──(일정 압박)──▶              팀(TSP) : 자율적 계획 및 협업     │
│        ▼                                       ▲                          │
│  개발자 : 방어적 코딩, 결함 양산          개인(PSP) : 정량적 데이터 기반  │
│           (원인: 개인 프로세스 부재)                  일정/결함 자기 통제 │
└───────────────────────────────────────────────────────────────────────────┘

이 그림의 핵심은 전통적인 환경에서는 조직의 목표가 개발자에게 단순한 '압박'으로 작용하여 오히려 품질 저하를 유발한다는 점이다. 반면 PSP/TSP 환경에서는 개발자 개인이 자신의 생산성(LOC/Hour)과 결함률 데이터를 정확히 알고 있기 때문에, 무리한 일정을 거부하고 실현 가능한 계획(TSP)을 수립하여 조직(CMMI)의 목표를 안정적으로 받쳐주는 견고한 기반이 된다.

📢 섹션 요약 비유: CMMI가 오케스트라 전체를 조율하는 '지휘자의 악보'라면, PSP는 바이올리니스트 개인이 매일 연습량을 기록하고 음정을 교정하는 '개인 연습장'이며, TSP는 파트별 연주자들이 모여 호흡을 맞추는 '실내악 앙상블'과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

PSP는 개발자가 0단계부터 3단계까지 점진적으로 자신의 프로세스를 고도화하는 구조를 가진다. 각 단계를 거치며 직관에 의존하던 코딩이 통계적 엔지니어링으로 변화한다.

PSP 레벨명칭내부 동작 및 목표핵심 산출물 / 척도
PSP 0기본 (Baseline)현재 작업 방식의 기록 및 측정 시작시간/결함 기록 로그, 코딩 표준
PSP 1계획 (Planning)과거 데이터 기반으로 규모(Size) 및 일정 추정PROBE(Proxy Based Estimation) 기법
PSP 2품질 (Quality)설계/코드 리뷰 도입으로 컴파일 전 결함 조기 발견설계/코드 리뷰 체크리스트
PSP 3사이클 (Cyclic)대규모 프로그램을 작은 단위로 분할하여 반복 개발점진적 개발 파이프라인

아래의 계층 구조도는 PSP의 각 레벨이 어떻게 누적되어 개발자의 개인 역량을 완성하는지를 보여준다.

┌───────────────── PSP (Personal Software Process) 계층 구조도 ─────────────────┐
│                                                                             │
│ [PSP 3: Cyclic Personal Process] ──▶ 대규모 모듈의 반복/점진적 개발 설계  │
│            ▲                                                                │
│ [PSP 2: Personal Quality Mgmt] ────▶ 개인 리뷰, 결함의 조기 식별 및 제거  │
│            ▲                                                                │
│ [PSP 1: Personal Planning Process] ─▶ 과거 Data 기반 일정/규모(Size) 추정  │
│            ▲                                                                │
│ [PSP 0: Baseline Personal Process] ─▶ 작업 시간(Time)과 결함(Defect) 기록  │
└─────────────────────────────────────────────────────────────────────────────┘

이 구조도의 핵심은 '측정 없이는 개선도 없다'는 사상이다. PSP 0에서 개발자는 자신이 어떤 유형의 에러(Syntax, Logic 등)를 주로 내는지, 100라인(LOC)을 짜는 데 몇 시간이 걸리는지 기록한다. 이를 바탕으로 PSP 1에서 다음 작업의 규모를 예측(PROBE 기법)하고, PSP 2에서는 컴파일러에 의존하기 전에 스스로 코드를 리뷰하여 결함 제거 비용을 최소화한다.

PSP로 무장한 개발자들이 모이면 TSP 사이클을 시작한다. TSP는 팀 구성(Launch) -> 전략 수립 -> 계획 -> 실행(Execution) -> 사후 분석(Postmortem)의 사이클로 돌아간다.

┌─────────────────────── TSP (Team Software Process) 사이클 ──────────────────────┐
│                                                                                 │
│ [ 1. 런칭 (Launch) ] : 비즈니스 목표 이해, 역할(계획, 품질, 개발 등) 할당     │
│          ↓                                                                      │
│ [ 2. 계획 (Plan) ]   : 전체 전략 수립, 개인 PSP 데이터를 합산하여 WBS 도출    │
│          ↓                                                                      │
│ [ 3. 실행 (Execute) ]: 주간 회의(Weekly), 개별 PSP 데이터로 진척/품질 모니터링│
│          ↓                                                                      │
│ [ 4. 종료 (Wrap-up) ]: 사후 분석(Postmortem), 팀 프로세스 및 지식 자산(OPA)   │
│                        업데이트 후 다음 사이클 반복                             │
└─────────────────────────────────────────────────────────────────────────────────┘

이 흐름도의 특징은 매니저가 일정을 하달하는 것이 아니라, 팀원들이 각자의 PSP 데이터를 바탕으로 "나는 이번 주에 500LOC를 짜고 5개의 버그를 잡을 수 있다"라고 직접 계획을 수립(Bottom-up Planning)한다는 점이다. 이로 인해 일정에 대한 책임감이 극대화되고 정확도가 비약적으로 상승한다.

📢 섹션 요약 비유: 다이어트를 할 때 매일 먹은 식단과 몸무게를 기록하여 내 몸의 패턴을 아는 것(PSP)이 먼저이고, 이 데이터를 바탕으로 트레이너와 상의하여 실현 가능한 운동 계획을 짜는 것(TSP)이 그 다음 단계인 것과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

현대 소프트웨어 공학에서 PSP/TSP는 애자일의 대표 주자인 스크럼(Scrum)과 자주 비교되거나 융합된다. 두 방법론 모두 '자기 조직화 팀'을 지향하지만, 접근 방식은 대조적이다.

비교 항목PSP/TSP (엔지니어링 중심)애자일 Scrum (가치/속도 중심)실무 판단 포인트
계획의 근거철저한 과거 정량적 데이터 (PSP Metrics)상대적 추정 (Story Point, Planning Poker)정밀한 일정 예측 vs 빠른 우선순위 변경
품질 관리개발자 개인의 체크리스트 및 코드 리뷰 강제TDD, CI/CD를 통한 자동화된 테스트 의존TSP는 컴파일 전 결함 제거를 선호함
팀의 동인정량적 통제와 측정에 의한 자율성투명한 소통(Daily Scrum)과 데모를 통한 피드백
오버헤드측정 및 기록을 위한 시간적/심리적 저항 큼상대적으로 가벼운 프레임워크결합 시(TSP+Agile) 시너지 발생 가능

다음은 CMMI, TSP, PSP의 상호 보완적 아키텍처를 보여주는 계층 매트릭스이다.

┌──────────────── CMMI, TSP, PSP 3단계 융합 프레임워크 ────────────────┐
│                                                                      │
│ [ CMMI (Macro) ] : 조직(Organization) 수준의 프로세스 능력 및 인프라 │
│       ▲ ▽         - 경영진의 목표, 전사 품질 보증, OPA 제공         │
│       │ │                                                            │
│ [ TSP (Micro)  ] : 프로젝트 팀(Team) 수준의 관리 및 실행             │
│       ▲ ▽         - 리더십, 팀워크, 자체 계획 수립 및 통제          │
│       │ │                                                            │
│ [ PSP (Atomic) ] : 개인(Individual) 수준의 기술 및 규율              │
│                    - 정량적 추정, 철저한 개인 코드 리뷰, 결함 데이터 │
└──────────────────────────────────────────────────────────────────────┘

이 매트릭스의 핵심은 세 가지 프레임워크가 배타적인 것이 아니라 완벽한 보완 관계라는 것이다. CMMI가 하드웨어 인프라라면, TSP는 운영체제(OS)이고, PSP는 그 위에서 도는 애플리케이션(App)과 같다. 아무리 CMMI Level 5 조직이라도 내부 엔지니어들이 PSP 역량을 갖추지 못했다면 그 성숙도는 서류상의 허상에 불과하다.

📢 섹션 요약 비유: 애자일이 "어떤 방향으로 달릴지"를 민첩하게 결정하는 '네비게이션'이라면, PSP/TSP는 엔진의 상태를 모니터링하고 고장 없이 달리게 해주는 '차량의 계기판과 정비 매뉴얼'입니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무에서 원시적인 PSP를 그대로 도입하려고 하면 100% 실패한다. 개발자들에게 모든 결함 하나하나와 컴파일 횟수를 스톱워치로 재고 엑셀에 기록하라고 강제하면 엄청난 저항(Overhead)에 직면하기 때문이다.

1. 실무 시나리오: 도구 자동화를 통한 PSP의 현대적 적용

  • 상황: 팀의 버그 발생률이 높아 PSP 도입을 검토했으나, 개발자들이 측정(Metrics)을 위한 행정 업무에 반발하며 도입을 거부함.
  • 의사결정: 수기 기록 방식을 폐기하고, 개발자의 IDE(VS Code, IntelliJ)에 플러그인(WakaTime 등)을 설치하여 코딩 시간과 디버깅 시간을 자동 측정한다. 또한 SonarQube와 같은 정적 분석 도구를 CI 파이프라인에 연동하여 개인별 결함 밀도와 코드 스멜(Code Smell)을 자동으로 수집한다.
  • 판단: PSP의 본질은 '기록 행위' 자체가 아니라 '자신의 데이터를 인지하는 것'이다. 자동화 도구를 통해 측정 오버헤드를 제로(0)로 만들면서도, 개발자가 자신의 대시보드를 보고 스스로 개선점(PSP 2)을 찾도록 유도해야 한다.

다음은 현대적 환경에서 'TSP+Agile' 융합 모델이 어떻게 동작하는지를 보여주는 운영 플로우이다.

┌───────────────── TSP + Agile(Scrum) 융합 운영 플로우 ─────────────────┐
│                                                                       │
│ [Sprint Planning]                                                     │
│  - Agile : 비즈니스 우선순위 기반 User Story 선택                     │
│  - TSP   : 개인별 PSP 데이터(시간/생산성)를 합산하여 수용 범위 결정   │
│        ↓                                                              │
│ [Sprint Execution]                                                    │
│  - Agile : Daily Scrum으로 장애물 공유 및 소통                        │
│  - TSP   : 컴파일 전 코드 리뷰(PSP 2) 강제로 내재적 결함 사전 제거    │
│        ↓                                                              │
│ [Sprint Retrospective]                                                │
│  - Agile : "무엇이 좋았고 나빴는가?" 정성적 회고                      │
│  - TSP   : "결함 주입률이 10% 증가했다, 원인은?" 정량적/원인 분석     │
└───────────────────────────────────────────────────────────────────────┘

이 흐름도의 핵심은 애자일의 가벼움이 놓치기 쉬운 '정량적 엄밀함'을 TSP가 보완해 준다는 점이다. 실무에서 애자일 팀은 스토리 포인트를 주먹구구식으로 산정하여 스프린트 목표를 자주 실패하는데, PSP/TSP 데이터를 결합하면 팀의 진정한 벨로시티(Velocity)를 수학적으로 증명해낼 수 있다.

📢 섹션 요약 비유: 수기로 가계부를 쓰던 시절(고전적 PSP)에서 벗어나, 이제는 카드 앱과 은행 앱이 자동으로 지출 내역을 분류하고 통계(자동화된 측정)를 내어주면, 우리는 그 데이터를 보고 과소비를 줄이는 결단(품질 개선)만 내리면 되는 것과 같습니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

PSP와 TSP를 성공적으로 정착시킨 조직은, 단순히 개발 속도가 빨라지는 것을 넘어 개발의 '예측 가능성'과 '결함 없는 코드'라는 두 마리 토끼를 잡게 된다.

도입 전후정성적 효과정량적 효과
도입 전테스트 단계에서 대량의 버그 발견, 무한 디버깅일정 초과율 30~50%, 테스트 비용 막대
도입 후코딩 단계에서 자기 리뷰로 결함 사전 차단컴파일/테스트 시간 50% 단축, 일정 오차 5% 이내

미래의 소프트웨어 엔지니어링에서는 AI 어시스턴트(GitHub Copilot 등)가 도입되면서 개발자의 생산성(LOC)이 폭발적으로 증가하고 있다. 이러한 환경일수록 AI가 생성한 코드의 결함을 개발자 스스로 인지하고 리뷰하는 PSP 2(Personal Quality)의 철학이 더욱 중요해진다. 결론적으로 PSP와 TSP는 도구나 양식에 얽매이는 것이 아니라, "나 자신의 엔지니어링 데이터를 측정하고, 동료들과 투명하게 공유하며 자율적으로 목표를 달성한다"는 프로페셔널 소프트웨어 엔지니어의 핵심 정신(Mindset)으로 영구히 자리 잡을 것이다.

📢 섹션 요약 비유: 좋은 골프 채(최신 프레임워크)를 쥐어주었다고 타이거 우즈가 되는 것이 아니라, 자신의 스윙 궤적을 끊임없이 분석하고 교정하는 뼈를 깎는 개인 훈련(PSP/TSP)이 있어야만 진정한 프로가 되는 원리입니다.

📌 관련 개념 맵 (Knowledge Graph)

  • CMMI (Capability Maturity Model Integration) : PSP/TSP가 개인/팀에 집중한다면, 조직 전체의 프로세스 성숙도를 다루는 상위 프레임워크.
  • PROBE (Proxy Based Estimation) : PSP에서 소프트웨어 규모(Size)와 개발 시간을 추정하기 위해 과거의 유사한 작업(Proxy) 데이터를 활용하는 통계적 기법.
  • 애자일 스크럼 (Scrum) : TSP와 유사하게 자기 조직화 팀을 지향하나, 정량적 측정보다는 가치 전달과 피드백에 집중하는 융합 대상 방법론.
  • 코드 인스펙션 (Code Inspection) : PSP 2단계의 핵심 활동으로, 컴파일러나 테스트에 의존하기 전에 개발자가 스스로 논리적 결함을 찾아내는 정적 분석 과정.
  • 기술 부채 (Technical Debt) : PSP 없이 무리한 일정 압박 속에서 개발할 때 필연적으로 쌓이는 코드의 구조적 결함.

👶 어린이를 위한 3줄 비유 설명

  1. 내가 숙제를 할 때 어떤 문제에서 자주 틀리는지, 시간이 얼마나 걸리는지 스스로 일기장에 적어보는 것이 PSP예요.
  2. 그렇게 자기 실력을 잘 아는 친구들이 모여서, 이번 주에는 누가 어떤 숙제를 완벽하게 해낼지 스스로 계획을 짜는 것이 TSP랍니다.
  3. 이렇게 하면 선생님이 억지로 시키지 않아도, 친구들끼리 서로 돕고 확인하면서 틀린 문제 없이 숙제를 엄청 빨리 끝낼 수 있어요!