본문으로 건너뛰기

하네스 감사 — 수용(미수정) 항목 결정 기록

일자: 2026-03-31 관련 문서: docs/decisions/2026-03-31-harness-audit.md 작성자: Leader (QA+PM)

개요​

하네스 감사보고서 31건 + 신규 발견 4건 총 35건 중 **7건을 의도적으로 수용(미수정)**합니다. 각 항목의 미수정 근거와 재검토 조건을 기록합니다.

수용 항목​

1. A-4: Planner-First 파이프라인 미강제 [P1-High]​

문제: "새 시스템은 Planner 설계 -> Coder 구현 순서" 규칙이 프롬프트에만 존재. TaskCreated 훅에서 Feature+Coder 조합이면 blocked_by에 Design 작업 필수 검증이 없음.

수용 근거:

  • TaskCreated 훅에 자동 종속성 주입을 구현하려면, "어떤 작업이 Design이고 어떤 작업이 구현인지"를 기계적으로 판단해야 함
  • 작업 유형(type 필드)이 "Feature"인 것만으로는 불충분 — 버그픽스, 리팩토링 등도 Feature로 분류될 수 있음
  • update-task.sh에 blocked_by 검증을 추가하여 (C-2 수정 완료), 잘못 시작하려는 시도는 이미 차단됨
  • 프롬프트 기반 Planner-First 지시 + Leader의 작업 생성 시 수동 종속성 설정이 현재 워크플로우에서 충분히 작동

대안 보상 장치:

  • Leader 프롬프트에 Planner-First 파이프라인 규칙 명시 (이미 적용)
  • update-task.sh의 blocked_by 검증으로 차단된 작업 시작 방지 (이미 적용)
  • 작업 생성 시 Leader가 수동으로 blocked_by 설정

재검토 조건: Planner 설계 없이 Coder가 새 시스템 구현을 시작하는 사례가 2회 이상 발생할 때

2. B-4: log-stop.sh 비동기 로그 의존 (경합 조건) [P1-High]​

문제: Stop 훅(동기)이 agent-events.jsonl을 읽는데, 이 파일은 log-tool-use.sh(비동기)가 씀. 팀원 최신 활동이 아직 안 쓰여서 Leader가 조기 종료할 수 있음.

수용 근거:

  • log-stop.sh는 2분 윈도우 내 활동을 체크함 — 비동기 쓰기 지연은 통상 수백ms 이내
  • 실제 운영에서 이 경합으로 인한 조기 종료 사례가 관측되지 않음 (이벤트 로그에 stop 10건 모두 정상)
  • 하트비트 파일 방식으로 전환하면 복잡도 증가 대비 실질 개선이 미미

대안 보상 장치:

  • 2분 윈도우가 충분히 넉넉하여 수백ms 지연을 흡수
  • Leader 조기 종료 시 사용자가 재시작하면 되므로 치명적이지 않음

재검토 조건: Leader가 팀원 활동 중 조기 종료하는 사례가 발견될 때

3. C-4: 작업 담당자 검증 없음 [P2-Medium]​

문제: update-task.sh에 에이전트명 파라미터가 없어서, 다른 에이전트의 작업 상태를 아무나 변경 가능.

수용 근거:

  • 현재 팀 규모 6명으로 작음 — 실수로 타 에이전트 작업을 변경할 확률이 낮음
  • update-task.sh에 에이전트 파라미터를 추가하면, 기존 모든 에이전트 프롬프트와 스크립트 호출부를 동시 수정해야 함 (후방 호환성 파괴)
  • Leader가 PM 역할로 모든 작업 상태를 관리하는 것은 정상 운영

재검토 조건: 팀 규모가 10명 이상으로 증가하거나, 타 에이전트 작업을 잘못 변경하는 사례가 발생할 때

4. F-2: Slack 채널 ID 하드코딩 [P2-Medium]​

문제: slack-post.sh 등에서 채널 이름을 채널 ID로 변환하는 로직이 하드코딩되어 있음.

수용 근거:

  • Slack 채널은 프로젝트 초기에 한 번 생성된 후 변경되지 않음
  • conversations.list API 캐시를 구현하면 네트워크 호출 추가 + 캐시 무효화 로직 필요
  • 현재 3개 채널(general, dashboard, review-queue)만 사용 — 하드코딩이 더 단순하고 신뢰성 높음

재검토 조건: Slack 채널 추가/변경이 빈번해질 때 (Phase 3 이후)

5. E-3: stop-agents.sh 이름 혼동 [P3-Low]​

문제: stop-agents.sh가 실제로는 대시보드 서버만 정지하는데 이름이 혼동됨.

수용 근거:

  • stop-dashboard.sh가 이미 별도 존재함
  • stop-agents.sh는 start-agents.sh와 짝을 이루는 이름으로 직관적
  • 리네임하면 기존 문서, 프롬프트, 호출부 모두 수정 필요
  • P3 수준의 가독성 이슈로 파급 효과 대비 가치 없음

재검토 조건: 신규 팀원(사람) 온보딩 시 혼동 발생

6. E-4: check-pending-commands.sh 폐기 코드 잔존 [P3-Low]​

문제: 더 이상 사용하지 않는 스크립트가 남아있음.

수용 근거:

  • 이미 [DEPRECATED] 표시 + exit 0만 실행 — 부작용 없음
  • 삭제 시 git 히스토리만 차지하고 실질적 개선 없음
  • pending-commands.jsonl 파일은 이미 존재하지 않음

재검토 조건: scripts/ 디렉토리 정리 일괄 작업 시

7. E-5: 대시보드 PID 경합 [P3-Low]​

문제: 대시보드 서버 시작 시 PID 파일 기반 중복 실행 방지가 flock 없이 구현됨.

수용 근거:

  • 대시보드 서버는 Leader가 단일 시작하므로 동시 시작 경합이 발생하지 않음
  • flock은 macOS에서 기본 미지원 (brew install 필요)
  • mkdir 기반 락이 이미 update-task.sh에 구현되어 패턴 일관성 유지

재검토 조건: 대시보드 서버 이중 기동으로 포트 충돌 발생 시

요약​

ID심각도항목수용 근거 핵심
A-4P1Planner-First 미강제기계적 판단 어려움 + blocked_by 검증으로 보상
B-4P1log-stop.sh 경합2분 윈도우 충분, 실제 문제 미관측
C-4P2담당자 검증 없음팀 규모 작음, 후방 호환성 파괴
F-2P2채널 ID 하드코딩3개 채널, 변경 빈도 극히 낮음
E-3P3스크립트 이름 혼동리네임 파급 효과 대비 가치 없음
E-4P3폐기 코드 잔존exit 0만 실행, 부작용 없음
E-5P3PID 경합단일 시작, macOS flock 미지원