gptbutler›문서›2026-08-02 세션 — gptbutler 기획 (ChatGPT 앱 비서 · MCP 커넥터) — 기록: [코디]
30.7 KB · 수정 2026-08-03 01:44
목차

2026-08-02 세션 — gptbutler 기획 (ChatGPT 앱 비서 · MCP 커넥터) — 기록: [코디]

논의·대안

발단은 "GPT와 연결된 기능이 지금 어디까지 내 자산에 닿는지 확인"이었다. 전수 확인 결과 GPT 연결 지점은 셋 — gpt-consult(MCP, .env의 GPT_BACKEND=browser → ChatGPT Plus 웹 UI 브리지, 도구 없음), gpt-consult-v2(같은 서버에 MCP env로 GPT_BACKEND=api, OpenAI Responses API + 읽기전용 도구 7종), agent-dialogue-hub(GPT↔채티 협의 루프·웹뷰어). 도달 범위는 GitHub 비공개 리포 11개(PAT delix0731), Notion 오브젝트 167개, 로컬 C:\dev 전체(정규식 전문검색 포함), 웹 3도메인. 노출 도구는 전부 GET이고 토큰은 헤더에만 쓰여 결과에서 스크럽된다.

그 확인의 목적이 "운용 프로젝트·도구가 너무 많아져서, PC·모바일에서 텍스트+라이브 보이스로 쓰는 비서를 GPT 공식 앱의 플러그·커넥터로 만들고 싶다"였다. 그래서 기획으로 넘어갔다.

기획의 뼈대를 가른 것은 플랫폼 제약 3건이다. ① ChatGPT 음성 모드에서는 커스텀 MCP 커넥터가 동작하지 않는다 — callbot에서 이미 내린 "GPT Live는 통화 중 도구호출 불가" 결론과 같다. ② 커넥터는 원격 HTTPS(SSE/Streamable HTTP)만 받고 로컬 stdio를 못 받는다 → 기존 cody-mcp-gateway의 로컬 MCP 경로를 그대로는 못 쓴다. ③ 모바일 앱에서는 쓰기 액션이 비활성이라 이동 중에는 읽기·브리핑만 된다.

대안으로 라이브 보이스는 네 갈래를 놓고 골랐다 — (a) 하이브리드(텍스트=커넥터, 보이스=사전 브리핑 주입, 추가 과금 0) (b) Realtime API 자체 PWA(음성 중 도구호출 가능하나 종량 과금 + 앱 자체 제작) (c) 텍스트만 먼저 (d) 기존 voicecody 확장. 노출 방식은 Cloudflare Tunnel / Tailscale Funnel / 클라우드 상주 / 데스크톱 로컬 MCP(모바일 포기)를, 인증은 비공개 URL+서버측 토큰 / OAuth 2.1 정석 / Cloudflare Access를, 서버 위치는 gateway 확장 / 신규 프로젝트 / hub 흡수를 비교했다.

부수 발견으로 로컬 읽기 가드의 구멍 2건이 나왔다(agent 도구의 safety 영역). 차단 글롭 credentials.*가 .credentials.json의 선행 점 때문에 불일치하고 한 줄 JSON이라 줄단위 마스킹도 비껴가 Claude OAuth 토큰이 평문으로 읽히며, .env·.env.* 글롭이 *.env를 못 막고 PW=가 마스킹 목록에 없어 PFS 운영·카카오 계정이 평문으로 읽힌다.

추가 지시 ① — devplan 매니저 (같은 날)

"운용 자산이 너무 많으니 현업(가구) 프로젝트와 부가 도구를 카테고리별로 분류하고 현재 상황에 맞춰 우선순위를 정리하는 역할"이 추가됐다. 순위 기준을 물었더니 페페 답은 "나는 사람이고 현업과 AI개발을 병행해야 한다. 두 길 위에서 균형을 조절해줄 비서가 필요하다" — 즉 기준 선택이 아니라 배분 설계를 요구한 것이다. 그래서 단일 순위표를 버리고 2트랙 균형 모델로 풀었다. 34개를 한 줄로 세우면 급한 현업이 상위를 다 먹어 개발이 영영 밀리거나 재미있는 개발이 올라와 납기가 깨진다.

추가 지시 ② — Codex 경로 (같은 날, 초안 정정)

"일반 채팅 GPT가 아니라 GPT PC 앱의 Codex로 연결해라, 활용범위가 크고 연결도 쉽다"는 지시. 확인 결과 지시가 맞았고 내 초안의 제약 판단 하나가 PC에서는 뒤집힌다. ChatGPT 데스크톱 앱은 설정에서 MCP 서버를 직접 등록하며 로컬 STDIO를 지원하고(~/.codex/config.toml, 데스크톱 앱·Codex CLI·IDE 확장이 설정 공유), 2026-07-23부터 음성이 데스크톱에 들어와 Chat/Work/Codex 세 모드에서 동작하며 음성으로 Codex 에이전트를 지휘한다. "음성모드엔 커넥터가 없다"는 제약은 웹·모바일 커스텀 커넥터 한정이었다. → PC 경로에서 터널·인증·경로토큰이 통째로 불필요해져 P0 난이도가 급락했고, 계획을 트랙 A(PC·데스크톱 stdio, P0~P1) / 트랙 B(모바일·원격 HTTPS 커넥터, P2)로 재편했다. 음성이 MCP 툴을 직접 호출하는지 Codex 태스크를 거치는지는 미확인 → P0 실측 항목.

추가 지시 ③ — session-relay 통합 (같은 날)

"GPT용 세션릴레이 계획도 수립해놨으니 통합해서 전체 계획에 반영하라"는 지시. 확인 결과 devplan/session-relay.html에 Codex 타깃 v1 설계가 2026-08-02 확정돼 있었다(로컬 실측 + 3관점 에이전트 검토 + GPT-5.5 상의). 결론은 codex exec --json -o <file> 서브프로세스 한 줄이 GUI 자동화 부품 전체를 대체하고, guard(체인상한·텔레그램 승인·중단지시)는 무수정 재사용, 사용량 게이트만 codex 자체 보고값을 읽는 신규 함수로 추가한다는 것.

두 계획은 역할이 다르고 Codex 표면이 같다 — session-relay=세션 수명 관리, gptbutler=비서 인터페이스. 그래서 합치지 않고 공유 지점만 명시했다: ①~/.codex/config.toml의 MCP 설정이 데스크톱 앱·CLI·IDE 공통이라 gateway를 한 번 등록하면 codex exec 체인 세션도 비서 툴을 그대로 쓴다(추가 작업 0) ②task_run 백엔드가 둘(대화형 claude -p / 무인 relay.py --target codex, guard 공유) ③사용량 지표를 매니저 주간리뷰가 함께 보고(단 usage는 비용 지표지 컨텍스트 잔량이 아니라는 상의 결론 유지) ④AGENTS.md=고정 / 인계문·툴 반환=동적 분리, .chatgpt-projects/g-p-*/AGENTS.md는 앱이 덮어쓰는 미러라 주입 채널 부적합 ⑤음성 30분 벽(GPT-Live 30~40분 컨텍스트 한계, 딥링크 없어 자동 인계 비범위)이 session-relay의 발단이었고, 이는 gptbutler 보이스 설계의 제약⑥으로 편입 — 브리핑은 언제든 1콜로 재생성 가능해야 한다.

session-relay가 이미 실측한 것(딥링크 프리필·exec --json 스트림·rollout 경로·app-server Windows 불가·threads 지연·standalone 핀)은 P0에서 재조사 금지로 못박았다.

추가 지시 ④ — 매니저 순위를 수치형에서 문맥 판정형으로 (같은 날)

페페 지적: "현재는 수치적 분배로 되어 있는데 신규 생성된 작업은 중요도가 높은데 수치적으로 약해서 상위 배치가 약할 수 있다. 이런 부분은 poin-agent, 가구 전문가, 클로드의 문맥 파악으로 중요도 파악이 필요하다."

맞는 지적이다. 초안의 순위 신호는 전부 이력에서 나오는 수치(정체일수·마감 D-N·세션 카운트)라, 방금 생긴 항목은 정체 0·세션 0으로 어느 규칙에도 안 걸려 cold start로 하위에 깔린다. 그런데 현장에서 방금 터진 문제나 통화로 막 확정된 납기가 대개 제일 급하다.

→ 2층 분리로 수정했다. 판정층(순위 생성) = poin-agent(현장 급박도 — 통화·카톡·PFS 실황) / furniture-expert(도메인 영향 — 제조·납기 구조) / 코디(기술 병목·비용 — 코드·의존)가 3축 라벨 + 근거 1줄을 남긴다. 배분층(가드레일) = 수치는 편향 경보·방치 감지·예산 잔량만 담당하고 순위를 만들지 않는다. 순위 규칙 1번을 "판정 현장 급박도 = 높음(신규 포함, 이력 무관)"으로 올려 cold start 구멍을 막았다.

그릴링 1문(신규 항목을 판정 전까지 어떻게 다루나) → 페페 확정 = 등록 즉시 자동 판정 호출. 비용은 라우터로 잡는다(가구·현장 건이면 poin-agent+furniture-expert, 도구·코드 건이면 코디만 → 보통 1~2콜, 최대 3콜, 잡담·중복은 trivial로 끊음). 판정 결과는 devplan/priority_state.json에 저장하고 코디가 쓰고 매니저는 읽는다(projects.json 불가침 유지). 재판정 트리거는 7일 경과·상태 변경·현장 이벤트, 리뷰에는 판정일 병기. 판정 실패는 재시도 루프 없이 "미판정"으로 상단 노출.

추가 지시 ⑤ — 현업/개발 정의 수정과 균형 목표 재수립 (같은 날)

[페페] 정의 확정: ①현업 = PFS·poin-agent·furniture-expert 등 실 업무 자동화를 활용하는 일 ②개발 = 가구·자동화·AI에 걸친 만드는 일이며, 1차 분류는 가구·PFS 직결인지 그 외 도구·프로젝트인지 ③현업 작업은 devplan에서 다루지 않는다 — 별도 현업 대시보드는 추후, 현재는 PFS에 접목된 자동화가 대부분.

이 정의를 받으면 초안의 biz(direct/indirect/experiment)는 폐기다 — 한 카드 안에서 현업을 가르려던 필드인데, 현업 실행 항목은 devplan에 아예 없다. 현업/개발은 필드가 아니라 원천이 나눈다(PFS·poin-agent vs devplan 카드). 개발 갈래만 dev_track 2값(pfs-furniture/tool)으로 남겼다 — 2값이라 애매함도 적고 P1 작업량도 준다.

균형 목표는 [페페] "새 전제에 따라 재수립해라, 기존 분류에 목매지 마라"에 따라 다시 세웠다. "현업 60:개발 40"은 현업 실행 시간을 devplan이 측정할 수 없어 근거가 없는 목표였고, 새 정의에서 현업과 개발은 경쟁이 아니라 공급-수요 관계다. → 감시 대상을 시간 배분에서 순환으로 바꿨다: A 환류(live인데 30일 사용 흔적 0 = 헛돈 개발) · B 갈래 배분(가구·PFS : 도구, 세션문서 × dev_track으로 devplan 안에서 정확히 측정 — 유일하게 숫자 목표를 걸 자격이 있는 축) · C 유입(현업에서 판정된 항목이 개발 백로그로 안 넘어오고 7일 체류). 현업 실행량 자체에는 목표를 걸지 않는다(근사뿐이라 거짓 경보) — A·C가 현업을 대리하고, 현업 대시보드가 생기면 실측으로 대체한다.

추가 지시 ⑥ — 기록 주체 표기 (같은 날)

[페페] "코디와 GPT 병행 사용 중이라 역할 분담은 있으나 파일 기록에 혼선이 있을 수 있다. user_brief 및 여러 문서에 기록한 자에 대한 표기가 필요하다."

새 형식을 만들지 않고 SARA 노션에서 쓰던 [사용자]/[채티]/[코디] 접두 컨벤션을 승계해 [코디]/[GPT]/[페페]로 통일했다. 위치는 항목 단위 접두(sessions.md 각 줄·handoff NOW·ideas.md append·archive 이관 항목), 세션문서는 제목 줄에 — 기록: [코디] 1회. frontmatter는 쓰지 않는다(협의 #36 "No frontmatter" 유지). 발화 주체 우선 — 페페 지시를 코디가 옮겨 적었으면 [페페]. 자동화 기록은 도구명([relay]).

전역 규칙이므로 user_brief/rules/workflow.md "작업 원칙"에 기록했다. gptbutler 쪽 적용은 자동화로 — note_add가 남기는 줄은 자동 [GPT], task_run이 코디를 돌려 만든 기록은 [코디], 판정 결과의 judged_by도 같은 어휘를 써서 표기 체계를 하나로 통일한다. 이 규약은 비서에 쓰기를 열기 전에 서야 한다(GPT가 문서를 쓰기 시작하면 혼선이 커지므로 P3 선행 조건).

추가 지시 ⑦ — devplan 허브 개선 목업 + 심사 대시보드 폐기 (같은 날)

[페페] "gptbutler에 추가 페이지로 devplan 메인의 개선 목업을 넣어라. 최대 20개지만 수량을 채우지 말고 관리형 UI의 대표 카테고리로 추천할 만한 안만 선정해라." 요구 = R1 카드가 어느 프로젝트인지 시선으로 즉시 안 잡힌다(최신순·수치순 배열로는 부족, 위 중요순위 분배처럼 문맥적 중요도 분류 필요) · R2 dashboard-review.html 폐기 · R3 devplan은 모든 프로젝트·작업을 통합 관리하는 최상위 페이지 · R4 카드 링크는 정확히 2개(기획서 / 관리페이지 = 생성 후 수정·실사용 관리항목 CRUD, 예 kakao-ops.html 카톡 관리).

수량을 채우지 말라는 지시에 맞춰 관리형 UI의 서로 다른 계열 7종만 골랐다(트리아지 결정 큐 / 2트랙 스위밍레인 / 중요도×상태 사분면 / 아이덴티티 타일 / 관리형 데이터 테이블 / 자산 건강판 / 브리핑 내러티브). 워크플로 서브에이전트 15개 — 설계 7(각 아키타입을 극단까지) → 적대검증 7(요구 4개 준수·34개 규모 내구성·데이터 실현성·색약 안전·네임스페이스 격리를 확인하고 결함을 직접 수정한 최종본 반환) → 종합 1(순위·단일 채택안·조합안·탈락). 산출 = devplan/gptbutler-hub-mockup.html(실물 렌더 목업 + 평가표 + 종합 판단).

결과는 7종 전부 8.0~8.5점으로 탈락 0이었다. 점수가 사실상 동점이라 변별력이 없어 종합 심사는 "화면을 열고 3초 안에 다음 행동이 나오는가"로 순위를 다시 매겼다 — 단일 채택안 = 트리아지 결정 큐(지금 뭘 해야 하는지에 화면이 대신 답하는 유일한 구조, 나머지는 현황만 주고 판단은 사람 몫), 조합안 = 트리아지(즉답) → 2트랙 레인(맥락) → 데이터 테이블(검색, 기본 접힘) 필요빈도 내림차순. 비권장 2종 = 브리핑 내러티브(수기 갱신이 밀리면 조용히 거짓말하는 화면이 된다 — 검증 중 실제 사실오류 1건 발생)와 사분면 맵(신규 프로젝트마다 좌표 수작업, 핀 겹침 실측 → 월간 회고용으로만). 간트·캘린더는 시작·마감·의존 데이터가 없고 현업 병행이라 고정 마감 자체가 드물어 가짜 일정 없이는 못 그린다 — 시도하지 않는 것이 맞다는 판단.

전 목업 공통 선행 작업 하나가 남았다 — 34개 프로젝트의 기획서·관리페이지 경로 매핑표. 지금 링크는 전부 더미라 R4의 2링크 규칙이 실제로 성립하려면 이 매핑이 먼저다.

R2는 즉시 실행했다 — 허브에서 링크 3곳(상단 탭·푸터 문구·모달 "심사 대시보드로 승격 검토" 버튼) 제거 후 재빌드, 페이지 파일은 C:\dev\_trash\devplan-dashboard-review-softdeleted-20260802\로 소프트딜리트(원본 보존), 생성기 build_dashboard.py는 지우지 않고 재실행 금지 헤더만 붙였다(입력 _wf*.json이 남아 있어 되돌릴 여지를 둔다).

추가 지시 ⑧ — 텔레그램 알림 점검 (같은 날)

[페페] "broker 텔레그램이 안 왔다. 세션이 dev에 없어서인지 다른 이유인지 확인하고, 이 세션은 단계별 알람까지 포함해 보고해라. 다른 프로젝트는 완료 시 알람이 정상 작동하는지 체크해라."

진단 결과 broker는 정상이고 원인은 내가 안 보낸 것이다(세션 경로와 무관). 근거 = broker 127.0.0.1:7777 LISTENING, DB notifications 최신 4건(8/2 02:03 야간 통화 파이프라인 · 16:54 ytmine · 17:07 ai-study · 18:44 devplan) 전부 telegram_ok=1. 이 세션은 19시 이후 시작인데 그 사이 발송 기록이 0이다. 8/1 20:45~23:34 실패 15건은 전부 api.telegram.org DNS 해석 실패(미니PC 인터넷 끊김 사건) — 토큰·코드 문제가 아니고 지금은 복구됐다. 예약작업 5종(PFS-KakaoBoard-Sync·PFS-Night-Worklog·SessionRelay-Calibrate·gmail_notify·CodyPermissionBrokerWatchdog) 마지막 실행 결과 전부 0(성공). 즉시 /notify-step 8/10을 보내 telegram_ok=1·한글 온전성까지 확인했다.

추가 지시 ⑨ — 목업 v2: 테이블 채택 + 2트랙 (26.8.3)

[페페] "3번 관리형 통합 테이블이 가장 마음에 든다. 여기에 2트랙 구분 기능을 추가하면 좋겠다. 3번을 메인 UI로 보고 2트랙 기능만 추가한 형태로 변형해 다시 목업 생성해라. 선택 안 된 항목들은 모두 폐기하고 3번 기준으로 다시 갈래를 나눠 추천 목업을 만든다."

관리형 데이터 테이블이 devplan 메인 UI로 확정됐다. 나머지 6종은 폐기했고 v1 페이지 원본만 _trash/devplan-mockup-v1-superseded-20260803/에 보존했다. v2는 아키타입을 바꾸지 않는다 — 테이블의 밀도·구획·환류 열을 그대로 두고 2트랙(가구·PFS 직결 / 도구·기타) 표현 방식만 5갈래로 나눴다: 트랙 배지 열(최소 변경) / 구획 내 트랙 서브그룹 / 트랙 2섹션 분리 / CSS 탭 필터 / 배분 바+인터리브.

결과는 「배분 바 + 인터리브」 추천(점수 9 · 베이스 보존 10 · 중요도 보존 10). 이 안만 트랙으로 화면을 쪼개지 않는다 — 상단 게이지(현재 41:59 · 목표 60:40 · −19%p 경보)로 균형만 감시하고 표는 중요도 순 인터리브를 유지해 함정 자체를 회피한다. 차점 badge도 9점이었으나 배지만 있고 비율 지표가 없어 "곁눈질로 치우침 파악"이 안 돼 탈락. 접붙이기는 2건만 — tabs의 CSS-only 트랙 필터(한 트랙 파고들 때)와 badge의 텍스트 라벨 병기(색띠+아이콘만으로는 반년 뒤 색 의미를 잊는다). 나머지 탈락 = subgroup(접힘 상태에서 트랙 비율 비노출, 검증 중 환류 열 실질오류) · split(P1~DEAD 완전분리라 트랙 간 비교에 섹션을 오감) · tabs(비교에 클릭이 필요 → 곁눈질 요건 미달).

반년 뒤 무너질 지점 2개도 미리 받아 적었다 — ①목표 60:40이 상수라 실제 업무 비중이 바뀌면 경보가 오탐만 울리다 무시된다(재조정 절차 필요) ②신규 카드에 dev_track 기본값을 강제하지 않으면 미분류가 쌓여 배분 바가 실제와 어긋난다 → build_hub.py가 미분류를 FAIL로 막는 게 맞다(source 경로 검증과 같은 패턴).

설계의 핵심 함정을 모든 변형의 공통 과제로 못박았다 — 트랙으로 화면을 쪼개면 "가장 급한 항목"이 두 군데로 분산돼 사람이 어느 쪽이 더 급한지 다시 비교해야 한다. 그러면 "3초 안에 다음 행동"이라는 목적 자체가 깨진다. 그래서 각 변형은 트랙을 보여주면서 중요도 1차 배열을 지키는 방법을 각자 제시하게 하고, 적대검증에서 점수와 별개로 베이스 보존도(테이블 강점을 지켰나)와 중요도 보존도(가장 급한 것이 흩어지지 않았나)를 따로 채점하게 했다.

추가 지시 ⑩ — 매니저 = 아바타로 승격 + 게이지 격하 (26.8.3)

[페페] ①v2 보완 제안(탭 필터·텍스트 라벨)은 추천안으로 진행 ②"게이지로 가구/도구 비율 표기가 되어 있는데 수치는 참고용으로 좋지만 이 부분이 중요한 부분은 아니다. 문맥적 파악으로 순위를 구성하다 보면 60:40 비율은 평균치일 뿐 매일 변한다" ③"devplan 매니저의 역할은 최종적으로는 직접 프로젝트 개발 계획을 세우고 내게 승인을 받아서 완료 목표를 기준으로 완료 시점까지 프로세스를 끌고 가는 것이다. 즉 나의 아바타가 되어 작업을 수행한다. 이 과정에서 devplan에 진행 상황을 갱신하고 내가 이해하기 쉬운 구조로 보고를 지속한다" ④목업은 한 스크롤이 아니라 탭으로 분리하고 목업을 상단·설명을 하단에.

이건 매니저의 성격이 바뀌는 지시다 — 조언자에서 실행 오너로 승격. 계획을 세워 승인을 받고, 완료 목표를 기준으로 완료 시점까지 끌고 가며, 진행을 갱신하고 지속 보고한다. 사이클 6단계로 고정했다: ①계획 수립(목적·범위·금지·완료조건·검증·되돌리기) → ②페페 승인 게이트(여기서 멈춘 건이 아바타의 가장 비싼 지연 → 화면 최상단 결재선) → ③완료 목표 확정(목표 없는 건은 "목표 미설정"으로 드러냄) → ④실행 추진(task_run → 코디, 위험 작업은 broker) → ⑤devplan 진행 갱신(project_state.json) → ⑥지속 보고. 승인은 사람 몫으로 남긴다 — 매니저가 스스로 승인하는 경로는 만들지 않는다. 툴 2종 추가(plan_draft, progress_update)로 총 11종.

배분 게이지는 격하했다. 60:40은 평균치이고 매일 변하므로 일간 화면에서 크게 울리면 오탐으로 무시된다 → 작고 조용한 참고 지표로 내리고 ±15%p 경보는 주간 리뷰에서만. 대신 배분층에 D 추진 정체를 신설했다(승인 대기 3일↑ · 단계 전환 없이 흐른 일수 · 완료 목표 미설정) — 배분 비율보다 이쪽이 실제로 일을 막는다.

UI 요구도 따라 바뀌어 v3 목업을 다시 돌렸다(설계 5 + 적대검증 5 + 종합 1). 표가 담아야 할 아바타 5요소 = 완료 목표(조건+D-N, 미설정 노출) · 현재 단계 · 다음 액션+주체 · 페페 결재선 · 최근 진행 보고. 갈래 = 단계 스테퍼 열 / 완료목표 D-day 중심 / 결재선 우선 / 보고서형 행 확장 / 주간 추진 보드. 검증에는 avatar_coverage(5요소 충족도)를 축으로 추가하고, "진척률 73%" 같은 가짜 정밀도는 단계 기반 표기로 강제 교체하게 했다(우리에게 공수 데이터가 없다).

v3 결과 = 「완료 목표 D-day 중심」 추천(종합 9 · 아바타 충족 10 · 중요도 보존 10). 5요소가 전부 별도 열로 존재하고 D-day 자체가 완료까지 남은 거리라 모델과 직결된다. 접붙이기 2건만 — 결재선 갈래의 상단 고정 결재 큐 배너(추천안은 결재선이 열이라 스크롤해야 보이는 게 유일한 약점)와 스테퍼의 단계 점 시각화. 탈락 = 스테퍼(CSS 스코프 누수 20개 셀렉터·정체 배지 색 역전을 검증에서 잡아 수정했으나 승인·완료거리 신호가 간접적) · 결재선(큐는 강하나 완료 목표·거리 표시가 약함) · 보고서형(<details> 행 확장이라 순수 table 이탈 + D-N이 추정치) · 주간보드(하위 30건의 남은 거리가 흐릿, 아바타 충족 8로 최저).

매니저 운영 규칙도 함께 확정했다 — 승인 요청 시 배너와 결재선 열에 요청 건·요청일을 동시에 채우고(안 채우면 대기 진입 금지), 단계 전환마다 즉시 갱신하며 다음 액션은 "액션+주체" 형태로, D-day는 확정된 것만 쓰고 미확정은 "미설정" 유지(추정치 금지), 완료 시 24~48시간 내 아카이브 강등, 주 1회 이상 최근 보고 갱신. 반년 뒤 붕괴 1순위는 지난 D-day 방치(갱신 안 하면 남은 거리가 거짓말하는 표가 된다), 2순위는 건수 드리프트(결재 대기 숫자를 수동 표기하면 카드가 늘 때 어긋난다 — 검증에서 4 vs 5 실측) → 자동 계산 강제.

페이지는 지시대로 탭 전환(CSS-only, 추천안이 기본 선택) + 목업 상단 · 설명 하단으로 재구성했고, 상단에 결론 한 줄 바를 뒀다.

추가 지시 ⑪ — 완료 목표 모델 재정의: 날짜가 아니라 완성도 (26.8.3)

[페페] "D-day는 devplan에서 보조 역할 정도만 하고 메인 기준이 될 수 없다. 작업이 보류될 수도 있고 사용자 특성상 하루 또는 몇 시간 만에 작업 완료를 할 수도 있다. 단계 중심으로 완성도 표시가 더 의미가 있다. 완료 목표는 실사용 기준으로 부분 우선 작업 또는 전체 작업 기준 등의 분류 기준을 먼저 잡고, 완료 목표를 1차 최종 또는 다회차 완료 기준으로 잡아야 되는 게 맞다."

바로 앞에서 v3가 추천한 「완료 목표 D-day 중심」의 축 자체가 기각됐다. 이 사람의 작업 속도는 편차가 극단적이라(몇 시간에 끝나거나 몇 주 보류되거나) 날짜로 줄을 세우면 표가 매일 거짓말한다. 완료 목표는 범위(부분 우선/전체) × 차수(1차 최종/다회차) 를 먼저 분류하고, 완성도는 단계(계획→승인→실행→검증→완료) × 회차로만 표현한다. 퍼센트 금지(공수 데이터가 없어 가짜 정밀도). 보류는 1급 상태로 사유+재개 조건을 함께 보여주고 지연처럼 빨갛게 칠하지 않는다 — 정상적인 선택이다. 날짜는 있으면 작은 회색 보조 표기, 정렬·강조·경보 기준으로 쓰지 않고 지난 날짜를 붉게 칠하지 않는다. 시간 신호가 필요하면 "마지막 진척 이후 경과"(단계가 안 바뀐 채 흐른 기간)를 쓴다 — 이건 방치 감지라 의미가 있다. 배분층 D(추진 정체)의 신호도 날짜 초과가 아니라 단계 무전환으로 교체했다.

목업 v4를 같은 구성으로 재생성했다(설계 5 + 적대검증 5 + 종합 1). 검증축은 아바타 충족도 대신 완료 명확도 / 날짜 비의존 / 베이스 보존 3축으로 바꿨다. 갈래 = 단계 게이지+회차 배지 / 완료 기준 체크리스트형 / 회차 타임라인 열 / 범위×차수 분류 그룹 / 단계 사다리 행 확장.

v4 결과 = 「단계 게이지 + 회차 배지」 추천(종합 9.3 · 완료 명확도 9 · 날짜 비의존 9 · 베이스 보존 10으로 5안 중 최고, kill 0). 진행을 면적으로 보여주는 유일한 안이라 날짜 없이 3초에 "어디까지 왔나"가 잡히고, 35행 전부에 이번 회차 완료 기준 1줄이 있으며, 보류는 별도 tier로 격리돼(경고색 배제) 죄책감 없이 표현된다. 게이지가 셀 안 인라인 요소라 표 밀도를 안 깨고 60행까지 버틴다. 접붙이기 2건만 — matrix의 범위×차수 고정 배지 열(정렬·필터에 유리)과 criteria의 보류 재개 조건 1줄 필수화(비면 등록 반려). 탈락 = criteria(완료 기준 표현은 최강이나 단계를 3초에 보여주는 축이 없음, 8) · rounds(회차 원 개수를 세야 하고 완료 tier엔 완료 기준 문구가 아예 없음, 8) · matrix(9컬럼·min-width 900px라 항목당 정보가 산개, 9) · ladder(행 확장이라 35→60건에서 세로 팽창 + "다회차 1차" vs "1차 최종" 오독 여지, 8.7).

완료 목표 운영 규칙도 확정했다 — ①등록 시 범위·차수를 먼저 태깅하고 모르면 계획단계-미정(빈칸 금지) ②총 회차를 모르면 "다회차(회차미정)"로 시작해 확정 즉시 N/M으로 갱신 ③회차 +1은 스코프 변경 또는 이전 회차 산출물 폐기 때만(단순 재검토·버그수정은 회차 유지) ④완료 전환은 이번 회차 완료 기준 충족이 조건이고 부분 범위는 그 부분만 충족해도 완료 태깅 가능(실사용 기준이므로) ⑤보류는 tier 격리 + 재개 조건 1줄 필수, 비면 등록 반려. 반년 뒤 붕괴점도 v4 기준으로 교체했다 — 1순위는 회차 운영의 주관성("스코프 변경" vs "단순 재검토"의 경계를 본인도 반년 뒤엔 잊어 회차가 인플레되거나 반대로 안 늘어난다), 2순위는 "다회차(회차미정)" 라벨 고착(계획 단계에서 붙인 임시 라벨이 착수 후 재분류 안 되면 게이지가 실제 진척과 괴리된 채 굳는다). v3의 1순위였던 "지난 D-day 방치"는 D-day를 보조로 격하하면서 해소됐다.

검증 = check_theme.py FAIL 0 · 네임스페이스 위반 0(5조각 319선택자 전수 정규식) · 조각 내 <script> 0 · 외부 리소스 0 · 탭 배선 5/5(추천안 기본 선택 1개) · build_hub.py --selftest 카드 35장 source 전부 해결 · 브라우저 실물 렌더 확인(콘솔 오류는 favicon 404뿐). v3 페이지 원본은 _trash/devplan-mockup-v3-superseded-20260803/에 보존했다.

결정

그릴링 8건 확정(재논의 금지) — 보이스=하이브리드(브리핑 주입) / 노출=Cloudflare Tunnel / 인증=비공개 URL 경로 토큰 + 서버측 검증(커넥터는 무인증 등록) / 쓰기=기존 cody-permission-broker(위험도 분류 + Telegram 승인) 재사용 / 1차 범위=PFS 업무조회·문서결정 검색·작업아이디어 등록·코드리포 조회 4축 / PFS=REST API 재사용(POST /api/auth/login → 세션) / 코드=cody-mcp-gateway 확장(신규 프로젝트 0) / 브리핑=같은 대화 텍스트 호출 후 음성 전환.

매니저 그릴링 4건 추가 확정 — 분류=기존 5카테고리 유지 + 카드에 biz(direct/indirect/experiment) 1줄, 카테고리 자체는 신규 프로젝트에 맞춰 수정 가능 / 순위=2트랙 균형 모델(배분 목표 기본 제안값 현업 60:개발 40, ±15%p 경보, 실제 배분은 최근 2주 세션문서 수 × biz로 근사) / 리듬=요청 시 1콜 + 주 1회 주간리뷰 자동 생성 / 쓰기=파일 직접 수정 금지, 코디 지시문까지 생성 후 승인 시 task_run 전달. 순위 규칙은 priority_rules.md(사람 편집)에 ①현업 마감 임박 ②병목 ③90% 마무리 ④60일 방치 정리로 고정.

경로는 트랙 A(PC=데스크톱 Codex 로컬 stdio, 터널 0) / 트랙 B(모바일=원격 HTTPS 커넥터, P2 후순위)로 재편. P0는 "커넥터가 붙는가"에서 "데스크톱 Codex에 stdio로 붙는가 + 음성으로도 되는가"로 바뀌었다.

툴은 9개로 상한을 못박았다(brief_today, portfolio_review, pfs_query, docs_search, docs_read, repo_read, code_search, note_add, task_run). 읽기 가드는 gpt_tools.py를 복제하지 않고 import 재사용한다. 가드 구멍 2건 수정은 P0 이전 필수 — 커넥터를 열면 같은 코드가 인터넷 경유로 호출되므로, 고치기 전에는 터널을 열지 않는다.

산출물·커밋

다음

P0 — 가드 2건 수정 → ChatGPT 데스크톱 앱에 gateway를 STDIO로 등록 → Codex 모드 툴 호출 + 음성 지휘 실측(30분, 터널 작업 0). 막히면 트랙 B(터널)를 앞당긴다. 이후 P1 brief_today + portfolio_review. P1 착수 전 그릴링 대상 6건 — 배분 목표 숫자(60:40이 맞는가·주 단위가 맞는가) / 카드 34개 biz 값 채우는 방식 / 브리핑 구성·분량 / "오늘 일정"의 단일 출처 부재 / 모바일 쓰기 우회 허용 여부 / gpt-consult 정리 시점.

관계