IT/CI CD

Tekton vs Argo Workflows, 6개월 굴려보고 우리 팀이 내린 결론

gfrog 2026. 6. 19. 12:48
SMALL

 

작년 말부터 우리 팀은 GitHub Actions 한 곳에 모든 파이프라인을 몰아넣던 구조를 깨기 시작했다. 빌드/배포는 Actions에 두고, 데이터 파이프라인과 K8s 안에서 도는 무거운 잡들은 클러스터 안에서 돌리자는 결정이었다. 후보는 Tekton Pipelines와 Argo Workflows 두 개. 결정을 못 내려서 결국 둘 다 6개월씩 굴려봤다.

올해 들어 두 프로젝트 모두 큰 릴리즈가 있었다. Tekton Pipelines는 작년 5월에 v1.0 GA 찍고 올 2월에 v1.9.0 LTS를 냈고, Argo Workflows는 v4.0.0이 2월 4일에 떨어졌다. 둘 다 안정성과 운영 편의 쪽으로 방향이 잡혀가는 시점이라 비교하기 딱 좋았다.

우리가 본 워크로드

비교가 의미 있으려면 어떤 잡을 돌렸는지부터 깔고 가야 한다. 우리 팀이 6개월간 두 도구로 돌려본 워크로드는 대충 이렇다.

  • 컨테이너 이미지 빌드 + Trivy 스캔 + ECR 푸시 (하루 200~400회)
  • 데이터 파이프라인: S3 → 전처리 → BigQuery 적재 (하루 50회 정도, DAG 모양)
  • 야간 배치: DB 백업 검증, 리포트 생성 (하루 10건, 길게는 2시간짜리)
  • 일회성 마이그레이션 잡: 인프라 변경 때 손으로 돌리는 일들

이게 중요한 이유는, 두 도구가 잘 하는 영역이 다르기 때문이다. 양쪽이 다 CI/CD라고 분류되긴 하는데, 실제로 돌려보면 결이 다르다.

Tekton, "잘 만들어진 빌드 파이프라인 엔진"

Tekton은 처음 만져봤을 때 "아 이거 진짜 Jenkins 후계자 노리는구나" 싶었다. Task, Pipeline, PipelineRun 추상이 깔끔하고, 각 Step이 하나의 컨테이너로 실행되니까 격리가 명확하다. v1.0에서 StepAction이 GA 되면서 재사용 가능한 단위가 더 작아진 것도 좋았다.

특히 좋았던 점.

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: build-and-push
spec:
  params:
    - name: image
  workspaces:
    - name: source
  steps:
    - name: build
      image: gcr.io/kaniko-project/executor:latest
      script: |
        /kaniko/executor --destination=$(params.image) ...
    - name: scan
      image: aquasec/trivy:latest
      script: |
        trivy image --severity HIGH,CRITICAL $(params.image)

이게 ArgoCD Pipelines나 OpenShift Pipelines처럼 패키징된 환경에 들어가면 그냥 동작한다. v1.9 LTS는 4월 2027년까지 지원이라 운영 입장에서 안정성을 보장받는다는 점도 의외로 컸다.

근데 단점도 명확했다.

DAG 표현이 어색하다. runAfter로 의존성을 거는 방식인데, 한 잡의 출력을 다른 잡 여러 개로 fan-out 하려고 하면 갑자기 YAML이 산만해진다. 우리 데이터 파이프라인은 "S3 prefix별로 병렬 처리 후 합치기"가 기본 패턴인데, 이걸 Tekton으로 짜려면 Matrix 같은 기능을 끌어와야 했고, 그게 v1.0 들어와서야 좀 쓸 만해졌다.

또 하나, UI가 약하다. Tekton Dashboard가 있긴 한데 Argo의 워크플로 뷰랑 비교하면 정보 밀도가 한참 떨어진다. SRE가 새벽에 페이저 받고 들어와서 "이 잡 어디서 죽었지?" 빠르게 보려면 결국 kubectl describe pipelinerun을 친다.

Argo Workflows, "DAG 잘 굴리는 잡 스케줄러"

Argo Workflows는 시작부터 "K8s 위에서 도는 Airflow"를 표방했고, 6개월 써보니 진짜 그 방향이 맞다. DAG와 Step 두 가지 템플릿 모두 자연스럽고, 동적으로 워크플로를 펼치는 withItems, withSequence가 강력하다.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: data-pipeline-
spec:
  entrypoint: main
  templates:
    - name: main
      dag:
        tasks:
          - name: extract
            template: extract
            arguments:
              parameters: [{name: prefix, value: "{{item}}"}]
            withItems: ["2026-06-18", "2026-06-17", "2026-06-16"]
          - name: merge
            template: merge
            dependencies: [extract]

이 식의 fan-out/fan-in이 한 줄로 끝난다. UI도 워크플로를 그래프로 그려주고, 각 노드 클릭하면 로그까지 바로 따라간다. 운영 입장에서 트러블슈팅이 진짜 편하다.

v4.0.0에서 추가된 Artifact Driver 플러그인 기능도 우리한테는 의미가 있었다. 사내 S3-호환 오브젝트 스토리지가 표준 S3 API를 다 지원하지 않는데, gRPC 드라이버 하나 짜서 붙이니까 깔끔하게 해결됐다. Tekton에서 같은 걸 하려면 Workspaces + 커스텀 Volume으로 우회해야 한다.

단점이 없을 리 없다.

워크플로 컨트롤러가 좀 무겁다. 동시에 500개 워크플로가 큐에 쌓이는 상황을 만들었더니 컨트롤러 메모리가 4GB를 넘어가더라. v3.6부터 들어간 Workflow Archive를 잘 쓰고 TTL을 빡세게 걸지 않으면 etcd가 비명을 지른다. 우리는 결국 완료 워크플로는 1시간 후 정리, 아카이브는 Postgres에 24시간 보관 정책으로 갔다.

또, 빌드 잡에는 약간 오버스펙이다. Kaniko로 이미지 빌드하는 단순한 잡까지 Argo로 돌리면 YAML이 길어지고, 사이드카로 따라붙는 wait 컨테이너 때문에 노드 리소스 소모도 늘어난다.

6개월 후, 우리는 어떻게 갈랐나

결론부터 말하면 둘 다 쓰고 있다. 한 도구로 일원화하려고 두 달쯤 노력하다가 포기했다.

  • 빌드/배포 파이프라인은 Tekton. 이미지 빌드 → 스캔 → 푸시는 선형 흐름이 99%다. Tekton의 Task/Pipeline 추상이 더 자연스럽고, StepAction으로 사내 표준 Task 라이브러리를 만들기 쉽다. 그리고 ArgoCD와 같이 쓰니까 GitOps와 결이 맞는다.
  • 데이터/배치 워크로드는 Argo Workflows. DAG가 필요한 순간 Tekton은 어색해진다. fan-out, dynamic step, 외부 이벤트 트리거(Argo Events 묶음) 다 Argo가 앞선다.

이렇게 두 개를 같이 굴리는 게 운영 부담은 분명 늘긴 한다. 컨트롤러 두 개, RBAC 두 벌, 모니터링 대시보드 두 개. 근데 "하나로 다 한다"고 우기다가 도구 한쪽이 약한 영역에서 YAML 700줄짜리 파이프라인을 만들었던 경험이 있어서, 적당한 분리가 차라리 낫다고 결론 냈다.

솔직히 처음엔 Argo로 통일하려고 했다. UI도 좋고 기능도 풍부하니까. 근데 우리 빌드 잡 패턴에선 Tekton이 너무 자연스러워서, 굳이 더 무거운 도구로 옮길 명분이 없었다.

도구 선택 전에 던져볼 질문

지금 비슷한 결정 앞에 있는 분이 있다면, 도구 비교표 보기 전에 이것부터 답해보면 좋겠다.

  • 우리 파이프라인의 80%는 선형인가, DAG인가?
  • 파이프라인 결과물(artifact)을 다음 잡으로 넘기는 패턴이 있는가? 있다면 그 저장소가 표준 S3인가, 아닌가?
  • 운영 인력 중 K8s YAML에 익숙한 사람이 몇 명인가? Tekton/Argo 둘 다 YAML 비중이 적지 않다.
  • LTS가 중요한가? Tekton v1.9는 LTS, Argo는 LTS 정책이 명시적이지 않다.

답이 갈리면 도구도 갈린다. 한 도구로 묶고 싶은 욕심이 자연스럽지만, 한쪽이 약한 영역에선 결국 도구가 일을 방해한다.

마무리

아직 검증 중인 부분도 있다. Tekton Chains로 빌드 SLSA 증명 붙이는 작업과, Argo Events + Workflows 묶음으로 외부 이벤트 기반 트리거 더 깊게 쓰는 거. 둘 다 다음 분기 과제로 미뤄놨다.

혹시 한 도구로 통일해서 잘 운영 중인 팀이 있다면 어떤 워크로드인지 댓글로 알려주시면 감사하겠다. 우리도 분리 운영이 정답이라 확신하는 건 아니라서.

BIG
저작자표시 비영리 동일조건 (새창열림)