요즘 하네스 만드는 게 재밌더라고요

요즘 하네스 만드는 게 재밌더라고요. 거창한 프레임워크를 새로 짜는 건 아니고, 여러 유명한 하네스와 좋은 로직들을 짬뽕해서 제 개발 환경과 작업 방식에 맞게 다듬는 일이에요.

남이 만든 걸 그대로 쓰는 게 아니라, 제 손에 맞는 도구를 조금씩 쌓아 올리는 거라 나만의 자산을 만든다는 느낌이 듭니다. 그 감각이 좋아서 자꾸 만지게 돼요.

그대로 안 쓰고 직접 만드는 이유

기성 하네스를 그대로 가져오면, 꼭 제 작업 흐름과 어긋나는 지점이 생기더라고요. 1인 개발이라 역할을 자주 바꿔야 하고, 외주와 자체 프로젝트가 섞여 있고, 쓰는 스택도 정해져 있으니까요. 그래서 좋은 아이디어만 골라 와서 제 환경에 맞게 조립합니다. 그러면 확실히 손에 붙습니다.

위 화면처럼 "/sj-company 로그인 기능 만들어줘" 한 줄이면, 기획부터 검증까지 한 흐름으로 굴러갑니다. 이 흐름을 처음부터 제가 발명한 건 아니고, 여러 하네스에서 좋은 부분을 가져와 엮은 거예요.

무엇을 참고했나

• Karpathy 하네스 — 컨텍스트를 최소화하고 태스크를 작게 쪼개는 방식. 실력보다 루프 속도가 이긴다는 관점이 좋아서, 짧은 루프와 명확한 목표 설정을 가져왔습니다.
• gstack — 멀티에이전트 오케스트레이션의 실전 구현. 에이전트들이 채널로 소통하고 Tech Lead가 병렬 디스패치·수렴을 조율하는 구조를, 혼자서도 팀처럼 일하려고 채택했습니다.
• Hermes (Nous Research) — 컨텍스트를 지우지 않고 archive만 하는 불변식. 세션이 끊겨도 과거 결정과 학습을 잃지 않으려고 메모리/컨텍스트 누적 방식을 빌려왔습니다.
• Claude Code의 서브에이전트·스킬 구조 — 역할별 서브에이전트와 슬래시 스킬로 의도를 라우팅하는 방식. 매번 직접 지시하는 대신 적절한 전문가를 부르려고 참고했습니다.

지금 갖춰진 스킬들

이렇게 모은 아이디어를 제 작업에 맞는 스킬들로 정리해 두었습니다. 의도를 입력하면 그에 맞는 역할이 움직이는 식이에요.

• /sj-company — 태스크 크기를 판단해 적절한 흐름으로 오케스트레이션
• /sj-pm — 요구사항·리스크·우선순위 정리
• /sj-tech-lead — 전문 개발 서브에이전트를 병렬로 디스패치하고 리뷰까지 집계
• 전문 서브에이전트 — frontend · backend · database · devops · security · data · SI 문서
• /sj-qa — 구현자 산출물을 보지 않고 독립적으로 검증
• /sj-design — 시안 여러 개를 먼저 보여주고 방향을 고른 뒤 구현
• /sj-loop — 반복 작업을 정지 조건이 있는 루프로 설계
• /pw-loop — Playwright로 기능 단위 테스트를 반복

아직 완성이라고 할 단계는 아니고, 작업하다 불편한 게 보이면 그때그때 고치고 더합니다. 그렇게 쌓인 게 결국 제 작업 방식 그 자체가 되는 것 같아서, 당분간은 계속 만지게 될 것 같아요.