OpenSpec, AI 코딩 에이전트용 경량 스펙 프레임워크 공개 (GitHub 스타 6만 8천)

이거 쓰고 있는데, 커스텀 하네스로 플래너 에이전트가 OpenSpec으로 계획 만들고 그걸 티켓 그래프로 바꾸게 했음. 꽤 잘 돌아가고 SpecKit보다 확실히 가볍더라.

딱 내가 필요하던 것 같음. Superpowers, GSD, oh-my-claude/openagent 다 써봤는데 대부분 토큰만 더 태웠음. 요즘은 순정 OMP가 균형이 제일 맞는데 브레인스토밍이랑 스펙 유지가 좀 부족해서 직접 얹어봤지만 결과는 애매했음.

설정 문서에서 Concepts 링크 눌렀더니 실제 파일이 아니라 GitHub의 템플릿으로 연결됨. 이러면 좀 신뢰가 안 가는데.

사이트를 다시 만들거나 문서를 옮기는 중인 것 같음. 얼마 전까진 다 잘 됐고 그때는 디자인도 완전히 달랐음.

유지보수자인데 위 답이 맞음. 문서를 처음부터 다시 쓰면서 다른 문서 자리를 placeholder로 넣었는데 링크가 몇 개 남은 것 같음. 고치겠음.

그냥 스킬이랑 md 파일 묶음인데 왜 CLI까지 필요한 거임?

CLI가 쓸모 있음. 스킬이 스펙과 결정적으로 상호작용할 수 있게 해줌. 예를 들어 파일을 토큰 들여 읽지 않고도 스펙 형상을 검증할 수 있음.

스펙 기반 워크플로를 아주 단순하게 쓰는데 놀랍게 잘 됨. 지난주에 471줄 스펙으로 큰 기능을 맡겼는데 전혀 흔들리지 않았음.

미안하지만 2026년에 471줄은 아무것도 아님. 5000줄에서 1만 줄짜리 스펙을 무결점으로 처리하고 다시 와라. 모델이 좋아지면서 기준선은 계속 올라감. 단순한 스펙 워크플로가 멀리 간다는 말은 맞음.

난 올해 초에 lat.md로 정착하고 안 돌아봄. 평범한 마크다운에 위키 링크로 개념을 잇고, // @lat: 주석으로 소스를 스펙에 묶음. lat check로 드리프트를 막고 lat search로 섹션 전체를 의미 검색함. 구조와 유연성 사이에서 균형이 맞음.

Openspec 좋음. 내부 평가에서도 점수가 잘 나왔고 의식(ceremony)이 제일 합리적임. 각 phase가 하나의 openspec 스펙이 되는 TUI도 만들고 있음. 큰 작업일수록 LLM 성능이 올라가는 걸 체감함.

요즘도 이런 게 필요한가? 최신 LLM은 긴 컨텍스트 작업을 충분히 학습해서 계획은 꽤 잘 세움. Codex나 Claude Code 쓰면 굳이 안 써도 될 듯.

계획은 세우지만 원하는 걸 만든다는 보장은 없음. 일의 상당 부분은 무엇을 만들지 합의하는 과정이고, 기술 계획은 아직 맡기지 않음. '무엇'은 사람이 정하고, 상위 기술 계획은 반반, 하위 세부는 질문이 있을 때만 개입하는 식으로 스펙 작업을 점진적으로 만듦.

스펙 작성은 계획이 아님.

AI 프로젝트 스펙 때문에 JIRA랑 싸우는 게 지겹다. 이게 정말 정리해준다면 당장 써볼 것임.

나도 비슷한 걸 이번 해에 만들었는데 OpenSpec이랑 철학이 겹침. 선언적 스펙과 설치 가능한 에이전트 스킬에 집중했고, 단일 바이너리라 의존성이 없게 Go로 썼음. 피드백 주면 좋겠음.

나도 비슷한 걸 만들고 있는데 역할 구성이 겹쳐서 재밌음. 몇 개 시스템을 비교해보면 좋겠다.