이 책을 읽는 분께

1. 그 사람은 고리의 어디에 서 있을까

AI와 일하는 이야기를 하다 보면 휴먼 인 더 루프(Human in the Loop)라는 말을 자주 듣습니다. AI가 일을 처리하는 고리 안에 사람이 끼어 있어야 한다는 뜻입니다. 이 말에 반대하는 사람은 거의 없습니다. 그런데 정작 그 사람이 고리의 어디에 끼어야 하는지는 잘 이야기하지 않습니다.

일을 시키기 전에 끼어야 할까요, AI가 일하는 도중에 끼어야 할까요, 결과물이 나온 다음에 끼어야 할까요. AI가 코드를 짜면 사람이 그 코드를 한 줄씩 읽어야 할까요, 아니면 다 만든 프로그램을 직접 써 봐야 할까요. 같은 '사람의 개입'이라도 어디에 서느냐에 따라 하는 일이 완전히 달라집니다.

저는 제주에서 AI·ICT 교육 회사 위니브를 운영하고 있습니다. 강의 플랫폼 위니버시티와 그 관리자 화면, 교재, 협업 도구, 상담 서버까지 지금 우리 회사가 쓰는 서비스의 많은 부분을 Claude Code와 함께 만들고 고칩니다. 견적서와 제안서, 결과보고서 같은 회사 문서도 스킬을 만들어 AI와 함께 씁니다. 이 책은 그렇게 일하며 업무와 소프트웨어 개발에서 제가 느낀 것들을 적은 기록입니다.

2. 왜 '맥락 제공은 어디서 할 것인가'인가

요즘 AI에게 일을 맡기는 방법으로 가장 많이 이야기되는 것이 스킬(Skills)입니다. Anthropic이 2025년 10월에 내놓은 이 방식은 지시와 자료, 스크립트를 폴더 하나에 묶어 두고 필요할 때만 꺼내 읽게 합니다.[1][2] 회사의 업무 방식을 스킬로 묶어 두면 AI가 그 업무를 볼 수 있게 됩니다. 그런데 스킬을 들여다보면 결국 맥락 제공입니다. 우리 회사는 어떤 양식을 쓰는지, 무엇을 중요하게 보는지, 어떤 표현은 쓰지 않는지를 AI에게 알려 주는 일입니다.

AI의 지능이 아무리 높아져도 이 맥락 제공은 남습니다. 우리 회사의 사정, 지난주에 바뀐 결정, 제가 좋다고 느끼는 결과물의 기준은 세상 어디에도 적혀 있지 않기 때문입니다. 그래서 저는 각 기업이 AI 시대에 가장 공을 들여야 할 곳이 이 맥락 제공이라고 생각합니다.

그렇다면 이 맥락을 어떻게 효율적으로 만들 수 있을까요. 제가 한동안 주목한 기술은 LLM 위키였습니다. LLM 위키나 CLAUDE.md 같은 파일에 맥락을 제공하는 규칙과 맥락 자체를 정리해 두고, AI가 일할 때마다 읽게 하는 방법입니다. 위니브에서도 이 방법을 다룬 『LLM 위키 에센셜』과 『클로드 코드 에센셜』 같은 책을 쓰고 강의도 했습니다.

그런데 Claude Code를 만든 사람들에게서 조금 다른 이야기가 들려왔습니다. 제가 처음 들은 것은 Claude Code 팀이 CLAUDE.md 파일을 주기적으로 지운다는 이야기였습니다. 나중에 원문을 찾아보니 정확히는 조금 달랐습니다. Claude Code를 만든 보리스 체르니(Boris Cherny)는 6개월마다 CLAUDE.md와 스킬, 훅을 지워 보고 모델이 어떻게 하는지 보라고 권했고, 팀은 새 모델이 나올 때마다 Claude Code의 시스템 프롬프트를 지워 왔다고 했습니다.[3] 이유는 이랬습니다. AI의 지능이 높아지면서, 지난 모델에게 필요했던 지침이 새 모델에게는 필요 없거나 오히려 모델을 지나치게 묶어 더 높은 차원의 일을 막는다는 것입니다.[4] 이 이야기는 3장에서 자세히 다룹니다.

멀티 에이전트도 비슷했습니다. 많은 개발자가 여러 에이전트를 동시에 돌리는 방식에 열광했지만, 그 역효과를 다룬 영상과 실험도 꾸준히 나왔습니다. 에이전트끼리 일을 주고받는 사이에 맥락이 사라지거나, 내가 의도하지 않은 일을 하는 경우가 많다는 것입니다. 그래서 웬만큼 복잡한 일은 에이전트 하나에게 맡기는 편이 낫다는 이야기가 이어졌습니다. 저도 공감합니다.

3. 외운 규칙은 다음 지능 앞에서 발목을 잡는다

이런 것들을 보며 든 생각이 있습니다. AI에게 맥락을 주고 일을 시키는 과정에 사람이 개입하는 데에도 나름의 판단 기준이 필요하다는 것입니다.

다만 그 기준이 이유를 모른 채 외운 규칙이라면 곤란합니다. "멀티 에이전트가 많아 보이니까 일을 빨리 처리하겠지", "LLM 위키나 CLAUDE.md는 무조건 써야 한다." 이렇게 암기해 버리면, 더 높은 지능의 AI가 나왔을 때 그 규칙이 오히려 방해가 됩니다. 규칙은 그대로인데 규칙을 만든 이유가 사라지는 순간이 오기 때문입니다.

그래서 이 책은 AI와 일할 때 당연하게 받아들이는 믿음들을 하나씩 꺼내 다시 물어봅니다. 에이전트가 많으면 일이 빨라질까, 지침을 써 두면 그대로 따를까, 맥락은 많이 쌓을수록 좋을까, 사람은 코드를 확인해야 할까. 뚜껑을 열어 보면 그렇지 않은 경우가 생각보다 많았습니다.

4. 이 책을 읽는 방법

이 책은 무엇을 하라고 처방하는 책이 아닙니다. 다 읽은 다음 날 바꿔야 할 행동 목록도 없습니다. 제가 당연하게 믿었던 것들이 실제로 일해 보니 어떻게 달랐는지, 그리고 인간이 개입해야 할 자리에 대한 제 생각이 어떻게 바뀌어 왔는지를 보여 드리려 합니다. 전체를 읽으며 각자의 일에 맞는 생각을 얻어 가시면 좋겠습니다.

코드를 몰라도 읽을 수 있게 썼습니다. 개발 이야기가 많이 나오지만 개발 방법을 가르치는 책은 아닙니다. 기획, 문서, 운영처럼 개발이 아닌 업무에 AI를 쓰는 분도 같은 질문을 만나게 될 것이라 생각합니다.

마지막으로 하나 당부드립니다. 이 책은 2026년 11월에 썼습니다. 여기에 적은 제 판단도 모델과 도구가 바뀌면 낡습니다. 1년 뒤에 이 책을 읽는다면, 그때의 AI 앞에서도 같은 말이 맞는지 의심하며 읽어 주세요. 그것이 이 책이 말하고 싶은 것이기도 합니다.