▲

Claude로 실제 코드를 배포하며 얻은 실전 노트

 (diwank.space)
31P by GN⁺ 10시간전 | ★ favorite | 댓글 5개
  • AI 도구인 Claude를 실제 서비스에 적용하며, 개발 생산성 10배 향상 효과의 현실적 달성 방법과 적용 노하우를 정리함
  • ‘vibe-coding’은 단순 유행이 아닌 실질적 방법론으로, 올바른 개발 습관과 인프라를 갖추면 AI의 강점을 극대화하고 약점을 보완할 수 있음
  • AI의 역할을 ‘초안 작성자’, ‘페어프로그래머’, ‘코드 검토자’ 세 가지 모드로 명확히 구분하며, 각 단계에 맞는 문서화와 가드레일이 필수임
  • 핵심은 프로젝트마다 ‘CLAUDE.md’ 파일을 활용해 컨벤션, 아키텍처, 패턴, 금지사항 등을 명확히 문서화하고, 코드 내 ‘anchor comment’로 AI를 효과적으로 가이드하는 것
  • 테스트 코드는 반드시 사람이 작성해야 하며, AI가 테스트·마이그레이션·보안·API 계약·시크릿 등 핵심 영역을 수정하지 못하도록 경계를 엄격히 설정해야 함
  • 올바른 경계와 습관 아래서 AI 코딩을 도입한 팀은 배포 빈도·안정성·개발 속도 모두 대폭 개선할 수 있으며, 실제 운영 노하우와 패턴 공유가 AI 개발 문화의 핵심이 되고 있음

Vibe Coding Isn’t Just a Vibe

  • 이 글은 AI를 활용한 새로운 소프트웨어 개발 방식의 현장 가이드로, 단순한 사용법이 아니라 실제로 효과적인 AI 개발의 '이유'까지 설명함
  • 신화처럼 여겨진 10배 생산성 향상도, AI의 강점은 최대화하고 약점은 보완하는 실천적 습관을 통해서만 가능함을 실제 사례로 보여줌
  • 실제 서비스 중인 Julep 코드베이스에서, CLAUDE.md 템플릿, 커밋 전략, 운영상 재난을 방지하는 가드레일 등 실전 인프라와 운영 노하우를 공개함
  • 특히 테스트 코드는 반드시 직접 작성해야 하며, AI에게 과도하게 의존할 경우 심각한 장애와 디버깅 악몽을 초래할 수 있음
  • AI 개발에는 세 가지 모드(초안 작성, 페어프로그래밍, 검토자) 가 존재하며, 상황에 따라 AI에 주도권을 주거나 인간이 직접 조정해야 하는 리듬과 원칙이 다름
  • 핵심 메시지: 좋은 개발 습관과 경계가 있을 때만 AI가 역량을 증폭시키며, 실제 연구 결과도 "철저한 개발 습관을 가진 팀이 배포 속도, 품질 모두에서 압도적으로 앞선다"는 사실을 보여줌

왜 이 글을 쓰게 되었나: 밈(Meme)에서 실전 방법론(Method)으로

  • AI에게 코드를 맡기고 개발자는 "바이브만 타는"다는 개념(‘vibe-coding’)은 원래 Andrej Karpathy의 농담 트윗에서 시작된 유행임
  • 당시 개발자 커뮤니티는 “AI가 대신 일해주고 우리는 커피나 마신다”는 최고의 판타지로 여기며 웃어넘겼음
  • 하지만 Anthropic의 Sonnet 3.7과 Claude Code 출시 이후, 이 농담이 실제로 가능한 현실로 바뀌기 시작함. 기존 Cursor 같은 도구도 있었지만, Claude Code는 진짜 '바이브 코딩' 느낌을 주기 시작함
  • 필자가 몸담은 Julep은 방대한 코드베이스와 다양한 설계 패턴, 기술적 부채까지 안고 있음. 코드 품질과 문서화는 철저히 유지하지만, 각 파트의 의도와 히스토리를 파악하는 데만 수주가 걸릴 정도로 복잡함
  • Claude를 guardrail 없이 쓰면, 과잉 열정의 인턴이 곳곳에서 실수를 저지르는 것과 같은 혼란이 발생
  • 이 글은 그런 시행착오와 새벽 3시의 디버깅, 실제 서비스 운영에서 살아남은 진짜 실전 패턴과 노하우만을 정리해서 공유함

바이브 코딩(Vibe-Coding)의 본질

  • Steve Yegge가 CHOP(Chat-Oriented Programming) 라는 용어를 만들었듯, ‘바이브 코딩’은 AI와 대화하며 코드를 완성하는 새로운 개발 방식임
  • 전통적인 코딩이 대리석을 조각하듯 한 줄 한 줄 신중하게 만드는 작업이라면,
    • 바이브 코딩은 오케스트라의 지휘자에 가깝고, AI는 원석(기본 코드 능력)을 제공하는 연주자임
    • 개발자는 전체 방향성과 구조를 설계하고, AI가 그 흐름을 따라 코드로 풀어냄
  • 바이브 코딩의 3가지 태도(Postures)
    • 1. AI를 초안 작성자로 활용 (First-Drafter)
      • 아키텍처·설계에 집중하며, 반복 작업(CRUD, 보일러플레이트 등)을 AI가 빠르게 생성
      • 생각하는 속도로 코드를 작성하는 주니어 엔지니어를 둔 느낌이지만, 지속적 가이드 필요
    • 2. AI와 페어프로그래밍 (Pair-Programmer)
      • 가장 실용적이며 효과적인 모드
      • 개발자와 AI가 아이디어를 주고받으며, 큰 틀은 사람이 그리고 세부 구현은 AI가 채움
      • 수많은 프로그래밍 지식은 있지만 실제 배포 경험이 없는 동료와 짝코딩하는 느낌
    • 3. AI를 검토자/코드 리뷰어로 활용 (Validator)
      • 사람이 작성한 코드를 AI가 검토, 버그·개선점·놓친 패턴을 제안
      • 언제나 피곤하지 않고 꼼꼼한 리뷰어 역할
  • 핵심 통찰: 개발자는 ‘작가’에서 ‘편집자’로 역할이 전환됨. 모든 코드를 직접 작성하는 대신, AI가 만든 결과물을 검토·수정·방향 제시함.
  • 단, 전체 아키텍처와 맥락은 인간이 반드시 직접 주도해야 하며, AI는 ‘백과사전적 지식의 인턴’일 뿐 우리 서비스·비즈니스의 맥락은 알지 못함

바이브 코딩 3가지 실전 모드: 프레임워크

수개월의 실험과 실제 배포 사고를 거쳐, 바이브 코딩에는 각기 다른 리듬과 가드레일, 최적의 용도가 있는 3가지 모드가 있음

  • 모드 1: Playground (실험/프로토타입/개인 프로젝트)

    • 사용 시점: 주말 해킹, 개인 스크립트, PoC, 즉흥적 아이디어 테스트 등
    • 특징: 설계·문서·가드레일 없이, AI가 코드의 80~90%를 작성. 아이디어 → 결과물까지 몇 분 만에 도달하는 속도
    • 위험: 실서비스/중요 코드에는 부적합. 장난/실험용으로만 사용. 엔지니어링 원칙은 오히려 더 중요해짐

  • 모드 2: Pair Programming (실사용·소규모 서비스)

    • 사용 시점: 5,000라인 이하 프로젝트, 실사용자 있는 사이드 프로젝트, 데모, 소규모 모듈 등
    • 핵심: 프로젝트의 관습·아키텍처·패턴·테스트 가이드 등을 CLAUDE.md로 한 번에 명확히 정의
    • 장점: 새 개발자 온보딩하듯, Claude에게 한 번만 설명하면 일관성 있게 코드 생성
    • 실전 포인트:
      • 코드 곳곳에 anchor comment(AIDEV-NOTE, AIDEV-TODO, AIDEV-QUESTION 등)로 Claude가 맥락을 잃지 않게 가이드
      • 이런 주석은 AI와 사람이 모두 참고할 수 있는 지침 역할, CLAUDE.md에 관리 기준과 예시까지 명시

  • 모드 3: Production/Monorepo Scale (대규모 서비스)

    • 사용 시점: 수십~수백 명 개발, 실사용자 있는 대형 서비스, 한 번의 실수로 큰 피해 발생 가능한 상황
    • 주의: 현시점(2025년 6월) 기준, 대규모 일괄 바이브 코딩은 완벽하게 확장되지 않음
    • 원칙: 개별 서비스/서브모듈 단위로 바이브 코딩 도입 권장, 모든 통합지점(API·DB 등)에 명확한 경계와 버전 관리, 주요 인터페이스·API에 변경 주의 주석 필수
    • 실전 예시:
      • # AIDEV-NOTE: API Contract Boundary - v2.3.1
      • # Changes require version bump and migration plan
      • 이런 경계선이 없으면 Claude가 함부로 개선하다가 실제 서비스 전체를 깨뜨릴 수 있음
  • 결론: 대규모 프로젝트는 바이브 코딩을 점진적으로, 분리된 서비스 단위로 도입하고, 반드시 문서화·가이드라인·리뷰 등 전통적 원칙을 병행해야 신뢰성 확보 가능

인프라 중심의 지속가능한 AI 개발 환경 만들기

  • CLAUDE.md: AI와 사람 모두를 위한 단일 진실(The Single Source of Truth)

    • CLAUDE.md는 모든 프로젝트 규칙, 아키텍처, 주의사항, 코드스타일, 금지 대상, 도메인 용어집 등을 체계적으로 담는 ‘헌법’ 역할을 함
    • AI와 새로운 팀원이 공유할 ‘지식의 뼈대’로 기능, 예시와 함께 구체 가이드라인과 금지사항을 노동집약적으로 관리
    • 좋은 CLAUDE.md에 투자하는 팀일수록 더 나은 결과를 만들어냄
    • 우리의 프로덕션 CLAUDE.md 참고
    • 코드베이스가 커질수록 CLAUDE.md만으로는 부족하고, 각 코드 곳곳에 anchor comment(AIDEV-NOTE/TODO/QUESTION 등)로 로컬 컨텍스트를 명확히 전달해야 함
    • 코드베이스를 도시로 비유한다면 anchor comment는 AI와 사람이 모두 길을 잃지 않게 해주는 표지판
    • 이런 주석은 단순 코드 설명을 넘어, "왜" 이렇게 동작하는지의 스토리를 남김

  • Git 워크플로우, AI 코드의 체계적 관리

    • AI 코드 생성 속도가 빨라질수록, 잘못 관리하면 git 히스토리가 오염될 수 있음
    • git worktree 방식 등으로 메인 브랜치에서 분리한 AI 실험 공간 마련해, 코드는 자유롭게 생성하되 기록은 체계적으로 구분/관리
    • 커밋 메시지엔 AI 관여 내역을 반드시 명시([AI] 태그 활용 등), 리뷰어가 추가로 주의 검토할 수 있도록 함

불문율: 테스트 코드는 반드시 사람이 작성

  • AI 보조 개발에서 가장 중요한 원칙: "테스트 코드는 절대 AI에게 맡기지 말 것"
  • 테스트는 단순히 동작 확인용 코드가 아님
    • 실제 문제 맥락, 엣지 케이스 인식, 사업적 요구 해석, 도메인에 대한 인간의 이해와 경험이 녹아든 실행 가능한 명세임
    • 속도와 안정성 모두 놓치지 않는 고수 팀은, 바로 이 테스트를 철저히 인간이 관리
  • AI가 자동 생성한 테스트는 피상적 경로(happy path)만 검증하며, 예기치 않은 심각한 문제(예: 메모리릭 등)는 놓침
  • 우리팀의 경우 AI가 테스트 파일을 건드리면 PR은 자동 반려 (예외 없음)
  • 테스트는 코드의 명세이자 안전망, 누적된 모든 버그와 엣지케이스의 지혜
  • 반드시 사람의 손으로 작성하고, AI가 만질 수 없도록 강력하게 보호해야 함

확장과 맥락관리: 토큰 경제와 컨텍스트 최적화

  • AI 코드 개발에서 흔히 저지르는 실수:
    "토큰 절약"을 위해 맥락(프롬프트, 요구사항, 환경 등)을 최소화하면 오히려 반복 작업이 늘고 전체 토큰 소비가 증가함
  • 적절한 맥락 제공이 장기적으로 더 효율적
    • "최소"가 아니라 "관련성 있고 충분한 맥락" 을 미리 주는 것이 핵심
  • 나쁜 예시: 맥락 부족 프롬프트 "Add caching to the user endpoint"
    • Claude는 단순 인메모리 캐싱, 무효화 전략/모니터링 없음, 멀티 서버 고려 없음, 캐시 스탬피드 무대책
    • 결과적으로 3번 이상 반복 수정을 거쳐, 총 4배 이상의 토큰이 소모됨
  • 좋은 예시: 맥락이 풍부한 프롬프트 
    Add Redis caching to the GET /users/{id} endpoint.  
Context:  
* 엔드포인트 트래픽 5만 req/분, 12대 API 서버, 데이터 변동 적음  
* 기존 Redis 인프라 위치, 표준 키 패턴, Prometheus 기반 메트릭 요구  
* 캐시 어사이드 패턴, TTL 1시간, 캐시 스탬피드 방지(확률적 조기 만료)  
* 캐싱 가이드 문서 참조
    • 처음부터 구체적 맥락을 제공해, 반복 없는 정확한 구현 가능
  • 결론:
    • "토큰은 좋은 도구에 투자하는 셈"
    • 미리 맥락을 충분히 넣으면, 장기적으로 반복과 수정이 줄어 비용이 절약됨
  • 실전 팁: 모든 프로젝트는 코드 변경 시마다 Claude에게 코드베이스 변화와 관련 맥락을 CLAUDE.md에 갱신하도록 요청

세션 관리와 맥락 오염 방지

  • 작업별로 Claude 세션을 새로 시작하는 것이 중요
    • 하나의 긴 대화에 여러 작업(예: DB 마이그레이션, 프론트엔드 디자인 등)을 혼합하면 컨텍스트가 섞여 의도하지 않은 결과 초래
  • 규칙: 한 작업 = 한 세션, 완료 시 세션 새로 시작
    • Claude의 '멘탈 모델'을 항상 깨끗하고 집중된 상태로 유지
    • 마치 생닭과 야채용 도마를 구분해서 쓰는 것처럼 맥락을 분리

실전 사례: 에러 처리 구조 전환

  • 실제로 500+ 엔드포인트에서의 ad-hoc 에러 처리방식을 구조화된 에러 계층(hierarchy) 으로 대체한 사례 소개
  • 사람(아키텍트)이 사전에 핵심 설계(SPEC.md/요구사항/에러 분류)를 작성하고, Claude가 실제 코드 대량변환(기계적 작업)의 실행자 역할을 맡는 방식
  • 아키텍처 원칙과 구체적 명세, 설계문서 예시/개념 도출 -> AI에 명확한 작업 지시 -> 정확 4시간 내 전체 리팩터링 완료 경험

AI 시대의 리더십과 조직문화

  • 시니어 엔지니어의 역할은 직접 코드 작성에서, 지식 큐레이션·경계 설정·AI/사람 모두를 가이드하는 일로 진화
  • 린(Lean) 매니지먼트, 지속적 배포 등 현대 개발 문화가 AI 협업 관리에도 그대로 중요함

  • 신규 입사자 온보딩 체크리스트(인간 + AI 협업 분리)

    • 1주차: 기본기 다지기
      • 팀의 CLAUDE.md(공통/서비스별) 읽기
      • 개발 환경 세팅
      • 첫 PR 제출(100% 직접 코딩, AI 금지)
    • 2주차: AI 협업 실습
      • Claude에 팀 템플릿 적용, 설정
      • '장난감 문제'를 AI와 함께 풀기
      • 프롬프트 패턴 연습
      • AI 보조 첫 PR(멘토/시니어와 함께)
    • 3주차: 독립적 실무
      • AI 보조로 주요 기능 개발 및 배포
      • 동료의 AI 코드에 대해 직접 테스트 작성
      • 코드리뷰 세션 1회 주도

투명한 문화 구축하기 : AI 활용의 적극적 공개

  • 모든 AI 활용 커밋에는 아래와 같이 커밋 메시지 태그로 명확히 표시 
    feat: add Redis caching to user service \[AI]  
# \[AI] - 50% 이상 AI 생성, \[AI-minor] - 50% 미만, \[AI-review] - 리뷰만 AI 사용  
# AI가 캐시/클라이언트 코드 작성, 캐시키 설계/테스트/검증은 사람이 직접
  • 효과
    1. 리뷰어가 AI 코드에 특별히 주의
    2. 디버깅 시 코드 출처 파악 용이
    3. AI 사용에 대한 부끄러움·은폐 문화 제거, "책임감 있게 AI를 쓴다"는 팀 문화 확립
  • 누구나 부담 없이 AI를 활용하고, 고성과 문화에 기여할 수 있도록 적극적인 공개와 문화적 장치가 중요

Claude의 금지사항: AI는 여기엔 절대 손대지 말 것

  • 테스트 파일/데이터베이스 마이그레이션/보안 핵심코드/API계약(버전관리 미포함)/환경 설정 및 시크릿 등은 AI의 자동화 절대 사용 불가
  • 실수 등급별(포맷·의존성부터 비즈니스 핵심영역 데이터 파괴까지)로 구분해, 고위험 영역엔 추가적인 강제 가드레일 적용 강조
  • AI 실수의 위험 등급(Hierarchy of AI Mistakes)
    • Level 1: 귀찮지만 치명적이지 않음
      • 포맷 오류(린터로 잡힘)
      • 장황한 코드(나중에 리팩터링)
      • 비효율적 알고리즘(프로파일링 시 발견)
    • Level 2: 비용 많이 드는 오류
      • 내부 API 호환성 깨짐(팀 조율 필요)
      • 기존 패턴 변경(혼란 초래)
      • 불필요한 의존성 추가(코드 비대화)
    • Level 3: 경력에 치명적(Career-Limiting)
      • 테스트 결과를 맞추기 위해 테스트 자체 수정
      • API 계약 파괴
      • 시크릿/개인정보 유출
      • 데이터 마이그레이션 손상
    • 실수의 레벨에 따라 가드레일 수준도 달라져야 하며, Level 3 실수는 커리어에도 중대한 위협이 됨

개발의 미래: 앞으로의 변화와 방향

  • 2025년 현재, AI 보조 개발은 사춘기 청소년처럼 강력하지만 아직 어색하고 거칠음
  • 그러나 성장 곡선은 명확하게 '가속' 중
  • 좋은 문서화(Documentation)는 AI 시대 DevOps 구현의 핵심 인프라
    • 문서는 이제 '참고자료'를 넘어, 인간 의도와 AI 실행 사이의 직접적 '인터페이스'
    • 고성과 팀은 테스트만큼 CLAUDE.md 등 문서 관리에 철저함

  • 앞으로 예상되는 변화

    • 코드 전체 맥락을 이해하는 AI
      • 파일 단위가 아닌 서비스/시스템 레벨까지 파악
    • 세션·프로젝트를 넘는 지속적 메모리
      • 대화와 작업 맥락을 장기적으로 기억·활용
    • 적극적 개선 제안을 하는 AI
      • 요청 없이도 문제·개선점을 미리 진단
    • 팀별 패턴·선호도를 학습하는 AI
      • 조직만의 스타일/관례에 맞는 코드를 자동 생성
  • 하지만, 기본은 변하지 않음:
    • 방향 설정은 인간, 실행·지렛대는 AI
    • 도구가 아무리 강력해져도, 우리는 여전히 ‘도구를 쓰는 사람’임

결론: 지금, 여기서 시작하세요

  • 여기까지 읽었다면 기대와 동시에 약간의 두려움도 느낄 것임
    • 그 반응이 정상, AI 보조 개발은 강력하지만 '의도적이고 체계적인 실천'이 필수

  • 오늘 바로 실천할 액션 플랜

    • 오늘
      • 1. 현재 프로젝트에 CLAUDE.md 파일 만들기
      • 2. 본인이 가장 복잡하다고 생각하는 코드에 anchor comment 3개 직접 추가
      • 3. 명확한 경계(가이드) 아래 AI 보조 기능 1개 시도
    • 이번 주
      • 1. 팀 단위로 AI 커밋 메시지 규칙 만들기
      • 2. 주니어 개발자와 함께 AI 코딩 세션 한 번 운영
      • 3. AI가 만든 코드에 대해 직접 테스트 코드 작성
    • 이번 달
      • 1. AI 도입 전후의 배포 빈도 변화 측정
      • 2. 팀 내 반복 작업에 대한 프롬프트 패턴 라이브러리 구축
      • 3. 팀 전체 AI 협업 회고 미팅 진행
  • 핵심은 "지금 당장, 작게, 신중하게, 그러나 반드시 시작"
  • 이 흐름을 빨리 마스터한 개발자는 더 똑똑해서가 아니라,
    • 더 일찍 시작해서 더 많이 실수하며 학습했기 때문
  • 소프트웨어 배포 성과가 곧 조직의 성과를 좌우
    • 속도와 품질이 경쟁력인 시대, AI 보조 개발은 선택이 아닌 '필수 역량'
    • 단, 올바른 방법으로 접근해야 함
  • 바이브 코딩은 장난처럼 들리지만,
    • 인간의 역량을 증폭하는 진지한 개발 방식
    • 도구와 패턴은 이미 충분히 준비됨
    • 이젠 누가 오케스트라를 지휘할지, 누가 혼자서 모든 악기를 연주할지 선택할 때

실전 자료와 추천 리소스

▲
kimjoin2 7시간전  [-]

ai 도움을 받는 코딩을 의미하는 vibe 코딩에서 vibe는 어떤 의도인지 아직도 모르겠음.
분위기? 느낌? 어울림? ai랑 연관도없고
퉁퉁퉁 사후르 급으로 맥락없이 느껴짐.

답변달기
▲
hohemian 5시간전  [-]

뇌를 비우고 흐름에 몸을 맡기세요.
모든 로직은 AI가 짜줍니다.
탭키싸게가 되는거에용!

답변달기
▲
secret3056 5시간전  [-]

look and feel👀🎵🎷. 이해하지 말고🧠 느끼세요!😊

같은 느낌이죠

답변달기
▲
humblebee 5시간전  [-]

오 그런가요? 저는 딱 들었을때 '느낌'이 오던데..
말씀하시니.. 요즘은 비개발 직군도 잘 이해하고 있는 '하드코딩(hard-coding)' 이라는 용어가 떠오릅니다.
요 단어 역시 처음에는 단어 자체로는 무슨 의미인지 알기 어렵지만, 개발을 배우다 보면 결국 무엇을 의미하는지 어떤 의도인지 모두가 잘 이해하고 있는 그런 '느낌'이랄까요? ㅎㅎ

답변달기
▲
GN⁺ 10시간전  [-]
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 쪽의 사용량이 장기적으로 비용을 더 키우는 방식

    • Max 구독은 두 가지 티어가 있고, $100은 Pro보다 토큰 5배, $200은 20배 제공
      토큰 계산이 쉽지 않고, 하이브리드 모드는 Opus 토큰 20% 남을 때까지만 Opus 사용 후 Sonnet으로 자동 전환되는 구조

  • 잘 쓴 글이지만 “테스트는 절대 AI에게 맡기지 말라”는 부분엔 의견 다름
    나는 요즘 모든 테스트를 AI로 작성시키고 직접 꼼꼼히 리뷰
    신규 코드라면 AI에게 테스트까지 맡겨야 높은 자율성이 가능
    AI에게 테스트 구현과 통과를 명확히 지시한 다음, AI가 개발 중일 때 즉시 리뷰하고 부족한 테스트 케이스는 추가하는 구조로 운용

  • 대부분 내용에 공감하지만, Claude가 테스트나 마이그레이션을 손도 못 대게 하는 정책엔 동의 못 하는 부분
    테스트를 직접 쓰는 게 가장 싫은 작업인데, LLM이 최소한의 초안만 작성해줘도 큰 도움이 되는 상황
    핵심은 생성 주체와 관계없이 최종 소유권과 책임은 항상 인간에게 있게 하는 것
    메시지의 뉘앙스상 저자는 Claude에 대한 신뢰 부족, 또는 직원들이 AI 결과물을 무비판적으로 받아들이지 않으려는 목적이 강한 듯
    혹은, 테스트/마이그레이션 관련 엄격한 규칙이 없으면 진짜 코드가 고장나거나 데이터 손실 발생 가능성이 현실적이라고 판단하는 듯

    • 그 말도 맞지만, 내 경험상 큰 문제를 겪은 사례가 있었음
      1. 생성된 테스트를 나중에 사람이 수동으로 고칠 때 진짜 심각한 함정이 많았음
      2. Claude는 문맥 컨텍스트를 잘 모르니까 거의 모든 걸 mock 처리해서 우리 서비스/빌드 환경과 완전히 동떨어진 테스트 자주 생성
      3. 그리고 더 큰 문제는, 팀 전체가 테스트에 대해 너무 게을러진다는 점
        실제로 production에서 버그가 크게 증가했음
답변달기