Topogram에서의 SDLC: 프로세스, 이점 및 트레이드오프

Topogram의 주요 역할은 topo/ 내에 있는 살아있는 앱 맵입니다. 여기에는 의도(intent), 계약(contracts), 소유권(ownership), 증명(proof)이 포함됩니다. SDLC는 사용자가 옵트인할 경우, 이러한 동일한 그래프 내에서 프로젝트 작업이 살아 숨 쉬게 하는 방식입니다. 이는 두 번째 제품이 아닙니다. 코드베이스를 잊어버리는 마크다운 티켓 폴더도 아닙니다.

저는 이를 엔진 레포지토리(주로 저와 agent 모델)에서 사용합니다. 이 게시물은 일반적인 형태, 즉 프로세스, 이점 및 트레이드오프에 대한 내용입니다.

옵트인하는 것들

• topo/sdlc/ 아래의 레코드 (피치(pitches), 요구사항(requirements), 수락 기준(acceptance criteria), 작업(tasks), 버그(bugs), 결정(decisions), 계획(plans))
• topogram.sdlc-policy.json에 명시된 정책 (adopted, mode, profile, 보호 경로)
• 상태(status), 기록(history), 및 검증 영수증을 소유하는 CLI 명령어
• topo/ 내의 다른 곳에 있는 **기능(capabilities), 규칙(rules), 검증(verifications)**으로 연결되는 링크들

SDLC는 선택 사항입니다. 정책 파일이 없어도 명령어는 계속 실행되며, --require-adopted 플래그를 사용하지 않는 한 게이트는 not_adopted로 보고합니다.

프로세스 (일반 루프)

1. 채택하기 (Adopt) (단 1회)

topogram init . --adopt-sdlc
# 또는 topogram.sdlc-policy.json과 topo/sdlc/**를 직접 추가합니다.

일반적인 정책:

• `mode:

일반적인 정책:

• mode:

topogram query sdlc-proof-gaps ./topo --task <task-id> --json
topogram sdlc verify record <verification-id> . --task <task-id> --actor <actor-id> \
  --command "<실행한 내용>" --status pass --write --json
...

5. 커밋 전 (강제 적용 시)

topogram sdlc prep commit . --base origin/main --head HEAD --json
topogram sdlc gate . --require-adopted --json

git에서 편집하는 내용	CLI가 관리하는 내용
.tg 기록 텍스트	상태 전환, .topogram-sdlc-history.json
제안(Pitches), 태스크, AC 문구	검증 실행 JSONL 영수증

게이트가 실패했다고 해서 사이드카를 수동으로 편집하지 마세요. 그렇게 감사 추적 기록이 사라집니다.

이점 (Benefits)

• 제품과 작업에 대한 단일 그래프; 에이전트는 전체 리포지토리를 다시 읽는 대신 슬라이스를 쿼리합니다.
• **태스크 시작 패킷(Task-start packets)**은 채팅 스레드나 모델이 변경될 때 범위를 재진술합니다.
• 주어/조건/결과 (Given/when/then) 인수 조건은 '완료'를 UI에서의 닫힘 상태가 아닌 관찰 가능한 증거에 연결합니다.
• 나중에 쿼리할 수 있는 검증 영수증(Verification receipts) (query verification-runs, 증거 격차)
• 패킷 내 규칙: 엔지니어링 법규가 AGENTS.md나 마지막 대화에만 존재하는 것이 아닙니다.
• 보호된 경로 + 게이트: '피곤한 날 프로세스를 건너뛰기'는 기본값이 아니라 명시적인 면제 사항이어야 합니다.
• 프로필(Profiles): 일상적인 작업에는 standard를, risk_class, change_type, 그리고 더 엄격한 면제 규칙이 필요할 때는 audit를 사용합니다.

트레이드오프 (Trade-offs)

• 소규모 변경 시의 오버헤드 (Overhead on small changes): 보호된 경로(protected paths)가 너무 넓을 경우 발생합니다. 추적성(traceability)이 실제로 필요한 범위로 경로를 좁히십시오.
• 기록 유지의 주체: 기록은 git에 유지됩니다. CLI가 당신을 위해 훌륭한 피치(pitch)를 대신 작성해주지는 않습니다.
• 강제 모드(Enforced mode)의 답답함: 습관(작업 시작, 검증 기록, 게이트 실행)이 형성될 때까지는 답답할 수 있습니다. 강제 실패(hard fails) 없이 신호(signal)만 받고 싶다면 advisory 모드가 존재합니다.
• Jira나 GitHub Issues가 아님: 내장된 알림, 담당자 UX, 또는 비기술적 대시보드는 제공되지 않습니다. 대신 그래프 링크와 쿼리(queries)를 제공합니다.
• 완성된 컴플라이언스 솔루션(Compliance in a box)이 아님: 엔터프라이즈용 내보내기(exports), 서명된 불변 히스토리(signed immutable history) 및 유사한 기능들은 현재 standard가 약속하는 것이 아니라 향후 프로필(future profile) 작업 사항입니다.
• 에이전트(Agents)에게도 여전히 리뷰가 필요함: sdlc start가 도움을 주기는 하지만, --write를 실행하기 전에 패킷(packet)을 읽는 과정을 대체하지는 않습니다.
• 정제된 규율 (Curated discipline): 지속적인 요구사항(ongoing vs satisfied)에 대한 관리나 그루밍 쿼리(grooming queries)는 한 번은 익혀야 하는 프로세스 표면(process surface)을 추가합니다.

가치가 있는 경우

상황	권장 사항
1인 개발자 + 에이전트, 컨텍스트가 계속 초기화됨	SDLC 도입 + sdlc start 패킷 사용
...

시도해보기

npm install --save-dev @topogram/cli
topogram init . --adopt-sdlc
topogram sdlc policy explain --json
...