0. "한 번에 다 처리 안해도 되니까 조금씩만이라도 해봐"
1. Cursor와 함께 6개의 서비스를 만들었다
23살, 컴공 4학년이자 스타트업 개발자로서 지난 2년간 Curosr는 내 최고의 파트너였다. Jetpack Compose로 안드로이드 앱을, React Native(Expo)와 FastAPI로 웹/앱/서버(AWS까지...)를 6개나 뽑아냈고 난 내가 커서를 마스터했다고 생각했다. 하지만 프로젝트 규모가 커질수록, 어느 순간부터 커서가 '멍청하게' 느껴지기 시작했다.
2. 처음엔 이렇게 생각했다: "AI는 원래 이렇지 뭐"
처음 커서를 쓸때는 실제 서비스 코드베이스에서 AI가 이 정도까지 생산성을 올려줄 수 있구나,,, 감탄했다.
스타트업에서 안드로이드 키오스크 앱을 운영하고 있었고, 이후에는 React Native, FastAPI, AWS까지 다루며 앱/웹/서버를 계속 붙여나갔다. 물론 이상한 코드를 뱉을 때도 있었고, 정신을 잠깐 놓으면 말도 안 되는 방향으로 가는 경우도 많았다. 같은 에러를 몇 번씩 반복하며 설명해야 했고, 수정한 코드가 다른 곳을 깨뜨리는 경우는 기본이었다.
하지만 그때는 그냥 'AI는 원래 이런거지~', '내가 직접 코드를 치는 것보단 빠르잖아' 라고 생각했고 실제로도 그랬다.
특히 Cursor의 큰 장점은 'IDE 안에 있다'는 점이었는데,
- 코드가 실시간으로 어떻게 바뀌는지 바로 보였고,
- 어느 파일이 수정됐는지도 눈에 들어왔다.
CLI처럼 결과만 기다리는 게 아니라, 내가 직접 흐름을 통제하고 있다는 안정감이 있었다.
Claude Code가 더 좋다는 이야기는 예전부터 들었지만, 나에게 API 비용은 꽤 부담이었고
조금 돌아가더라도 비교적 저렴한 월정액으로 계속 갈 수 있다는 건 현실적으로 큰 장점이었다.
그래서 난 GPT, Gemini, Cursor를 계속 조합해가며 프로젝트를 만들었다.
- 로직 설계는 GPT와 함께,
- 구현은 Cursor로 하고,
- 설계에 의문증이 생기면 Gemini에게 질문하고,
- 다시 Curosr로 돌아와서 코드 수정하고
난 이 워크플로우가 꽤 효율적이라고 생각했다.
캐시 메모리를 최소한으로 쓰면서 각 AI에 적합한 방향으로 썼다고 생각했다.
적어도 프로젝트 규모가 커지기 전까지는...
3. 문제 발생 시작: 쉬운 문제에서도 맥락을 잃어
3-1. X-Username 인증 문제
JWT 인증을 구현하는게 번거로워서 로그인 기능 구현 전에 다른 기능을 하기 위해 회원의 username을 인증 헤더로 포함시키는걸로 임시 개발을 하고 있었는데, JWT 인증 구현 후에 해당 X-Username 인증 기능을 제거하지 않고 남겨뒀더니, 회원의 일부 정보가 보이지 않는 에러가 발생했다. 근데 다만 iOS에서는 조회되는데 Android에서는 조회가 안돼서 바로 X-Username이 원인이라는 걸 찾지 못했음...
해당 문제를 커서한테 말하니
"변수명을 name 대신 id로 써보세요" <- 이런다... X-Username 인증 로직을 바로 보지 못하고 뚱딴지 같은 소리를 하는 게 되게 surface-level의 코드만 보는구나... 느꼈다. (나중에 X-Username을 남겨놨다는 게 갑자기 떠올라서 이 문제를 짚어줬더니 그제서야 이해를 하더라)
-> 문제는 코드 한 줄이 아니라, 인증 경계가 두 개(JWT/X-Username)로 분리되어 있었다는 점
3-2. 다소 당황스러운 루프
무서워서 못하겠네...
3-3. 컴포넌트 재사용을 못함 -> Dirty Code
이 문제는 특히 프론트 작업할 때 심했는데, 회원가입 단에서 이름 입력 -> 생년월일 입력 등 디자인이 일관되어 있는 게 있어도 커서는 컴포넌트를 추상화해서 재사용하기보다, 화면 단위로 파일을 계속 복제하는 방식을 자주 선택했다. 뒤로 가기 버튼 위치나 '확인' 버튼 디자인이 변경되면 회원가입 단의 17개의 페이지를 모두 수정해야하는, 정말 더러운 코드였다. 솔직히 이게 제일 큰 문제였다. 유지보수가 어려운 코드는 정말 안 좋은 코드니까.
4. 진짜 문제가 뭐냐면: 성능이 아닌 interaction 방식
구현 단계에서 가장 답답했던 건, 내가 설명하지 않은 부분을 AI가 '적당히 추론해서' 구현해버리는 순간들이었다.
특히 설계 레벨의 결정은 한 번 잘못 굳어지면 이후의 전체 코드가 그 방향으로 흘러가버리는데, 몇 번 잘못 설계된 코드를 처음부터 뜯어 고친다고 고생을 많이 했었다. 그래서 난 어느 순간부터 구현 전에 항상 이런 말을 했다.
"구현하기 전에 모르겠는거나 나한테 물어볼 거 있나? 정확히 맞추고 가자"
즉 나는 autocoomplete이나 코드 몇줄의 파일 수정만 원한 게 아니었고, 아키텍처의 reasoning, 전체 시스템에 대한 그림을 그리고 있었는데 새삼 이런 나의 모습을 보면서 아 기존의 파일 수정을 원하던 내 요구사항이 지금은 설계의 관점으로 바뀌고 있구나, 라는 것을 느꼈다. 머릿속은 이미 에이전트를 원하고 있었는데, 손은 아직 도구에 갇혀있었다는 것을 느꼈다.
5. Claude Code를 시도한 결정적인 이유
내가 하고 있던 프로젝트가 '수천 개의 논문을 분석해 영양소 시너지와 부작용 및 효과적인 레시피를 산출하는 AI 엔진을 구축'하는 것이었고, 프로젝트 구조는 [논문 데이터 -> 근거 -> Rule Mapping -> Reduce] 하는 파이프라인이었다.
기존에 하던 플랫폼 구축보다 읽는 양이 워낙 방대하다 보니까 3시간만에 일주일치 할당된 토큰량을 다 쓸 정도로 소모되는 양이 너무 많았다. 1개월만에 MVP를 뽑아내긴 했지만, 가중치를 미세하게 조정하고 로직을 고도화하려니 커서와의 대화가 단편적이고 파편화되어있는 컨텍스트로 일관성을 자꾸 놓치고 있었다. 엔진의 전체 설계도를 보고 대화하고 싶은데 커서는 그 많은 부분 중 한 칸을 닦고 있는 느낌이었다.
파이프라인 구조상, 전체 데이터가 흐르는 규칙이 깨지지 않는 게 중요한데, 부분적인 코드 수정에 집중한 것이다. 이와 대비해서 클로드는 복잡한 룰과 컨텍스트를 기억하고 가중치를 조정하는 등의 파인튜닝에 강점이라는 것을 듣고 클로드 코드로 바꾸게 되었다.
6. 바꾸고 나니 포커싱 두는 문제 종류가 달라졌다
솔직히 난 가시성과 가성비가 주는 효율이 개발의 속도보다 더 크다고 생각했다. 하지만 프로젝트가 고도화되고 관리하는 범위가 넓어질수록, AI를 달래고 수동으로 코드를 옮기는 시간이 누적되면서 '아, 내가 아낀 돈보다 내 집중력과 시간이 더 빠르게 소모되고 있구나'라는 것을 느꼈다.
Claude Code로 커서와 최근에 싸우고 있던 문제에 대해 물어보니, 두가지 접근에 대한 트레이드오프를 비교분석했다. 커서도 물론 실행 가능한 두가지 옵션이 있을때 추천을 하긴 하는데, 커서는 surface-level에서 구조적으로 구현 속도가 빠른 것, 수정해야하는 코드 양이 적은 것 위주로 추천했다면, 클로드는 내가 설계하려는 의도를 파악하고 내 철학에 맞춰 트레이드오프를 제시하는 느낌을 받았다.
여기서 내가 느낀 건 '다른 사람과 같이 의견을 주고받는 느낌' 이었다. 구조적으로 틀린 게 아닌 철학적인 면을 파고들어서 의미상으로 틀린 부분을 잡아주는 게 전체 설계의 일관성을 유지하는 데 큰 도움이 될거라 생각이 들었다.
스타트업에서 홀로 개발자로 일을 하고 있다보니 설계나 구현 부분에서 의견을 나눌 사람이 없었고 단독으로 정하는 게 많아서 내가 놓치는 게 없는지가 항상 고민이었는데, 의견을 주고받을 수 있다는 것에서 내가 느끼고 있던 AI의 한계가 흐릿해지는 기분이었다. 든든한 개발자 동료를 둔 느낌,,, 오타를 고치는 시간 대신, 더 큰 아키텍처를 고민할 시간을 벌 수 있었던 건 개발 인생에서 정말 큰 변화점이 아니었을까 생각한다. 물론 코드가 변하는 과정이 보이지 않아서 내가 질문하는것과 답변하는것에 집중할 수밖에 없지만, 집중력이 소모되는 곳이 더 가치있는 '설계 문제'로 이동했다는 게 나에겐 정말 중요했다.
7. 도구의 문제가 아니라 워크플로우의 문제였던 것
지금 클로드를 한 달 정도 사용해본 기준으로는, 커서가 갑자기 멍청해진 건 아니었다. 오히려 나는 커서를 정말 많이 활용했고, 실제로 그걸로 여러 서비스를 출시했다. 빠른 프로토타이핑과 구현 속도 면에서는 지금도 강력한 도구라고 생각한다.
문제는 프로젝트 규모가 커지면서 내가 AI에게 기대하는 역할 자체가 달라지고 있었다는 점이다.
초반에 나는 '함수 에러 고쳐줘', 'API 연동해줘' , '이 화면 만들어줘' 정도의 요청만으로도 충분했다. 하지만 점점 시스템이 복잡해질수록 내가 원했던 건 단순 코드 생성이 아니었고,
- 왜 이 구조가 반복적으로 깨지는지,
- 이 수정이 다른 로직에 어떤 영향을 주는지,
- 데이터 흐름 전체에서 일관성이 유지되는지,
- 지금의 선택이 나중에 어떤 문제를 야기할 수 있는지
같은 걸 고민할 수 있는 사람 혹은 AI를 원하고 있었다. 하지만 난 계속 IDE 안에서 내가 언급한 파일 기준으로만 대화하고 있었고 그 순간부터 나에게 AI는 '내가 계속 맥락을 설명하고 관리해야하는 존재' 처럼 느껴졌다. 결국 내가 원했던 건 프로젝트 전체를 이해한 상태에서 구조와 맥락까지 함께 사고할 수 있는 존재에 가까웠다. 난 커서를 쓰고 있으면서도 이미 클로드같은 interaction을 원하고 있었던 것이다 !!