노동은 줄이고 흐름은 늘리기 - 요청부터 구현까지의 경로 자동화

최근 저희 조직은 대대적인 구조 개편을 겪었습니다. 불과 몇 주 만에 저희 팀의 규모는 두 배로 커졌고 책임 범위도 배로 늘어났습니다. 소수의 AWS 계정을 지원하던 수준에서 여러 제품 라인에 걸친 인프라를 소유하게 되었고, (다른 인프라 팀들과 함께) 여러 클라우드 제공업체를 관리하며 여러 국가에 분산된 수백 명의 엔지니어를 지원하게 되었습니다.

조직 개편과 함께 저희가 선택하지 않은 변화들도 찾아왔습니다. 그중 하나는 Jira에서 Linear로 전환하는 것이었습니다 (솔직히 말해서, 저는 환영합니다). 또 다른 변화는 확장성이 떨어지는 협업 프로세스를 물려받게 된 것이었습니다.

이러한 새로운 멀티 클라우드 (multi-cloud) 환경에서, 클라우드 운영 (cloud-ops) 엔지니어들은 제품 팀 엔지니어들이 Linear에 직접 티켓을 생성하는 것을 꺼려했습니다. 백로그 (backlog)가 지저분해지거나 잘못된 팀(AWS? GCP? Azure?)에 요청이 전달될 것을 우려했기 때문입니다. 그래서 기본 방식은 공유 채널에 간단한 Slack 메시지를 게시하는 것이 되었습니다. 플랫폼 도메인의 누군가가 이를 읽고, *머릿속으로 분류 (triage)*한 뒤에야 비로소 적절한 팀을 위해 Linear에 수동으로 티켓을 생성했습니다.

이 프로세스는 최근 양식을 통해 요청을 구조화하는 Slack Workflow를 추가함으로써 이미 개선된 상태였습니다. 여전히 분류 (triage)가 필요한 Slack 메시지 형태였지만, 적어도 관련 정보가 깔끔하게 정리되어 제공되었습니다.

저는 여기서 더 나아갈 수 있다고 생각했습니다. 철저하게 자동화하여, 무엇보다도 수동적인 노동 (toil)과 소음을 줄이는 것입니다.

AI 지원을 통한 요청부터 구현까지의 흐름

저의 목표는 간소화된 파이프라인 (pipeline)을 구축하는 것이었습니다:

1. Slack이 프론트 도어 (front door) 역할을 유지합니다: 엔지니어들이 Linear를 직접 만지거나 어떤 팀/워크스페이스를 대상으로 해야 하는지 알 필요가 없습니다.
2. **자동화 (Automation)**가 요청을 적절한 팀의 구조화된 티켓 (ticket)으로 변환합니다 (AI가 일부 추가적인 컨텍스트를 채워 넣습니다).
3. **AI 지원 트리아지 (AI-assisted triage)**를 통해 티켓이 완전하고, 적절하게 라벨링되었으며, 실행 가능한 상태인지 확인합니다.
4. **명세 기반 개발 (Spec-driven development)**은 잘 기술된 티켓을 누구나 바로 맡아서 할 수 있는 요구사항과 작업 (task)으로 전환합니다.

사용된 도구: Slack Workflows, Linear Slack Integration, Linear MCP 서버, 그리고 두 가지 커스텀 스킬(Ticket Triage 및 Platform Support)을 갖춘 Kiro

1단계: 프론트 도어로서의 Slack

초기에 팀들의 마찰을 줄이기 위해 (종종 문화적/조직적 변화가 수행하기 가장 어렵고 시간이 많이 걸립니다), 우리는 기존의 MultiCloud 채널을 그대로 유지하기로 결정했습니다.
우리는 프로세스를 하루아침에 중단시키고 싶지 않았기에, 요청을 전달하는 과정을 단순화할 몇 가지 규칙을 추가했습니다 (Slack Workflows는 매우 단순하면서도 트리거 유형, 양식 열기, 입력된 데이터 조작, 채널로 전달, 또는 다른 무언가를 트리거하는 것과 같은 여러 작업의 체이닝 (chaining) 등 매우 높은 수준의 커스터마이징을 허용합니다).

• 우리는 기존 워크플로우를 수정하여, 클라우드 제공업체 (Cloud Provider)를 알 수 있는 경우(또는 리포지토리 이름 등을 통해 추론할 수 있는 경우) 해당 정보를 명시하도록 했습니다. 예를 들어, 리포지토리 이름이 aws-terraform-modules라면 어떤 제공업체일지 짐작할 수 있을 것입니다.
• 우리는 요청 후(또는 Slack 대화 중에) 적절한 클라우드 제공업체 이모지를 사용하는 것만으로도 해당 팀을 자동으로 호출(ping)하는 또 다른 워크플로우를 추가했습니다
  

이를 통해 초기 수동 분류(triage)가 빨라졌고, 사람들은 적절한 팀을 직접 지정하는 데 익숙해졌습니다. 그 후, 대부분의 주제(데이터베이스 액세스 요청, S3 버킷 액세스 권한, 또는 Terraform 코드를 수정하기 위한 PR 생성 등)에 대해 요청자는 관련 클라우드 제공업체/플랫폼 팀이 AWS인지 GCP인지 알 수 있었기 때문에, 우리는 점진적으로 **전용 채널(dedicated channel)**로 이동하였고, 공유 채널은 전환기 동안(또는 소유권이 여전히 불분명한 요청, 예를 들어 Cloudflare, Datadog infrastructure-as-code 리포지토리 등)에만 남겨두었습니다.

워크플로우 트리거하기 (Triggering the workflow)

저희의 경우 채널에 명시적인 버튼을 유지하기로 선택했습니다.

하지만 워크플로우는 간단한 단축키로도 작동합니다. 채널의 메시지 입력창에 /aws를 입력하기만 하면 양식이 나타납니다.

양식은 필수 사항을 묻습니다: _무엇_이 필요한지, 왜 필요한지, 그리고 _얼마나 긴급한지_입니다. 제출되면 내용은 가시성을 위해 채널에 게시된 후, Linear Slack AI 연동을 통해 Linear로 라우팅됩니다.

왜 Linear의 기본 Slack 연동을 사용하지 않았나요?

Linear의 표준 Slack 연동(/linear)은 어떤 팀, 프로젝트, 라벨을 선택해야 하는지 이미 알고 있는 엔지니어들에게는 잘 작동합니다. 하지만 멀티 클라우드 플랫폼 조직 전반에 걸쳐 요청을 제출하는 이해관계자(stakeholders)들에게는 충분하지 않았습니다. 가장 중요한 점은 양식 필드가 너무 경직되어 있었다는 것입니다(우리의 사이클, 라벨, 그리고 관심사(concerns) 커스터마이징이 부족함). 이로 인해 티켓이 제대로 설명되지 않은 채 생성되는 결과가 초래되었습니다.

Slack Workflow를 통해 라우팅하고 AI가 양식(form) 내용을 분석하게 함으로써, 우리는 **더 풍부한 티켓(richer tickets)**을 얻을 수 있습니다. AI는 컨텍스트(context)를 추가하고, 구조를 추론하며, (우리가 추정 및 우선순위 지정에 활용할 수 있는) 가장 관련성 높은 영역에 티켓 내용을 채워 넣습니다.

2단계: AI 지원 트리아지(Triage): 티켓을 실행 가능하게 만들기

이 부분부터 상황이 더욱 흥미로워집니다. 특히 AI 네이티브 SDLC(Software Development Life Cycle)와 AI 도구 활용 측면에서 더욱 그렇습니다.

트리아지(triage)란 정확히 무엇인가요?

이 용어는 응급 의학에서 유래되었습니다. 간호사가 각 환자의 상태를 짧게 평가하여 위험도와 긴급도를 결정하고, 실제 치료를 수행하지 않은 채 환자를 적절한 곳으로 배치하는 것을 의미합니다.

소프트웨어 트리아지(Software triage)도 동일한 방식으로 작동합니다. 아직 문제를 해결하는 단계가 아니라, 문제가 충분히 이해되었는지, 올바르게 우선순위가 지정되었는지, 그리고 누군가 작업을 시작할 수 있도록 적절한 큐(queue)에 놓여 있는지를 확인하는 과정입니다.

저희의 경우, 티켓이 트리아지(Triage) 수신함에 도착하면 검토가 필요합니다. 실행 가능한가? 우선순위가 현실적인가? 들리는 것처럼 정말로 심각한 차단 요소(blocker)인가, 아니면 단순히 다음 사이클로 계획을 잡을 수 있는 사항인가? (종종 메시지는 지나치게 극적이며, 설정되거나 추론된 우선순위와 마감일이 일치하지 않는 경우가 많습니다.) 라벨(labels)이 정확한가? 설명(description)에 누군가 작업을 시작하기에 충분한 정보가 포함되어 있는가?

티켓-트리아지 기술(Ticket-Triage Skill)

저는 이것을 처음에는 Kiro Agent로 구축한 다음, Kiro를 사용하지 않는 동료들도 혜택을 누릴 수 있도록 Agent Skill로 변환했습니다.

사실 저는 커스텀 서브 에이전트(sub-agents)를 만들고 사용하는 것을 즐기지만, 많은 상황에서 스킬(skills)이 더 유용하다는 것을 깨닫기 시작했습니다 (steering files보다 더 나은 컨텍스트 관리, 단순 프롬프트보다 더 많은 컨텍스트 제공, 그리고 반복되는 제한적인 작업을 위해 에이전트를 교체할 필요가 없다는 점 등. 유일하게 부족한 점은 MCP 서버와 허용된 도구의 자동 설정뿐입니다).

이 스킬은 Linear MCP server를 통해 Linear에 연결되어 티켓을 가져온 후, 다음과 같이 구조화된 평가를 수행합니다:

• 이슈 분류 (Issue classification): 보고자가 추측한 내용이 아니라 콘텐츠 신호를 기반으로 올바른 유형(story, bug, support-request, technical-improvement, spike, security)을 결정합니다.
• 우선순위 평가 (Priority assessment): 일관된 척도(Urgent = 운영 중단; High = 작업 차단; Normal = 표준 기능; Low = 있으면 좋은 기능)에 따라 평가합니다.
• 불일치 탐지 (Discordance detection): 어조와 우선순위, 설명과 긴급도, 또는 우선순위와 마감일 사이의 불일치를 포착합니다. 마감일이 3주 남았는데 당황한 듯한 "URGENT!!!" 메시지가 있거나, 실제 운영 차단 요소를 숨긴 차분한 설명이 있는 경우 이를 플래그(flag)로 표시합니다.
• 완결성 평가 (Completeness evaluation): 명확한 문제 정의, 수락 기준(acceptance criteria), 올바른 라벨, 적절한 추정치, 의존성, 그리고 가장 중요한 요소인 "이유"(비즈니스 가치 또는 사용자 니즈)가 있는지 확인합니다.
• 관심 영역 매핑 (Concern mapping): 어떤 인프라 영역(networking, compute, storage, CI/CD, observability, security, Iaac)이 연관되어 있는지 식별하고 적절한 라벨을 적용합니다.
• 정제 가이드 (Refinement guidance): 티켓이 준비되지 않은 경우, 기억이 생생할 때 보고자에게 다시 질문을 던질 수 있도록 구체적인 질문을 생성합니다.

내부 구조: 스킬이 구성되는 방식

Kiro Skill은 본질적으로 프론트매터 (frontmatter) 메타데이터와 상세한 프롬프트 (prompt) 역할을 하는 본문으로 구성된 구조화된 마크다운 파일 (SKILL.md)입니다. 즉, 스킬이 활성화되었을 때 AI 에이전트가 따르게 되는 일련의 지침, 결정 트리 (decision trees), 그리고 참조 데이터 (reference data)의 집합입니다.

Triage Skill이 포함하고 있는 내용은 다음과 같습니다:

1. 프론트매터 (Frontmatter): Kiro가 스킬을 언제 활성화할지 알려주는 이름 (name), 설명 (description), 그리고 트리거 키워드 (trigger keywords)입니다:

---
name: triage-ticket
description: Triage and refine Linear issues through structured analysis.
...

2. 선행 조건 (Prerequisites): 해당 스킬이 의존하는 MCP 서버들입니다. 우리의 경우, 티켓을 가져오고 업데이트하기 위해 Linear MCP 서버가 필수적이며, 구현 제안 과정에서의 리포지토리 탐색을 위해 GitHub MCP 서버는 선택 사항입니다:

{
  "mcpServers": {
    "linear": {
...

3. 단계별 워크플로 (A step-by-step workflow): 스킬은 구조화된 분류 프로세스 (가져오기 → 분류 → 우선순위 평가 → 불일치 감지 → 완전성 평가 → 보고서 생성 → 컨텍스트 조사 → 개선)를 정의합니다. 각 단계에는 명시적인 지침, 결정 테이블 (decision tables), 그리고 출력 형식 (output formats)이 포함되어 있습니다. 예를 들어, 불일치 감지 (discordance detection) 단계에는 신호 패턴 테이블이 포함됩니다:

**Tone vs Priority**: Look for urgent language ("ASAP", "critical",
"immediately", "blocking") paired with Normal/Low priority, or
casual/exploratory language with Urgent/High priority.
...

4. 참조 테이블 (Reference tables): 관심사 매핑 키워드 (concern mapping keywords), 우선순위 척도 (priority scales), 마감일 가이드라인 (due date guidelines), 추정 범위 (estimate ranges), 그리고 라벨 정의 (label definitions)를 다룹니다. 이는 AI가 일반적인 지식에 의존하는 대신 일관된 기준을 갖도록 합니다:

관심사 (Concern)	키워드 (Keywords)
네트워킹 (Networking)	VPC, DNS, load balancer, ingress, service mesh
...

5. 안전 규칙 (Safety rules): "원본 설명을 절대 덮어쓰지 말 것", "수정하기 전에 항상 질문할 것", "구현 제안은 인라인 (inline)이 아닌 주석 (comment)에 작성할 것"과 같은 명시적인 제약 조건입니다. 이러한 규칙은 AI가 변경 사항을 과도하게 공격적으로 적용하는 것을 방지합니다.

6. 스킬 구성 (Skill composition): 분류 (triage) 스킬은 7단계 동안 플랫폼 지원 (platform-support) 스킬을 명시적으로 호출 (calls) 합니다. 이는 스킬 본문 내에 의존성 (dependency)으로 선언됩니다:

## 의존성 (Dependency): platform-support 스킬

이 스킬은 분류 (triage) 과정 중에 `platform-support` 스킬을 활성화합니다.
...

이러한 구성 패턴은 강력합니다. 각 스킬은 자신의 도메인에 집중하면서도, 더 풍부한 결과물을 위해 서로 체인 (chain)처럼 연결될 수 있습니다. 분류 (triage) 스킬은 무엇 (what) 과 왜 (why) 를 처리하고, 플랫폼 지원 (platform-support) 스킬은 어디서 (where) 와 어떻게 (how) 를 처리합니다.

분류 (triage) 스킬이 의존하고 있는 플랫폼 지원 (platform-support) 스킬은 본질적으로 우리 인프라의 살아있는 지도 (living map) 입니다.