Claude Code로 터미널에서 AI랑 같이 코딩해보니, 생각보다 꽤 쓸 만하더라

요즘 개발자들 사이에서 AI 바이브 코딩이라는 말, 진짜 자주 들리죠. 저도 처음엔 좀 시큰둥했어요. 솔직히 말하면 “또 뭔가 그럴듯한 이름 붙여서 유행처럼 도는 거겠지” 싶었거든요. 그런데 막상 써보니까요, 이게 단순히 유행어로 넘길 물건은 아니더라고요.

특히 Claude Code를 터미널에서 써보면서 느낌이 좀 달라졌습니다. 웹 브라우저 열고, 코드 복사해서 붙여넣고, 다시 답변 받아서 IDE에 옮기고… 이런 흐름이 아니라 그냥 터미널 안에서 AI랑 바로 이야기하면서 코드를 만지는 방식이잖아요. 이게 생각보다 손에 착 붙어요. 뭐랄까, 개발 작업 흐름 안에 AI가 자연스럽게 들어온 느낌?

저도 개발자로 밥 먹고 산 지 벌써 20년 가까이 됐는데요. 그동안 참 많은 도구를 봤습니다. IDE도 바뀌고, 언어도 바뀌고, 프레임워크도 뜨고 지고… 그런데 Claude Code 같은 CLI 기반 AI 도구는 조금 결이 달라요. “나 대신 코딩해주는 도구”라기보다는 “옆자리에서 같이 봐주는 꽤 똑똑한 동료”에 가깝습니다. 물론 가끔 헛소리도 합니다. 사람 동료도 그러잖아요...

오늘은 제가 직접 Claude Code를 써보면서 느낀 점들, 그리고 토큰을 아끼는 방법, 프롬프트를 덜 삽질하게 쓰는 방법, 설정에 미리 넣어두면 편한 것들을 좀 편하게 풀어볼게요. 아주 정색하고 강의하는 글은 아니고요. 그냥 친한 개발자 친구한테 “야, 이거 써보니까 이런 건 좋고 이런 건 조심해야겠더라” 하고 말하는 느낌으로 봐주시면 좋겠습니다.

Claude Code가 뭐냐면, 터미널 안에 들어온 AI 개발 동료 같은 느낌이에요

Claude Code는 Anthropic에서 만든 CLI 기반의 AI 코딩 도구입니다. 아주 쉽게 말하면 터미널에서 Claude를 호출해서, 지금 작업 중인 코드에 대해 물어보고, 수정도 요청하고, 리팩토링도 부탁할 수 있는 도구예요.

보통 AI 코딩이라고 하면 웹에서 ChatGPT나 Claude를 열어놓고 코드를 복사해서 붙여넣는 장면을 떠올리잖아요. 저도 예전엔 그렇게 많이 했고요. 그런데 이 방식은 은근히 피곤합니다. 코드 복사하고, 설명 붙이고, 답변 받고, 다시 옮기고, 파일 위치 헷갈리고… 작은 작업은 괜찮은데 파일이 여러 개 엮이면 흐름이 금방 깨져요.

그런데 Claude Code는 터미널에서 바로 프로젝트 파일을 보고, 필요한 파일을 찾아가며 대화할 수 있다는 점이 꽤 큽니다. 개발자가 실제로 일하는 공간에 AI가 들어오는 거죠. 우리가 평소에 git 치고, npm 돌리고, 테스트 실행하고, 서버 로그 보는 바로 그 공간 말이에요.

생각해보면 개발자들, 특히 백엔드나 인프라 쪽 일을 오래 한 사람들은 터미널을 정말 많이 씁니다. 어떤 날은 IDE보다 터미널을 더 오래 보고 있기도 해요. 저도 배포 이슈 터지면 거의 터미널에 붙어 삽니다. 그런 공간에서 바로 “이 에러 로그 좀 봐줘”, “이 함수 리팩토링해줘”, “현재 변경사항 리뷰해줘”라고 말할 수 있다는 건 꽤 큰 변화예요.

처음에는 저도 “그냥 웹 Claude 쓰면 되는 거 아닌가?” 했습니다. 그런데 막상 터미널에서 직접 써보니까 다르더라고요. 파일 경로를 알고 있고, 변경된 코드를 확인해주고, git diff 기준으로 이야기할 수 있으니까 확실히 작업 밀도가 올라갑니다. 복붙 노동이 줄어드니까 머리도 덜 피곤하고요.

AI 바이브 코딩이 편하긴 한데, 토큰 관리는 진짜 신경 써야 합니다

AI 바이브 코딩을 하다 보면 처음엔 신납니다. “오, 이것도 해주네?”, “이것도 고쳐주네?” 하면서 이것저것 막 시켜보게 돼요. 그런데 어느 순간 현실이 옵니다. 바로 토큰 비용이죠.

AI 도구를 쓸 때 토큰은 그냥 돈이라고 보면 됩니다. 특히 프로젝트 규모가 커질수록, AI가 읽어야 하는 파일이 많아질수록 토큰은 순식간에 녹아요. 정말 녹습니다. 체감상 카드값 빠져나가는 속도랑 비슷해요. 농담 같지만, 많이 써보신 분들은 무슨 말인지 아실 겁니다.

그래서 Claude Code를 쓸 때는 “AI에게 최대한 많이 보여주자”가 아니라 “AI가 봐야 할 것만 정확히 보여주자” 쪽으로 생각을 바꾸는 게 좋아요. 이게 토큰도 아끼고, 결과물 품질도 좋아집니다. 너무 많은 맥락을 주면 똑똑해질 것 같지만, 실제로는 오히려 산만해질 때도 많거든요.

안 봐도 되는 파일은 과감하게 제외해두세요

프로젝트 루트에 .claudeignore 같은 제외 설정을 활용해서 AI가 굳이 읽을 필요 없는 파일이나 디렉토리를 빼두는 게 좋습니다. 예를 들면 이런 것들이죠.

• node_modules
• .git
• dist
• build
• coverage
• 대용량 로그 파일
• 자동 생성된 파일
• 민감한 설정 파일

이런 파일들은 사람이 봐도 별 도움이 안 되는 경우가 많잖아요. AI도 마찬가지입니다. 괜히 읽히면 토큰만 잡아먹고, 답변도 지저분해질 수 있어요.

저는 예전에 한 프로젝트에서 별생각 없이 전체 디렉토리를 열어두고 Claude Code를 썼다가, 불필요한 generated 파일까지 컨텍스트에 들어가면서 답변이 이상하게 길어지는 걸 겪었습니다. 그때부터는 프로젝트 처음 세팅할 때 제외 파일부터 정리해요. 이거 별거 아닌 것 같은데, 실제로 해보면 체감이 꽤 큽니다.

“이 코드 봐줘”보다 “이 파일의 이 함수를 이렇게 봐줘”가 훨씬 낫습니다

AI에게 모호하게 말하면 AI도 모호하게 답합니다. 이건 사람과 대화할 때랑 똑같아요. “이거 좀 괜찮게 해줘”라고 하면 상대방도 난감하잖아요. 뭘 괜찮게 하라는 건지, 성능인지, 가독성인지, 보안인지, 테스트인지 알 수가 없으니까요.

Claude Code에 요청할 때는 가능한 한 구체적으로 말하는 게 좋습니다. 예를 들면 이런 식이에요.

나쁜 요청: 이 코드 좀 봐줘.

괜찮은 요청: src/services/userService.ts 파일에서 getUserById 함수의 에러 핸들링을 개선해줘. 사용자가 없을 때 null을 반환하지 말고 NotFoundError를 던지는 방식으로 바꾸고, 관련 테스트도 같이 수정해줘.

이렇게 말하면 AI가 헤맬 여지가 확 줄어듭니다. 어떤 파일을 봐야 하는지, 어떤 함수를 고쳐야 하는지, 어떤 방향으로 바꿔야 하는지, 테스트까지 필요한지 다 알 수 있으니까요. 당연히 토큰도 덜 씁니다. 불필요하게 프로젝트 전체를 뒤지는 일이 줄어들거든요.

한 세션에 모든 일을 다 우겨 넣지 않는 게 좋아요

AI랑 대화하다 보면 은근히 사람처럼 이어서 말하게 됩니다. “아까 그거 말인데”, “방금 수정한 거 기반으로”, “이것도 같이 해줘” 이런 식으로요. 물론 작은 작업은 괜찮습니다. 그런데 작업이 길어지면 컨텍스트가 점점 무거워지고, AI도 앞뒤를 헷갈리기 시작합니다.

저는 요즘 작업 단위를 꽤 잘게 나누는 편이에요. 예를 들어 API 엔드포인트 하나 추가하는 작업을 끝냈으면, 그다음 리팩토링은 새 세션에서 시작합니다. Claude Code에서 컨텍스트 초기화 기능이나 새 대화 흐름을 적절히 쓰면 훨씬 깔끔해요.

사실 저도 처음엔 한 세션에 모든 걸 다 몰아넣었습니다. “이왕 여기까지 이야기했으니 계속 이어서 하자” 싶었거든요. 그런데 어느 순간부터 Claude가 예전 맥락을 붙잡고 엉뚱한 제안을 하더라고요. 그 뒤로는 작업이 끝나면 미련 없이 끊습니다. 사람도 회의가 너무 길어지면 집중력 떨어지잖아요. AI도 비슷하게 다뤄야 하더라고요.

프롬프트는 어렵게 생각하지 말고, 일을 잘 시키는 대화라고 보면 됩니다

프롬프트 작성법이라고 하면 괜히 거창하게 들리죠. 프롬프트 엔지니어링, 역할 부여, 제약 조건, 출력 포맷… 이런 말들이 나오면 좀 피곤해집니다. 저도 그렇습니다. 하루 종일 코드 보는데, AI에게 말 거는 법까지 논문처럼 공부하고 싶진 않거든요.

그런데 실전에서 느낀 건 단순해요. AI에게 일을 잘 시키려면, 사람에게 일을 잘 부탁하듯 말하면 됩니다. 다만 사람보다 조금 더 구체적으로 말해줘야 해요. 사람은 눈치가 있는데 AI는 눈치가 있는 척을 하거든요. 이 차이가 큽니다.

역할, 맥락, 요구사항, 제약조건을 한 번에 알려주면 답변이 좋아집니다

Claude Code에게 요청할 때 저는 보통 이런 흐름으로 말합니다.

• 어떤 역할로 봐줬으면 하는지
• 현재 프로젝트나 코드의 맥락이 뭔지
• 구체적으로 무엇을 바꾸고 싶은지
• 절대 깨면 안 되는 조건이 뭔지
• 테스트나 문서 수정이 필요한지

예를 들면 이런 식입니다.

너는 TypeScript와 NestJS를 오래 다룬 시니어 백엔드 개발자 관점으로 봐줘. 현재 user-service 모듈에서 초대 기능을 추가하는 중이야. src/modules/user/user.controller.ts에 POST /users/invite 엔드포인트를 추가하고, service 레이어에 inviteUser 함수를 만들어줘. 기존 인증 가드와 응답 포맷은 유지해야 하고, 관련 unit test도 같이 작성해줘.

이 정도만 적어도 답변 품질이 꽤 달라집니다. 특히 “기존 인증 가드와 응답 포맷은 유지” 같은 제약조건이 중요해요. AI가 코드를 고치다 보면 가끔 자기 마음대로 구조를 바꾸거나, 기존 스타일을 무시하는 경우가 있거든요. 그래서 안 되는 걸 미리 말해줘야 합니다.

출력 형식을 미리 정하면 토큰도 아끼고 마음도 편합니다

AI 답변이 길어서 좋은 경우도 있지만, 코딩할 때는 오히려 짧고 정확한 게 더 좋을 때가 많습니다. 특히 이미 맥락을 알고 있는 상태라면 장황한 설명은 별로 필요 없어요. 그래서 저는 출력 형식을 자주 지정합니다.

• 변경된 코드만 보여줘.
• diff 형식으로 보여줘.
• 설명은 짧게 하고, 수정 파일 목록을 먼저 알려줘.
• 코드를 바로 적용하지 말고 계획만 먼저 제안해줘.
• 테스트 케이스 이름과 의도만 먼저 정리해줘.

이렇게 말하면 Claude가 불필요한 말을 덜 합니다. 토큰도 아끼고, 내가 원하는 방식으로 검토하기도 좋아요. 특히 회사 코드처럼 바로 수정하면 부담스러운 경우에는 “먼저 계획만 제안해줘”가 꽤 유용합니다. 이거 습관 들이면 사고를 많이 줄일 수 있어요.

멀티파일 작업은 파일 이름을 콕 집어주는 게 안전합니다

Claude Code의 매력 중 하나가 여러 파일을 함께 다루는 겁니다. controller, service, repository, test 파일이 줄줄이 엮인 작업을 한 번에 요청할 수 있죠. 그런데 여기서 방심하면 사고 납니다.

“이 기능 추가해줘”라고만 하면 AI가 알아서 관련 파일을 찾으려고 합니다. 잘 찾을 때도 있지만, 프로젝트 구조가 복잡하거나 비슷한 이름의 파일이 많으면 엉뚱한 곳을 건드릴 수 있어요. 그래서 저는 가능한 한 수정해야 할 파일을 직접 지정합니다.

예를 들면 이렇게요.

src/modules/user/user.controller.ts, src/modules/user/user.service.ts, src/modules/user/user.service.spec.ts 세 파일만 수정해서 초대 기능을 추가해줘. 다른 모듈 구조는 건드리지 말아줘.

저는 예전에 “이 컨트롤러에 라우트 하나 추가해줘”라고 대충 말했다가, Claude가 비슷한 이름의 admin 컨트롤러를 건드린 적이 있습니다. 다행히 git diff 보고 바로 잡았지만, 그 순간 좀 식은땀이 나더라고요. 그 뒤로는 파일 경로를 직접 박아 넣습니다. 귀찮아 보여도 결국 이게 빠릅니다.

설정은 초반에 조금 귀찮아도, 해두면 나중에 계속 편합니다

Claude Code를 그냥 기본값으로 써도 꽤 쓸 만합니다. 그런데 개발 도구라는 게 그렇잖아요. 내 손에 맞게 조금만 손봐두면 생산성이 확 올라갑니다. VS Code 단축키 세팅해두는 거랑 비슷해요. 처음엔 귀찮지만, 한 번 맞춰두면 몸이 기억합니다.

다만 설정 파일 이름이나 지원 방식은 Claude Code 버전에 따라 조금씩 달라질 수 있으니, 실제 적용할 때는 공식 문서를 한 번 확인하는 게 좋아요. 여기서는 제가 실무에서 중요하다고 느낀 방향 위주로 이야기해볼게요.

프로젝트 규칙은 CLAUDE.md 같은 문서에 적어두면 편합니다

프로젝트마다 코딩 스타일이 다르잖아요. 어떤 팀은 함수형 스타일을 좋아하고, 어떤 팀은 명시적인 클래스를 선호하고, 테스트 네이밍 룰도 다르고요. 이런 걸 매번 AI에게 설명하는 건 꽤 귀찮습니다.

그래서 프로젝트 루트에 CLAUDE.md 같은 안내 문서를 두고, Claude가 지켜야 할 규칙을 적어두면 좋아요. 예를 들면 이런 내용입니다.

• TypeScript strict 모드를 기준으로 작성할 것
• 기존 코드 스타일을 우선 따를 것
• 함수 이름은 명확하게 작성할 것
• 에러 처리는 기존 CustomError 패턴을 사용할 것
• 코드 변경 시 관련 테스트도 함께 수정할 것
• 불필요한 리팩토링은 하지 말 것

여기서 저는 “불필요한 리팩토링은 하지 말 것”을 꽤 중요하게 봅니다. AI가 가끔 의욕이 넘쳐요. 내가 라우트 하나 추가해달라고 했는데 주변 구조까지 예쁘게 바꾸려고 할 때가 있습니다. 고마운데, 실무에서는 그게 위험할 때가 많거든요. 작은 변경은 작게 끝나는 게 좋습니다.

VS Code 터미널에서 같이 띄워두면 흐름이 제일 자연스럽습니다

저는 보통 VS Code에서 왼쪽은 코드, 아래나 오른쪽은 터미널로 두고 Claude Code를 사용합니다. split view로 열어두면 Claude가 제안한 변경사항을 바로 확인할 수 있어서 편해요.

터미널만 보면 뭔가 멋있어 보이긴 하는데, 실제 개발할 때는 코드 전체 흐름을 눈으로 같이 보는 게 중요합니다. AI가 수정한 코드가 문법적으로는 맞아도, 우리 프로젝트 스타일과 안 맞을 수 있거든요. 그래서 저는 Claude에게 일을 시키고, 에디터에서 diff를 확인하고, 테스트 돌리고, 다시 수정 요청하는 식으로 씁니다.

이 흐름이 익숙해지면 꽤 빠릅니다. 마치 옆에 주니어 개발자가 초안을 만들어주고, 제가 리뷰하는 느낌이에요. 물론 가끔은 주니어보다 훨씬 빠르고, 가끔은 주니어보다 더 자신 있게 틀립니다. 그래서 웃기기도 하고 무섭기도 합니다.

민감한 정보는 AI에게 보여주지 않는 습관을 들이세요

이건 정말 중요합니다. API key, 비밀번호, 토큰, 고객 정보, 운영 DB 접속 정보 같은 건 절대 AI에게 그대로 보여주면 안 됩니다. 개인 프로젝트라도 습관을 잘 들여야 해요. 회사 프로젝트라면 더 말할 것도 없고요.

Claude Code를 쓸 때는 민감한 파일을 제외 설정에 넣거나, 환경변수 파일을 직접 읽지 않게 관리하는 게 좋습니다. .env, secret 관련 yaml, 인증서 파일 같은 건 특히 조심해야 합니다.

• .env
• .env.local
• *.pem
• *.key
• credentials.json
• 운영 환경 설정 파일

AI 도구를 잘 쓰는 것도 중요하지만, 보안 감각을 잃으면 안 됩니다. 개발 생산성 몇 퍼센트 올리려다가 보안 사고 나면 정말 큰일 나요. 이건 20년 개발하면서 뼈저리게 느낀 부분입니다. 편한 도구일수록 경계심은 조금 남겨둬야 합니다.

자주 쓰는 요청은 커스텀 명령처럼 만들어두면 손이 편합니다

반복해서 쓰는 프롬프트는 따로 저장해두는 게 좋습니다. Claude Code에서는 프로젝트나 사용자 설정에 따라 커스텀 명령, slash command 비슷한 방식으로 자주 쓰는 요청을 구성할 수 있습니다. 이것도 버전에 따라 경로와 방식은 달라질 수 있으니 확인은 필요하고요.

제가 자주 쓰는 요청은 대충 이런 것들입니다.

• 현재 브랜치의 변경사항을 코드 리뷰해줘.
• 테스트가 부족한 부분을 찾아서 테스트 케이스를 제안해줘.
• 이 모듈에서 복잡도가 높은 함수를 찾아줘.
• 성능상 문제가 될 만한 쿼리나 반복문을 봐줘.
• 배포 전에 확인해야 할 위험 요소를 체크해줘.

매번 긴 문장을 치는 것도 은근히 귀찮습니다. 이런 건 템플릿으로 만들어두면 좋아요. 사실 개발 생산성이라는 게 엄청난 한 방에서만 나오는 게 아니더라고요. 이런 작은 귀찮음을 하나씩 없애는 데서 꽤 많이 올라갑니다.

Claude Code가 만능은 아닙니다, 그래서 더 잘 써야 해요

여기까지 보면 제가 Claude Code를 엄청 찬양하는 것처럼 보일 수 있는데요. 그렇진 않습니다. 저는 AI 도구를 꽤 좋아하지만, 동시에 꽤 의심하면서 씁니다. 이게 제 나름의 원칙이에요. 믿되, 반드시 검증한다. 진짜 이 말이 딱 맞습니다.

복잡한 작업은 생각보다 오래 걸릴 수 있습니다

Claude Code가 빠를 때는 정말 빠릅니다. 단순한 코드 생성, 테스트 초안, 함수 분리 정도는 사람이 하는 것보다 훨씬 빨라요. 그런데 프로젝트 전체 구조를 봐야 하거나, 여러 모듈의 의존성을 고려해야 하는 작업은 생각보다 시간이 걸립니다.

가끔은 AI가 한참 생각하다가 답을 주는데, 그 답이 기대보다 평범할 때도 있어요. 이럴 때 괜히 답답해집니다. “내가 직접 했으면 벌써 했겠다” 싶은 순간도 있고요. 그래서 저는 큰 작업을 한 번에 맡기기보다, 작은 단위로 나눠서 진행합니다.

예를 들어 “결제 모듈 전체를 리팩토링해줘”보다는 “payment.service.ts에서 validatePaymentInput 함수만 먼저 분리해줘”가 훨씬 낫습니다. 작은 성공을 쌓는 방식이 안전합니다.

맥락 이해는 똑똑하지만 완벽하지 않습니다

AI가 코드를 꽤 잘 읽긴 합니다. 그런데 프로젝트 전체의 역사나 팀의 암묵적인 규칙까지 이해하는 건 아닙니다. 예전에 왜 이렇게 짰는지, 어떤 장애를 겪고 이런 구조가 됐는지, 어떤 팀원이 어떤 이유로 이 패턴을 고집하는지… 이런 건 모릅니다.

그래서 Claude가 제안한 코드가 “그럴듯하지만 위험한” 경우가 있어요. 문법도 맞고 테스트도 일부 통과하는데, 운영 환경에서는 문제가 될 수 있는 그런 코드요. 특히 인증, 권한, 결제, 정산, 배치 작업 같은 영역은 절대 AI에게만 맡기면 안 됩니다.

AI는 초안을 빠르게 만들어주는 도구로 봐야 합니다. 최종 책임은 여전히 개발자에게 있어요. 이건 앞으로 AI가 더 좋아져도 당분간은 변하지 않을 것 같습니다.

비용은 생각보다 현실적인 문제입니다

토큰 기반 도구는 많이 쓰면 비용이 나옵니다. 이건 피할 수 없어요. 개인 프로젝트에서는 크게 부담 안 될 수 있지만, 회사에서 여러 명이 매일 쓰기 시작하면 비용이 꽤 커질 수 있습니다.

그래서 저는 AI 사용도 일종의 개발 리소스라고 봅니다. 서버 비용, CI 비용, 모니터링 비용처럼 관리해야 하는 항목이라는 거죠. 막 쓰면 편하긴 한데, 팀 단위에서는 어느 정도 룰이 필요합니다.

• 대용량 파일은 제외한다.
• 작업 단위로 세션을 나눈다.
• 출력 형식을 짧게 지정한다.
• 불필요한 설명은 요청하지 않는다.
• 반복 요청은 템플릿화한다.

이 정도만 해도 비용이 꽤 줄어듭니다. 실제로 저도 한동안 아무 생각 없이 쓰다가 토큰 사용량 보고 살짝 놀란 적이 있어요. 그 뒤로 프롬프트를 짧고 정확하게 쓰는 습관을 들였고, 불필요한 파일 제외도 꼼꼼히 하기 시작했습니다. 그러니까 확실히 낭비가 줄더라고요.

제가 요즘 Claude Code를 쓰는 방식은 이렇습니다

요즘 저는 코드를 처음부터 끝까지 직접 다 치기보다는, Claude Code에게 초안을 만들게 하고 제가 리뷰하는 방식으로 많이 일합니다. 특히 반복적인 코드나 테스트 코드, 단순한 CRUD, 타입 정의, 마이그레이션 초안 같은 건 AI에게 맡기면 속도가 꽤 납니다.

대신 중요한 로직은 제가 직접 봅니다. 비즈니스 규칙, 장애 날 수 있는 경계 조건, 보안 관련 부분, 데이터 정합성 같은 건 절대 대충 넘기지 않아요. AI가 아무리 잘해도 그 부분은 개발자의 책임이라고 생각합니다.

제 작업 흐름은 대략 이렇습니다.

• 작업 범위를 작게 정합니다.
• Claude에게 수정할 파일과 목표를 명확히 말합니다.
• 바로 수정하지 말고 계획을 먼저 달라고 할 때도 있습니다.
• 제안이 괜찮으면 코드 변경을 요청합니다.
• git diff로 변경사항을 확인합니다.
• 테스트를 돌립니다.
• 이상한 부분은 다시 짧게 수정 요청합니다.

이 방식이 가장 안정적이더라고요. AI에게 한 번에 모든 걸 맡기면 편해 보이지만, 나중에 검토 비용이 더 커질 수 있습니다. 반대로 너무 잘게 시키면 대화가 많아져서 피곤하고요. 적당한 단위, 이게 중요합니다. 말은 쉬운데 해보면 감이 생깁니다.

AI 바이브 코딩 시대에 개발자에게 더 중요해진 것들

Claude Code 같은 도구를 쓰다 보면 묘한 생각이 듭니다. “이제 개발자는 뭘 해야 하지?” 이런 질문이요. 저도 처음엔 살짝 그랬습니다. AI가 코드를 이렇게 빨리 짜면, 개발자의 가치는 어디에 남을까 싶었거든요.

그런데 조금 써보니 오히려 반대에 가깝더라고요. 개발자의 기본기가 더 중요해졌습니다. AI가 만든 코드가 맞는지 틀린지 판단하려면, 결국 내가 알아야 하거든요. 구조를 알아야 하고, 테스트를 알아야 하고, 장애 포인트를 알아야 하고, 성능과 보안을 어느 정도 볼 줄 알아야 합니다.

AI는 속도를 올려줍니다. 하지만 방향을 정하는 건 여전히 사람입니다. 이상한 방향으로 빨리 달리면 더 빨리 망합니다. 이게 무섭죠.

그래서 저는 요즘 후배 개발자들에게도 AI를 쓰지 말라고 하지 않습니다. 오히려 쓰라고 해요. 대신 “답을 믿지 말고, 결과를 리뷰하는 눈을 키워라”라고 말합니다. AI 시대에는 코드를 치는 속도보다, 좋은 코드와 위험한 코드를 구분하는 감각이 더 중요해질 것 같아요.

그래도 저는 Claude Code, 꽤 추천합니다

여러 단점과 주의할 점을 이야기했지만, 그래도 저는 Claude Code를 꽤 추천하는 편입니다. 특히 터미널 작업에 익숙한 개발자라면 한 번쯤 써볼 만해요. 손에 맞으면 정말 편합니다.

다만 처음부터 너무 큰 기대를 하면 실망할 수도 있습니다. “내 일을 다 대신해주겠지”라고 생각하면 안 되고요. “내가 하던 귀찮은 일의 일부를 꽤 빠르게 도와주는 도구” 정도로 시작하면 만족도가 높습니다.

토큰을 아끼려면 필요한 파일만 보여주고, 요청은 구체적으로 하고, 작업 단위로 세션을 나누는 게 좋습니다. 프롬프트는 어렵게 생각하지 말고, 일 잘하는 동료에게 부탁하듯 맥락과 요구사항을 분명히 말하면 됩니다. 설정은 초반에 조금만 정리해두면 나중에 계속 편하고요.

저는 요즘 Claude Code를 쓰면서 개발이 조금 더 재미있어졌습니다. 반복 작업은 덜 지루해졌고, 리팩토링은 덜 부담스럽고, 테스트 작성도 예전보다 손이 덜 무거워졌어요. 물론 여전히 최종 확인은 제 몫입니다. 그건 어쩔 수 없죠. 개발자는 결국 책임지는 사람이니까요.

AI 바이브 코딩이 거창한 미래 이야기처럼 들릴 수도 있지만, 막상 써보면 그냥 오늘의 개발 습관이 조금 바뀌는 정도에서 시작합니다. 터미널 하나 열고, 작은 함수 하나부터 맡겨보세요. 아마 생각보다 금방 감이 올 겁니다. “아, 이거 잘만 쓰면 진짜 시간 좀 아끼겠는데?” 하는 순간이요...

🔍 관련 정보 더 보기