아이디어는 좋았다. 경제성이 나빴다.
software engineering에는 읽는 순간 바로 맞는 말처럼 느껴지는 아이디어가 많습니다.
당연히 contracts는 function이 무엇을 받아들이고 무엇을 반환해야 하는지 정의해야 합니다. 당연히 tests는 몇 개의 예제만 보는 대신 properties를 검증해야 합니다. 당연히 팀은 coverage만 보고 안심할 게 아니라 tests가 실제로 faults를 잡는지 확인해야 합니다. 당연히 architecture decisions는 자신이 지배하는 code와 동기화되어야 합니다.
이 어느 것도 논쟁적인 주장은 아니었습니다. 문제는 경제성이었습니다. 이 전략들은 대부분의 팀이 가장 늘리기 어려운 자원, 즉 specialist attention을 많이 요구했습니다.
오랫동안 강한 engineering 전략들은 같은 사이클에 갇혀 있었습니다. 팀이 도입합니다. 품질이 올라갑니다. 그리고 maintenance cost가 찾아옵니다. contracts는 drift하고, property tests는 schema 변화에 뒤처지고, surviving mutants는 triage되지 않은 채 쌓이고, architecture docs는 현실과 멀어집니다. 전략이 실패한 이유는 틀려서가 아니었습니다. 일반적인 product team이 감당하기 어려운 수준의 지속적 expertise를 요구했기 때문입니다.
지금의 AI 순간이 중요한 이유가 여기에 있습니다. 중요한 변화는 model이 code를 더 빨리 쓸 수 있다는 것만이 아닙니다. 예전에는 너무 비쌌던 specification과 verification 노동의 상당 부분을 model이 흡수할 수 있게 되었다는 점입니다.
무엇이 이 전략들을 niche에 묶어 두었나
문제는 compute가 아니었습니다. 값싼 compute는 이미 오래전부터 있었습니다.
문제는 tooling만도 아니었습니다. 많은 분야에 좋은 tools는 있었습니다. 하지만 누군가는 여전히 올바른 invariants, generators, contracts, boundary rules를 써줄 수 있어야 했습니다.
진짜 bottleneck은 병렬화하기 어려운 expertise였습니다.
- Design by contract 는 refactor 이후에도 유효한 preconditions, postconditions, invariants를 쓰고 유지할 수 있는 engineers를 요구했습니다.
- Property-based testing 는 function을 보고 examples가 아니라 round trips, idempotence, error behavior, algebraic properties로 사고할 수 있는 사람을 요구했습니다.
- Mutation testing 는 survivors가 실제 gap인지 harmless equivalent mutants인지 분류할 수 있는 triage 능력을 요구했습니다.
- Type-level correctness 는 branded types, phantom types, typestates, 심지어 formal verification tooling에 대한 익숙함을 요구했습니다.
- Living specifications 는 인간의 결정을 실행 가능한 architecture rules로 계속 번역하는 작업을 요구했습니다.
각 전략마다 maintenance tax가 있었습니다. 여러 전략을 함께 쓰면 그 사이를 잇는 glue까지 필요해져 더 비싸졌습니다.
그래서 많은 “good on paper” 아이디어가 aerospace, finance, formal methods research, 혹은 매우 disciplined한 infrastructure teams 안에 머물렀습니다. 방법은 작동했습니다. staffing model이 작동하지 않았습니다.
AI가 바꾸는 것
AI는 engineering judgment를 없애지 않습니다. judgment를 쓰는 위치를 바꿉니다.
이전에는 senior engineer가 대부분의 scaffolding을 손으로 작성해야 했습니다. 지금은 model이 first draft contract를 만들고, properties를 제안하고, schema를 만들고, architecture rule을 초안하고, surviving mutant를 겨냥한 regression test 초안까지 만들 수 있습니다. 인간은 빈 화면에서 시작하는 대신 domain correctness를 review합니다.
이 변화는 생각보다 큽니다.
예전 workflow는 author-heavy였습니다. 이제 workflow는 review-heavy가 됩니다.
그 결과:
- contracts 도입 비용이 내려가고
- property-based testing이 훨씬 현실적이 되며
- mutation testing이 더 운영 가능해지고
- architecture constraints를 실제로 enforcement하기 쉬워집니다
이것이 진짜 경제적 unlock입니다. engineers를 model로 대체하는 것이 아니라, 과거에는 specialist authorship이 필요했던 전략을 일반적인 product team도 감당할 수 있게 만드는 것입니다.
중요한 통찰: 이 전략들은 함께 쓸 때 더 강하다
핵심 가치는 개별 technique 하나에 있지 않습니다.
흥미로운 변화는 AI가 stack 전체를 감당 가능하게 만든다는 점입니다.
contract는 property test의 입력이 될 수 있습니다. property test는 mutation testing으로 평가할 수 있습니다. schema는 runtime boundary를 정의할 수 있습니다. ADR은 architecture rule로 바뀔 수 있습니다. branded type은 runtime checks가 돌기 전에 surface area를 줄일 수 있습니다. 가치의 핵심은 각 조각 자체뿐 아니라 그 사이의 glue에 있습니다.
AI 이전에는 대부분의 팀이 이 전략 중 하나만 정당화하기도 어려웠습니다. AI 이후에는 여러 전략을 조합해도 reliability work가 specialist program이 되지 않습니다.
이건 마법이 아니다
물론 잘못된 방식도 있습니다.
AI가 code, contracts, tests를 생성하게 하면서 deterministic enforcement를 두지 않으면 그럴듯한 text 더미만 커집니다. 목표는 model이 codebase를 축복하게 만드는 것이 아닙니다. 목표는 model을 이용해 싸고 반복적으로 검증 가능한 artifacts를 만드는 것입니다.
그래서 결국 이기는 패턴은 여전히 단순합니다.
- AI로 generate하고
- deterministic tools로 validate하고
- specification level에서 review하고
- rule 위반은 CI에서 즉시 fail시키는 것
AI의 가치는 final judge가 되는 데 있지 않습니다. expertise gap을 메우는 데 있습니다.
왜 지금 중요한가
이미 많은 팀이 AI로 implementation time을 줄이고 있습니다. 문제는 delivery speed가 verification depth보다 더 빨리 커질 수 있다는 점입니다.
그렇게 되면 더 생산적인 engineering organization이 만들어지는 것이 아니라, fragile systems로 가는 속도만 빨라집니다.
기회는 generation을 가속하는 같은 models를 사용해, 역사적으로 너무 비쌌던 reliability practices를 다시 살리는 데 있습니다. 그래야 speed가 operational debt로 바뀌지 않습니다.
앞으로 몇 년은 이 차이를 빨리 이해한 팀에게 유리할 것입니다. AI-assisted coding만으로는 전략이 되지 않습니다. AI-assisted verification and enforcement가 전략입니다.
그래서 많은 오래된 engineering 아이디어가 다시 중요해집니다. 갑자기 더 옳아져서가 아니라, 이제야 경제적으로 실행 가능해졌기 때문입니다.