[Software Spec Series 4] 스펙의 역할

소프트웨어 프로젝트에서 스펙의 역할을 알아보자.

모든 프로젝트 이해관계자가 사용, 프로젝트의 중심

스펙은 프로젝트의 모든 요구사항이 모이며 프로젝트의 중심이 되는 문서다. 프로젝트의 모든 이해관계자가 스펙을 참조하거나 작성에 참여한다. 스펙은 다시 여러 프로젝트 이해관계자들이 받아서 자신의 역할을 수행한다. 프로젝트에서 가장 중요한 문서 하나를 꼽으라고 하면 스펙이다.

(프로젝트의 모든 이해관계자가 참조해야 하는 SRS)

고객, 마케팅 부서, 영업 부서는 어떠한 제품이 만들어지는지 알 수 있다.

스펙이 없거나 부실한 상태로 진행하는 프로젝트는 프로젝트가 완료되기 전까지 어떠한 소프트웨어가 개발될지 알기가 어렵다. 그러면 영업부서는 소프트웨어 개발이 완료되기 이전에 판매 준비를 하거나 계약을 할 수가 없다. 스펙이 잘 작성된 프로젝트인 경우 스펙만 보고도 최종적으로 개발될 소프트웨어가 무엇인지 정확하게 알 수 있다. 영업부서에서는 이를 보고 판매에 필요한 준비를 할 수 있다. 영업망을 확충하거나 세일즈 자료를 준비할 수 있다. 또한 고객을 만나서 개발도 완료되지 않은 소프트웨어를 미리 팔 수도 있다. 소프트웨어 개발이 완료된 후에 부랴부랴 판매를 시작한다면 이미 상당한 판매 기회를 놓치게 된 것이다. 그 외에 안전, 의료, 보안 등의 인증이 필요한 경우도 스펙이 잘 작성되어 있다면 소프트웨어 개발이 완료되지 않았음에도 인증을 신청해서 인증을 미리 획득할 수 있다. 인증은 종류에 따라서 1년 넘게 또는 수년이 걸리기도 한다. 소프트웨어 개발이 완료된 후에서야 인증을 진행하면 수년의 영업 기회를 날려버릴 수도 있다.

프로젝트관리자(PM)에게는 스펙이 프로젝트 관리의 기준이 된다. 일정산정, 인력 배분, 리스크 분석 등을 할 수 있다.

스펙이 제대로 작성되지 않는 프로젝트에서 프로젝트 관리자는 별로 할 일이 없다. 일정을 제대로 예측하기도 어렵고, 리스크 파악도 어렵다. 적정한 리소스 계획을 세우지 못한다. 프로젝트가 진행이 되도 정확하게 진척률을 파악할 수가 없다. 그래서 1년짜리 프로젝트가 8개월쯤 지나도 정확하게 1년 안에 프로젝트가 종료될지 예측이 안된다. 그러면 프로젝트 관리자는 프로젝트 성공을 위해서 무엇을 더 해야 하는지 알 수 없다. 그저 운에 맡기는 수밖에 없다. 프로젝트의 성격에 따라서는 단계별로 진행을 하여 짧은 주기로 여러 차례 업그레이드를 하면서 진행하는 경우도 있다. 이 경우도 주기만 짧을 뿐이지 짧은 주기에 해당하는 스펙을 적절히 작성하는 것도 똑같이 필요하다.

개발팀은 스펙을 통해서 개발팀이 개발해야 할 제품이 무엇인지 정확하게 알 수 있다.

스펙을 제대로 작성하지 않았다면 개발팀은 정확하게 무엇을 개발해야 하는지 파악하기 어렵다. 기획자나 분석 아키텍트에게 너무 많은 것을 수시로 물어봐야 해서 시간을 매우 낭비해야 한다. 개발자가 임의대로 생각해서 기능을 구현하게 되면 기획의 의도와는 완전히 다르게 되기도 한다. 개발자에게 주어진 너무 높은 자유도가 소프트웨어 아키텍처를 부실하게 만들기도 한다. 개발자에게 자유도는 필요하지만 소프트웨어 전체 아키텍처는 분석, 설계 시에 정해져서 개발자에게는 한정된 자유도만 주어야 한다. 그래야 기획 시 의도된 소프트웨어가 제대로 개발될 수 있다.

(프로젝트에서 SRS의 위치)

테스트팀은 스펙을 통해서 테스트 계획 및 테스트 케이스를 작성할 수 있다.

보통은 스펙 작성 후에 개발자들이 구현을 하는 동안 테스트팀은 테스트 준비를 한다. 테스트 계획을 세우고 테스트 설계를 해야 한다. 하지만 스펙이 없거나 부실하다면 테스트팀은 테스트 준비를 제대로 할 수가 없다. 소프트웨어가 개발된 후에 소프트웨어를 보면서 테스트 준비를 해야 하는데 이 방법으로는 테스트 일정도 예측할 수 없고 부실한 테스트를 할 수 밖에 없다. 소프트웨어 품질이 나빠지는 것은 당연한 결과다.

기술문서팀은 스펙을 통해서 매뉴얼과 도움말을 작성할 수 있다.

소프트웨어 스펙이 완성된 후에는 많은 일들이 벌어진다. 기술문서팀은 소프트웨어를 동작시켜 보지도 않고 매뉴얼을 미리 작성한다. 단지 화면 캡쳐만 소프트웨어 개발 후 추가할 뿐이다. 이뿐만 아니다. 고객지원 부서는 고객 지원에 필요한 준비를 해 놓고 교육팀은 교육 준비를 한다. 이처럼 소프트웨어 스펙을 보고 많은 사람들이 자신의 일을 수행해야 하는데 바쁘다고 스펙 없이 개발을 하는 것은 개발자 중심의 사고방식이며 프로젝트가 효율적으로 진행되지도 않는다.

외주 업체는 스펙을 통해서 외주 업무를 정확하게 파악하고 SRS를 기준으로 계약을 할 수 있다.

우리나라에서는 많은 소프트웨어 프로젝트가 스펙도 없이 진행이 된다. 대략의 요구사항을 기반으로 계약하고 진행되는 프로젝트는 정상적으로 진행되기 어렵다. 고객이 수시로 요구사항을 무리하게 바꿔도 하소연하기 어렵다. 또한, 분석을 제대로 하지 않고 진행을 하므로 요구사항만으로는 프로젝트의 규모를 제대로 산정하기 어렵다. 그래서 계약 시는 성공적인 계약으로 생각되지만 프로젝트를 진행할수록 손해를 보는 경우도 허다하다. 우리나라도 스펙을 기준으로 계약을 하는 관행이 자리잡아야 한다.

share with abctech.software

"계획은 완벽했는데 왜 항상 늦어질까요?"

이 질문을 하는 PM이라면, 아마 숨은 작업을 놓쳤을 겁니다.

프로젝트가 진행되면서 "아, 이것도 해야 했구나"라는 순간이 반복됩니다.
처음엔 일주일만 늦어질 거라고 생각했는데, 어느새 한 달이 지나갑니다.
팀원들의 눈빛에서 자신감이 사라지고, 매일 아침 스탠드업 미팅이 부담스러워집니다.

연구에 따르면 초기 WBS 작성 시 평균 30-50%의 작업이 누락됩니다.
마치 빙산처럼, 수면 아래 보이지 않는 작업들이 프로젝트를 침몰시킵니다.

오늘은 이 숨은 작업들을 체계적으로 찾아내는 7가지 실전 기법을 소개합니다.
더 이상 "예상치 못한 작업"에 당황하지 마세요.

숨은 작업의 정체

먼저 무엇이 숨어있는지 알아야 찾을 수 있습니다.

숨은 작업의 5가지 카테고리:

1. 준비 작업: 환경 설정, 도구 설치, 권한 획득, 학습
2. 연결 작업: 데이터 마이그레이션, API 연동, 시스템 통합
3. 품질 작업: 코드 리뷰, 리팩토링, 성능 최적화, 보안 검토
4. 소통 작업: 회의, 문서화, 지식 공유, 피드백 반영
5. 수정 작업: 버그 수정, 요구사항 변경, 재작업, 롤백

대부분의 PM은 "구현"에만 집중합니다.
하지만 실제로는 구현 외 작업이 전체의 40-60%를 차지합니다.

기법 1: 시간축 역추적법 (Timeline Reverse Engineering)

"끝에서부터 시작하라"

일반적으로는 시작부터 끝까지 생각합니다.
하지만 거꾸로 생각하면 놓치기 쉬운 중간 단계들이 드러납니다.

역추적 과정:

1. 최종 산출물: 배포 완료
2. 그 전에 필요한 것: 운영 환경 테스트
3. 그 전에 필요한 것: 스테이징 배포
4. 그 전에 필요한 것: 통합 테스트
5. 그 전에 필요한 것: 단위 테스트
6. 그 전에 필요한 것: 코드 리뷰
7. 그 전에 필요한 것: 기능 구현
8. 그 전에 필요한 것: 상세 설계
9. 그 전에 필요한 것: 환경 구축

각 단계에서 "이전에 뭐가 필요한가?" 질문을 던지면 숨은 작업이 보입니다.

기법 2: 5W1H 체크리스트

"모든 작업에 6가지 질문을 던져라"

task: "로그인 기능 개발"
questions:
  what: "정확히 무엇을 만드는가?"
    - OAuth 로그인
    - 이메일 로그인
    - 비밀번호 찾기

  why: "왜 필요한가?"
    - 사용자 인증
    - 권한 관리

  who: "누가 관련되는가?"
    - 개발자
    - 디자이너 (UI)
    - 보안팀 (검토)

  when: "언제 해야 하는가?"
    - 의존성: 회원가입 후
    - 선행: API 게이트웨이 전

  where: "어디에 영향을 주는가?"
    - 프론트엔드
    - 백엔드 API
    - 데이터베이스
    - 캐시 서버

  how: "어떻게 구현하는가?"
    - JWT 토큰
    - Redis 세션
    - 보안 라이브러리

각 질문의 답변이 새로운 작업을 만들어냅니다.

기법 3: 페르소나 워크스루 (Persona Walkthrough)

"모든 이해관계자의 관점에서 걸어보라"

각 역할의 입장에서 생각하면 놓친 작업이 보입니다.

주요 페르소나별 작업:

• 개발자: 개발 환경 설정, 라이브러리 학습, 코드 작성, 디버깅, 테스트 작성
• QA: 테스트 케이스 작성, 테스트 환경 구축, 버그 리포팅, 재테스트
• 운영팀: 서버 준비, 모니터링 설정, 백업 설정, 장애 대응 준비
• 사용자: 사용법 학습, 데이터 마이그레이션, 교육 자료 필요

각 페르소나가 해야 할 일을 나열하고, 현재 WBS에 없는 작업을 찾아보세요.

기법 4: 인터페이스 매핑 (Interface Mapping)

"연결점마다 숨은 작업이 있다"

각 화살표마다 최소 3-5개의 숨은 작업이 있습니다:

• 프로토콜 정의
• 에러 처리
• 인증/인가
• 로깅
• 모니터링

기법 5: 시나리오 스트레스 테스트

"최악의 상황을 상상하라"

위기 상황을 가정하면 평소 놓치는 작업들이 드러납니다.

주요 시나리오와 숨은 작업:

• 배포 직전 크리티컬 버그 발견: 긴급 패치 개발, 재테스트, 롤백 계획 수립, 이해관계자 커뮤니케이션
• 핵심 개발자 갑작스런 부재: 지식 이전, 문서화, 새 담당자 교육, 일정 재조정
• 보안 취약점 발견: 보안 감사, 패치 개발, 침투 테스트, 보안 인증

이런 상황이 발생했을 때 필요한 작업들을 미리 계획에 포함시키세요.

기법 6: 히스토리 마이닝 (History Mining)

"과거 프로젝트의 교훈을 캐내라"

같은 실수를 반복하지 마세요.

과거 프로젝트에서 놓쳤던 작업 패턴:

• 브라우저/디바이스 호환성: 다국어 지원 (2주 지연), IE 브라우저 대응 (1주 지연)
• 레거시 시스템 통합: 데이터 마이그레이션 (3주 지연), 레거시 시스템 연동 (2주 지연)
• 규정/인증 준수: 보안 인증 (4주 지연)
• 성능 요구사항: 성능 최적화 (2주 지연)
• 데이터 관련 작업: 데이터 마이그레이션, 데이터 정제

과거 프로젝트 회고록을 보면 놓쳤던 작업들의 패턴이 보입니다.
이 패턴을 새 프로젝트에 적용하세요.

기법 7: 크로스 체크 매트릭스

"다차원으로 검증하라"

작업과 품질 속성을 매트릭스로 만들어 검증하면 숨은 작업이 보입니다.

작업 vs 품질 속성 매트릭스:

각 작업(로그인, 결제, 알림 등)에 대해 다음 품질 속성을 체크하세요:

• 보안: 암호화, 취약점 점검, 침투 테스트
• 성능: 부하 테스트, 최적화, 캐싱
• 사용성: UI 테스트, 접근성, 다국어
• 호환성: 브라우저, 모바일, API 버전
• 유지보수: 문서화, 로깅, 모니터링

예를 들어, "로그인 - 보안 - 암호화" 작업이 WBS에 있는지 확인하세요.
이 매트릭스를 통해 수십 개의 숨은 작업을 발견할 수 있습니다.

실전 적용: 체크리스트

숨은 작업 발견을 위한 최종 체크리스트:

□ 시간축 역추적: 끝에서부터 필요한 작업 나열했는가?
□ 5W1H: 모든 주요 작업에 6가지 질문 적용했는가?
□ 페르소나: 모든 이해관계자 관점 검토했는가?
□ 인터페이스: 시스템 간 연결점 분석했는가?
□ 시나리오: 위기 상황 대비 작업 포함했는가?
□ 히스토리: 과거 프로젝트 교훈 반영했는가?
□ 매트릭스: 품질 속성별 작업 검증했는가?

숨은 작업 발견의 ROI

숨은 작업을 찾는 데 시간이 걸리지만, 그 투자는 충분히 가치가 있습니다.

ROI 계산 예시:

• 투자: 16시간 (작업 발견에 드는 시간)
• 수익: 일일 지연 비용 50,000원 × 10일 = 500,000원 절감
• ROI: 약 625%

16시간 투자로 10일 지연을 막는다면, ROI는 625%입니다.
작은 투자로 큰 손실을 방지할 수 있습니다.

핵심 정리

프로젝트 성공의 비밀은 화려한 기능이 아닙니다.
보이지 않는 작업을 보는 눈입니다.

오늘 소개한 7가지 기법을 활용하면:

• 프로젝트 초기에 30% 더 많은 작업 발견
• 예상치 못한 지연 50% 감소
• 팀의 신뢰도 향상

"계획에 없던 작업"이라는 말을 더 이상 하지 마세요.
처음부터 찾아내면 됩니다.

다음 프로젝트 WBS 작성 시 이 7가지 기법을 적용해보세요.
작은 노력이 큰 차이를 만듭니다.

---

체계적인 작업 분해와 숨은 작업 발견이 필요하신가요? Plexo를 확인해보세요.