프로젝트 초기에 자꾸 빠뜨리는 20가지 작업: 왜 계획은 항상 구멍이 날까?

"이번엔 완벽하게 시작하자"

킥오프 미팅의 화이트보드는 언제나 깔끔합니다.
모든 작업이 정리되어 있고, 일정도 명확하고, 팀원들의 얼굴엔 자신감이 넘칩니다.

그런데 3개월 후면 어김없이 계획의 절반도 못 간 상태에서 예산은 바닥을 보이기 시작합니다.
"아, 이것도 해야 했구나", "저것도 빠뜨렸네" 하며 계획을 수정합니다.
처음엔 간단해 보였던 프로젝트인데, 막상 진행하니 놓친 작업들이 줄줄이 나타납니다.

무엇이 문제일까요?

답은 프로젝트 초기에 "당연히 누군가 했겠지"라고 생각한 작업들입니다.
NASA 연구에 따르면, 초기에 놓친 작업을 나중에 처리하는 비용은 100배에서 1000배까지 증가합니다.
1시간이면 끝날 작업이 나중엔 100시간의 재작업으로 돌아온다는 뜻이죠.

Standish Group의 2023년 보고서를 보면 더 충격적입니다.
프로젝트 실패의 43%가 초기 계획에서 놓친 작업 때문이었고, 그 중 85%가 "기본적인 것"들이었습니다.

프로젝트 초기에 놓치기 쉬운 20가지 작업

1. 환경 설정 문서화

"README에 npm install이라고만 써있으면 되지 않나요?"

신입 개발자가 합류할 때마다 개발 환경 구축에 3일씩 걸린다면? 팀원 10명이면 30일의 생산성이 날아갑니다. Node 버전, 환경 변수, 데이터베이스 설정 등을 명확히 문서화해야 합니다.

2. 에러 처리 표준화

"에러는 나중에 처리하면 되잖아요."

초기에 에러 처리 표준을 정하지 않으면, 나중엔 수백 가지 다른 방식의 에러 처리가 난무합니다. 디버깅은 악몽이 되고, 사용자는 알 수 없는 오류 메시지에 좌절합니다.

3. 로깅 전략 수립

"console.log면 충분하지 않나?"

프로덕션에서 문제가 생겼을 때, 로그가 없으면 눈을 가리고 디버깅하는 것과 같습니다. 로그 레벨, 포맷, 저장 방식을 초기에 정해야 합니다.

4. 보안 체크리스트

"보안은 나중에..."

OWASP Top 10조차 체크하지 않고 시작하면, 나중엔 전체 아키텍처를 뜯어고쳐야 할 수 있습니다. SQL Injection, XSS, CSRF 같은 기본적인 보안 취약점은 초기에 막아야 합니다.

5. 성능 기준선 설정

"빠르면 되는 거 아닌가요?"

'빠르다'의 기준이 없으면, 성능 최적화는 끝이 없습니다. API 응답 시간, 페이지 로드 시간, 동시 사용자 수 등 명확한 기준이 필요합니다.

6. 데이터 마이그레이션 계획

"기존 데이터요? 그냥 복사하면 되죠."

레거시 시스템의 데이터는 생각보다 복잡합니다. 인코딩 문제, 형식 불일치, 중복 데이터 등을 처리하는 계획이 없으면 출시가 몇 달씩 지연됩니다.

7. 롤백 전략

"문제 생기면 이전 버전으로 되돌리면 되죠."

데이터베이스 스키마가 변경됐다면? 외부 API 연동이 바뀌었다면? 롤백은 단순히 코드를 되돌리는 것이 아닙니다.

8. 모니터링 대시보드 구축

"서버가 죽으면 알람 오잖아요."

서버가 죽기 전에 징조를 파악해야 합니다. CPU, 메모리, 디스크, 네트워크 사용량을 실시간으로 모니터링할 대시보드가 필요합니다.

9. API 버저닝 정책

"API는 한 번 만들면 끝 아닌가요?"

첫 번째 API 변경이 필요한 순간, 버저닝 정책이 없으면 기존 클라이언트가 모두 깨집니다. v1, v2 같은 버전 관리 전략을 초기에 수립해야 합니다.

10. 테스트 데이터 관리

"테스트 데이터는 아무거나 넣으면 되죠."

현실적인 테스트 데이터가 없으면, 프로덕션에서만 발견되는 버그가 속출합니다. 대용량 데이터, 엣지 케이스, 다국어 데이터 등을 준비해야 합니다.

11. 백업 및 복구 절차

"백업은 자동으로 되고 있어요."

백업은 되는데 복구를 해본 적이 없다면? 실제로 복구가 필요한 순간, 백업 파일이 손상됐거나 복구 절차를 모른다면 재앙입니다.

12. 라이선스 검토

"오픈소스니까 무료 아닌가요?"

GPL 라이선스 라이브러리를 상용 제품에 사용했다가 소스코드를 공개해야 하는 상황이 생길 수 있습니다. 사용하는 모든 라이브러리의 라이선스를 검토해야 합니다.

13. 접근성(Accessibility) 기준

"일단 만들고 나중에 개선하면..."

WCAG 2.1 기준을 나중에 적용하려면 UI를 처음부터 다시 만들어야 할 수 있습니다. 키보드 네비게이션, 스크린 리더 지원 등은 초기부터 고려해야 합니다.

14. 국제화(i18n) 준비

"영어 버전만 만들면 되잖아요."

나중에 다국어를 지원하려면 모든 하드코딩된 텍스트를 찾아 수정해야 합니다. 날짜 형식, 통화, 시간대 처리도 초기에 설계해야 합니다.

15. 캐시 무효화 전략

"캐시하면 빨라지잖아요."

캐시는 컴퓨터 과학의 두 가지 어려운 문제 중 하나입니다. 언제 캐시를 무효화할지, 어떻게 일관성을 유지할지 전략이 없으면 데이터 불일치로 고생합니다.

16. 세션 관리 정책

"로그인 유지하면 되는 거 아닌가?"

세션 타임아웃, 동시 로그인 제한, 세션 하이재킹 방지 등을 고려하지 않으면 보안 구멍이 생깁니다.

17. 파일 업로드 제한

"파일 업로드 기능 추가는 간단하죠."

파일 크기 제한, 형식 검증, 악성 코드 스캔, 저장 공간 관리를 고려하지 않으면 서버가 다운되거나 보안 사고가 발생합니다.

18. 이메일 발송 시스템

"SMTP 설정하면 끝 아닌가요?"

반송 처리, 스팸 필터 회피, 대량 발송 제한, 템플릿 관리 등을 고려하지 않으면 이메일이 전달되지 않습니다.

19. 외부 서비스 장애 대응

"AWS는 안 죽잖아요."

2023년에만 AWS가 3번 다운됐습니다. 외부 서비스 장애 시 우아한 성능 저하(Graceful Degradation) 전략이 필요합니다.

20. 문서화 표준

"코드가 문서죠."

코드는 'How'를 보여주지만 'Why'는 보여주지 않습니다. API 문서, 아키텍처 결정 기록(ADR), 운영 매뉴얼 등의 표준을 초기에 정해야 합니다.

체크리스트로 만들어 활용하기

이 20가지를 프로젝트 초기 체크리스트로 만들어 활용하세요:

## 프로젝트 초기 체크리스트

### 개발 환경

- [ ] 환경 설정 문서 작성
- [ ] 개발 환경 자동화 스크립트
- [ ] IDE 설정 공유

### 품질 관리

- [ ] 에러 처리 표준
- [ ] 로깅 전략
- [ ] 테스트 데이터 준비
- [ ] 성능 기준선

### 보안 및 운영

- [ ] 보안 체크리스트
- [ ] 백업/복구 절차
- [ ] 롤백 전략
- [ ] 모니터링 대시보드

### 확장성

- [ ] API 버저닝
- [ ] 캐시 전략
- [ ] 국제화 준비
- [ ] 접근성 기준

### 외부 연동

- [ ] 라이선스 검토
- [ ] 외부 서비스 장애 대응
- [ ] 이메일 시스템
- [ ] 파일 업로드 정책

### 기타

- [ ] 데이터 마이그레이션
- [ ] 세션 관리
- [ ] 문서화 표준

핵심 정리

"악마는 디테일에 있다"는 말이 있습니다.

프로젝트도 마찬가지입니다.
거창한 아키텍처나 최신 기술보다, 이런 기본적인 것들을 놓치지 않는 것이 더 중요합니다.

위 20가지 중에서 여러분의 프로젝트에서 놓친 것은 몇 개나 되나요?
지금이라도 늦지 않았습니다.
하나씩 체크하고 보완해 나가세요.
초기에 투자한 1시간이 나중에 100시간을 절약해줄 것입니다.

기억하세요.
완벽한 계획은 없지만, 구멍 난 계획으로 시작하면 반드시 실패합니다.

다음 프로젝트부터 이 20가지를 체크리스트로 활용해보세요.
작은 노력이 큰 차이를 만듭니다.

---

프로젝트 계획을 체계적으로 관리하고 싶으신가요? Plexo를 확인해보세요.

인지 부하 이론으로 본 WBS: 왜 우리 뇌는 7개 이상을 처리 못할까

"이 프로젝트 작업이 총 몇 개죠?"

"음... 한 200개쯤?"

그 순간 PM의 뇌는 멈춥니다.
200개를 어떻게 머릿속에서 관리하죠?

프로젝트가 커질수록 WBS는 복잡해집니다.
작업이 50개, 100개, 200개로 늘어나면서, 머릿속에서 모든 것을 추적하기 어려워집니다.
"이 작업은 어디에 속하지?", "저 작업은 누가 하지?" 하며 혼란스러워집니다.

이런 경험 있으신가요?

오늘은 인지과학의 관점에서 WBS를 다시 봅니다.
왜 우리 뇌는 복잡한 프로젝트 앞에서 무력해지는지,
그리고 어떻게 뇌 친화적인 WBS를 만들 수 있는지 알아봅시다.

밀러의 마법 숫자: 7±2

1956년, 심리학자 조지 밀러는 인간의 단기 기억 용량을 발견했습니다.

인간의 작업 기억 용량:

• 최대 7개 항목 (±2)
• 지속 시간: 약 20초
• 7개 이하: 처리 가능
• 7개 초과: 혼란과 실수 증가

프로젝트도 마찬가지입니다.
한 번에 7개 이상의 작업을 생각하면 뇌가 과부하됩니다.
3개 작업은 쉽게 기억하지만, 15개 작업은 머릿속에서 꼬이기 시작합니다.

청킹(Chunking): 뇌의 압축 알고리즘

우리 뇌는 정보를 묶어서(chunk) 처리합니다.

청킹 전: 12개 개별 항목 (과부하)

• HTML 작성, CSS 스타일링, JavaScript 로직, API 설계, DB 스키마, 쿼리 작성, 단위 테스트, 통합 테스트, E2E 테스트, 서버 설정, 도메인 연결, SSL 설정

청킹 후: 4개 그룹 (처리 가능)

• 프론트엔드: HTML 작성, CSS 스타일링, JavaScript 로직
• 백엔드: API 설계, DB 스키마, 쿼리 작성
• 테스트: 단위 테스트, 통합 테스트, E2E 테스트
• 인프라: 서버 설정, 도메인 연결, SSL 설정

이것이 WBS가 계층 구조를 갖는 과학적 이유입니다.
작은 작업들을 의미 있는 그룹으로 묶으면 뇌가 훨씬 쉽게 처리합니다.

인지 부하의 3가지 유형

인지 부하 이론(Cognitive Load Theory)에 따르면:

1. Intrinsic (본질적 부하)

• 정의: 작업 자체의 복잡도
• 예시: 알고리즘 구현의 난이도
• 해결: 작업을 더 작게 분해

2. Extraneous (외재적 부하)

• 정의: 불필요한 정보 처리
• 예시: 복잡한 엑셀 시트 해독
• 해결: 시각화와 단순화

3. Germane (관련 부하)

• 정의: 학습과 이해에 필요한 부하
• 예시: 새로운 기술 스택 학습
• 해결: 점진적 학습 계획

인지 부하 최적화 전략:

• 복잡한 작업을 2-4시간 단위로 분해
• 불필요한 회의와 보고서 제거
• 학습 시간을 명시적으로 할당

주의력 자원 이론 (Attention Resource Theory)

우리의 주의력은 한정된 자원입니다.

멀티태스킹 시 효율 감소:

• 단일 작업: 100% 효율
• 2개 동시: 각 40% 효율 (총 80%)
• 3개 동시: 각 20% 효율 (총 60%)
• 4개 이상: 거의 진전 없음 (총 40%)

실제 예시:

• 코딩만 할 때: 100% 집중 가능
• 코딩 + 회의 + 이메일 + 리뷰: 각 작업당 10% 집중

이래서 WIP(Work In Progress) 제한이 중요합니다.
동시에 진행하는 작업을 2-3개로 제한하면 효율이 크게 향상됩니다.

시각적 계층 구조의 힘

우리 뇌는 시각 정보를 텍스트보다 60,000배 빠르게 처리합니다.

텍스트 리스트 (인지 부하 높음):

• 1. 프로젝트
• 1.1 프론트엔드
• 1.1.1 UI 개발
• 1.1.2 상태 관리
• 1.2 백엔드
• 1.2.1 API 개발
• 1.2.2 DB 설계

시각적 트리 (인지 부하 낮음):

프로젝트
├── 프론트엔드
│   ├── UI 개발
│   └── 상태 관리
└── 백엔드
    ├── API 개발
    └── DB 설계

인지 부하 비교:

• 텍스트: 7 (각 항목을 개별 처리)
• 시각: 3 (구조를 한눈에 파악)
• 시각화로 인지 부하 57% 감소

프로그레시브 디스클로저 (Progressive Disclosure)

모든 정보를 한 번에 보여주지 마세요.

상황별 적정 수준:

• 개요 (Overview): 기획, 개발, 테스트, 배포 (인지 부하: 4)

  • 경영진 보고서에 적합

• 확장 (Expanded): 개발 → 프론트, 백엔드, DB, API (인지 부하: 7)

  • 일일 스탠드업에 적합

• 상세 (Detailed): 프론트 → 컴포넌트, 라우팅, 상태관리, 스타일링 (인지 부하: 10)

  • 상세 계획 시에만 사용 (과부하 위험)

필요할 때만 펼쳐서 보는 것이 뇌에 부담을 덜 줍니다.

인지 부하를 줄이는 WBS 설계 원칙

1. 매직 넘버 7 규칙

각 레벨당 항목을 7개 이하로 제한하세요.

규칙:

• 레벨1: 최대 7개 주요 단계
• 레벨2: 각 단계당 최대 7개 작업
• 레벨3: 각 작업당 최대 7개 세부사항

나쁜 예: 15개 최상위 항목 (과부하)

좋은 예: 5개로 그룹핑

• 준비: 기획, 설계
• 개발: 프론트, 백엔드
• 품질: 테스트, 리뷰
• 배포: 스테이징, 프로덕션
• 운영: 모니터링, 유지보수

2. 색상 코딩 시스템

뇌가 즉시 인식하는 색상 체계를 사용하세요.

색상 코딩:

• 회색: 시작 전
• 파랑: 진행 중
• 주황: 차단됨
• 초록: 완료
• 빨강: 위험

인지 부하 비교:

• 텍스트 읽기: 200ms
• 색상 인식: 50ms (4배 빠름)

색상으로 상태를 표시하면 텍스트를 읽을 필요 없이 즉시 파악할 수 있습니다.

3. 패턴 인식 활용

반복 패턴으로 인지 부하를 감소시킬 수 있습니다.

일관된 명명 패턴:

• 프론트엔드: Design_Frontend, Develop_Frontend, Test_Frontend
• 백엔드: Design_Backend, Develop_Backend, Test_Backend
• 데이터베이스: Design_Database, Develop_Database, Test_Database

패턴을 학습하면 예측 가능해집니다.
새 작업 이해 시간 70% 감소

인지 과학 기반 WBS 도구 요구사항

필수 기능:

• 접기/펼치기: Progressive Disclosure
• 색상 코딩: 즉각적 상태 인식
• 드래그앤드롭: 공간 기억 활용
• 자동 그룹핑: 7±2 규칙 적용
• 시각화 뷰: 트리, 칸반, 간트
• 검색/필터: 주의력 집중
• 템플릿: 인지 부하 감소

피해야 할 기능:

• 과도한 정보: 한 화면에 모든 것
• 깊은 계층: 5단계 이상 중첩
• 작은 글씨: 가독성 저하
• 복잡한 관계: 많은 의존성 화살표

실전: 인지 친화적 WBS 체크리스트

□ 각 레벨이 7개 이하 항목인가?
□ 색상 코딩을 사용하는가?
□ 일관된 명명 패턴인가?
□ 시각적 계층 구조가 명확한가?
□ 필요한 정보만 표시하는가?
□ 복잡한 작업을 청킹했는가?
□ 인지 부하가 높은 시간대를 피했는가?

핵심 정리

우리 뇌는 슈퍼컴퓨터가 아닙니다.
하지만 올바른 방식으로 정보를 제공하면,
놀라운 능력을 발휘합니다.

WBS는 단순한 작업 목록이 아닙니다.
우리 뇌가 복잡한 프로젝트를 이해하고 관리할 수 있도록 돕는 인지 도구입니다.

인지 과학을 이해하고 적용하면,
더 명확하고, 더 효율적이고, 더 스트레스 없는 프로젝트 관리가 가능합니다.

다음 WBS 작성 시 이 원칙들을 적용해보세요.
작은 변화가 큰 차이를 만듭니다.

---

인지 과학 기반의 스마트한 WBS 도구가 필요하신가요? Plexo를 확인해보세요.