grep

AI Native 조직은 도메인 지식을 어떻게 공유하는가

무신사

2026년 8월 25일

원문에서 보기 ↗

표준 위에 얹는 시맨틱 레이어

사람과 여러 AI가 같은 코드를 다루는 시대에, '우리 조직만의 도메인 지식'을 모든 에이전트가 함께 읽게 만드는 법. 표준 기반 Core와 조직 특화 Overlay로 이뤄진 2층 시맨틱 레이어를 만들고, 그게 언제 통하고 언제 위험한지 150개 질문으로 비교해본 이야기.

자신만만하게 틀리는 AI

낯선 레거시 코드 한 조각을 AI에게 던져본 적 있으신가요. "이 엔티티, 업무적으로 뭐야?"

돌아온 답은 대개 이렇습니다. 큰 틀은 맞고, 우리 조직 이야기로 들어가면 무너집니다.

많은 산업 도메인에는 전 세계적으로 표준화된 비즈니스 모델 이 있습니다. 물류와 회계, 결제, 제조에는 국제 표준이 잘 정의돼 있고 LLM은 그 표준을 압니다. 문제는 실제 회사 시스템이 "표준 모델 + 그 위에 얹힌 우리만의 특수 프로세스"라는 데 있습니다. AI가 아는 건 앞의 절반뿐입니다.

이 글은 그 나머지 절반을 AI에게 이해시킨 이야기입니다. 그게 언제 도움이 되고 언제 오히려 독이 되는지 점검한 기록이기도 합니다.

혼자 챗봇에 묻던 시절이라면 개인 팁으로 끝났을 겁니다. 지금은 코드 리뷰 봇, 운영 지원 에이전트, IDE 코파일럿까지 여러 AI가 사람과 나란 히 같은 코드를 만집니다. AI가 하나면 사수가 옆에서 알려주면 됩니다. 여럿이면 각자에게 도메인을 따로 가르치는 방식으로는 감당이 안 됩니다. 모두가 함께 읽는 공용 지식 하나가 필요합니다.

전제가 하나 있습니다. 이 방법은 아무 도메인에나 통하지 않습니다. 산업 표준이 존재하는 도메인에 한합니다. 출발점이자 한계입니다.

지도와 골목 주석: 두 개의 층

시맨틱 레이어는 AI가 읽는 도메인 사전입니다. 모델도 아니고 DB도 아닙니다. 낯선 코드나 테이블, 로그, 에러를 만났을 때 "이게 업무적으로 뭔가"를 통역해주는 나침반입니다. 이걸 두 층으로 쪼갠 게 핵심입니다.

규칙은 하나뿐입니다. Overlay는 Core를 고치지 않고 ID로 참조만 합니다.

표준 세계 지도(Core) 위에 우리 동네 골목 주석(Overlay)을 얹는 셈입니다. 지도는 전 세계 공통이라 누구나 읽고, 골목 사정은 우리만 압니다. AI는 골목 주석을 만나면 참조 링크를 따라 표준 지도까지 함께 펼쳐 답합니다. "이건 우리 고유의 X 처리인데, 표준으로는 Y에 해당해요."

이 분리가 주는 이점이 셋입니다. 표준인 Core는 다른 팀에도 그대로 재사용됩니다. 자주 바뀌는 건 Overlay뿐이라 유지보수가 가볍습니다. "이건 표준 근거, 이건 조직 특화"가 늘 또렷하게 남습니다. 다만 뒤에서 다시 말하겠지만 이 세 가지는 아직 실측이 아니라 설계 의도입니다.

그래서 실제로 어떻게 생겼나

추상적으로 들릴 수 있으니 형태를 밝히면 이렇습니다. Core와 Overlay는 둘 다 사람이 읽을 수 있으면서 AI도 쉽게 파싱하는 구조화 문서 입니다. 각 개념은 문장 뭉치가 아니라 필드를 가진 항목입니다. 안정적인 ID, 설명, 관련 엔티티, 상태(state), 참조 관계 를 갖습니다. Overlay의 각 항목은 relates_to 같은 필드로 자신이 대응하는 Core 개념을 명시적으로 가리킵니다. 산문이 아니라 연결된 개념 그래프인 셈입니다. 뒤에 나오는 "잘 쓴 문서와 뭐가 다른가"에 대한 답도 여기서 나옵니다.

어떻게 만들었나: 세 개의 기둥

1. 표준을 Core로, 사실은 '표준 조각을 편집하는' 일

여기서 솔직해야 할 대목이 있습니다. 이 도메인에 깔끔한 단일 국제 표준이 하나 있어서 그걸 가져다 쓴 게 아닙니다. 실제로는 식별 체계와 프로세스 참조 모델, 이벤트 표준 같은 조각들이 흩어져 있었습니다. 그걸 모아 서로 충돌하지 않게 정리하고 우리 도메인에 맞는 핵심 개념 집합으로 편집하는 데 이 프로젝트 작업량의 상당 부분이 들어갔습니다.

그래서 이 방법의 진입 장벽은 "표준이 존재하는가"가 아닙니다. **"흩어진 표준 조각을 우리 도메인의 Core로 정리할 수 있는가, 그 비용을 감당할 것인가"**입니다. 이 큐레이션을 거친 개념에 안정적인 ID(CORE-*)를 붙였습니다. 표준 기반이라 튼튼하고 거의 바뀌지 않습니다.

2. 조직 프로세스를 Overlay로

조직 고유의 규칙과 상태 전이, 예외를 Overlay로 옮기되 각 개념이 relates_to로 Core를 가리키게 했습니다. Overlay는 입고, 재고, 출고, 반품처럼 도메인별 섹션으로 나눴습니다. 정적 목차에 의존해 매번 전체를 읽게 하는 대신, 질문의 의미에 따라 관련 섹션을 골라 읽게 했습니다. 어떤 섹션이 맞는지는 질문 맥락으로 판단합니다.

3. 확신은 코드에서, 검증 루프

가장 값진 교훈이 여기서 나왔습니다.

시맨틱 레이어만 믿고 답하면 위험합니다(이유는 뒤에). 그래서 "지금 어떻게 처리하나", "이 로직이 맞나" 같은 질문에는 레이어가 가리키는 방향을 실제 코드베이스에서 검색해 검증하게 했습니다.

이 루프가 두 가지를 한 번에 잡습니다. Overlay의 지식 출처는 주로 운영과 문제 해결 과정에서 쌓인 경험 이라 정상 흐름은 얕고 예외는 진합니다. 코드 검색이 그 빈 곳을 메웁니다. 게다가 Overlay가 "이 개념 = 이 엔티티/파일"을 알려주니 코드 검색이 어디를 봐야 할지 바로 압니다. 시맨틱 레이어가 코드 검색을 더 빠르고 정확하게 만드는 셈입니다.

지식이 낡지 않도록, 축적된 지식이 바뀌면 해당 섹션을 감지해 후보를 자동 생성하고 검증과 사람 리뷰를 거쳐 승격하는 반자동 갱신 루프 를 뒀습니다. AI 생성물을 곧바로 반영하지 않는다는 게 핵심입니다. 검증되지 않은 자동 생성 지식이 잘못 반영될 수 있다는 걸 한 번 실감하고 세운 원칙입니다.

정말 도움이 될까: 150개 질문으로 비교해봤다

"좋아 보인다"로는 부족하죠. 그래서 정량으로 점검했습니다.

도메인 질문 150개를 만들어 같은 질문을 시맨틱 레이어를 켰을 때(ON)와 껐을 때(OFF) 두 조건에서 각각 실행 했습니다. 비교 지표는 기대 키워드 포함률(specificity), 표준 개념을 인용한 횟수(grounding), LLM judge 점수 셋입니다. 절대 점수의 높낮이가 아니라 레이어 유무가 만드는ON/OFF 차이만 보는 게 목적이었습니다.

judge는 왜 그대로일까요. 질문을 난이도별로 쪼개보니 답이 나왔습니다.

여기서 선을 하나 그어야 합니다. 이 실험이 증명하는 것은 "레이어의 존재가 답을 바꾼다 "까지입니다. 글 제목이기도 한 "2층으로 쪼갠 구조 자체가 최적이었나"는 증명하지 않습니다 . 같은 지식을 하나의 평평한 문서로 넣은 경우와 직접 비교(flat vs 2층)를 아직 하지 않았기 때문입니다. grounding이 크게 오른 것도 설계상 어느 정도 예정된 결과입니다. 표준 ID를 명시적으로 줬으니 인용이 늘죠. 그러니 2층 분리의 세 이점(재사용, 가벼운 유지보수, 근거 명료)은 지금으로선 실측이 아니라 운영 경험에 기댄 가설로 남습니다. flat 대조군 비교는 다음 과제입니다. 여기까지 선을 긋는 것이 이 실험의 결론입니다.

가장 값진 교훈: 나침반이지, 정답지가 아니다

이 프로젝트에서 제일 크게 배운 건 성과 그래프가 아니라한 번의 아찔한 오답이었습니다.

어떤 "예외 처리" 규칙을 물었을 때, 시맨틱 레이어만 믿었다면 실제와 정반대 로 답할 뻔했습니다. Overlay의 지식은 운영과 문제 해결 과정에서 나옵니다. 그러다 보니**"이건 막혀 있다"는 예외는 진하게 담기고, "실제론 다른 경로로 폭넓게 허용된다"는 정상 흐름은 얕게** 담깁니다. 규칙 몇 개를 전체 동작으로 착각하면 그럴듯하지만 위험하게 틀립니다.

그래서 원칙을 한 줄로 정의했습니다.

시맨틱 레이어는 나침반이지 정답지가 아니다. 방향은 레이어가 잡고, 현재 동작의 정답은 코드에서 확인한다.

질문 유형으로 나누면, "이 개념이 뭐야" 같은 해석·매핑 질문은 레이어 중심으로 답해도 됩니다. "지금 어떻게 처리하나 / 현황" 같은 현재 동작 질문은 코드 검증이 우선이고 레이어는 진입점입니다. "왜 안 돼" 같은 원인 분석은 레이어로 가설을 세우고 코드, 데이터로 검증합니다.

"그거 잘 쓴 온보딩 문서랑 뭐가 달라?"

정당한 반론입니다. 요즘 에이전트는 코드베이스 탐색을 잘하는데 잘 정리한 온보딩 문서 한 장과 뭐가 다르냐는 것이죠. 앞의 결과, 그러니까 현황 질문은 결국 코드 검증이 필요하다는 대목이 이 반론에 힘을 실어주기도 합니다.

답은 두 가지입니다.

첫째, 형태가 문서가 아니라 연결된 개념 그래프 입니다. 온보딩 문서는 사람이 읽고 해석하는 산문이지만, 이 레이어는 안정적인 ID와 상태, 참조 관계를 가진 구조라 여러 에이전트가 프로그램처럼 똑같이 소비합니다. "이 개념은 저 표준의 이것에 대응"이 링크로 걸려 있어 해석이 사람마다, 도구마다 갈리지 않습니다.

둘째, 레이어가 코드 검색의 진입점을 줍니다. "이 개념 = 이 엔티티/파일"을 알려주니 에이전트가 넓은 코드베이스를 헤매지 않고 어디를 볼지 바로 압니다. 온보딩 문서는 맥락을 주지만 검증 지점을 좌표로 찍어주진 않습니다. 이 레이어는 문서를 대체하기보다 코드 탐색을 더 빠르고 정확하게 만드는 좌표계에 가깝습니다.

이 레이어는 무엇에 특화됐나, 그리고 무엇이 아닌가

이 접근을 우리는 의미(해석) 레이어 로 특화했습니다. 정체성을 또렷이 하려면 무엇이 아닌지부터 말하는 게 빠릅니다.

대신 "이 코드, 테이블, 로그, 에러가 업무적으로 뭔가"를 통역하는 데 특화했습니다. 다섯 가지로 요약됩니다.

  1. 절차가 아니라 의미를 다루는 해석형이고,
  2. 국제표준 Core에 조직 Overlay를 얹은 표준 접지 2층이며,
  3. 산문이 아니라 기계 소비형 개념 ID 그래프입니다.
  4. A/B 정량과 "나침반이지 정답지 아니다"라는 측정 기준을 안에 넣었고,
  5. 쓸수록 다듬어지는 복리 지식입니다.

이 다섯이 함께일 때 시맨틱 레이어가 문서 모음을 넘어 AI가 우리 도메인을 이해하게 만드는 층이 됩니다.

AI Native 조직에서: 사전을 넘어 인프라로

여기서 관점을 한 번 뒤집어야 합니다. 시맨틱 레이어는 "AI를 위한 문서"가 아니라 "AI를 위한 API"에 가깝습니다. 사람이 읽는 위키는 사람이 해석해 씁니다. 하지만 이 레이어는 여러 에이전트가 프로그램처럼 똑같이 소비하는 공용 인터페이스입니다.

현재는 두 종류의 코딩 에이전트가 같은 레이어를 동일한 방식으로 읽도록 패키징했고, 개발과 평가 과정에서 실제로 둘 다 이 레이어를 근거로 답했습니다. 여러 AI가 하나의 근거를 공유한다는 가능성은 여기서 확인했습니다. 앞으로는 코드 리뷰 봇이나 운영 지원 에이전트처럼 더 다양한 소비자로 넓혀갈 수 있습니다.

그 방향이 중요한 이유는 이렇습니다. 첫째, 모든 AI가 같은 근거를 봅니다. 도구마다 도메인을 따로 가르치면 답이 제각각이 되지만, 공용 근거 하나를 두면 어떤 에이전트가 답하든 같은 Core/Overlay를 인용해 일관되게 해석합니다. 둘째, 지식이 복리로 쌓입니다. 운영에서 새 지식이 쌓이면 Overlay에 반영되고, 다음 답이 더 정확해지고, 더 신뢰받아 더 쓰입니다. 담당자에게만 남지 않고 조직 자산으로 불어나죠. 셋째, 답변을 넘어 '행동'을 준비합니다. 나침반 + 코드 검증 루프는, 에이전트가 뭔가 바꾸기 전에 현재 코드로 근거를 확인 하게 하는 최소 안전장치입니다. 넷째, 사람은 코드 작성자에서 '지식의 편집자'로 올라섭니다. 자동 생성물을 바로 반영하지 않고 사람이 승격하게 한 이유죠. 잘 다듬은 Overlay 한 줄이 수많은 AI 답변의 정확도를 동시에 끌어올립니다.

정리하면, 시맨틱 레이어는 한 사람의 생산성 도구가 아니라 조직의 AI 공용 그라운딩 인프라를 지향합니다. 사람과 여러 에이전트가 같은 표준·같은 조직 지식·같은 검증 규칙을 공유할 때, AI Native는 구호가 아니라 굴러가는 시스템에 가까워집니다.

나가며: 우리 팀에도 맞을까

한 번 자문해보세요.

Yes가 많을수록 이 2층 + 코드 검증 방식이 잘 맞습니다. 특히 두 번째(큐레이션 비용)와 마지막(코드 검증)이 관건입니다 --- 마지막이 No라면, 레이어는 나침반에서 멈추고 정답지가 되지 못합니다.

우리는 AI에게 도메인을 표준(Core) + 조직 특화(Overlay) 두 층으로 이해시키고, 그 답을 코드로 검증하는 길을 냈습니다. 비교해보니 표준 인용은 크게 늘었고(1.6→7.6), 어려운 질문일수록 진짜 값이 드러났으며(judge 5.8→6.4 역전), 동시에 "현황 질문은 코드로 확인해야 한다"는 경계도 숫자로 확인했습니다. 그리고 2층 구조 자체의 우월성은 아직 정직하게 "가설"로 남겨뒀습니다.

가장 하고 싶은 말은 이 한 문장입니다. 지식 주입은 강력하지만, 검증 없는 지식 주입은 그럴듯하게 틀립니다. 레이어를 나침반으로 쓰고 코드로 확신을 더할 때 AI는 비로소 우리 조직을 "안다"고 말할 수 있습니다.

그리고 AI Native로 갈수록 이 자산의 값은 커집니다. 도구는 계속 바뀌고 늘어나지만, **"우리 조직을 이해하는 하나의 공용 지식"**은 그 위에서 모든 AI가 공유하는 토대가 되니까요. 모델은 갈아끼워도, 도메인 이해는 조직에 남습니다.