아이디어는 좋았다. 경제성이 나빴다.
소프트웨어 엔지니어링에는 읽는 순간 바로 맞는 말처럼 느껴지는 아이디어가 많습니다.
당연히 contracts는 function이 무엇을 받아들이고 무엇을 반환해야 하는지 정의해야 합니다. 당연히 tests는 몇 개의 예제만 보는 대신 properties를 검증해야 합니다. 당연히 팀은 coverage만 보고 안심할 게 아니라 tests가 실제로 faults를 잡는지 확인해야 합니다. 당연히 architecture decisions는 자신이 지배하는 code와 동기화되어야 합니다.
이 어느 것도 논쟁적인 주장은 아니었습니다. 문제는 경제성이었습니다. 이 전략들은 대부분의 팀이 가장 늘리기 어려운 자원, 즉 지속적인 전문가의 주의를 많이 요구했습니다.
오랫동안 강한 엔지니어링 전략들은 같은 사이클에 갇혀 있었습니다. 팀이 도입합니다. 품질이 올라갑니다. 그리고 유지보수 비용이 찾아옵니다. contracts는 drift하고, property tests는 schema 변화에 뒤처지고, surviving mutants는 triage되지 않은 채 쌓이고, architecture docs는 현실과 멀어집니다. 전략이 실패한 이유는 틀려서가 아니었습니다. 일반적인 프로덕트 팀이 감당하기 어려운 수준의 지속적 전문성을 요구했기 때문입니다.
지금의 AI 순간이 중요한 이유가 여기에 있습니다. 중요한 변화는 model이 code를 더 빨리 쓸 수 있다는 것만이 아닙니다. 예전에는 너무 비쌌던 specification과 verification 노동의 상당 부분을 model이 흡수할 수 있게 되었다는 점입니다.
무엇이 이 전략들을 틈새에 묶어 두었나
문제는 연산 자원이 아니었습니다. 값싼 연산 자원은 이미 오래전부터 있었습니다.
문제는 도구만도 아니었습니다. 많은 분야에 좋은 tools는 있었습니다. 하지만 누군가는 여전히 올바른 invariants, generators, contracts, boundary rules를 써줄 수 있어야 했습니다.
진짜 병목은 병렬화하기 어려운 전문성이었습니다.
- 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, 심지어 형식 검증 도구에 대한 익숙함을 요구했습니다.
- Living specifications 는 인간의 결정을 실행 가능한 architecture rules로 계속 번역하는 작업을 요구했습니다.
각 전략마다 유지보수세가 있었습니다. 여러 전략을 함께 쓰면 그 사이를 잇는 접착층까지 필요해져 더 비싸졌습니다.
그래서 많은 “서류상으로는 좋아 보이는” 아이디어가 항공우주, 금융, 형식 기법 연구, 혹은 매우 규율 잡힌 인프라 팀 안에 머물렀습니다. 방법은 작동했습니다. 인력 구조가 작동하지 않았습니다.
AI가 바꾸는 것
AI는 엔지니어링 판단을 없애지 않습니다. 판단을 쓰는 위치를 바꿉니다.
이전에는 시니어 엔지니어가 대부분의 발판 코드를 손으로 작성해야 했습니다. 지금은 model이 first draft contract를 만들고, properties를 제안하고, schema를 만들고, architecture rule을 초안하고, surviving mutant를 겨냥한 regression test 초안까지 만들 수 있습니다. 인간은 빈 화면에서 시작하는 대신 도메인 정확성을 review합니다.
이 변화는 생각보다 큽니다.
예전의 진행 방식은 작성 부담이 컸습니다. 이제는 검토 부담이 커집니다.
그 결과:
- contracts 도입 비용이 내려가고
- property-based testing이 훨씬 현실적이 되며
- mutation testing이 더 운영 가능해지고
- architecture constraints를 실제로 enforcement하기 쉬워집니다
이것이 진짜 경제적 돌파구입니다. engineers를 model로 대체하는 것이 아니라, 과거에는 전문가의 작성이 필요했던 전략을 일반적인 프로덕트 팀도 감당할 수 있게 만드는 것입니다.
중요한 통찰: 이 전략들은 함께 쓸 때 더 강하다
핵심 가치는 개별 technique 하나에 있지 않습니다.
흥미로운 변화는 AI가 stack 전체를 감당 가능하게 만든다는 점입니다.
contract는 property test의 입력이 될 수 있습니다. property test는 mutation testing으로 평가할 수 있습니다. schema는 runtime boundary를 정의할 수 있습니다. ADR은 architecture rule로 바뀔 수 있습니다. branded type은 runtime checks가 돌기 전에 surface area를 줄일 수 있습니다. 가치의 핵심은 각 조각 자체뿐 아니라 그 사이의 접착층에 있습니다.
AI 이전에는 대부분의 팀이 이 전략 중 하나만 정당화하기도 어려웠습니다. AI 이후에는 여러 전략을 조합해도 신뢰성 작업이 전문가 전용 프로그램이 되지 않습니다.
이건 마법이 아니다
물론 잘못된 방식도 있습니다.
AI가 code, contracts, tests를 생성하게 하면서 deterministic enforcement를 두지 않으면 그럴듯한 text 더미만 커집니다. 목표는 model이 codebase를 축복하게 만드는 것이 아닙니다. 목표는 model을 이용해 싸고 반복적으로 검증 가능한 artifacts를 만드는 것입니다.
그래서 결국 이기는 패턴은 여전히 단순합니다.
- AI로 generate하고
- deterministic tools로 validate하고
- specification level에서 review하고
- rule 위반은 CI에서 즉시 fail시키는 것
AI의 가치는 최종 판정자가 되는 데 있지 않습니다. 전문성의 공백을 메우는 데 있습니다.
왜 지금 중요한가
이미 많은 팀이 AI로 구현 시간을 줄이고 있습니다. 문제는 개발 속도가 검증 깊이보다 더 빨리 커질 수 있다는 점입니다.
그렇게 되면 더 생산적인 개발 조직이 만들어지는 것이 아니라, 취약한 시스템으로 가는 속도만 빨라집니다.
기회는 generation을 가속하는 같은 models를 사용해, 역사적으로 너무 비쌌던 신뢰성 실천을 다시 살리는 데 있습니다. 그래야 speed가 운영 부채로 바뀌지 않습니다.
앞으로 몇 년은 이 차이를 빨리 이해한 팀에게 유리할 것입니다. AI-assisted coding만으로는 전략이 되지 않습니다. AI-assisted verification and enforcement가 전략입니다.
그래서 많은 오래된 엔지니어링 아이디어가 다시 중요해집니다. 갑자기 더 옳아져서가 아니라, 이제야 경제적으로 실행 가능해졌기 때문입니다.