Hacker News 의견들

• Claude Code 팀의 Boris임. 몇 가지 팁을 공유함

  1. Claude가 자주 틀리거나 이해하지 못하는 부분은 CLAUDE.md에 적어두면 좋음. Claude는 이 파일을 자동으로 읽음
  2. Plan 모드(Shift+Tab 두 번) 를 적극 활용해 계획을 먼저 세운 뒤 실행시키면 어려운 작업에서 2~3배 더 나은 결과를 얻을 수 있음
  3. 작업 검증 방법을 제공하면 좋음. 예를 들어 Svelte에서는 Puppeteer MCP 서버를 써서 브라우저에서 결과를 확인하게 할 수 있음
  4. 모델은 Opus 4.5를 추천함. Sonnet 4.5보다 확실히 한 단계 업그레이드된 느낌임
     도움이 되길 바람
  • 나도 Plan 모드 덕분에 큰 생산성 향상을 경험했음. 하지만 최근 버전에서 Plan 모드가 세션 첫 계획만 계속 참조하는 버그가 생겨서 워크플로우가 망가졌음. 내가 비정상적으로 쓰는 건지 궁금함
  • 작업 중 Claude를 교정한 뒤에는 self-reflection 프롬프트를 실행하면 좋음. 이 과정이 수동으로 정리한 내용들을 CLAUDE.md로 자동 반영해줌
  • 위 조언들에 공감함. 특히 (3)번의 피드백 루프가 핵심임. 모델이 직접 수정하고 결과를 확인할 수 있게 해야 함. 로그 파일을 남기게 하거나, pseudocode 계획을 세우게 하면 복잡한 문제도 빠르게 해결됨
  • Opus 4.5는 진짜 게임 체인저임. 오래된 React 프로젝트를 리팩터링할 때 큰 도움이 되었음. 프롬프트를 정밀하게 작성하고 CLAUDE.md를 잘 세팅하면 효과가 큼
  • CLAUDE.md가 4~5번 정도까지만 잘 작동하고 이후엔 지시를 잊어버림. 예를 들어 이름을 “Mr. bcherny”로 부르라고 해도 금방 잊음
  • Google Jules와 비교했을 때 Claude Code가 훨씬 전문 개발자처럼 느껴졌음. 다만 Claude Code Web에는 프로젝트 기능이 없어 .clinerules 파일을 쓰라는 답변을 받았는데, CLAUDE.md와의 차이를 알고 싶음
  • CLAUDE.md에서 유용한 기능 하나는 @import임. 파일 이름 앞에 @를 붙이면 강제로 컨텍스트에 포함시킬 수 있음. 다만 너무 많이 쓰면 비효율적임

• 음성 입력을 활용하면 모델이 의도를 더 정확히 이해함. 500단어 정도의 프롬프트를 말로 전달함. 타이핑보다 말할 때 생각이 더 자연스럽게 이어짐.
  “계획을 세우고 질문이 있으면 물어봐”라고 하면 Claude가 실제로 질문을 해옴. 이전 코드 스타일을 모방하도록 지시하는 것도 효과적임

  • 나도 음성으로 laboratory.love를 거의 전부 만들었음. 단축키로 “코드 작성 전 문제와 요구사항을 분석하고 모호한 점을 물어봐”라는 문장을 자주 씀
  • 말이 빠르다고 해서 생각 없이 말하는 건 아님. 오히려 생각을 덜 하고 말하는 게 문제일 수 있음
  • 누군가 듣고 있을 때 AI에게 말하는 건 좀 어색하지만, 긴 문장은 나도 음성으로 입력함
  • 어떤 음성 인식 서비스를 쓰는지 궁금함

• 프롬프트에 루프 조건(loop condition) 을 포함해야 함. 예: “yarn test가 통과할 때까지 반복”.
  LLM은 결국 도구를 반복 실행하는 에이전트이므로 그렇게 다뤄야 함
  참고: Prompting the Agent Loop

• 내가 만든 nori-profiles 설정을 추천함.
  4개월간 실험한 결과 Claude Code의 성능이 눈에 띄게 향상됨.
  관련 글: Averaging 10 PRs a Day with Claude

  • Claude Code의 skills와 비교하면 어떤 차이가 있는지 궁금함

• 회사에서 Golang 대규모 코드베이스를 다룸. Cursor, Claude Code, Gemini CLI 등 여러 툴을 써봤지만 대부분 코드량에 압도됨.
  그러나 aider는 훨씬 제어가 쉬웠고 정확도가 높았음. 파일 추가는 수동이지만 거의 100% 정확함.
  최신 Claude Sonnet이나 Gemini 2.5 Pro와 함께 쓰면 가장 정확함

  • aider는 완전한 에이전트형이 아니라는 점이 장점임. 수동으로 컨텍스트를 관리해 잘못된 파일 수정이 없음. 토큰 절약과 속도 면에서도 유리함

• Cursor로 작업할 때는 먼저 한 라우트를 리팩터링하면서 규칙 파일을 생성하게 함. 이후 다른 라우트에서는 “refactor”만 하면 됨

  • 긴 프롬프트를 두려워하지 말 것. 이것이 바로 context engineering임. 대화 기록 자체가 컨텍스트를 풍부하게 만들어줌.
    남은 컨텍스트 용량을 항상 의식하고, 필요 시 일찍 context clear를 하는 게 좋음

• 에이전트를 팀원처럼 대하는 관점이 중요함. 서로의 강점과 약점을 관찰하며 협업 방식을 조정해야 함.
  나는 검증 가능한 문제나 실험용 코드에 에이전트의 힘을 집중함.
  Svelte는 잘 모르지만, TDD 스타일의 disposable 테스트로 리라이트를 유도하는 게 좋을 듯함.
  때로는 이전의 잘못된 맥락을 버리고 새로운 워크스페이스에서 다시 시작하는 게 최선임

  • 그 “인지 스타일과 팀워크” 관련 텍스트의 요약을 공유해주면 좋겠음

• 나는 LLM을 탐색기(searcher) 로 봄. 질문을 작고 구체적으로 하면 탐색이 쉬워지고, 훈련 데이터에서 멀어질수록 오류 확률이 높아짐.

  1. 프로젝트를 Zed에서 열고
  2. Gemini CLI, Qwen code, Claude 중 하나를 연결
  3. 파일을 수정 요청하고 테스트
  4. 안 되면 Grok이나 Gemini 3 Chat에 시도
  5. 그래도 안 되면 수동으로 해결
     새 프로젝트는 one-shot 프롬프트로도 충분히 가능함
  • 하지만 너무 작은 프롬프트는 정보 부족(underspecification) 문제를 일으킴. 계산 비용만 줄 뿐, 품질 면에서는 불리함

• 내가 즐겨 쓰는 Claude Code 툴셋은 superpowers임

  1. 먼저 브레인스토밍 세션으로 기능을 설명
  2. Claude가 디자인 문서와 구현 계획을 작성해 디스크에 저장
  3. 새 Claude 창에서 Execute Plan 명령으로 단계별 실행 및 커밋
  4. 세 단계마다 자체 리뷰를 시켜 코드 품질을 높임
     2주째 쓰고 있는데 거의 실패한 적이 없음

• 나의 AI 프로그래밍 원칙은 단순함

  1. 한 번에 완성(one-shot) 은 실패함
  2. 작업을 검증 가능한 단위로 쪼갬
  3. 전체 계획을 Markdown 파일에 정리
  4. 각 단계마다 새 세션으로 실행하고 검토 후 커밋
     핵심은 “Less is more” 임. 컨텍스트 창은 새로울수록 좋고, 500~750단어 정도가 이상적임. 모든 단계는 검증 가능해야 함

• Java 관련 작업에서는 Claude가 지속적으로 방향을 바꾸거나 모순된 제안을 함. ChatGPT가 훨씬 낫다고 느낌

  • 프롬프트에 더 구체적인 지시를 주면 나아질 수 있음
  • 혹시 Claude Code 버전을 써봤는지 궁금함

• “Idiomatic code”를 원한다면 먼저 자신이 생각하는 스타일을 세세히 정의해야 함. 좋은/나쁜 예시를 작게 나누고, 이를 Opus 4.5의 Plan 모드에 넣어 계획을 세운 뒤 실행함. 한 번에 완벽하지 않으면 계획 문서를 수정하고 다시 시도함. 주니어 개발자처럼 세세히 지도하려 들면 오히려 비효율적임

  • 다른 사람은 “요즘 모델은 꼭 세션을 새로 시작하지 않아도 된다”며, 인라인 리팩터링으로도 충분히 안정적이라고 경험을 공유함