AI에 의존하지 않는 지식 구조의 외부화: 'AI 지식의 하드코딩'을 넘어, '생각하는 방식'을 생각하는 시민 개발자가 되는 설계론

생성형 AI나 로우코드 툴의 보급으로 현장 업무 개선(시민 개발)의 속도는 극적으로 빨라졌습니다. 하지만 그와 동시에 'AI에게 모든 것을 조작하게 하고, AI 안에 지식을 쌓아두면 언젠가 업무가 완전히 자동화될 수 있다'는 환상이 퍼지고 있습니다.

AI 내부(메모리 기능, 긴 채팅 기록, 블랙박스적인 자율 에이전트)에 업무 지식을 축적하는 것은 위험하며 미래성이 그리 높지 않습니다. 이는 소프트웨어 설계에서의 '하드코딩(매직 넘버를 직접 기입)'과 같습니다. 초기에는 빠르게 시작할 수 있지만, 반드시 '왜 AI가 이 판단을 했는지 알 수 없다', '규칙이 바뀌었는데 오래된 지식을 지울 수 없다'는 거대한 기술적 부채로 현장을 덮칩니다.

본 글에서는 AI 시대의 시민 개발자가 빠지기 쉬운 함정을 밝히고, '일부러 인간이 수동으로 개입하여 '차이점(Diff)'과 '이유(Why)'를 외부에서 관리하는 것'이 왜 압도적인 미래성을 가지는지, 실질적인 아키텍처와 함께 설명합니다.

AI가 '작업(How)'을 초고속으로 처리하게 되면서, 현장에서 업무 개선이나 시스템 구축에 관여하는 인간의 위치는 잔혹할 정도로 다음과 같은 3가지 레이어로 분리되고 있습니다.

우리가 시민 개발에서 추구해야 할 것은 명백히 '③ 생각하는 방식을 생각하는 계층'입니다.
AI에게 사고를 포기하고 전가하는 (①)도 아니고, 인간의 개인적인 노력에 가두는 (②)도 아닌, **'판단의 기준(생각하는 방식)을 어떻게 외부 구조로 결정화할 것인가'**를 설계하는 것이 앞으로 시민 개발의 핵심입니다.

'AI에게 과거 자료 전체를 읽게 해서 기억시키자', 'AI와의 채팅 기록을 그대로 지식으로 하자'는 접근은 언뜻 스마트해 보입니다. 하지만 이는 프로그램 코드 안에 업무 규칙이나 상수를 직접 흩뿌리는 하드코딩과 구조적으로 같은 문제를 안고 있습니다.

언러닝(망각 및 수정)이 불가능하다

일시적인 대응이나 모든 규칙을 무질서하게 기억시키지만, 불필요한 규칙이나 규칙 변경에 대처할 수 없습니다. 규칙이 바뀔 때 '과거의 그 판단 기준만 정확히 비활성화하는 것'이 극도로 어렵습니다. 오래된 맥락이 좀비처럼 AI의 추론을 오염시킵니다. -
'왜(Why)'에 대한 감사 흔적(Audit Trail)이 없다

엄격한 품질 관리나 심사가 요구되는 업무에서, '왜 A라는 표현을 B로 수정했는지'에 대한 근거는 생명선입니다. AI 내부의 블랙박스로 쌓인 지식에서는 사후적으로 명확한 이유를 끌어낼 수 없습니다. -
AI 모델에 대한 벤더 종속성(Vendor Lock-in)

특정 AI 도구나 모델 내부에 지식을 키워버리면, 그 AI 플랫폼의 수명이 다했을 때, 혹은 더 우수한 다른 모델로 갈아타고 싶을 때 업무 자산(지식)을 가지고 나올 수 없습니다.

이 문제를 해결하는 원칙은 간단합니다. AI에게 '상태(State=기억)'를 갖게 하는 것을 멈추고, **지식은 모두 외부의 SSoT(Single Source of Truth: 단일 정보원)**에 분리해야 합니다.

AI는 외부로부터 '이번 입력 데이터'와 '적용해야 할 판단 규칙 세트'를 받아, 추론 결과만을 반환하는 **스테이트리스한 순수 함수(pure function)**로 취급합니다. 이것이야말로 하드코딩에서 벗어나 설정이나 의존성을 외부에서 주입(DI: Dependency Injection)하는 모던한 설계 사상 그 자체입니다.

그렇다면, 외부 데이터베이스(시민 개발자의 경우 SharePoint Lists 등)에 무엇을 기록해야 할까요?

많은 사람이 저지르는 실수는 '완성된 최종본 문서(결과 = What)'만을 폴더에 쌓아두는 것입니다. 하지만 완성품만 아무리 살펴보아도, '왜 그 서술이 되었는지(어떤 NG 표현이 어떤 이유로 수정되었는지)'라는 판단 기준은 읽어낼 수 없습니다.

진정으로 재사용 가치가 있는 지식(Knowledge)이란, 심사나 리뷰 과정에서 발생하는 **'차이점(Diff)'**과 **'이유(Why)'**의 세트입니다.

예를 들어, 현장의 계획서나 절차서, 지시 기록 마스터 등을 작성하고, 품질 보증(QA)이나 상위자가 심사/검토하는 프로세스를 생각해 봅시다. 이때는 AI의 처리뿐만 아니라 인간의 처리라 하더라도 다음 5가지 요소를 1개 레코드로 SharePoint Lists에 기록합니다.

작성 시점의 미흡하거나 부적절한 서술 State_A

(변경 전): -
심사를 거쳐 수정된 올바른 서술 State_B

(변경 후): -
Reason_Why

(이유): 왜 A로는 안 되고 B로 해야 하는지 (원칙/근거) -
실제 수정 대응 범위 및 수평 전개 범위 Action_Taken

(대응): -
심사자에 의한 최종 확인 및 마감 기록 Verification

(확인):

문서의 심사 내용은 매우 다양하기 때문에, RDB(관계형 데이터베이스)처럼 딱딱하게 열을 정규화하면 입력이 고통스러워져 운영이 파탄 납니다. 그래서 SharePoint Lists를 '검색용 인덱스 열'과 '맥락을 유연하게 담는 NoSQL적 페이로드'의 하이브리드 형태로 설계합니다.

이 지식 기반을 운영하는 데 있어 극히 중요한 거버넌스가 쓰기(Write)와 읽기(Read) 권한 분리입니다.

• 심사/승인 측 (QA 등) = Write 권한:

판단의 오소리티(권위)를 가진 쪽만이 리스트에 [A→B, 이유]를 기록하고 확정합니다. 이를 통해 '무엇이 올바른 판단 기준인지'의 순도가 100% 유지되며, 현장의 임의 해석으로 인한 지식 오염을 방지합니다. -
작성/개발 측 (현장/AI) = Read-Only 권한:

계획서나 절차서를 작성하는 쪽은 이 리스트를 '읽기 전용 외부 계약(Contract)'처럼 참조합니다. 위변조 위험이 없기 때문에, 이 리스트 자체가 강력한 감사 추적 기록(Audit Trail)으로도 기능합니다. 다만 Action에 대해서는 현장이 추가할 수 있도록 하는 것이 좋을 것입니다.

이 외부화 아키텍처의 진가가 발휘되는 순간은 **'전제 규칙이 바뀐 때'**와 'AI에 의한 사전 체크' 상황입니다.

법 개정이나 사내 규정 업데이트로 과거의 판단 기준이 바뀌었다고 가정해 봅시다. AI 내부에 기억시키고 있었다면 절망적이지만, SharePoint Lists에 외부화되어 있다면 작업은 순식간입니다.

• 오래된 기준 레코드의 RuleStatus

을로 변경한다(이력으로 남기기 위해 삭제하지는 않는다). Superseded

(폐지) - 새로운 기준에 근거하여
[A→B, 이유]

의 레코드를 (레코드)로 1행 추가합니다. Active

(유효)

이것만으로도 과거의 경위(감사 추적)를 전혀 손상시키지 않으면서 조직의 지식 베이스가 최신 상태로 전환됩니다.

기획자가 새로운 계획서나 절차서 초안을 Word나 Excel로 작성했을 때, 심사에 넘기기 전에 AI로 셀프 리뷰를 수행합니다. 이때 AI에게 다음과 같이 지시합니다.

【AI에 대한 프롬프트 구조】

당신은 다음의 [심사 규칙 세트]

에 엄격하게 따르는 스테이트리스한 심사 엔진입니다.

SharePoint 목록에서 추출한 RuleStatus = Active

그리고 ProcessTag = 대상 공정

의 레코드 그룹(JSON/CSV)을 아래에 제공합니다.

이번의 [신규 초안]

안에, 과거의 State_A

(변경 전)과 유사한 기술이나, 혹은 Reason_Why

(이유) 원칙에 위배되는 부분이 없는지 검사하고, State_B

(변경 후)로의 수정안과 그 근거가 된 규칙 ID를 출력해 주세요.

이를 통해 AI는 환각(그럴듯한 거짓말)을 만들 여지를 빼앗기고, "조직이 공식적으로 승인한 최신 '이유(Why)'만을 근거로 초안을 검사하게 됩니다. 심사에 넘기기 전에 정형화된 지적 사항들이 모두 해소되므로, 반려에 따른 재작업 루프가 극적으로 감소합니다.

"AI에게 전부 맡기고 인간은 아무 생각 안 해도 된다"는 것은 달콤한 함정입니다. 그렇게 할수록 현장에는 누구도 유지보수할 수 없는 블랙박스 부채가 쌓이게 됩니다.

반면, "인간의 장인 기술로 계속 체크하는 것" 역시 한계가 있습니다.

AI 시대의 시민 개발자가 서야 할 곳은 그 어느 쪽도 아닙니다.

"인간이 어디에서 의사결정을 하고, 그 '차이점(Diff)'과 '이유(Why)'를 어떤 데이터 구조로 외부화해야 인간도 AI도 막힘없이 움직일 수 있을까"—이 '생각하는 방식(아키텍처)을 생각하는' 것이야말로 현장을 꿰뚫고 있는 시민 개발자만이 할 수 있는 최고의 엔지니어링입니다.

챗 화면 너머의 AI에게 기억을 맡기는 것은 이제 그만해야 합니다. 우리의 업무의 '이유'는 우리가 통제할 수 있는 외부 테이블에, 명확한 구조로 새겨 넣어야 하는 것입니다.