AI를 단순히 똑똑한 도구로 쓰는 단계를 넘어, 이제는 AI가 성과를 낼 수 있는 환경 을 설계하는 ‘하네스 엔지니어링(Harness Engineering)‘이 주목받고 있습니다. 단순히 프롬프트를 잘 던지는 것이 아니라, AI가 일하는 방식과 규칙, 검증 절차를 시스템화하는 것이 핵심입니다. 이 글은 아래 영상을 기반으로, 하네스 엔지니어링의 개념부터 사주 분석 앱을 만드는 실전 사례, 그리고 피터 드러커의 MBO(Management by Objectives)를 결합한 관리 관점의 AI 운영 전략을 정리한 가이드입니다. 영상: 하네스 엔지니어링 따라하기 (Harness Engineering Practice feat. Management) 채널: Ask Dori! Dori와 따라하는 IT 더보기

LLM의 컨텍스트 윈도우는 계속 커지고 있습니다. 그런데 실무에서는 이상한 장면이 자주 나옵니다. 자료를 더 많이 넣었는데 답이 더 좋아지기는커녕, 엉뚱한 파일을 집거나 이미 결정한 사항을 다시 뒤집는 경우입니다. 이 현상을 최근 실무권에서는 컨텍스트 로트(context rot) 라는 말로 자주 부릅니다. 중요한 점은 이 표현이 엄밀한 학술 용어라기보다, 긴 문맥이 쌓일수록 모델의 주의력과 일관성이 서서히 망가지는 현상을 묶어 부르는 실무 용어라는 점입니다. 더보기

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

justopen.ai의 짧은 Threads 포스트는 Claude Code를 잘 쓰는 순서를 아주 날카롭게 뒤집습니다. 많은 사람이 먼저 “무슨 기능이 있지?“를 묻지만, 이 포스트의 요지는 그 질문 자체가 이미 늦었다는 데 있습니다. 먼저 해야 하는 일은 기능 탐색이 아니라 누가 어떤 판단을 맡고, 그 판단이 어떤 문서로 남아야 하는지 를 정하는 것입니다. 더보기

최근 Reddit의 r/ClaudeAI에 올라온 GSD(Get Shit Done) 업데이트 글은 단순한 “기능 추가 안내"에 가깝지 않습니다. 오히려 AI 코딩 워크플로우가 어디에서 무너지기 쉬운지, 그리고 GSD가 그 지점을 어떤 구조로 다루려는지를 짧은 글 안에 압축해서 보여줍니다. 핵심은 같습니다. 사용자가 보는 인터페이스는 더 단순하게 유지하면서, 내부에서는 연구-계획-실행-검증-디버깅을 더 강하게 분리한다 는 점입니다. 더보기

Claude Code를 오래 쓰다 보면 가장 먼저 부딪히는 한계는 모델 성능보다 세션 단절 입니다. 방금 전까지 무엇을 조사했고 어떤 결정을 내렸는지 다음 세션에서 다시 설명해야 하는 순간이 반복되기 때문입니다. thedotmack/claude-mem은 바로 그 문제를 겨냥한 플러그인입니다. 저장소의 표현을 그대로 옮기면, 이 프로젝트는 Claude Code용 “persistent memory compression system” 이고, 세션 동안 발생한 관찰을 자동 수집하고 요약한 뒤 다음 세션에 다시 주입하는 구조를 제공합니다. (README.md) 더보기