클로드와 함께 실제 코드를 배포하며 얻은 현장 노트: 요약 및 구조화

1. 서론: AI 코드 도구 활용 경험 공유의 필요성

• 글쓴이(Author)는 최근 클로드(Claude)와 같은 LLM(대형 언어 모델) 기반 코드 도구에 대한 글이 넘쳐나지만, 실제로 현장에서 얻은 실질적인 팁을 공유하고자 글을 썼다고 밝힙니다.
• 강조 대사

  "솔직히 말해서, 요즘 클로드 코드 관련 글이 정말 넘쳐나죠. 하지만 우리가 발견한 몇 가지 진짜 유용한 팁은 공유할 가치가 있다고 생각했어요."

2. 핵심 팁: Anchor Comments(앵커 주석) 시스템

• Anchor Comments란?
  코드 곳곳에 특정 형식의 주석을 남겨, 나중에 쉽게 검색(grep)하고, 코드의 맥락이나 중요 포인트를 기록하는 방법입니다.

• CLAUDE.md 예시

  ### Anchor comments
  
  Add specially formatted comments throughout the codebase, where appropriate, for yourself as inline knowledge that can be easily `grep`ped for.
  
  - Use `AIDEV-NOTE:`, `AIDEV-TODO:`, or `AIDEV-QUESTION:` as prefix as appropriate.
  - _Important:_ Before scanning files, always first try to grep for existing `AIDEV-…`.
  - Update relevant anchors, after finishing any task.
  - Make sure to add relevant anchor comments, whenever a file or piece of code is:
    - too complex, or
    - very important, or
    - could have a bug
  

• 주요 키워드:

  • AIDEV-NOTE:, AIDEV-TODO:, AIDEV-QUESTION:
  • CLAUDE.md 파일
  • 코드 복잡성, 중요성, 버그 가능성에 따라 주석 추가

• 강조 대사

  "코드베이스 곳곳에 적절한 위치에 특수 형식의 주석을 추가하세요. 너무 복잡하거나, 매우 중요하거나, 버그가 있을 수 있는 부분에는 반드시 앵커 주석을 남기세요."

3. 실제 사용 경험과 커뮤니티 반응

• 경험 많은 엔지니어의 피드백

  "LLM을 체계적으로 쓰진 않지만, 실제 프로젝트에서 어떻게 활용하는지 보니 동기부여가 되네요. 이런 실용적인 시스템을 공유해줘서 고마워요."

• 다른 도구와의 비교
  • aider와의 차이: aider는 메모리/컨텍스트 관리가 뛰어나지만, 글쓴이는 클로드 코드의 TUI(터미널 UI)가 더 마음에 든다고 언급.

    "aider는 완전히 다른 도구예요. 메모리/컨텍스트 관리가 최고지만, 저는 클로드 코드의 TUI가 더 좋아요. 결국 개인 취향과 워크플로우의 문제죠."

4. 테스트 코드와 LLM의 역할

• 테스트 코드는 사람이 직접!
  • 글쓴이는 AI가 테스트 코드를 작성하거나 수정하는 것을 금지한다고 강조합니다.

    "절대. AI에게. 테스트를. 맡기지. 마세요."

• 이유
  • AI가 테스트를 작성하면, 나중에 사람이 이해하거나 수정하기 어려워지고, 개발자들이 테스트에 소홀해져 프로덕션 버그가 증가했다고 경험을 공유합니다.

    "AI가 생성한 테스트를 나중에 사람이 수정하려고 하면 정말 난감한 상황이 생겼어요. 그리고 개발자들이 테스트에 너무 게을러져서 실제로 버그가 많이 늘었죠."

• 실제 적용 방법
  • CLAUDE.md에 테스트 디렉토리 편집 금지 명시
  • .claude/settings.json에서 테스트 디렉토리 편집 도구 비활성화
  • PR 리뷰와 커밋 메시지로 AI가 테스트를 건드렸는지 확인(주로 신뢰에 기반)
• 반론
  • 일부는 "AI가 테스트를 1차로 작성하고, 사람이 리뷰하는 방식도 유용하다"고 주장

    "AI가 테스트를 먼저 작성하고, 사람이 꼼꼼히 리뷰하는 방식이 저에겐 큰 도움이 됐어요. 중요한 건 최종 책임은 사람이 진다는 점이죠."

5. LLM 도구 선택과 비용

• 클로드 코드(Claude Code)와 Opus 4
  • Opus 4 모델이 가장 강력하며, Max 구독($100/월, $200/월)이 추천됨.
  • 토큰 계산이 복잡하다는 의견도 있음.

    "가장 간단한 시작은 Claude Max $100 티어를 구독하고 Opus 4를 쓰는 거예요. 다른 모델은 제대로 된 경험을 주지 못하거든요."

• 비용에 대한 현실적인 고민
  • 하루에 $10 이상 쓰기도 하고, 연간 $2,000까지 올라갈 수 있음.

    "며칠 전에 개인 프로젝트에서 클로드 코드를 써봤는데, 너무 효율적이더라고요. 근데 정말 비싸요. 하루에 10달러 넘게 썼어요. 하지만 어쩔 수 없이 AI 세금 내야 할 것 같아요."

• 해외 저렴한 개발자 vs LLM
  • LLM의 성능이 빠르게 향상되고 비용이 떨어지면서, 일부 회사는 저렴한 국가의 개발자 대신 LLM을 선호하기도 함.

    "저렴한 국가의 개발자보다 LLM이 더 빠르고 저렴해서, 이제는 그쪽 인력을 더 이상 뽑지 않아요."

6. LLM 활용의 조직적/문화적 변화

• 투명성과 팀 규칙
  • LLM을 쓴다고 해서 팀 규칙이 사라지는 건 아님.
    코드 리뷰, 린터, 팀 규칙 등 기존 개발 문화가 여전히 중요.

    "클로드나 다른 자동화 도구를 쓴다고 해서 팀 규칙이 사라지는 건 아니에요. 코드 리뷰, 린터 등으로 팀의 기준을 지키는 게 여전히 중요하죠."

• AI가 불편한 영역은 시스템화의 신호
  • AI가 다루기 불편한 부분은 검증/검사 시스템을 도입할 신호로 삼을 수 있음.

    "AI가 뭔가를 하는 게 불편하다면, 그건 그 부분에 체계적인 검증 시스템을 도입해야 한다는 신호일 수 있어요."

• 문서화와 주석의 역할
  • CLAUDE.md, SPEC.md, AIDEV 주석 등으로 LLM이 이해할 수 있도록 명확한 규칙과 예시를 제공해야 함.
  • 인간을 위한 문서와 LLM을 위한 문서는 스타일과 내용이 다름.

    "사람을 위한 스타일 가이드는 100줄이면 되지만, 클로드를 위한 가이드는 500줄이 넘어요. 예시도 훨씬 많이 들어가야 하죠."

7. 실제 워크플로우와 생산성

• LLM을 활용한 대규모 리팩토링
  • 500개 이상의 엔드포인트를 4시간 만에 리팩토링(테스트 제외)

    "테스트는 포함 안 됐어요. 그건 훨씬 오래 걸렸죠. 이제 우리 개발자들은 테스트를 대충 썼다는 핑계는 못 대겠네요."

• 문서/연구 통합
  • 클로드 코드의 에이전트적 마크다운 편집 기능으로, 여러 자료를 한 문서에 의미적으로 통합 가능

    "클로드 코드에 복사해서 붙여넣으면, 단순 병합이 아니라 '이 연구의 관련 부분을 이 문서에 통합해줘' 같은 의미적 병합이 가능해요. 정말 강력하죠!"

8. 커뮤니티의 논쟁: LLM 활용과 진정성

• AI 활용 투명성 논란
  • 글의 40~60%가 LLM의 도움을 받았다는 점이 논란이 됨.
  • HN(해커뉴스) 운영진은 "콘텐츠의 질이 중요하다"는 의견과 "진정성이 더 중요하다"는 의견이 대립.

    "가장 흥미롭고 통찰력 있는 콘텐츠가 LLM에서 나왔다면, 그게 우리가 읽고 토론해야 할 내용 아닌가요?" "아니요. 차라리 지루하더라도 진짜 사람이 쓴 글이 더 낫죠."

• 결론적으로
  • 저자는 "아이디어와 코드, 예시, 이미지 등은 모두 내 것이고, LLM은 초안 작성과 연구에 도움을 줬다"고 해명.
  • 운영진은 "비영어권 저자가 LLM을 활용해 글을 다듬는 건 허용할 수 있다"며 글을 다시 메인에 올림.

9. 마무리: LLM 도구의 미래와 개발자의 역할

• LLM은 아직 완벽하지 않지만, 빠르게 발전 중
  • "새로운 지렛대가 만들어지는 중이고, 아직은 거칠지만 배울 가치가 있다."
• 개발자의 책임
  • LLM이 코딩을 빠르게 해주지만, 테스트와 검증, 최종 책임은 여전히 개발자에게 있음.

    "기능 개발이 빨라진 만큼, 테스트는 직접 쓰게 하면 개발자가 코드와 버그에 책임을 지게 됩니다."

핵심 요약

• 앵커 주석(Anchor Comments), CLAUDE.md 등으로 LLM과 협업하는 체계적인 방법을 도입하면, 코드 품질과 생산성을 높일 수 있음.
• 테스트 코드는 사람이 직접 작성하는 것이 바람직하며, LLM이 도와주더라도 최종 검증과 책임은 개발자에게 있음.
• 비용은 만만치 않지만, LLM의 성능과 효율성은 빠르게 발전 중.
• 팀 문화와 규칙은 LLM 도입 후에도 여전히 중요하며, 투명성과 책임감을 유지해야 함.
• AI 활용의 진정성과 콘텐츠의 질에 대한 논쟁이 있지만, 결국 중요한 건 실질적인 가치와 결과임.

💡 이 글을 읽고 나면, 단순히 LLM을 어떻게 쓰는지 뿐만 아니라, 왜 이렇게 써야 하는지, 그리고 실제로 현장에서 어떤 고민과 시행착오가 있었는지까지 이해할 수 있습니다!

주요 키워드:

• Anchor Comments
• CLAUDE.md
• AIDEV-NOTE, AIDEV-TODO, AIDEV-QUESTION
• 테스트 코드 직접 작성
• LLM 도구(Claude Code, Opus 4, aider, Cursor)
• 비용/구독
• 팀 규칙, 코드 리뷰
• 투명성, 진정성, 책임

😊 혹시 더 궁금한 점이 있으면 언제든 질문해 주세요