LAXworkspace
알림 · 보고서
🧩

규원· LAX People Ops & 에이전트 온보딩 리드↗

온라인입력 0 (캐시 0%) · 출력 0
새 대화
세션 목록
박보검의 요청: [에이전트 슬러그 정책 변경 검토] Jason 지시: 새 에이전트 슬러그를 '이름 기반'(bogum, gyohwan 등 이름 로마자화)으로 만들지 말고 '만들어진 순서(생성 순번)'로 자동 부여하고 싶어 해. 네가 온보딩/에이전트 생성 오너니까 영향도를 봐줘: 1. 슬러그가 'agent-7'처럼 순번 기반이 되면, 너의 온보딩 절차(에이전트 설계·생성·동료 등록)에서 깨지거나 불편한 게 있어? ask_agent(to:"<slug>")로 동료를 부를 때 이름 대신 순번이라 혼란 생길 여지는? 2. 기존 에이전트(bogum/gyohwan/wooseok/ria/sukgu/jarvis)의 슬러그는 그대로 두고 신규만 순번으로 가는 게 맞지? (기존 슬러그 변경하면 voice 'jarvis'·artifacts.agent_slug·상호 roster 참조가 깨질 텐데) 3. 슬러그 자동부여 시, 사람이 수동 입력할 일이 없어지니까 생성 폼에서 슬러그 입력칸을 아예 없애도 되나? 아니면 자동값을 기본으로 두되 수정 가능하게 남길까? 4. 순번 포맷 선호: 'agent-7' / 'a7' / 그냥 '7' 중 뭐가 실무상 나아? 진행상황: 나는 LAX-site 코드(shared/agents.ts createAgent, agents/form.tsx)에서 슬러그 생성부를 이미 파악했고, 자동부여 구현은 가능해. 네 의견 받아서 Jason에게 포맷만 확정받고 바로 반영하려고 해.

코드 확인했습니다. shared/agents.ts(createAgent / validate / roster)와 agents/form.tsx 기준으로 영향도 답합니다.

핵심 사실 (코드 확인)

  • 현재 slug는 수동 입력(form.tsx name="slug", pattern=[a-z0-9-]{2,60}, required) → SLUG_RE 검증 → DB UNIQUE 제약. 생성 후 변경 불가(edit 시 readonly).
  • slug는 단순 식별자가 아니라 여러 테이블의 외래키 역할: artifacts.agent_slug, agent_activity.agent_slug, agent_memory, agent_projects 모두 LEFT JOIN agents ON a.slug = ...로 묶임. voice jarvis도 slug 참조.
  • ask_agent 로스터(bridge/routes.ts:174)는 - {이름} (slug: {slug}) — {역할} 형식으로 이름과 slug를 항상 같이 보여줌.

질문별 답

1. 순번 슬러그가 온보딩 절차를 깨뜨리나?
설계·등재 절차 자체는 안 깨집니다. 충돌도 더 안전해져요(이름 로마자화는 동명이인·표기 흔들림 위험이 있지만 순번은 MAX+1로 끝). 다만 호명 인지비용이 생깁니다. 에이전트가 ask_agent(to:"agent-7")를 부르려면 매번 로스터에서 이름→번호를 역매핑해야 함. 로스터가 이름을 같이 노출하니 치명적이진 않지만, 사람이 /agents URL(/agents/agent-7)이나 로그를 볼 때 누군지 즉시 안 떠오릅니다. → 수용 가능하되, 번호는 절대 재사용 금지(은퇴 에이전트의 번호를 비우고 계속 증가). 재사용하면 artifacts·activity 과거 기록이 엉뚱한 사람에게 붙습니다.

2. 기존은 그대로, 신규만 순번 — 맞나?
맞습니다. 기존 slug 변경 금지가 정답입니다. bogum/gyohwan/wooseok/ria/sukgu/jarvis를 바꾸면 voice(jarvis)·artifacts·activity·memory·상호 로스터 참조가 전부 끊깁니다(코드상 slug 기반 조인). 마이그레이션 비용 대비 이득 없음. → 하이브리드 확정(레거시=이름, 신규=순번). 부작용은 로스터에 이름slug와 번호slug가 섞이는 정도인데, 로스터가 이름을 함께 표기하므로 실무상 문제없습니다.

3. 폼의 slug 입력칸을 없앨까?
완전 제거는 비추, "자동값 기본 + 선택적 수정 가능"을 권합니다. 이유: slug는 영구·식별성 자산인데 순수 번호는 위 1번 인지비용이 있습니다. 평소엔 자동 순번으로 손 안 대게 하되, 핵심 상시 역할(예: 의뢰처 담당 같은)에는 사람이 읽히는 slug를 줄 여지를 남기는 게 운영상 유연합니다. 구현: 입력칸 유지하되 placeholder를 자동 생성값으로 prefill, 비워두면 순번 자동 부여. (단순화를 원하면 readonly 자동값으로 가도 동작엔 문제없음 — 결정은 Jason 취향.)

4. 포맷: agent-7 권장.

  • 7 단독 → SLUG_RE가 2~60자라 1자리(7)는 검증 실패. 식별자로도 모호.
  • a7 → 너무 짧고 사람 이니셜과 혼동.
  • agent-7 → 네임스페이스 있어 정렬·검색·URL 가독성 최선이고 기존 패턴([a-z0-9-]) 그대로 통과.

Jason에게 올릴 확정 요청 (2개만)

  1. 포맷 agent-N 채택 여부.
  2. 폼: 자동값 수정 가능으로 둘지 / readonly 고정으로 둘지.

다음 액션:

  • Jason에게 위 2개(포맷 agent-N + 폼 수정가능 여부)만 올려 확정받기.
  • 확정 후 변우석 또는 손석구에게 구현 위임 — 번호 부여는 전 상태(은퇴 포함) 통틀어 MAX(N)+1, 재사용 금지 규칙 명시.
  • 기존 6개 slug는 동결(변경 금지)임을 온보딩 절차 문서에 1줄 추가.