문서 인덱스

완전한 문서 인덱스를 다운로드하세요: https://acai.sh/llms.txt

이 파일을 사용하여 추가 탐색 전에 모든 가능한 페이지를 발견하세요.

이게 익숙한가요?

와. Claude. 놀라움. 전체 기능이 훌륭합니다. 하지만 제가 언급하지 않은 매우 중요한 에지 케이스 하나를 잊어버렸습니다.

아, 그리고 저는 이제 깨달았습니다. 당신은 사용하셨습니다. 맞습니다! 수정하겠습니다.

오프셋 페이징
표 UI에 적합합니다. 당연한 일입니다.

커서 페이징
여기에 더 잘합니까?

또는 그것이 N+1 쿼리인가요? 테이블의 모든 행을 가져오나요? 한 번의 라운드트립을 왜 하지 않습니까?

맞습니다! 수정하겠습니다.

이것이 제가 여전히 일을 하는 이유, 맞습니다!

...

피크 슬롭

나는 이 장면을 여러 번 지켜보았습니다. 그러나 빈도는 감소하고 있습니다. 내 도구와 그들을 사용하는 방법 모두 계속 개선되고 있습니다. 나는 피크 슬롭이 이미 지나갔다고 생각합니다.**하늘의 한계는 아닙니다. 컨텍스트 윈도우가 한계입니다.**그리고 내가 컨텍스트 윈도우를 채우거나 세션을 종료하거나, 머신을 변경하거나, 프로젝트를 다른 사람에게 넘기면 어떻게 될까요? 우리는 이미 알고 있습니다. 에이전트는 궤도에서 벗어나거나 요구사항이 상실되고, 결정적으로 중요한 세부 사항이 압축됩니다. 따라서 우리는 적응하고 완화합니다. 우리는 문서화합니다. 우리는 요구사항을 나열합니다. 맞습니다, 수백만 명이 동일한 깨달음에 도달하고 있습니다: 우리는 더 많은 요구사항을 문서로 작성해야 합니다. 요구사항이 변경될 때 업데이트해야 합니다. 보십시오! 나는 스펙을 작성했습니다! 나는

아마도 그렇지만 그것은 새로운 것이 아닙니다. 우리 멘토들은 수십 년 전에 이러한 습관을 가르치려 했습니다.

스펙 기반 개발?## 비행 중 스펙 지정

당신의 가장 좋아하는 스펙의 맛은 무엇인가요? README.md

와 AGENTS.md

는 좋은 시작입니다. testing-guide.md

를 잊지 마십시오. architecture.md
, PRD.md
, 그리고 설계 문서도 고려해 보셨나요? md.md
(에이전트에게 .md
작성을 가르치기 위해)를 고려하셨나요? 더 많은 .md
일수록 좋죠?

무비로직하게, 네. 문서와 비정형 스펙은 매우, 매우 멀리까지带我去합니다. 프롬프트 하나보다 훨씬 멀리갑니다. 아직 어떤문서를 작성하지 않는다면, 이 글을 읽지 말고 바로 시작하세요. 그리고 기억하세요, 슬롭을 넣으면 슬롭이 나옵니다. 어떤 것보다 좋은 것은 유기적이고 목축농장 기르는,

손으로 쓴스펙입니다. 스펙 작성이 소프트웨어 공학의 실제적인 행위가 일어나는 곳입니다. 그래서 몇 주 전에 나는 어떻게 멀리까지 가져갈 수 있는지, 그리고 얼마나 멀리 가져가야 하는지 스스로에게 질문하기 시작했습니다.

마크다운에서 꿈꾸기

이야기는 내가 AI 심증에 빠졌고, "스펙 맥스"가 되었고, 당신은 보아온 가장 아름다운 PRD 와 TRD 를 몇 시간 동안 작성하는 데 시간을 썼다고 합니다. 나는 템플릿과 기술 및 역할을 초안화하고, 내 에이전트도 스펙을 작성할 수 있나 생각했습니다! 나는 군대를 조립하여 미니어둠 공장
처럼 함께 일하며 내 스펙을 현실로 바꾸었습니다. 내 작업은 더 야심차게 성장했고, 한 번에 나는 진공 코딩의 음향 장벽을 깨뜨렸습니다:

*1.5 시간 동안 감독 없이 실행된 에이전트!*흥미진진합니다. 그러나 그 군대가 나에게 무엇을 가져왔나요? 슬롭이 아니었습니다. 사실 그것은
작동했습니다, 이는 매일 내가 다른 회사에 강요받게 하는 쓰레기보다 더 좋습니다. 하지만 여전히 약간 느슨했습니다. 나는 완벽주의자가 아니며 대부분의 사람들보다 코너를 잘라내는 것을 좋아하지만, 이것이 어떤 방식으로든 충분하지 않았습니다. AI 심증의 한 가지 특징적인 증상은
제품을 구축하기 위한 AI 를 구축하는 데 AI 를 사용하는 것
이 아니라 단순히 제품을 구축하기 위해 AI 를 사용하는 것입니다. 나는 내 질병을 수용하고, 분지를 버리고, 모든 마크다운을 폐기하고 다시 시작했습니다.

AI 수용 기준 (ACAI)

몇 일 후, 예상치 못한 일을 하는 야심 찬 작은 에이전트를 발견했습니다.**작은 놈은 내 요구사항을 번호를 붙이고, 그 다음 코베이스에서 참조하기 시작했습니다.**왜? 제가 요청하지 않았어요! 저는 혐오스러웠습니다. 코드와 사양의 긴밀한 결합, 그리고 사양과 코드의 긴밀한 결합이 좋지 않죠?

*내가 사양을 변경할 때마다 내 모든 코드를 리팩토링할 거라고 정말 기대하나요?*아. 아마도 그건 좋은 일일까요? 흥미롭네요. 궁금합니다…

• 이 태그들이 거대한 PR들을 탐색하는 데 도움이 될 수 있을까요?
• 이 태그들은 정확히 어디에서 요구사항이 충족되거나 테스트되는지를 지시할 수 있을까요?
• 아마도 제가 그들에게 참고 사항과 상태 (todo, assigned, completed) 를 주석으로 추가할 수 있겠네요!
• 아마도 제가 테스트 커버리지 대신 수용 커버재직을 추적하기 시작할 수 있겠네요!

**ACIDs (Acceptance Criteria IDs).**하지만 몇 가지 질문이 남았습니다.

*내 ACIDs 가 스스로 번호를 붙이고 라벨링할 수 있을까요?*그들을 정렬하는 것이 번거롭지 않나요?*나는 사양과 진행 상황을 샌드박스, 브랜치, 기능 및 구현을 통해 어떻게 공유할 수 있나요?

Acai.sh - 오픈소스 툴킷

Acai.sh 를 새로 발명된 문제들 중 일부 해결하기 위해 만들었습니다. 그리고 결과는 매우 기대됩니다.- 기능 사양용 단순하고 유연한 템플릿, feature.yaml 이라고 합니다.

Feature.yaml 는 ACID 로 각 요구사항을 참조할 수 있게 합니다.

• CI 와 에이전트를 위한 작은 CLI (npm 또는 github release 를 통해 이용 가능).
• 대시보드와 JSON REST API 를 제공하는 웹앱 (Elixir, Phoenix, Postgres).

일정 기간 동안 무료이거나, 아마도 영원히 무료일 것이요. 이 것이 얼마나 인기가 많거나 비싸게 될지에 따라 결정됩니다. 소스 코드는 Apache 2.0 라이선스 하에 GitHub 에 있습니다.

작동 방법

단계 1 - 지정

기능 사양을 작성하기 시작하세요. 야심 찬 – 실제 가치를 추가하는 것입니다. 사양에 노란 UI 나 네일 폴리시 같은 세부 사항을 넣지 마세요. 요구사항은 구체적이고, 테스트 가능하며, 정말 중요한 것에 집중해야 합니다 (기능적 행동 + 핵심 제약 조건). 마크다운 대신 acai 의 feature.yaml 형식을 사용하세요.

Acai 의 사양은 numbered list of requirements 입니다.

단계 2 - 발송

아래 프롬프트를 복사하고 붙여넣으세요.

단계 3 - 검토

파일별로 GitHub PR 검토는 더 이상 없습니다. Acai.sh 대시보드를 사용하여 요구사항을 검토하세요. 이상적으로는, 당신은 GitHub action 에 acai push 를 추가할 수 있습니다 (예제 CI/CD 워크플로우 곧 출시 예정).

• https://app.acai.sh 에서 무료 팀과 액세스 토큰 생성
• 환경 변수 노출
• 대시보드로 사양 및 코드 참조를 푸시하여 검토

단계 4 - 반복 / 반복

목표는 사양을 먼저 작업하는 것입니다. 사양 자체를 변경하거나, 대시보드를 사용하여 사양에 주석을 추가하세요. 올바른 하네스를 사용하면 에이전트를 반응하고 자동 할당할 수 있습니다 (acai CLI 명령어 사용).

결과물은 프롬프트 및 재프롬프트 시간을 줄이고, 검토 시간을 줄이며, 느슨한 코드 생성을 줄이고, 당신이 원하는 제품에 대해 생각하는 데 더 많은 시간을 할애합니다.

plan → implement → review 루프. 그 부분은 아직 포함되지 않았습니다. 곧 강력한 예제를 공유할 계획입니다.

미래 전망

LLM 환각 (psychosis) 에서 도출되더라도 여전히 이 접근법이 유용하고 생산적이라고 생각합니다. 엄밀함 (rigour) 과 분위기 (vibes), 구조와 유연성 사이의 최적점을 찾았다고 믿습니다. 수용 기준 (acceptance criteria) 을 항목별로 나열하는 것은 제게 후퇴하여 중요한 것에 집중하고, 출력물을 테스트 및 검증하는 방식을 재고하도록 독려합니다. 다시 말하지만, 이 아이디어들은 모두 새롭지 않습니다. 하지만 중력의 인력을 느끼며, 이것이 어디로 이어지는지, 다음 단계가 무엇인지 궁금해집니다.

사고 실험 (Thought Experiment)

어떠한 복잡성을 가든 애플리케이션 전체가 즉시 생성되었다고 상상해보세요프롬프트 창에서 키보드를 누르기 시작하는 순간. 마법적으로, 동일한 프롬프트 입력이 항상 동일한 결정론적 (deterministic) 출력으로 이어지며, 비용은 없으며, 밀리초 단위로 준비된다면. 어딘가, 기록하지 않더라도. 스펙 (spec) 은 소프트웨어를 만들고 싶은 것입니다. 그것은 종종 당신의 머릿속이나 대화에만 존재합니다. 당신과 팀, 비즈니스는 스펙이 무엇을 말하고 있는지 항상 중요하게 여기며, 이는 결코 변하지 않습니다. 따라서 지금 적어두는 것이 더 좋습니다! 그리고 저는 평범한 수용 기준 목록이 좋은 시작점이라고 생각합니다. (그것은 정말로 feature.yaml 이라기 때문입니다.)

여기에 따른 몇 가지 추가 사항이 있습니다;

-> 스펙 최대화 (Specmaxxing) 에서 테스트 최대화 (Testmaxxing)

코드가 읽을 수 있는 것보다 더 빠르게 생성될 때, 병목 현상은 QA 와 검증으로 이동하며, 코드가 스펙에 부합하는지에 대한 당신의 신뢰가 결정됩니다. 따라서 QA 자동화와 테스트 커버리지에 투자하면 막대한 투자 대비 수익 (ROI) 을 얻습니다. 그리고 최대 테스트 커버리지와 관찰 가능성 (observability) 이 달성된 후, 우리는 GitHub 의 차이점 (diffs) 에서 눈을 돌립니다. 우리는 스펙을 중요한 자산 (구현, QA 피드백, 사용자 피드백, 빌드, 실행, 리뷰 및 보고서) 과 연결할 수 있는 곳을 필요로 합니다. 아마 Acai.sh 가 그 곳이 될 것입니다. 현재는 스펙과 코드 내 구현에만 집중하고 있습니다.

-> 테스트 최대화 (Testmaxxing) 에서 반응형 소프트웨어 공장 (reactive software factories)

최종 잠금 해제 (unlock) 는 LLM 이 빨간색 테스트나 경고에 반응할 수 있을 때입니다. 스펙이 잘 정의되고, 통합 파이프라인과 QA 에 대한 당신의 신뢰도가 높다면, LLM 은 당신 개입 없이 완전히 권한을 부여받아 반응할 수 있습니다. 지구의 모든 자금 지원 소프트웨어 팀은 현재 자신의 맞춤형 솔루션을 구축하는 데 바쁘며, 무엇이 작동하고 무엇이 작동하지 않는지 보고 매우 기대합니다. 첫 단계로, 저는 http://acai.sh 에 OpenCode Agent 템플릿을 두어 지금까지 잘 작동했습니다.

다른 스펙 기반 개발 도구의 비교

참고할 정도로 제가 이 도구들을 알지 못했었습니다. 제 자신의 것을 거의 완성했을 때야야 알았습니다. 핵심 차별점은 Acai.sh 가 추적 (track) 을 도와주는 데 집중한다는 것입니다. 이는 다른 도구들이 해결하려는 문제와 약간 다릅니다.

수용 커버리지와 스펙 정렬을 여러 구현에 걸쳐 저는 편향되지 않은 피드백을 제공할 수 없습니다. 왜냐하면 제가 '이곳에서 발명하지 않음' 증후군 (Not Invented Here syndrome) 을 겪고 있기 때문입니다. Acai.sh 접근법이 오히려 이러한 도구를 향상시킬 수도 있습니다.

GitHub SpecKit

SpecKit 는 제 눈에는 '추가 단계가 있는 분위기 코딩 (vibe coding)'과 같습니다. 즉, 에이전트에 더 많은 프롬프트와 더 많은 기술을 추가하는 CLI 입니다. 이는 분명히 생산적이지만, 약간 다른 문제들을 해결합니다.OpenSpec

그들의 문서를 읽을 때 가장 먼저 느낀 점은 명시된 '마인드 모델'으로, 이는 다음과 같이 쓰여 있습니다: “Specs […] describe how your system currently behaves.”. 저는 이에 근본적으로 반대합니다. Acai.sh 에서 specs 는 시스템이 SHOULD (해야 할 것) 행동하는 방식을 기술합니다. 현재 동작은 일시적입니다. 또한 그들의 프로세스는