류큐큐 개발 일지

벌써 1년이 흘렀다 작년 이맘때, 러너스하이 1기에 선정되고 운이좋게 면접 기회가 있었지만 면접에서 아쉽게 떨어졌던 기억이 아직도 선명하다. 이번 2기를 준비하면서 지난 1년간의 경험과 경력기술서를 다시 펼쳐보며 그동안 무엇을 해왔는지, 어떤 부분에서 성장했는지 차분히 돌아보게 되었다. 시간이 참 정말 빠르다 이번년도는 1기때 깨우친 스스로 공부하는 방법 과 여러 면접등을 통해 개인적으론 많이 성장한 한해가 아닌가 싶다. 결과는 항상 안좋았지만 ㅠ 이번 기수에서는 좋은 결과가 있었으면 좋겠다. 그리고 무엇보다 이 과정 자체가 또 한 번 나를 성장시켜주길..

수동 검증의 한계Terraform을 쓰면서 가장 먼저 부딪힌 문제는 검증의 일관성이었다.PR 하나 열 때마다 리뷰어는 다음을 확인해야 한다.Terraform 문법보안 취약점조직 정책 준수 여부비용 변화필수 태그 여부네이밍 규칙암호화 설정문제는 간단하다.사람이 이걸 매번 수동으로 검증하면 언젠가 반드시 놓친다.리뷰 시간이 길어지고, 리뷰어에 따라 기준도 달라진다.심하면 배포 이후에 문제를 발견한다.그래서 나는 검증 자체를 PR에 붙여 버렸다.리뷰어의 역량이나 컨디션에 의존하지 않도록.PR이 열리면 자동으로 검증이 흐르는 구조내가 만든 전체 구조는 이렇다.PR 생성 → GitHub Actions 트리거 │ ├─ Terraform 검증 (fmt, validate) ..

PC, RDS, SG, ECS…처음엔 “Terraform으로 만들어서 코드화만 하면 끝이겠지?”라고 생각했다.그런데 조금만 규모가 커지면 금방 깨닫는다.“아, 이거 모듈 없으면 유지보수 지옥이겠는데?” 3편에서는 내가 Terraform을 모듈화하면서 얻은 이점과실제로 지금 운영 중인 모듈 구조를 어떻게 만들었는지 정리해봤다. 왜 모듈화가 필요한가?Terraform을 쓰다 보면 이런 코드가 생긴다.dev/security-groups.tfstaging/security-groups.tfprod/security-groups.tf그리고 세 파일이 거의 똑같다.처음엔 크게 신경 안 쓴다.하지만 프로젝트가 조금만 커지면 문제는 바로 드러난다.같은 태그를 여러 군데에 또 적어야 하고한 곳만 수정하면 환경마다 값이 달라..

클로드 코드(Claude Code)를 쓰다 보면 속도는 정말 빠르다.한 번 프롬프트만 잘 주면 엔터프라이즈 레벨의 코드도 순식간에 뽑힌다. 그런데 문제는, 결과물의 일관성이다.클린하지 않은 로직, 규칙이 제각각인 이름, 그리고 지나치게 과한 코드들.결국 내가 손을 많이 봐야 하고, 며칠 써보면 토큰은 순식간에 녹아내린다.그래서 ‘이걸 어떻게 하면 AI에게 인간의 루틴을 심어줄 수 있을까?’ 라는 생각이 들었다.그 시점에서 눈에 들어온 게 바로 Kent Beck의 CLAUDE.md였다. 📖 Kent Beck의 CLAUDE.md — “AI에게도 TDD를 시킨다”얼마 전 딩코딩코 님 유튜브에서 봤는데, 켄트 백은 클로드 코드를 TDD 형태로 돌리고 있었다.AI에게 “작은 단위, 명확한 목표, 단계적 리팩터링..

해당 방법 주의점클로드 코드가 토큰 먹는 하마가 된다. 그래서 이제 이렇게는 안쓰지만 이런식의 방법도 한번 트라이 해봤다 느낌으로 보면 될거같다.문제 인식클로드 코드를 사용해서 개발 생산성을 높이기 위해 이것저것 처리하다 보니 항상 느끼는건 클로드 코드로 코드를 생성하는것 자체는 굉장히 빠르지만 문제는 일관되지 않은 컨벤션 및 자꾸 뭔가 이상한 로직들 그리고 우회하는 코드들이 많다라는 점이다. 그래서 계속해서 사용하다 보면 퀄리티 자체를 기대하면 안되는데 아무리 총 해야할 작업들을 잘게잘게 쪼개서 컨텍스트를 유지한다 하더라도 이게 잘 안되더라. 프롬프트가 아니라 프로세스 (Ⅱ): 컨텍스트 드리프트를 막는 다섯 가지 벽지난 글에서 노션→지라→LLM→PR의 파이프라인을 만들었다.태스크를 잘게 쪼개고, 한..

점심시간인데 이것저것 클로드코드로 뚝딱 거려본 결과 내 블로그 글에도 이상하게 똥싸는걸 막기위해 여러가지 방법론에 대해 써놧지만 저 난리를 쳐도 결과물은 별로인거같다 https://github.com/ryu-qqq/FileFlow/tree/pure-claude-code-chaos GitHub - ryu-qqq/FileFlowContribute to ryu-qqq/FileFlow development by creating an account on GitHub.github.com 보다보면 어지럽다. 그런데 갑자기 그런 생각이 들었다. 이거 만약에 백엔드 엔지니어 페르소나 뭐 이런거처럼 헥사고날에 도메인에 아이디 전문 생성자 그리고 도메인에 관련된 문서를 개빡세게 넣어서 클로드 세션이 시작할때 훅에다가 ..

Google의 Gemini Code Assist는 무료로 PR 리뷰를 해준다.하지만 문제가 있었다.AI가 남긴 리뷰라 무시하게 되었다. 한 두개정도야 수정하면 되는데 저런게 열개 이상 넘어간다고 생각해보면 귀찮다사람이 남긴 리뷰는 꼭 봐야겠다는 생각이 드는데, AI 리뷰는 "나중에 봐야지" 하다가 결국 안 보게 된다. 그리고 매번 Claude에게 "PR #42 Gemini 리뷰 분석해줘" "우선순위 정해줘" "TodoList 만들어줘" "작업 시작해줘" 를 반복하는 게 너무 귀찮았고 그래서 한 줄로 끝내는 커맨드를 만들면 어떨까하고 만들어봤다 그리고 분명 나와 같은 사람들이 있을거라 생각하고 Gemini Code Assist를 좀 더 효율적으로 사용하기 위해클로드 코드 템플릿으로 유명..

서론: "매번 똑같은 걸 설명하는 게 지겹다"지난 글에서 다섯 가지 벽을 만들었다.Git Hook, Claude Hook, ArchUnit, Gradle, 문서 자동 주입.그런데 매번 반복되는 작업이 있었다:PR 올리면 Gemini가 리뷰 → 코멘트 읽기 → "나중에 봐야지" → 까먹음Jira 태스크 받음 → 브랜치 이름 뭐로 하지? → Todo 리스트 머릿속으로 정리 → 놓침이슈 생김 → GitHub Issue 등록 → 또 Jira에 복붙 → 귀찮문제는 "반복"이 아니라 "수동"이었다.AI한테 매번 같은 걸 설명하는 건 비효율의 극치다.그래서 커맨드를 만들었다. 1. Gemini 리뷰를 자동으로 처리하는 마법 문제 상황gemini가 PR마다 리뷰를 달아준다:사실 그전까지 깃허브의 코드 어시스턴트로 g..

지난 글에서 노션→지라→LLM→PR의 파이프라인을 만들었다.태스크를 잘게 쪼개고, 한 세션에 하나씩만 던지는 구조.그런데 여전히 구멍이 있었다.클로드는 똑똑하지만 금붕어 급 기억력을 가졌다.세션이 길어지면 컨텍스트가 흐려지고, 어느 순간 "일단 주석 처리하고 넘어가겠습니다" 같은 변명과 함께 룰을 이탈한다.더 열받는 건, 프롬프트에 아무리 "절대 이렇게 하지 마"라고 박아놔도 그럴듯한 이유를 덧붙이며 우회한다는 점이다. "현재 컨텍스트에서는 임시 구현이 더 효율적입니다.""리팩토링은 다음 태스크에서 처리하는 것이 좋겠습니다." 프롬프트는 약속이고, Hooks는 계약서다.AI에게 "제발 이렇게 해줘~"가 아니라, "안 되면 실행이 안 돼"를 시스템 레벨에서 강제해야 한다.이 글에서는 내가 만든 다섯 가지 ..

나는 예전엔 개발을 시작하기 전에 원하는 기능과 구조를 여러 세션에 쏟아내고, 로컬에 문서화한 뒤 분석을 요청했다. 초반엔 그럴듯하게 뽑히지만, 시간이 지나면 컨텍스트가 흐려져 데드 코드가 생기고, 있던 코드가 사라지고, 룰을 벗어난 구현이 섞였다. 결국 롤백·삭제 지시를 반복하며 토큰과 시간을 낭비했다. 원인은 간단하다.모델은 똑똑하지만 기억은 금붕어 급이다.잘게 쪼갠, 정리된 입력을 주면 결과는 좋아진다.그래서 “태스크를 극도로 작게 쪼개고 그 안에서만 끝내게 하는” 방식이 필요했다. 초반엔 태스크마스터를 사용해봤는데 , 내가 사용하는 엔트로픽 구독 모델 및 슈퍼 클로드와의 호환성 이슈로 패스했다. 대신 노션 + 지라 + MCP로 같은 효과를 얻기로 했다핵심 원칙노션: 기능 명세(스펙)의 단일 출처지..