github·2026년 7월 21일·3분 읽기큐레이션 요약

캔버스로 인터랙티브한 경험을 만드는 방법

캔버스 확장은 GitHub Copilot을 단순한 대화형 도구에서 시각적이고 상호작용 가능한 작업 공간으로 확장한다. 사용자는 정보를 직접 보고 클릭·편집하며 작업할 수 있고, 에이전트는 같은 캔버스를 실시간으로 갱신한다. 따라서 이슈 분류, 코드 구조 탐색, 워크트리 정리처럼 대화만으로 처리하기 어려운 작업을 더 직관적으로 수행할 수 있다. ## 캔버스의 작동 방식 - 캔버스는 GitHub Copilot 앱 안에서 에이전트와 개발자가 함께 사용하는 공유 인터페이스다. - 에이전트는 작업 과정에서 캔버스를 업데이트하고, 사용자는 클릭·편집·필터링 등으로 정보를 직접 조작할 수 있다. - 사용자의 상호작용은 에이전트에 전달되거나 캔버스 내부에서 로컬로 처리된다. - Copilot에 추가 기능이나 개선 사항을 요청하면서 캔버스를 작업 흐름에 맞게 계속 발전시킬 수 있다. - GitHub Copilot 앱의 에이전트 세션에서 `/create-canvas`를 입력한 뒤 원하는 인터페이스와 기능을 설명하면 생성할 수 있다. ## 시각적 이슈 트리아지 - 저장소의 GitHub Issue를 카드 형식으로 하나씩 보여준다. - 오른쪽으로 스와이프하면 처리할 이슈로, 왼쪽으로 스와이프하면 거절할 이슈로 분류할 수 있다. - 사용자의 선택에 따라 캔버스가 실시간으로 이슈를 적절한 그룹으로 이동시킨다. - 긴 대화나 명령 대신 빠른 제스처로 많은 이슈를 검토할 수 있다. ## 인터랙티브 코드베이스 다이어그램 - 프로젝트의 각 구성 요소를 노드로 표현하고, 컴포넌트 간 관계를 시각화한다. - 노드를 마우스로 이동하거나 마우스를 올려 세부 정보를 확인할 수 있다. - 필터를 사용해 코드베이스의 특정 계층이나 영역만 탐색할 수 있다. - 정적인 문서나 설명을 읽는 대신 아키텍처를 직접 탐색하면서 시스템 구조를 이해할 수 있다. ## 세션과 Git worktree 관리 - GitHub Copilot 앱의 활성 세션과 연결된 worktree를 한 화면에 표시한다. - 현재 사용 중인 worktree와 오래되었거나 고립된(orphaned) worktree를 구분한다. - 필요하지 않은 stale worktree를 버튼 클릭 몇 번으로 정리할 수 있다. - 여러 에이전트 세션을 동시에 사용하는 개발자에게 세션 상태와 작업 공간을 관리하는 시각적 제어판 역할을 한다. ## 에이전트 프롬프트 코치 - 과거 에이전트 세션의 프롬프트를 분석해 개선점을 제안한다. - 부족한 맥락, 맞춤법 오류, 문법·구문 문제 등을 찾아낸다. - 각 프롬프트를 더 명확하고 효과적으로 작성하는 방법을 안내한다. - 반복적인 피드백을 통해 에이전트가 더 일관된 결과를 내도록 프롬프트 작성 능력을 높일 수 있다. ## 여러 도구를 연결하는 지식 탐색 - Slack, Teams, 이메일, 문서 등 여러 업무 도구를 검색한다. - 특정 파일이나 주제와 관련된 지식이 있는 사람을 찾아준다. - 해당 인물과 주제의 연결 근거가 어디에서 발견되었는지도 함께 보여준다. - 조직 내 담당자나 관련 전문가를 빠르게 파악해 추가 질문과 협업으로 이어갈 수 있다. ## 활용 시사점 캔버스 확장은 AI와의 상호작용을 프롬프트와 응답의 연속에서 시각적 탐색·편집·실행 과정으로 바꾼다. 정보를 한눈에 비교하거나 직접 조작해야 하는 작업이라면 `/create-canvas`로 원하는 화면과 동작을 구체적으로 요청해 보는 것이 효과적이다.

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

slackAI 에이전트github-copilotgithub-issues+3

figma·2026년 7월 1일·3분 읽기큐레이션 요약

스킬이 있으신가요? Figma Agent를 더 나은 협업자로 만들기 | Figma 블로그

Figma의 “스킬”은 팀의 업무 방식과 전문 지식을 자연어 지침으로 저장해 두고, `/` 명령으로 Figma 에이전트에서 반복 사용할 수 있게 하는 기능이다. 디자인 시스템이 컴포넌트와 UI 패턴을 제공한다면, 스킬은 브랜드 문체·접근성·리뷰 절차·개인별 피드백 방식 같은 조직의 맥락을 더한다. Figma는 이를 통해 에이전트를 단순한 생성 도구가 아니라 팀의 작업 방식을 이해하고 협업하는 파트너로 활용할 수 있다고 설명한다. ## 스킬과 디자인 시스템의 역할 구분 - 디자인 시스템은 에이전트가 사용할 컴포넌트, 패턴, UI 요소를 제공한다. - 스킬은 그 위에 팀의 전문 지식과 업무 규칙을 적용한다. - 적용할 수 있는 예시는 다음과 같다. - 브랜드 보이스와 UX 라이팅 규칙 - 컴플라이언스 및 접근성 기준 - 디자인 리뷰 절차 - 제품 원칙과 의사결정 기준 - 디자인 시스템을 특정 업무 흐름 안에서 호출하는 방법 - 한 번 만든 스킬은 팀이나 조직에 게시해 여러 사람이 반복 사용할 수 있다. ## 필요할 때 받는 두 번째 의견 스킬은 특정 관점으로 디자인이나 문구를 검토해 아이디어의 약점을 찾고 더 나은 질문을 하도록 돕는다. - **이해관계자의 피드백 방식 모사** - 공개 코멘트, 과거 크리틱, 파일에 남은 메모 등을 예시로 제공한다. - 에이전트가 특정 인물의 피드백 스타일을 적용하도록 만들 수 있다. - Figma는 CEO Dylan의 코멘트 방식을 반영해, 공식 리뷰 전에 작업을 점검하는 스킬을 만들었다. - **UX 라이팅 기준 적용** - 스타일 가이드에 따라 대문자 사용, 구두점 등 문구의 일관성을 1차 검토한다. - 작성자는 단순한 형식 오류보다 더 중요한 내용과 메시지에 집중할 수 있다. - **처음 사용하는 사람의 관점 제공** - 제품을 잘 아는 디자이너가 놓치기 쉬운 마찰 지점과 부족한 설명을 찾는다. - 신규 사용자가 경험을 이해할 수 있는지 점검하는 데 유용하다. ## 한 번 만들고 반복해서 사용하는 업무 팀이 매번 비슷한 방식으로 수행하는 의식이나 절차는 스킬로 만들 가치가 있다. - **`/catch-me-up`** - 파일이나 프로젝트의 최근 활동을 요약한다. - 한동안 자리를 비운 사람이 댓글과 변경 내역을 직접 추적하지 않고 빠르게 상황을 파악할 수 있다. - **크리틱 준비 체크리스트** - 에이전트가 페르소나, 작업 범위, 크리틱 참석자 등 프로젝트 맥락을 질문한다. - 수집한 정보를 바탕으로 크리틱 페이지와 토론용 질문을 만든다. - Figma의 스킬은 Nielsen Norman Group의 모범 사례를 참고해 더 깊은 논의를 유도하는 질문을 구성한다. - **크리틱 회고** - 회의에서 나온 피드백을 주제별로 정리한다. - 결정 사항, 후속 작업, 보류된 항목을 구분해 실행 계획으로 만든다. - 결과를 캔버스의 recap 카드나 Slack 스레드에 공유할 수 있어 회의 후 정보가 유실되는 것을 줄인다. ## 팀의 암묵지를 재사용 가능한 지침으로 전환 - 팀만 알고 있던 업무 방식이나 반복 프롬프트를 자연어 지침으로 문서화한다. - 매번 같은 설명을 다시 입력하지 않고 `/스킬이름`으로 호출한다. - 개인의 머릿속에 머물던 리뷰 기준과 작업 절차를 조직 전체가 사용할 수 있는 자산으로 바꾼다. - 스킬을 만들 때는 실제 피드백, 스타일 가이드, 기존 산출물처럼 구체적인 사례를 함께 제공할수록 팀의 방식에 가까운 결과를 얻을 수 있다. 팀에서 반복되는 작업이나 동일한 검토 기준이 있다면, 이를 먼저 작은 스킬로 만들어 테스트하는 것이 좋다. 특히 온보딩, 크리틱 준비·회고, 문구 검수처럼 입력과 결과가 비교적 명확한 업무부터 시작하면 효과를 확인하기 쉽다.

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

slackFigma디자인 시스템AI 에이전트+2

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

Hubber로서 전환하기

GitHub의 Arthur Searle은 회사의 핸들 중심 문화와 원격 근무 환경, 성별 확정 의료 지원 덕분에 직장에서 비교적 안전하고 자연스럽게 트랜지션할 수 있었다고 말합니다. 이름·대명사 변경 과정의 행정적 마찰은 있었지만, 동료들의 존중과 지지를 통해 자신의 정체성으로 일하는 기쁨을 경험했습니다. 이 글은 트랜스젠더 구성원이 직장에서 겪는 어려움뿐 아니라, 포용적인 환경이 만들어내는 안도감과 기쁨도 함께 보여줍니다. ## IT 지원에서 보안 엔지니어로 - Arthur는 IT 지원과 운영 업무로 커리어를 시작한 뒤, 독학으로 코딩을 배웠습니다. - 동료의 추천으로 GitHub에 입사해 IT Engineering 팀에서 근무했습니다. - 보안 관련 문제와 풀 리퀘스트를 여러 보안 팀에 지속적으로 제기한 결과, 6개월 만에 Enterprise Security 팀으로 이동했습니다. - 주요 SaaS 플랫폼의 인프라를 코드로 이전하는 작업에 참여했고, 옥스퍼드대학교에서 버전 관리 관련 강연도 진행했습니다. ## 핸들 중심 문화가 만든 정체성의 연속성 - 입사 당시 법적 이름은 Ursula였지만, 온라인 핸들은 계속 `gleeblezoid`였습니다. - GitHub의 원격 중심 문화에서는 실명보다 핸들을 자주 사용하기 때문에, 이름을 바꾸더라도 기존의 업무 정체성과 관계를 유지하기 쉬웠습니다. - 다른 회사처럼 모든 사람이 외모와 실명만으로 서로를 식별하는 환경이었다면 트랜지션 과정이 더 어려웠을 것이라고 설명합니다. - 내부 시스템에서 이름과 대명사를 업데이트한 뒤, 대부분의 동료가 자연스럽게 새 이름을 사용했습니다. ## 의료 지원과 원격 근무의 장점 - GitHub는 직원 모두에게 성별 확정 의료와 관련된 복지 혜택을 제공합니다. - Arthur는 해당 혜택으로 다음과 같은 비용을 지원받을 수 있었다고 말합니다. - 음성 훈련 - HRT 처방약 - 상담 및 치료 - 원격 근무 덕분에 출근 복장이나 이동 중 다른 사람의 시선에 대해 걱정할 필요가 적었습니다. - 업무 소통 대부분이 Slack과 GitHub에 글로 남기 때문에, 음성 훈련이나 HRT로 목소리가 변하는 시기에 하루 종일 직접 말해야 하는 부담도 줄었습니다. - 만화 캐릭터 아바타처럼 외모와 성별 표현에서 자유로운 문화 역시 불필요한 추측과 판단을 줄였습니다. ## 직장에서 트랜스젠더로 살아가는 현실 - Arthur는 직장에서 커밍아웃하지 못하거나, 이름 변경 과정에서 행정적 문제를 겪는 트랜스젠더 동료들을 알고 있다고 말합니다. - 새로운 사람을 만날 때마다 자신의 정체성을 반복해서 설명해야 하는 경우도 있습니다. - 본인은 급여 시스템 등에서 법적 이름을 바꾸는 행정 절차를 제외하면 비교적 순조롭게 트랜지션할 수 있었습니다. - 동료들은 그를 특별히 다르게 대하지 않고, 원하는 이름과 대명사를 사용하며 일반적인 동료로 존중했습니다. ## 지지와 긍정적인 감정 - 트랜스젠더로 살아가는 일이 항상 쉽거나 사회적으로 받아들여지는 것은 아니지만, 경험이 고난만으로 정의되는 것은 아니라고 강조합니다. - 직장에서 처음 자신의 이름을 듣고 남성 대명사로 불렸을 때 큰 감동을 느꼈습니다. - 한 동료가 면도 키트를 보내준 일처럼, 동료들의 작은 배려가 강한 소속감과 기쁨을 만들었습니다. - 동료들은 Arthur와 관련된 농담과 밈을 공유하며 그의 트랜지션을 진심으로 축하하고 지지했습니다. - 그는 “항상 남성이었지만, 남성으로 살아가고 사회에 참여할 시간과 지원이 필요했다”고 말하며 글을 마무리합니다. 기업이 트랜스젠더 구성원을 지원하려면 의료비 보장뿐 아니라 이름·대명사 변경 절차, 원격·비동기 소통, 외모에 대한 판단을 줄이는 문화까지 함께 마련해야 합니다. 궁극적으로 중요한 것은 트랜지션을 특별한 사건으로만 다루지 않고, 구성원이 원하는 정체성으로 존중받으며 평범하게 일할 수 있도록 하는 것입니다.

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

slackgithubversion-controlinfrastructure-as-code+3

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

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

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

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

내부 데이터 분석 에이전트를 구축한 방법

GitHub는 사내 데이터 웨어하우스에 자연어로 질문하면 SQL을 작성하고 결과를 해석해 주는 GitHub Copilot 기반 분석 에이전트 ‘Qubot’을 구축했다. Qubot은 대시보드나 정기 리포트의 대체재가 아니라, 데이터 모델·필터·쿼리 작성법을 몰라도 탐색적 분석을 수행하도록 돕는 도구다. 핵심 성공 요인은 데이터에 대한 구조화된 컨텍스트와 자동화된 평가 체계이며, 이를 통해 분석 정확도뿐 아니라 응답 속도도 크게 향상됐다. ## Qubot의 목적과 활용 범위 - GitHub의 여러 제품·엔지니어링 팀이 데이터 분석가의 도움 없이 제품 텔레메트리를 활용하도록 지원한다. - 사용자는 다음과 같은 탐색적 질문을 자연어로 입력할 수 있다. - 특정 기능의 유지율이 가장 높은 사용자 코호트는 무엇인가? - 지난주 특정 지표의 변화에 가장 큰 영향을 준 제품은 무엇인가? - 정기 보고서나 대시보드를 대체하지 않고, 데이터셋을 빠르게 이해하고 가설을 검증하는 데 초점을 둔다. - 데이터 분석 지원 요청을 줄이고, 데이터 웨어하우스를 사용해 본 적이 적은 직원도 의사결정에 필요한 데이터를 직접 탐색할 수 있게 한다. ## 세 가지 핵심 구성 요소 Qubot은 사용자 인터페이스, 컨텍스트 계층, 쿼리 엔진으로 구성된다. - **사용자 인터페이스** - Slack, VS Code, Copilot CLI에서 사용할 수 있다. - Slack에서는 채널에 질문을 올리면 GitHub.com에서 Copilot Cloud Agent가 실행된다. - 답변은 Slack에 바로 게시되며, 스레드에서 질문을 추가로 구체화할 수 있다. - 분석 결과는 Markdown 보고서로 작성되어 Pull Request에 저장된다. - VS Code와 Copilot CLI에서는 플러그인 설치 후 다른 에이전트·스킬·도구와 함께 사용할 수 있다. - **컨텍스트 계층** - 데이터의 관리 수준에 따라 서로 다른 정보를 제공한다. - Bronze 데이터에는 제품 팀이 제공한 이벤트 스키마와 메타데이터가 포함된다. - Silver 데이터에는 예시 쿼리, 사용 지침, 필수 필터 등이 포함된다. - Gold 데이터에는 해당 데이터셋을 소유한 팀이 정의한 비즈니스 규칙과 지표 정의가 포함된다. - ETL 파이프라인이 추가 신호와 파생 메타데이터를 자동으로 보강한다. - 에이전트는 실행 시점에 GitHub MCP Server를 통해 필요한 컨텍스트를 가져온다. - **쿼리 엔진** - GitHub의 주요 분석 엔진인 Kusto와 Trino를 MCP 서버로 연결한다. - Kusto는 최근 이벤트 데이터를 빠르게 탐색하는 데 적합하다. - Trino는 복잡한 조인과 장기간의 이력 분석에 적합하다. - 사용자가 엔진을 직접 선택하지 않아도 Qubot이 기본적으로 Kusto를 사용하고, 복잡한 질문에는 Trino로 자동 전환한다. ## 컨텍스트 에이전트와 지식 관리 - 컨텍스트 정보는 여러 저장소에 Markdown 형태로 관리된다. - 팀은 표준 템플릿을 사용하거나 관련 컨텍스트가 있는 저장소를 참조해 지식을 기여할 수 있다. - 컨텍스트 에이전트가 정보를 수집한 뒤 정리·정규화해 Qubot이 활용하기 쉬운 구조로 변환한다. - 데이터 모델 자체보다 데이터의 의미, 올바른 필터, 지표 정의, 사용 사례를 함께 제공하는 것이 에이전트의 분석 품질을 높이는 핵심이다. ## 자동화된 평가 프레임워크 - 컨텍스트나 에이전트 설정이 변경될 때마다 배포 전에 오프라인 평가를 수행한다. - 평가 대상은 정확도뿐 아니라 적절한 답을 찾는 데 걸리는 시간과 기존 기능의 회귀 여부다. - 평가 프레임워크는 다음 세 부분으로 구성된다. - **테스트 케이스**: 정답, 기준 SQL, 도메인, 난이도를 포함한 표준 질문 집합 - **실행 오케스트레이션**: GitHub CLI의 `gh agent-task create`를 이용해 테스트를 병렬 실행하고 JSON 결과를 저장 - **통계 집계**: 테스트별 완료율, 정확도, 평균·최소·최대 소요 시간을 계산 - 전체 과정은 테스트 정의 → 여러 차례 실행 → 결과 수집 → 통계 집계 → 설정 비교 순서로 진행된다. - 이를 통해 컨텍스트 추가나 에이전트 변경이 실제 품질 향상으로 이어지는지 검증할 수 있다. ## 도입 효과와 핵심 교훈 - Qubot은 수백 명의 사용자가 수천 건의 쿼리를 실행할 정도로 확산됐다. - 데이터·분석 Slack 채널에 반복적으로 들어오던 질문이 크게 줄었다. - 사용자는 간단한 질문을 직접 해결하고, 분석 전문가는 더 복잡한 문제에 집중할 수 있게 됐다. - Slack, VS Code, Copilot CLI를 함께 제공해 기술 수준과 업무 방식에 따른 진입 장벽을 낮췄다. - 실험 결과, 잘 구조화되고 큐레이션된 컨텍스트는 Qubot의 정확도를 높였을 뿐 아니라 올바른 답을 반환하는 속도도 약 3배 향상시켰다. - 따라서 데이터 문서, 지표 정의, 사용 규칙 같은 컨텍스트 자산을 단순한 문서가 아니라 분석 시스템의 핵심 구성 요소로 관리해야 한다. 실무적으로는 처음부터 모든 데이터를 자동 분석하려 하기보다, 자주 묻는 도메인부터 표준화된 컨텍스트와 기준 테스트를 구축하는 접근이 적합하다. 또한 여러 쿼리 엔진을 사용한다면 사용자가 엔진을 선택하지 않아도 되도록 에이전트가 질문 특성에 따라 자동 라우팅하도록 설계하는 것이 좋다.

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

slackAI 에이전트모델 컨텍스트 프로토콜github-copilot+4

toss·2026년 6월 19일·3분 읽기큐레이션 요약

디자이너에게 AI로 뭐든 만들어보라고 한다면

토스 디자인 챕터의 AI Contest는 AI로 무엇이든 만들어보는 한 달간의 실험으로, 총 122개의 결과물이 모였습니다. 사례를 보면 AI는 완전히 새로운 업무보다 반복 작업 자동화, 지식 공유, 인터랙션 설계, 짧은 시간 안의 품질 향상에 특히 효과적이었습니다. 핵심은 AI를 직접 활용해 자신의 문제를 빠르게 실험하고 해결하는 데 있습니다. ## 반복 업무를 자동화하다 - 이미지를 입력하면 UI에 적합한 색상을 자동으로 추출하고 보정하는 로직을 개발했습니다. - 사진마다 색상 결과가 달라 수년간 해결하지 못했던 문제를 AI와 함께 코드 초안으로 만들었습니다. - 샘플 이미지를 반복해서 입력하고 결과를 검증·수정하며 로직을 개선했습니다. - 완성된 로직은 실제 토스 쇼핑 상품 카드의 색상에 적용됐습니다. ## 개인 지식으로 협업 비용을 줄이다 - 과거 슬랙 대화와 정리된 참고 자료를 학습한 메신저 봇을 만들었습니다. - 팀원의 디자인·요건 질문에 대해 과거 논의를 근거로 답변 초안을 생성합니다. - 담당자는 초안을 그대로 보내거나 수정해 전달할 수 있습니다. - 사람이 수정한 답변 방향도 다시 반영해 유사한 질문에 더 정확히 답하도록 개선됩니다. - 반복적인 질문 대응 시간이 줄어들면서 “내가 1.5명으로 늘어난 느낌”이라는 효과를 얻었고, 다른 디자이너들도 각자의 봇을 만들기 시작했습니다. ## 말보다 동작하는 프로토타입으로 설득하다 - 주식 거래용 증권 PC 화면을 정적인 시안이 아닌 실제로 조작 가능한 프로토타입으로 구현했습니다. - 패널을 끌어 위치를 바꾸거나 창 크기를 조절하면 화면이 반응하도록 제품 코드를 직접 활용했습니다. - 말이나 영상으로 설명해야 했던 인터랙션을 직접 움직여 보여주면서 디자인 의도가 개발 과정에서 흐려지는 문제를 줄였습니다. - 개발자와 PO가 결과를 즉시 이해할 수 있어 커뮤니케이션과 설득력이 높아졌습니다. ## 제한된 시간에 완성도를 높이다 - 토스뱅크 공채 웹페이지의 직군별 키비주얼에 사용할 모션그래픽을 AI로 제작했습니다. - 모션의 기본 이미지와 시작·끝 프레임은 사람이 직접 만들고, 중간 결과 생성은 Kling을 활용했습니다. - 원하는 결과가 나올 때까지 프롬프트를 반복적으로 수정했습니다. - 촉박한 일정 속에서도 직군별 모션을 단 하루 만에 완성했습니다. ## AI 활용을 시작하는 네 가지 방향 - **효율:** 매일 반복하는 일 중 가장 번거로운 작업 하나를 자동화합니다. - **분신:** 반복해서 답하는 질문을 대신 처리할 개인 지식 봇을 만듭니다. - **설득:** 말로 설명하던 디자인을 직접 작동하는 프로토타입으로 보여줍니다. - **퀄리티:** 짧은 시간 안에 더 높은 완성도에 도달할 수 있도록 AI를 제작 과정에 활용합니다. AI를 도입할 때는 거창한 신규 프로젝트보다 현재 업무에서 반복되거나 설명하기 어렵고 시간이 부족한 문제 하나를 골라 작게 실험하는 것이 효과적입니다.

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

slackAI프로토타이핑프롬프트 엔지니어링+3

toss·2026년 6월 17일·3분 읽기큐레이션 요약

매일 하던 업무를 디자인하기

토스뱅크의 프로덕트 디자이너 김혜미는 매일 슬랙과 노션에 할 일을 수기로 옮기던 반복 업무를 직접 자동화했다. 슬랙 메시지에 특정 이모지를 달면 AI가 맥락을 읽고, 한 줄짜리 할 일과 팀 태그, 출처 링크를 위젯에 등록하도록 만든 것이다. 그 결과 업무를 수집·정리하는 데 쓰던 에너지를 줄이고, 실제 우선순위 판단에 집중할 수 있게 됐다. ## 반복 업무를 참는 대신 디자인하기 - 업무가 늘어나 하루 할 일이 20개를 넘으면서 수기 관리 방식의 한계가 드러났다. - 더 나은 할 일 앱을 찾기보다, 자신이 매일 사용하는 프로덕트로 문제를 재정의했다. - 사용자는 자신이고, 진짜 목표는 “할 일을 정리하는 것”이 아니라 “중요한 일을 놓치지 않고 처리하는 것”이었다. - 가장 큰 마찰은 할 일을 옮겨 적고, 관련 맥락과 출처를 다시 찾는 반복 작업이었다. - 해결 방향은 다음과 같았다. - AI가 슬랙 메시지에서 할 일을 자동 등록 - 원본 스레드와 문서 링크를 함께 저장 - 우선순위를 표시하고 화면에 위젯을 항상 노출 ## 슬랙 맥락을 AI가 할 일로 바꾸기 - 특정 이모지를 단 슬랙 메시지를 한 채널에 모은 뒤, Claude Code가 내용을 읽어 할 일로 변환했다. - 핵심 과제는 긴 메시지와 대화 맥락을 실행 가능한 한 줄의 문장으로 요약하는 것이었다. - 예를 들어 “대출 연장 신청 시 에러가 발생하는데 확인해달라”는 요청을 “대출 연장 에러 케이스 확인”으로 바꾸고 관련 팀을 태그했다. - 초기에는 요약이 지나치게 길거나 핵심을 놓치고, 잘못된 팀에 배정되는 문제가 있었다. - 이를 개선하기 위해 다음 기준을 직접 정의했다. - 좋은 할 일의 문장 구조 - 팀을 구분하는 기준 - 일관된 표현 방식 - 반드시 포함하거나 제거해야 할 정보 - 결국 AI가 만든 결과가 “내가 직접 적었을 법한 문장”이 되도록 예시와 규칙을 반복해서 다듬었다. ## AI에게 요구사항을 명확히 설명하기 - 위젯의 접기·펼치기, 드래그 같은 인터랙션을 구현하는 과정에서도 세부 동작을 구체적으로 설명해야 했다. - 머릿속에서는 당연한 동작도 AI에게는 단계별 조건과 예외를 언어로 전달해야 했다. - 구현 과정은 단순히 코드를 작성하는 일이 아니라, 자신의 업무 방식과 판단 기준을 명확히 정의하는 과정이었다. - 특히 AI가 업무를 이해하도록 만드는 일은 사용자의 요구를 더 정확한 언어로 구조화하는 작업과 같았다. ## 수집과 정리에서 우선순위 판단으로 - 위젯이 항상 화면에 표시되기 때문에 슬랙이나 노션을 반복해서 열어 할 일을 확인할 필요가 없어졌다. - 이전에는 하루에도 수십 번 “할 일이 뭐였지?” 하며 정보를 찾는 데 시간을 썼다. - AI가 업무를 모으고 정리하면서, 사용자는 무엇부터 처리할지 판단하는 데 집중할 수 있게 됐다. - 해야 할 일을 놓칠 것이라는 불안이 줄고, 우선순위 설정에 더 많은 에너지를 쓸 수 있었다. ## 개인적인 불편에서 팀의 문제로 - 개인용으로 만든 도구였지만 팀원들도 사용하기 시작했고, 유료 서비스로 제공해도 좋겠다는 반응까지 나왔다. - 개발자들이 직접 버그를 제보하고 기능을 제안하면서 사용자와 제작자의 역할이 뒤바뀌기도 했다. - 이를 통해 할 일 관리, 맥락 수집, 우선순위 설정은 직무와 관계없이 많은 사람이 겪는 공통 문제임을 확인했다. - 도구가 확산된 이유는 새로운 아이디어라서가 아니라, 사람들이 이미 반복적으로 겪던 불편을 해결했기 때문이다. ## 직접 적용하는 방법 - 이번 주에 가장 자주 반복한 ‘진짜 일이 아닌 일’을 찾는다. - 옮겨 적기 - 자료 찾기 - 정보 정리하기 - 다음 질문으로 문제를 정의한다. - 사용자는 누구인가? - 실제로 이루려는 결과는 무엇인가? - 가장 큰 마찰은 어디에서 발생하는가? - 무엇이 자동화되면 성공인가? - 기존 도구가 해결하지 못하는 이유를 살핀다. - 처음부터 큰 시스템을 만들기보다, 다음 날 바로 써볼 수 있는 가장 작은 기능부터 구현한다. 반복적으로 정보를 옮기고 정리하는 업무가 있다면, 이를 개인의 습관이나 인내심 문제가 아니라 자동화할 수 있는 프로덕트 문제로 바라보는 것이 출발점이다.

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

slackAI자동화claude-code+2

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

도메인 전문가를 코드화하기: Spotify 데이터 어시스턴트를 뒷받침하는 컨텍스트 레이어 | Spotify Engineering

Spotify의 데이터 어시스턴트가 신뢰할 만한 답변을 제공하는 핵심은 거대한 스키마를 LLM에 모두 넣는 것이 아니라, 도메인 전문가가 선별한 맥락 계층을 구축하는 데 있다. 이 맥락은 관련 데이터셋, 검증된 질문-SQL 예시, 업무 문서로 구성되며 각 도메인 팀이 소유하고 관리한다. 결국 AI는 전문가를 대체하기보다 전문가의 지식을 여러 사용자에게 확장하는 역할을 한다. ## 대규모 데이터 환경에서 스키마만으로 부족한 이유 - Spotify에는 7만 개 이상의 데이터셋과 페타바이트 규모의 데이터가 있다. - 모든 스키마를 LLM의 컨텍스트에 넣는 방식은 다음과 같은 한계가 있다. - 컨텍스트 윈도우가 전체 데이터 웨어하우스를 담기에 부족하다. - 컬럼 타입만으로는 실제 업무 의미를 알 수 없다. - 예를 들어 `INT64` 컬럼만 보고는 테스트 데이터와 실제 데이터의 구분, 또는 “활성 사용자”의 정의를 알 수 없다. - 테이블 수가 많을수록 모델은 비슷한 테이블 중 잘못된 대상을 선택하면서도 자신 있게 답할 수 있다. - 따라서 스키마와 LLM 사이에 도메인별 의미와 사용법을 담은 별도의 맥락 계층이 필요하다. ## Spotify 데이터 에이전트의 동작 방식 - 사용자가 자연어로 질문하면 에이전트가 다음 과정을 수행한다. - 적절한 데이터 맥락을 선택한다. - SQL을 생성한다. - 데이터 웨어하우스에서 쿼리를 실행한다. - 답변, 생성된 SQL, 사용한 출처를 함께 반환한다. - ReAct 루프를 사용해 도구 호출 결과에 따라 추론과 행동을 반복하고, 필요하면 쿼리를 수정한다. - 사용자는 결과뿐 아니라 답변이 어떻게 만들어졌는지도 확인할 수 있다. - Slack 봇, IDE와 AI 도구에서 사용할 수 있는 MCP 서버, 전용 웹 UI로 제공된다. - 관련 지식 기반이 없을 경우에도 이를 명시해 답변의 한계를 투명하게 드러낸다. - 2025년 8월 기준 2,100명 이상의 사용자가 13,000건 이상의 대화에서 활용했으며, 광고·팟캐스트·음악·오디오북·재무 등 177개 클러스터를 지원한다. ## 도메인별 클러스터 모델 Spotify는 데이터 도메인을 “클러스터”라고 부른다. 클러스터는 특정 조직, 프로젝트, 이니셔티브 또는 관심 주제를 중심으로 구성되며, 각 클러스터는 이름이 지정된 전문가 팀이 소유한다. - **데이터셋** - 관련 웨어하우스 테이블과 전체 스키마를 포함한다. - 컬럼 카디널리티, 자주 등장하는 값의 샘플, 파티션 구조 등을 프로파일링한다. - 예를 들어 `country` 컬럼에 `US`, `GB`, `SE` 등이 존재한다는 정보는 모델이 적절한 `WHERE` 조건을 작성하는 데 도움을 준다. - **질문-SQL 쌍** - 전문가가 작성하거나 검토한 질문과 SQL의 조합이다. - 단순한 예시가 아니라 해당 도메인에서 권장되는 쿼리 패턴과 데이터 의미를 가르치는 few-shot 자료로 사용된다. - **문서** - 업무 용어, 팀별로 달라지는 정의, 데이터 사용 시 주의점 등을 기록한다. - 어떤 컬럼을 사용해야 하고 어떤 컬럼을 피해야 하는지도 설명할 수 있다. - 클러스터의 범위, 포함할 테이블, 중요한 예시는 데이터 과학자와 애널리틱스 엔지니어 등 도메인 전문가가 결정한다. ## 자동 생성보다 전문가 검토가 중요한 이유 - Spotify는 데이터 웨어하우스의 과거 쿼리 기록에서 질문-SQL 쌍을 자동으로 생성하는 방법을 검토했다. - 실제 쿼리이므로 유용할 것처럼 보였지만, 큐레이터가 승인한 예시는 전체의 12.5%에 불과했다. - 나머지 87.5%에는 다음과 같은 쿼리가 포함되어 있었다. - 일회성 탐색이나 디버깅 쿼리 - 다시 사용하지 않을 임시 분석 - 잘못된 테이블을 사용한 쿼리 - 기술적으로는 맞지만 다른 사용자에게 잘못된 패턴을 가르치는 쿼리 - 쿼리 기록에는 정보가 많지만, 어떤 쿼리가 표준적인 지식인지는 자동으로 표시되지 않는다. - 따라서 AI가 데이터의 진실을 결정하도록 하지 않고, 전문가가 예시를 검토하고 정식 사례로 승인한다. - 목적은 전문가를 대체하는 것이 아니라 전문가의 판단을 재사용 가능한 형태로 확장하는 것이다. ## 클러스터의 지속적인 건강 관리 데이터 스키마와 업무 규칙은 계속 변하기 때문에, 한 번 만든 맥락이 영원히 정확한 것은 아니다. - 테이블이 교체되거나 폐기될 수 있다. - 컬럼명이 변경될 수 있다. - 비즈니스 정의와 분석 방식이 달라질 수 있다. - 기존 질문-SQL 쌍이 변경된 스키마와 호환되지 않을 수 있다. - Spotify는 여러 신호를 종합해 클러스터 건강 점수를 계산한다. - 기반 데이터의 상태 - 최근 스키마 변경 이후에도 curated pair가 유효한지 여부 - 실제 사용자가 묻는 질문을 충분히 다루는지 - 생성된 SQL을 재현할 수 있는지 - 기타 품질 및 활용 지표 - 문제가 발생하면 건강 점수가 낮아지고, 전문가에게 필요한 정비 작업이 제안된다. - 클러스터 소유자는 대시보드의 점수와 세부 신호를 보고 우선적으로 관리할 영역을 결정한다. ## 사용자 대화로 이어지는 피드백 루프 - 모든 대화와 쿼리는 기록되어 클러스터 소유자에게 전달된다. - 소유자는 질문, 답변, 생성된 SQL, 사용자 피드백을 확인할 수 있다. - 전문가가 질문-SQL 쌍을 승인하거나 문서를 보완할 때마다 이후 사용자에게 제공되는 맥락이 개선된다. - 즉, 실제 사용 과정이 새로운 품질 관리와 지식 축적의 자료가 된다. - 어시스턴트의 신뢰도는 모델 자체보다 그 모델이 참조하는 맥락의 품질과 최신성에 달려 있다. ## 실용적인 시사점 데이터 AI를 구축할 때는 모든 스키마를 한꺼번에 제공하기보다, 도메인별로 범위를 나누고 전문가가 검증한 예시와 업무 규칙을 함께 관리하는 것이 효과적이다. 또한 자동 생성된 지식은 그대로 신뢰하지 말고 사람의 검토를 거치며, 스키마 변경·사용 패턴·쿼리 재현성을 기반으로 지속적인 품질 관리를 해야 한다.

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

slackAI대규모 언어 모델모델 컨텍스트 프로토콜+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를 전사적으로 한꺼번에 도입하기보다, 반복 문의나 인시던트 보고처럼 효과를 측정하기 쉬운 업무부터 시작하는 것이 좋다. 원본 출처와 사람의 검토 절차를 반드시 포함하고, 검증된 작업 흐름은 스킬로 표준화해 점진적으로 확산하는 방식이 적절하다.

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

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

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

Nova: 코딩 에이전트를 위한 사내 플랫폼을 소개합니다

코딩 에이전트는 코드 작성뿐 아니라 CI 장애 대응, 마이그레이션, 테스트 개선 등 소프트웨어 개발 전반의 반복 업무를 지원할 수 있다. Dropbox는 대규모 모노레포와 Bazel, 사내 인프라에 맞는 실행·검증 환경을 제공하기 위해 개별 도구 대신 클라우드 기반 플랫폼인 Nova를 구축했다. Nova는 대화형 세션과 비동기 자동화 작업을 하나의 인터페이스로 통합하고, 실제 빌드·테스트 결과를 바탕으로 에이전트가 반복적으로 수정하도록 설계됐다. ## 분산된 개발 업무를 통합하는 플랫폼 - 개발 과정에는 디버깅, 의존성 업데이트, 테스트 커버리지 개선, flaky test 수정처럼 반복적이지만 중요한 작업이 많다. - 작업에 따라 상호작용 방식이 다르다. - 개발자가 직접 대화하며 진행하는 대화형 세션 - 에이전트가 백그라운드에서 실행되고 의미 있는 결과만 전달하는 비동기 작업 - Dropbox의 대규모 모노레포는 Bazel의 캐시와 원격 실행, 온프레미스 인프라에 의존한다. - 일반적인 외부 코딩 에이전트는 로컬 개발에는 적합하지만 Dropbox의 저장소 구조와 빌드·검증 경로를 자연스럽게 지원하지 못한다. - 따라서 워크플로마다 별도 AI 도구를 만드는 대신, 실행·검증·컨텍스트 처리를 공통화한 플랫폼을 선택했다. ## Nova의 실행 및 검증 방식 - 각 Nova 세션은 특정 커밋 시점의 Dropbox 코드베이스 스냅샷을 기반으로 격리된 환경에서 실행된다. - 호출자는 다음 정보를 전달할 수 있다. - 기준 커밋 - 수행할 작업 - 작업 후 실행할 검증 명령 - 검증 실패 시 계속 진행할지 여부 - 최대 반복 횟수 - 결과를 게시할 브랜치 - 기본 흐름은 다음과 같다. - 에이전트가 변경 사항 제안 - Bazel 빌드·테스트 등 실제 검증 수행 - 실패 결과를 에이전트에 전달 - 에이전트가 원인을 분석하고 수정 - 정해진 반복 횟수까지 재검증 - 단순히 그럴듯한 패치를 생성하는 데 그치지 않고, 실제 Dropbox 개발 환경에서 변경 사항이 유효한지 확인한다. - 세션은 하나의 브랜치만 사용하고 코드 게시 작업은 에이전트 외부에서 처리한다. - 활성 브랜치와 게시 상태를 예측하기 쉽다. - 테스트 실행, 리베이스 등 후속 자동화를 단순하게 유지할 수 있다. - 여러 브랜치를 에이전트가 직접 관리할 때 발생하는 기준 브랜치 선택 문제를 피할 수 있다. ## 다양한 개발 인터페이스와 확장 기능 - Nova는 여러 코딩 에이전트를 동일한 인터페이스 뒤에서 사용할 수 있도록 확장됐다. - 제공 방식은 다음과 같다. - 웹 UI 기반 대화형 세션 - CLI - API - 로컬 에이전트, 스크립트, 사내 서비스에서 병렬 작업 실행 - 장기 실행 워크플로에 AI 단계를 추가할 수 있는 헬퍼를 제공한다. - 프롬프트 평가, 관측성, 피드백 수집 기능으로 에이전트 성능을 측정하고 개선할 수 있다. - 파일 수정 외에도 로그 수집, 장애 조사, 여러 단계에 걸친 컨텍스트 유지가 필요하므로 다음 확장 기능을 포함한다. - Skills - Plugins - MCP 통합 - 관측성 시스템 접근 ## CI 장애 대응에서 시작한 적용 - Nova는 CI 실패에 대한 수정 제안을 자동화하는 문제에서 출발했다. - 예시 요청은 특정 커밋에서 CI 실패를 조사하고, 관련 Bazel 테스트를 실행하며, 실패 시 최대 5회까지 수정·재검증하는 형태다. - 검증 명령을 호출자가 명시하므로 에이전트가 변경한 코드에 필요한 컴파일·테스트 범위를 구체적으로 지정할 수 있다. - 이 방식은 “변경 제안 → 실제 검증 → 실패 원인 반영”이라는 안정적인 자동화 패턴을 만든다. ## 개발자 주도 세션 - 엔지니어는 Nova 웹 UI에서 로컬 개발을 중단하지 않고 빠른 수정이나 프로토타입을 진행할 수 있다. - Bazel 선택성 도구와 검증 명령을 결합해 변경된 코드와 관련된 컴파일·테스트 대상만 검증할 수 있다. - Slack 대화에서 바로 Nova 세션을 시작하고 해당 스레드의 논의 내용을 컨텍스트로 전달할 수 있다. - 이를 통해 문제 설명이나 팀 내 논의를 에이전트 프롬프트에 수동으로 다시 작성하는 비용을 줄인다. ## Flaky test 자동 수정 - Nova의 대표적인 운영 자동화 사례는 flaky test remediation이다. - Dropbox의 flaky 테스트 탐지 시스템인 Athena와 내부 도구 Deflaker를 결합했다. - Deflaker의 흐름은 다음과 같다. - 테스트가 성공한 사례와 실패한 사례를 수집 - 관련 로그를 Nova에 컨텍스트로 전달 - 에이전트가 가능한 근본 원인을 분석 - 수정안을 제안 - 이는 단순 코드 생성보다 로그 분석, 증거 비교, 원인 추론이 중요한 장기 실행형 워크플로에 해당한다. ## 실용적인 시사점 코딩 에이전트를 도입할 때는 에디터 플러그인 하나를 추가하는 것보다 저장소, 빌드 시스템, 테스트 인프라, 로그와 컨텍스트를 연결하는 플랫폼 설계가 중요하다. 특히 에이전트의 결과를 실제 검증 명령으로 확인하고, 실패 결과를 다시 에이전트에 제공하는 반복 루프와 예측 가능한 브랜치·게시 정책을 갖추는 것이 안정적인 자동화의 핵심이다.

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

slack옵저버빌리티CI/CD모델 컨텍스트 프로토콜+4

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

코딩은 더 이상 제약이 아니다: Spotify에서 팀과 에이전트를 위한 개발자 경험 확장 | Spotify Engineering

Spotify는 AI 코딩 에이전트 도입으로 개발 속도가 크게 향상되면서, 이제 코딩 자체보다 의사결정과 개발 경험의 확장성이 새로운 병목이 되었다고 설명합니다. 수년간 구축한 자동화 시스템, 내부 개발자 포털, 표준화된 기술 스택이 AI 에이전트의 성능과 신뢰성을 높이는 기반이 되었습니다. 그 결과 99% 이상의 엔지니어가 매주 AI 코딩 도구를 사용하고, 풀 리퀘스트 생성 빈도도 76% 증가했습니다. ## AI 코딩 도구의 폭발적인 확산 - Spotify 엔지니어의 99% 이상이 매주 AI 코딩 도구를 사용합니다. - 94%는 AI가 생산성을 높였다고 응답했습니다. - 풀 리퀘스트 생성 빈도는 76% 증가했습니다. - 대부분의 PR은 개발자와 AI 에이전트가 협업해 작성합니다. - 특히 Claude Opus 4.5 출시 이후 Claude Code 사용량이 급격히 증가했습니다. - Spotify는 과거에도 내부 생산성 도구를 꾸준히 배포했지만, AI 도구만큼 빠른 채택률은 경험하지 못했습니다. ## 에이전트 이전부터 시작된 자동화 - Spotify의 운영 코드베이스는 엔지니어 수보다 7배 빠르게 증가했습니다. - 개발자들은 기능 개발보다 다음과 같은 유지보수 작업에 더 많은 시간을 쓰게 되었습니다. - 의존성 업그레이드 - API 마이그레이션 - 보안 취약점 패치 - 특히 마이그레이션이 개발자 불만의 가장 큰 원인이었습니다. - 이를 해결하기 위해 여러 팀이 각자 수작업으로 처리하는 대신, 수백~수천 개 컴포넌트를 한꺼번에 변경하는 Fleet Management를 구축했습니다. - Fleetshift는 대상 식별, 작업 예약, 진행 상황 추적 등 전체 변경 작업을 조율합니다. - 지금까지 250만 건 이상의 자동화 유지보수 PR을 병합했으며, 대부분은 사람의 개입 없이 자동 병합되었습니다. ## Honk: 백그라운드 코딩 에이전트 - 단순한 변경에는 결정론적 스크립트가 효과적이었지만, API 교체나 대규모 리팩터링처럼 예외가 많은 작업에서는 한계가 있었습니다. - Spotify는 복잡한 스크립트를 계속 추가하는 대신 LLM이 코드 수정 작업을 수행하도록 했고, 그 결과 Honk를 만들었습니다. - Honk의 구성은 다음과 같습니다. - Claude와 Agent SDK 기반 - Spotify 자체 실행 하네스와 결합 - Kubernetes 파드에서 실행 - 여러 에이전트 세션을 클라우드에서 동시에 스케줄링 - 여러 운영체제에서 CI 빌드를 실행해 변경 사항 검증 - Fleetshift가 전체 작업을 관리하고 Honk가 실제 코드 수정을 담당합니다. - 최근 백엔드 서비스의 Java 마이그레이션은 한 명의 엔지니어가 3일 만에 완료했습니다. - 과거 수백 팀이 수주 또는 수개월에 걸쳐 수행하던 작업을 단일 엔지니어가 며칠 안에 처리할 수 있게 되었습니다. - Honk는 Slack에서도 호출할 수 있어, 대화 중 언급하면 맥락을 바탕으로 작업하고 PR을 생성합니다. - Honk v2에서는 다음 기능을 도입할 예정입니다. - 공유 에이전트 세션 - 팀 프로젝트 - Chirp를 통한 에이전트 오케스트레이션 - 여러 개발자와 에이전트의 협업 ## 에이전트에게도 필요한 개발자 경험 - Spotify는 “세계 최고 수준의 기술 영역을 적게 만들수록 더 빠르게 움직일 수 있다”는 원칙을 오래 유지해 왔습니다. - 제한된 기술 스택과 일관된 설계 패턴을 사용하면 다음 효과가 있습니다. - 팀 간 협업이 쉬워짐 - 기술 선택에 따른 불필요한 의사결정 감소 - 코드베이스에 대한 공통 전문성 향상 - 개발자와 에이전트가 참고할 수 있는 일관된 코드 증가 - Claude는 참고할 코드가 많고 그 구조가 일관될수록 더 나은 결과를 냅니다. - 반대로 코드베이스가 파편화되어 있으면 에이전트 성능도 측정 가능하게 저하됩니다. ## Backstage를 통한 통합과 표준화 - Spotify는 오픈소스 내부 개발자 포털인 Backstage를 개발 경험의 중심으로 사용합니다. - Backstage 이전에는 배포, CI, A/B 테스트 등 기능별로 약 100개의 내부 도구가 분리되어 있었습니다. - Backstage는 이를 하나의 화면으로 통합하고, 소프트웨어 컴포넌트 카탈로그를 중심으로 관리합니다. - 개발자와 에이전트 모두 Backstage에서 다음 정보를 확인할 수 있습니다. - 컴포넌트 소유 팀 - 관련 문서 - 기술 구성 - 담당자와의 커뮤니케이션 경로 - Spotify는 Backstage 기능을 MCP와 CLI 도구로 노출해 Claude도 동일한 정보를 활용하도록 했습니다. - 에이전트는 필요한 컴포넌트의 담당자를 조회하거나 문서를 읽고, Slack으로 책임 팀에 문의할 수 있습니다. ## Golden State와 자동 피드백 - Golden state는 컴포넌트 유형별 권장 기술과 개발 관행을 정의합니다. - Soundcheck는 각 팀이 자신의 컴포넌트가 표준을 얼마나 준수하는지 점검하는 UI를 제공합니다. - 정적 분석과 린팅을 결합하면 표준이 단순한 문서가 아니라 실제 가드레일로 작동합니다. - Claude가 권장되지 않는 기술이나 설계 패턴을 사용하면 린터가 즉시 피드백을 제공합니다. - 에이전트는 이 피드백을 바탕으로 스스로 코드를 수정할 수 있습니다. - 같은 피드백 루프가 개발자와 에이전트 모두에게 적용되므로, 조직 전체의 일관성을 유지하는 효과적인 수단이 됩니다. ## 실용적인 결론 AI 에이전트를 도입하려면 모델 자체보다 먼저 일관된 기술 스택, 중앙화된 컴포넌트 정보, 자동화된 검증 체계를 마련해야 합니다. 표준화된 코드베이스와 즉각적인 린트·CI 피드백이 갖춰질 때 에이전트는 대규모 마이그레이션과 유지보수 작업을 안정적으로 수행할 수 있습니다.

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

slackAI 에이전트쿠버네티스CI/CD+4

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가 담당하는 구조가 바람직하다.

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

slack생성형 AI자동화jira+4

aws·2026년 4월 27일원문

AWS 주간 정리: Anthropic과 Meta의 파트너십, AWS Lambda S3 파일, Amazon Bedrock AgentCore CLI 등 (2026년 4월 27일) | Amazon Web Services (새 탭에서 열림)

이번 AWS 주간 소식은 Anthropic 및 Meta와의 전략적 파트너십 강화와 생성형 AI 에이전트 개발을 가속화하는 기술적 진보에 초점을 맞추고 있습니다. AWS는 실리콘 레벨에서의 최적화와 서버리스 기술의 고도화를 통해 복잡한 AI 워크로드를 더 효율적으로 처리할 수 있는 환경을 구축하고 있습니다. 결과적으로 개발자들은 하 인프라의 복잡성에서 벗어나 더 정교하고 협업 중심적인 AI 애플리케이션 구축에 집중할 수 있게 되었습니다. **Anthropic 및 Meta와의 전략적 파트너십 확대** - Anthropic은 AWS Trainium 및 Graviton 인프라를 활용해 최신 파운데이션 모델을 학습시키며, 하드웨어와 소프트웨어 스택 전반의 효율성을 극대화하기 위해 Annapurna Labs와 협력합니다. - Amazon Bedrock 내에서 'Claude Cowork'가 출시되어, 기업 고객들은 AWS의 보안 환경을 유지하면서 팀 단위의 협업 AI 워크플로우를 직접 배포할 수 있습니다. - Meta는 추론, 코드 생성, 다단계 작업 오케스트레이션 등 CPU 집약적인 에이전트 중심 AI 워크로드를 위해 수천만 개의 AWS Graviton 코어를 도입하기로 합의했습니다. **Lambda 및 Aurora의 서버리스 기능 강화** - **Lambda S3 Files:** Amazon EFS를 기반으로 구축된 이 기능을 통해 Lambda 함수가 S3 버킷을 파일 시스템으로 마운트할 수 있으며, 데이터 다운로드 없이 표준 파일 작업을 수행할 수 있어 AI 모델의 메모리 유지 및 상태 공유가 용이해졌습니다. - **Aurora Serverless 성능 향상:** 새로운 플랫폼 버전 4에서는 이전보다 최대 30% 향상된 성능과 스마트 스케일링 알고리즘을 제공하며, 사용하지 않을 때는 비용이 발생하지 않는 'Scale to zero' 기능을 유지합니다. - **EKS Hybrid Nodes 게이트웨이:** 온프레미스와 클라우드 간의 복잡한 네트워크 인프라 변경 없이도 하이브리드 Kubernetes 환경의 네트워킹을 자동화하여 포드 간 통신을 간소화합니다. **AI 에이전트 개발 및 운영 효율화 도구** - **Bedrock AgentCore:** 새로운 CLI와 관리형 하네스(Managed Harness)를 도입하여 오케스트레이션 코드 없이도 모델, 프롬프트, 도구를 정의해 즉시 에이전트 프로토타입을 실행하고 이를 IaC(AWS CDK 등)로 내보낼 수 있습니다. - **세분화된 비용 할당:** Amazon Bedrock 사용량을 태그 기반으로 상세하게 추적할 수 있게 되어, 여러 팀이나 프로젝트를 운영하는 조직에서 정밀한 비용 가시성과 비용 재청구(Chargeback)가 가능해졌습니다. - **SageMaker 추론 최적화 권장:** 생성형 AI 모델 배포 시 최적의 인스턴스 타입, 컨테이너, 추론 파라미터를 자동으로 식별하여 비용을 절감하고 응답 속도를 개선합니다. **실무자를 위한 교육 및 이벤트 정보** - **무료 마이크로디그리(Microcredentials):** AWS Skill Builder를 통해 실제 라이브 환경에서 구성, 트러블슈팅, 최적화 기술을 검증하는 실무형 인증 과정을 무료로 이용할 수 있습니다. - **AWS Summit Seoul:** 오는 5월 20일 서울에서 개최되는 서밋을 포함하여 전 세계 주요 도시에서 최신 클라우드 및 AI 혁신 사례를 공유하는 오프라인 행사가 진행될 예정입니다. 생성형 AI를 실제 서비스에 적용하려는 개발자라면 Bedrock AgentCore를 통한 신속한 프로토타이핑을 시도해보고, 비용 최적화를 위해 Graviton 기반 인스턴스와 SageMaker의 추론 권장 기능을 적극적으로 활용해 보시기 바랍니다.

slack쿠버네티스생성형 AIPostgreSQL+4

line·2026년 4월 8일원문

AI 활용의 열쇠는 '조직적 학습'에 있다 - Orchestration Development Workshop의 시작 (새 탭에서 열림)

LY Corporation은 AI 도입 초기 단계를 넘어, 여러 AI를 유기적으로 연계하여 엔지니어의 창의성을 극대화하는 ‘오케스트레이션 개발 워크숍(Orchestration Development Workshop)’을 본격적으로 시작했습니다. 이 워크숍은 단순한 도구 활용을 넘어 AI와 협업하는 조직으로 진화하기 위한 실무 중심의 배움터로, 반복적인 업무를 자동화함으로써 엔지니어가 보다 가치 있는 설계와 창의적 활동에 집중할 수 있는 환경을 구축하는 것을 최종 목표로 합니다. **여러 AI를 연계하는 ‘오케스트레이션’ 개발 방식** * AI 오케스트레이션은 단일 도구 사용을 넘어, 여러 AI를 조합해 복잡한 개발 프로세스를 일괄 수행하는 '협주형' 개발 방식을 의미합니다. * 주요 사례로 Jira 티켓 기반 코드 자동 생성, 테스트 및 리뷰 수행, Pull Request(PR) 작성까지 AI가 연속적으로 처리하는 워크플로우를 제안합니다. * Slack을 통해 접수된 장애 보고를 바탕으로 AI가 원인을 추정하고 즉각적인 수정안을 제시하는 등 실전적인 대응 모델을 포함합니다. **지속적인 지식 확산을 위한 3단계 조직 구조** * 특정 개인의 열정에만 의존하지 않고 조직 전체가 성장할 수 있도록 ‘추진(DevRel)’, ‘현장 인사이트(길드)’, ‘품질 보증(TD)’의 체계적인 협력 구조를 구축했습니다. * DevRel 조직은 프로젝트의 운영과 전사적 확산을 담당하며 지식 전파의 엔진 역할을 수행합니다. * 현장 엔지니어로 구성된 길드가 실무 지식을 제공하고, TD(Technical Director)가 콘텐츠의 품질과 재현성을 검증하여 교육의 신뢰도를 높입니다. **실무 재현성을 극대화한 양방향 학습 설계** * ‘보기만 하다 끝나지 않는다’는 슬로건 아래, 참가자가 발표자의 화면을 보며 실시간으로 따라 하는 핸즈온(Hands-on) 실습 환경을 제공합니다. * Zoom을 통한 실시간 대화와 Slack을 활용한 질문 수집을 병행하여, 학습 과정에서 발생하는 과제를 그 자리에서 즉시 해결하는 양방향 소통을 지향합니다. * 단순한 지식 전달을 넘어 각 엔지니어가 자신의 실제 프로젝트에서 AI 오케스트레이션을 재현할 수 있는 실질적인 기술 습득에 초점을 맞춥니다. **엔지니어의 창의성 해방과 미래 전망** * AI 활용의 본질은 단순한 작업 속도 향상이 아니라, 엔지니어를 반복 작업에서 해방시켜 고부가가치 설계 영역에 집중하게 만드는 것입니다. * 생성형 AI뿐만 아니라 비생성형 AI까지 아우르는 폭넓은 주제를 다루며, 사내에서 축적된 AI 주도 개발 노하우를 기술 블로그 등 외부 채널을 통해 적극적으로 환원할 예정입니다. AI가 코드를 작성하고 인간이 리뷰하는 단계를 넘어, 설계 단계부터 AI와 긴밀히 협업하는 시대가 오고 있습니다. 이제 엔지니어는 개별 코딩 기술에 매몰되기보다 여러 AI를 조율하고 제어하는 '오케스트레이터'로서의 역량을 갖추는 것이 필수적입니다. LY Corporation의 사례처럼 실무 중심의 핸즈온 학습을 통해 AI와 함께 만드는 조직 문화를 선제적으로 경험해 보길 추천합니다.

slackAI데이터베이스 설계PostgreSQL+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로 설정하고 외부 시스템을 유연하게 연결하는 아키텍처를 고민해 보시기 바랍니다.

slack데이터베이스 설계jiraredis+4