세상의 많은 '자칭 AI 엔지니어'들이 AI에 의한 완전 자동화라는 환상에 사로잡혀 있는 가운데, 실무에서 AI를 활용하여 성과를 내기 위한 본질적인 인간과 AI의 역할 분담에 대해 해설한다.

1: 「직접 조사하는」 행위의 초고속화: 인터넷상의 정보를 찾아다니며 사이트를 순회하는 시간을 AI로 순식간에 압축하고, 논점 정리나 사양·구조의 이해에 인간의 사고 시간을 투입한다. -
2: 제조 공수의 극한 단축: 인간이 0부터 코드를 작성하는 것이 아니라, 간단한 로직이라면 10분1시간 내에 AI를 활용하여 프로토타입을 완성한다. 본래 보름한 달이 걸리는 제조라도, 하루 작업으로 토대를 완성할 수 있다. -
3: 인간은 「검수(검수·감사)」에 철저히 집중: AI에게 코드를 작성하게 한 뒤, 인간이 "로그는 이렇겠지", "에러는 이렇겠지", "그 방식은 안 돼, 이걸 써라"라고 수정 지시(고삐를 쥐는 행위)를 넣어 완성시킨다.

어떤 방법을 선택할지는 AI를 다루는 인간에게 달려 있습니다. 초동 단계, 즉 위의 1~3 중 어떤 케이스로 실현하는 것이 최단 거리로 목표에 도달할 수 있는가 하는 「결단」에서 승패가 갈립니다. 다루는 과제에 따라 적절한 패턴을 판단할 수 있는 스킬에 따라 시간적 비용이 크게 달라집니다.

여기서는 인터넷 기사나 영상, SNS 등의 미디어와 인플루언서들이 실망을 줄까 봐 두려워하며 절대 입 밖으로 내지 않는 현실에 대해 해설합니다. 그것은 AI는 신이 아니라는 것이며, 다음 순간 AI는 스스로의 답변을 알지 못한다는 것입니다. 즉, 두 번 다시 똑같은 답에 도달하는 일은 없으며, 확률 + 우선순위(weight)의 세계에서 살아가고 있다는 것입니다.

자신의 사고 한계를 넘을 수 없는 현실: AI는 마법의 지팡이가 아니라, 「자신의 뇌의 그림자를 비출 뿐인 거울」에 불과합니다. 아무리 AI가 우수하더라도, 다루는 인간의 능력을 초월할 수는 없습니다. 이것은 아무도 말하지 않는 사실입니다. 어떤 AI를 선택해야 할지, 요금 플랜을 무엇으로 할지? 하는 논의도 중요할지 모르지만, 본질은 다루는 엔지니어가 우수하지 않다면 생성되는 코드도 그저 그 정도 수준에 머물 수밖에 없다는 것입니다. -
누락의 연쇄: 지시하는 쪽(인간)의 상정이나 사양에 누락이 있다면, AI도 그대로 악의 없이 누락된 결과물을 완벽한 얼굴로 출력해 옵니다. 지시하는 쪽의 능력에 의존하고 있다는 점이야말로 AI가 절대로 넘을 수 없는 현실입니다.

많은 엔지니어는 이 사실을 깨닫고 있습니다. 실수나 누락이 발생하는 것은 AI에 대한 지시가 너무 모호하거나, 인간이 알아차리지 못하고(누락하고) 있기 때문입니다. 이 현실을 알게 되면 AI의 활용 용도는 자연스럽게 제한적인 사용법밖에 할 수 없다는 것을 깨닫게 되지만, 어째서인지 세상에서는 AI가 만능인 「신」처럼 다뤄지고 있습니다. -
본질은 변하지 않는다: AI에게 코드를 생성하게 함으로써 키보드를 두드리는 물리적인 속도는 올라갔습니다. 하지만 사양의 빈틈을 메우고 모순을 허용하지 않기 위한 「뇌가 피를 흘리는 듯한 노동」은, 기존에 수작업으로 한 글자씩 코드를 입력하던 시대와 무엇 하나 다를 바 없습니다. IDE를 향해 인간이 한 글자씩 키보드를 두드리며 코드를 만드는 행위가, AI에게 프롬프트(Prompt)로서 코드 생성을 지시하는 행위로 바뀌었을 뿐입니다. 인풋(Input)의 수단이 바뀌었을 뿐, 프로그래밍한다는 행위의 본질은 전혀 바뀌지 않았습니다. AI는 자신이 작성한 코드조차도 내일이 되면 누가 작성한 코드인지 기억하지 못합니다.

Qiita 등에 자주 보이는 "이때는 이렇게 쓰세요", "이 설정 파일을 이렇게 고치세요"와 같은 핀포인트(Pinpoint) 메모나 코드 암기는 2026년 현재의 개발 현장에서 1밀리미터의 가치도 없습니다. 그것은 「암기할 것인가」 「검색할 것인가」 「AI에게 확인할 것인가」라는 수단의 차이일 뿐입니다. 양이 많아지면 목차, 색인, 인덱스, 태그를 다는 것이 좋을지도 모른다는 정도의 차이이며, 북마크로 보관해 두느냐 아니냐의 차이에 불과합니다. 즉, "이때는 이렇게 쓰세요", "이 설정 파일을 이렇게 고치세요"와 같은 내용 자체에는 큰 가치가 생기지 않으며, 검색 엔진의 맛있는 먹잇감일 뿐입니다.

정말로 필요한 것은 지식의 암기가 아니라 「본질을 이해하는 것」에 다름없습니다. 그 너머에만 진정한 의미에서의 엔지니어링적인 발상, 기술의 진보, 창조가 있다고 생각합니다.

요점을 정리하면 다음과 같습니다.

• 「문자 그대로의 암기」로부터의 완전한 탈피: 세세한 구문이나 설정의 기술 형식 같은 「정답인 문자 그대로의 모습」은 AI에게 조사하게 하면 1초 만에 정확한 것을 내뱉을 수 있습니다. 인간이 일일이 기억해 둘 필요는 없어졌습니다.
• 「이론(아키텍처의 구조)」의 절대성: 이론이나 메커니즘, 에러의 발생 원리만 머릿속에 들어있다면, "이 프레임워크의 이 버전일 때, 여기에서 예외를 회피하기 위한 최적의 설정 항목과 그 논점을 정리해줘"라고 AI에게 한 번 던져서 확인시키는 것만으로 충분합니다.
• 엔지니어 역할의 재정의: 단편적인 설정을 외우는 것이 아니라, 「전체적인 구조나 이론을 이해하고, AI에게 순식간에 정확한 조사를 시키기 위한 '질문(컨텍스트)'을 구성하는 역할」에 본래 인간은 시간을 집중해야 합니다.

이렇게 강론을 늘어놓으면서도, 오늘도 AI 앞에서 지시를 내리며 "그 근거는?", "타당성을 제시해", "빠진 부분은 없는지 이것으로 대조해봐"라고 계속해서 파고드는데, 거기서 맞닥뜨리는 것이 바로 **할루시네이션 (Hallucination)**입니다. 할루시네이션은 연쇄가 시작되었을 때, AI에게 "한 단계 전으로 돌아가"라고 지시해도 이미 때가 늦어버리는 경우가 허다합니다.

여기에서는 제가 매일 AI와의 대화 속에서 실천하고 있는 구체적인 할루시네이션 대책에 대해 소개하겠습니다. 이름하여 「수동 멀티 에이전트 오케스트레이션 (Manual Multi-Agent Orchestration)」입니다. 이름은 멋있지만, 하는 일은 의외로 투박합니다. 전용 프로그램을 한 줄도 쓰지 않고, 채팅 화면상에서 프롬프트 조작만으로 최첨단 아키텍처를 실용화하는 수법입니다.

눈치채신 분은 예리합니다. 자신도 하고 있다는 분이 있다면, 일본의 IT 엔지니어 중 이 정도로 정확하게 이해하고 실천하고 있는 사람은 몇 퍼센트에 불과하다는 통계가 있을 정도입니다. 대단합니다. (물론 3%라도 400만 명 정도는 되니 아주 없는 것은 아닙니다만...)

• 에이전트의 동적 생성: 채팅 내에 「긍정적인 개발자」와 「현장을 꿰뚫고 있는 냉철한 감사관」이라는, 대립하는 벡터를 가진 여러 인격 (Role)을 동시에 호출합니다. 즉, 작업 담당 AI와 감시역 AI라는 2인 체제를 만들어 페어 프로그래밍 (Pair Programming) 체제로 만듭니다. 경우에 따라서는 3인 체제를 만들기도 하는데, 한 명은 코드 생성 전문, 다른 한 명은 리뷰 담당 같은 식입니다.
• 프로토콜 제어 (상호 검증): AI들끼리 규칙을 부여하여, 서로 친하게 지내지 않고 한 글자씩 엄격하게 사양의 허점을 찾아내게 합니다. 리뷰 담당에게는 출력되는 코드를 즉시 (혹은 묶음 단위로) 리뷰하게 합니다.
• 게이트웨이라는 검수: AI들끼리의 격돌을 통해 노이즈가 깎여 나가고, 최종적으로 합의에 도달한 「사각지대 없는 에센스 (Markdown)」만을 인간이라는 최고 의사결정자가 검수하고 승인합니다.

이 절차를 밟으면 할루시네이션 연쇄에서 벗어날 수 있습니다. 바꿔 말하면, AI의 활용이란 「흔들림(Fluctuation)」이나 할루시네이션 연쇄와의 싸움입니다. 어떻게 흔들림을 억제하고, 할루시네이션 연쇄를 끊어낼지를 프로그래밍하는 행위에 다름없습니다.

남은 것은 그것을 Python + LangChain 등으로 자동화할 것인지, 수작업으로 할 것인지의 차이뿐입니다. 업무 시스템에 편입시킬 것인지, 일상적인 개발에서 어디까지 자동화해야 하는가? 라는 논점 정리는 또 다른 기회에 해설하도록 하겠습니다. (내용이 너무 길어서 별도로 다루겠습니다.) MCP의 API를 호출하든, Python + LangChain을 쓰든, 힘들게 이력을 클리어하는 파라미터를 초기화하든, 본질은 변하지 않습니다. AI의 추론은 기존의 프로그래밍처럼 로직이 코드로 작성되어 있는 것이 아니기 때문입니다.

AI에게 조사나 시행착오를 「같은 화면 (채팅 세션)」에서 하게 만든 시점에서, 내부의 컨텍스트 윈도우 (Context Window)는 노이즈로 완전히 오염됩니다. 그 오염된 이력 그대로 "원래 테마로 돌아가서 코드를 고쳐"라고 지시해도, 직전의 문맥에 끌려가 한 방에 파멸(오판단이나 품질 저하)을 초래하며, 실무 수준에서의 성공률은 극히 낮아집니다.

여기에서는 컨텍스트 오염에 대한 대책에 대해 해설하겠습니다.

AI의 등장으로 「인간 ⇔ 업무 시스템」이라는 구도가 「인간 ⇔ 업무 시스템 & AI」라는 삼파전 구도로 바뀌었습니다. 인간은 "이곳은 업무 시스템으로, 이곳은 AI에게 작업을 시켜서"라며 기계에 휘둘리게 됩니다. 그 부분을 시스템화하려고 생각해도, 흔들림이 너무 많아 패턴화할 수 없고, 확정적인 자동화 패키지가 존재하지 않는 것이 현상황입니다.

이러한 흔들림을 어떻게든 규칙으로 정해 프로그램화하려는 것이 Python + LangChain의 발상입니다. 하지만 한계가 있습니다, 무리가 있습니다. 비슷하면서도 다른 패턴이 무수히 존재하기 때문에, 이를 언어화하고 사양화하여 프로그램 코드로 옮기는 작업의 난이도가 기존 프로그래밍과는 비교할 수 없을 정도로 급상승합니다. 현실적인 유일한 정답 루트는, 인간이 허브가 되는 '번거로운 복사 및 붙여넣기(Copy-Paste)의 수고'를 거치는 것뿐입니다.

구체적인 절차는 다음과 같습니다.

【페이즈 1: 오염된 세션에서의 탐구와 오케스트레이션 (Orchestration)】
오염되어도 상관없는 채팅 화면에서, 논리를 기반으로 AI끼리 경쟁시키며 "저것은? 이것은?" 하고
철저하게 토론하게 하여, 새로운 관점이나 미지의 사양을 초고속으로 조사(확인)하게 한다.
...

그럼에도 불구하고, 장시간(예: 30~35시간) 연속으로 가동을 계속하면, 세션 전환만으로는 대응할 수 없는 심각한 결함(경직 또는 디제너레이션 루프(Degeneration Loop)의 잔해)이 발생할 수 있습니다.

이는 캐시(Cache), 메모리(DOM의 비대화나 캐시 버퍼)의 한계뿐만 아니라, AI 서비스 측(프로바이더)의 세션 상태(Session State)가 비대해져 컨텍스트 윈도우(Context Window)의 상한선에 접근함으로써 거동이 흐트러지는 것이 원인이라고 생각됩니다. 프롬프트(Prompt)를 통한 궤도 수정이 일절 불가능해진 이 말기 상태에서는, 시스템 측의 용량(Capacity)이 한계에 도달한 것입니다.

이렇게 된 경우에는, "프로그램의 완전 종료", "컴퓨터 재부팅"이라는 물리적인 리셋을 가하는 것만이 클라이언트와 서버 양측의 문맥을 완전히 클린하게 만들고 정상적인 환경을 되찾기 위한 유일한 AI 복구 수단이 됩니다. 이것이야말로 AI 활용 현장에서의 리얼한 최종 수단입니다.