핵심 키워드: AI 코드 검증, Architecture Hardening, 바이브 코딩, AI 리팩토링, Enterprise AI, 소프트웨어 아키텍처, SELMA
앞선 글에서는 SELMA의 테스트가 모두 Green이었는데도 Architecture가 잘못되어 있었던 경험과, 이를 발견하기 위해 Architecture Invariant를 정의한 과정을 이야기했습니다.
Invariant를 만들고 Repository Audit까지 마쳤으니 처음에는 남은 일이 단순하다고 생각했습니다.
발견된 문제를 AI에게 수정하게 하고 테스트를 돌립니다.
Green이면 다음 Finding으로 넘어갑니다.
AI가 코드를 빠르게 작성하니 며칠이면 충분할 것 같았습니다.
그런데 실제 작업은 예상과 완전히 달랐습니다.
Architecture를 하나의 원칙으로 수렴시키는 데 약 7일이 걸렸습니다.
더 흥미로운 점은 이 과정에서 코드 작성뿐 아니라 검증에도 AI를 적극적으로 사용했다는 것입니다.
하나를 고치면 또 하나가 나타났다
가장 반복적으로 나타났던 패턴이 있었습니다.
SELMA에는 과거 Architecture에서 만들어진 여러 fallback과 보완 코드가 남아 있었습니다.
예를 들어 Contract에서 Metric을 찾지 못하면 이름으로 추측하거나, 이전 답변의 문장을 다시 분석해 Context를 복원하는 식입니다.
Architecture Invariant 관점에서는 이런 코드가 두 번째 Semantic Authority가 될 수 있었습니다.
그래서 제거했습니다.
그런데 기능이 깨졌습니다.
처음에는 제거가 잘못됐다고 생각할 수 있습니다.
하지만 더 깊게 조사해보니 상황이 달랐습니다.
fallback이 필요했던 것이 아니라, fallback이 Architecture의 미완성 부분을 가리고 있었습니다.
답변 문장을 다시 분석하는 코드를 없애자 실제 Execution이 자신의 결과를 Lineage에 충분히 남기지 않는 문제가 드러났습니다.
Metric 이름을 추측하는 fallback을 제거하자 Contract 자체에 Metric의 역할을 표현할 방법이 부족한 경우도 나타났습니다.
“불필요한 코드”를 지웠다가 기능이 사라지기도 했다
AI는 Repository 전체를 검색해 호출처가 없는 함수나 중복 코드를 매우 빠르게 찾아낼 수 있습니다.
실제로 SELMA에서도 여러 Dead Code 후보가 발견됐습니다.
그런데 이 과정에서 한 번은 호출처가 없는 Tool Wrapper들을 제거했다가 Planner의 Tool이 통째로 사라지는 문제가 발생했습니다.
원인은 Dynamic Registry였습니다.
소스코드에서 함수를 직접 호출하는 것이 아니라 설정 파일의 이름과 globals()를 이용해 Runtime에서 함수를 찾아 등록하는 구조였습니다.
일반적인 Call Site 검색에서는 호출처가 0개였습니다.
하지만 실제로는 살아 있는 코드였습니다.
즉,
No caller ≠ Dead code
였습니다.
AI가 빠르게 코드를 지울 수 있다는 것과 그 코드를 지워도 된다는 것을 증명하는 것은 완전히 다른 문제였습니다.
Red → Green에서 끝내지 않았다
이런 경험 이후 수정 절차도 점점 엄격해졌습니다.
먼저 결함을 재현했습니다.
그다음 해당 결함을 잡는 Acceptance Test를 만들고 Red 상태를 확인했습니다.
Architecture를 수정해 Green으로 만듭니다.
하지만 여기서 끝내지 않았습니다.
일부러 이전의 잘못된 구현을 다시 복원했습니다.
테스트가 정말 다시 Red가 되는지 확인하기 위해서였습니다.
예를 들어,
- Session Chronology가 Branch Lineage를 다시 이기게 만들기
- Permission Scope를 SQL에서 제거하기
- 하나로 합친 Semantic Authority를 다시 둘로 만들기
- 제거한 fallback을 다시 복원하기
같은 방식으로 의도적으로 Architecture를 깨뜨렸습니다.
테스트가 정확한 이유로 실패해야 비로소 해당 Invariant를 보호하는 Acceptance라고 판단했습니다.
AI가 검증하면 더 빨리 끝날 줄 알았다
이번 Architecture Hardening에서 흥미로운 점은 대부분의 조사와 검증 역시 AI와 함께했다는 것입니다.
AI가 Repository를 검색했습니다.
원인을 추적했습니다.
Acceptance Test를 작성했습니다.
수정 코드를 만들었습니다.
Regression Suite를 실행하고 결과를 다시 분석했습니다.
사람이 직접 모든 코드를 작성하고 조사하는 것보다 분명 빨랐습니다.
그런데도 전체 작업에는 약 일주일이 필요했습니다.
왜 그랬을까요?
코드 한 줄을 수정하는 것은 빨랐지만,
“이제 정말 하나의 Architecture로 수렴했는가?”
를 확인하는 일이 훨씬 어려웠기 때문입니다.
하나의 보상 경로를 제거하면 숨겨진 미완성이 나타났고, 그것을 수정하면 다른 고객 데이터에서 새로운 경계 조건이 발견됐습니다.
단순한 Code Generation 문제가 아니었습니다.
실제 고객과 다른 데이터 구조가 Architecture를 시험했다
SELMA에서는 하나의 데모 데이터만 사용하지 않았습니다.
소매 형태의 데이터뿐 아니라 제약 CRM과 고객 케어처럼 구조가 다른 데이터도 연결해 검증했습니다.
이 과정에서 특정 고객 데이터에서는 권한 컬럼이 기본 테이블에 있었지만, 다른 데이터에서는 여러 JOIN을 거쳐야 하는 경우가 발견됐습니다.
한 데이터셋에서는 완벽하게 동작하던 코드가 다른 구조에서는 존재하지 않는 SQL Alias를 참조하며 실패했습니다.
처음에는 SQL 오류처럼 보였습니다.
하지만 근본 원인은 Permission이라는 Semantic Meaning을 물리적인 SQL 철자가 대신하고 있었던 것이었습니다.
결국 문제 하나를 패치하는 대신 Scope를 Semantic Contract로 끌어올리고, 각 Query가 자신의 SQL 구조 안에서 Binding하도록 Architecture를 변경했습니다.
이런 결정 때문에 Hardening은 단순 리팩토링보다 훨씬 길어졌습니다.
AI 코딩의 새로운 병목은 Confidence일 수 있다
이번 7일을 경험하면서 바이브 코딩에 대한 생각도 조금 달라졌습니다.
AI가 Implementation 비용을 크게 낮춰주는 것은 분명합니다.
하지만 코드 생성 비용이 낮아진다고 신뢰를 만드는 비용까지 같은 비율로 낮아지는 것은 아니었습니다.
오히려 AI가 하루 동안 훨씬 많은 코드를 만들 수 있기 때문에 검증해야 할 시스템도 더 빠르게 커질 수 있습니다.
그래서 지금은 AI 코딩 시대의 병목이 이렇게 이동할 가능성이 있다고 생각합니다.
Implementation → Verification → Confidence
얼마나 빨리 만들 수 있는가만큼,
얼마나 빨리 “이제 믿고 다음 단계로 넘어가도 된다”는 근거를 만들 수 있는가가 중요해지는 것입니다.
SELMA에서는 결국 Critical과 High Finding, Architecture Invariant, Regression, break-to-red, 반복 안정성 등을 확인하는 Exit Gate까지 만들어 Hardening의 종료 조건을 정했습니다.
AI에게 계속 “더 고칠 것이 있니?”라고 묻는다면 개선할 부분은 끝없이 나올 수 있기 때문입니다.
AI는 코드를 매우 빠르게 만들었다.
하지만 Architecture는 여전히 수렴해야 했다.
이것이 지난 7일간 SELMA를 리팩토링하면서 얻은 가장 큰 경험 중 하나였습니다.
그런데 더 재미있는 일은 Architecture Hardening을 완료했다고 판단한 이후에 일어났습니다.
테스트도 통과했고 주요 Invariant도 Clean이었습니다.
그리고 처음으로 개발자가 아니라 평범한 사용자처럼 SELMA 사이트에 접속해 질문을 던졌습니다.
첫 질문부터 새로운 문제가 발견됐습니다.
다음 10편에서는 “테스트는 모두 Green인데 Architecture는 틀렸다”에서 한 단계 더 나아가, 하나의 Source of Truth를 만들기 위해 어떤 문제들을 제거했는지 SELMA의 실제 Architecture Convergence 과정을 중심으로 살펴보겠습니다.
#AI코드검증 #ArchitectureHardening #바이브코딩 #AI리팩토링 #AI코딩 #소프트웨어아키텍처 #ArchitectureInvariant #AI테스트 #EnterpriseAI #AIEngineering #개발자 #SELMA