부록 A. 더 알아 둘 말

이 부록에서 할 일

본문에서 뜻만 짧게 짚고 지나간 말 다섯 개를 정리합니다. 각 말이 이 시리즈의 어느 장과 이어지는지, 실무에서는 어떤 모습으로 보이는지 확인합니다.

본문에서 이름만 스치고 지나간 말 중에는 실습에 당장 필요하지는 않아도 AI 소식을 읽다 보면 계속 마주치는 말이 많아, 그중 꼭 필요한 다섯 개만 골랐습니다. 이 다섯 개를 알아 두면 이 시리즈에서 한 일이 어떤 흐름 위에 있었는지 보입니다.

1. 에이전트

에이전트(Agent)는 계획 → 실행 → 확인을 스스로 반복하며 일을 끝까지 처리하는 방식입니다. 도구의 종류라기보다 일하는 방식을 가리키는 말이며, 질문에 답만 돌려주고 멈추는 방식과 대비됩니다.

이 말은 1.4장에서 처음 나왔는데, 모델, 프롬프트, 지침, 스킬, MCP를 받아 일을 끝내는 직원을 에이전트라고 했습니다. 클로드 엑셀도 이 방식으로 일하며, 4.4장에서 살펴본 문서 읽기 → 계획 → 코드 실행 → 결과 확인의 반복이 바로 에이전트의 모습입니다. 따라서 클로드 엑셀은 0장의 분류로는 웹 쪽 도구이지만 일하는 방식은 에이전트입니다.

실무에서는 진행 메시지에서 이 모습을 확인할 수 있습니다. 클로드는 코드를 돌린 뒤 결과를 다시 읽고, #REF! 같은 오류가 보이면 스스로 고쳐 다시 돌립니다. 다만 에이전트가 스스로 확인한다고 해서 늘 맞는 것은 아닙니다. 에이전트는 오류 표시처럼 눈에 띄는 문제는 잡지만, 합친 행 수가 원본과 맞는지처럼 업무의 기준으로 맞춰 볼 일은 알려 주지 않으면 모릅니다. 5부와 6부의 실습마다 행 수나 합계처럼 맞춰 볼 숫자를 프롬프트에 함께 넣은 것도 이 때문입니다.

2. RAG

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 질문을 받으면 관련 문서를 먼저 찾아 근거로 붙인 뒤 답하게 하는 방식입니다. 이름의 세 단어는 순서 그대로 찾고(검색), 붙이고(증강), 쓰는(생성) 과정을 뜻합니다.

AI 도입을 검토하는 자리에서는 "우리 회사 규정을 AI에 학습시켜야 하나요?"라는 질문이 거의 빠지지 않는데, 대개는 학습시킬 필요 없이 RAG로 해결됩니다. 쉽게 말해 규정집을 통째로 외우게 하는 대신 시험 때 규정집을 펼쳐 주는 오픈북 방식입니다. 기준서는 개정되고 사내 규정은 해마다 바뀌므로, 외운 지식은 외운 그날부터 낡기 시작합니다. 1.3장에서 할루시네이션의 대책으로 출처를 요구하라고 한 것을 구조로 만든 방식이 RAG이며, 1.5장에서 살펴본 노트북엘엠(NotebookLM)이 대표적인 예입니다.

이 시리즈에서는 커넥터가 그 역할을 했습니다. 2.3장에서 회계위키 커넥터를 연결하자 답에 출처가 붙었고, 6.3장에서는 제1116호 문단을 조회해 리스 판단의 근거로 남겼는데, 둘 다 RAG를 도구로 쓴 모습입니다. 하지만 검색이 엉뚱한 문단을 집어 오면 AI는 그 근거 위에서 성실하게 틀립니다. 따라서 근거가 붙었다는 사실은 틀리지 않는다는 보증이라기보다, 틀렸을 때 확인할 길이 생겼다는 의미로 받아들여야 합니다.

3. 하네스와 루프

하네스(Harness)는 검증 규칙이라는 안전틀을 둘러 AI가 그 안에서만 일하게 하는 환경이고, 루프(Loop)는 기준에 못 미치면 AI가 고쳐 다시 돌리는 반복입니다.

에이전트에게 일을 맡겨도 결과를 사람이 일일이 열어 확인하는 동안에는 일이 사람 속도로 흐르는데, 하네스와 루프는 그 확인을 코드로 넘긴 구조입니다. 즉 7.1장에서 말한 "결과는 검증"을 사람 대신 코드가 매번 해 주며, 실습에서 행 수 일치(5.1), 열 합계 0(5.5), 차대 차이 0(6.3)을 함께 확인시킨 것이 그 씨앗입니다.

그림으로 보면 AI와 코드, 사람의 역할이 다음과 같이 나뉩니다.

작성 → 검증 → 수정으로 도는 닫힌 루프, 검증과 연결은 코드가 맡는다

AI가 초안을 쓰면 코드가 검증 게이트에서 기준에 맞는지 가려, 통과한 결과만 사람에게 넘기고 걸린 결과는 사유를 붙여 AI에게 돌려보냅니다. AI는 그 사유를 보고 고쳐 다시 검증에 올리며, 기준을 넘을 때까지 이 왕복이 이어집니다. 차변과 대변 합계가 다르면 전표 저장 자체가 되지 않는 회계 시스템과 같은 원리입니다. 사람은 기준을 설계하고, 끝까지 통과한 결과만 마지막에 한 번 확인합니다. 이런 장치는 대개 내 PC에서 코드로 짜 두기 때문에 7.2장에서 다룬 로컬 에이전트의 몫입니다.

4. 컨텍스트 엔지니어링

컨텍스트 엔지니어링(Context Engineering)은 질문 문장을 다듬는 대신, AI가 일할 때 무엇을 읽게 할지를 설계하는 일입니다.

1.5장에서는 컨텍스트 윈도우가 넓어지자 관심이 질문을 다듬는 기술에서 무엇을 읽혀 줄지로 옮겨 갔고, 프롬프트 엔지니어링 대신 이 말이 들리기 시작했다고 설명했습니다. 1.2장에서 컨텍스트를 건네는 방법이 입력 → 첨부 → 스킬·MCP로 발전해 왔다고 한 것도 같은 흐름이며, 설계의 목표는 매번 붙여 넣던 자료를 AI가 필요할 때 알아서 가져오게 만드는 데 있습니다. 7.1장에서 이 시리즈의 실습이 모두 프롬프트를 잘 쓰는 법보다 맥락을 붙여 두는 법에 관한 이야기였다고 정리한 결론도, 이 용어를 우리말로 풀어 쓴 말입니다.

실무에서는 프롬프트 한 줄보다 그 옆에 무엇이 붙어 있느냐가 결과를 가릅니다. 예를 들어 클로드 엑셀 지침에 서식 스킬을 걸어 두고(6.1), 절차는 스킬로, 근거는 회계위키 커넥터로 붙여 두면(6.3) 계약서 한 장만 던져도 같은 판단 순서를 밟습니다. 반대로 상관없는 대화가 쌓이면 품질이 떨어지므로, 새 작업을 새 채팅에서 시작하는 습관(1.3)도 컨텍스트를 설계하는 일에 속합니다.

5. 상시 자율 에이전트

상시 자율 에이전트는 24시간 켜 둔 컴퓨터에서 대기하다가, 메신저로 던져 둔 지시를 사람 없이 처리하고 결과를 남겨 두는 에이전트입니다.

0장의 네 단계로 말하면 레벨 4, 즉 헤르메스(Hermes)나 오픈클로(OpenClaw) 같은 도구를 직접 세워 업무에 쓰는 단계입니다. 하네스와 루프로 품질은 구조로 잡았지만 여전히 누군가 PC 앞에 앉아 실행을 눌러야 일이 돌았는데, 이 단계에서는 그 시작 버튼이 없어집니다. 텔레그램·슬랙 같은 메신저로 지시를 던져 두면 자리를 비운 사이에 작업이 끝나 결과가 남아 있습니다. 특히 화면을 보며 마우스와 키보드를 직접 움직이는 컴퓨터 유즈(Computer Use)와 만나면, MCP 같은 연결 통로가 없는 프로그램까지 사람처럼 다룰 여지도 생깁니다.

상시 자율 에이전트가 목적지처럼 보이지만, 저는 대부분의 실무는 로컬 에이전트로 충분하다고 생각합니다. 매달 같은 자리에서 만드는 정산표라면 시작 버튼을 누르는 일이 부담이 되지 않기 때문입니다. 오히려 지금 쌓는 스킬과 검증 규칙이 훗날 자율 에이전트가 부릴 밑천이 됩니다. 부릴 흐름이 없으면 24시간 켜 둔 에이전트도 할 일이 없으므로, 6부에서 만든 대손충당금·리스 스킬은 다음 레벨에서도 그대로 쓰입니다.

정리

• 에이전트는 계획 → 실행 → 확인을 반복하는 일하는 방식이고, 클로드 엑셀도 이 방식으로 일합니다.
• RAG는 문서를 찾아 근거로 붙여 답하는 오픈북이고, 이 시리즈에서는 회계위키 커넥터가 그 역할을 했습니다.
• 하네스와 루프는 사람이 하던 확인을 코드로 넘겨, 기준을 넘을 때까지 AI가 고쳐 다시 돌게 하는 구조입니다.
• 컨텍스트 엔지니어링은 프롬프트를 잘 쓰는 법에서 맥락을 붙여 두는 법으로 옮겨 간 흐름의 이름입니다.
• 상시 자율 에이전트는 레벨 4의 모습이고, 지금 쌓는 스킬과 검증 규칙이 그 밑천이 됩니다.