지금까지 AI를 사용하며 느낀 점과, 최근 팀 내부 및 사이드 프로젝트에서 Claude Code를 도입한 경험을 정리해보려 합니다.
LLM이란
Large Language Model의 약자로, ChatGPT·Gemini·Claude 등 여러 AI 도구의 기반이 되는 언어 처리 모델입니다.
AI를 사용하면서 크게 두 가지 의문이 들었습니다.
1. AI는 진짜 생각을 하는 것일까?
Claude Code나 Cursor로 대화를 이어나가다 보면 답변 영역에 Thinking...이라는 문구를 자주 마주합니다. 어떻게 보면 진짜 생각하는 것처럼 보이지만, 사용자 입장에서는 결국 원하는 답변을 얻는 데 집중하다 보니 크게 신경 쓰지 않게 되는 문구이기도 합니다.
하지만 그 Thinking... 뒤에서는 실제로 꽤 많은 일이 일어납니다.
Claude Code 공식 문서에서는 Agentic Loop라는 개념을 소개합니다. 태스크가 주어지면 Claude는 컨텍스트 수집 → 액션 → 결과 검증이라는 세 단계를 반복하며 작업을 수행합니다. 단순한 질문이라면 컨텍스트 수집만으로 끝나지만, 버그 수정이라면 세 단계를 여러 번 순환하며 코드를 찾고, 수정하고, 테스트하는 과정을 거칩니다.
하나의 대화 세션에서 주고받은 모든 문맥은 Context라는 단위로 관리됩니다. Thinking... 뒤에서는 이 에이전트 루프가 실행되며, 각 단계에서 얻은 정보가 다음 판단의 근거가 됩니다. 단순한 텍스트 생성이 아니라, 여러 도구를 순서대로 호출하며 실제로 작업을 수행하는 구조인 셈입니다.
처음에는
빠른 자동완성정도로 여겼는데, 내부에서 파일을 열고, 검색하고, 테스트를 돌리고, 결과를 보고 다시 수정하는 과정이 자동으로 이루어진다는 걸 알고 나서 바라보는 시각이 달라졌습니다. 생각보다 훨씬 에이전트에 가까운 동작이었습니다.
2. 내가 원하는 대로 왜 답을 안 주고, 거짓말을 자꾸 할까?
Cursor를 처음 접했을 때, 하나의 세션 안에서 모든 작업을 처리하려 했습니다. 답변이 점점 이상해지고 왜 이렇게 멍청하지?라는 생각이 들 때쯤에야 새로운 세션을 열었던 기억이 있습니다.
지금 돌아보면, 세션이 길어질수록 답변 속도가 오히려 빨라졌습니다. 당시에는 토큰이라는 존재를 몰랐기 때문에, 사용 가능한 토큰이 빠르게 소진되고 있다는 사실을 인식하지 못했습니다.
반면 새로운 세션을 열면 에이전트가 이전 세션에서 파악했던 코드베이스를 처음부터 다시 분석하기 때문에 처음에는 느리게 느껴졌습니다.
나중에 Context의 개념을 이해하고 나서야 그 이유를 알게 되었습니다. 세션이 길어질수록 누적된 문맥이 한계치에 가까워지고, 오래된 내용이 밀려나거나 뒤섞이면서 에이전트가 환각(Hallucination) 을 일으키기 시작한 것입니다.
빠른 답변이 꼭 좋은 답변은 아닙니다. 컨텍스트가 포화 상태에 가까울수록 에이전트는
생각보다패턴 매칭에 가까운 답을 내놓습니다. 세션을 짧고 명확하게 유지하는 것이 품질을 높이는 가장 쉬운 방법이라는 걸, 직접 겪고 나서야 체감했습니다.
Cursor에서 Claude Code로 넘어가게 된 계기
한동안 Cursor를 메인으로 사용했지만, 작업이 복잡해질수록 한계가 느껴지기 시작했습니다. 결정적인 차이는 두 가지였습니다.
Context Rot
세션이 길어질수록 누적된 컨텍스트가 오히려 품질을 저하시키는 현상입니다.
Cursor는 세션 시작 시 코드베이스 전체를 컨텍스트에 넣는 것이 아니라, RAG 방식으로 쿼리와 관련성이 높은 코드 청크만 선택적으로 불러옵니다. 내부적으로는 코드베이스를 청크 단위로 임베딩해 벡터 DB에 저장하고, 쿼리가 들어올 때 의미적으로 유사한 청크를 꺼내 컨텍스트에 포함하는 구조입니다.
하지만 활성 파일, @-mention으로 추가한 파일, 도구 실행 결과 등이 대화가 이어질수록 메인 컨텍스트에 계속 누적됩니다. 서브 에이전트가 병렬로 동작하더라도 결과는 결국 메인 컨텍스트로 합산되기 때문에, 작업이 길어질수록 Context Rot이 빠르게 찾아왔습니다.
반면 Claude Code는 서브 에이전트가 작업을 마치면 결과 요약만 메인 컨텍스트로 반환합니다. CLAUDE.md와 Skill을 활용해 컨텍스트를 적절히 분리하면, Context Rot이 찾아오는 시점을 유의미하게 늦출 수 있습니다. 체감상 할루시네이션 빈도도 줄었습니다.
프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로
단순히 질문을 잘 쓰는 것을 넘어, 어떤 정보를 컨텍스트에 담을 것인가가 더 중요해진 시기가 온 것 같습니다.
최근에는 어떻게 요청해야 에이전트가 내가 원하는 대로 동작할까?라는 질문을 가지고 에이전트 파이프라인을 구성하고 있습니다. 실무에서는 코드 컨벤션, 팀 컨벤션, 린트 규칙 등 다양한 기준이 존재합니다. CLAUDE.md를 통해 이를 명시적으로 정의해 두면, 팀원 모두가 동일한 에이전트 동작을 공유하며 코드베이스를 일관성 있게 유지할 수 있습니다.
개인의 프롬프트 실력에 의존하는 것이 아니라, 에이전트 하네스(Agentic Harness) — 즉 CLAUDE.md, Skill, Hook, 서브 에이전트 구성 등을 조합한 팀 공유 컨텍스트 구조 — 를 설계하는 것이 최종 목표입니다. 이를 통해 팀원 누구나 동일한 품질의 아웃풋을 만들어내며 코드베이스를 안정적으로 구축해 나갈 수 있습니다.
Cursor가 나쁘다고 생각하지는 않습니다. 코드베이스 규모가 크지 않다면 오히려 Cursor가 더 편할 수 있습니다. IDE 안에서 코드를 보면서 바로 AI와 대화할 수 있고, 인라인 편집(
Cmd+K)이나 diff 미리보기처럼 시각적 피드백이 즉각적으로 주어지기 때문입니다. 터미널 기반인 Claude Code에 비해 별도 설정 없이 바로 시작할 수 있다는 점도 진입 장벽이 낮습니다. 다만 프로젝트 규모가 커지고, 컨텍스트를 직접 설계해야 할 필요가 생겼을 때는 Claude Code가 더 맞는 선택이라고 생각합니다.
사용해보기
CLAUDE.md 구성
CLAUDE.md 파일은 매 세션이 시작될 때마다 자동으로 컨텍스트에 포함됩니다. 다만 이 파일에 너무 많은 내용을 담으면 그 자체가 컨텍스트를 차지하게 됩니다. 그래서 저는 CLAUDE.md에 구체적인 지시를 전부 적는 대신, 어떤 상황에서 어떤 Skill과 SubAgent를 호출해야 하는지에 대한 지도를 구성해 두었습니다.
예를 들어,
숫자만 입력할 수 있게 하는 유틸 함수의 단위 테스트를 작성해줘.
라고 입력하면, 에이전트는 CLAUDE.md에 기재된 지도를 참조하여 자동으로 test 서브 에이전트와 Skill을 호출합니다. CLAUDE.md가 일종의 오케스트레이터 역할을 하는 셈입니다.
아래는 실제로 사용 중인 SubAgent, Skill, Rules 구성입니다.
처음에는 oh-my-claudecode라는 오픈소스를 사용해 볼까 했지만, 코드베이스를 이해한 상태에서는 팀만이 알 수 있는 디테일을 직접 추가하는 편이 더 좋은 답변을 이끌어낼 수 있다고 판단했습니다.
Skill
대부분의 Skill은 CLAUDE.md의 지도를 통해 프롬프트가 들어오면 해당 태스크에 맞춰 자동으로 오케스트레이팅됩니다.
대표적인 예로, 팀 내부에서 Redmine이라는 일정 관리 툴을 사용하고 있습니다. Jira의 티켓과 동일한 개념인 일감이라는 단위가 존재하며, 각 일감에는 고유한 번호가 부여됩니다.
아래 이미지는 Redmine Skill을 구성하여 호출하는 모습입니다.
issue number라는 placeholder가 자동으로 표시되도록 구성했습니다.
일감 번호를 입력하고 프롬프트를 전달하면, Redmine MCP 서버를 호출하여 실제 작성된 일감 내용을 가져와 컨텍스트에 포함시킵니다.
실제 작업 흐름
AI를 도입한 뒤 특히 체감이 컸던 부분은 테스트 코드 작성입니다. 반복적인 테스트 케이스를 에이전트에게 맡기고, 비즈니스 로직 구현에 더 집중할 수 있게 되었습니다.
아래는 test Skill과 SubAgent를 호출하여, 구현한 커스텀 훅에 대한 테스트 코드를 자동 생성한 과정입니다.
AI에 대한 개인적인 생각
AI가 빠르게 발전하면서, 단순 반복적인 기능 구현은 적절한 하네스를 구성해 두면 빠르게 처리할 수 있는 영역이 되었습니다. 그만큼 개발자는 프로젝트의 구조 설계와 아키텍처 판단에 더 집중할 수 있게 되었다고 생각합니다.
또한 포지션 간의 경계가 많이 줄었다는 느낌을 받습니다. 하네스만 잘 구성되어 있다면 기획자나 디자이너도 부담 없이 프론트엔드 코드를 작성할 수 있을 것 같습니다. 반대로, 프론트엔드 개발자가 기획력까지 갖춘다면 만들어낼 수 있는 임팩트는 훨씬 커질 수 있다 생각합니다.
빠르게 변화하는 AI 흐름에 적응하며, 더 나은 프론트엔드 개발자가 될 수 있도록 계속 노력해야겠습니다.