AI Agent 시대, 나는 AI를 어떻게 써야 할까

Mini·2026년 7월 22일

목록 보기

17/18

들어가며

빅프로젝트 특강 중 「Claude 엔지니어가 알려주는 AI Agent 시대의 개발 방법론과 실전 데모」를 들으며 가장 인상 깊었던 부분은, 강의가 단순히 새로운 AI 기술을 소개하는 강의가 아닌 앞으로 개발자가 어떤 방식으로 일해야 하는지를 중심으로 이야기하는 강의였다는 것이다. 특강은 생성형 AI의 현재 수준, AI Agent의 핵심 기술, 실전 데모, 그리고 앞으로 개발자의 역할이라는 네 가지 흐름으로 진행되었다. 들어가며 강조한 3가지가 인상깊어 글 시작전에 보고 다시 들어가보자.

첫 번째는 ‘말’, 즉 언어에 대한 부분이었다. AI 에이전트, MCP, 컨텍스트 엔지니어링 같은 용어를 단순히 외우는 것이 아니라, 왜 이런 개념이 등장했는지 자신의 문장으로 설명할 수 있어야 한다는 이야기였다.
두 번째는 ‘눈’, 즉 감각이었다. 에이전트가 제대로 작동하고 있는 상황과 불필요하게 반복하거나 엉뚱한 방향으로 흐르는 상황을 구분할 수 있는 판단력이 중요하다고 했다.
마지막은 ‘손’, 즉 행동이었다. 거창한 계획보다 오늘 저녁부터 바로 시작할 수 있는 90일 로드맵과 포트폴리오를 만들어보는 등 실천/활용이 필요하다는 점을 강조하는 특강이였던거 같다.

글 들어가기전, 요약

AI Agent는 이제 "실험"이 아니라 "실행"의 영역에 들어왔고, 개발자의 일은 "만드는 것"에서 "정하고 검증하는 것"으로 무게중심이 옮겨가고 있다.

그런데 "토큰과 생각(추론)을 어떻게 줄일까"는 강의가 던진 화두이다. 실제로 파고들어 보면 훨씬 많은 갈래의 판단이 필요했다, 이 글의 절반은 그 고민이다.

내가 만들던 claude-code-use 프로젝트를 강의 프레임에 대입해보니, 아직 AI를 100%역량을 끌어올려 사용하지 못한다고 생각이 들었다. 좀더 발전시켜서 AI를 잘 활용하자.

특강에서 다룬 개념

지금 우리는 어디쯤 와 있나

핵심은 "누가 다음 행동을 결정하는가"가 단계마다 사람에게서 AI로 옮겨간다는 것이다.

단계	특징
Chat	묻는다·답한다. 매 턴 사람이 질문하고 결과도 사람이 옮겨 붙임
Copilot	옆에서 거든다. 자동완성·초안 작성. 실행 주도권은 여전히 사람
Agent	목표만 주면 스스로 계획하고 도구를 골라 쓰고 결과를 검증
Multi-Agent	지휘자 1명 + 전문가 N명이 역할을 나눠 병렬로 일한다

지금은 실험의 해가 끝나고 실행의 해가 시작된 시점이라는 게 강의의 내용이였다. AI를 최소 한 개 업무에라도 도입한 조직이 이미 다수이고, 공개된 MCP 서버 수도 1년 반 사이 수십 배로 늘었다. 다만 완전 자율 에이전트 도입은 아직 소수에 그친다.
챗봇은 질문→답변으로 끝나지만, 에이전트는 목표→계획→도구 실행→결과 평가→반복이라는 루프를 스스로 돈다.

같은 LLM을 쓰는데 결과물이 다른 이유는, 그 주변에 뭘 붙였느냐의 차이다.

이미 무게중심이 옮겨간 공정들

프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로 — 반복적이고 순환적인 과정

설계·인프라·리뷰·문서 네 공정 모두 AI가 초안을 만들고, 사람은 그게 사업 맥락에 맞는지 최종 판단하는 쪽으로 역할이 옮겨가고 있다.
일이 줄어드는 게 아니다. 일의 무게중심이 "만드는 쪽"에서 "정하고 검증하는 쪽"으로 이동한다. 용어도 1년 반 사이 빠르게 바뀌어왔다.

프롬프트 엔지니어링 - >
- 컨텍스트 엔지니어링 - >
  - 하네스 엔지니어링 - >
    - 루프 엔지니어링

이름은 계속 바뀌지만 아래층(왜 이 문제가 생기는가)은 겹쳐 쌓인다는 게 요지였다. 그래서 용어 자체보다 판단 기준을 배우는 게 낫다.

AI Agent를 이루는 것들

Augmented LLM 구조	컨텍스트 보정

AI Agent는 다음 네 가지가 루프를 도는 것으로 정의된다. 하나라도 빠지면 그냥 챗봇이다.

LLM (두뇌) — 무엇을 할지 추론·판단
Memory (기억) — 무슨 일이 있었는지 들고 다님
Tool (손발) — 바깥 세상을 읽고 바꿈
Planning (계획) — 목표를 단계로 쪼개고 다시 짬
LLM은 텍스트만 뱉고, 실제 실행은 런타임(우리 코드)이 담당한다. 그래서 위험한 도구일수록 권한을 좁게, 파일 접근은 특정 디렉터리로 스코프를 한정하는 게 기본 원칙으로 강조됐다.

컨텍스트는 무한하지 않다는 것도 핵심 메시지였다. 많이 넣을수록 똑똑해질 것 같지만 실제로는 반대로 갈 때가 많다(Context Rot, Lost in the Middle 같은 연구가 근거로 제시됐다). 그래서 나온 게 네 가지 전략이다.

전략	의미
Write 쓴다	미래의 나를 위해 로그·결정 사항을 파일에 남긴다
Select 고른다	지금 필요한 것만 컨텍스트에 넣는다
Compress 줄인다	중요도는 남기고 분량만 줄인다
Isolate 격리한다	서브 에이전트에 맡기고 요약만 받는다

이 네 전략은 뒤에 나오는 내 개인적인 고민(토큰과 생각을 어떻게 줄일 것인가)의 출발점이 됐다.

워크플로 vs 에이전트, 그리고 자율성 레벨

"AI에게 다 맡기자"는 대개 실패한다.

workflow(사람이 순서와 분기를 미리 정함, 예측 가능하지만 예외에 취약)와 agent(모델이 도구와 순서를 스스로 판단, 유연하지만 관측·평가가 필수) 사이에서 지금 이 작업에 얼마나 맡길지를 정하는 게 현실적인 답이다. 자율성 레벨을 제시해줬다.

L0(사람이 전부)

L1(AI 제안·사람 실행)

L2(AI 초안·사람 리뷰)

L3(AI 실행·사후 확인)

L4(완전 자율)

이 중 L2가 실무에서 가장 흔히 쓰이는 지점이라고 한다. L4를 목표로 삼기보다, 지금 작업에 맞는 레벨을 스스로 정하는 게 실무적이라는 메시지였다.

고민하자

강의는 비용 = 토큰 × 스텝 수라는 한 줄로 정리하고 넘어갔다. 그런데 이 문장을 실제로 내 작업에 적용하려고 하니, 훨씬 많은 갈래의 고민이 나왔다. 일곱 가지로 정리해본다.

1. 애초에 추론이 필요한 문제인가부터 의심한다

"생각 깊이를 작업마다 다르게 설정하라"는 조언 앞에 생략된 판단이 있다고 생각한다. 이 작업에 추론이 정말 필요한가? 라는 질문이다.

1.파일 하나 찾기, 오타 하나 고치기처럼 답이 명백한 작업에 깊은 추론 모델을 물리면 토큰만 태우고 결과는 똑같다.
2. 반대로 여러 파일에 걸친 설계 결정처럼 "틀린 가정을 되돌아봐야 하는" 작업에 빠른 모델을 쓰면 결과가 부정확해서 재작업(=스텝 수 증가)으로 이어진다.

effort를 잘못 낮추면 재시도 비용으로 되돌아온다. "싼 모델을 쓰는 것"과 "적절한 모델을 쓰는 것"은 다른 문제다.

2. 스텝 수를 줄이는 게 토큰을 줄이는 것보다 효과가 클 때가 많다

프롬프트 한 줄을 줄이는 건 토큰 단가에서 몇 % 절약이지만, 루프 한 번을 줄이는 건 그 루프 전체(탐색+실행+검증)의 토큰을 통째로 아끼는 것이다.
그래서 고민의 우선순위는 "무엇을 짧게 쓸까"보다 "어디서 다시 도는가"를 먼저 찾는 쪽이어야 한다. 이건 결국 초기 지시가 얼마나 명확한가의 문제로 돌아간다. 다음에 애매하게 시켜서 되묻는 루프가 생기면, 그 되묻는 루프 자체가 스텝 수다.

3. 컨텍스트를 "안 채우는 것"과 "채웠다가 비우는 것"은 다른 전략이다

Write·Select·Compress·Isolate를 다시 뜯어보면, 이 넷은 사실언제 비용을 지불하느냐의 타이밍이 다르다.

Select(애초에 필요한 것만 넣기)는 가장 싸다. 비용을 아예 안 만든다. 하지만 "지금 뭐가 필요한지"를 미리 정확히 알아야 하는데, 탐색적인 작업에서는 이게 어렵다.
Compress(줄이기)는 한 번 채운 다음 요약하는 비용이 추가로 든다. 요약 자체도 LLM 호출이라 토큰을 쓴다.
Isolate(서브 에이전트 분리)는 겉으로는 메인 컨텍스트를 지키지만, 서브 에이전트가 쓰는 토큰까지 합치면 총량은 오히려 늘어난다. 간단한 작업에 서브 에이전트를 붙이면 분리 비용만 남는다.

결국 네 전략 중 뭘 쓸지는 지금 이 작업이 얼마나 오래, 얼마나 많은 파일에 걸쳐 진행될 것인가를 미리 가늠해야 고를 수 있는데, 이 가늠 자체가 또 하나의 판단 비용이라는 게 아이러니하다...

4. 캐싱은 설계에서부터 고려해야 나오는 절약이다

매 요청마다 같은 시스템 프롬프트·같은 CLAUDE.md를 새로 밀어 넣으면 캐시가 안 붙고 매번 전체 단가로 과금된다. 자주 안 바뀌는 것과 매번 바뀌는 것을 앞뒤로 명확히 분리해두면 앞부분이 캐시에 걸려 반복 비용이 크게 줄어든다. 프롬프트를 무엇을 넣을까로만 생각하면 안 나오고, 어떤 순서로, 얼마나 자주 바뀌는 덩어리로 나눌까까지 생각해야 나오는 절약이다.

5. 병렬로 돌릴 것과 순차로 돌릴 것을 가르는 기준

서브 에이전트를 여러 개 동시에 돌리면 시간은 줄지만 토큰 총량은 그대로거나 늘어난다. 반대로 순차로 돌리면 앞 단계 결과를 뒤 단계가 참고할 수 있어 재작업이 줄 수도 있지만 시간이 길어진다.
나는 여태 이걸 "빠르면 좋은 것"으로만 생각했지 비용 관점에서 저울질해본 적이 없었다.

독립적인 작업(탐색 여러 갈래) → 병렬이 이득
서로 의존하는 작업(설계→구현→검증)을 억지로 병렬화 → 나중에 합치는 비용이 더 든다

6. 검증 비용도 전체 비용에 포함해서 계산해야 한다

빠르고 싼 모델로 작업을 끝냈다고 해서 끝난 게 아니다. 결과가 틀렸는지 사람이 검토하는 시간, 틀렸을 때 다시 시키는 토큰까지 합쳐야 진짜 비용이다. 모델을 고를 때 이 답이 틀렸을 때 내가 알아챌 수 있는가까지 고민에 넣어야 한다. 알아채기 어려운 실수를 내는 모델을 싸다고 고르면, 검증 비용이 절약분을 다 잡아먹는다.

7. 정말 풀리지 않는 고민

이번 판단에 얼마나 생각을 태울까를 매번 사람이 정해야 하는가?
effort를 작업마다 다르게 설정하라는 조언은 맞지만, 그 설정을 사람이 매번 판단해야 한다면 이것도 결국 사람의 인지 비용이다. 이상적으로는 에이전트가 이 작업은 되돌아볼 필요가 있어 보인다"는 걸 스스로 감지해서 effort를 올리는 게 맞을 텐데, 이걸 사람이 대신 정해주는 지금 단계와 에이전트가 스스로 정하는 다음 단계 사이에 아직 간극이 있다.
나는 지금 이 판단을 거의 느낌으로 하고 있는데, 이걸 규칙으로 정리해서 CLAUDE.md나 하네스 설정에 박아둘 수 있을지가 다음에 시도해볼 지점이다. 예를 들면 이런 식이다.

파일 3개 이상 걸치면 → 깊은 모델
테스트 실패가 2회 이상 반복되면 → effort 상향

특강을 듣고 정리하고 나니 확실해진 게 있다.

토큰을 줄인다는 하나의 목표를 넘어서 어디서 비용이 새는지를 계속 다시 찾아야 하는 것이 중요하다고 생각한다.
이 프레임(Write·Select·Compress·Isolate, effort 조절)은 도구 상자일 뿐이고, 지금 이 작업에 어떤 도구를 얼마나 꺼내 쓸지는 결국 매번 새로 판단해야 한다.

내가 이미 하고 있던 것과 겹쳐보기

이 강의를 들으면서 계속 떠오른 게, Claude CLI를 자주 사용하는 입장에서 내가 편하려고 만들고 있는 claude-code-use였다. 배운 개념에 내 프로젝트를 대입해보자

지금 레포에는 11개의 서브 에이전트(00-orchestrator부터 시작해서 planner, implementer, reviewer, tester.. 등등)와, 그 아래에서 실제로 돌아가는 CLI 도구 몇 개가 있다. claude-cost는 세션을 시작하기 전에 에이전트·모델별로 예상 비용을 계산해준다. claude-handoff는 세션이 끝날 때 작업 맥락을 파일로 저장해뒀다가 다음 세션 시작할 때 그대로 이어 붙일 수 있게 해준다. claude-remind는 TODO.md나 CLAUDE.md에 남겨둔 미완료 항목을 세션 시작 시점에 다시 띄워준다. (여러가지 있지만) 이 조합을 다시 보면, planner·reviewer·security-auditor는 애초에 읽기 전용 권한만 갖도록 정의해뒀다는 게 눈에 들어온다. 코드를 직접 고치는 건 implementer 하나뿐이고, 나머지는 보고 판단만 하게 만들어뒀다. 이건 "사람이 개입하는 지점을 설계했는가"라는 질문에는 이미 답이 되어 있는 부분이다.

반면 없는 것도 분명하다. GitHub·Figma·Notion MCP 서버는 이미 클라이언트로 연결해서 쓰고 있지만, 전부 남이 만들어둔 걸 가져다 쓰는 입장이다. claude-code-use 안에 있는 도구들은 전부 내가 터미널에서 직접 실행하는 CLI라서, 이 중 하나라도 내가 직접 MCP 서버로 만들어서 Claude가 스스로 판단해서 호출하게 만든 건 아직 없다. 그리고 claude-cost가 "이번 달에 재작업이 몇 번 있었다"는 숫자는 남기지만, 정작 그 재작업이 왜 일어났고 어떻게 고쳤는지를 사람이 읽을 수 있는 글로 남기는 도구는 없다. 강의를 듣고 개선할 부분을 생각해보자.

MCP 서버
지금 claude-code-use에 있는 도구들은 전부 내가 터미널에서 직접 실행하는 CLI다. claude-cost(비용 추정)나 claude-handoff(세션 기록 조회)처럼 이미 로직이 검증된 도구부터 MCP 서버로 한 번 감싸보려고 한다. 새로 뭔가를 만드는 것보다, 이미 잘 도는 로직을 다른 방식(AI가 스스로 호출하는 방식)으로 한 번 더 노출해보는 쪽이 첫 시도로는 덜 위험하다고 판단했다. 이렇게 하면 에이전트가 작업을 시작하기 전에 "이 작업 예상 비용이 얼마나 나올까"를 스스로 물어볼 수 있게 되는데, 이게 바로 위에서 정리한 첫 번째 고민(추론이 정말 필요한 작업인지 미리 판단하기)을 도구 차원에서 도와주는 셈이 된다.
실패를 기록하는 습관.
지금은 재작업이 얼마나 자주 일어났는지 숫자(비율)만 남기고 있는데, 정작 "왜 헛돌았고 어떻게 고쳤는지"를 글로 남긴 적은 없었다. 다음부터는 재시도가 발생한 세션이 끝나면 무엇을 하려고 했는지, 왜 안 됐는지, 어떻게 고쳤는지, 다음엔 뭘 다르게 할 것인지를 짧게라도 파일로 남겨보려고 한다. 숫자는 "얼마나 자주 실패했는가"는 보여주지만 "왜 실패했는가"는 보여주지 못한다는 걸, 많이 겪고 블로그 또는 프로젝트에 남겨보려고 한다.

생각정리

나는 AI를 어떻게 써야 할까
AI는 이제 설계도대로 아주 잘 짓는 존재가 됐지만, 무엇을 지을지 정하는 건 여전히 사람의 일이다.

나에게 이게 구체적으로 의미하는 건 이렇다.

자율성 레벨을 스스로 정한다, L4(완전 자율)를 목표로 삼지 않는다. L2(AI 초안·사람 리뷰)가 실무에서 가장 많이 쓰이는 지점이고, 내 프로젝트의 읽기 전용 에이전트들도 결국 이 L2를 코드로 강제한 것이다.
컨텍스트를 RAM처럼 다룬다. 무한히 넣지 않는다. 필요할 때만 꺼내 쓰고, 작업 경계에서 비운다.
포트폴리오는 성공이 아니라 실패와 경계로 완성된다. 다음 과제는 명확해졌다. MCP 서버 하나를 직접 만들고, 실패 케이스를 의도적으로 만들어서 그 실패를 어떻게 고쳤는지 기록하는 것 또는 AI를 많이 활용하며 부족한점에 대해 계속 끊임없이 고민하는것이다.

대학교 학부에서 GPT-3.5를 사용하며 AI가 하지 못하는 일을 사람이 메우는 것이 개발자의 역할이라고 생각했다. 하지만 AI는 1년, 6개월, 그리고 불과 1개월 단위로도 체감될 만큼 빠르게 발전하고 있다. 지금의 AI를 보며 '과연 주니어 개발자는 앞으로 어떤 경쟁력을 가져야 할까?'라는 고민이 들 정도였다. 그런데 이번 강의를 들으며 생각이 조금 달라졌다. AI가 점점 더 능숙한 장인이 되어갈수록, 사람은 더 이상 벽돌을 하나씩 쌓는 사람이 아니라 어떤 땅 위에 무엇을 지을지 결정하는 사람이어야 한다는 것이다. 방향을 정하고, AI가 이해할 수 있는 맥락을 설계하며, 완성된 결과를 검증하고 책임지는 역할이 더욱 중요해지고 있다. 결국 AI 시대의 개발자는 코드를 가장 많이 작성하는 사람이 아니라, 가장 좋은 문제를 정의하고, 가장 올바른 질문을 던지며, 가장 분명한 기준을 세울 수 있는 사람이 되어야 한다고 생각한다. 기술은 점점 더 빠르게 발전하겠지만, 무엇을 만들 것인지 결정하고 그 결과에 책임을 지는 일만큼은 여전히 사람의 몫이라는 사실은 변하지 않을 것이다.