|| 표준 위에 얹는 시맨틱 레이어사람과 여러 AI가 같은 코드를 다루는 시대에, ‘우리 조직만의 도메인 지식’을 모든 에이전트가 함께 읽게 만드는 법. 표준 기반 Core와 조직 특화 Overlay로 이뤄진 2층 시맨틱 레이어를 만들고, 그게 언제 통하고 언제 위험한지 150개 질문으로 비교해본 이야기.자신만만하게 틀리는 AI
낯선 레거시 코드 한 조각을 AI에게 던져본 적 있으신가요. “이 엔티티, 업무적으로 뭐야?”
돌아온 답은 대개 이렇습니다. 큰 틀은 맞고, 우리 조직 이야기로 들어가면 무너집니다.
“재고를 관리하는 도메인이군요.” 여기까진 잘합니다. 그 도메인의 산업 표준을 이미 학습했으니까요.
“이 상태값은 이럴 때 이렇게 넘어갑니다.” 우리 조직만의 규칙에 들어서는 순간 자신만만하게 틀린 답이 나옵니다.
많은 산업 도메인에는 전 세계적으로 표준화된 비즈니스 모델이 있습니다. 물류와 회계, 결제, 제조에는 국제 표준이 잘 정의돼 있고 LLM은 그 표준을 압니다. 문제는 실제 회사 시스템이 “표준 모델 + 그 위에 얹힌 우리만의 특수 프로세스”라는 데 있습니다. AI가 아는 건 앞의 절반뿐입니다.
이 글은 그 나머지 절반을 AI에게 이해시킨 이야기입니다. 그게 언제 도움이 되고 언제 오히려 독이 되는지 점검한 기록이기도 합니다.
혼자 챗봇에 묻던 시절이라면 개인 팁으로 끝났을 겁니다. 지금은 코드 리뷰 봇, 운영 지원 에이전트, IDE 코파일럿까지 여러 AI가 사람과 나란히 같은 코드를 만집니다. AI가 하나면 사수가 옆에서 알려주면 됩니다. 여럿이면 각자에게 도메인을 따로 가르치는 방식으로는 감당이 안 됩니다. 모두가 함께 읽는 공용 지식 하나가 필요합니다.
전제가 하나 있습니다. 이 방법은 아무 도메인에나 통하지 않습니다. 산업 표준이 존재하는 도메인에 한합니다. 출발점이자 한계입니다.
지도와 골목 주석: 두 개의 층
시맨틱 레이어는 AI가 읽는 도메인 사전입니다. 모델도 아니고 DB도 아닙니다. 낯선 코드나 테이블, 로그, 에러를 만났을 때 “이게 업무적으로 뭔가”를 통역해주는 나침반입니다. 이걸 두 층으로 쪼갠 게 핵심입니다.
Core (범용): 산업 표준에 기반해 어느 회사에나 통용되는 층입니다. 국제 도메인 표준이 근거이고 거의 바뀌지 않습니다.
Overlay (조직): 우리만의 프로세스와 규칙, 예외를 담는 층입니다. 근거는 실무에서 축적된 도메인 지식이고 자주 바뀝니다.
규칙은 하나뿐입니다. Overlay는 Core를 고치지 않고 ID로 참조만 합니다.
표준 세계 지도(Core) 위에 우리 동네 골목 주석(Overlay)을 얹는 셈입니다. 지도는 전 세계 공통이라 누구나 읽고, 골목 사정은 우리만 압니다. AI는 골목 주석을 만나면 참조 링크를 따라 표준 지도까지 함께 펼쳐 답합니다. “이건 우리 고유의 X 처리인데, 표준으로는 Y에 해당해요.”
이 분리가 주는 이점이 셋입니다. 표준인 Core는 다른 팀에도 그대로 재사용됩니다. 자주 바뀌는 건 Overlay뿐이라 유지보수가 가볍습니다. “이건 표준 근거, 이건 조직 특화”가 늘 또렷하게 남습니다. 다만 뒤에서 다시 말하겠지만 이 세 가지는 아직 실측이 아니라 설계 의도입니다.
그래서 실제로 어떻게 생겼나
추상적으로 들릴 수 있으니 형태를 밝히면 이렇습니다. Core와 Overlay는 둘 다 사람이 읽을 수 있으면서 AI도 쉽게 파싱하는 구조화 문서입니다. 각 개념은 문장 뭉치가 아니라 필드를 가진 항목입니다. 안정적인 ID, 설명, 관련 엔티티, 상태(state), 참조 관계를 갖습니다. Overlay의 각 항목은 relates_to 같은 필드로 자신이 대응하는 Core 개념을 명시적으로 가리킵니다. 산문이 아니라 연결된 개념 그래프인 셈입니다. 뒤에 나오는 "잘 쓴 문서와 뭐가 다른가"에 대한 답도 여기서 나옵니다.
어떻게 만들었나: 세 개의 기둥1. 표준을 Core로, 사실은 ‘표준 조각을 편집하는’ 일
여기서 솔직해야 할 대목이 있습니다. 이 도메인에 깔끔한 단일 국제 표준이 하나 있어서 그걸 가져다 쓴 게 아

