GitLab Duo Agent Platform Hackathon 2026 에서 Honorable Mention을 수상했습니다. 총 $65,000 의 상금 풀과 6,971 명의 참가자가 참여한 글로벌 대회였습니다. 프로젝트명은 Carbon Tracker이며, 저는 Sustainable Agent Category에서 우승했습니다. 혼자서 만들었습니다. 5 일 만에. GitLab 에 대한 사전 경험은 전혀 없었습니다. 이것이 바로 전 이야기입니다 — 제가 무엇을 만들었는지, 왜 만들었는지, 어떻게 작동하는지, 그리고 배운 모든 것. 🌍 대부분 사람들이 말하지 않는 문제 저는 실패한 CI/CD 파이프라인을 검토 중일 때 생각이 들었습니다: 이 파이프라인은 단순히 3 회 재시도했습니다. 그 과정에서 얼마나 많은 전기를 낭비했을까요? 그런 질문에 답할 수 있는 도구를 찾았습니다. 존재하지 않았습니다. GitLab 기능도 없었고, 제 3 자 플러그인도 없으며, 오픈 소스 프로젝트도 없었습니다. 개발자들은 파이프라인 속도, 테스트 커버리지, 코드 품질에 집착하지만, CI/CD 인프라의 탄소 발자국은 완전히 눈에 띄지 않습니다. 이것이 바로 문제의 규모입니다: 소프트웨어 산업이 전 세계 탄소 배출량의 2~3% 를 기여합니다. 10 명의 개발자가 하루에 20 개의 파이프라인을 실행하면 CO2 약 1 톤 — 파이프라인에서만 매년 배출됩니다. 한 번의 불완전한 테스트가 2 회 재시도되고, 하루에 20 회 실행되면 = 연간 440 kg CO2 — 하나의 테스트에서 발생합니다. 아무도 모릅니다. 아무도 추적하지 않습니다. 그런 도구는 존재하지 않습니다. 지금까지는. 🌱 Carbon Tracker 는 무엇인가요? Carbon Tracker 는 GitLab Duo Agent Platform 을 기반으로 한 3 에이전트 AI 플로우입니다. 다음 기능을 수행합니다: 🔁 GitLab Issue 나 MR 에서 언급할 때 트리거됩니다. 📊 물리 기반 에너지 모델을 사용하여 작업당 CO2 배출량을 계산합니다. 🤖 Claude (Anthropic) 를 사용하여 낭비 패턴을 감지하고 팁을 생성합니다. 💬 MR/Issue 댓글로 완전한 지속 가능성 보고서를 자동으로 게시합니다. 전체 프로젝트는 2 개의 YAML 파일입니다. 서버, 데이터베이스, 유지보수할 인프라가 없습니다. ⚙️ 아키텍처 — 3 에이전트가 어떻게 협력하는지 사용자가 Issue 나 MR 에서 @ai-carbon-tracker-flow 를 언급합니다 ↓ Agent 1: pipeline_fetcher 도구: get_merge_request, list_merge_requests → 작업 이름, 지속 시간, 상태를 가져옵니다 ↓ Agent 2: carbon_calculator → 에너지 모델을 적용합니다. → 낭비 패턴을 감지합니다. → 완전한 마크다운 보고서를 생성합니다 ↓ Agent 3: report_publisher 도구: create_merge_request_note, create_issue_note → MR/Issue 댓글로 보고서를 게시합니다 ↓ Report Live ✅ 각 에이전트는 하나의 작업만 수행합니다. 플로우 정의에서 from/as bindings 를 통해 출력이 다음으로 전달됩니다. 이것은 진정한 멀티 에이전트 오케스트레이션입니다 — 챗봇이 아닙니다. 🔬 탄소 모델 — 간단한 수학, 실제 영향 핵심 로직은 한 문장으로 설명할 수 있습니다: 서버는 전기를 사용합니다. 전기는 CO2 를 생성합니다. 각 작업의 실행 시간을 알고 있으므로 CO2 를 계산할 수 있습니다. 단계 1 — Ener

일 작업당 소비된 에너지 (gy): E(kWh) = (duration_seconds / 3600) × (150W / 1000)

Step 2 — CO2 emitted per job: CO2(g) = E(kWh) × 475

Step 3 — Waste multiplier for retried jobs: CO2_total = CO2_job × (1 + N_retries)

Constants used:

Real example: test:unit ran 45 minutes
45 ÷ 60 = 0.75 hours
0.75 × 150W = 112.5 Wh
112.5 ÷ 1000 = 0.1125 kWh
0.1125 × 475 = 53.4g CO2 = Driving 0.35 km in a car From one job. One pipeline. One day.

📊 Real Output From a Real Pipeline
This is an actual report Carbon Tracker auto-posted on my MR during development:
Pipeline #2405610327 — Live Report ⚡ Energy 💨 CO₂ 🚗 Equivalent
0.0034 kWh
1.62g ~0.011 km driven

📋 Job Breakdown
Job Duration Energy (kWh) CO₂ (g) Status
unit-test-job ~63s 0.002625 1.247g ✅
lint-test-job ~13s 0.000542 0.257g ✅
build-job ~3s 0.000125 0.059g ✅
deploy-job ~3s 0.000125 0.059g ✅

📊 CO₂ Distribution
Job Share %
unit-test-job 🟧🟧🟧🟧🟧🟧🟧🟧 77%
lint-test-job 🟧🟧 16%
build-job 🟨 4%
deploy-job 🟨 4%

🔥 Waste Patterns Detected:
Artificial sleep in unit-test-job → 77% of total CO₂
Config-only change triggered full pipeline → wasted 1.56g
Deploy ran on non-production branch unnecessarily

💡 Optimization Tips:
Replace sleep with real tests → saves ~96% emissions
Add path rules for config changes → saves 1.56g/run
Restrict deploy to main branch → saves 0.059g/push

🏅 Sustainability Score: B+

🤖 Carbon Tracker · GitLab Duo + Claude (Anthropic)
Claude identified that a sleep 60 command was responsible for 77% of the pipeline's total CO2.
That's the kind of specific, actionable insight that makes this tool genuinely useful — not just a novelty.

🛠️ The Code — How It's Built
flow.yml — The 3-Agent Orchestration
name : " Carbon Tracker Flow"
description : " Calculates CO2 emissions per CI/CD pipeline job."
public : true
definition : version : v1
environment : ambient
components :

• name : " pipeline_fetcher"
  type : AgentComponent
  prompt_id : " fetch_prompt"
  inputs :
• from : " context:goal"
  as : " goal"
  toolset :
• " get_merge_request"
• " list_merge_requests"
  ui_log_events :
• on_agent_final_answer
• name : " carbon_calculator"
  type : AgentComponent
  prompt_id : " calculate_prompt"
  inputs :
• from : " context:goal"
  as : " goal"
• from : " pipeline_fetcher:output"
  as : " pipeline_data"
  ui_log_events :
• on_agent_

final_answer - name : " report_publisher" type : AgentComponent prompt_id : " publish_prompt" inputs : - from : " context:goal" as : " goal" - from : " carbon_calculator:output" as : " carbon_report" toolset : - " create_merge_request_note" - " create_issue_note" ui_log_events : - on_agent_final_answer routers : - from : " pipeline_fetcher" to : " carbon_calculator" - from : " carbon_calculator" to : " report_publisher" - from : " report_publisher" to : " end" flow : entry_point : " pipeline_fetcher"

agent.yml — The Standalone Agent yaml name : " Carbon Tracker Agent" description : " Calculates CO2 emissions for CI/CD pipeline jobs." public : true system_prompt : |
You are the Carbon Tracker Agent running inside GitLab Duo. Calculate CO2 per job: energy_kwh = (duration_seconds / 3600) * 150 / 1000 co2_grams = energy_kwh * 475
Generate a markdown report with job breakdown and tips. End with:
"🤖 Carbon Tracker · GitLab Duo + Claude (Anthropic)"

Why 3 Agents Instead of 1?
Approach Problem Single agent Gets confused doing fetch + calculate + publish
3 agents Each has one job — focused, debuggable, reliable
Separating concerns across agents produces dramatically better output quality from Claude. Each prompt is laser-focused on one task, which means each agent does it exceptionally well.

🚧 Challenges I Ran Into

1. Learning GitLab Duo From Zero
   I had never used GitLab before this hackathon. Learning the Agent Platform, Flow schema, YAML configuration, CI/CD variables, and the tool system — simultaneously — under a 5-day deadline was the steepest part of the entire build.
2. YAML Schema Validation Hell
   The toolset format for flow components was completely undocumented for custom flows. I went through this loop:

Attempt 1 — Failed ❌

toolset : - get_merge_request

Attempt 2 — Failed ❌

toolset : - tool_name : get_merge_request

Attempt 3 — Failed ❌

toolset : - tool_name : " get_merge_request"

Final — Passed ✅

toolset : - " get_merge_request"
Each attempt was a full commit → CI pipeline → read error → fix cycle. That loop taught me more about the platform than any documentation could have.
3. No Official Runner Energy Data
GitLab's API doesn't expose runner power consumption anywhere. I researched cloud compute energy benchmarks from AWS, GCP, and Azure instance specs and settled on 150W as a physically grounded constant — accurate enough to be meaningful without overclaiming false precision.
4. Prompt Engineering for Consistent Output
Getting Claude to produce

각 실행마다 깔끔하고 일관된 포맷의 마크다운 테이블 — 실제 직무명을 참조하는 구체적인 실행 가능한 팁 (일반적인 조언이 아님) 을 포함하려면 3 개 에이전트 시스템 프롬프트를 모두 걸쳐 상당한 반복이 필요했습니다. 핵심 통찰: 각 에이전트를 위한 짧고 집중된 프롬프트는 모든 것을 시도하려는 단일 긴 프롬프트보다 성능이 뛰어납니다.

✅ 달성 사항
GitLab Duo 에서 이전 GitLab 경험 없이도 완전히 작동하는 다중 에이전트 흐름 구축
IEA 2024 에너지 데이터를 기반으로 한 실제 물리 기반 탄소 모델 설계
GitLab CI/CD 파이프라인에 대한 첫 번째 (저의 지식 범위 내에서) 직무별 CO2 분해 도구 생성
진정한 3 에이전트 오케스트레이션 구현 — 챗봇이 아닌, 실제 자동화된 다단계 워크플로우
개발자가 워크플로우를 변경하지 않고도 탄소 데이터를 얻을 수 있도록 지속 가능성 완전 무결점화
GitLab 지식 0 에서 검증된 카탈로그 게시 흐름으로 5 일 만에 출시

🧠 배운 것
기술적: GitLab Duo Flows v1 에서 에이전트 컴포넌트 단계가 라우터와 from/as 입력 결합을 통해 어떻게 연쇄되는지
집중적이고 단일 목적의 에이전트를 위한 프롬프트 엔지니어링은 하나의 대형 프롬프트보다 훨씬 더 나은 결과를 만듭니다
인프라 메타데이터를 사용하여 공공 탄소 강도 데이터를 기반으로 실제 세계 에너지 소비를 모델링하는 방법
Claude 의 시스템 프롬프트가 자동화된 파이프라인에 걸쳐 구조적이고 일관된 출력 형식을 강제할 수 있는 방법
압력 하에서 개발하기: 빠르게 출시하고 더 빠르게 디버깅 — 실패한 파이프라인 하나하나가 문서에 없는 것을 가르쳐 주었습니다
문서화되지 않은 것 = 기회. 다른 누구도 알아내지 못했기 때문에 경쟁자가 적습니다
최선의 프로젝트는 후견에서 명확하게 느껴지는 문제를 해결하지만 아직誰も tackling 하지 않은 문제입니다
1 학년 학생은 전 세계적으로 경쟁할 수 있고 승리할 수 있습니다 — 인터넷은 학습 연도를 고려하지 않습니다

🔮 탄소 트래커의 다음 단계
지역별 탄소 강도 — 글로벌 475 gCO2/kWh 를 러너 메타데이터를 사용하여 위치별 값으로 대체
프로젝트 탄소 대시보드 — 월간 배출량 추이 그래프가 포함된 누적 위키 페이지
탄소 예산 알림 — 월간 파이프라인 배출량이 임계치를 초과할 때 팀에 알림
MR 탄소 차이 — 병합 전에 코드 변경이 배출량에 미치는 영향을 예측합니다
실제 러너 와트수 — GitLab 러너 메타데이터 API 를 통한 퍼 러너 전력 소비량
주간 탄소 디지스트 — 팀 전체의 배출량과 최대 절감량의 슬랙/이메일 요약

🏆 결과
GitLab Duo 에이전트 플랫폼 해커스톤 2026 에서 준우승 수상
6,971 명의 글로벌 참가자 중 승리
$500 현금상금
솔로 빌드 5 일
첫 학년 B.Tech CSE 학생
이전 GitLab 경험 없음

🔗 링크

Devpost: https://devpost.com/software/carbon-tracker-ij25kf
GitLab Repo: https://gitlab.com/gitlab-ai-hackathon/participants/altamish6589 💬 Let's Talk
만약 GitLab Duo Agent Platform 에서 빌드하고, 플로우 (flows), 툴셋 선언 (toolset declarations), 또는 멀티 에이전트 오케스트레이션 (multi-agent orchestration) 에 대해 질문이 있다면 댓글을 남겨주세요. 도움을 드릴 기분이 듭니다.
팀의 CI/CD 파이프라인을 운영하며 탄소 발자국 (carbon footprint) 을 중요하게 생각하신다면, Carbon Tracker 를 위해 만들었습니다. 🌱 GitLab Duo Agent Platform + Claude (Anthropic) 로 구축됨