IntentOps

이 장에서 배우는 것 "코드가 아니라 의도를 만든다"가 실제로 무슨 뜻인지, 그리고 개발자가 책임지는 두 가지.

산출물이 바뀝니다

지금까지 개발자의 산출물은 코드였습니다. IntentOps에서는 이렇게 바뀝니다.

구현은 AI가 맡습니다. 개발자는 무엇을 만들지와 됐다는 걸 어떻게 아는지를 정의합니다.

책임지는 두 가지

1. 명세 — 모호하지 않게

자연어로 쓰되 해석의 여지를 남기지 않습니다.

해석의 여지가 곧 버그입니다. 위 예에서 "중복 불가"를 안 적으면 AI가 알아서 정하고, 그 결정이 기획 의도와 다를 수 있습니다.

이건 좋은 지시의 네 요소를 코드 작업에 적용한 것입니다.

2. 테스트 — 실행 가능한 합격 기준

명세를 판정 가능한 형태로 만든 것입니다.

테스트가 "완료"의 유일한 정의입니다. 다섯 개가 통과하면 끝난 것이고, 통과 안 하면 안 끝난 것입니다. "거의 다 됐다"가 없습니다.

코드는 일시적입니다

여기서 유명한 표현이 나옵니다 — "code is ephemeral".

최적화가 필요하거나 다른 스택으로 옮겨야 하면, 코드를 고치는 게 아니라 같은 의도로 다시 생성합니다.

graph TD
  I["의도 + 테스트<br/>원본"] --> C1["코드 v1"]
  I --> C2["코드 v2<br/>성능 개선판"]
  I --> C3["코드 v3<br/>다른 언어"]
  C1 -.->|"전부 같은 테스트를 통과"| T["합격 기준"]
  C2 -.-> T
  C3 -.-> T

의도와 테스트가 원본이고 코드는 파생물입니다. 이 관계가 뒤집힌 게 기존 방식이었습니다 — 코드가 원본이고 문서가 파생물이라 문서가 항상 뒤처졌습니다.

무엇이 어려워지나

솔직하게 말하면 더 어려워지는 부분이 있습니다.

"일단 만들어보면서 요구사항을 이해하는" 방식이 안 통합니다. 이건 실제로 많이 쓰이던 방식이라 적응이 필요합니다.

다만 작게 나누면 완화됩니다. 마이크로 스프린트 하나는 애초에 이해하기 쉬운 크기입니다. 큰 기능을 한 번에 명세하려니 어려운 것입니다.

실무에서 시작하는 법

전면 도입 전에 이렇게 연습할 수 있습니다.

3번에서 막히는 경험이 중요합니다. 대부분 처음에는 "이걸로는 완료를 판정할 수 없다"는 걸 발견합니다. 그게 지금까지 얼마나 애매하게 시작했는지를 보여줍니다.

자주 하는 오해

"TDD랑 같은 거 아닌가?"

비슷하지만 다릅니다.

TDD의 습관이 있으면 IntentOps로 넘어가기 쉽습니다.

"명세를 그렇게 자세히 쓰면 코드 쓰는 것보다 오래 걸리지 않나?"

한 번은 그럴 수 있습니다. 그런데 그 명세는 재사용됩니다 — 재생성할 때, 비슷한 기능을 만들 때, 나중에 왜 이렇게 만들었는지 확인할 때.

코드는 한 번 쓰면 그 코드로 끝이지만, 의도는 계속 살아 있습니다.

확인

1. IntentOps에서 개발자가 책임지는 두 가지는?

2. "코드는 일시적"이라는 말이 성립하려면 무엇이 전제되어야 합니까?

3. IntentOps에서 무엇이 더 어려워집니까?

코드가 파생물이 되면 레거시의 정의도 바뀝니다 → 유동적 소프트웨어