Claude Code

AI 코딩 에이전트로 대규모 프로젝트를 진행하다 보면 누구나 겪는 문제가 있습니다. 처음 몇 턴은 모델이 완벽하게 동작하지만, 컨텍스트가 쌓이면서 답변이 짧아지고, 이전 결정을 잊어버리고, 엉뚱한 코드를 변경하기 시작합니다. GSD (Get Shit Done)는 바로 이 컨텍스트 붕괴 (Context Rot) 문제를 정면으로 해결하려는 오픈소스 워크플로우 시스템입니다. 이미 GitHub에서 수만 개의 스타를 받으며 빠르게 확산되고 있습니다. 더보기

400~500명 규모의 기수제 AI 스터디 커뮤니티를 단 2명이 운영한다면? 지피터스(GPTers)의 송다혜님은 Claude Code(오픈클로)로 만든 뽀짝이 에이전트를 통해 그 불가능에 가까운 운영을 실제로 해내고 있습니다. 이 글은 빌더 조쉬 채널의 인터뷰를 바탕으로, 뽀짝이가 어떻게 만들어졌고 어떻게 동작하며, 그 경험에서 AI 네이티브 조직을 만들려는 분들이 무엇을 배울 수 있는지를 정리합니다. 더보기

Claude Code에 Remote Control 기능이 추가되었습니다. 터미널에서 코딩 작업을 시작한 뒤, 노트북을 두고 자리를 떠나도 휴대폰에서 세션을 그대로 제어할 수 있는 기능입니다. 더보기

겉으로만 보면 bkit 과 GSD(Get Shit Done) 는 비슷해 보입니다. 둘 다 AI 코딩을 더 체계적으로 만들겠다고 말하고, 계획과 실행 사이를 문서와 에이전트로 연결하며, 컨텍스트 엔지니어링이라는 표현도 사용합니다. 하지만 공식 문서를 조금만 깊게 읽어 보면, 두 도구가 실제로 통제하려는 대상은 꽤 다릅니다. bkit 은 Claude Code 안에서 엔지니어링 절차와 검증 규율 을 강하게 밀어 넣는 쪽이고, GSD 는 여러 런타임에서 context rot를 줄이면서 실전 구현을 계속 굴리는 운영 흐름 에 더 가깝습니다. 그래서 중요한 질문은 “어느 쪽이 더 강한가"가 아닙니다. 더 정확한 질문은 AI 코딩에서 내가 지금 가장 줄이고 싶은 실패가 무엇인가 입니다. 요구사항 없이 바로 구현으로 점프하는 문제가 더 큰지, 긴 세션에서 품질이 무너지는 문제가 더 큰지, 혹은 Claude Code 하나에 깊게 최적화할지 여러 런타임을 오갈지가 더 중요한지에 따라 답은 달라집니다. 더보기

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를 내세우고 있습니다. 숫자만 많아 보이는 도구처럼 보일 수도 있지만, 핵심은 숫자보다 구조입니다. 이 글에서는 그 구조가 실제로 무엇을 바꾸는지 중심으로 보겠습니다. 더보기

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 더보기