Cursor랑 Claude로 매일 일하는데, 왜 되는지는 모르고 있었다

들어가기 전에

이 글은 매일 AI를 쓰는 개발자가 도구의 속을 들여다보고 싶어 부트캠프에 들어간 이야기다. AI가 일상을 바꾸는 속도를 가까이서 보며 흥분과 불안을 동시에 느꼈고, 결국 "쓰기만 하는 자리"에서 한 걸음 더 들어가보기로 했다. 비슷한 자리에 서 계신 분들이 꽤 있을 것 같아 기록으로 남긴다.

내가 AI를 쓰는 방식

배경부터 짧게 풀어놓는다.

FE 6년차. React, Next.js, TypeScript, 웹뷰 하이브리드. 수만 명 임직원이 쓰는 사내 그룹웨어의 여러 영역을 담당한다.
Claude Max 구독. 업무 시간 대부분의 코드 작성이 Cursor + Claude 페어 프로그래밍으로 흘러간다. 사이드 프로젝트도 동일.
MCP 서버 몇 개 붙여 쓴다. Playwright, Context7 같은 것들. 문서 자동 조회, 브라우저 자동화 정도.
커스텀 스킬·슬래시 커맨드를 만든다. 반복되는 워크플로(리뷰, 릴리즈 노트, 체크포인트 등)를 스킬로 만들어 두고 쓴다.
에이전트 하네스는 아직. 자체 하네스를 구축해서 쓰는 단계는 아니다. 관심 갖고 탐색 중이고, 곧 올려볼 예정이다.

업무에 AI를 적극적으로 끼워 넣는 편이고, 새 도구가 나오면 빠르게 시도해본다. 이 리듬을 몇 년째 유지하고 있다.

그런데, 같은 속도로 불안도 자라고 있었다

같은 시기에 다른 감정도 함께 자랐다.

매일 보는 풍경이 이렇다. AI가 코드를 짠다. 디자인 시안을 뽑는다. 프로덕트 아이디어까지 던진다. 어제까진 사람이 모여 회의를 거쳐 만들던 결과물을, 오늘은 도구 하나가 1분 안에 초안으로 내놓는다. FE 6년차로 쌓아온 감각의 상당 부분이 빠르게 자동화되고 있다는 게 보인다.

회사 일이 재미없어진 건 아니다. 다만 5~10년 뒤를 생각하면, 툴이 좋아질수록 "FE 개발자 3명이 필요했던 자리가 1명으로 줄어드는" 구조가 가속될 것 같았다. 그 남는 1명이 되려면 "FE 잘 함" 만으로는 부족해질 거란 예감이 든다.

거기에 한 가지가 더 얹혀 있었다. 매일 쓰는 도구인데, 그 안이 어떻게 돌아가는지를 잘 모른다.

프롬프트에 따라 출력이 크게 달라지는데, 나는 그걸 대부분 "감"으로 판단한다.
컨텍스트 관리가 좋은 답을 만든다는 건 아는데, "왜 그런가"를 정확히 설명하진 못한다.
RAG, 임베딩, 벡터 DB 같은 단어들은 대충은 안다. 근데 내 사이드 프로젝트에 붙여보라고 하면 못 붙인다.
"이걸 AI에 맡길 수 있을까요?" 라고 기획자가 물어보면, 나는 보통 직관으로 답하고 있었다. 근거가 없다.

이건 마치 "자바스크립트 엔진이 내부에서 뭘 하는지는 모르지만, JS 코드는 잘 짜는 상태" 와 비슷한데, 그건 괜찮다. 6년간 V8이 뭘 하든 내 커리어에 별 지장이 없었으니까.

AI는 좀 다른 것 같았다. 내가 의사결정에 영향을 주는 쪽에 있었기 때문이다.

우리 서비스에 AI 기능을 붙일지 말지
어떤 모델을 쓸지, 어떤 비용을 감당할지
왜 이 프롬프트가 더 잘 먹히는지 동료에게 설명할 때
새로운 에이전트 도구를 도입할지 평가할 때

이런 자리에서 "직관"과 "설명"의 차이는 크다. "그냥 이렇게 해봤는데 잘 되더라고요"와 "이 모델은 retrieval 전에 query rewriting을 해서 recall이 20% 정도 올라가요"는 완전히 다른 발언이다.

그래서 결론이 났다.

"AI를 알고 쓰는 개발자"가 되고 싶다.

AI 엔지니어로 갈아타려는 게 아니다. 지금 하는 일을 더 오래, 더 단단하게 하기 위한 투자에 가깝다. 같이 수료하는 동료들을 보면, 본격 AI 엔지니어로 커리어를 바꾸려는 사람부터, 나처럼 현재 직군을 단단하게 하려는 사람까지 스펙트럼이 넓다. 목표가 어디든 밟아야 할 단계는 같다. 이 연재가 그 스펙트럼 어딘가에 서 있는 누군가에게 참고가 되면 좋겠다.

기존 자료로는 부족했다

이 결정 이후에 가장 먼저 한 일은, 당연히 "혼자 공부해보기" 였다. 무료·유료 강의를 결제했고, 책 몇 권을 샀고, Hugging Face·LangChain·OpenAI 공식 가이드를 쭉 훑었다. 유튜브에서 "RAG from scratch" 류도 봤다.

결과적으로 이 자료들은 한 지점까지는 데려다줬지만 거기서 딱 멈췄다. 그 지점이 어디냐면:

"Hello, LLM" 수준. OpenAI 키 꽂아서 간단한 챗봇 만들기. 내가 이미 할 수 있거나, 조금만 파면 할 수 있는 수준.
"튜토리얼 복붙" 수준. LangChain 문서를 따라가면 RAG 데모가 뜬다. 그런데 그게 내 프로덕션 서비스에 붙일 수준인지는 전혀 다른 문제다. 자료들은 대부분 여기서 멈춘다.
"개별 개념 소개" 수준. 임베딩이 뭔지, 청킹이 뭔지는 배운다. 근데 "왜 이 청킹 전략을 이 데이터에 쓰는 게 맞는지"는 아무도 안 가르쳐준다.

작동하는 것과 잘 작동하는 것 사이의 간극, 그리고 개별 개념과 시스템 설계 사이의 간극. 이 두 간극이 자료로는 잘 메워지지 않았다.

내가 정말 알고 싶었던 건 이 간극의 반대편이었다. "왜 이 프롬프트가 더 잘 먹히는지"를 시스템 관점에서 설명하는 것, "동작한다"와 "쓸 만하다" 사이를 수치로 증명하는 법, "이 문제는 RAG로 안 풀려요"라고 근거 있게 말할 수 있는 감각, 그리고 이상한 응답을 받았을 때 여러 원인 후보를 차례로 분리해내는 능력.

혼자 해보니, 이건 자료만 읽어서는 잘 안 쌓이는 감각 같았다. 실제 서비스 수준의 코드를 함께 굴려보고, 리뷰받고, 실패를 기록하는 환경이 필요했다.

결국 부트캠프를 골랐다

이 기준으로 몇 군데를 비교해봤고, 최종적으로 PI Lab (파이랩)으로 들어갔다. 선택 이유를 간단히만 적자면 — 커리큘럼이 "AI 호출해보기"에서 멈추지 않고, 하이브리드 검색·리랭킹·환각 방지·평가 시스템 구축처럼 혼자서는 거의 닿기 어려운 구간까지 밀고 나가는 구성이었다. 주말 페어 프로그래밍과 피어 리뷰가 있는 리듬도, 평소 회사에서 일하는 방식과 비슷해서 잘 맞겠다 싶었다.

8주가 어떤 궤적을 그리는가, 그리고 내가 도달하고 싶었던 자리

커리큘럼을 한 문장으로 요약하면 이렇다.

"AI 모델의 기본 원리"에서 시작해서, 그것을 "문서와 대화하는 시스템"으로, 그것을 "영상·음성까지 다루는 시스템"으로, 마지막으로 "실제 서비스에서 돌아가는 시스템"으로 쌓아 올리는 8주.

각 단계가 이전 단계의 전제 위에 올라선다. 기초를 안 밟으면 다음이 공중에 뜬다. 마지막 단계는 "되는 것"과 "쓸 만한 것"의 차이를 수치로 증명하는 훈련이다. 이게 혼자서는 닿기 어려운 구간이고, 내가 이 과정을 선택한 가장 큰 이유였다. 기술 스택도 자연스럽게 쌓인다. 파이썬 기반의 ML 도구들, 트랜스포머, 벡터 DB, 음성 처리, 비전 모델, 그리고 이 모든 것을 엮는 백엔드 아키텍처. FE 6년차인 나에게는 백엔드·데이터·ML을 한꺼번에 관통하는 드문 경험이다.

이 궤적을 따라가면서 내가 도달하고 싶었던 자리는 이 정도였다.

AI가 블랙박스가 아니게 된다. 이상한 응답을 받았을 때, 원인 후보를 같은 가중치가 아니라 우선순위로 의심할 수 있게.
"왜 이 프롬프트가 더 잘 먹히는지"를 구조로 설명할 수 있게 된다. 감이 아니라 근거로.
내 사이드 프로젝트에 RAG·멀티모달 기능을 진지하게 붙일 수 있게 된다. Hello 수준이 아니라, 실제로 쓸 수 있는 수준으로.
AI 시스템의 트레이드오프를 의사결정할 수 있게 된다. 모델 선택, 비용, 정확도, 응답 속도의 균형을 설계 문서로 쓸 수 있게.
실무에서 "이거 AI로 되나요?" 질문에 근거 있게 답할 수 있게 된다. "됩니다/안 됩니다"가 아니라 "이 조건에서는 이 정도 정확도로 가능하고, 이런 한계가 예상됩니다" 수준.
다음 커리어 선택지가 넓어진다. FE 전문가로 계속 갈 수도, AI 영역을 진지하게 파고들 수도, 그 중간 어딘가에 서 있을 수도 있게.

이 연재에서 다룰 것

이 글은 서론이다. 본론은 다음 다섯 편에서 풀어간다.

2편 — PDF RAG를 처음부터 만들어보면서 마주친 것들 PDF 챗봇을 한 사이클 굴려본 기록. 청킹 비교, 한국어 임베딩, 환각 방지, 멀티모달 PDF, 평가 체계.
3편 — 영상에서 자연어 검색되는 시스템을 만들어보면서 마주친 것들 영상 → STT → 비전 → 타임스탬프 검색까지. 모델 교체 3건, WER → CER 전환, 24분 영상을 1분 10초로.
4편 — 지표는 올랐는데 체감은 나빠졌다 — RAG 평가의 역설 두 사이클을 가로질러 발견한 평가 체계의 5가지 역설. Vision 환각, 임베딩 분포, 올바른 거부가 0점, 검색≠답변, LLM 비결정성.
5편 — 로컬에서는 됐는데요 — 배포 직전 한 달간 마주친 4가지 함정 런타임·인프라 레이어 트러블슈팅. async def 함정, AV1 코덱, 병렬화 ROI, "호환 API"의 함정.
6편 — 회사에서 "RAG 붙여주세요" 했을 때 — 내가 정리해본 4-Phase 구축 순서 앞의 5편을 거치면서 정리한 구축 순서. 문제 정의부터 프로덕션 하드닝까지의 단계별 회고.

맺으며

이 연재는 "AI를 더 잘 쓰고 싶어서 속을 들여다본 FE 개발자" 의 기록이다. 혹시 이 글을 읽는 당신도:

Cursor, Claude, ChatGPT를 이미 잘 쓰고 있는데 어느 순간 "이게 왜 되지?" 에 답을 못 해서 걸렸거나
AI 쪽으로 본격적인 커리어 전환을 고민 중이거나
기존 자료로는 "작동하는 것과 잘 작동하는 것의 간극"이 채워지지 않는다고 느낀다면

이 글이 조금이라도 지도가 되면 좋겠다. 출발점이 어디든, 밟는 단계는 비슷하다. 다음 편에서 본격적으로 시작한다.

프론트엔드 6년차 개발자가 PI Lab에서 AI 엔지니어링 8주 과정을 수료하며 정리한 기록입니다. 매일 Cursor·Claude로 바이브코딩하면서도 머신러닝 안쪽은 잘 몰랐던 개발자가, AI 시스템을 본격적으로 들여다본 회고입니다.