line·2026년 6월 26일·4분 읽기큐레이션 요약

프롬프팅에서 워크플로로, 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 전 검증을 단계적으로 연결하면 단순한 코드 생성보다 재작업 감소와 품질 향상이라는 더 큰 효과를 얻을 수 있습니다.

원문 읽기(새 탭에서 열림)

jira대규모 언어 모델모델 컨텍스트 프로토콜React+4

line·2026년 5월 29일·4분 읽기큐레이션 요약

ODW #8: Slack MCP로 사고 대응과 FAQ 생성 작업 속도를 높이는 실습형 사내 워크숍 후기

Slack에 축적된 문의와 사고 대응 정보는 중요하지만, 문서화가 늦어지거나 담당자별 품질 차이로 지식 자산화가 어려웠다. 이 글은 사내 인증 기반 Slack MCP와 Confluence·Jira MCP를 결합해 FAQ, 사고 상황 요약, 인시던트 리포트를 자동 생성하는 워크숍 사례를 소개한다. 핵심은 기술 설명보다 실제 업무를 직접 자동화해 보고, 검증된 프롬프트를 스킬로 만들어 조직 전체에서 재사용하는 데 있다. ## Slack 정보의 구조화 격차 - Slack에는 사고 대응, 문의, 프로젝트 논의 등 실시간 업무 정보가 축적된다. - 그러나 문서화가 본업에 밀리거나 담당자에 따라 기록 품질이 달라진다. - 그 결과 중요한 정보가 Slack 스레드에 묻혀 재검색과 재활용이 어려워진다. - FAQ, 사고 보고서, 진행 상황 보고서 형태로 Confluence나 Jira에 정리할 필요가 있다. ## Slack MCP 도입과 워크숍 목표 - 사내 Slack MCP는 사내 인증과 연동되어 개인 토큰이나 복잡한 OAuth 설정 없이 Slack 정보에 접근할 수 있다. - 새로운 도구의 도입을 막는 요인은 다음과 같다. - 업무 중 별도로 학습할 시간 부족 - 설정과 활용에 대한 심리적 부담 - 사내 정보 확산의 지연 - 워크숍은 Slack MCP가 공개된 직후 빠르게 열어 참가자의 관심을 실습으로 연결했다. - 목표는 깊은 기술 지식 전달보다 참가자가 당일부터 업무에 활용할 수 있게 만드는 것이었다. ## Slack MCP의 주요 기능과 확장성 - Slack MCP는 다음 기능을 제공한다. - 메시지와 스레드 조회 - 메시지 게시 및 액션 실행 - 채널과 멤버 조회 - 메시지 검색 - Confluence MCP와 결합하면 프로젝트 보고서나 FAQ를 자동 생성하고 게시할 수 있다. - Jira MCP와 결합하면 Slack 논의를 바탕으로 작업 티켓을 만들 수 있다. - 워크숍에서는 먼저 AI에게 Slack 채널에 “Hello”를 게시하게 하여 MCP의 동작을 직접 체험하게 했다. ## 문의 대응 내용을 FAQ로 변환 - Slack 문의 채널의 대화를 검색해 FAQ 형식의 마크다운으로 변환했다. - 기존 Confluence FAQ와 대조해 이미 문서화된 내용은 제외했다. - 생성된 내용을 Confluence 하위 페이지로 게시하고, 증상·해결책·원인 구조의 표로 정리했다. - 활용 흐름은 다음과 같다. - 문의 채널과 Confluence 페이지 지정 - ‘문의’를 포함한 최신 스레드 검색 - 기존 FAQ와 중복 여부 확인 - 신규 문의만 FAQ 파일로 생성 - Confluence에 게시 - 이를 통해 반복 문의를 지식 베이스로 축적하고 담당자별 답변 품질 차이를 줄일 수 있다. ## 사고 상황 요약과 인시던트 리포트 생성 ### 빠른 상황 파악 - “시스템 장애 내용 및 상황을 정리해줘”와 같은 자연어 지시로 Slack 스레드를 검색한다. - AI는 해결 상태, 고객 영향, 담당자별 조치, 장애 타임라인을 요약한다. - 예를 들어 장애 감지 시각, 원인 파악 시각, 대응 완료 시각을 한눈에 정리할 수 있다. - 매니저가 중간에 합류하거나 담당자에게 직접 묻기 전에 전체 상황을 파악할 수 있어 의사 결정이 빨라진다. ### 인시던트 리포트 자동 작성 - 사전에 정한 형식에 따라 발생 시각, 감지 시각, 장애 기간, 원인, 영향 범위, 대응 내용을 자동 구조화한다. - 데이터베이스 커넥션 풀 고갈이나 설정 변경 누락 같은 원인과 사용자 수, 영향 기능, 데이터 손실 여부 등을 보고서에 포함할 수 있다. - 사고 대응 중에는 현황 요약을, 대응 완료 후에는 공식 리포트를 생성하는 식으로 목적에 맞게 활용한다. ## 정확도와 리뷰를 높이는 방법 - Slack의 모든 정보를 그대로 사용하지 말고 분석 범위를 먼저 좁혀야 한다. - 기존 Confluence 문서와 중복 제거 - 특정 리액션이 달린 메시지만 선택 - 특정 채널이나 기간, 키워드로 검색 범위 제한 - AI가 생성한 결과를 그대로 공개해서는 안 된다. - 개인정보 포함 여부 확인 - 원본 스레드 출처 표시 - 원래 발언을 과도하게 해석하지 않았는지 검토 - 실제 실습에서도 원본 스레드의 의도와 FAQ 내용이 미묘하게 달라지는 사례가 있어 사람의 리뷰가 필요함을 확인했다. - “증상·해결책·원인 세 칼럼의 표로 작성”처럼 출력 형식을 구체적으로 지정하면 팀 문서 표준에 맞는 결과를 얻기 쉽다. ## 재사용 가능한 스킬 설계 - 반복 작업은 스킬로 저장해 프롬프트를 매번 다시 작성하지 않도록 했다. - 워크숍에서 사용한 스킬은 다음 네 가지다. - `slack-to-faq`: Slack 스레드에서 FAQ 생성 - `faq-to-confluence`: FAQ를 Confluence에 게시 - `slack-incident-status`: 사고 상황 요약 - `slack-incident-report`: 인시던트 리포트 생성 - 스킬 제작 과정은 다음과 같다. - 수동으로 여러 프롬프트를 실험 - 효과적인 지시와 출력 형식 기록 - 재사용 가능한 스킬로 정의 - 팀에 공유하고 피드백을 반영해 개선 - 이를 통해 워크숍 참가자가 같은 절차를 재현하고, 팀 전체가 일관된 품질의 결과를 얻을 수 있다. ## 워크숍 운영에서 얻은 교훈 - 신기술이 등장해 관심이 높은 시점에 빠르게 교육을 제공하면 학습 참여를 높일 수 있다. - “Hello” 게시처럼 단순한 성공 경험부터 시작한 뒤 FAQ 생성과 사고 대응으로 난도를 높이는 단계적 구성이 효과적이다. - 일반적인 기능 소개보다 문의 대응과 장애 대응처럼 실제로 시간이 많이 드는 업무를 주제로 삼아야 활용 가능성을 쉽게 체감할 수 있다. - 기술 자체보다 참가자가 직접 손을 움직여 자신의 업무에 적용해 보는 경험이 현장 정착에 중요하다. 실무에서는 Slack MCP를 전사적으로 한꺼번에 도입하기보다, 반복 문의나 인시던트 보고처럼 효과를 측정하기 쉬운 업무부터 시작하는 것이 좋다. 원본 출처와 사람의 검토 절차를 반드시 포함하고, 검증된 작업 흐름은 스킬로 표준화해 점진적으로 확산하는 방식이 적절하다.

원문 읽기(새 탭에서 열림)

jira생성형 AI모델 컨텍스트 프로토콜slack+4

line·2026년 5월 28일·4분 읽기큐레이션 요약

도쿄에서 후쿠오카까지, 현장에서 답을 찾다 - CS InquiryChat 도입기

타사 채팅 솔루션의 종료를 계기로 데마에칸은 자체 메시징 플랫폼인 InquiryChat으로 전환했다. 이 프로젝트는 연간 라이선스 비용을 0원으로 줄였을 뿐 아니라, 상담 재활성화 비율을 약 20% 낮추고 보안·운영 유연성·사용자 경험을 개선했다. 성공적인 전환의 핵심은 단순한 기능 복제가 아니라, 현장 관찰과 사용자 테스트를 통해 실제 업무 맥락을 파악하고 이해관계자 간 합의를 이끌어낸 데 있었다. ## 자체 솔루션 전환의 배경과 목표 - 기존 타사 채팅 서비스의 종료가 예정되면서 후속 솔루션 도입과 자체 개발을 비교 검토했다. - InquiryChat을 선택한 이유는 다음과 같다. - 라이선스 비용을 제거할 수 있음 - 데마에칸의 운영 프로세스에 맞춘 유연한 커스터마이징 가능 - 내부 담당자를 통한 실시간 연동과 운영 지원 가능 - 고객 정보를 보안 문제 없이 활용 가능 - 실시간 분석·리포팅 제공 - 기존 서비스에는 다음과 같은 개선 과제가 있었다. - 상담원이 사용자가 전송하지 않은 메시지를 미리 볼 수 있는 보안 취약점 - 사용자가 이탈하면 세션이 유지되지 않아 상담을 처음부터 반복해야 하는 문제 - 다른 플랫폼과의 통합 및 사용자 정의가 제한적임 - 안정적으로 사용하던 도구를 교체하는 만큼, 상담원 교육과 업무 프로세스 변화, 서비스 중단 없는 전환이 필요했다. ## 문서 중심 요구 사항의 한계 - 초기 요구 사항은 기존 기능을 단순히 나열한 목록에 가까웠다. - 기능이 실제로 사용되는지, 현장 업무에 필요한지, InquiryChat에서 그대로 제공할 수 있는지 판단하기 어려웠다. - 요구 사항이 협업 부서를 거쳐 전달되면서 실제 상담원과 매니저의 업무 맥락이 희석됐다. - 기능을 다음 세 가지로 재분류해 우선순위를 정리했다. - 기본 제공 기능 - 커스터마이징 또는 추가 검토가 필요한 기능 - 신규 개발이 필요한 기능 ## 후쿠오카 콜센터 현장 조사 - 실제 사용자인 상담원과 매니저를 이해하기 위해 후쿠오카의 두 콜센터를 직접 방문했다. - 피크 시간대 업무를 모니터링한 뒤 여러 상담원과 매니저를 인터뷰해 공통 요구 사항을 도출했다. - 현장 조사로 불필요한 기능과 필수 기능을 구분할 수 있었다. - 매니저에게 지원을 요청하는 메시지 기능은 실제로 손짓이 더 빨라 거의 사용되지 않음 - 사무실에서 소리를 켤 수 없어 채팅 단절 음성 경고 기능은 실효성이 낮음 - 상담 내용을 CS 솔루션에 연동하는 기능은 상담 기록과 공유에 필수적이므로 우선순위를 높여 구현 - 직접 관찰한 근거를 바탕으로 협업 부서와 기능 우선순위를 설득할 수 있었다. ## 복잡한 협업 구조를 관리한 PM 전략 - 한국과 일본의 여러 부서, 외주 콜센터가 참여하는 구조에서 공통된 목표와 기준을 만드는 데 집중했다. - Jira 대시보드를 설계해 개발 진행 상황을 실시간으로 시각화하고 지표 기반 의사 결정을 가능하게 했다. - 파편화된 요구 사항을 하나의 마스터 사양서로 통합해 단일 기준을 마련했다. - 기획 의도가 실제 구현에 반영됐는지 확인하기 위해 기획·개발 단계의 내부 QA를 주도했다. - 출시 직후 현장에서 활용할 수 있도록 상세 운영 가이드도 제작했다. ## FGT를 통한 실제 사용자 경험 검증 - 화상 회의와 문서만으로는 세밀한 사용 경험을 검증하기 어렵다고 판단해 FGT를 진행했다. - 사용자와 상담원 역할을 나누고, 고객 문의 시작부터 문제 해결까지의 전체 시나리오를 직접 수행했다. - FGT 과정은 배경 설명, 수행 과제, 실습, 설문, Q&A 등으로 구성됐다. - 백엔드 연동에 집중하던 개발자도 실제 앱 사용 흐름을 경험하면서 문제를 QA 전에 발견하고 수정할 수 있었다. - 주요 피드백과 개선 사항은 다음과 같다. - 역할과 현재 상태를 더 직관적으로 표시할 필요 - 링크에 날짜뿐 아니라 시간도 표시 - Android 푸시 안정화 - 키패드와 채팅 입력창이 겹치는 문제 개선 - 푸시 알림 제목 변경 - 일부 대화 로그가 CS 솔루션에 누락되는 문제 해결 ## 보안과 상담 효율 사이의 균형 - 기존 상담원이 선호하던 ‘입력 중 메시지 미리보기’는 고객이 전송하지 않은 데이터까지 상담원이 볼 수 있다는 보안·정보 주권 문제를 안고 있었다. - 상담원에게는 고객 답변을 미리 파악해 평균 처리 시간(AHT)을 줄이는 유용한 기능이었다. - 단순히 기능을 삭제하면 상담 효율이 떨어질 수 있어, 대안으로 ‘입력 중 표시기’를 제안했다. - 상담원은 고객이 메시지를 작성 중인지 알 수 있지만, 실제 입력 내용은 볼 수 없도록 설계해 편의성과 개인정보 보호를 절충했다. - 이 과정은 기술 내재화가 기존 기능을 그대로 복제하는 것이 아니라, 운영 효율과 보안 원칙을 재검토하는 과정임을 보여준다. ## 실용적인 시사점 자체 솔루션 전환에서는 요구 사항 문서보다 실제 사용 현장 관찰이 우선되어야 한다. 또한 기능을 그대로 옮기기보다 보안, 업무 효율, 사용자 경험을 함께 평가하고, FGT 같은 실사용 검증을 통해 출시 전에 문제를 발견하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

jiraAndroiduser-researchinformation-security+3

line·2026년 5월 22일·4분 읽기큐레이션 요약

ODW #7: 세 가지 방법으로 토큰 소비량 40% 절감! ADK를 이용한 컨텍스트 엔지니어링

LY Corporation의 워크숍은 AI 에이전트의 비용 증가와 응답 정확도 저하를 해결하기 위해 컨텍스트 엔지니어링을 소개한다. 핵심은 LLM에 전달하는 프롬프트, 도구 정의, 대화 이력, 외부 데이터를 무조건 많이 제공하는 것이 아니라 작업에 필요한 고품질 정보만 적절한 형태로 선별하는 것이다. ADK의 구조화 스키마, AgentTool, MCP 도구 필터링을 활용하면 토큰 사용량을 줄이면서도 장시간 실행 에이전트의 정확도를 개선할 수 있다. ## 사내 AI 활용 확대에 따른 문제 - Claude Code, Cline, ADK 등 AI 도구의 사용자가 늘면서 토큰 소비량이 급증했다. - 프롬프트에 명시한 지시를 AI가 무시하거나 중요한 정보를 누락하는 문제가 발생했다. - 대화가 길어질수록 AI가 이전 맥락에 묻혀 엉뚱한 답변을 생성하기도 했다. - 주요 원인은 LLM에 전달되는 컨텍스트를 체계적으로 관리하지 않았기 때문이다. - 토큰 증가 요인에는 다음이 포함된다. - AI 사용 인구 증가 - 원하는 결과를 얻기 위한 반복 작업 - 싱글 에이전트에서 멀티 에이전트로의 확장 - 단발성 작업에서 장시간 실행 작업으로의 변화 - MCP 도구 정의 자체가 차지하는 토큰 - 컨텍스트 최적화 기법의 확산 부족 ## 컨텍스트 부패와 토큰 관리 - LLM 사용 비용은 입력과 출력에 사용된 총 토큰 수를 기준으로 산정된다. - 장시간 실행되는 에이전트에서는 대화 이력과 중간 결과가 계속 축적된다. - 현재 작업과 관계없는 정보가 컨텍스트에 남으면 중요한 신호가 노이즈에 묻힌다. - 이로 인해 컨텍스트 윈도 압박, 관련성 저하, 응답 정확도 하락이 발생한다. - 해결책은 필요한 정보만 추려 LLM에 전달하는 것이다. ## 컨텍스트 엔지니어링의 개념과 원칙 컨텍스트 엔지니어링은 에이전트가 사용하는 모든 문맥 정보를 설계하고 최적화하는 방법이다. - 관리 대상은 세 가지로 나뉜다. - **정적 컨텍스트**: 시스템 프롬프트, 도구 정의 - **동적 컨텍스트**: 사용자 메시지, 대화 이력, RAG 데이터 - **장기 컨텍스트**: 장시간 실행 중 축적되는 정보와 세션 상태 - 핵심 원칙은 “고품질 신호를 가진 최소한의 토큰 집합”을 찾는 것이다. - 정보를 너무 적게 주면 AI가 추측에 의존한다. - 정보를 지나치게 많이 주면 비용이 증가하고 핵심 정보가 묻힌다. - 따라서 작업에 필요한 수준으로 구체적이면서도 불필요한 정보는 제거해야 한다. - 프롬프트 엔지니어링이 지시문 작성에 초점을 둔다면, 컨텍스트 엔지니어링은 프롬프트뿐 아니라 도구, 데이터, 이력, 상태까지 포함해 전체 입력 환경을 최적화한다. ## ADK를 활용하는 이유 Google의 오픈소스 AI 에이전트 프레임워크인 ADK는 컨텍스트 엔지니어링을 팀 단위로 적용하기에 적합하다. - 개인의 CLI 숙련도에 의존하지 않고 팀의 지식을 에이전트 설계에 반영할 수 있다. - UI, API 서버, 평가 기능, 멀티 에이전트 구성을 제공한다. - 에이전트를 조합하고 도구처럼 호출할 수 있어 컨텍스트를 분리하기 쉽다. - 컨텍스트 엔지니어링을 위한 9개 핵심 컴포넌트를 조합해 사용할 수 있다. ## 주요 ADK 컴포넌트 실습에서는 다음 세 가지 기능을 중심으로 설명한다. - **Structuring Data** - 입력과 출력을 특정 JSON 스키마로 강제한다. - 에이전트 간 데이터 전달 형식을 명확히 한다. - 불필요한 자연어 설명을 줄여 토큰 사용량을 절감한다. - **AgentTool** - 다른 에이전트를 함수나 도구처럼 호출한다. - 하위 에이전트의 내부 도구와 중간 컨텍스트를 호출자에게 노출하지 않는다. - 최종 결과만 반환해 상위 에이전트의 컨텍스트 누적을 막는다. - **MCP Toolset의 `tool_filter`** - MCP 서버가 제공하는 도구 중 필요한 도구만 선택한다. - 예를 들어 Jira 티켓 검색에는 `jira_search`, 상세 조회에는 `jira_get_issue`만 허용할 수 있다. - 불필요한 도구 정의를 제거해 토큰 비용과 LLM의 판단 부담을 줄인다. ## Jira 주간 보고서 에이전트: v1의 문제 v1은 하나의 에이전트가 Jira 티켓 검색, 개별 티켓 상세 조회, 분석, 보고서 작성을 모두 수행하는 구조다. - 단일 에이전트에 Jira 관련 도구를 모두 제공한다. - 티켓마다 상세 정보를 가져와 같은 컨텍스트에 계속 축적한다. - 티켓 수가 증가할수록 컨텍스트가 커지고 컨텍스트 부패가 발생한다. - 여러 도구의 정의와 중간 결과가 함께 전달되어 토큰 사용량이 커진다. - 장시간 작업에서 중요한 티켓 정보와 불필요한 이전 정보가 섞일 가능성이 높다. ## Jira 주간 보고서 에이전트: v2의 개선 v2는 역할을 분리한 2-에이전트 구조로 변경했다. - **루트 에이전트** - Jira 티켓 목록을 검색한다. - 개별 티켓 분석 에이전트를 호출한다. - 각 분석 결과를 Markdown 표 형태의 주간 보고서로 집계한다. - **개별 티켓 분석 에이전트** - 하나의 Jira 티켓만 담당한다. - `issue_key`를 입력으로 받고 `report`를 구조화된 출력으로 반환한다. - Jira 상세 조회 도구인 `jira_get_issue`만 사용할 수 있다. - 사실만 포함하고 추측은 금지하도록 지시된다. - `AgentTool`을 통해 하위 에이전트의 내부 처리 과정은 루트 에이전트에 노출하지 않는다. - `input_schema`와 `output_schema`로 에이전트 간 데이터 형식을 제한한다. - `tool_filter`로 각 에이전트가 실제로 필요한 MCP 도구만 사용하게 한다. - 결과적으로 티켓별 상세 분석 컨텍스트가 루트 에이전트에 불필요하게 누적되는 것을 줄인다. AI 에이전트를 설계할 때는 프롬프트를 길게 작성하는 것보다 어떤 정보를 언제, 어떤 형식으로 전달할지 먼저 설계하는 것이 중요하다. 특히 작업을 하위 에이전트로 분리하고, 입력·출력 스키마와 도구 필터를 적용하면 비용과 정확도를 함께 개선할 수 있다.

원문 읽기(새 탭에서 열림)

jira대규모 언어 모델AI 에이전트쿠버네티스+3

line·2026년 5월 14일·4분 읽기큐레이션 요약

AI는 QA를 대체하지 않았다, 대신 확장했다

생성형 AI는 QA를 대체하기보다 분산된 품질 정보를 구조화하고 QA의 사고 범위와 영향력을 확장한다. LINE Album QA는 AI를 단순한 문서 작성 도구가 아니라 Jira, Slack, 테스트 도구, 사용자 리뷰와 연결된 품질 워크플로로 재설계했다. 그 결과 AI는 반복적인 수집·분석·초안 작성을 담당하고, QA 엔지니어는 리스크 판단과 최종 의사 결정에 집중하게 됐다. ## QA의 본질은 테스트 실행이 아닌 품질 설계 - QA 엔지니어는 기획, 개발, 테스트, 릴리스 전 과정에서 품질 관점을 제공한다. - 기획 단계에서는 잠재 리스크를 식별하고, 개발 단계에서는 변경 사항의 영향 범위를 분석한다. - 릴리스 이후에는 사용자 리뷰와 운영 데이터를 제품 개선으로 연결한다. - 따라서 QA는 단순한 테스트 수행자가 아니라 제품 생명 주기를 연결하는 **품질 설계자(quality architect)**에 가깝다. - 생산성을 결정하는 핵심 요소는 테스트 속도보다 다음 정보를 얼마나 빠르게 구조화하고 맥락화하는가에 있다. - 기획·기술 문서 - Slack 논의와 의사 결정 - Jira 이슈와 작업 티켓 - 자동화 테스트 스크립트와 실행 로그 - 다국어 사용자 리뷰와 피드백 ## AI를 대화 도구에서 품질 워크플로로 전환 - 초기에는 AI를 문서 요약, 테스트 케이스 초안 작성, 버그 리포트 정리 등에 활용했다. - 그러나 사람이 정보를 수집해 AI에 입력해야 했기 때문에 개인 생산성 향상 이상의 효과에는 한계가 있었다. - LINE Album QA는 Jira 이슈 생성, PR 병합, 테스트 실행, 사용자 리뷰 수집 같은 품질 이벤트에 AI가 자동으로 반응하도록 운영 체계를 구축했다. - 현재 30개 이상의 워크플로가 운영되며, AI는 정보를 분석하고 구조화하는 품질 시스템의 일부로 작동한다. - QA 엔지니어는 정리 작업보다 결과를 기반으로 리스크를 판단하고 필요한 검증을 수행하는 데 집중한다. ## 스케줄링 기반 자동화 - 정해진 시간에 반복 실행하며 정기적인 품질 데이터를 수집·요약한다. - 주요 활용 사례: - App Store·Google Play 리뷰의 이슈 분류 및 요약 - API 자동화 테스트 결과 분석 및 Slack 공유 - UI 자동화 테스트 결과 리포트 생성 - 주간 QA 활동과 주요 이슈 보고서 작성 - QA가 여러 시스템에서 데이터를 직접 모으는 시간을 줄이고, 구조화된 결과를 바탕으로 판단할 수 있게 한다. ## 웹훅 기반 이벤트 트리거 - 품질 관련 이벤트가 발생하는 즉시 분석을 시작한다. - 주요 활용 사례: - PR 병합 후 코드 변경 내용과 잠재 영향 범위 요약 - Slack 논의 스레드 종료 후 의사 결정 회의록 생성 - 자동화 테스트 결과 업로드 후 실행 통계 분석 및 시각화 - 중요한 품질 신호를 정기 보고까지 기다리지 않고 빠르게 인지할 수 있다. ## 자동화된 QA 업무 흐름 - UI 자동화 테스트는 MagicPod으로 Android·iOS 테스트를 실행하고, 결과를 Jira와 Slack에 공유한다. - 테스트 실패 시 AI가 플레이키 테스트 여부와 실패 원인을 분석한다. - Pytest 기반 API 테스트도 동일하게 실행 결과를 Jira와 Slack에 자동 반영한다. - 데일리 스크럼 전에는 테스트 현황, 미해결 이슈, QA 확인 필요 항목, Jira 멘션을 자동으로 정리한다. - 앱 리뷰는 긍정·부정 여부를 분류하고 일본어·한국어로 번역·요약한 뒤 일별·월별로 공유한다. - QA 엔지니어는 집중 업무 시간에 자동 수집된 정보를 활용해 품질 계획과 테스트 전략을 수립한다. - AI가 데이터를 수집·분석하는 동안 QA는 최종 판단, 수동·자동 테스트, 워크플로 개선을 담당한다. ## AI와 테스트 케이스 설계 - 2026년 기준 전체 테스트 케이스의 약 90%는 AI가 초안을 생성한다. - 단순히 요구 사항만 입력하면 일반적인 정상 흐름과 예외 케이스는 만들 수 있지만, 제품의 실제 맥락과 과거 결함을 반영하기 어렵다. - 이를 보완하기 위해 다음 정보를 AI의 입력 맥락으로 연결했다. - 기능 명세와 개발 티켓 - 변경 배경 - 과거 Jira 이슈 - 테스트 이력 - 반복적으로 발생한 결함 패턴 - 오케스트레이터 에이전트와 5개 서브 에이전트가 역할을 나누어 테스트 설계를 수행한다. - **Plan-Analyzer**: 기획 문서, 기능 설명, 이미지에서 기본 흐름 분석 - **Dev-Analyzer**: 개발 티켓과 구현 정보 분석 - **TestCase-Generator**: 정상·예외·경계값·플랫폼 차이·우선순위를 반영한 테스트 생성 - **TestCase-Validator**: 요구 사항 커버리지, 추적 가능성, Given/When/Then 형식, 플랫폼 커버리지 검증 - **Quality-Inspector**: 이전 피드백과 품질 평가를 반영해 다음 실행의 개선점 축적 - 과거에 실제로 발생한 결함 패턴까지 참고해 명세에 없는 유사 결함 시나리오도 확장한다. - 검증 결과가 부족하면 생성 단계로 피드백을 보내는 반복 루프를 통해 실행 가능한 테스트 케이스로 다듬는다. ## 실용적인 결론 AI 도입의 핵심은 테스트 케이스를 많이 생성하는 데 있지 않고, 기획·개발·운영·사용자 피드백을 연결해 품질 판단에 필요한 맥락을 자동으로 제공하는 데 있다. 효과적인 QA 자동화를 위해서는 AI를 개별 도구로 사용하기보다 품질 이벤트를 감지하고 분석·공유하는 워크플로로 통합해야 하며, 최종 리스크 판단과 의사 결정은 QA가 담당하는 구조가 바람직하다.

원문 읽기(새 탭에서 열림)

jira생성형 AI자동화slack+4

line·2026년 4월 15일원문

ODW #2: ADK로 싱글/멀티 에이전트를 개발해 사내 시스템과 통합 (새 탭에서 열림)

LY Corporation은 사내 AI 활용의 개인차를 극복하고 업무 생산성을 높이기 위해 'ADK(Agent Development Kit)'를 활용한 싱글 및 멀티 에이전트 개발 워크숍을 진행했습니다. 이 워크숍은 개인 중심의 AI 도구 활용에서 벗어나, 팀 단위로 최적화된 AI 에이전트를 구축하고 MCP(Model Context Protocol)를 통해 사내 시스템과 통합하는 실무 지식을 공유하는 데 중점을 두었습니다. 결과적으로 복잡한 업무를 자동화하는 멀티 에이전트 시스템을 직접 구현함으로써 지식 사일로 현상을 해소하고 조직 차원의 기술 상향 평준화를 목표로 하고 있습니다. **사내 AI 활용의 한계와 워크숍의 필요성** * **지식의 사일로화:** 개인별로 로컬 AI 도구(Cline, Claude Code 등)를 사용하면서 활용 능력에 따른 생산성 격차가 발생하고, 유사한 문제에 대해 각자 프롬프트를 최적화하는 중복 작업이 빈번해졌습니다. * **싱글 에이전트의 한계:** 단일 LLM 기반 에이전트만으로는 복잡한 비즈니스 로직이나 전문적인 대응에 한계가 있으며, 이를 해결할 수 있는 멀티 에이전트 개념에 대한 이해가 부족한 상황이었습니다. * **정보 접근의 어려움:** Jira, Confluence 등 사내 시스템에 파편화된 정보를 검색하고 요약하는 데 많은 시간이 소요되어, 이를 자동화할 수 있는 중앙 집중형 에이전트 호스팅의 필요성이 대두되었습니다. **에이전트 개발 도구: ADK와 MCP** * **ADK (Agent Development Kit):** 에이전트의 동작을 정의하고 멀티 에이전트 시스템을 구현하기 위한 오픈소스 프레임워크입니다. Python 등을 활용해 함수를 정의하면 에이전트가 이를 도구(Tool)로 인식하여 실행할 수 있게 해줍니다. * **MCP (Model Context Protocol):** LLM을 Jira, Confluence와 같은 외부 시스템과 연결하는 표준 프로토콜입니다. 이를 통해 에이전트가 사내 문서나 업무 이력을 능동적으로 탐색하고 활용할 수 있는 환경을 제공합니다. * **컨텍스트 관리:** 너무 많은 도구를 에이전트 하나에 부여하면 정확도가 떨어지므로, 멀티 에이전트 구조를 통해 역할별로 컨텍스트를 분리하여 성능을 최적화합니다. **멀티 에이전트를 활용한 '프로젝트 추적기' 구현** * **순차적 에이전트(Sequential Agent) 구조:** 복잡한 프로젝트 관리 업무를 해결하기 위해 4개의 특화된 에이전트를 순차적으로 연결하는 파이프라인을 구성했습니다. * **단계별 역할 분담:** * 1단계: 진행 중인 작업 분석(Jira 데이터 수집) * 2단계: 할 일(Todo) 목록 분석 및 우선순위 파악 * 3단계: 수집된 정보를 종합하여 마크다운 형식의 리포트 생성 * 4단계: 생성된 리포트를 지정된 언어로 번역 * **실무 적용 효과:** 사용자가 일일이 데이터를 찾고 정리할 필요 없이, 멀티 에이전트 시스템이 사내 시스템에 접속하여 분석부터 번역까지 완료된 종합 보고서를 즉시 제공합니다. 단순히 AI 도구를 도입하는 것을 넘어, 팀의 고유한 도메인 지식과 사내 시스템을 결합한 '팀 전용 에이전트'를 구축하는 것이 중요합니다. ADK와 같은 프레임워크를 활용해 멀티 에이전트 환경을 구축하고 이를 호스팅하여 공유한다면, 개인의 프롬프트 엔지니어링 역량에 의존하지 않고 조직 전체의 업무 효율을 상향 평준화할 수 있습니다.

jiraAI쿠버네티스모델 컨텍스트 프로토콜+4

line·2026년 3월 24일원문

SRE 팀의 반복 작업을 10분의 1로 줄인 SRE 봇 개발기 (새 탭에서 열림)

LINE Home DevOps 팀은 인프라 전환과 서비스 확대로 급증한 운영 문의 및 반복적인 배포 요청 문제를 해결하기 위해 Slack 기반의 통합 자동화 도구인 'SRE 봇'을 구축했습니다. 기존에 수동으로 수행하던 Jira 티켓 생성, 컨플루언스 체크리스트 복사, 배포 매뉴얼 검색 등의 프로세스를 자동화하여 업무 시간을 획기적으로 단축하고 휴먼 에러를 방지했습니다. 이를 통해 팀은 단순 반복 업무에서 벗어나 서비스 안정화와 인프라 고도화라는 본연의 업무에 집중할 수 있는 환경을 마련했습니다. ### 수동 운영 프로세스의 한계와 비효율성 * **복잡한 워크플로와 컨텍스트 스위칭:** 배포 요청 한 건을 처리하기 위해 Slack, Confluence, Jira 등 여러 플랫폼을 오가며 정보를 복사-붙여넣기해야 했으며, 이 과정에서 1건당 약 1시간의 시간이 소요되었습니다. * **휴먼 에러의 빈번한 발생:** 수동 작업 특성상 릴리스 버전 설정 오류, 필수 체크리스트 항목 누락, Epic 링크 연결 누락 등 실수가 잦았고, 긴급 상황일수록 이러한 문제는 더욱 심화되었습니다. * **가시성 부족과 정량화의 어려움:** Slack 멘션으로 들어오는 요청은 휘발성이 강해 진행 상황 추적이 어려웠으며, 팀의 업무량을 정량적으로 파악하여 성과로 증명하기 힘든 구조였습니다. ### 사용자 편의와 시스템 안정성을 고려한 기술적 설계 * **Slack 워크플로 기반 UI:** 사용자가 직접 명령어를 입력하는 방식 대신 Slack 워크플로 양식을 채택하여 필수 항목 누락을 방지하고 사용자의 진입 장벽을 낮췄습니다. * **백그라운드 비동기 처리:** Slack API의 응답 제한 시간(3초) 내에 외부 시스템(Jira, Confluence)과의 복잡한 연동을 마칠 수 없으므로, 즉시 응답 후 실제 작업은 백그라운드에서 수행하는 비동기 방식을 선택했습니다. * **Redis를 활용한 상태 관리:** Slack 스레드와 Jira 티켓 간의 매핑 정보를 Redis에 저장(TTL 30일 설정)하여 100ms 미만의 빠른 조회 성능을 확보하고, 트랜잭션을 통해 여러 SRE가 동시에 작업할 때 발생할 수 있는 동시성 문제를 해결했습니다. ### 헥사고날 아키텍처를 통한 유연한 확장성 확보 * **포트와 어댑터 패턴 적용:** Slack, Jira, Redis 등 외부 시스템과의 결합도를 낮추기 위해 헥사고날 아키텍처를 도입했습니다. * **비즈니스 로직 보호:** 인터페이스를 통해 외부 환경을 격리함으로써 Jira API 버전 업그레이드나 Slack SDK 변경 등 외부 변화가 발생하더라도 내부의 핵심 비즈니스 로직을 수정할 필요가 없도록 설계했습니다. * **테스트 및 유지보수 용이성:** 각 레이어가 명확히 분리되어 있어 기능 추가 시 영향 범위를 최소화할 수 있으며, 테스트 코드 작성이 수월해져 안정적인 코드베이스 유지가 가능해졌습니다. ### 도입 후 시나리오별 변화 및 성과 * **배포 요청 처리 시간 단축:** 기존 30분 이상 걸리던 배포 요청 처리가 SRE 봇 도입 후 1분 이내로 단축되었습니다. 봇이 Fix Version 생성, 티켓 연결, 매뉴얼 검색을 10초 만에 자동 수행하기 때문입니다. * **긴급 대응 및 가시성 개선:** 긴급 요청 시 즉시 우선순위가 높게 설정된 티켓이 생성되고 채널에 알림이 공유됩니다. SRE는 이모지 클릭만으로 본인에게 티켓을 할당하고 상태를 업데이트할 수 있어 실시간 추적이 용이해졌습니다. * **정기적인 업무 정량화:** 모든 요청이 정형화된 Jira 티켓으로 자동 기록됨에 따라, 팀원당 투입 시간과 처리 건수를 명확히 데이터화하여 운영 성과를 증명할 수 있게 되었습니다. 단순 반복적인 운영 업무로 인해 팀의 에너지가 고갈되고 있다면, 기술적인 자동화 레이어를 구축하여 'Zero Manual Work'를 지향하는 것이 장기적인 팀 생산성 향상의 핵심입니다. Slack과 같은 협업 툴을 Single Point of Truth로 설정하고 외부 시스템을 유연하게 연결하는 아키텍처를 고민해 보시기 바랍니다.

jira데이터베이스 설계slackredis+4

line·2025년 8월 8일원문

3년 차 앱 개발자가 일하는 순서를 공유합니다 (새 탭에서 열림)

효율적인 협업과 코드 리뷰를 위해 개발 프로세스를 세분화하고 작업 단위를 최소화하는 것이 핵심입니다. 기획 시뮬레이션부터 PoC(Proof of Concept), 그리고 리뷰어를 배려한 PR(Pull Request) 작성까지 이어지는 체계적인 워크플로우를 통해 작업의 예측 가능성을 높이고 팀 내 신뢰를 구축할 수 있습니다. 궁극적으로 작고 명확한 단위로 일하는 습관은 본인의 히스토리 관리와 팀의 전체 생산성 향상에 기여합니다. ### 기획 리뷰와 동작 시뮬레이션 * 기획서의 목적과 작동 방식을 명확히 이해하고, 실제 코드를 작성하듯 데이터 흐름과 화면 전환, 예외 상황(Edge Case)을 머릿속으로 시뮬레이션합니다. * 이 과정에서 사용자 경험을 위한 개선 아이디어나 의문점이 생기면 기획자와 즉시 소통하여 요구 사항을 확정합니다. * 복잡한 기능은 다이어그램이나 화살표를 활용해 전체적인 구조와 데이터 흐름을 시각화하여 큰 그림을 먼저 그립니다. ### 협업 효율을 높이는 작업 가시화 * 그려둔 작업 흐름을 바탕으로 Jira 에픽(Epic)과 하위 이슈들을 생성하여 전체 작업을 눈에 보이게 쪼갭니다. * 중요도가 높거나 여러 명이 관여하는 작업의 경우, 티켓을 확정하기 전 동료들에게 개발 방향 콘셉트를 공유하여 피드백을 받습니다. * 사전 공유 단계를 거치면 추후 리뷰 단계에서 발생할 수 있는 대규모 수정을 미연에 방지하고 불필요한 논쟁을 줄일 수 있습니다. ### PoC를 통한 규모 검토와 셀프 피드백 * 본격적인 개발 전 프로토타이핑(PoC)을 진행하며 예상치 못한 문제나 누락된 시나리오가 없는지 점검합니다. * PoC 단계의 코드 양을 확인하여(저자 기준 400줄), 변경 사항이 너무 많다면 주제별로 티켓을 분리하거나 하위 작업(Sub-task)으로 세분화합니다. * "내가 이 PR을 리뷰한다면 부담스럽지 않을까?"라는 질문을 스스로 던지며 리뷰어가 이해하기 쉬운 적정 규모로 작업을 조정합니다. ### 리뷰어 중심의 구현 및 PR 작성 * 의미 있는 단위로 커밋을 쪼개고, 인터페이스 정의 후 구현체를 작성하는 등 논리적인 순서로 코드를 쌓아 올립니다. * PR 작성 시에는 목적, 원인, 영향 범위, 테스트 방법 등을 상세히 기록하며, 필요시 동작 영상을 첨부하여 리뷰어의 이해를 돕습니다. * 작고 명확한 PR은 문제가 발생했을 때 원복(Revert)이 쉽고, 리뷰어에게 '읽기 편한 코드'라는 신뢰를 주는 효과가 있습니다. 이러한 워크플로우를 정착시키면 개발 기간 산정의 정확도를 높일 수 있습니다. 특히 Jira의 시간 기록 기능을 활용해 '최초 추정 시간'과 '실제 소요 시간'을 비교하고 기록하는 습관을 들이면, 본인의 개발 속도를 객관적으로 파악하고 더욱 정교한 일정 관리가 가능해집니다. 환경에 맞춰 이 프로세스를 유연하게 적용해 보시길 권장합니다.

jiragithub코드 리뷰Git+4