HyperTeams프로세스 4단계 지도
이 장에서 배우는 것 다음 네 장이 각각 무엇을 다루는지, 그리고 익숙한 분석·설계·구현·시험이 이 안에서 어디로 갔는지.
여기까지 개념을 봤습니다 — 남은 병목, 바뀌는 지점, 마이크로 스프린트, IntentOps, 유동적 소프트웨어.
이제 실제 프로세스입니다. 네 장으로 이어지는데, 들어가기 전에 전체를 한 장에서 봅니다.
4개 프로세스
graph TD
P1["프로세스 1<br/>의도 포착"] --> P2["프로세스 2<br/>에이전트 오케스트레이션"]
P2 --> P3["프로세스 3<br/>자동 검증"]
P3 --> P4["프로세스 4<br/>즉시 배포"]
P3 -.->|"테스트 실패"| P2
P3 -.->|"재시도 초과 — 명세가 문제"| P1
P4 -.->|"모니터링 신호"| P1점선 셋이 이 그림의 내용입니다.
- 프로세스 3 → 2 (자가 치유): 테스트가 실패하면 사람을 부르지 않고 코드를 다시 만듭니다. 이게 루프의 기본 동작입니다.
- 프로세스 3 → 1 (되돌아감): 몇 번 고쳐도 안 되면 코드가 아니라 명세나 테스트가 틀린 것입니다. 여기서 사람이 들어옵니다.
- 프로세스 4 → 1 (루프가 닫힘): 배포 후 모니터링 신호가 다음 사이클의 의도가 됩니다.
한 바퀴가 분·시간 단위입니다. 2주가 아닙니다.
각 프로세스가 답하는 질문
| 프로세스 | 핵심 질문 | 산출물 |
|---|---|---|
| 1. 의도 포착 | 무엇을 만드는가 — 해석의 여지 없이 | 명세 + 완료 판정 테스트 |
| 2. 오케스트레이션 | 어떻게 만드는가 | 동작하는 코드 |
| 3. 자동 검증 | 정말 됐는가 | 전부 통과한 테스트 결과 |
| 4. 즉시 배포 | 실제로 쓰이는가 | 배포된 변경 + 모니터링 신호 |
익숙한 4단계는 어디로 갔나
분석 → 설계 → 구현 → 시험. 이 순서로 일해온 조직이라면 위 그림이 낯설 것입니다. 사라진 게 아니라 자리가 바뀌었습니다.
| 익숙한 단계 | 어디로 갔나 | 무엇이 달라졌나 |
|---|---|---|
| 분석 | 프로세스 1 | 회의가 아니라 PM 에이전트의 문답. 회의록이 아니라 문답이 그대로 명세 |
| 설계 | 프로세스 2 안의 아키텍트 | 별도 단계가 아니라 구현·리뷰와 동시에 도는 역할 |
| 구현 | 프로세스 2 안의 코딩 | 사람이 아니라 에이전트가 씀. 코드는 자산이 아니라 파생물 |
| 시험 | 앞(IntentOps) + 프로세스 3 | 맨 뒤가 아니라 명세와 함께 앞에서 정해지고, 뒤에서는 자동 판정만 |
| (배포) | 프로세스 4 | 단계 밖의 이벤트가 아니라 루프 안 |
가운데 두 줄을 조금 더 봅니다.
설계는 사라지지 않았습니다
프로세스 2에 아키텍트 에이전트가 있고, 시스템 구조와 변경 범위를 설계하는 일이 그대로 있습니다. 다만 구현이 끝나기를 기다렸다가 리뷰가 시작되는 순서가 아닙니다. 셋이 동시에 돌고, 문제가 발견되면 되돌아갑니다.
그리고 사람이 설계에 개입하는 지점이 정해져 있습니다.
- 설계 방향이 명세와 어긋날 때
- 되돌릴 수 없는 결정 — 스키마 변경, 외부 계약 변경
이 둘은 사이클이 아무리 짧아져도 사람이 봅니다.
시험은 앞으로 당겨졌습니다
전통적으로 시험은 마지막 관문이었습니다. 여기서는 IntentOps에서 명세와 함께 테스트를 먼저 정하고, 프로세스 3은 그걸 돌려 판정만 합니다.
순서가 바뀐 이유는 하나입니다. 사람이 완료를 판정하지 않으려면 판정 기준이 시작 시점에 있어야 하기 때문입니다.
순서가 아니라 조율이 바뀐 것입니다
이 지도를 보고 "결국 워터폴을 빠르게 도는 것 아닌가"라고 읽기 쉽습니다. 그렇지 않습니다.
graph TD
W["순차 모델"] --> W1["설계가 끝나야 구현<br/>구현이 끝나야 리뷰"]
H["프로세스 2"] --> H1["아키텍트 · 코딩 · 리뷰가<br/>동시에 돌며 주고받음"]바뀌는 지점에서 본 대로 이 방법론이 바꾸는 것은 단계의 순서나 길이가 아니라 조율의 주체입니다. 위 매핑 표는 익숙한 이름이 어디에 들어갔는지 보여주는 지도일 뿐이고, 네 프로세스를 순차 게이트로 읽으면 안 됩니다.
사람은 어디에 있나
네 프로세스 어디에도 "사람이 코드를 쓴다"가 없습니다. 대신 세 곳에 있습니다.
| 위치 | 하는 일 |
|---|---|
| 프로세스 1 앞 | 무엇을 만들지 정하는 판단 |
| 프로세스 2 안 | 설계 방향, 그리고 되돌릴 수 없는 결정의 승인 |
| 프로세스 3 의 기준 | 테스트가 진짜 합격 기준인지 보는 눈 |
세 번째가 가장 자주 빠집니다. 루프의 목표는 테스트 통과라서 기준이 얕으면 빈틈을 정확히 파고듭니다.
넷을 다 도입해야 하나
아닙니다. 프로세스 4(즉시 배포)는 전제 조건이 가장 많습니다 — 자동 배포 파이프라인, 분 단위 롤백, 실시간 모니터링. 갖춰지지 않았다면 프로세스 1~3만 쓰고 배포는 기존대로 사람 승인으로 두는 것이 맞습니다.
자주 하는 오해
"그럼 설계 문서는 안 쓰나?"
문서의 자리에 명세와 테스트가 들어갑니다. 사람에게 설명하려고 쓰던 문서는 줄고, 사람과 에이전트가 같이 읽는 명세가 남습니다. 유동적 소프트웨어에서 본 "지켜야 할 자산이 코드에서 명세+테스트로 옮겨간다"와 같은 이야기입니다.
"단계별 산출물 검토가 필요한 조직인데요"
프로세스마다 산출물이 있으니 검토 지점 자체는 만들 수 있습니다. 다만 거는 위치가 다릅니다. 사이클이 분·시간 단위로 도는데 사이클마다 사람 검토를 걸면 없앴던 조율 비용이 그대로 돌아옵니다. 검토는 개별 사이클이 아니라 명세와 테스트 기준 쪽에 겁니다 — 그게 가드레일의 주제입니다.
확인
1. 익숙한 "설계" 단계는 어디로 갔습니까?
답
프로세스 2 안의 아키텍트 역할로 갔습니다. 없어진 게 아니라 별도 단계가 아니게 된 것이고, 구현·리뷰와 동시에 돕니다. 다만 되돌릴 수 없는 결정(스키마 변경, 외부 계약 변경)은 사람이 승인합니다.
2. 시험이 앞으로 당겨진 이유는?
답
사람이 완료를 판정하지 않기 때문입니다. 자동으로 판정하려면 판정 기준이 시작 시점에 있어야 해서, IntentOps에서 명세와 함께 테스트를 먼저 정합니다.
3. 프로세스 3에서 테스트가 계속 실패하면 무엇을 의심해야 합니까?
답
몇 번 고쳐도 안 되면 코드가 아니라 명세나 테스트가 틀린 것입니다. 그래서 재시도 한계를 걸고 초과하면 사람을 부릅니다 — 그림의 프로세스 3 → 1 점선입니다.
이제 각 프로세스를 하나씩 봅니다 → 프로세스 1 — 의도 포착