프롬프팅에서 워크플로로, AI로 프런트엔드 개발 생산성 끌어올리기

3 hours ago 2

코딩 속도는 더 이상 가장 큰 병목이 아닙니다. 이제 병목은 입력이 여러 곳에 흩어져 있다는 점과 그것들을 하나로 엮는데 드는 비용입니다.

하나의 기능을 구현하려면 여러 시스템을 오가야 합니다. 요구 사항은 Jira에, 디자인은 Figma에, 문서는 Confluence에, 세부 확인 사항은 Slack에, 구현은 Git에 있습니다. 프런트엔드 개발자는 이 모든 입력이 한곳으로 모이는 지점에 있습니다. 사양, 디자인, 요구 사항, 계획을 모아 사용자가 실제로 사용할 수 있는 결과물로 조립하는 일이 프런트엔드 개발자의 역할입니다.

오랫동안 프런트엔드의 업무 부담은 정보를 흡수하고 종합하는 능력에 크게 의존해 왔습니다. 티켓을 읽고, 디자인 파일을 확인하고, 에지 케이스를 명확히 하고, 제품 및 백엔드 팀과 지속적으로 동기화해 최종 결과물이 기대에 부합하도록 만드는 것입니다.

이제 이러한 컨텍스트 전환과 여러 수작업을 LLM(large language model)의 도움을 받아 자동화할 수 있게 됐습니다. 이에 따라 코딩 자체는 LLM이 더 많이 담당하게 되면서 프런트엔드 개발은 점점 코딩의 문제가 아니라 오케스트레이션의 문제가 되고 있습니다.

변화: 프롬프팅에서 워크플로로

AI를 사용할 때 가장 먼저 떠오르는 방식은 영리한 프롬프트를 작성하고 결과를 기대하는 것입니다. 그런데 이 방식은 한 번은 통할 수 있지만, 누적 효과로 연결되지는 않습니다.

반면 워크플로는 다릅니다. 워크플로는 입력에서 출력까지 이어지는 반복 가능한 경로입니다. 작업이 이미 존재하는 시스템(Jira, Confluence, Slack, 코드)에서 컨텍스트를 수집하고, 실제로 요청된 내용을 요약하며, 불명확한 부분을 드러낸 다음 구현 계획을 제안합니다. 그리고 코드에 손대기 전에 사람이 검토하기를 기다립니다.

AI는 워크플로를 실행하는 엔진입니다.

LY Corporation에는 이미 여러 훌륭한 팀이 구축한 강력한 내부 생태계가 있습니다. Jira, Confluence, Slack, GitHub과 같은 도구를 연결한 Noah MCP가 그 한 예입니다. Noah MCP는 매일 하나씩 고립된 장소에 방문해서 접근해야 했던 데이터를 AI 에이전트가 읽고, 추론하고, 행동할 수 있는 연결된 입력으로 변환했습니다. 이는 AI가 더 이상 사람이 수동으로 프롬프트에 붙여넣은 컨텍스트에 제한되지 않고 일상 워크플로 안에 존재하는 실제 컨텍스트를 활용할 수 있다는 것을 의미합니다.

한 번 구축한 워크플로는 모든 티켓에 적용할 수 있습니다. 입력은 바뀌지만 패턴은 동일합니다. 이것이 확장성을 만드는 핵심입니다.

워크플로 전체 모습

워크플로를 구체적으로 살펴보겠습니다. Jira 티켓이 하나 있다고 가정하겠습니다. 이 Jira 티켓에는 검색, 필터, 정렬, 역할 기반 필터 표시 제어가 있는 목록 페이지를 구현해 달라는 요청이 담겨 있습니다.

기존 방식에서는 다음과 같이 작업을 진행합니다.

티켓을 열고 두 번 읽습니다. 정렬/필터/검색은 적혀 있지만, 필터 상태를 새로고침 후에도 유지해야 하는지, 공유 가능한 형태여야 하는지에 대한 내용은 없습니다.
Figma를 엽니다. 목록의 빈 상태 / 로딩 상태 / 결과 없음 상태와 필터 패널을 찾습니다.
Confluence에서 해당 기능을 검색합니다. 어떤 역할에 어떤 필터가 표시되는지 정의한 필터 규칙 문서를 찾습니다.
Slack을 검색합니다. 수백 개의 메시지가 있을 수 있으며, 지난달 다른 팀이 합의한 스레드를 발견하거나 기획자가 최종 결정하지 않았다는 사실을 알게 될 수 있습니다.
코드베이스를 엽니다. 다른 기능에 이미 useTableFilters 및 useUrlState 훅이 존재한다는 것을 확인합니다. 새로 만들 것이 아니라 재사용해야 합니다.
노트 파일을 열고 각 소스에서 조각들을 복사해 붙여넣기 시작합니다. 일관된 계획으로 조립하려고 합니다.
개발 중에는 코드를 실행하고 온갖 버그와 가능한 모든 에지 케이스를 해결해야 합니다. 타입 문제, 린트 규칙, 코딩 컨벤션도 맞춰야 합니다.
마지막으로 저장소에 PR(pull request)을 제출합니다.

새로운 방식에서는 다음과 같이 작업을 진행합니다.

먼저 워크플로를 실행합니다.

- Read Jira ticket FE-1234. - Find related Confluence docs on filter rules and role-based visibility. - Search Slack for recent decisions on this list page or filter behavior. - Look for similar list/filter implementations in the codebase. Do not modify code yet. Return: requirement summary, frontend impact, files involved, implementation checklist, test checklist, open questions.

몇 분 후 에이전트가 다음과 같은 결과를 반환합니다.

## Requirement summary Build a list page for the <Feature> module with search, filter, and sort. Integrates with the existing GET /api/<feature> endpoint (already paginated). Filter set depends on the current user's role. ## Frontend impact - New `<FeatureListPage />` route + container - New `<FeatureList />` component reusing existing table primitives - Search / filter / sort UI wired to the shared filter hook - State sync: filter + sort + page must round-trip through the URL ## Files likely involved - src/features/<feature>/FeatureListPage.tsx ← new route - src/features/<feature>/FeatureList.tsx ← new - src/hooks/useTableFilters.ts ← reuse - src/hooks/useUrlState.ts ← reuse - src/components/ui/SearchInput.tsx ← reuse - src/components/ui/FilterPanel.tsx ← reuse - src/api/<feature>.ts ← already exists ## Role-based filter visibility (from Confluence: "<Feature> Access Matrix", updated 2026-04) - viewer → search, status filter, date range - editor → + owner filter - admin → + internal-only flags ## Implementation checklist - [ ] Add route and page container - [ ] Wire search / filter / sort to useTableFilters + useUrlState - [ ] Gate admin-only filters behind useCurrentUserRole() - [ ] Empty / loading / no-results states per Figma ## Test checklist - [ ] Filters round-trip through URL params (reload preserves state) - [ ] Shareable URL renders the same filtered view for another user - [ ] Role-based filters are hidden for lower-privilege users - [ ] No-results state renders correctly ## Open questions 1. Filter and sort state: store in URL params or localStorage? (Slack thread 2026-04-12 in #frontend-platform suggests URL params for shareability) 2. Should the empty state offer a "clear filters" CTA, or just "no results"? (Figma shows both variants without indicating which is final.)

위 내용이 에이전트가 작성한 계획입니다. 이 계획을 보면 즉시 눈에 띄는 점이 세 가지 있습니다.

Slack 스레드에 숨겨져 있던 요구 사항이 드러났습니다. 필터 상태는 localStorage가 아니라 URL에 있어야 합니다. 이 내용이 PR 리뷰 단계에서야 드러났다면 구현 중간에 재작업이 필요했을 가능성이 큽니다.
재사용 가능한 기존 훅 두 개(useTableFilters, useUrlState)가 확인됐습니다. 덕분에 이 두 개는 새로 만들 필요가 없습니다.
코드를 작성하기 전에 해결할 필요가 있는 두 가지 미해결 질문이 드러났습니다.

계획을 확인하고 미해결 질문을 정리하고나면 코드 에이전트가 보다 더 강한 확신을 갖고 구현을 시작할 수 있습니다. 그 결과 매우 높은 품질의 작업물이 나옵니다.

여기서 기능 구현에서 멈추면 안 됩니다. 전체 워크플로는 코딩 이후의 후속 작업도 포함해야 합니다. 강력한 워크플로에는 닫힌 루프(closed-loop) 형태의 개발 사이클이 필요합니다. 코딩 에이전트가 첫 구현을 마치면, 다음 단계는 에이전트가 자신의 작업을 원래 계획과 대조해 검증하도록 만듭니다. 같은 워크플로가 계속 이어집니다. 에이전트는 원래 계획을 바탕으로 검증 루프를 만들 수 있습니다.

Implementation is done. Now verify the work against the original plan. Run: - typecheck - lint - related unit tests - relevant smoke test or local verification flow Then return: - what passed - what failed and was fixed - what could not be verified automatically - screenshots or notes for UI states - remaining risks before PR

이 지점에서 LLM이 특히 유용합니다. 프런트엔드 유지 보수 작업의 대부분은 개념적으로 어렵지는 않지만 시간이 많이 들며, 바쁠 때 건너뛰기 쉬운 작업입니다. 예를 들어TypeScript 오류 수정, 테스트 목(mock) 조정, 린트 규칙 준수, 에지 상태 확인, 스냅숏 업데이트, 구현이 코드베이스의 기존 컨벤션을 따르는지 확인하는 작업 등이 여기에 해당합니다.

다음은 출력 예시입니다.

## Verification summary Typecheck: passed Lint: passed Unit tests: passed Smoke test: partially verified locally ## Tests added / updated - Added tests for URL state persistence when filters change - Added tests for role-based filter visibility - Updated no-results state test to match the Figma copy ## Smoke test result Verified manually in local environment: - Search updates the URL query params - Refresh preserves search / filter / sort state - Viewer role cannot see owner or internal-only filters - Admin role can see all filters - Empty state renders correctly when the API returns no rows ## Issues found and fixed 1. Filter state was reset when changing page number Fixed by preserving existing URL params inside `useTableFilters`. 2. Admin-only filter was hidden on first render because user role loaded async Fixed by rendering the filter panel only after role resolution. 3. No-results state used the generic empty text instead of the Figma-specific copy Fixed by reusing the correct translation key. ## Could not verify automatically - Shareable URL behavior for another user role requires a real account with different permissions. - Final empty-state CTA decision still depends on PM / Design confirmation. ## Remaining risk before PR The implementation follows the current Confluence access matrix, but if the role rules change before release, the filter visibility logic needs to be updated.

이렇게 하면 에이전트를 단순한 코드 생성기에서 구현·실행·실패·수정·검증·보고라는 지루하지만 중요한 루프를 완성할 수 있는 개발 파트너로 바꿀 수 있습니다.

여기서 코드 에이전트가 애플리케이션을 실행하거나, 안전한 환경에서 실제 API를 호출하거나, Playwright 스모크 테스트를 실행할 수 있게 만들면 훨씬 더 안정적인 결과를 만들 수 있습니다. 에이전트는 단지 코드를 작성하는 것뿐만 아니라 스스로 결과를 확인할 수 있어야 합니다.

예를 들어 다음과 같이 지시할 수 있습니다.

Run the local app and smoke test the feature. Check: - loading state - empty state - search - filter - sort - pagination - URL refresh behavior - role-based visibility Do not create a PR yet. Return screenshots, failed cases, and suggested fixes.

이것이 워크플로의 진정한 가치입니다. 계획 단계에서 수집한 동일한 컨텍스트가 구현, 테스트, 디버깅 및 인수 인계 단계에서도 재사용됩니다. 에이전트는 매 단계마다 요구 사항을 다시 발견할 필요가 없습니다. 원래 계획과 현재 작업을 계속 비교할 수 있습니다.

검증 루프가 충분히 깔끔해지면 마지막 단계는 인수인계입니다. 에이전트는 이미 전체 컨텍스트를 갖고 있습니다.

티켓 요구 사항
변경된 파일 목록
Jira, Confluence, Slack 또는 Figma에서 결정된 사항들
추가된 테스트들
통과한 검사 항목
리뷰어가 주의해야 할 리스크

따라서 팀 컨벤션에 맞춘 PR을 준비할 수 있습니다.

Prepare the PR. Read the project PR template and recent merged PRs in this area. Summarize the change using the team convention. Link the Jira ticket. Include test evidence. Call out remaining risks or manual verification notes. Do not hide unresolved questions.

PR 설명은 일반적이어서는 안 됩니다. 전체 워크플로의 최종 요약이어야 합니다.

## Summary Implemented `<Feature>` list page with search, filters, sorting, pagination, and role-based filter visibility. ## Key behavior - Search / filter / sort state is synced to URL params - Viewer, editor, and admin roles see different filter sets based on the access matrix - Empty, loading, and no-results states follow Figma - Existing `useTableFilters` and `useUrlState` hooks are reused ## Verification - Typecheck: passed - Lint: passed - Unit tests: passed - Local smoke test: completed ## Notes for reviewers - URL state behavior follows the Slack decision from 2026-04-12 - Empty-state CTA still needs final Design confirmation - Shareable URL behavior across different user roles requires staging verification

이렇게 닫힌 루프 워크플로가 완성됩니다. 컨텍스트는 전체 개발 사이클을 따라 이동합니다. 계획은 잘못된 구현을 방지합니다. 테스트는 불안정한 구현을 방지합니다. 스모크 테스트는 이론상으로만 작동하는 구현을 걸러냅니다. PR 인수인계는 리뷰어가 흩어진 커밋에서 전체 이야기를 재구성해야 하는 수고를 줄여줍니다.

Gather context → Return plan → Resolve open questions → Implement → Run checks → Fix failures → Smoke test → Summarize verification → Prepare PR

이 마법을 어떻게 구현할 수 있을까?

작업을 시작하기 위해 워크플로 라이브러리가 필요하지는 않습니다. 필요한 것은 좋은 프롬프팅 규율과 검증된 MCP 설정입니다.

1. 최초 한 번, 에이전트가 도구에 접근할 수 있는지 확인

다음 명령어로 에이전트가 도구에 접근할 수 있는지 최초에 한 번 확인하세요.

claude mcp list # or codex mcp list

저희 회사의 경우 예상 목록은 다음과 같습니다.

jira confluence slack github figma

만약 가능하다면 다음 항목도 살펴보시기를 권장합니다.

design.md playwright

필요하다면 다음 문서를 참고해 주세요.

Claude Code MCP 설정
Codex CLI MCP 설정
Design.md(코딩 에이전트에게 시각적 아이덴티티를 설명하는 문서)

2. 각 도구의 역할 확인

저희 회사 기준으로 각 도구의 역할은 다음과 같습니다.

도구에이전트가 읽는 내용에이전트가 할 수 있는 작업

Jira	티켓 범위, 수용 기준, 링크된 이슈, 하위 작업, 댓글, 커스텀 필드	팀의 표준 설명 형식을 따라 계획 문서에서 티켓 생성 진행 상황을 댓글로 남기기 상태 전환, 에픽으로 링크
Confluence	장기적인 비즈니스 규칙(권한, 상태 정의, 에지 케이스, 접근 행렬, 디자인 사양)	스페이스 전체 검색 긴 페이지에서 특정 섹션 추출 여러 문서를 현재 티켓에 관련된 비즈니스 규칙으로 요약
Slack	티켓에 반영되지 않은 최근 결정 및 확인 사항, 디자인 관련 대화, API 제한 변경, PM 확인 사항	키워드로 스레드 검색 확정된 결정과 아직 미해결된 질문 구분 검증할 수 있도록 채널 + 날짜와 함께 메시지 인용
GitHub	동일 영역의 이전 PR, 브랜치 히스토리, 프로젝트 커밋 컨벤션, PR 템플릿, CI 상태	린트 실행 및 자동 수정 적용 컨벤션에 따라 변경 사항을 커밋으로 그룹화 팀 템플릿을 바탕으로 PR 설명 초안 작성, 티켓에 링크된 PR 초안 생성
Figma	컴포넌트 사양 및 변형, 디자인 토큰, 레이아웃 세부사항, 화면 상태(빈 상태 / 로딩 / 에러 / 호버 / 포커스), 접근성 주석.	프레임에서 컴포넌트 스캐폴드 생성 디자인 토큰을 코드로 추출 Code Connect를 통해 Figma 컴포넌트를 기존 코드 컴포넌트와 매핑 티켓이 놓친 디자인 상태 드러내기

3. '플랜 모드'를 사용해 실제 티켓에서 워크플로 실행

Claude Code를 사용하고 있다면 실행 전에 플랜 모드(/plan)를 켭니다. 플랜 모드는 ‘코드를 아직 수정하지 마세요’라는 규칙을 구조적으로 강제합니다. 에이전트는 검색하고, 읽고, 계획을 세울 수 있지만 사람이 명시적으로 승인하기 전에는 파일을 수정할 수 없습니다. ‘코드를 아직 수정하지 마세요’라는 단순한 문장형 지시를 실제로 강제되는 보증으로 바꿔 주는 것입니다. 다른 코딩 에이전트 도구를 사용한다면 Claude Code의 플랜 모드와 동일한 역할을 하는 기능을 사용하세요.

4. 코드 수정 전 출력물 검토

특히 ‘Open questions’ 섹션을 확인하세요. 에이전트가 우리가 놓친 좋은 질문을 하나만 찾아내도 그 워크플로는 이미 비용을 회수한 것입니다.

5. 닫힌 루프 개발 준비

코드베이스 안에 LLM이 읽고 따를 수 있는 코드 컨벤션을 마련하세요. SKILL.md 또는 Custom Slash Commands가 이를 관리하기에 가장 좋은 장소입니다. 또한 어떤 작업이든 항상 테스트 스위트와 함께 진행해야 합니다.

6. 최종 검토 및 인수인계 준비

인수인계 조건은 계획에 있는 모든 항목을 만족해야 하며, PR 및 Git 관리 방식에서 팀 컨벤션에 부합해야 합니다. 잘 정의된 컨벤션과 템플릿이 중요합니다.

왜 이 방식이 작동하는가? 실행하기 전에 이해하기

이 워크플로가 유용한 출력을 만드는 이유는 프롬프트 자체가 아니라 순서 때문입니다. 에이전트는 코드를 변경하도록 허용받기 전에 컨텍스트를 수집하고, 요약하고, 질문합니다. 이 순서가 워크플로와 초보적인 프롬프팅을 구분합니다.

이 방식을 지탱하는 요소는 다음 세 가지입니다.

명확한 컨텍스트: 에이전트는 어디를 찾아야 하는지(Jira, Confluence, Slack, 코드)와 무엇을 반환해야 하는지(위 프롬프트의 여섯 가지 항목)를 알고 있습니다. 모호한 지시는 모호한 결과를 낳습니다.
경계 설정: ‘아직 코드를 수정하지 마세요’라는 한 줄이 AI가 너무 많이 해버리는 실패를 대부분 막아줍니다. Claude Code에서는 플랜 모드가 이를 구조적으로 강제하기 때문에 사람이 승인하기 전까지 에이전트는 파일을 쓸 수 없습니다. 에이전트는 자신이 무엇을 변경할 수 있고 무엇을 살펴보기만 해야 하는지 알아야 합니다.
구조화된 출력: 고정된 패턴은 결과를 검토하기 쉽게 만듭니다. 요약, 파일 목록, 체크리스트, 테스트, 미해결 질문이 항상 같은 순서로 나타나야 합니다. 이렇게 하면 출력을 빠르게 훑어보고 누락된 컨텍스트를 잡아내며, 다음 단계를 승인하기 전에 계획을 요구 사항과 비교할 수 있습니다.

프런트엔드 작업에서 대부분의 실수는 문법 실수가 아니라 맥락 실수입니다. 컴포넌트가 컴파일되고 UI가 렌더링되며 테스트도 통과하지만 잘못 작동하는 경우가 있습니다. 이는 에이전트가 비즈니스 규칙을 놓쳤거나 디자인 제약을 무시했거나 사용자 흐름을 잘못 이해했기 때문입니다. 실행 전에 이해를 강제하는 것이 이러한 문제를 가장 효과적으로 빠르게 발견하는 방법입니다.

따라서 프런트엔드 개발에서 다음으로 중요해질 역량은 워크플로를 어떻게 구성할지 깊이 이해하는 능력입니다. 단일 프롬프트는 특정 한 작업에서만 도움이 되지만, 워크플로는 해야 할 일의 전체 맥락을 포착하는 데 도움을 줍니다.

무엇이 잘못될 수 있는가?

AI 워크플로는 실제로 큰 레버리지를 제공하지만 주의하지 않으면 쉽게 복잡해지고 통제하기 어려워질 수 있습니다. 아직 어떻게 적용해야 하는지 완전히 이해하지 못한 상태에서 흔히 저지르는 실수는 다음과 같습니다.

확신에 찬 출력을 과도하게 신뢰하기

에이전트가 적절한 도구에 접근할 수 있더라도 요구 사항을 오해하거나 에지 케이스를 놓치거나 잘못된 가정을 할 수 있습니다. 특히 출력에 자신감이 넘칠 때가 위험한 순간입니다. 깔끔한 구현이 항상 올바른 구현을 의미하지는 않습니다. 주도권은 항상 개발자가 갖고 있어야 합니다. 이해 부채(comprehension debt)를 너무 많이 쌓지 마세요.

한 번에 모든 것을 자동화하려고 시도하기

티켓을 읽고, 모든 시스템을 검색하고, 코드를 수정하고, 테스트를 작성하고, PR을 만들고, Slack에 업데이트를 게시하는 하나의 큰 워크플로를 만들고 싶어질 수 있습니다. 하지만 큰 워크플로는 통제하기 어렵고, 문제가 생겼을 때 어느 단계에서 실패했는지 파악하기가 어려워집니다. 기본 원칙은 읽기와 쓰기 작업을 분리하는 것입니다. 계획 먼저 하고 그다음 실행하세요.

AI는 제약이 있을 때 가장 잘 작동한다는 사실을 잊기

제약이 없으면 에이전트는 너무 많은 것을 변경하거나 잘못된 패턴을 사용하거나 기존 아키텍처와 맞지 않는 코드를 만들 수 있습니다. 경계를 구체적으로 정할수록 실행이 더 안전해집니다. 가장 효과적인 워크플로는 가장 자동화된 워크플로가 아닙니다. 반복 가능하고 검토 가능하며 팀의 기존 작업 방식에 부합하는 워크플로입니다.

워크플로 적용 및 확장 사례 소개

계획에서 PR로

그럼 이제 워크플로를 이용해 Jira 티켓에서 PR까지 생성해 보겠습니다. 다음은 워크플로를 작동시키는 프롬프트 예시입니다.

- Read Jira ticket EXP-4513. - Find related Confluence docs on filter rules and role-based visibility. - Search Slack for recent decisions on this list page or filter behavior. - Look for similar list/filter implementations in the codebase. Do not modify code yet. Return: requirement summary, frontend impact, files involved, implementation checklist, test checklist, open questions.

다음은 출력 예시입니다.

EXP-4513: Improve 'Live schedule' item - Requirements Analysis (Final) 1. Requirement Summary Goal: Clarify the "Live schedule" field purpose based on live type to reduce user confusion. Key Changes: 1. Create/Edit Live Video Form: - Live stream: Hide the "Live schedule" field entirely - Pre-recorded video: Show "Live schedule" with updated description text - Update description: "Schedule a time for your pre-recorded video. It will start automatically at the scheduled time and can also be started manually." 2. Live Board Page: - Live stream: Hide "Scheduled date" label and date in "Release" section for scheduled status - Pre-recorded video: Show "Release" tab with scheduled date - Only display scheduled date for pre-recorded videos; live stream shows live date only after going on-air 3. Live Videos List Page: - Rename column from "Live date" to "Live status & Live date" - Add info icon tooltip with explanations: - Title: "Live date" - Scheduled: "Scheduled time (Pre-recorded only)" - On-air: "Actual live start time ~" - Finished: "Actual live start time ~ end time" - Hide scheduled dates for live stream broadcasts in Scheduled status Frontend Impact Behavior Changes: - Conditional rendering based on broadcastType - Scheduled date visibility rules differ by broadcast type and status - UI text updates across 3 main areas Data Requirements: - broadcastType field must be available in all contexts - scheduledLiveStartTime field - broadcastStatus field - No new backend fields required UX Improvements: - Clearer distinction between live stream and pre-recorded behavior - Reduced confusion about when scheduled dates apply - Better information architecture with tooltip guidance Files Involved Components to Modify: 1. Create/Edit Live Video Form: - <project-root>/src/components/createEditLiveVideo/form/basicInformation/BasicInformationForm.tsx - Conditional rendering of Live schedule field 2. Live Board Page: - <project-root>/src/components/liveBoard/LiveBoardInformation/LiveBoardInformation.tsx - Release section rendering logic - Schedule date rendering function ... ... ... Implementation Checklist Phase 1: Pull Latest Translations - Run the project translation sync command - Verify required translation keys are available in message files - If keys are missing, coordinate with design/PM team Phase 2: Basic Information Form - Add conditional rendering for Live schedule field based on broadcastType - Show Live schedule only for pre-recorded videos ... ... ... Unit Tests Create/Edit form shows or hides schedule field based on broadcastType Date display logic returns empty string for Live stream + Scheduled Date display logic returns scheduledLiveStartTime for Pre-recorded + Scheduled Tooltip content renders with correct translation keys Integration Tests Scenario 1: Create Live Stream Live schedule field is not visible Can create without setting schedule Validation for schedule is skipped Live Board Release section shows no scheduled date when status is Scheduled List view shows blank date cell when status is Scheduled After going On-air, date appears as actual live start time Scenario 2: Create Pre-recorded Video ... ... ... Browser/Device Tests Chrome desktop Firefox desktop Safari desktop Mobile responsive layout Tooltip positioning correct on all screen sizes Table column width adjusts properly with new header Accessibility Tests Tooltip accessible via keyboard Screen reader announces column header text Info icon has proper aria-label Blank date cells do not cause screen reader issues Open Questions Existing Scheduled Live Streams:What happens to live stream broadcasts that already have scheduledLiveStartTime in the database? Recommended approach: hide the date per new spec Alternative: show with a deprecation notice API Validation:Does the backend still accept scheduledLiveStartTime for live stream broadcasts? If yes: add frontend validation to prevent it If no: rely on backend validation ... ... ...

이후 구현이 완료되면 같은 형태의 워크플로로 PR을 생성할 수 있습니다.

From the code changes, - reads the project's commit convention and PR template - groups them into commits - opens a draft PR linked back to the ticket

다음은 출력 예시입니다.

⏺ Bash(git add . && git commit -m "EXP-4513: Improve 'Live schedule' item ") ⎿ > example @1.2.0 pre-commit Searched for 1 pattern, called github (ctrl+o to expand) ... ⏺ PR created: https://githum.com/org-example/example-project/pull/900 - Committed as EXP-4513: Improve 'Live schedule' item . - Opened PR #900 against release/v1.2.0.

Slack 스레드에서 계획으로

컨텍스트를 수집하고, 계획을 반환하고, 검토하고, 코드를 작성하는 기본 루프가 안정적으로 작동하기 시작하면 워크플로 패턴을 확장할 수 있습니다. 예를 들어 어떤 기능의 단일 진실 공급원(source of truth)이 Jira 티켓이나 Confluence 페이지가 아닐 수 있습니다. 대신 2주 동안 PM, 디자이너, 백엔드, QA 등 이해관계자가 모두 참여해 150개 이상의 메시지가 오간 Slack 스레드일 수 있습니다. 이런 상황에서는 티켓이 내게 할당됐을 때 어떤 결정이 최종인지, 어떤 제안이 폐기됐는지, 어떤 질문이 답변되지 않았는지 아무도 기억하지 못할 수 있습니다.

이를 동일한 형태의 워크플로로 처리할 수 있습니다. 직접 30분 동안 스크롤을 되짚는 대신 에이전트에게 해당 스레드를 지정하고 이전과 동일한 경계(‘아직 코드를 수정하지 마세요’)를 부여한 뒤 구조화된 계획을 반환하도록 요청하세요.

- Read Slack thread <link> in #live-platform from 2026-05-01 onwards (~180 messages, 9 participants). - Cross-reference with Jira ticket GLPEX-4720 and any Figma frames linked in the thread. - Look for similar implementations in the codebase. Do not modify code yet. Return: thread summary, confirmed decisions (with message timestamps), rejected proposals, open questions, files likely involved, suggested implementation plan.

다음은 예시 출력입니다.

## Thread summary Slack #example-project, 2026-05-01 → 2026-05-14, 184 messages, 9 participants. Topic: rollout of "scheduled go-live reminders" for the Live module. Started as a PM proposal, expanded into design / backend / frontend negotiation. ## Confirmed decisions (with message timestamps so you can verify) - 2026-05-03 @taro.pm Reminders fire at 10 / 5 / 1 min before scheduled start. Reconfirmed 2026-05-09. - 2026-05-06 @yuki.design Use the existing toast component, not a modal. Figma frame linked. - 2026-05-08 @minho.be Backend exposes `scheduledLiveStartTime` on /live/upcoming. No new endpoint. - 2026-05-12 @taro.pm Pre-recorded videos only. Live streams excluded from v1. ## Rejected proposals (kept here so they don't resurface in review) - Push notifications via APNs rejected 2026-05-04 - out of scope for v1 - Separate "Reminders" tab in nav rejected 2026-05-07 - duplicates schedule view ## Open questions still unresolved in the thread 1. Timezone: viewer's local tz vs broadcaster's tz? Last touched 2026-05-10 by @yuki.design as a question, never answered. 2. Dismiss behavior: does dismissing the 10-min reminder also suppress the 5-min and 1-min? Mentioned twice, no decision recorded. 3. Reload behavior: should a dismissed reminder come back after page refresh? ## Files likely involved - src/features/live/hooks/useUpcomingLiveReminders.ts ← new - src/features/live/components/LiveReminderToast.tsx ← new - src/components/ui/ToastStack.tsx ← reuse - src/api/live.ts ← extend with /live/upcoming ## Suggested implementation plan (gated on the 3 open questions above) - [ ] `useUpcomingLiveReminders(broadcastId)` hook subscribes to /live/upcoming on mount - [ ] Schedule the 10 / 5 / 1 min reminders client-side, reuse <ToastStack /> - [ ] Dismiss state in sessionStorage (until Q3 is resolved) - [ ] Gate the feature behind `broadcastType === 'pre-recorded'` ## Recommended next action Don't start coding yet. Post the 3 open questions back into the thread, tag @taro.pm and @yuki.design, and wait for explicit answers. The thread does not contain them - re-reading won't help.

입력이 184개의 시끄러운 메시지였는데도 이 방법이 잘 작동하는 이유는 다음 두 가지 때문입니다.

결정된 사항과 아직 논쟁 중인 사항을 분리합니다. 스레드는 너무 길어서 새로 참여한 사람이 매번 다시 읽기 어렵습니다. 에이전트는 이를 한 번 정리한 뒤 어떤 줄이든 10초 안에 검증할 수 있도록 타임스탬프를 인용해 놓습니다.
답을 지어내지 않습니다. 스레드에서 결론이 나지 않은 부분은 에이전트가 그대로 표시해서 사람에게 되돌려 줍니다. 그럴듯한 추측으로 3주 후 버그가 되게 하지 않습니다.

이 패턴은 앞서 ‘플랜에서 PR로’에서 살펴본 패턴과 동일합니다. 먼저 읽고, 그다음 구조화하고, 누락된 항목을 드러내지만, 아직 코드는 수정하지 않습니다. 입력 소스만 단일 티켓에서 장기간 여러 이해관계자가 참여한 Slack 스레드로 바뀌었을 뿐입니다. 이것이 워크플로의 핵심입니다. 입력은 바뀌어도 패턴은 동일합니다.