하이퍼 애자일이 바꾸는 지점

이 장에서 배우는 것 무엇을 바꾸는 방법론인지, 그리고 병목이 사라지는 게 아니라 이동한다는 것.

바꾸는 것은 하나입니다

조율의 주체를 사람에서 AI 에이전트로 옮깁니다.

스프린트를 더 잘게 쪼개자는 이야기가 아닙니다. 앞 장에서 봤듯 그건 조율 비율만 올립니다.

에이전트가 조율하면 무엇이 없어지나

이것들이 없어지면 사이클의 하한이 달라집니다.

무엇이 그대로인가

이 부분이 중요합니다. 애자일의 좋은 것들은 그대로 갑니다.

마지막 줄이 핵심입니다. 사람이 줄어드는 게 아니라 역할이 앞으로 옮겨갑니다.

비교표

각 행이 다음 장들의 주제입니다.

병목은 사라지지 않고 이동합니다

여기가 가장 오해하기 쉬운 대목입니다.

graph TD
  A["조율 병목 제거"] --> B["다음 병목이 드러남"]
  B --> C["무엇을 만들지<br/>얼마나 정확히 말할 수 있는가"]

애매한 요구사항을 넣으면 애매한 결과물이 아주 빠르게 나옵니다. 속도가 빨라진 만큼 잘못된 방향으로도 빠르게 갑니다 — 에이전트는 틀린 방향으로도 열심히 간다는 성질이 조직 차원에서 나타나는 것입니다.

그래서 사람의 일이 이렇게 바뀝니다.

이게 우리에게 맞나 — 먼저 확인할 것

방법론을 도입하기 전에 확인할 것이 하나 있습니다.

테스트가 "완료"를 판정할 만큼 촘촘한가?

하이퍼 애자일은 테스트를 완료의 유일한 기준으로 삼습니다. 그 기준이 부실하면 빠르게 잘못된 것을 만들어냅니다.

테스트 문화가 없는 조직에서 이 방법론을 먼저 도입하면 속도만 올라가고 품질 판정은 아무도 못 하는 상태가 됩니다. 그 경우 테스트 체계부터 세우는 게 순서입니다.

자주 하는 오해

"개발자가 필요 없어진다는 뜻인가?"

아닙니다. 하는 일이 바뀝니다. 의도를 정확히 정의하고, 판정 기준을 세우고, 결과를 판단하는 일이 남습니다. 그리고 이 일들은 그 도메인을 아는 사람만 할 수 있습니다.

오히려 도메인 지식의 가치가 올라갑니다. 코드 작성 기술의 상대적 비중이 줄어들 뿐입니다.

"우리 규모에는 과한 것 아닌가"

방법론 전체를 도입하지 않아도 개별 요소는 따로 쓸 수 있습니다.

• 작업을 원자 단위로 쪼개기 → 규모 무관하게 유용
• 테스트를 완료 기준으로 삼기 → 규모 무관
• 자가 치유 루프 → 자동화 파이프라인이 있어야 함

앞의 둘부터 시작해도 됩니다.

확인

1. 하이퍼 애자일이 바꾸는 것 한 가지는 무엇입니까?

2. 조율 병목이 사라지면 다음 병목은 어디에 생깁니까?

3. 도입 전에 반드시 확인해야 할 한 가지는?

이제 핵심 개념 세 가지를 하나씩 봅니다. 먼저 작업 단위입니다 → 마이크로 스프린트