# 에이전트 미팅: 완료된 Todo 안건 대시보드 UX 처리 방안

**날짜**: 2026-03-12
**소집**: 아누 (개발실장)
**참석**: 오딘(2팀장, 시스템 설계), 미미르(2팀 UX/UI), 아테나(1팀 UX/UI), 로키(레드팀, DA)
**토론 모드**: 2사이클 (독립 → 종합)

---

## 배경 분석 (아누)

### 현재 상태
- `todo.json`에 13건의 안건(issue) 존재
- `issue-011` (마케팅 에이전트 역량 강화): **status="done"**, completed_at 기록됨, sub_items 7/7 완료
- `issue-012` (대시보드 후속이슈): **status="in_progress"**, sub_items 5/5 완료 (status 갱신 누락)
- 프론트엔드 필터: `i.status !== 'completed'` — "completed"만 걸러냄. "done"은 통과하여 화면에 표시됨
- 서버 API (`/api/todo`): 필터링 없이 전체 반환 (project 필터만 존재)

### 제이회장님 요구사항
1. 완료 안건이 대시보드 상단에 떠있는 것은 UX/UI상 불편
2. 히스토리에서 나중에 다시 체크할 수 있어야 함
3. 즉, **아카이브(숨김) + 이력 보존** 둘 다 필요

---

## Cycle 1: 독립 의견

### 오딘 (시스템 설계 — 데이터 구조 & API)

**1. 데이터 구조 제안: `archived` 필드 추가**

별도 파일(todo-archive.json)로 분리하는 것보다 **동일 파일 내 필드 추가**가 낫다.

```json
{
  "id": "issue-011",
  "status": "done",
  "archived": true,
  "archived_at": "2026-03-12T18:30:00",
  ...
}
```

근거:
- 별도 파일 분리 시: 안건 이동 로직, 두 파일 동시 관리, 데이터 정합성 리스크
- 필드 추가 시: 기존 API 호환, 단일 소스 오브 트루스 유지, 필터 한 줄 추가로 해결
- status 값으로 분리("archived" 상태 신설)도 검토했으나, status는 작업 진행 상태(pending/in_progress/done)를 표현하는 축이고, 아카이브는 **표시 여부**를 표현하는 별도 차원이므로 독립 필드가 의미론적으로 맞음

**2. API 변경**

```
GET /api/todo              → 기본: archived 제외 (archived=false만)
GET /api/todo?include_archived=true  → 전체 (아카이브 포함)
GET /api/todo?archived_only=true     → 아카이브된 것만
PUT /api/todo  body: {"id": "issue-011", "archived": true}  → 아카이브 처리
PUT /api/todo  body: {"id": "issue-011", "archived": false} → 아카이브 해제 (복원)
```

- 기존 API 경로 유지, 쿼리 파라미터만 추가. 하위 호환성 100%.
- 아카이브 해제(복원) 가능해야 함. 실수로 아카이브한 경우 되돌리기 필수.

**3. status 정규화 선행 필요**

현재 issue-012처럼 sub_items가 전부 done인데 status가 "in_progress"인 불일치가 있음. 아카이브 기능과 별개로, **status 갱신 로직**을 점검해야 함. sub_items 전체 완료 시 자동으로 status를 "done"으로 변경하는 로직이 서버에 있어야 하는지, 아니면 수동 관리인지 명확히 해야 함.

**4. 구현 난이도: 낮음 (Lv.1)**

- server.py: GET 핸들러에 archived 필터 3줄, PUT 핸들러에 archived 필드 처리 2줄
- todo.json: 기존 데이터에 archived 필드 없으면 false 취급 (default)
- 예상 수정: server.py 10줄 이내

---

### 미미르 (UX/UI — 사용자 경험)

**1. 핵심 UX 원칙: "완료 = 보상감 + 정리감"**

완료 안건이 계속 보이면 두 가지 심리적 문제가 생김:
- **성취감 희석**: 완료했는데도 목록에 남아있으면 "아직 안 끝난 것 같은" 느낌
- **인지 부하**: 진행 중인 것과 완료된 것이 섞이면 현재 해야 할 일 파악이 어려움

따라서 기본 뷰에서 완료 안건을 **숨기되**, 사용자가 원할 때 쉽게 접근 가능해야 함.

**2. UI 방안: "접이식 섹션" 추천**

여러 방안을 비교:

| 방안 | 장점 | 단점 |
|------|------|------|
| A. 완전 숨김 + 별도 탭 | 깔끔 | 접근성 낮음, 탭 이동 귀찮음 |
| B. 토글 버튼 (숨김/표시) | 간단 | 토글 위치가 어색, 맥락 전환 |
| C. **접이식 섹션** | 맥락 유지 + 깔끔 | 구현 약간 복잡 |
| D. 탭 내 서브탭 | 구조적 | 과도한 설계 |

**C안 "접이식 섹션" 상세:**

프로젝트 카드 내부에서 안건 목록 아래에 접힌 상태로 "완료 안건 N건" 표시:

```
[ThreadAuto 카드]
├─ 안건: 운영 인프라 구축 (진행중)     ← 활성 안건
├─ 안건: 실전 배포 및 검증 (대기)       ← 활성 안건
└─ ▶ 완료된 안건 2건                    ← 접힌 상태 (클릭하면 펼침)
     ├─ ✓ 마케팅 에이전트 역량 강화
     └─ ✓ 대시보드 후속이슈
```

- 기본: 접힌 상태 (시각적 노이즈 최소화)
- 클릭: 펼쳐서 완료 안건 확인 가능 (히스토리 접근)
- 해당 프로젝트 맥락 안에서 바로 볼 수 있음 (탭 이동 불필요)

**3. 시각 디자인**

- 완료 안건: 텍스트 `text-slate-400` + `line-through` (취소선)
- 프로그레스 바: 100% 초록색 (완료 상태 명시)
- 카운터: "완료된 안건 N건" 라벨, `text-slate-400` 컬러
- 펼침 시 배경: `bg-slate-50` 으로 활성 안건과 시각적 구분

**4. 자동화 vs 수동**

- **자동 아카이브 추천**: status가 "done"이면 자동으로 아카이브 처리. 별도 버튼 클릭 필요 없음.
- 근거: 제이회장님은 개발자가 아님. "아카이브 버튼을 눌러야 숨겨진다"는 추가 인지 부하.
- 아카이브 해제는 수동 (혹시 잘못된 경우)

---

### 아테나 (UX/UI — 대안적 관점)

**1. 미미르와의 관점 차이**

미미르의 "접이식 섹션"은 **프로젝트 카드 내부**에 완료 안건을 넣는 방식인데, 이에 동의하지 않음.

**문제**: 완료 안건이 프로젝트별로 흩어짐. 제이회장님이 "최근 뭘 끝냈지?" 하고 전체를 보고 싶을 때, 각 프로젝트 카드를 하나씩 열어야 함.

**2. 대안: 프로젝트뷰 상단에 "완료 요약 위젯"**

프로젝트 그리드 상단에, 최근 완료된 안건을 프로젝트 관계없이 시간순으로 모아서 보여주는 위젯:

```
┌──────────────────────────────────────────┐
│ ✓ 최근 완료 안건                    모두 보기 → │
│ ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ │
│ ✓ 대시보드 후속이슈       DevInfra  03-12  │
│ ✓ 마케팅 에이전트 역량 강화 DevInfra  03-12  │
└──────────────────────────────────────────┘
```

- 최근 완료 3~5건만 표시 (최신순)
- "모두 보기" 클릭 시 기록(archive) 탭으로 이동하여 전체 완료 이력 열람
- 프로젝트 카드에서는 완료 안건 **완전 제거** (깔끔함)

**3. 기록(Archive) 탭 연계**

3/11 미팅 (2026-03-11-dashboard-archive-ia.md)에서 이미 [기록] 탭을 추가하기로 합의했음. 완료 안건의 "모두 보기"는 이 기록 탭의 한 섹션으로 자연스럽게 들어갈 수 있음.

기록 탭 구조:
```
[기록 탭]
├─ 완료 안건 (todo archive)     ← 새로 추가
├─ 작업 보고서 (reports)
└─ 미팅 기록 (meetings)
```

**4. 자동 아카이브에 동의하되 조건 추가**

- status="done" 이면서 **completed_at이 존재**할 때만 자동 아카이브
- completed_at이 없으면 status가 done이어도 아카이브하지 않음 (데이터 불완전 경고 표시)
- 이유: issue-012처럼 sub_items 전부 done인데 status/completed_at 미갱신인 케이스가 실제로 존재

**5. 구현 관점**

- 프로젝트 카드 내 필터: `issues.filter(i => !i.archived)` 한 줄
- 상단 위젯: 별도 컴포넌트 20~30줄
- 기록 탭 섹션: 이미 합의된 구조에 추가하는 것이므로 자연스러움

---

### 로키 (DA — 레드팀)

**DA 3대 질문:**

#### 질문 1: "이 기능이 실패하는 시나리오는?"

**시나리오 A — 아카이브된 안건을 아무도 안 본다.**
- "나중에 다시 체크"라고 했지만, 실제로 아카이브된 걸 다시 열어보는 빈도는 극히 낮을 것. 결국 아카이브 기능을 구현해도 그냥 숨기기 버튼일 뿐.
- **반론**: 그래도 괜찮다. 핵심 요구사항은 "대시보드에서 치우기"이지 "아카이브 열람"이 아님. 열람은 선택적 부가 기능.
- **판정**: 리스크 낮음. 하지만 아카이브 열람 UI에 과도한 투자를 하지 말 것.

**시나리오 B — 자동 아카이브가 실수로 활성 안건을 숨긴다.**
- status를 "done"으로 실수로 변경한 경우, 자동 아카이브가 활성 안건을 숨겨버림.
- 제이회장님이 "어? 분명 있었는데 없어졌다?"라고 혼란.
- **반론**: 복원(unarchive) 기능으로 대응 가능.
- **판정**: 리스크 중간. 복원 기능은 필수 요건으로 격상해야 함.

#### 질문 2: "나중에 후회할 이유는?"

**"archived 필드를 추가하면 todo.json 스키마가 점점 비대해진다."**

현재 issue 필드: id, project, title, description, priority, status, created_at, completed_at, linked_tasks, sub_items (10개). 여기에 archived, archived_at이 추가되면 12개.

향후 예상 필드 증가:
- assignee (담당팀)
- due_date (마감일)
- tags (태그)
- comments (코멘트)

→ 금방 15~20개 필드가 될 수 있음. todo.json이 사실상 JIRA ticket이 되어가는 거 아닌가?

- **반론**: 현재 13건 규모에서 필드 2개 추가는 문제 없음. 안건이 100건 넘으면 그때 DB 마이그레이션 논의해도 늦지 않음.
- **판정**: 현재 규모에서는 문제 없으나, 경계선을 인식하고 있어야 함. **안건 30건 초과 시 구조 재검토** 트리거를 두자.

#### 질문 3: "더 단순한 대안은 없는가?"

**대안: status 필터만 수정하면 끝 아닌가?**

현재 코드:
```js
(todoData || []).filter(i => i.status !== 'completed')
```

이걸 이렇게 바꾸면:
```js
(todoData || []).filter(i => i.status !== 'completed' && i.status !== 'done')
```

**한 줄 수정으로 완료 안건이 사라진다.** archived 필드, API 변경, 위젯, 아무것도 필요 없다.

히스토리 열람? `todo.json` 파일을 직접 보면 된다. 혹은 이미 합의된 기록 탭에서 `todo.json`의 done 항목을 보여주면 된다.

- **반론**: 너무 단순해서 "아카이브 해제"가 불가. status를 done에서 다시 in_progress로 바꿔야 하는데, 그건 아카이브 해제가 아니라 상태 변경임. 의미가 다름.
- **판정**: 최소 MVP로는 유효. 하지만 아카이브/복원 시맨틱이 필요하다면 archived 필드가 맞음.

#### 추가 리스크 지적

**리스크: 현재 status 값 혼란**

현재 사용되는 status 값: `pending`, `in_progress`, `done`. 그런데 프론트엔드 필터는 `completed`를 걸러냄. 실제 데이터에 `completed`를 쓰는 안건은 없음. 이건 **dead code**이거나, 과거 어느 시점에 `completed`를 쓰다가 `done`으로 바뀐 것.

이 불일치를 방치하면 "done"이 아카이브 대상인데 필터에서 안 걸리는 현재 버그가 반복될 수 있음.

**권고**: status 값 체계를 먼저 확정하고(`pending` / `in_progress` / `done`), 프론트엔드 필터를 정규화한 후에 archived 기능을 추가할 것.

---

## Cycle 2: 종합 토론

### 아누 (진행)

Cycle 1 요약 정리:

| 논점 | 오딘 | 미미르 | 아테나 | 로키 |
|------|------|--------|--------|------|
| 데이터 구조 | archived 필드 | (UI 관점) | (UI 관점) | status 필터만으로도 가능 |
| UI 처리 | API 필터 | 접이식 섹션 (카드 내) | 상단 위젯 + 기록탭 | 최소 수정 우선 |
| 히스토리 접근 | API 쿼리 | 카드 내 펼침 | 기록 탭 | 파일 직접 열람 |
| 자동화 | (미언급) | 자동 아카이브 | 조건부 자동 | 수동 추천 |

**쟁점 3가지:**
1. 접이식 섹션(미미르) vs 상단 위젯+기록탭(아테나) vs 최소 필터(로키)
2. archived 필드(오딘) vs status 필터만(로키)
3. 자동 아카이브 vs 수동 아카이브

---

### 오딘 (반응)

로키의 "status 필터 한 줄 수정"은 MVP로 인정한다. 하지만 제이회장님의 요구는 단순히 "안 보이게"가 아니라 **"히스토리에서 다시 체크"**도 포함한다. 히스토리 접근을 위해서는 어떤 형태든 아카이브된 안건을 조회하는 API가 필요하고, 그러려면 `done`인 것과 `아카이브된 것`을 구분하는 메커니즘이 필요하다.

예를 들어 status="done"인데 아직 화면에서 확인 중인 안건과, 완전히 정리 끝난 안건을 구분할 수 없게 된다. `archived` 필드가 이 구분을 해준다.

단, 로키가 지적한 **status 정규화**에 전적으로 동의한다. 현재 `completed` vs `done` 혼란은 선행 수정해야 한다.

**수정된 제안:**
1. status 값 정규화: `pending` / `in_progress` / `done` 3종으로 확정
2. 프론트엔드 필터: `status !== 'done'` → `!archived` 기준으로 변경
3. archived 필드 추가 (default: false, 누락 시 false 취급)

---

### 미미르 (반응)

아테나의 "상단 위젯" 제안을 검토했다. 일리가 있다. 프로젝트별로 흩어진 완료 안건을 한곳에서 보는 것은 **전체 진행률 파악**에 유리하다.

하지만 두 가지를 양립할 수 있다:
- **프로젝트 카드 내 접이식**: 해당 프로젝트 맥락에서 "이 프로젝트에서 뭘 끝냈지?" 확인
- **상단 위젯**: 전체적으로 "최근 뭘 끝냈지?" 확인

다만 구현 공수 대비 ROI를 따져야 한다. 현재 13건 중 완료 1~2건. 상단 위젯까지 만드는 건 과잉 설계일 수 있다.

**양보안:**
- 1차: 프로젝트 카드에서 done 안건을 **기본 숨김** 처리 (가장 간단)
- 2차: 기록 탭에 완료 안건 섹션 추가 (기록 탭 구현 시 함께)
- 3차(선택): 상단 위젯 (안건 10건 이상 완료 시 검토)

프로젝트 카드 내 접이식은 취하한다. 생각해보니, 완료 안건이 0~1건인 프로젝트에서 "완료된 안건 0건"이 표시되면 오히려 노이즈다. 그냥 안 보이게 하는 게 낫다.

---

### 아테나 (반응)

미미르가 접이식을 취하하고 "기본 숨김"으로 선회한 것에 동의한다.

**정리하면 내 최종 제안:**
1. 프로젝트 카드: done 안건은 **표시하지 않음** (필터로 제외)
2. 기록 탭: 완료 안건 섹션 추가 (시간순 역순, 프로젝트 라벨 포함)
3. 상단 위젯: 현재 스킵 (기록 탭으로 충분)

기록 탭은 이미 3/11 미팅에서 합의되었고 구현 대기 중. 거기에 완료 안건 목록을 포함하면 추가 공수가 거의 없다.

오딘의 archived 필드 제안에 한 가지 의문: **status="done"이면 곧 아카이브 아닌가?** 별도 필드 없이 status="done"을 아카이브 조건으로 쓰면 안 되나? "done인데 아카이브 안 한" 중간 상태가 실제로 필요한가?

---

### 로키 (DA 최종 반론)

아테나가 핵심을 찔렀다. **"done이면서 비아카이브"인 상태가 실제로 존재하는가?**

시나리오를 그려보면:
1. 안건 완료 → status="done" → 제이회장님이 확인 → 아카이브
2. 이 사이 "done인데 아카이브 전" 상태가 존재

그런데 제이회장님이 "확인"하는 절차가 실제로 있나? 현재 워크플로우에서 안건 완료 시:
- 팀이 sub_items 체크
- 아누가 status를 done으로 변경
- 끝. 별도 "확인" 절차 없음.

**따라서 "done = 아카이브"로 취급해도 무방하다.**

archived 필드를 추가하면:
- 장점: "done인데 아직 보여주고 싶은" 중간 상태 지원
- 단점: 필드 1개 + 상태 매트릭스 복잡도 증가

**로키 최종 의견:**

제이회장님 요구를 가장 단순하게 만족하는 방법:

1. **프론트엔드 필터 수정** (1줄): `i.status !== 'done'` 조건 추가
2. **기록 탭에 완료 안건 표시**: API에 `?include_done=true` 파라미터 추가
3. **archived 필드: 불필요** (현재 규모에서는)

만약 향후 "done인데 잠깐 보여주고 싶다"는 요구가 생기면 그때 archived 필드를 추가해도 늦지 않다. YAGNI (You Aren't Gonna Need It).

단, status 정규화(completed → done 통일)는 반드시 선행.

---

### 종합 토론 수렴

**투표 결과:**

| 항목 | 오딘 | 미미르 | 아테나 | 로키 |
|------|------|--------|--------|------|
| archived 필드 추가 | O | - | X | X |
| status 필터 기반 (done 숨김) | - | O | O | O |
| 프로젝트 카드에서 done 숨김 | O | O | O | O |
| 기록 탭에 완료 안건 표시 | O | O | O | O |
| 자동 아카이브 | - | O | O | O |
| status 정규화 선행 | O | - | - | O |

**오딘 양보**: archived 필드는 현재 규모(13건)에서 과잉. 3:1로 패배. 다만, 안건 30건 초과 시 재검토 트리거를 합의 사항에 포함할 것을 요청.

**합의 형성**: 전원 동의.

---

## 최종 합의

### 데이터 구조
1. **archived 필드 추가하지 않음.** status="done"을 아카이브 조건으로 사용. 현재 규모에서 추가 필드는 YAGNI.
2. **status 값 정규화**: `pending` / `in_progress` / `done` 3종 확정. 프론트엔드의 `completed` 필터를 `done`으로 통일.
3. **issue-012 status 보정**: sub_items 전부 done인데 status="in_progress"인 불일치 → status="done", completed_at 기록으로 수정.

### 대시보드 UI
4. **프로젝트 카드: done 안건 기본 숨김.** 프론트엔드 필터: `i.status !== 'done'` 추가. 프로젝트 카드의 "안건 N건" 카운터도 활성 안건만 반영.
5. **기록(Archive) 탭에 완료 안건 섹션 추가.** 3/11 미팅 합의된 기록 탭 구현 시 함께 포함. 시간순 역순, 프로젝트 라벨, completed_at 표시.
6. **상단 위젯: 현재 스킵.** 완료 안건이 10건 이상 누적되면 재검토.

### 히스토리 접근
7. **기록 탭에서 열람.** 별도 API 파라미터 `?include_done=true` 추가하여 done 안건 포함 조회 가능.
8. **todo.json은 단일 파일 유지.** 아카이브 분리 파일 만들지 않음.

### 자동화
9. **status="done"이면 자동 숨김.** 별도 아카이브 버튼 없음. status 변경 시점에 자동으로 프로젝트뷰에서 사라짐.
10. **복원**: status를 "in_progress"로 되돌리면 다시 프로젝트뷰에 표시됨. 별도 unarchive 로직 불필요.

### 구현 범위
11. **server.py**: GET `/api/todo`에 `include_done` 쿼리 파라미터 추가 (기본: done 제외). 약 5줄.
12. **index.html**: ProjectView 필터 수정 1줄 (`i.status !== 'done'`). 기록 탭 완료 안건 섹션은 기록 탭 구현 태스크에 포함.
13. **todo.json**: issue-012 status 보정 (in_progress → done, completed_at 추가).
14. **예상 난이도**: Lv.1 (단순 수정)

### 트리거/경계선
15. **안건 30건 초과 시**: 데이터 구조 재검토 미팅 소집 (archived 필드 또는 DB 마이그레이션 검토).
16. **완료 안건 10건 이상 누적 시**: 프로젝트뷰 상단 "최근 완료" 위젯 추가 검토.

---

## 다음 단계

- [ ] 위 합의 사항을 제이회장님께 보고, 승인 요청
- [ ] 승인 시 Lv.1 위임 (server.py 필터 + index.html 필터 + todo.json 보정)
- [ ] 기록 탭 구현 태스크에 "완료 안건 섹션" 요건 포함시키기