포스트

'마녀:귀찮아!' DevLog 06 — Claude와 함께 개발하기

Claude를 WM 전체 개발 사이클에 도입한 경험 — 기술 결정·구현·검증 단계의 AI 협업 워크플로우와 배운 점.

'마녀:귀찮아!' DevLog 06 — Claude와 함께 개발하기

머리말


WM 개발에 AI 협업을 본격 도입했다. 처음엔 코드리뷰나 간단한 리팩토링만 시켰지만, 최근엔 아키텍처 설계부터 테스트 작성까지 전체 개발 사이클에 Claude를 참여시키고 있다.

이 변화가 개발 속도와 코드 품질에 미친 영향, 그리고 앞으로의 방향을 기록한다.

AI와 함께하는 개발의 변화


전: 수동 작업 중심

  • 기능 설계 → (혼자 고민) → 코드 작성
  • 리팩토링은 시간이 나면 나중에
  • 테스트 커버리지 낮음

후: AI와 대화 중심

  • 기능 요청 → Claude에 구현 방향 상의 → 함께 설계
  • 코드 작성 중 막히는 부분은 바로 질문
  • 테스트를 먼저 짜고 구현
  • 검증을 구조화하는 습관 생김

구체적 워크플로우


기술 결정 단계

새 기능을 구현하기 전에 여러 방식을 비교한다.

예: “캐릭터 초상화 렌더링을 할 때 Prefab을 쓸지 Procedural Mesh를 쓸지 고민이야”

Claude는:

  • 각 방식의 장단점 정리
  • 기존 아키텍처와의 호환성 검토
  • 성능 예상치 제시
  • 비슷한 게임의 사례 언급

결정이 더 빠르고 확신 있게 된다.

구현 단계

  • 복잡한 로직: 의사코드 먼저 작성 → Claude가 C# 구현으로 변환
  • 간단한 부분: “이 함수 이렇게 수정 가능할까?” → 받아서 조정
  • 에러 발생: 메시지 + 코드 컨텍스트 보내기 → 원인과 해결법 제시

검증 단계

  • 로컬 빌드 + 플레이 테스트 (여기만 수동)
  • 회귀 케이스: Claude가 수정한 부분 중심으로 테스트 케이스 작성
  • 커밋 전: 내가 인증한 부분만 푸시

배운 점


프롬프트 엔지니어링의 중요성

“이 함수를 최적화해줘” vs “이 함수가 100k 반복에서 1초 걸려. 병목을 찾고 고쳐줄 수 있어?”

→ 후자가 훨씬 좋은 결과를 낸다. 맥락 제공이 핵심.

AI는 보조이지 대체가 아니다

설계 결정, 테스트 검증, 최종 승인은 여전히 내가 한다. AI를 무조건 따르면 기술 부채가 쌓인다.

반복적 대화가 가장 효율적

한 번에 완벽한 코드를 요청하기보다 “일단 이렇게 만들어줄래 → 봤어, 여기만 다시” 식 대화가 더 빠르다.

그 외


  • 프로젝트 구조(폴더, 다이어그램)를 Claude와 공유하는 방식 정립
  • 급한 버그 대응 시 Claude의 진단 속도가 매우 유용
  • 코드스타일 + 설명 방식을 미리 알려주면 일관성 높아짐
  • 매 세션 시작 전 “지금 WM의 상태는 X야”라고 브리핑하는 습관

다음


  • 이 워크플로우를 문서화해 팀(나중에 생기면)과 공유
  • AI와 협업하기 좋은 프로젝트 구조 연구
  • 자동 테스트 + CI/CD 파이프라인 강화

메모

  • 참고: Cursor IDE, GitHub Copilot 도입 사례들과 비교해보기 — WM은 Claude CLI를 로컬 워크플로우에 통합 중
  • 키워드: pair programming, prompt engineering, code quality gate, LLM native workflow
  • 다음 편 아이디어: WM 아키텍처 리팩토링 기록 (Composition Root 패턴 도입기)

To Be Continued..

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.