핵심 키워드: Source of Truth, Enterprise AI, AI 아키텍처, AI 테스트, 소프트웨어 아키텍처, Semantic Authority, SELMA
앞선 글에서는 SELMA의 Architecture Invariant를 기준으로 Repository를 다시 검증하면서 약 7일간 Architecture Hardening을 진행한 이야기를 했습니다.
그 과정에서 반복해서 등장한 문제가 하나 있었습니다.
코드가 틀린 것도 아니고 테스트가 실패하는 것도 아니었습니다.
문제는 같은 질문에 답하는 기준이 시스템 안에 두 개 이상 존재한다는 것이었습니다.
예를 들어 Business Meaning은 Contract가 결정한다고 했지만 Runtime에도 이름을 보고 의미를 추측하는 코드가 남아 있었습니다.
대화 Context는 Branch Lineage를 따라야 했지만 Session Memory에도 비슷한 정보가 있었습니다.
처음에는 모두 같은 값을 가리켰습니다.
그래서 테스트도 통과했습니다.
하지만 두 기준 중 하나만 달라지는 순간 문제가 시작됐습니다.
Source of Truth가 두 개면 왜 위험할까?
간단한 예를 들어보겠습니다.
기업에서 매출이라는 Metric을 Contract에 정의했다고 가정해보겠습니다.
그런데 과거 코드에는 sales, revenue, 매출 같은 문자열을 보고 Metric을 추측하는 fallback도 남아 있습니다.
오늘은 두 코드가 모두 revenue를 선택합니다.
문제가 없어 보입니다.
하지만 Contract가 변경되거나 새로운 고객이 rx_amount, lost_monthly_fee처럼 완전히 다른 업무 지표를 사용한다면 어떻게 될까요?
한쪽은 Contract를 따르고 다른 쪽은 이름을 추측합니다.
그 순간부터 같은 질문이 어떤 실행 경로를 지나느냐에 따라 다른 의미를 가질 수 있습니다.
그래서 SELMA에서는 단순한 코드 중복보다 Duplicated Authority를 더 위험하게 보기 시작했습니다.
실제로 Clarification에서도 같은 문제가 있었다
사용자의 질문이 모호하면 SELMA는 되묻기를 합니다.
예를 들어 어떤 지표를 의미하는지 여러 후보가 있다면 선택지를 보여줄 수 있습니다.
서버는 이미 각 선택지에 안정적인 Key를 가지고 있었습니다.
그런데 UI는 사용자에게 보여준 Label 문자열만 다시 서버로 보내고 있었습니다.
즉 이런 구조였습니다.
서버가 안정 Key를 결정 → Label 표시 → 사용자가 선택 → Label을 새 자연어 질문처럼 다시 전송 → 서버가 다시 해석
매출처럼 Label 자체가 자연어 별칭과 같으면 우연히 정상 동작합니다.
하지만 10%, 특정 구성원 이름처럼 다시 해석되지 않는 값에서는 시스템이 자기가 방금 물어본 질문의 답을 이해하지 못하는 상황이 발생했습니다.
문제의 본질은 파싱 성능이 아니었습니다.
이미 만들어 놓은 정체성을 버리고 자연어를 두 번째 Authority로 사용한 것이 문제였습니다.
Label은 Identity가 아니다
이를 수정하면서 Clarification Contract를 다시 만들었습니다.
사용자에게는 사람이 이해할 수 있는 Label을 보여줍니다.
하지만 사용자가 선택했을 때 서버로 돌아가는 것은 Label이 아니라 어느 질문의 어느 선택지를 골랐는지 나타내는 Stable Identity입니다.
쉽게 표현하면 다음과 같습니다.
표시: 품목별로
실제 회신: clarificationId + optionId
사용자에게 보여주는 이름과 시스템이 사용하는 정체성을 분리한 것입니다.
이후 SELMA에는 다음 원칙이 더 명확해졌습니다.
Stable identity is never a display label.
화면에 표시되는 이름은 바뀔 수 있습니다.
언어에 따라 달라질 수도 있습니다.
하지만 시스템 내부에서 의미를 연결하는 Identity까지 같이 흔들려서는 안 됩니다.
Session의 최신 상태도 두 번째 Authority가 될 수 있었다
더 흥미로운 사례는 두 개의 브라우저 탭을 동시에 사용했을 때 나타났습니다.
각 탭에서 서로 다른 질문을 하다가 한쪽에서 과거 Clarification에 답하면, Session에 저장된 가장 최근 Clarification 상태가 다른 탭의 질문을 가리키는 경우가 있었습니다.
사용자가 A라는 질문에 답했는데 Runtime 일부가 Session 최신 상태인 B를 참고한 것입니다.
숫자는 실제 데이터였습니다.
하지만 다른 질문의 답이 만들어질 수 있었습니다.
이 문제 역시 결국 같은 원인이었습니다.
메시지에 연결된 Clarification과 Session 최신 상태가 동시에 의미를 결정하고 있었습니다.
그래서 구조화된 Reply가 존재하면 그 Reply가 지목한 질문의 Contract가 Authority가 되도록 변경했습니다.
Fallback은 언제 기술부채가 될까?
Fallback 자체가 나쁜 것은 아닙니다.
시스템 장애 시 대체 경로를 제공하거나 사용자 경험을 개선하는 데 필요할 수 있습니다.
하지만 SELMA를 개발하면서 구분하게 된 것이 있습니다.
Fallback이 정본이 결정해야 할 의미를 다시 판단하기 시작하면 두 번째 Authority가 됩니다.
예를 들어 Contract에서 Metric을 찾지 못했는데 Runtime이 이름을 보고 대신 고릅니다.
Branch Lineage에 Context가 없는데 Session의 최근 대화에서 추측합니다.
Stable Key가 있는데 Label을 다시 자연어로 해석합니다.
처음에는 사용자를 도와주는 보완 기능처럼 보입니다.
하지만 시간이 지나면 어떤 답이 정본에서 나왔고 어떤 답이 fallback의 추측에서 나왔는지 구분하기 어려워집니다.
그래서 SELMA Architecture에서 중요하게 자리 잡은 원칙이 이것입니다.
One semantic decision, one authority.
하나의 의미를 결정하는 곳은 하나여야 합니다.
Architecture Convergence는 코드를 하나로 만드는 일이 아니었다
Source of Truth를 하나로 만든다는 것을 처음에는 중복 함수를 합치는 리팩토링 정도로 생각할 수도 있습니다.
실제로는 조금 달랐습니다.
중요한 것은 코드가 몇 개냐가 아니었습니다.
같은 사실을 판단하는 권한이 몇 군데 존재하느냐였습니다.
두 함수가 존재하더라도 하나의 Contract를 읽는다면 문제가 아닐 수 있습니다.
반대로 함수 하나 안에서도 Contract와 이름 기반 fallback이 각각 판단한다면 Authority는 두 개일 수 있습니다.
그래서 Architecture Convergence의 목표는 모든 코드를 하나로 합치는 것이 아니라,
“이 질문의 진실은 어디에서 결정되는가?”
에 하나의 답을 갖게 만드는 것이었습니다.
AI 시스템에서 Source of Truth가 중요한 이유
LLM 기반 시스템은 자연어를 다루기 때문에 어느 정도의 유연성과 추론이 필요합니다.
하지만 기업 데이터의 의미, 권한, Identity까지 모두 추론에 맡기면 시스템의 행동을 설명하기 어려워질 수 있습니다.
그래서 SELMA에서는 점점 역할을 분리하고 있습니다.
LLM은 해석합니다.
Contract는 의미를 선언합니다.
Lineage는 Context를 보존합니다.
Permission Scope는 읽을 수 있는 범위를 결정합니다.
Runtime은 그 선언을 실행합니다.
각자가 자기 역할을 가지고 같은 의미를 두 번 결정하지 않는 구조입니다.
그리고 이 구조가 어느 정도 정리된 뒤 SELMA의 Alpha Architecture Hardening을 완료할 수 있었습니다.
그런데 바로 다음 단계에서 예상하지 못했던 일이 일어났습니다.
Architecture Audit도 통과했고 주요 Acceptance Test도 모두 Green인 상태에서 실제 사이트를 열어 평범한 사용자처럼 질문했습니다.
“올해 8월 매출 분석해줘.”
SELMA는 정확한 매출 숫자를 답했습니다.
하지만 분석은 하지 않았습니다.
다음 11편에서는 이 한 문장이 왜 수많은 테스트가 발견하지 못한 새로운 문제를 드러냈는지, 그리고 SELMA에 Human Acceptance Test가 필요하다고 생각하게 된 과정을 정리해보겠습니다.
#SourceOfTruth #EnterpriseAI #AI아키텍처 #SemanticAuthority #AI테스트 #소프트웨어아키텍처 #ArchitectureInvariant #AI코딩 #바이브코딩 #데이터거버넌스 #AIEngineering #SELMA