신규하 블로그

Claude Code를 쓰다 보면 금방 느끼는 문제가 있습니다. 코드는 빨리 나오는데, 계획과 설계와 검증이 한 흐름으로 묶이지 않으면 결과가 들쭉날쭉해진다는 점입니다. bkit 은 바로 그 지점을 겨냥한 플러그인입니다. 저장소의 현재 설명대로 보면, 이 도구는 Claude Code 위에 PDCA 방법론, CTO-Led Agent Teams, 자동 문서화, Context Engineering 을 얹어 AI 코딩을 조금 더 “운영 가능한 개발 프로세스"에 가깝게 바꾸려는 시도입니다. 현재 공개 저장소 기준으로 bkit 은 v2.0.6, Apache-2.0 라이선스, 37 Skills, 32 Agents, 18 Hook Events, 57 scripts, 88 lib modules, ~620+ functions를 내세우고 있습니다. 숫자만 많아 보이는 도구처럼 보일 수도 있지만, 핵심은 숫자보다 구조입니다. 이 글에서는 그 구조가 실제로 무엇을 바꾸는지 중심으로 보겠습니다. 더보기

Marmelab의 “Agent Experience” 글이 흥미로운 이유는, 코딩 에이전트의 성능 차이를 모델 자체보다 코드베이스가 얼마나 에이전트 친화적으로 설계되어 있는가 로 설명하기 때문입니다. 글은 “좋은 프롬프트를 어떻게 쓸까” 보다 한 단계 더 들어가서, 에이전트가 검색하고, 이해하고, 실행하고, 검증하는 전 과정을 코드베이스 차원에서 어떻게 돕느냐를 묻습니다. 즉 이 글은 에이전트를 잘 쓰는 법을 말하는 사용법 가이드라기보다, 에이전트가 잘 일할 수 있는 저장소를 만드는 운영 원칙 모음 에 가깝습니다. 다만 이때의 Agent Experience는 아직 널리 합의된 표준 용어라기보다, Developer Experience의 문제의식을 에이전트 실행 환경으로 확장한 실무적 framing으로 보는 편이 더 정확합니다. 특히 대형 프로젝트에서 사람이 반복해서 채팅으로 설명하던 규칙과 문맥을 파일, 테스트, 도구, 훅, 문서로 옮겨 두면 에이전트의 자율성과 정확도가 함께 올라간다는 점을 아주 실무적으로 보여 줍니다. 더보기

Claude Code 생태계를 조금만 깊게 따라가 보면 금방 헷갈립니다. Superpowers, GSD, Spec Kit, OpenSpec, gstack, BMAD, Everything Claude Code, HumanLayer/RPI 가 전부 비슷해 보이는데, 막상 안을 들여다보면 같은 문제를 푸는 방식이 전혀 다릅니다. 2026년 3월 24일 기준으로 shanraisshan/claude-code-best-practice 의 Development Workflows 표가 흥미로운 이유도 여기에 있습니다. 이 표는 여러 시스템을 단순 인기 순위가 아니라, 모두 Research → Plan → Execute → Review → Ship 라는 공통 골격 위에 서 있지만 각자 다른 철학을 얹은 워크플로우 로 읽게 만듭니다. Development Workflows 그래서 이 글에서는 스타 수나 명령 개수보다 작동 방식과 잘 맞는 상황 에 집중합니다. 같은 “AI 코딩 워크플로우” 라고 묶여 있어도, 어떤 것은 테스트 규율을 강하게 밀고, 어떤 것은 명세 문서 체인을 중시하고, 어떤 것은 가상 엔지니어링 팀처럼 병렬 스프린트를 운영하고, 어떤 것은 아예 AI 개발 환경 전체를 하니스 시스템으로 보려 합니다. 결국 중요한 질문은 “무엇이 더 유명한가?” 가 아니라 “내 팀이 지금 어느 실패 패턴을 줄이고 싶은가?” 입니다. 더보기

gstack를 그냥 “Claude Code용 스킬 모음"으로 보면 이 프로젝트의 핵심을 놓치기 쉽습니다. 이 영상이 보여 주는 진짜 포인트는, 하나의 에이전트에게 모든 일을 몰아주는 대신 CEO, 엔지니어링 매니저, QA, 릴리즈 엔지니어처럼 역할을 분리하고 그 순서를 워크플로로 고정했다는 점입니다. 발표자는 이를 Garry Tan의 노하우를 Markdown 스킬로 빌려 오는 경험이라고 설명하고, 실제로 기획부터 브라우저 QA, 회고까지를 하나의 개발 루프로 연결해 보여 줍니다 (t=135, t=154, t=330). 날짜를 분리해서 읽는 것도 중요합니다. 영상은 2026-03-19에 업로드됐고, 설명란에는 업로드 시점 기준으로 15개 스킬과 2.5만 스타가 언급됩니다. 반면 제가 2026-03-24에 GitHub API로 확인했을 때 garrytan/gstack 저장소는 스타 43,925개, 포크 5,500개였고, 현재 README는 specialist skills와 power tools를 합쳐 28개의 slash command를 안내합니다. 즉 이 글은 영상이 전하는 설계 철학과 2026-03-24 기준 공식 저장소 상태를 구분해서 읽는 정리입니다. YouTube 영상 gstack 저장소 gstack README 더보기

프롬프트 엔지니어링은 AI에게 잘 부탁하는 기술이다. 하네스 엔지니어링은 AI가 잘못된 방향으로 갈 수 없도록 구조 자체를 설계하는 기술이다. DIO의 Forward Deployed Engineer(FDE) 김지운 님은 Claude를 쓰든, OpenAI Codex를 쓰든, Gemini를 쓰든 동일한 코드 구조와 문서가 나오는 시스템을 구축하는 데 수백 시간을 투자했다. 배달 플랫폼 4개 소프트웨어를 3개 모델에 시키면 12개의 결과물이 나오는데, 그 12개가 실질적으로 동일하다는 것을 직접 시연했다. 이것이 하네스 엔지니어링의 목표다. 더보기

이 영상이 흥미로운 이유는 “Claude Code 스킬을 어떻게 만들까"를 추상적으로 말하지 않기 때문입니다. 발표자는 Anthropic 팀이 내부에서 수백 개 스킬을 운영하면서 무엇이 실제로 먹히는지 압축해서 보여 줍니다. 그래서 초점은 예쁜 SKILL.md 문서를 쓰는 법이 아니라, 스킬이 왜 자꾸 흐트러지고 어떤 구조로 바꿔야 안정적으로 작동하는지 에 있습니다 (t=0). 영상 전체를 한 문장으로 줄이면 이렇습니다. 스킬은 정적인 프롬프트 파일이 아니라, 실패 기록과 보조 자료와 실행 제약을 함께 묶은 작업 패키지 여야 한다는 것입니다. 이 관점으로 보면 폴더 구조, description, gotchas, hooks, 팀 배포 방식이 모두 하나의 운영 문제로 연결됩니다 (t=22, t=262, t=313). 더보기

pbakaus/impeccable 가 흥미로운 이유는 “예쁜 프런트엔드 프롬프트 모음” 수준에서 끝나지 않기 때문입니다. 이 프로젝트는 디자인 품질 문제를 단순한 취향이나 모델 성능의 문제가 아니라, AI에게 줄 수 있는 디자인 어휘와 평가 기준이 부족한 문제 로 다시 정의합니다. 공식 사이트가 강조하듯, 사용자가 vertical rhythm 같은 말을 모르면 모델에게 그 수준의 수정을 요청하기도 어렵습니다. 그래서 Impeccable의 핵심은 “더 멋진 화면을 만들어 줘"가 아니라, 디자인 언어를 스킬과 명령으로 쪼개서 여러 AI 하네스에 이식 가능한 형태로 배포한다 는 데 있습니다. 2026년 3월 23일 기준으로 공식 사이트는 이 프로젝트를 1개의 종합 스킬과 20개의 디자인 명령으로 소개하고 있고, 실제 저장소 소스 디렉터리도 총 21개 스킬 중 20개를 user-invocable 명령으로 구성하고 있습니다. 더보기