상담원 등록 정식 경로 — 동명이인 · 이름만으로 만들어지는 계정

무엇을

decisions/406(09-21)으로 상담원 토큰 발급이 이름만 받아 없으면 그 자리에서 만든다. 그 결정이 스스로 남긴 둘을 닫는다 — 동명이인과 정식 등록 경로.

왜

406 은 「agent 테이블에 상담원을 만들 방법이 아예 없어 이름 입력이 전부 404」이던 것을 푼 응급 처치다. 지금은 같은 이름이면 같은 사람으로 본다 — 김민수가 둘이면 토큰·블랙리스트 요청·요약 확정 기록이 한 사람으로 섞인다. 시연 규모에서는 안 나지만, 「누가 확정했는가」가 기록의 근거(decisions/310·311)라 발표에서 물으면 답이 있어야 한다.

09-21 에 남긴 확인도 여기서

• 브라우저 실확인 — 토큰 발급 → 관리자 화면 표시 → 대기화면에 display_name
• Postgres 통합 테스트 1건(로컬 DB 가 없어 미실행)

완료 조건

• 동명이인을 가르는 방법(사번 등)을 정하거나, 「이름이 곧 식별자다 — 시연 범위의 한계」를 결정 기록에 명시한다
• 위 두 확인을 돌리고 결과를 남긴다

2026-09-23 — 결정 (조서희)

decisions/409로 「이름이 곧 식별자다 — 시연 범위의 한계」를 정식 확정했다. 406이 이미 “동명이인은 테스트 단계라 감수한다”고 적어 뒀던 것을, 정식 등록 경로(사번 등)는 만들지 않는다는 것까지 포함해 확정했다 — 되돌리기는 열어 뒀다(agent_id를 직접 지정하는 경로가 이미 있어 필요해지면 바로 확장 가능).

덤으로 확인 — 406이 남긴 다른 한계(“J-5 베테랑 배정에는 이 경로로 만든 상담원을 쓸 수 없다”)는 이미 풀려 있었다. 오늘 이 세션의 w6-admin-agent-hired-on-ui로 어떤 상담원이든 관리자 화면에서 입사일을 나중에 채울 수 있게 됐다.

남은 확인 둘(브라우저 실확인·Postgres 통합 테스트)은 이번에도 못 했다 — 이 세션엔 브라우저도 로컬 Docker/Postgres도 없다. 코드 변경이 없는 결정 기록 티켓이라 그 자체로 done으로 올리지만, 이 두 확인은 실제 환경에서 누군가 한 번은 해야 한다.