Workflow

Claude Code로 랜딩 페이지를 만들면 종종 결과물이 비슷해집니다. 영상의 핵심 주장은 단순합니다. 문제는 “Claude Code가 원래 디자인을 못해서” 만이 아니라, 사용자가 자신의 취향과 의도를 충분히 전달하지 못하기 때문에 결과가 generic해진다는 것입니다. 발표자는 이를 해결하기 위한 학습 경로를 7단계로 나눠 설명하며, 각 단계에서 무엇을 기대할 수 있고 어디서 막히는지, 그리고 다음 단계로 어떻게 넘어가야 하는지를 순서대로 보여줍니다. 오프닝 요약, 문제 정의 이 글은 그 7단계를 그대로 번역하지 않고, 실제로 Claude Code를 쓰는 개발자 관점에서 다시 구조화한 정리입니다. 핵심은 세 가지입니다. 첫째, 텍스트 프롬프트만으로는 한계가 빠르게 온다는 점, 둘째, 좋은 결과는 스킬과 레퍼런스, 코드 해체, 반복 편집의 누적으로 나온다는 점, 셋째, “AI가 알아서 예쁘게 만들어주길 기대하는 상태” 에서 “내가 비주얼 디렉터로서 AI를 조종하는 상태” 로 역할을 바꿔야 한다는 점입니다. 로드맵 제시, 마무리 메시지 더보기

Claude Code를 쓴다는 것은 AI 도구를 쓰는 것이 아닙니다. Neil Kakkar는 Tano에 합류한 후 6주 만에 커밋 수를 극적으로 늘렸는데, 그 비결은 모델을 잘 쓰는 것이 아니었습니다. 에이전트가 일하기 좋은 인프라를 구축한 것이었습니다. 구현자에서 에이전트 팀 매니저로 역할을 바꾸고, 마찰을 하나씩 제거하는 4단계 여정을 정리합니다. 더보기

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

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

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