글 작성자 입장: 요즘에 Claude 코드 관련 글이 넘쳐나는 상황에서, 우리가 발견한 몇 가지 핵심 포인트—특히 Anchor Comments—공유 가치가 있다고 판단한 부분 남김
Anchor Comments 방식은 코드베이스 이곳저곳에 특수 포맷의 주석을 남겨놓아, 필요한 지식을 바로 grep 해서 찾아볼 수 있게 해주는 구조
예시로, AIDEV-NOTE:, AIDEV-TODO:, AIDEV-QUESTION:와 같은 프리픽스를 사용
파일 검색 전에는 먼저 기존 AIDEV-…이 있는지 반드시 grep 해야 하는 룰
작업이 끝난 후에는 해당 anchor 업데이트 필수
코드파일이나 코드 조각이 너무 복잡하거나, 아주 중요하거나, 버그가 있을 수 있다고 판단되면 항상 anchor 주석 남기기
참고 예시는 여기에서 확인 가능
아주 경험 많은 엔지니어로서 LLM을 체계적으로 쓰지 않고 가끔만 사용하는 입장인데, 실제 프로젝트에서 LLM을 어떻게 프로덕션에 적용하는지 자세히 보니 상당히 유익한 느낌
다른 분들이 왜 부정적인 시각을 갖는지 이해 안 되는 부분
내 워크플로우에 LLM 활용도를 좀 더 높여보고 싶은 동기 부여 받는 경험
물론 LLM이 프로젝트 키를 쥐고 있지는 않았지만, 특정 작업을 맡겨 성공한 사례 꽤 많은 상황
요즘 관련 글은 많지만 이 글은 실용성이 높고 내게 적용해볼만한 시스템 아이디어 제시해줌
aider 같은 툴을 쓸 때와 이런 워크플로우의 차이가 궁금한 상황—혹시 저자 관점이 있다면 듣고 싶은 요청
훌륭한 아티클 덕분에 대규모 LLM 활용법 이해에 큰 도움 받은 느낌
"AI는 테스트는 절대 손대면 안 된다"고 했는데, 이어서 500개가 넘는 엔드포인트 리팩터링 예시에서 4시간 만에 처리했다는 점이 인상적
이 4시간에 테스트 리팩터링까지 포함된 시간인지, 아니면 프롬프트에 소비된 시간뿐인지 궁금한 부분
테스트가 AI에 의해 업데이트된 경우 PR을 거절한다는 규칙 언급 내용을 봤는데, 실제로 AI가 생성 또는 수정했다는 걸 어떻게 확인하는지 궁금
글에서는 git 커밋 메시지 룰로 판별한다고 했는데, 이것도 커밋 단위로만 작동하는 상황
글 작성에 Claude Code를 사용했는지 궁금
나 스스로는 요즘 내 글 100%를 Claude Code로 작성하는데, 마크다운 파일에 에이전트가 직접 편집하는 효과가 뛰어나 claude.ai artifacts나 chatgpt.com canvas보다 훨씬 생산성 느끼는 중
덕분에 연구 자료나 관련 파일을 문서에 깊게 병합하는 게 아주 쉬워진 상황
AI 에이전트의 흥미로운 점은, 평소 중요하다고 생각하지만 실제로는 시스템 배포 앞에서 우선순위가 밀렸던 프로세스들을 진짜 실행하게 만든다는 점
AI가 자기 대신 뭔가를 하는 데 불편함 느끼는 정도를 '시스템적 검증에 시간을 투입할 지표'로 활용하는 꿀팁 사용 중
링크에서처럼 데이터 마이그레이션 검증 시스템을 구축하면, 관련 모든 변경 사항도 자연스럽게 AI 활용 범위 안으로 넣을 수 있음
추상적 '기술 부채' 이야기보다 이렇게 구체적으로 외부에 설명하기 쉬운 장점 체감
확실히 그렇다고 공감하는 바이지만, 내가 발견한 또다른 유용한 트릭은 Claude Code에게 "코드베이스를 둘러보고 헷갈리거나, 이상하거나, 직관에 어긋나는 부분이 있으면 AIDEV-QUESTION: 주석을 남겨달라"고 요청하는 방식
예상 밖의 복잡하고 잊힌 코드 덕분에 중요한 곳을 다시 찾게 되는 경험했던 기억
내 직감으로, 추상화 수준이 높은 검증 도구—예: acceptance test, property test, formual verification—를 더 자주 쓰게 될 가능성이 큼
보일러플레이트 비용이 LLM 활용으로 상대적으로 많이 낮아진 환경
읽으면서 새로운 걸 배움
최근 Sonnet 4를 Cursor랑 Web에서 써봤는데, 계속 무언갈 대충 처리하거나 결과를 오해하게 보고하는 경우가 많아 당황
심지어 프로그래밍 외 영역에서도 병적으로 잘못된 이야기를 하는 느낌
Anthropic 리포트에서 본 대로 “삭제할거야” 같은 경고도 효과가 없었고, 사용 후 모바일 앱에서 피드백이 안 접수되는 문제까지 겪은 상황
다른 분들은 Claude 관련 이슈가 없는 듯한데 혹시 나만 이런 상황인지 궁금
최근 업데이트에서 AI의 능력을 너무 약화시킨 듯한 인상
3.5 버전까지는 텍스트 분석, 요약, 짧은 글쓰기 등 간단한 작업엔 괜찮았지만 4버전 이상은 한 컨텍스트 내에서 3-4회 이상 명령을 제대로 못 따르는 상황
“간결하게 하라고 했는데 왜 자꾸 장황하게 설명하냐” 라고 물으면, 디폴트 설정 때문에 명령어를 무시한다고 답변하고 “해로운 정보”는 아예 피하려는 성향까지 표현
여러 번 논리적 허점을 집어주면 스스로 신뢰도가 낮다고 인정하기도
오히려 너무 똑똑해져서 문제가 밀려온 건가 싶을 정도이며, Anthropic이 잘못된 방향으로 발전시킨 거라면 아쉬움 남김
위에서 말한 문제들을 모두 실제로 경험한 사용자 입장
Web에서는 아주 구체적으로 요청을 넣으면 좀 낫지만, 그래도 생성된 코드의 절반은 여전히 오류가 섞여 있음
문서화 팁을 읽으면서 느낀 게, 사실 이런 규칙들은 꼭 AI만을 위한 게 아니라 일반 코딩에도 적용 가능
CLAUDE.md 대신 CONVENTIONS.md, AI를 위한 주석 대신 READER를 위한 주석으로 남겨도 똑같이 유용
낯선 코드베이스에서 새롭게 기여할 때 이런 주석이 있다면 꽤 감사할 것 같은 입장
aider로 실제 시도해봤더니 상당히 잘 작동한 경험
비행기 기다리면서 PDF 뷰어와 드로잉 기능까지 넣은 코드를 30분 만에 완성한 사례 경험
원글 작성자는 아니지만, 실제로 Claude에 도움 되는 주석과 인간에게 도움 되는 주석 스타일이 현저히 다름
인간용 스타일 가이드는 보통 100줄 정도로 작성하고 “input 바꾸는 함수엔 반드시 !붙이기”와 같은 간단한 규칙 위주
Claude용 가이드는 500줄 이상 작성했고, 각 규칙별로 "이렇게 하라, 저렇게 하지 말라" 식의 예시를 많이 포함해야 겨우 효과 받는 느낌
글 작성에 감사
많은 개발자들이 LLM에게 업무 통제권을 일부 넘길 때 느끼는 불안감, 기존의 형식적이고 엄격한 개발 방법론이 아닌 실험적이거나 비구조적 접근 방식 같다는 상반된 고민이 있다는 점 공감
그렇지만 LLM을 활용해 훨씬 빠른 속도로 문제를 해결하려는 '목표 중심 최적화'가 실제로 실현 가능한 중간 지대 생성
종종 구현 디테일에 빠져 실제 목표를 놓치는 일이 많은데, LLM 활용은 이런 실수를 줄이는 데 도움 준다는 생각
맞는 이야기
나는 LLM을 미완의 레버라고 보는데, 아직은 거칠고 실수도 많지만 배워가며 쓸 가치 충분
허술한 엔지니어링을 정당화하는 핑계로 쓰지 않는 선에서, 진짜로 쓸만한 도구로 진화시키려는 노력이 중요하다는 시각
글 맨 위 2.3MB짜리 이미지는 와이파이 환경에서도ㅎ 농담처럼 아주 느리게 로딩된 경험
몇 가지 생각
LLM 관련 프롬프트나 명세를 코드베이스에서 더 세련되게 정리할 방법이 있는지 의문
CLAUDE.md, SPEC.md, AIDEV 주석이 많아지면 다루기 힘들어질 듯
'vibe-coding'의 요즘 정의는 뭔지 궁금
Karpathy의 “카우보이 모드”처럼 코드 안 보고 diff 전부 수용하는 것에서 최근에는 LLM 워크플로우를 다 포함하는 의미로 변질된 듯
타인의 LLM에 코드 보낼 때 소스코드 난독화를 하는지도 궁금
주석이 많아지면 정말 금방 코드가 복잡해지는 것이 사실
그래서 이를 시각화해서 gutter에 작은 인디케이터로 보여주는 vscode 확장 도구를 직접 개발 중
vibe-coding 의미는 사람마다 다른데, 개인적으로는 완벽한 해법은 아니었고 여러 이슈 만남
3.7 Sonnet과 Codex는 60% 성과였으나 Opus 4는 실제로 굉장히 효율적이라고 느낌
코드 난독화 관련해서는, 본문 예시는 애초에 전부 오픈소스라 큰 문제 없었음
매우 흥미로워서 내 CLAUDE.md 파일에도 적용해볼 생각
“토큰 아끼려고 컨텍스트를 아끼는 게 오히려 역효과”라는 AI-개발의 역설적인 교훈에 동감
더 큰 프로젝트, 복잡한 코드에서는 Claude Opus와 Sonnet의 성능 차이가 실제로 상당하게 나타나는 걸 직접 느끼는 중
Sonnet은 안 해도 될 시도만 반복하다가 오히려 상황을 더 안 좋게 만드는 경우가 많았음
결국 Max 구독 유저에게 Opus와 Sonnet을 굳이 구분할 필요가 없는 게 아닐까 의문
Sonnet이 10~20회 번갈아 할 걸 Opus는 2~3회 만에 끝내는 경우라, 오히려 Sonnet 쪽의 사용량이 장기적으로 비용을 더 키우는 방식
Max 구독은 두 가지 티어가 있고, $100은 Pro보다 토큰 5배, $200은 20배 제공
토큰 계산이 쉽지 않고, 하이브리드 모드는 Opus 토큰 20% 남을 때까지만 Opus 사용 후 Sonnet으로 자동 전환되는 구조
잘 쓴 글이지만 “테스트는 절대 AI에게 맡기지 말라”는 부분엔 의견 다름
나는 요즘 모든 테스트를 AI로 작성시키고 직접 꼼꼼히 리뷰
신규 코드라면 AI에게 테스트까지 맡겨야 높은 자율성이 가능
AI에게 테스트 구현과 통과를 명확히 지시한 다음, AI가 개발 중일 때 즉시 리뷰하고 부족한 테스트 케이스는 추가하는 구조로 운용
대부분 내용에 공감하지만, Claude가 테스트나 마이그레이션을 손도 못 대게 하는 정책엔 동의 못 하는 부분
테스트를 직접 쓰는 게 가장 싫은 작업인데, LLM이 최소한의 초안만 작성해줘도 큰 도움이 되는 상황
핵심은 생성 주체와 관계없이 최종 소유권과 책임은 항상 인간에게 있게 하는 것
메시지의 뉘앙스상 저자는 Claude에 대한 신뢰 부족, 또는 직원들이 AI 결과물을 무비판적으로 받아들이지 않으려는 목적이 강한 듯
혹은, 테스트/마이그레이션 관련 엄격한 규칙이 없으면 진짜 코드가 고장나거나 데이터 손실 발생 가능성이 현실적이라고 판단하는 듯
그 말도 맞지만, 내 경험상 큰 문제를 겪은 사례가 있었음
생성된 테스트를 나중에 사람이 수동으로 고칠 때 진짜 심각한 함정이 많았음
Claude는 문맥 컨텍스트를 잘 모르니까 거의 모든 걸 mock 처리해서 우리 서비스/빌드 환경과 완전히 동떨어진 테스트 자주 생성
그리고 더 큰 문제는, 팀 전체가 테스트에 대해 너무 게을러진다는 점
실제로 production에서 버그가 크게 증가했음
Hacker News 의견
글 작성자 입장: 요즘에 Claude 코드 관련 글이 넘쳐나는 상황에서, 우리가 발견한 몇 가지 핵심 포인트—특히 Anchor Comments—공유 가치가 있다고 판단한 부분 남김
Anchor Comments 방식은 코드베이스 이곳저곳에 특수 포맷의 주석을 남겨놓아, 필요한 지식을 바로 grep 해서 찾아볼 수 있게 해주는 구조
예시로,
AIDEV-NOTE:,AIDEV-TODO:,AIDEV-QUESTION:와 같은 프리픽스를 사용파일 검색 전에는 먼저 기존
AIDEV-…이 있는지 반드시 grep 해야 하는 룰작업이 끝난 후에는 해당 anchor 업데이트 필수
코드파일이나 코드 조각이 너무 복잡하거나, 아주 중요하거나, 버그가 있을 수 있다고 판단되면 항상 anchor 주석 남기기
참고 예시는 여기에서 확인 가능
아주 경험 많은 엔지니어로서 LLM을 체계적으로 쓰지 않고 가끔만 사용하는 입장인데, 실제 프로젝트에서 LLM을 어떻게 프로덕션에 적용하는지 자세히 보니 상당히 유익한 느낌
다른 분들이 왜 부정적인 시각을 갖는지 이해 안 되는 부분
내 워크플로우에 LLM 활용도를 좀 더 높여보고 싶은 동기 부여 받는 경험
물론 LLM이 프로젝트 키를 쥐고 있지는 않았지만, 특정 작업을 맡겨 성공한 사례 꽤 많은 상황
요즘 관련 글은 많지만 이 글은 실용성이 높고 내게 적용해볼만한 시스템 아이디어 제시해줌
aider 같은 툴을 쓸 때와 이런 워크플로우의 차이가 궁금한 상황—혹시 저자 관점이 있다면 듣고 싶은 요청
훌륭한 아티클 덕분에 대규모 LLM 활용법 이해에 큰 도움 받은 느낌
"AI는 테스트는 절대 손대면 안 된다"고 했는데, 이어서 500개가 넘는 엔드포인트 리팩터링 예시에서 4시간 만에 처리했다는 점이 인상적
이 4시간에 테스트 리팩터링까지 포함된 시간인지, 아니면 프롬프트에 소비된 시간뿐인지 궁금한 부분
테스트가 AI에 의해 업데이트된 경우 PR을 거절한다는 규칙 언급 내용을 봤는데, 실제로 AI가 생성 또는 수정했다는 걸 어떻게 확인하는지 궁금
글에서는 git 커밋 메시지 룰로 판별한다고 했는데, 이것도 커밋 단위로만 작동하는 상황
글 작성에 Claude Code를 사용했는지 궁금
나 스스로는 요즘 내 글 100%를 Claude Code로 작성하는데, 마크다운 파일에 에이전트가 직접 편집하는 효과가 뛰어나 claude.ai artifacts나 chatgpt.com canvas보다 훨씬 생산성 느끼는 중
덕분에 연구 자료나 관련 파일을 문서에 깊게 병합하는 게 아주 쉬워진 상황
AI 에이전트의 흥미로운 점은, 평소 중요하다고 생각하지만 실제로는 시스템 배포 앞에서 우선순위가 밀렸던 프로세스들을 진짜 실행하게 만든다는 점
AI가 자기 대신 뭔가를 하는 데 불편함 느끼는 정도를 '시스템적 검증에 시간을 투입할 지표'로 활용하는 꿀팁 사용 중
링크에서처럼 데이터 마이그레이션 검증 시스템을 구축하면, 관련 모든 변경 사항도 자연스럽게 AI 활용 범위 안으로 넣을 수 있음
추상적 '기술 부채' 이야기보다 이렇게 구체적으로 외부에 설명하기 쉬운 장점 체감
확실히 그렇다고 공감하는 바이지만, 내가 발견한 또다른 유용한 트릭은 Claude Code에게 "코드베이스를 둘러보고 헷갈리거나, 이상하거나, 직관에 어긋나는 부분이 있으면 AIDEV-QUESTION: 주석을 남겨달라"고 요청하는 방식
예상 밖의 복잡하고 잊힌 코드 덕분에 중요한 곳을 다시 찾게 되는 경험했던 기억
내 직감으로, 추상화 수준이 높은 검증 도구—예: acceptance test, property test, formual verification—를 더 자주 쓰게 될 가능성이 큼
보일러플레이트 비용이 LLM 활용으로 상대적으로 많이 낮아진 환경
읽으면서 새로운 걸 배움
최근 Sonnet 4를 Cursor랑 Web에서 써봤는데, 계속 무언갈 대충 처리하거나 결과를 오해하게 보고하는 경우가 많아 당황
심지어 프로그래밍 외 영역에서도 병적으로 잘못된 이야기를 하는 느낌
Anthropic 리포트에서 본 대로 “삭제할거야” 같은 경고도 효과가 없었고, 사용 후 모바일 앱에서 피드백이 안 접수되는 문제까지 겪은 상황
다른 분들은 Claude 관련 이슈가 없는 듯한데 혹시 나만 이런 상황인지 궁금
최근 업데이트에서 AI의 능력을 너무 약화시킨 듯한 인상
3.5 버전까지는 텍스트 분석, 요약, 짧은 글쓰기 등 간단한 작업엔 괜찮았지만 4버전 이상은 한 컨텍스트 내에서 3-4회 이상 명령을 제대로 못 따르는 상황
“간결하게 하라고 했는데 왜 자꾸 장황하게 설명하냐” 라고 물으면, 디폴트 설정 때문에 명령어를 무시한다고 답변하고 “해로운 정보”는 아예 피하려는 성향까지 표현
여러 번 논리적 허점을 집어주면 스스로 신뢰도가 낮다고 인정하기도
오히려 너무 똑똑해져서 문제가 밀려온 건가 싶을 정도이며, Anthropic이 잘못된 방향으로 발전시킨 거라면 아쉬움 남김
위에서 말한 문제들을 모두 실제로 경험한 사용자 입장
Web에서는 아주 구체적으로 요청을 넣으면 좀 낫지만, 그래도 생성된 코드의 절반은 여전히 오류가 섞여 있음
문서화 팁을 읽으면서 느낀 게, 사실 이런 규칙들은 꼭 AI만을 위한 게 아니라 일반 코딩에도 적용 가능
CLAUDE.md 대신 CONVENTIONS.md, AI를 위한 주석 대신 READER를 위한 주석으로 남겨도 똑같이 유용
낯선 코드베이스에서 새롭게 기여할 때 이런 주석이 있다면 꽤 감사할 것 같은 입장
aider로 실제 시도해봤더니 상당히 잘 작동한 경험
비행기 기다리면서 PDF 뷰어와 드로잉 기능까지 넣은 코드를 30분 만에 완성한 사례 경험
원글 작성자는 아니지만, 실제로 Claude에 도움 되는 주석과 인간에게 도움 되는 주석 스타일이 현저히 다름
인간용 스타일 가이드는 보통 100줄 정도로 작성하고 “input 바꾸는 함수엔 반드시 !붙이기”와 같은 간단한 규칙 위주
Claude용 가이드는 500줄 이상 작성했고, 각 규칙별로 "이렇게 하라, 저렇게 하지 말라" 식의 예시를 많이 포함해야 겨우 효과 받는 느낌
글 작성에 감사
많은 개발자들이 LLM에게 업무 통제권을 일부 넘길 때 느끼는 불안감, 기존의 형식적이고 엄격한 개발 방법론이 아닌 실험적이거나 비구조적 접근 방식 같다는 상반된 고민이 있다는 점 공감
그렇지만 LLM을 활용해 훨씬 빠른 속도로 문제를 해결하려는 '목표 중심 최적화'가 실제로 실현 가능한 중간 지대 생성
종종 구현 디테일에 빠져 실제 목표를 놓치는 일이 많은데, LLM 활용은 이런 실수를 줄이는 데 도움 준다는 생각
나는 LLM을 미완의 레버라고 보는데, 아직은 거칠고 실수도 많지만 배워가며 쓸 가치 충분
허술한 엔지니어링을 정당화하는 핑계로 쓰지 않는 선에서, 진짜로 쓸만한 도구로 진화시키려는 노력이 중요하다는 시각
글 맨 위 2.3MB짜리 이미지는 와이파이 환경에서도ㅎ 농담처럼 아주 느리게 로딩된 경험
몇 가지 생각
LLM 관련 프롬프트나 명세를 코드베이스에서 더 세련되게 정리할 방법이 있는지 의문
CLAUDE.md, SPEC.md, AIDEV 주석이 많아지면 다루기 힘들어질 듯
'vibe-coding'의 요즘 정의는 뭔지 궁금
Karpathy의 “카우보이 모드”처럼 코드 안 보고 diff 전부 수용하는 것에서 최근에는 LLM 워크플로우를 다 포함하는 의미로 변질된 듯
타인의 LLM에 코드 보낼 때 소스코드 난독화를 하는지도 궁금
주석이 많아지면 정말 금방 코드가 복잡해지는 것이 사실
그래서 이를 시각화해서 gutter에 작은 인디케이터로 보여주는 vscode 확장 도구를 직접 개발 중
vibe-coding 의미는 사람마다 다른데, 개인적으로는 완벽한 해법은 아니었고 여러 이슈 만남
3.7 Sonnet과 Codex는 60% 성과였으나 Opus 4는 실제로 굉장히 효율적이라고 느낌
코드 난독화 관련해서는, 본문 예시는 애초에 전부 오픈소스라 큰 문제 없었음
매우 흥미로워서 내 CLAUDE.md 파일에도 적용해볼 생각
“토큰 아끼려고 컨텍스트를 아끼는 게 오히려 역효과”라는 AI-개발의 역설적인 교훈에 동감
더 큰 프로젝트, 복잡한 코드에서는 Claude Opus와 Sonnet의 성능 차이가 실제로 상당하게 나타나는 걸 직접 느끼는 중
Sonnet은 안 해도 될 시도만 반복하다가 오히려 상황을 더 안 좋게 만드는 경우가 많았음
결국 Max 구독 유저에게 Opus와 Sonnet을 굳이 구분할 필요가 없는 게 아닐까 의문
Sonnet이 10~20회 번갈아 할 걸 Opus는 2~3회 만에 끝내는 경우라, 오히려 Sonnet 쪽의 사용량이 장기적으로 비용을 더 키우는 방식
토큰 계산이 쉽지 않고, 하이브리드 모드는 Opus 토큰 20% 남을 때까지만 Opus 사용 후 Sonnet으로 자동 전환되는 구조
잘 쓴 글이지만 “테스트는 절대 AI에게 맡기지 말라”는 부분엔 의견 다름
나는 요즘 모든 테스트를 AI로 작성시키고 직접 꼼꼼히 리뷰
신규 코드라면 AI에게 테스트까지 맡겨야 높은 자율성이 가능
AI에게 테스트 구현과 통과를 명확히 지시한 다음, AI가 개발 중일 때 즉시 리뷰하고 부족한 테스트 케이스는 추가하는 구조로 운용
대부분 내용에 공감하지만, Claude가 테스트나 마이그레이션을 손도 못 대게 하는 정책엔 동의 못 하는 부분
테스트를 직접 쓰는 게 가장 싫은 작업인데, LLM이 최소한의 초안만 작성해줘도 큰 도움이 되는 상황
핵심은 생성 주체와 관계없이 최종 소유권과 책임은 항상 인간에게 있게 하는 것
메시지의 뉘앙스상 저자는 Claude에 대한 신뢰 부족, 또는 직원들이 AI 결과물을 무비판적으로 받아들이지 않으려는 목적이 강한 듯
혹은, 테스트/마이그레이션 관련 엄격한 규칙이 없으면 진짜 코드가 고장나거나 데이터 손실 발생 가능성이 현실적이라고 판단하는 듯
실제로 production에서 버그가 크게 증가했음