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

코딩 속도보다 더 큰 병목은 Jira, Figma, Confluence, Slack, Git 등에 흩어진 정보를 모으고 조정하는 비용입니다. 글은 LLM을 단발성 프롬프트 도구가 아니라 반복 가능한 개발 워크플로의 실행 엔진으로 활용해야 한다고 주장합니다. 이를 통해 구현 전 요구 사항을 통합하고, 불확실성을 드러내며, 구현 후 검증까지 자동화하는 오케스트레이션 중심의 프런트엔드 개발이 가능해집니다.

프런트엔드 개발의 병목 변화

• 하나의 기능을 구현하려면 여러 시스템을 오가야 합니다.
  • 요구 사항: Jira
  • 디자인: Figma
  • 기술·정책 문서: Confluence
  • 의사결정과 논의: Slack
  • 구현과 검증: Git
• 프런트엔드 개발자는 이 정보를 통합해 실제 사용 가능한 결과물로 조립하는 역할을 담당합니다.
• 주요 부담은 코드를 작성하는 일보다 다음과 같은 컨텍스트 작업에 있습니다.
  • 티켓과 디자인 분석
  • 에지 케이스 확인
  • 제품·백엔드 팀과의 동기화
  • 기존 코드와 재사용 가능한 구성 요소 탐색

프롬프트에서 반복 가능한 워크플로로

• 단발성 프롬프트는 한 번의 작업에는 유용하지만, 반복성과 누적 효과가 부족합니다.
• 워크플로는 입력부터 출력까지의 표준화된 경로입니다.
  • 여러 시스템에서 관련 컨텍스트 수집
  • 요구 사항 요약
  • 모호하거나 충돌하는 내용 식별
  • 구현 계획과 파일 목록 제안
  • 사람이 검토한 뒤 코드 수정 진행
• 이 구조에서 LLM은 단순히 코드를 생성하는 도구가 아니라 워크플로를 실행하는 엔진입니다.
• 한 번 구축한 워크플로는 티켓의 내용이 달라져도 동일한 패턴으로 적용할 수 있어 확장성이 높습니다.

연결된 개발 컨텍스트와 Noah MCP

• LY Corporation의 Noah MCP는 Jira, Confluence, Slack, GitHub 같은 내부 도구를 연결합니다.
• AI 에이전트가 사람이 복사해 붙여넣은 정보가 아니라 실제 업무 시스템에 존재하는 컨텍스트를 직접 읽고 추론할 수 있게 합니다.
• 이를 통해 개발자는 각 시스템을 수동으로 방문하고 정보를 노트에 조합하는 작업을 줄일 수 있습니다.
• 핵심은 AI를 별도의 도구로 사용하는 것이 아니라 기존 업무 흐름 안에 배치하는 것입니다.

구현 전 요구 사항 통합

예시 기능은 검색·필터·정렬과 역할 기반 필터 표시가 있는 목록 페이지입니다. 기존 방식에서는 개발자가 Jira, Figma, Confluence, Slack, 코드베이스를 직접 확인한 뒤 계획을 작성합니다.

워크플로 기반 방식에서는 에이전트에게 다음을 요청합니다.

• Jira 티켓 분석
• 관련 Confluence 문서 검색
• Slack의 최근 의사결정 확인
• 유사한 코드 구현 탐색
• 코드 수정 없이 다음 결과 반환
  • 요구 사항 요약
  • 프런트엔드 영향 범위
  • 관련 파일
  • 구현 체크리스트
  • 테스트 체크리스트
  • 미해결 질문

에이전트가 도출한 계획에는 다음과 같은 구체적인 정보가 포함됩니다.

• FeatureListPage.tsx, FeatureList.tsx 등 신규 파일
• 기존 useTableFilters, useUrlState 훅의 재사용
• GET /api/<feature>의 기존 페이지네이션 API 활용
• 역할별 필터 표시
  • viewer: 검색, 상태 필터, 날짜 범위
  • editor: owner 필터 추가
  • admin: 내부 전용 플래그 추가
• 필터·정렬·페이지 상태를 URL 파라미터와 동기화
• 로딩, 빈 결과, 검색 결과 없음 상태 구현

숨겨진 요구 사항과 재작업 방지

• Slack 논의에서 필터 상태를 localStorage가 아니라 URL에 저장해야 한다는 결정이 발견됩니다.
  • URL 공유가 가능해지고
  • 새로고침 후에도 상태가 유지되며
  • 다른 사용자가 동일한 화면을 재현할 수 있습니다.
• 코드베이스 검색을 통해 이미 존재하는 훅을 재사용할 수 있습니다.
  • 불필요한 중복 구현 방지
  • 기존 동작과의 일관성 유지
  • 개발 시간 단축
• 구현 전에 다음과 같은 미해결 사항도 드러납니다.
  • 필터·정렬 상태를 URL에 저장할지 여부
  • 빈 상태에서 “필터 초기화” 버튼을 제공할지 여부
• 이런 문제를 PR 리뷰 단계가 아니라 구현 전에 발견하면 재작업 가능성을 줄일 수 있습니다.

코딩 이후의 폐쇄 루프 검증

워크플로는 코드 생성에서 끝나지 않고 검증 단계까지 포함해야 합니다.

• 구현 후 원래 계획과 실제 변경 사항을 대조합니다.
• 자동 검증 항목을 실행합니다.
  • 타입 검사
  • 린트
  • 관련 단위 테스트
  • 스모크 테스트 또는 로컬 검증 흐름
• 에이전트는 다음 결과를 보고합니다.
  • 통과한 검사
  • 실패 후 수정한 문제
  • 자동화하지 못한 검증
  • UI 상태별 스크린샷이나 확인 메모
  • PR 전 남은 위험 요소
• 이 폐쇄 루프를 통해 계획, 구현, 검증이 하나의 연속된 개발 사이클이 됩니다.

실용적인 적용 방향

프런트엔드 팀은 먼저 Jira·문서·메신저·코드 검색을 묶은 “구현 전 분석 워크플로”부터 도입하는 것이 좋습니다. 이후 구현 계획 승인, 코드 수정, 자동 테스트, PR 전 검증을 단계적으로 연결하면 단순한 코드 생성보다 재작업 감소와 품질 향상이라는 더 큰 효과를 얻을 수 있습니다.