핵심 키워드: 바이브 코딩, AI 코딩, Architecture Invariant, AI 테스트, 소프트웨어 아키텍처, AI Engineering, SELMA
AI와 함께 개발하면 놀랄 만큼 빠르게 코드가 늘어납니다.
기능을 설명하면 Implementation을 만들고, 오류를 전달하면 수정합니다. 테스트가 부족하면 Test Case까지 작성합니다.
개인 프로젝트 SELMA를 개발하면서 저 역시 이런 방식으로 상당한 양의 코드를 만들었습니다.
처음에는 생산성이 높아진 만큼 테스트를 충분히 작성하면 안전하게 개발할 수 있다고 생각했습니다.
그런데 프로젝트가 커진 뒤 예상하지 못한 경험을 했습니다.
코드도 일관됐고 테스트도 모두 Green이었는데 Architecture가 틀려 있었습니다.
AI가 코드와 테스트를 함께 만들 때 생기는 문제
일반적으로 테스트는 Implementation의 오류를 발견하기 위해 사용합니다.
그런데 AI가 Implementation과 Test를 모두 만드는 Workflow에서는 조금 다른 문제가 발생할 수 있습니다.
예를 들어 AI가 시스템의 구조를 A라고 이해했다고 가정해보겠습니다.
그 가정을 바탕으로 코드를 만듭니다.
그리고 같은 Context에서 테스트도 작성합니다.
Implementation은 A를 따르고 테스트 역시 A를 기대하기 때문에 모든 Test가 Green이 될 수 있습니다.
하지만 실제 Architecture가 요구하는 것이 B라면 어떻게 될까요?
코드는 정상입니다.
테스트도 정상입니다.
둘이 함께 잘못된 것입니다.
SELMA를 개발하면서 실제로 비슷한 상황을 경험했습니다.
Branch 구조를 만들었는데 Runtime은 과거에 머물러 있었다
SELMA는 처음에 일반적인 Linear Conversation 방식으로 만들어졌습니다.
사용자가 질문하고 답을 받은 뒤 다음 질문을 이어가는 구조였습니다.
이후 분석을 과거 어느 지점에서든 다시 이어갈 수 있도록 Workspace → Analysis → Branch 구조로 변경했습니다.
UI도 Branch-aware로 변경했습니다.
Persistence Model도 Branch를 저장했습니다.
그런데 실제 사용 중 과거 Branch를 선택해 질문했을 때 가끔 다른 Context의 답이 나왔습니다.
조사해보니 일부 Semantic Runtime이 여전히 Session에서 시간상 가장 최근의 대화를 Context로 사용하고 있었습니다.
문제는 테스트였습니다.
기존 테스트 역시 대부분 질문을 순서대로 이어갔습니다.
따라서 Session Chronology를 사용하는 잘못된 Runtime과 Test Scenario가 정확하게 맞아떨어졌습니다.
결과는 계속 Green이었습니다.
그래서 테스트와 다른 질문을 시작했다
이 경험 이후 Repository를 보는 질문을 바꿨습니다.
기존에는 주로 이렇게 물었습니다.
“이 기능이 제대로 동작하는가?”
하지만 Architecture를 검증하려면 이것만으로 부족했습니다.
그래서 다음과 같이 질문하기 시작했습니다.
“이 시스템이 어떤 실행 경로에서도 절대로 깨뜨리면 안 되는 명제는 무엇인가?”
SELMA에서는 이런 명제를 Architecture Invariant로 정의했습니다.
대표적으로 다음과 같은 원칙입니다.
- Business Meaning은 Contract에서 온다.
- Permission Scope는 실제 SQL 실행까지 보존된다.
- Semantic Context는 Session Chronology가 아니라 선택된 Branch Lineage를 따른다.
- 하나의 Semantic Decision에는 하나의 Authority만 존재한다.
- LLM은 Authoritative SQL을 직접 결정하지 않는다.
- Analytical Claim은 Evidence보다 강할 수 없다.
이 원칙들은 특정 함수가 어떤 값을 반환해야 한다는 테스트와는 조금 다릅니다.
시스템 전체가 계속 지켜야 하는 약속입니다.
약 47K lines를 다시 보니 13개의 Finding이 나왔다
Invariant를 정의한 뒤 당시 약 47K lines 규모의 Repository를 다시 Audit했습니다.
결과는 예상보다 컸습니다.
총 13개의 Architecture Finding이 발견됐고, 당시 분류 기준으로 Critical 1개와 High 5개가 포함되어 있었습니다.
모든 것이 잘못됐다는 뜻은 아니었습니다.
오히려 일부 핵심 Architecture는 Clean으로 확인됐습니다.
문제는 새로운 Architecture로 Migration하면서 과거 방식이 일부 남아 있거나, 같은 의미를 Contract와 Fallback이 동시에 결정하는 것처럼 Authority가 중복된 부분이었습니다.
기능별 테스트만 볼 때는 쉽게 보이지 않았던 문제였습니다.
Green으로 만드는 것보다 Red가 되는지를 확인했다
여기서 검증 방식도 하나 더 바뀌었습니다.
결함을 발견하면 먼저 Acceptance Test를 작성해 현재 Architecture에서 Red가 되는지 확인했습니다.
그다음 코드를 수정해 Green으로 만듭니다.
보통이라면 여기서 작업이 끝날 수 있습니다.
SELMA에서는 한 단계를 더 진행했습니다.
수정한 Architecture를 일부러 다시 깨뜨렸습니다.
Session Chronology를 다시 Semantic Context로 사용하게 만들거나, Permission Scope를 SQL에서 제거하거나, 하나로 합친 Authority를 다시 두 개로 만들었습니다.
그리고 Test가 다시 Red가 되는지 확인했습니다.
제가 확인하고 싶었던 것은 단순히
“테스트가 통과하는가?”
가 아니었습니다.
“우리가 지키려는 원칙을 깨뜨렸을 때 이 테스트가 정말 실패하는가?”
였습니다.
이른바 break-to-red 방식입니다.
테스트가 Green이라는 사실보다 올바른 이유로 Red가 될 수 있다는 것이 더 중요한 경우가 있었습니다.
Tests와 Invariants는 경쟁 관계가 아니다
Architecture Invariant가 필요하다고 해서 일반적인 테스트가 중요하지 않다는 의미는 아닙니다.
Unit Test, Integration Test, E2E Test는 모두 필요합니다.
다만 검증하는 대상이 다릅니다.
저는 SELMA를 개발하면서 둘의 차이를 이렇게 정리하게 됐습니다.
Tests validate examples.
Invariants validate the system.
Test는 우리가 생각한 Scenario에서 올바르게 동작하는지 확인합니다.
Invariant는 우리가 미처 생각하지 못한 실행 경로에서도 시스템의 약속이 깨질 수 있는지 묻습니다.
AI가 코드를 빠르게 생성할수록 두 검증은 오히려 함께 중요해질 수 있습니다.
Vibe Coding의 다음 문제는 Confidence일 수 있다
바이브 코딩을 사용하면 Implementation 비용은 크게 줄어듭니다.
하지만 하루 동안 만들 수 있는 코드가 많아진다는 것은 하루 동안 만들어질 수 있는 Architecture Decision 역시 많아진다는 의미입니다.
AI가 작성한 수만 줄의 시스템을 운영하려면 결국 질문은 코드 생성 속도에서 다른 곳으로 이동합니다.
“이 시스템을 무엇을 근거로 신뢰할 것인가?”
저는 AI 코딩의 다음 병목이 Implementation이 아니라 Confidence가 될 가능성이 있다고 생각합니다.
그리고 Architecture Invariant는 그 Confidence를 만드는 방법 중 하나였습니다.
빠르게 만드는 것과 믿을 수 있게 만드는 것은 같은 문제가 아니었습니다.
AI가 Implementation을 더 빠르게 만들수록, 시스템이 절대로 깨뜨려서는 안 되는 것을 먼저 정의하는 일이 오히려 더 중요해질 수 있습니다.
다음 Engineering Notes 2편에서는 이 Invariant를 실제 Repository에 적용하면서 경험했던 이야기를 이어가겠습니다.
“AI 코딩은 빨랐지만 검증은 오래 걸렸다.”
SELMA를 약 일주일 동안 Architecture Hardening하면서 왜 하나를 고칠 때마다 또 다른 문제가 나타났는지, 그리고 AI 리팩토링의 실제 병목이 어디에 있었는지 정리해보겠습니다.
#바이브코딩 #AI코딩 #ArchitectureInvariant #AI테스트 #AIEngineering #소프트웨어아키텍처 #AI코드검증 #EnterpriseAI #리팩토링 #생성형AI #개발자 #SELMA