사람들이 Claude Code에 대한 극찬을 하는 걸 볼 때마다, 마치 다 인플루언서들이거나 터미널과 Emacs, Vim 같은 전통적인 툴에 열광하는 팬들뿐이라는 느낌을 지울 수 없음. 나는 항상 Claude Code가 Cursor보다 훨씬 낫다는 댓글을 볼 때마다 실제로 구독해 대규모 TypeScript 코드베이스에 적용해 보는데, 과정은 오래 걸리고 학습 곡선도 높음. 결과는 결국 Cursor 내장 Claude와 똑같으면서 더 느리고 불명확해서 코드 리뷰도 어려움. 지금은 그냥, 댓글의 열성팬들은 모두 후원받고 있거나 이미 200달러를 냈으니 자기 선택을 정당화하는 느낌이 듦. 솔직히 Cursor가 훨씬 생산성 높았음. 18년차 프로그래머로 매일 코드 많이 쓰지만 Gemini 2.5 Pro와 Claude 4.0을 번갈아 활용하며, 외려 Cursor로 더 많은 걸 얻고 있음. 아직 단 한 명도 날 설득한 적이 없음. 실질적 이점이 안 보임. 이후엔 생각이 달라질 수도 있겠지만, 지금은 전혀 못 느끼겠음
대부분의 사람들이 소프트웨어 개발에서 진짜 어려운 부분이 뭔지 깊이 오해하고 있다고 생각함. 실제 업무의 대부분은 복잡한 알고리즘 개발이 아니라 기존 아이디어를 잘 엮어서 맞춰 붙이는 일임. 하지만 그 모든 건 사전 명세·설계·아키텍처 등 선행 작업 뒤에 오는 일임. AI로 이런 프로그램을 뚝딱 만들어내는 게 멋져 보이고 데모에서는 빠르게 “끝낸” 것처럼 느껴지지만, 진짜 문제는 30년 간 써야 하는 시스템을 품질 기준 맞춰 제대로 만드는 것임. 프로토타입이나 일회성 목적에는 최고지만 장기적인 내구성엔 한계가 큼
이런 툴로 생산성을 극대화하려면 아주 짧고 빠른 피드백 루프가 핵심임. Cursor의 탭 자동완성 모델은 편집자가 뭔가를 하려는 걸 직감적으로 파악해서, 마치 미친 듯이 영리하게 감속기를 밟는 느낌임. 내가 머리 싸매고 매크로 프로그래밍할 필요 없이, 그냥 필요 없으면 Esc로 취소하면 되고 아니면 점진적으로 agentic 모드로 옮기면 됨. 완전한 에이전트 기반 에디터들은 15~30분씩 걸리고, 워크플로가 완전히 끊기는 문제도 있음. 결과물을 리뷰하는 게 일이고, 짧은 수용/거절 루프와는 비교도 안 되게 신경을 많이 씀. 네트워크 권한 줄지 오프라인으로 띄울지 고민도 커서, 유지보수/보안/신뢰성이 중요하지 않은 코드를 빨리 막 만들어야 할 때만 써볼 만함. 그 외엔 오히려 생산성이 떨어짐. 앞으로 나아지겠지만 현재는 확실히 Cursor에서 더 좋은 결과를 낼 수 있음
나도 예전엔 그렇게 느꼈지만 최근 Claude Code를 실제로 써보니 Cursor보다 훨씬 낫다고 느낌. 왜 그런지는 잘 모르겠으나 Claude가 전체 구조를 더 잘 파악하고 불필요한 수정을 잘 피하는 듯함. 물론 직접 방향을 잡아줘야 할 때도 있지만 효율성이 훨씬 더 높음. 특징 중 하나는 보통 한 번에 하나의 파일만 딱 보여주니까 리뷰하기 훨씬 쉬움. Cursor는 여러 파일을 한꺼번에 열고, 변화량이 많아서 빠르게 파악하기 힘듦. 참고로 난 VSCode 터미널 창에서 Claude Code 확장 프로그램을 이용함. Claude가 바꿔줄 파일 탭을 열어 변경안을 제안함
아직 사람들이 모르는 건 Cursor는 하나의 완성된 제품이 아니라, 모든 툴들이 빨리 따라잡으려고 추가하는 기능 묶음이라는 점임. 진짜 교훈은, 딥 인터페이스 말고도 각자 원하는 편집기로 베스트 인 클래스 에이전트 솔루션을 결합하려는 전략이 있음. 이런 경험들이 결국 “베스트 프랙티스”로 응집돼서, 사람들이 자기 편집기나 IDE에서 자연스럽게 적용하고, 이런 vscode 포크들은 다 사라질 것임
한 달도 안 되는 기간 17달러 요금제로 썼는데, 신기함과 답답함이 반반임. 러스트로 8천 줄, 마크다운으로 1만 2천 줄을 썼고, 작업명세와 구체적 태스크를 마치 테스트하네스와 같은 방식으로 분리해서 인공지능과 상호작용함. 마법이 VC 보조금 때문인지 뭔지 모르겠지만, 러스트가 마치 스크립트 언어처럼 느껴질 정도였음. (참고: GitHub 저장소는 ‘knowseams’임)
내가 AI에서 제일 좋은 점은, 귀찮을 때 “이거해줘” 하면 된다는 점임. 결과물이 좋든 별로든 상관없음. 일단 시작점 만들어줌
LLM 덕분에 백지 공포가 없어짐. 복잡한 맥락을 다시 머릿속에서 되살릴 필요 없이 “우리 뭘 하고 있었지?”, “이 코드는 뭐였지?”라고 물어보면 AI가 금방 설명해주고, 곧바로 다시 몰입할 수 있음. 루버덕 디버깅이나 반복적 사소한 작업(yak shaving)까지 엄청 빠르게 처리해줘서 진짜 유용함. Slack, Notion, Linear 등과도 연동해 써서 내겐 태스크/프로젝트 관리 툴임
스스로 직접 하고 싶을 때도, AI에게 계획을 짜달라고 해서 마크다운에 남겨둠. 오늘도 refactor 계획을 부탁했는데, 40개 파일로 된 프로토타입 코드 블록을 아래에서부터 구조변경하는 식으로 잘못 접근함. 만약 그 방향대로 실수했다면 디버깅에 엄청난 시간이 걸렸을 듯. 그래도 공격 포인트를 제공해주고, 계획도 한 시간만에 고쳐서 적용함. 내가 혼자 했다면 복잡함에 질려 시작도 못했거나, 문서화 반복하다 포기했을 것 같음
하루 끝엔 더 이상 집중이 안 돼서 쓰거나 되돌리는 양이 비슷해질 때 AI에게 핸들을 맡겨 한숨 돌릴 수 있음. 작은 이슈는 diff만 슬쩍 보면 되고, 어려운 이슈도 구체적으로 뭐가 문제인지 알면 AI를 방향 잡아주며 설득하면 됨. 작업의 40~60% 정도 완성되면 직접 이어받아 finish하는 편임. 평소에는 내가 날카로운 시간대에 집중해서 직접 사고하며 개발하고, 남는 야근이나 반복잡무는 AI에게 맡겨 익일 준비나 좀 더 고차원 글쓰기·설계를 주로 함
난 그냥 산책하고 커피를 마심. 인간문제는 인간적인 방식으로 해결하는 게 좀 더 자연스러운 느낌임
Claude Code는 뭐라고 설명하기 힘들 정도임. 사용한 뒤로는 아예 직업을 바꾼 것 같은 기분까지 들었음. 기존에도 Claude를 전면 워크플로우에 도입했지만, Claude Code는 그야말로 “스테로이드” 급임. 아직 안 써봤으면 무조건 추천임. 진짜로 주니어 엔지니어와 함께 일하는 느낌을 처음 받았음
내 경험은 정반대임. 무언가 지시하면 몇 분 걸려 뭔가 결과를 주는데, 실제로는 앱이 망가져 디버깅하다 보면 완전히 엉뚱하게 작업해서 결국 다 버림. 그럼에도 Claude를 계속 잡는 건 다른 사람들처럼 잘만 굴러가면 너무 좋기 때문임. 현실은 부일러플레이트만 뽑고, 직접 디버깅을 꽤 해야 하며, 최악이면 한 시간과 토큰만 날림
오늘 처음 회사에서 써봤는데 Cursor보다 압도적으로 혁신적인 변화임. 같은 파운데이션 모델을 씀에도 완전히 다른 경험임. 한 달 전에는 AI 때문에 일이 더 느렸는데, 오늘 Claude Code로 20분 만에 처리가 끝났고, API 사용료도 10달러가 채 안 듦. 문맥 관리에 신경 쓸 일이 매우 적었고, Claude Code는 스스로 필요한 맥락을 찾아넣어 훨씬 오랜 시간 동안 생산적으로 작업함. Cursor의 agent 모드는 3~5분짜리 작업까지만 쓸만하지만 Claude Code는 10분 넘는 작업에서도 자기 길을 잃지 않고 꾸준히 진전시킴. 도구 사용도 탁월하고, 루프에 잘 갇히지 않는 점이 놀라움
“주니어 엔지니어와 일하는 듯하다”고 했는데, 내가 느낀 건 오히려 내가 부하직원이고 Claude가 상사 같음. “내가 이런 멋진 거 해냈어요!”라고 자랑하면 “근데 그건 내가 시킨 게 아니야…” 라고 반응하는 느낌임
어떤 작업, 언어, 도메인에서 활용했는지 더 구체적으로 설명해줄 수 있음? 모두 케이스가 너무 달라서 궁금함
나도 같은 경험임. Claude는 단순 주니어 그 이상임. 옵션 제안이나, 결정을 위한 추천, 그리고 트레이드오프 시각화를 너무 잘해줌
실제로 Claude Code로 앱이나 라이브러리를 만드는 워크스루 사례가 많지 않음? 나는 단순 “신기함”을 말하는 글보다 진짜 해당 툴로 실전 개발하는 모습을 보고 싶음. 그런 사례 모음이 있음 정말 좋겠음
뭔가 전체적으로 이 상황이 조금 이상하게 느껴짐. Claude Code 자체는 분명 좋고, 훨씬 빠르게 문서나 스택오버플로를 찾는 데 쓸 수 있음. 하지만 만약 과장된 소문이 사실이라면, 이런 툴로 엄청난 속도로 소프트웨어 혁신이 일어나야 하지 않냐는 의문이 듦. Stripe CEO는 AI 툴이 생산성 100배 증가라 했는데, 3~4개월 지났으면 지금쯤 Stripe는 로켓 발사해야 하지 않음? Microsoft도 AI코딩 올인하였다는데 Teams는 왜 여전히 별로 같지? 1년 넘게 이 툴이 혁신이라는데, 실제 현실은 3~4년 전과 큰 차이가 없는 듯함
최근 눈에 띄는 두 가지 트렌드는 (1) 비숙련자가 사소한 프로젝트에 AI를 쓰는 것, (2) 개발자가 전체 앱 구조와 파일, 인터페이스, 테크 스택, 테스트 프레임워크까지 빽빽하게 미리 명세해두고 LLM에 세밀하게 핸들링을 시켜 괜찮은 결과를 겨우 끌어내는 것임 YouTube 예시. PR/유튜브 등에서 들려오는 80~99%의 얘기는 사실상 첫 번째 그룹에서 나옴. 생산성 상승을 느끼는 건, LLM과 대화·문서화·유도·수정하는 일이 직접 개발하는 것보다 덜 피곤하게 느껴져서임. 시간이나 총노력은 똑같아도 기대치를 덜기 때문임
유튜브에서 진짜 생산성 부스트를 내는 현장 스트림/사례를 찾고 있는데, “와 진짜 빠르다!”고 느낀 케이스는 못 봄
찬반 양극단 의견이 많지만 정작 대다수는 조용히 각자 커밋하고 있음(이 말 자체가 아이러니). 내 경우, 작업에 따라 1.5~10배까지 빨라짐을 реально 체감함. 가장 큰 이점은 순수 창조적·일회성·보일러플레이트·리팩토링류 작업에서 인지적 부하가 크게 줄어서, 일관된 성과를 유지한다는 점임. 여전히 “손코딩”도 많이 하고, 거의 모든 라인을 끝까지 리뷰함. 몇 시간째 혼자 돌려놓는 일은 Nightmare임. 실제로 10년 넘게 유지 중인 프로덕션 앱에서도 어딘가 블로그에 홍보할 시간도 없음. 반면 아주 슬림한 조직이라 전체 시스템 문맥도 내 손에 쥐어져 있어 문제를 더 빠르게 파악할 수 있는 면도 큼. 자기 효율성 확보가 중요한 환경에선 확실히 근본을 키움. 대규모 조직에선 이런 경험 얻기 힘듦
내 경험상 Claude.md라는 마크다운 파일을 각 코드폴더 루트에 둬서, 파이프라인처럼 미니멀한 룰셋을 추가함. 테스트 생성과 배치는 지정된 폴더 및 방식에 꼭 맞게 하고, 디버그 파일 생성을 막음. 새로운 클래스나 구조의 난립을 막고, 꼭 필요한 경우 외엔 재사용하도록 룰을 걸어둠. 프롬프트도 길게 적지 않고, 대개 불확실한 부분만 계획서를 작성함. LLM의 지식범위를 벗어난 신상 이슈에도 큰 입력은 최소한으로만 전달함. 이런 방식으로 1 input–1 output(뎁스까지 다 적용) 결과를 일관성 있게 얻음. 최근엔 Claude Code 대신 CLI 모드로 Opus 등 다른 대형 모델을 더 저렴하게 써서 옮겨갔음. CLI가 진짜 파워임. 60~70개의 에이전트 스트림을 동시에 돌리고 있고, 2억 토큰 규모(react/typescript/golang) 코드베이스도 무리 없이 관리. 단 한두 번 정도만 추가 지시한 경험
에이전트 스트림으로 어떤 걸 운영하는지 리스트 가능함? 매우 궁금함
Anthropic 외에 어떤 모델을 쓰는지 알고 싶음. Kimi K2는 써봤는데, 내 사용에 별로임
"에이전트 스트림"이란 게 무엇을 의미하는지 궁금함. 60~70개를 어떻게 관리하는지, 인지적 부담이 상상도 안 됨
가끔 Claude Code로 특정 작업을 할 때 생산성이 극적으로 오름. Slash command를 활용해서 이전 대화를 slash command로 만드는 방식을 추천함. 이렇게 하면 점점 더 활용 가능한 프리미티브 명령어 세트를 쌓아갈 수 있음. 내 사례는 GitHub에 올려둠 make-command.md, improve-command.md
비결정론적 블랙박스를 프로그래밍하려 든다는 점이 정말 대단하다고 생각함. 용기 진짜 대단
PSA(공익 정보): 이 저장소로 어떤 모델과도 Claude Code를 연동할 수 있음. 최신 Kimi-K2가 꽤 잘 동작한다고 알려짐
나도 Kimi-K2 써봤는데, Sonnet/Opus 4.0보다는 성능이 떨어지고, tool calling은 Gemini 2.5 Pro보다는 나은 편임. Claude Max(월 100~200달러)가 부담스러우면 강추함. 모델 자체가 군더더기 없이 매우 간단해서 좋음. Anthropic도 차라리 Claude Code 오픈소스화하면 cli coding agent계의 VSCode가 될 수 있을 듯. 그리고 opencode도 추천함. 모든 모델 네이티브 지원 및 Claude Code 유사 기능 제공
여러 모델로 쓸 거라면 sst/opencode를 그냥 추천함(나도 Claude Pro로 씀)
참고로 CC를 아직 못 써본 사람들은 – CC 클라이언트를 npm으로 받아 무료로 쓸 수 있음
Claude Code, local LLM, Continue, VSCode로 간단한 파이썬 앱을 “vibe coding” 하며 놀다가, Claude 무료티어를 알게 되어 진행중이던 코드와 LLM 결과물을 넣어봤음. 오류와 업데이트를 한 번에 정확히 정리·수정해줘서 신남! 그래서 다음 단계로 pygame 기반 2d 게임(마닉 마이너 스타일) 프로젝트의 스펙과 프롬프트를 ChatGPT로 짜고 Claude에 넣어보니, Claude가 계속 없는 메서드를 참조하거나 코드베이스 버전 차이 운운하며 헛소리를 함. 라인 넘버와 주변 코드로 콕 찝어줘도 여전히 gaslighting 중. 어떻게 해결하면 좋을지, 완벽은 바라지 않지만 local LLM 때랑 비슷한 한계에 막힌 느낌임. 건강이 안 좋아 간헐적으로 하는 거라 조언 부탁함
“모호한 인터페이스와 숨어있는 전제들이 가득한 코드 지옥”에 빠졌을 확률이 큼. 이럴 땐 차라리 기존 ChatGPT 결과물 모두를 요약해, 현재 게임이 무엇을 하는지/모든 기능을 깊게 리스트업한 다음, 그 문서를 Claude에 넣고 요구사항을 처음부터 다시 break down하면 훨씬 깔끔한 결과를 얻을 수 있음. Claude는 zero-shot으로도 훌륭한 샘플을 낼 수 있고, 최악이어도 반복적으로 자체 브러시 업을 할 수 있음. 여전히 Claude가 터무니없는 기능을 만든다면 context7 MCP 서버를 설치해서 Claude에 context7 이용을 명확히 요구할 것 추천
이건 LLM 기술의 근본적 한계임. 확률적으로 “가장 그럴듯한” 토큰 시퀀스를 출력하지만, “그럴듯함”과 “정확함”이 일치하지 않으면 답이 없음. 각 LLM마다 이 “그럴듯함” 기준은 학습/파인튜닝마다 다름
기본적인 설정 이후, 이 툴이 잘 돌아가도록 하기 위해 어떤 추가적인 방법을 고민하는지 궁금함. 즉, 문맥/context와 코드베이스 구성에서 툴이 스스로 정확히 방향을 잡게 하는 실무적 방법들이 뭐가 있는지 노하우 공유 부탁함. 내 생각 정리는 이 글에 남겨둠. 더 좋은 방법론이 계속 나올 거라고 생각함
Claude Code로는 여러 알파(Alpha)를 얻고 있지만, 팀 전체로 확장하는 게 고민임. 팀원들이나 내가 관리하는 사람들이 효과적으로 Claude Code를 활용할 수 있게 실무 팁이나 베스트 프랙티스 공유하는 방법이 있을지 궁금함
Hacker News 의견
사람들이 Claude Code에 대한 극찬을 하는 걸 볼 때마다, 마치 다 인플루언서들이거나 터미널과 Emacs, Vim 같은 전통적인 툴에 열광하는 팬들뿐이라는 느낌을 지울 수 없음. 나는 항상 Claude Code가 Cursor보다 훨씬 낫다는 댓글을 볼 때마다 실제로 구독해 대규모 TypeScript 코드베이스에 적용해 보는데, 과정은 오래 걸리고 학습 곡선도 높음. 결과는 결국 Cursor 내장 Claude와 똑같으면서 더 느리고 불명확해서 코드 리뷰도 어려움. 지금은 그냥, 댓글의 열성팬들은 모두 후원받고 있거나 이미 200달러를 냈으니 자기 선택을 정당화하는 느낌이 듦. 솔직히 Cursor가 훨씬 생산성 높았음. 18년차 프로그래머로 매일 코드 많이 쓰지만 Gemini 2.5 Pro와 Claude 4.0을 번갈아 활용하며, 외려 Cursor로 더 많은 걸 얻고 있음. 아직 단 한 명도 날 설득한 적이 없음. 실질적 이점이 안 보임. 이후엔 생각이 달라질 수도 있겠지만, 지금은 전혀 못 느끼겠음
대부분의 사람들이 소프트웨어 개발에서 진짜 어려운 부분이 뭔지 깊이 오해하고 있다고 생각함. 실제 업무의 대부분은 복잡한 알고리즘 개발이 아니라 기존 아이디어를 잘 엮어서 맞춰 붙이는 일임. 하지만 그 모든 건 사전 명세·설계·아키텍처 등 선행 작업 뒤에 오는 일임. AI로 이런 프로그램을 뚝딱 만들어내는 게 멋져 보이고 데모에서는 빠르게 “끝낸” 것처럼 느껴지지만, 진짜 문제는 30년 간 써야 하는 시스템을 품질 기준 맞춰 제대로 만드는 것임. 프로토타입이나 일회성 목적에는 최고지만 장기적인 내구성엔 한계가 큼
이런 툴로 생산성을 극대화하려면 아주 짧고 빠른 피드백 루프가 핵심임. Cursor의 탭 자동완성 모델은 편집자가 뭔가를 하려는 걸 직감적으로 파악해서, 마치 미친 듯이 영리하게 감속기를 밟는 느낌임. 내가 머리 싸매고 매크로 프로그래밍할 필요 없이, 그냥 필요 없으면 Esc로 취소하면 되고 아니면 점진적으로 agentic 모드로 옮기면 됨. 완전한 에이전트 기반 에디터들은 15~30분씩 걸리고, 워크플로가 완전히 끊기는 문제도 있음. 결과물을 리뷰하는 게 일이고, 짧은 수용/거절 루프와는 비교도 안 되게 신경을 많이 씀. 네트워크 권한 줄지 오프라인으로 띄울지 고민도 커서, 유지보수/보안/신뢰성이 중요하지 않은 코드를 빨리 막 만들어야 할 때만 써볼 만함. 그 외엔 오히려 생산성이 떨어짐. 앞으로 나아지겠지만 현재는 확실히 Cursor에서 더 좋은 결과를 낼 수 있음
나도 예전엔 그렇게 느꼈지만 최근 Claude Code를 실제로 써보니 Cursor보다 훨씬 낫다고 느낌. 왜 그런지는 잘 모르겠으나 Claude가 전체 구조를 더 잘 파악하고 불필요한 수정을 잘 피하는 듯함. 물론 직접 방향을 잡아줘야 할 때도 있지만 효율성이 훨씬 더 높음. 특징 중 하나는 보통 한 번에 하나의 파일만 딱 보여주니까 리뷰하기 훨씬 쉬움. Cursor는 여러 파일을 한꺼번에 열고, 변화량이 많아서 빠르게 파악하기 힘듦. 참고로 난 VSCode 터미널 창에서 Claude Code 확장 프로그램을 이용함. Claude가 바꿔줄 파일 탭을 열어 변경안을 제안함
아직 사람들이 모르는 건 Cursor는 하나의 완성된 제품이 아니라, 모든 툴들이 빨리 따라잡으려고 추가하는 기능 묶음이라는 점임. 진짜 교훈은, 딥 인터페이스 말고도 각자 원하는 편집기로 베스트 인 클래스 에이전트 솔루션을 결합하려는 전략이 있음. 이런 경험들이 결국 “베스트 프랙티스”로 응집돼서, 사람들이 자기 편집기나 IDE에서 자연스럽게 적용하고, 이런 vscode 포크들은 다 사라질 것임
한 달도 안 되는 기간 17달러 요금제로 썼는데, 신기함과 답답함이 반반임. 러스트로 8천 줄, 마크다운으로 1만 2천 줄을 썼고, 작업명세와 구체적 태스크를 마치 테스트하네스와 같은 방식으로 분리해서 인공지능과 상호작용함. 마법이 VC 보조금 때문인지 뭔지 모르겠지만, 러스트가 마치 스크립트 언어처럼 느껴질 정도였음. (참고: GitHub 저장소는 ‘knowseams’임)
내가 AI에서 제일 좋은 점은, 귀찮을 때 “이거해줘” 하면 된다는 점임. 결과물이 좋든 별로든 상관없음. 일단 시작점 만들어줌
LLM 덕분에 백지 공포가 없어짐. 복잡한 맥락을 다시 머릿속에서 되살릴 필요 없이 “우리 뭘 하고 있었지?”, “이 코드는 뭐였지?”라고 물어보면 AI가 금방 설명해주고, 곧바로 다시 몰입할 수 있음. 루버덕 디버깅이나 반복적 사소한 작업(yak shaving)까지 엄청 빠르게 처리해줘서 진짜 유용함. Slack, Notion, Linear 등과도 연동해 써서 내겐 태스크/프로젝트 관리 툴임
스스로 직접 하고 싶을 때도, AI에게 계획을 짜달라고 해서 마크다운에 남겨둠. 오늘도 refactor 계획을 부탁했는데, 40개 파일로 된 프로토타입 코드 블록을 아래에서부터 구조변경하는 식으로 잘못 접근함. 만약 그 방향대로 실수했다면 디버깅에 엄청난 시간이 걸렸을 듯. 그래도 공격 포인트를 제공해주고, 계획도 한 시간만에 고쳐서 적용함. 내가 혼자 했다면 복잡함에 질려 시작도 못했거나, 문서화 반복하다 포기했을 것 같음
하루 끝엔 더 이상 집중이 안 돼서 쓰거나 되돌리는 양이 비슷해질 때 AI에게 핸들을 맡겨 한숨 돌릴 수 있음. 작은 이슈는 diff만 슬쩍 보면 되고, 어려운 이슈도 구체적으로 뭐가 문제인지 알면 AI를 방향 잡아주며 설득하면 됨. 작업의 40~60% 정도 완성되면 직접 이어받아 finish하는 편임. 평소에는 내가 날카로운 시간대에 집중해서 직접 사고하며 개발하고, 남는 야근이나 반복잡무는 AI에게 맡겨 익일 준비나 좀 더 고차원 글쓰기·설계를 주로 함
난 그냥 산책하고 커피를 마심. 인간문제는 인간적인 방식으로 해결하는 게 좀 더 자연스러운 느낌임
Claude Code는 뭐라고 설명하기 힘들 정도임. 사용한 뒤로는 아예 직업을 바꾼 것 같은 기분까지 들었음. 기존에도 Claude를 전면 워크플로우에 도입했지만, Claude Code는 그야말로 “스테로이드” 급임. 아직 안 써봤으면 무조건 추천임. 진짜로 주니어 엔지니어와 함께 일하는 느낌을 처음 받았음
내 경험은 정반대임. 무언가 지시하면 몇 분 걸려 뭔가 결과를 주는데, 실제로는 앱이 망가져 디버깅하다 보면 완전히 엉뚱하게 작업해서 결국 다 버림. 그럼에도 Claude를 계속 잡는 건 다른 사람들처럼 잘만 굴러가면 너무 좋기 때문임. 현실은 부일러플레이트만 뽑고, 직접 디버깅을 꽤 해야 하며, 최악이면 한 시간과 토큰만 날림
오늘 처음 회사에서 써봤는데 Cursor보다 압도적으로 혁신적인 변화임. 같은 파운데이션 모델을 씀에도 완전히 다른 경험임. 한 달 전에는 AI 때문에 일이 더 느렸는데, 오늘 Claude Code로 20분 만에 처리가 끝났고, API 사용료도 10달러가 채 안 듦. 문맥 관리에 신경 쓸 일이 매우 적었고, Claude Code는 스스로 필요한 맥락을 찾아넣어 훨씬 오랜 시간 동안 생산적으로 작업함. Cursor의 agent 모드는 3~5분짜리 작업까지만 쓸만하지만 Claude Code는 10분 넘는 작업에서도 자기 길을 잃지 않고 꾸준히 진전시킴. 도구 사용도 탁월하고, 루프에 잘 갇히지 않는 점이 놀라움
“주니어 엔지니어와 일하는 듯하다”고 했는데, 내가 느낀 건 오히려 내가 부하직원이고 Claude가 상사 같음. “내가 이런 멋진 거 해냈어요!”라고 자랑하면 “근데 그건 내가 시킨 게 아니야…” 라고 반응하는 느낌임
어떤 작업, 언어, 도메인에서 활용했는지 더 구체적으로 설명해줄 수 있음? 모두 케이스가 너무 달라서 궁금함
나도 같은 경험임. Claude는 단순 주니어 그 이상임. 옵션 제안이나, 결정을 위한 추천, 그리고 트레이드오프 시각화를 너무 잘해줌
실제로 Claude Code로 앱이나 라이브러리를 만드는 워크스루 사례가 많지 않음? 나는 단순 “신기함”을 말하는 글보다 진짜 해당 툴로 실전 개발하는 모습을 보고 싶음. 그런 사례 모음이 있음 정말 좋겠음
뭔가 전체적으로 이 상황이 조금 이상하게 느껴짐. Claude Code 자체는 분명 좋고, 훨씬 빠르게 문서나 스택오버플로를 찾는 데 쓸 수 있음. 하지만 만약 과장된 소문이 사실이라면, 이런 툴로 엄청난 속도로 소프트웨어 혁신이 일어나야 하지 않냐는 의문이 듦. Stripe CEO는 AI 툴이 생산성 100배 증가라 했는데, 3~4개월 지났으면 지금쯤 Stripe는 로켓 발사해야 하지 않음? Microsoft도 AI코딩 올인하였다는데 Teams는 왜 여전히 별로 같지? 1년 넘게 이 툴이 혁신이라는데, 실제 현실은 3~4년 전과 큰 차이가 없는 듯함
최근 눈에 띄는 두 가지 트렌드는 (1) 비숙련자가 사소한 프로젝트에 AI를 쓰는 것, (2) 개발자가 전체 앱 구조와 파일, 인터페이스, 테크 스택, 테스트 프레임워크까지 빽빽하게 미리 명세해두고 LLM에 세밀하게 핸들링을 시켜 괜찮은 결과를 겨우 끌어내는 것임 YouTube 예시. PR/유튜브 등에서 들려오는 80~99%의 얘기는 사실상 첫 번째 그룹에서 나옴. 생산성 상승을 느끼는 건, LLM과 대화·문서화·유도·수정하는 일이 직접 개발하는 것보다 덜 피곤하게 느껴져서임. 시간이나 총노력은 똑같아도 기대치를 덜기 때문임
유튜브에서 진짜 생산성 부스트를 내는 현장 스트림/사례를 찾고 있는데, “와 진짜 빠르다!”고 느낀 케이스는 못 봄
찬반 양극단 의견이 많지만 정작 대다수는 조용히 각자 커밋하고 있음(이 말 자체가 아이러니). 내 경우, 작업에 따라 1.5~10배까지 빨라짐을 реально 체감함. 가장 큰 이점은 순수 창조적·일회성·보일러플레이트·리팩토링류 작업에서 인지적 부하가 크게 줄어서, 일관된 성과를 유지한다는 점임. 여전히 “손코딩”도 많이 하고, 거의 모든 라인을 끝까지 리뷰함. 몇 시간째 혼자 돌려놓는 일은 Nightmare임. 실제로 10년 넘게 유지 중인 프로덕션 앱에서도 어딘가 블로그에 홍보할 시간도 없음. 반면 아주 슬림한 조직이라 전체 시스템 문맥도 내 손에 쥐어져 있어 문제를 더 빠르게 파악할 수 있는 면도 큼. 자기 효율성 확보가 중요한 환경에선 확실히 근본을 키움. 대규모 조직에선 이런 경험 얻기 힘듦
내 경험상 Claude.md라는 마크다운 파일을 각 코드폴더 루트에 둬서, 파이프라인처럼 미니멀한 룰셋을 추가함. 테스트 생성과 배치는 지정된 폴더 및 방식에 꼭 맞게 하고, 디버그 파일 생성을 막음. 새로운 클래스나 구조의 난립을 막고, 꼭 필요한 경우 외엔 재사용하도록 룰을 걸어둠. 프롬프트도 길게 적지 않고, 대개 불확실한 부분만 계획서를 작성함. LLM의 지식범위를 벗어난 신상 이슈에도 큰 입력은 최소한으로만 전달함. 이런 방식으로 1 input–1 output(뎁스까지 다 적용) 결과를 일관성 있게 얻음. 최근엔 Claude Code 대신 CLI 모드로 Opus 등 다른 대형 모델을 더 저렴하게 써서 옮겨갔음. CLI가 진짜 파워임. 60~70개의 에이전트 스트림을 동시에 돌리고 있고, 2억 토큰 규모(react/typescript/golang) 코드베이스도 무리 없이 관리. 단 한두 번 정도만 추가 지시한 경험
에이전트 스트림으로 어떤 걸 운영하는지 리스트 가능함? 매우 궁금함
Anthropic 외에 어떤 모델을 쓰는지 알고 싶음. Kimi K2는 써봤는데, 내 사용에 별로임
"에이전트 스트림"이란 게 무엇을 의미하는지 궁금함. 60~70개를 어떻게 관리하는지, 인지적 부담이 상상도 안 됨
가끔 Claude Code로 특정 작업을 할 때 생산성이 극적으로 오름. Slash command를 활용해서 이전 대화를 slash command로 만드는 방식을 추천함. 이렇게 하면 점점 더 활용 가능한 프리미티브 명령어 세트를 쌓아갈 수 있음. 내 사례는 GitHub에 올려둠 make-command.md, improve-command.md
PSA(공익 정보): 이 저장소로 어떤 모델과도 Claude Code를 연동할 수 있음. 최신 Kimi-K2가 꽤 잘 동작한다고 알려짐
나도 Kimi-K2 써봤는데, Sonnet/Opus 4.0보다는 성능이 떨어지고, tool calling은 Gemini 2.5 Pro보다는 나은 편임. Claude Max(월 100~200달러)가 부담스러우면 강추함. 모델 자체가 군더더기 없이 매우 간단해서 좋음. Anthropic도 차라리 Claude Code 오픈소스화하면 cli coding agent계의 VSCode가 될 수 있을 듯. 그리고 opencode도 추천함. 모든 모델 네이티브 지원 및 Claude Code 유사 기능 제공
여러 모델로 쓸 거라면 sst/opencode를 그냥 추천함(나도 Claude Pro로 씀)
참고로 CC를 아직 못 써본 사람들은 – CC 클라이언트를 npm으로 받아 무료로 쓸 수 있음
Claude Code, local LLM, Continue, VSCode로 간단한 파이썬 앱을 “vibe coding” 하며 놀다가, Claude 무료티어를 알게 되어 진행중이던 코드와 LLM 결과물을 넣어봤음. 오류와 업데이트를 한 번에 정확히 정리·수정해줘서 신남! 그래서 다음 단계로 pygame 기반 2d 게임(마닉 마이너 스타일) 프로젝트의 스펙과 프롬프트를 ChatGPT로 짜고 Claude에 넣어보니, Claude가 계속 없는 메서드를 참조하거나 코드베이스 버전 차이 운운하며 헛소리를 함. 라인 넘버와 주변 코드로 콕 찝어줘도 여전히 gaslighting 중. 어떻게 해결하면 좋을지, 완벽은 바라지 않지만 local LLM 때랑 비슷한 한계에 막힌 느낌임. 건강이 안 좋아 간헐적으로 하는 거라 조언 부탁함
“모호한 인터페이스와 숨어있는 전제들이 가득한 코드 지옥”에 빠졌을 확률이 큼. 이럴 땐 차라리 기존 ChatGPT 결과물 모두를 요약해, 현재 게임이 무엇을 하는지/모든 기능을 깊게 리스트업한 다음, 그 문서를 Claude에 넣고 요구사항을 처음부터 다시 break down하면 훨씬 깔끔한 결과를 얻을 수 있음. Claude는 zero-shot으로도 훌륭한 샘플을 낼 수 있고, 최악이어도 반복적으로 자체 브러시 업을 할 수 있음. 여전히 Claude가 터무니없는 기능을 만든다면 context7 MCP 서버를 설치해서 Claude에 context7 이용을 명확히 요구할 것 추천
이건 LLM 기술의 근본적 한계임. 확률적으로 “가장 그럴듯한” 토큰 시퀀스를 출력하지만, “그럴듯함”과 “정확함”이 일치하지 않으면 답이 없음. 각 LLM마다 이 “그럴듯함” 기준은 학습/파인튜닝마다 다름
기본적인 설정 이후, 이 툴이 잘 돌아가도록 하기 위해 어떤 추가적인 방법을 고민하는지 궁금함. 즉, 문맥/context와 코드베이스 구성에서 툴이 스스로 정확히 방향을 잡게 하는 실무적 방법들이 뭐가 있는지 노하우 공유 부탁함. 내 생각 정리는 이 글에 남겨둠. 더 좋은 방법론이 계속 나올 거라고 생각함
Claude Code로는 여러 알파(Alpha)를 얻고 있지만, 팀 전체로 확장하는 게 고민임. 팀원들이나 내가 관리하는 사람들이 효과적으로 Claude Code를 활용할 수 있게 실무 팁이나 베스트 프랙티스 공유하는 방법이 있을지 궁금함