실제 CI 자동화 사례와 함께

루프 엔지니어링 (Loop Engineering)이 갑자기 어디에서나 들려오고 있습니다. 솔직히 말해서, 저는 단순히 유행어를 따라 하는 대신 이를 제대로 이해하고 싶었습니다. 제가 루프 엔지니어링을 설명할 수 있는 가장 간단한 방법은 이것입니다: 루프 엔지니어링은 에이전트 (agent)에게 끊임없이 프롬프트 (prompt)를 입력하는 사람으로서의 저를 대체합니다.

제가 수동으로 문제를 인지하고, 그것이 무엇을 의미하는지 결정하고, 다음 프롬프트를 작성하고, 프로세스를 앞으로 밀어붙이는 대신, 저는 제가 원하는 결과에 도달할 때까지 스스로 계속 움직이는 시스템을 설계합니다. 그것이 루프 엔지니어링의 핵심입니다. 저는 운영자 (operator)처럼 행동하는 것을 멈추고 시스템 설계자 (system designer)처럼 행동하기 시작합니다.

이 아이디어를 구체화하기 위해, 저는 CI 실패를 중심으로 실질적인 소프트웨어 엔지니어링 워크플로우 (workflow)를 구축했습니다. GitHub Actions CI 실행이 실패할 때마다, 시스템은 자동으로 실패를 분류하고, 실제 문제에 대해 Jira 버그를 생성하며, Slack 알림을 보내고, 동일한 실패를 두 번 처리하지 않도록 결과를 기록합니다.

루프 엔지니어링이 실제로 의미하는 것

초기 AI 워크플로우 (workflows)는 대부분 선형적이었습니다. 제가 프롬프트를 주면 모델 (model)이 답변을 반환하고, 만약 답변이 불완전하거나 틀렸다면 제가 다시 개입하여 다시 프롬프트를 입력했습니다. 그것도 작동은 했지만, 저를 프로세스 안에 갇히게 만들었습니다.

루프 엔지니어링은 그 역학 관계를 바꿉니다. 저는 더 이상 각 단계를 돌보는 사람이 아닙니다. 저는 관찰하고, 결정하고, 행동하며, 상태 (state)를 유지할 수 있는 자율적인 루프 (autonomous loop)를 구축합니다. 시스템은 제가 마이크로매니징 (micromanage)할 필요 없이 작업이 완료될 때까지 계속 반복합니다.

그 차이가 중요합니다. 일반적인 프롬프트 기반 워크플로우 (prompt based workflow)에서는 인간이 여전히 접착제 역할을 합니다. 루프 엔지니어링에서 인간은 기계를 만들고, 기계가 루프를 실행합니다.

루프 엔지니어링의 5가지 구성 요소

제가 루프 엔지니어링 (Loop Engineering)을 분석할 때, 저는 이를 함께 작동하는 다섯 가지 핵심 구성 요소 (building blocks)로 생각합니다.

1. 자동화 (Automations)
이것들은 전체 시스템을 시작하는 이벤트 기반 트리거 (event driven triggers)입니다. 이것들은 루프의 심장 박동과 같습니다. 어떤 일이 발생하면 자동화가 실행됩니다. 이것이 없다면 아무것도 시작되지 않습니다.

2. 기술 (Skills)
기술은 에이전트 (agent)에게 구조화된 컨텍스트 (context)를 제공합니다. 에이전트가 매번 팀의 관례를 다시 발견하도록 강요하는 대신, 저는 해당 컨텍스트를 한 번 인코딩하여 에이전트가 동일한 가정을 바탕으로 반복해서 작동할 수 있도록 합니다.

3. 하위 에이전트 (Sub-agents)
이 부분에서 시스템은 더욱 견고해집니다. 하나의 에이전트가 출력을 생성하면, 다른 에이전트가 이를 검증하거나 분류할 수 있습니다. 생성 (generation)과 검증 (validation)은 항상 동일한 작업이 아니기 때문에 이러한 분리는 유용합니다.

4. 커넥터 (Connectors)
커넥터는 루프가 실제 세상에서 행동할 수 있게 해주는 요소입니다. 시스템 내부의 결정은 Jira, Slack, GitHub 또는 다른 플랫폼과 같은 외부 요소를 트리거할 수 있을 때만 가치가 있습니다.

5. 상태 파일 (State files)
상태 (State)는 메모리입니다. 이는 루프가 이미 처리한 내용을 기억하도록 도와줍니다. 이를 통해 중복 처리와 반복적인 작업을 방지합니다. 지속적인 상태 (persistent state)가 없다면 시스템은 소란스럽고 신뢰할 수 없게 될 수 있습니다.

왜 CI 실패 사례를 사용했는가

저는 루프 엔지니어링을 단순한 장난감 데모가 아닌 실제 사례에 적용하고 싶었습니다. 지속적 통합 (CI, Continuous Integration)은 팀들이 항상 CI 실패를 겪고, 후속 작업의 상당 부분이 반복적이기 때문에 완벽한 예시입니다.

GitHub Actions에서 CI 실행이 실패할 때 보통 발생하는 일은 다음과 같습니다:

• 누군가가 실패를 인지합니다.
• 누군가가 이것이 불안정한 테스트 (flaky test)인지, 환경 문제인지, 아니면 실제 버그인지 확인합니다.
• 누군가가 Jira 이슈를 생성합니다.
• 누군가가 Slack 메시지를 보냅니다.
• 누군가가 해당 이슈가 이미 처리되었는지 추적합니다.

이것이 바로 수동적인 노고 (manual toil)입니다.

이런 상황에서는 노고 (toil)를 바라보는 Google SRE의 사고방식이 유용합니다. 노고 (toil)란 팀의 규모에 따라 선형적으로 증가하는 반복적인 수동 작업 (manual work)을 의미합니다. 엔지니어링 조직이 성장함에 따라 CI 실패도 함께 증가합니다. 만약 이를 처리하는 과정이 여전히 매일 똑같은 지루한 단계를 수행하는 인간에게 의존한다면, 그 비용은 감당하기 어려울 정도로 커집니다.

따라서 저의 목표는 간단했습니다. 루프 엔지니어링 (Loop Engineering)을 통해 그러한 노고 (toil)를 가능한 한 많이 제거하는 것이었습니다.

내가 구축한 루프

루프는 다음과 같이 작동합니다.

• GitHub Actions에서 CI 실행이 실패합니다.
• 자동화 (automation)가 자동으로 트리거됩니다.
• AI가 실패 원인을 분류 (classify)합니다.
• 만약 그것이 일시적인 오류 (flake)라면, 시스템은 이를 기록하고 Jira 단계를 건너뜁니다.
• 만약 그것이 실제 버그 (real bug)라면, 시스템은 Jira 티켓을 생성합니다.
• 시스템은 상세 정보가 담긴 Slack 알림을 보냅니다.
• 결과는 영구적인 상태 (persistent state)로 다시 기록되어, 동일한 실패가 두 번 처리되지 않도록 합니다.

이것이 바로 **루프 엔지니어링 (Loop Engineering)**의 매우 실용적인 예시입니다. 중간에 수동 프롬프팅 (manual prompting)이 없습니다. 사람이 실패를 알아차릴 때까지 기다릴 필요도 없습니다. 반복적인 인수인계 (handoffs)도 없습니다.

실제 워크플로우의 동작 방식

저는 이 워크플로우를 에이전트 기반 SDLC 플랫폼인 Port.io에서 구축했습니다. 흥미로운 점은 제품 홍보가 아닙니다. 흥미로운 점은 이 플랫폼이 자동화 (automations), 워크플로우 (workflows), AI 분류 (AI classification), 그리고 외부 시스템을 연결할 수 있는 깔끔한 방법을 제공했다는 것입니다.

제가 만든 워크플로우는 본질적으로 CI 실패 처리를 위한 7개 노드 (node) 프로세스입니다. 워크플로우 실행이 변경되면, 시스템은 CI 실패를 분류 (classify)합니다. 그 후, 분류 결과에 따라 분기 (branch)됩니다.

실패가 일시적인 오류 (flake)로 처리되면, 로그가 기록되고 Jira 단계는 건너뜁니다. 만약 분류 결과가 버그 (bug)라면, Jira 버그를 생성하고 Slack으로 알림을 보내며, Port의 실행 상태 (run status)를 업데이트합니다.

이 지점에서 루프 엔지니어링 (Loop Engineering)은 단순한 이론 그 이상이 됩니다. 루프는 단순히 결정을 내리는 것에 그치지 않습니다. 도구 전반에 걸쳐 조치를 취하고 그 결과를 다시 시스템에 기록하는 것입니다.

논점을 증명하는 실제 사례

설정을 테스트하기 위해, 저는 GitHub 저장소의 README 파일을 수정하고 main 브랜치에 직접 커밋하여 CI 실패를 유도했습니다. 제 설정에서 해당 변경 사항은 의도적으로 실패를 시뮬레이션하는 CI 워크플로우 (workflow)를 시작하기에 충분했습니다.

CI 실행이 실패하자, 연쇄 반응이 자동으로 일어났습니다.

Port 내부에서 새로운 워크플로우 실행 (workflow run)이 나타났습니다. 시스템은 실패를 감지하고, 이를 분류한 뒤, 자동화 경로를 따라 계속 진행했습니다.

그 후 Jira에서 버그가 자동으로 생성되었습니다. 해당 이슈에는 다음과 같은 유용한 세부 정보가 포함되었습니다:

• AI 분류 (AI classification)
• 신뢰 수준 (Confidence level)
• CI 실패 요약 (Summary of the CI failure)
• 워크플로우 이름 (Workflow name)
• 브랜치 (Branch)
• 커밋 (Commit)
• 수행자 (Actor)
• 실행 URL (Run URL)
• Port 엔티티 참조 (Port entity reference)

그리고 Slack에는 동일한 핵심 세부 정보와 함께 GitHub, Jira, Port로 연결되는 링크가 포함된 알림이 도착했습니다.

그 순간이 바로 루프 엔지니어링 (Loop Engineering)이 진정으로 작동하는 순간입니다. 제가 중간에 개입하지 않아도 실패가 발생하고, 시스템이 그에 대해 추론하며, 조치를 취하고, 결과를 기록했습니다.

이것이 처음 생각하는 것보다 더 중요한 이유

많은 사람들이 "자율 워크플로 (autonomous workflow)"라는 말을 들으면 단순히 편리함을 의미한다고 생각합니다. 하지만 저는 그 이상의 의미가 있다고 생각합니다.

새벽 3시에 CI 실패가 발생하는 상황을 상상해 보세요. 보통은 나중에 누군가가 이를 인지하고, 조사하고, 무엇을 할지 결정해야 합니다. 이러한 지연은 특히 실패가 쌓일 때 팀의 속도를 늦출 수 있습니다. 하지만 루프 엔지니어링 (Loop Engineering) 접근 방식을 사용하면 첫 번째 대응이 즉시 이루어집니다.

설령 루프가 아직 문제를 완전히 해결하지 못하더라도, 지루한 운영 오버헤드 (operational overhead)를 제거해 줍니다:

• 탐지 (Detection) 자동화
• 분류 (Triage) 자동화
• 라우팅 (Routing) 자동화
• 알림 (Notification) 자동화
• 상태 추적 (State tracking) 자동화

이것만으로도 이미 엄청난 이득입니다. 그리고 루프가 충분히 성숙해지면, 보고를 넘어 복구 (remediation) 단계로 잠재적으로 확장될 수 있습니다.

이를 구축하기 위해 필요했던 것

사전 요구 사항은 꽤 간단했습니다.

• Port.io 계정
• GitHub 계정 및 리포지토리 (repository)
• GitHub의 CI 워크플로 (workflow)
• CI 실행 메타데이터 (metadata)를 Port로 보고하는 워크플로
• Jira 프로젝트 및 자격 증명 (credentials)
• Slack 앱 및 봇 토큰 (bot token)
• 두 개의 GitHub 워크플로 파일

저는 리포지토리에 두 개의 YAML 파일을 사용했습니다.
첫 번째는 메인 CI 파이프라인 (pipeline)입니다. 이 파일은 제가 데모에서 사용한 것과 같은 종류의 변경을 수행할 때 테스트 실패를 시뮬레이션합니다.

두 번째는 Port CI 리포터 (reporter) 워크플로입니다. 이 워크플로의 역할은 CI 실행이 완료된 후 실행되어, 실행 메타데이터를 단일 업서트 (upsert)로 Port에 전송하는 것입니다. 해당 메타데이터에는 워크플로 이름, 브랜치 (branch), 커밋 메시지 (commit message), 작업자 (actor), 실행 URL과 같은 정보가 포함됩니다.

이 두 번째 파일은 GitHub를 루프 엔지니어링 (Loop Engineering) 시스템으로 연결하는 가교 역할을 하기 때문에 매우 중요합니다.

Port 내부의 연결 구조

Port 내부에는 몇 가지 주요 설정 구성 요소들이 있었습니다.

1. 데이터 소스 (Data sources)

Port가 워크플로우 실행(workflow run) 정보를 동기화할 수 있도록 GitHub와 CI CD 워크플로우 실행 데이터 소스를 연결했습니다.

2. 셀프 서비스 액션 (Self-service action)