커뮤니티

소개

이번 작업은 대시보드 구축 교육 자료를 검토하는 데서 시작했습니다. 교육생이 화면을 만드는 과정을 넘어, 자신의 업무에서 어떤 문제를 풀어야 하는지 정의하고 필요한 AI Agent를 설계할 수 있도록 돕고 싶었습니다.

처음에는 가상 재고 자료로 문제 정의와 설계를 진행했습니다. 당시 선택한 목표는 ‘담당자의 재고 조사 시간 단축’이었고, 결과물은 ‘품목별 비교표와 조사 메모’였습니다. 하지만 다른 업무에서도 쓸 수 있도록 하려면 업무별 사례와 공통 방법론을 구분해야 했습니다.

그래서 범위를 기업 AX 진단 → 과제 선정 → 데이터 준비도 평가 → 지식 및 Agent 설계 → 실제 구축 → 검증과 개선으로 확장했습니다. 여기서 AX는 기업의 업무 방식을 AI와 함께 개선하는 과정으로 정의했습니다.

최종적으로 만들고자 한 것은 다음 세 가지입니다.

• 교육생과 기업 담당자가 문제 정의부터 따라갈 수 있는 공통 방법론
• Codex와 Claude Code에서 같은 절차를 실행할 수 있는 Skill
• 온톨로지, Wiki 및 원문을 연결해 근거를 찾고 검토 초안을 만드는 작은 Agent

방법론에는 운영 인계와 효과 측정까지 포함했습니다. 이번에 실제로 수행한 범위는 가상 자료를 이용한 진단, 설계, 로컬 구현 및 재검증까지입니다. 실제 기업에 배포하거나 업무 시간 절감 효과를 측정한 상태는 아닙니다.

진행 방법

1. 도구보다 먼저 문제와 성공 기준을 정했습니다

처음부터 모든 문제를 Agent로 해결한다고 정하지 않았습니다. 어떤 업무 결과를 바꿔야 하는지 확인하고, 대시보드, 일반 자동화, 검색, LLM 보조 및 Agent 중 적절한 수단을 비교하도록 했습니다.

문제 정의에서는 다음 질문을 중심으로 자료를 읽고 대화를 진행하도록 만들었습니다.

질문지는 기본 72개 질문을 담은 질문 은행으로 만들었습니다. 모든 질문을 한 번에 묻는 방식은 피하고, 자료에서 확인할 수 있는 답을 먼저 채운 뒤 필요한 질문을 골라 진행하도록 했습니다.

이때 실제로 사용한 요청 중 하나입니다.

진행해. 특정 업종에 맞추지 말고 기업 AX 진단부터 과제 선정, AI Agent 구축까지 활용할 수 있는 범용 방법론으로 확장해줘. 기업 진단 질문지, 과제 선정표, 데이터 준비도 평가표, Agent 설계서도 자세히 만들어줘.

2. 진단 결과가 다음 단계로 이어지도록 네 가지 양식을 연결했습니다

문서가 각각 따로 끝나면 앞에서 정의한 문제가 구축 과정에서 사라질 수 있습니다. 그래서 같은 목표, 문제, 과제 및 근거를 다음 단계에서도 추적하도록 했습니다.

과제 점수는 근거가 붙은 제안으로 사용했습니다. 자료가 없으면 미확인으로 남겼고, 점수가 높다는 이유로 데이터 접근이나 실행 권한 문제를 통과시키지 않도록 했습니다.

3. 온톨로지, LLM Wiki 및 Skill의 역할을 나눴습니다

업무 자료를 모아 놓는 것만으로는 ‘어떤 자료가 어떤 판단의 근거인지’가 명확해지지 않았습니다. 그래서 용어와 관계, 설명과 근거, 실행 절차를 나누어 연결했습니다.

전사 온톨로지를 먼저 완성하려 하지 않고, 선택한 질문에 답하는 데 필요한 개념부터 만들었습니다. 누리워크 앱에서는 요청, 규정, 근거, 충돌 및 검토 상태의 연결이 우선이었습니다. 별도 그래프 DB나 OWL 추론기를 도입하지 않고 JSON 관계와 코드 검사로 시작했습니다.

Wiki는 원문을 찾고 내용을 이해하는 길잡이로 사용했습니다. FAQ나 요약에 적혀 있다는 이유만으로 공식 규정과 같은 권위를 부여하지 않았습니다. 질문에 답할 때는 다시 원문과 적용 시점을 확인하도록 했습니다.

4. 방법론을 Codex 및 Claude Code용 스킬로 만들었습니다

초기 업무 실습은 build-work-agent로 진행했고, 기업 AX 범위로 확장한 진입점은 enterprise-ax로 정리했습니다. 스킬에는 진행 절차와 양식, 원문 인용 규칙, 사실, 추론 및 불확실성 구분, 역할 및 권한 구분, 결과 검증 절차를 포함했습니다.

Codex에서는 $enterprise-ax, Claude Code에서는 /enterprise-ax로 호출하도록 설치했습니다. 공통 방법론은 스킬에 두고, 기업별 원자료, Wiki 및 실행 결과는 별도 프로젝트에 저장했습니다.

실제 설치와 가상 기업 검증은 다음 요청으로 진행했습니다.

이제 이 방법론을 Codex와 Claude Code에서 바로 사용할 수 있는 skill로 설치하고, 가상 기업 사례로 AX 진단부터 과제 선정, 데이터 준비도 평가, Agent 설계까지 테스트해줘.

스킬 설치만으로 업무 시스템이 연결되는 것은 아니었습니다. 실제로 실행할 도구와 상태 저장, 오류 처리, 사람 검토 경계는 별도의 로컬 앱에서 구현했습니다.

5. 가상 기업 ‘누리워크’에서 과제를 선정했습니다

누리워크는 특정 업종에 속하지 않는 120명 규모의 가상 조직으로 설정했습니다. 기업 개요, 인터뷰, 규정의 현재판 및 이전판, FAQ, 요청 표본, 데이터 사전, 작업 로그를 준비했습니다. 회사, 인터뷰 및 업무 수치는 모두 합성 자료입니다.

가상 자료에 적용한 과제 선정 결과는 다음과 같았습니다.

선정한 과제는 ‘근거 조사 및 검토 초안 Agent’였습니다. 처음부터 업무 승인이나 외부 발송까지 맡기지 않고, 담당자가 검토할 근거표와 초안을 만드는 범위로 정했습니다. 설계 과제로 선정한 것과 실제 운영을 승인한 것도 구분했습니다.

데이터 준비도에서는 파일을 실제로 열어 중복, 결측, 날짜 및 규정의 적용 기간을 확인했습니다. 가상 작업 로그에는 중복과 결측이 있었고, 대기를 포함한 경과 시간도 있었습니다. 결측을 0으로 채우거나 경과 시간을 사람의 작업 시간과 합치지 않았습니다. 짧은 표본으로 연간 효과를 추정하지도 않았습니다.

6. 근거 조사부터 초안 저장까지 실제로 실행했습니다

설계를 마친 뒤에는 다음과 같이 요청했습니다.

이제 가상 기업 누리워크에서 선정한 근거 조사·검토 초안 Agent를 로컬에서 실제로 동작하게 만들고, 온톨로지와 Wiki를 연결해 가상 데이터로 테스트해줘.

로컬 앱의 처리 흐름은 아래와 같습니다.

요청과 기준일 입력
→ 온톨로지에서 관련 관계 탐색
→ Wiki 설명 조회
→ 적용할 규정과 원문 확인
→ 필수 근거 누락·자료 충돌 검사
→ LLM 검토 설명과 근거표 생성
→ 초안·실행 이력 저장
→ 사람의 검토

앱과 지식 파일, 실행 DB는 로컬에 두었습니다. LLM을 사용하는 모드에서는 Claude 서비스를 호출했습니다. 따라서 로컬 앱이라는 표현이 모델 추론까지 오프라인으로 수행했다는 뜻은 아닙니다. 규칙만으로 실행하는 모드와 실제 LLM 호출도 구분했습니다.

7. 누락 근거와 FAQ 충돌을 보완해 전후 상태를 비교했습니다

한 가상 요청에는 예외 처리에 필요한 근거가 빠져 있었고, FAQ와 규정 사이에 충돌도 있었습니다. 앱은 이를 정상 완료로 처리하지 않고 판단을 보류했습니다.

여기에 요청 근거 문서와 FAQ 해석 확인서를 가상 자료로 추가했습니다. 단순히 문서 제목이나 문자열이 있다는 이유로 인정하지 않고, 등록된 원문, 요청, 조직, 규정 및 유효 시점과 연결되는지 확인하도록 했습니다.

요청 근거만 추가하면 FAQ 충돌이 남았고, FAQ 확인서만 추가하면 요청 근거 누락이 남았습니다. 같은 코드 및 자료판에서 네 조합을 규칙 기반으로 비교했습니다. 실제 LLM으로 보완 후 초안을 다시 생성한 기록은 이 조합 시험과 별도로 남겼습니다.

보완 전후에는 앱 및 프롬프트 버전과 조회 기준일도 달라졌습니다. 그래서 답변 문체의 변화까지 전부 ‘자료를 추가한 효과’라고 해석하지 않았습니다. 확인할 수 있는 조건 변화와 통제되지 않은 차이를 나누어 기록했습니다.

8. 자료 변경이 어떤 답변에 영향을 주는지 추적했습니다

DEXA의 온톨로지 학습 자료와 AKM의 지식 관리 접근을 참고해 질문–주장–근거 연결표와 변경 영향 검사를 추가했습니다. 이 과정에서 채택한 내용은 기존 방법론과 실행 구조에 맞게 조정했습니다.

예를 들어 FAQ 해석 확인서가 바뀌면 다음 연결을 확인합니다.

원문 변경
→ 그 원문을 근거로 삼은 주장
→ 주장을 설명하는 Wiki
→ 영향을 받는 질문
→ 다시 검토할 답변과 초안

가상 FAQ 문구를 변경한 시험에서는 원문 해시와 인용 내용의 불일치가 발견됐습니다. 해시만 새 값으로 바꾸어도 기존 인용이 원문과 다르면 통과시키지 않았습니다. 당시 연결 범위에서는 관련 질문 2개와 Wiki 1편을 영향 대상으로 확인했습니다.

Windows에서 한글 및 공백 경로와 줄바꿈 차이도 검토했습니다. 정상 상대 경로를 위험 경로로 잘못 판단하는 경우를 보완했고, 검사기가 기존 원문과 실행 DB를 바꾸지 않는지도 확인했습니다.

9. 같은 사례를 두 도구에서 다시 실행하며 스킬을 개선했습니다

FAQ 사례만 반복하면 그 사례에 맞춘 규칙이 될 수 있어, 외부 자료 제공 및 인수인계 사례로 범위를 넓혔습니다. 이후에는 복귀, 재개 및 재승인을 다루는 가상 사례 9개를 만들어 같은 해나 같은 달 안의 사건 순서와 기간 경계를 확인했습니다. 개발에 사용한 뒤의 재시험은 알려진 사례에 대한 회귀 시험으로 기록했습니다.

반복해서 확인한 구분은 다음과 같습니다.

원문이 “3월에 재승인했다”고만 하면 날짜를 3월 1일로 만들지 않아야 합니다. ‘복귀’라는 말에서 이전 소재를 추론할 수 있더라도, 그것을 무조건 전년도 입주로 바꾸면 안 됩니다.

오류를 발견하면 원본 답안을 보존하고, 공통 규칙과 검증 절차를 개선한 뒤 두 도구의 설치본을 다시 맞췄습니다. 답변을 직접 고친 결과와 모델을 새로 실행해 얻은 결과를 섞지 않았습니다.

최근에는 참조 및 변경 분류와 함께 집계 오류도 보완했습니다. 한 실행에서는 실제 프레임 59개를 최종 응답에 61개로 보고한 문제가 있었습니다. 이를 계기로 저장된 결과에서 수치를 계산하고 최종 답변을 생성 및 재검증하는 도구를 추가했습니다.

결과와 배운 점

실제로 만들어진 것

이번 과정에서 기업 AX 방법론, 네 가지 상세 양식, Codex 및 Claude Code 공통 스킬, 누리워크 가상 자료, 로컬 Agent, 원문과 Wiki 연결, 변경 영향 검사, 실행 및 재시험 기록을 만들었습니다.

기업 AX 스킬의 저장소와 Codex 및 Claude Code 설치본이 같은지 확인했고, 이번에 추가 보완한 집계와 최종 응답 도구의 집중 테스트 10개를 통과했습니다. 이 수치는 도구 검사 결과이며 기업 업무 효과를 측정한 수치는 아닙니다.

가장 최근의 비교 결과

2026년 10월 20일, 동일한 누리워크 가상 사례 9개를 두 CLI의 새 세션에서 실행했습니다. 원문, Wiki 및 검사기를 유지하고, 이전 답안이나 평가표를 모델에 제공하지 않았습니다.

Claude의 0/9는 모든 사실과 시간 해석이 틀렸다는 뜻이 아닙니다. 변경표 누락과 관계 참조까지 포함한 전체 대조에서 각 사례에 후속 보완점이 남았다는 의미입니다. 예를 들어 날짜 속성에 회차 정보를 함께 연결하거나, 기존 Wiki의 ‘동시에 권한 갱신’을 ‘승인안의 효력 즉시 시작’으로 바꾸어 해석한 문제가 남았습니다.

이번 수치 집계 오류는 재발하지 않았지만, Claude는 추가한 공통 최종 답변 생성 및 검증 절차를 실행하지 않았습니다. 지침에 적어 놓은 것과 실제 실행됐다는 것은 별도로 확인해야 했습니다.

이 비교는 알려진 합성 사례에 대한 각 호스트 한 번의 최종 회귀 실행입니다. 두 도구는 각각의 실행 환경과 모델 설정을 사용했으며, 설정을 완전히 통제한 모델 비교 실험은 아닙니다. 의미 대조는 작성 측 LLM이 수행했으며 독립 사람 심사가 아닙니다. 따라서 일반적인 모델 우열이나 실무 정확도 순위로 확대해석하지 않았습니다.

시행착오를 통해 배운 점

첫째, 문제 정의가 결과물의 범위를 결정했습니다. ‘AI Agent를 만들자’에서 시작하면 자동 승인이나 외부 발송까지 범위가 커지기 쉬웠습니다. 누구의 어떤 조사 및 검토를 돕는지 정하자 입력과 출력, 보류 조건이 구체화됐습니다.

둘째, 지식은 양뿐 아니라 연결과 적용 범위를 관리해야 했습니다. 어떤 문장이 어떤 원문을 근거로 하는지, 어느 조직과 시점에 적용되는지, 자료가 바뀌면 무엇을 다시 봐야 하는지가 필요했습니다.

셋째, 정확한 인용이 올바른 해석을 보장하지 않았습니다. 같은 문장을 인용해도 사건 시점과 기간, 수행 사실과 권한, 설정 변경과 갱신을 혼동할 수 있었습니다. 구조 검사와 의미 검토를 분리한 이유입니다.

넷째, 작은 오류를 재사용할 규칙으로 바꾸는 과정이 중요했습니다. 특정 답변을 고치는 데서 끝내지 않고, 사실, 추론 및 미결 구분과 관계별 대조 규칙을 스킬에 반영했습니다. 수정 후에는 새 실행 결과를 다시 확인했습니다.

다섯째, 완료 상태와 성과를 구분해야 했습니다. 초안 생성 완료, 판단 보류 해소, 사람의 검토, 업무 반영은 서로 다른 상태였습니다. 로컬 앱이 동작했다는 사실만으로 실제 기업의 시간 절감이나 운영 준비 완료를 주장할 수는 없었습니다.

남은 과제와 다음 계획

우선 Claude에 남은 관계 참조와 변경 분류 문제를 보완해야 합니다. 공통 최종 응답 절차도 지침 준수에만 의존하지 않고 실행 기록으로 확인할 방법이 필요합니다.

그다음에는 개발에 사용하지 않은 사례를 별도로 준비하고, 실제 업무 담당자의 검토를 받아보려고 합니다. 실제 기업 파일럿에서는 조사 시간뿐 아니라 검토, 수정 및 실패 대응 시간과 초안 채택 여부를 함께 측정할 계획입니다. 현재까지 실제 기업의 시간 절감률이나 ROI는 측정하지 않았습니다.

도움 받은 글

• DEXA 온톨로지 학습 자료: 온톨로지와 지식 연결 방법을 검토할 때 참고했습니다.
• AKM Skill Suite: 질문–주장–근거 연결과 변경 영향 검사를 기존 방법론에 반영할 때 참고했습니다.

이 글은 2026년 10월 20일까지의 프로젝트 실행 및 검증 기록을 바탕으로 AI의 도움을 받아 작성했습니다. 누리워크와 업무 자료는 가상이며, 그림은 설명용 개념도와 기록 기반 비교표입니다.

원문: 천동암, 지피터스 GPTers (2026.10.20) gpters.org 원문 보기