Notes

Tekton vs Jenkins

Jenkins의 controller/plugin 중심 CI/CD 모델과 Tekton의 Kubernetes-native Task/Pipeline/PipelineRun 모델을 비교하고, 운영·보안·스토리지·마이그레이션 관점에서 선택 기준을 정리한다.

Published: Jun 2, 2026
Updated: Jun 2, 2026
Area: Cloud Infrastructure
Type: concept
Series: DevOps Explained
Category: Notes

TektonJenkinsKubernetesCI/CDPipelineTaskRunPipelineRunDevOps

개요

Jenkins와 Tekton은 모두 CI/CD pipeline을 구현할 수 있는 도구다. 두 도구 모두 source code 변경을 감지하고, build와 test를 수행하며, container image를 만들고, registry에 push한 뒤, 애플리케이션을 배포하는 흐름을 만들 수 있다.

하지만 둘의 차이는 단순히 기능 목록의 차이가 아니다. 더 중요한 차이는 CI/CD 실행 상태를 어디에 두고, 어떤 방식으로 pipeline을 운영할 것인가에 있다.

Jenkins는 전통적으로 controller 중심의 automation server다. Jenkins controller가 job, plugin, credential, build history, pipeline execution을 관리하고, 실제 작업은 controller 또는 agent에서 실행된다.

Tekton은 Kubernetes-native CI/CD framework다. pipeline 자체를 Kubernetes Custom Resource로 표현하고, 각 작업은 pod와 container로 실행된다. Task, TaskRun, Pipeline, PipelineRun, Workspace, Trigger 같은 Kubernetes resource를 조합해 CI/CD 흐름을 만든다.

핵심 차이를 짧게 정리하면 다음과 같다.

Jenkins:
  CI/CD를 Jenkins controller 안에서 정의하고 실행한다.

Tekton:
  CI/CD 실행 자체를 Kubernetes resource와 pod로 표현한다.

비교의 핵심 질문

Tekton과 Jenkins를 비교할 때 핵심 질문은 다음이다.

같은 CI/CD pipeline을 만들 때, 중앙 controller 기반으로 구성할 것인가, 아니면 Kubernetes-native resource 기반으로 구성할 것인가?

두 도구 모두 다음과 같은 pipeline을 구성할 수 있다.

Git push
  -> source clone
  -> build
  -> test
  -> container image build
  -> registry push
  -> deploy

그러나 이 흐름을 구현하는 방식은 다르다.

구분	Jenkins	Tekton
기본 성격	범용 automation server	Kubernetes-native CI/CD framework
중심 구조	controller 중심	Kubernetes resource 중심
pipeline 정의	`Jenkinsfile`, job config	`Task`, `Pipeline`, `PipelineRun` YAML
실행 단위	stage, step, agent	pod, container step
확장 방식	plugin	Task, custom Task, container image
상태 저장	Jenkins home, Jenkins build history	Kubernetes object, pod, PVC, log backend
Kubernetes 통합	plugin 또는 agent 기반	Kubernetes 내부에서 native하게 동작
운영 부담	controller, plugin, Jenkins home 관리	cluster resource, RBAC, PVC, pod lifecycle 관리

따라서 선택 기준은 “어느 도구가 더 최신인가”가 아니다. 실제 기준은 조직의 runtime이 무엇인지, 운영팀이 어떤 platform을 표준으로 삼는지, pipeline 상태를 어디에 두고 싶은지다.

Jenkins의 기본 모델

Jenkins는 오래된 CI/CD 생태계에서 널리 사용되어 온 automation server다. 기본 구조는 Jenkins controller와 agent로 이해할 수 있다.

GitHub / GitLab / Bitbucket
  -> webhook 또는 polling
  -> Jenkins controller
  -> job 또는 pipeline scheduling
  -> agent 할당
  -> build / test / deploy 실행
  -> log와 build history 저장

Jenkins controller는 다음 역할을 담당한다.

구성 요소	역할
Jenkins controller	job scheduling, UI, API, plugin loading, credential 관리
Agent / Node	실제 build, test, deploy step 실행
Plugin	Git, Docker, Kubernetes, Slack, credential 등 외부 기능 연동
Jenkinsfile	pipeline을 코드로 정의하는 파일
Jenkins home	job 설정, plugin, credential metadata, build history 저장
Webhook	repository event를 Jenkins build trigger로 연결

Jenkins의 장점은 성숙한 생태계와 넓은 범용성이다. Git, Docker, Kubernetes, Maven, Gradle, Slack, Jira, SonarQube 등 거의 모든 CI/CD 주변 도구와 연결할 수 있다. VM, bare metal, legacy system, on-premise 환경과도 잘 맞는다.

반면 Jenkins는 중앙 controller와 plugin 생태계에 대한 운영 책임이 크다. plugin이 많아질수록 compatibility, upgrade, security patch, controller stability를 지속적으로 관리해야 한다.

Jenkinsfile과 Pipeline-as-code

Jenkins에서는 pipeline을 Jenkinsfile로 정의할 수 있다. 이 파일은 application repository에 함께 저장할 수 있으므로, pipeline 자체를 code review와 version control 대상으로 만들 수 있다.

간단한 예시는 다음과 같다.

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                sh 'echo Building...'
            }
        }

        stage('Test') {
            steps {
                sh 'echo Testing...'
            }
        }

        stage('Deploy') {
            steps {
                sh 'echo Deploying...'
            }
        }
    }
}

Jenkinsfile의 주요 구성 요소는 다음과 같다.

구성 요소	의미
`pipeline`	전체 pipeline 정의
`agent`	pipeline 또는 stage가 실행될 worker 지정
`stages`	큰 실행 단계 묶음
`stage`	build, test, deploy 같은 논리적 단계
`steps`	실제 명령 실행 단위
`sh`	shell command 실행
`environment`	환경 변수 정의
`post`	성공, 실패, 항상 실행할 후처리 정의

Jenkinsfile은 사람이 읽기 쉽고, 기존 CI/CD 사용자에게 직관적이다. 그러나 Jenkinsfile 내부의 많은 step은 plugin에 의존한다. 특정 plugin version, controller 설정, credential scope, agent 환경에 따라 실행 결과가 달라질 수 있다.

즉, Jenkinsfile은 pipeline-as-code를 가능하게 하지만, 완전히 독립적인 실행 정의는 아니다. Jenkins runtime과 plugin 생태계를 전제로 한다.

Jenkins Plugin 생태계의 장점과 부담

Jenkins의 가장 큰 장점 중 하나는 plugin 생태계다. 필요한 기능이 있으면 plugin으로 붙일 수 있는 경우가 많다.

대표적으로 다음 기능을 plugin으로 확장할 수 있다.

기능	예시
SCM 연동	Git, GitHub, GitLab, Bitbucket
Build tool	Maven, Gradle, npm
Container	Docker, Kubernetes
품질 검사	SonarQube, lint, static analysis
알림	Slack, email, webhook
인증/권한	LDAP, OAuth, role strategy
배포	SSH, Kubernetes, cloud provider plugin

그러나 plugin은 동시에 운영 부담이 된다.

주의할 점은 다음과 같다.

plugin 간 version compatibility를 관리해야 한다.
Jenkins upgrade 시 plugin 충돌이 발생할 수 있다.
plugin 보안 취약점에 대한 patch cycle이 필요하다.
pipeline 동작이 plugin 내부 구현에 의존할 수 있다.
controller 장애 또는 plugin 오류가 여러 pipeline에 동시에 영향을 줄 수 있다.
plugin이 많아질수록 Jenkins controller의 upgrade 난이도가 높아질 수 있다.

Jenkins를 안정적으로 운영하려면 plugin을 무작정 늘리기보다, 조직에서 표준으로 사용할 plugin과 폐기할 plugin을 관리해야 한다.

Tekton의 기본 모델

Tekton은 Kubernetes 위에서 동작하는 CI/CD framework다. Jenkins처럼 독립적인 automation server를 중심으로 동작하는 것이 아니라, pipeline을 Kubernetes Custom Resource로 표현한다.

Tekton의 핵심 아이디어는 다음과 같다.

Pipeline도 Kubernetes resource다.
Task도 Kubernetes resource다.
실행 인스턴스도 Kubernetes resource다.
각 step은 container로 실행된다.
각 TaskRun은 pod로 스케줄링된다.

Tekton의 기본 흐름은 다음과 같이 볼 수 있다.

Git event
  -> EventListener
  -> PipelineRun 생성
  -> TaskRun 생성
  -> pod/container 실행
  -> Workspace/PVC를 통한 파일 공유
  -> registry push 또는 deploy

이 모델에서 CI/CD는 별도 서버 내부 상태가 아니라 Kubernetes API object와 pod lifecycle로 표현된다.

Tekton 핵심 Resource

Tekton을 이해하려면 다음 resource를 구분해야 한다.

Tekton resource	역할
`Task`	하나 이상의 step으로 구성된 재사용 가능한 작업 단위
`TaskRun`	특정 `Task`를 실제로 실행하는 인스턴스
`Pipeline`	여러 `Task`를 순서와 의존성에 따라 연결한 workflow
`PipelineRun`	특정 `Pipeline`을 실제로 실행하는 인스턴스
`TriggerTemplate`	event 발생 시 생성할 resource template
`TriggerBinding`	event payload에서 parameter를 추출
`EventListener`	webhook 등 외부 event를 수신
`Workspace`	task 간 파일 공유 또는 config/credential mount 지점
`PersistentVolumeClaim`	workspace에 persistent storage 제공
`ServiceAccount`	pipeline 실행 권한과 secret 접근 범위 정의

이 구조에서 Task와 Pipeline은 정의에 가깝고, TaskRun과 PipelineRun은 실제 실행 기록에 가깝다.

Task: Tekton의 가장 작은 재사용 작업 단위

Task는 Tekton에서 가장 기본적인 작업 단위다. 하나의 Task는 하나 이상의 step으로 구성된다. 각 step은 container image를 기반으로 실행된다.

예시는 다음과 같다.

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: run-tests
spec:
  workspaces:
    - name: source
  steps:
    - name: test
      image: node:20
      workingDir: $(workspaces.source.path)
      script: |
        npm install
        npm test

이 예시에서 중요한 점은 다음과 같다.

Task는 Kubernetes resource다.
steps의 각 항목은 container image를 가진다.
source code는 Workspace를 통해 전달된다.
실행 환경은 agent machine이 아니라 container image로 고정된다.

Jenkins에서는 보통 agent에 toolchain을 설치해두고 sh step을 실행한다. Tekton에서는 step마다 필요한 image를 명시한다. 예를 들어 test는 node:20, image build는 kaniko, deploy는 kubectl 또는 helm image를 사용할 수 있다.

이 방식은 재현성을 높인다. agent에 무엇이 설치되어 있는지에 덜 의존하고, step 실행 환경을 image로 명시할 수 있기 때문이다.

Pipeline: Task의 실행 순서와 의존성 정의

Pipeline은 여러 Task를 연결한 workflow다. 예를 들어 일반적인 application CI는 다음과 같이 구성될 수 있다.

clone-source
  -> run-tests
  -> build-image
  -> push-image
  -> deploy

Tekton에서는 이를 Pipeline resource로 정의한다.

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: app-ci
spec:
  workspaces:
    - name: shared-source
  tasks:
    - name: clone
      taskRef:
        name: git-clone
      workspaces:
        - name: output
          workspace: shared-source

    - name: test
      taskRef:
        name: run-tests
      runAfter:
        - clone
      workspaces:
        - name: source
          workspace: shared-source

    - name: build
      taskRef:
        name: build-image
      runAfter:
        - test
      workspaces:
        - name: source
          workspace: shared-source

runAfter는 task 실행 순서를 정의한다. 어떤 task는 순차적으로 실행하고, 어떤 task는 병렬로 실행할 수 있다. 또한 parameter, results, workspace를 이용해 task 간 데이터를 연결할 수 있다.

Jenkins에서는 하나의 Jenkinsfile 안에 stage를 작성하는 방식이 일반적이다. Tekton에서는 재사용 가능한 Task와 이를 조합하는 Pipeline을 분리해서 설계한다.

PipelineRun과 TaskRun

Tekton에서 Pipeline은 설계도이고, PipelineRun은 실제 실행이다. 이 관계는 Kubernetes의 Deployment와 Pod 관계를 떠올리면 이해하기 쉽다.

개념	성격	의미
`Task`	작업 정의	어떤 step을 실행할지 정의
`TaskRun`	작업 실행	특정 `Task`를 실제로 실행
`Pipeline`	workflow 정의	여러 `Task`의 연결 관계 정의
`PipelineRun`	workflow 실행	특정 parameter와 workspace로 `Pipeline` 실행

예를 들어 app-ci라는 Pipeline이 있다면 commit마다 새로운 PipelineRun이 만들어질 수 있다.

Pipeline:
  app-ci

PipelineRun:
  app-ci-run-001 for commit a1b2c3
  app-ci-run-002 for commit d4e5f6
  app-ci-run-003 for commit f7g8h9

PipelineRun은 실행 시점의 값을 주입한다.

Git repository URL
branch 또는 revision
image tag
target namespace
workspace volume
service account
timeout
credential 접근 범위

이 구조 덕분에 같은 Pipeline을 여러 repository, branch, environment에 재사용할 수 있다.

TriggerTemplate과 EventListener

CI/CD pipeline은 보통 Git event로 시작된다. Jenkins에서는 repository webhook이 Jenkins controller의 endpoint로 들어오고, Jenkins job이 trigger된다.

Tekton에서는 EventListener, TriggerBinding, TriggerTemplate을 통해 event를 PipelineRun 생성으로 연결한다.

Git push event
  -> webhook request
  -> EventListener
  -> TriggerBinding으로 payload 값 추출
  -> TriggerTemplate으로 PipelineRun 생성
  -> Pipeline 실행

각 resource의 역할은 다음과 같다.

Resource	역할
`EventListener`	외부 webhook event를 수신
`TriggerBinding`	event payload에서 repository URL, branch, commit SHA 등을 추출
`TriggerTemplate`	추출된 값을 이용해 `PipelineRun` 같은 resource를 생성

Jenkins와 Tekton의 trigger 차이는 event 이후의 처리 위치에 있다.

구분	Jenkins	Tekton
event 수신	Jenkins controller	`EventListener`
실행 생성	Jenkins job/build	`PipelineRun`
상태 위치	Jenkins 내부 상태	Kubernetes resource 상태

Jenkins에서는 webhook이 Jenkins로 들어가고, Jenkins가 build를 관리한다. Tekton에서는 webhook이 Kubernetes 내부의 EventListener로 들어가고, 그 결과로 PipelineRun이 생성된다.

Workspace와 PVC

CI/CD pipeline에서는 여러 단계가 파일을 공유해야 한다. 예를 들어 git clone 단계에서 받은 source code를 test 단계와 build 단계가 함께 사용해야 한다.

Jenkins에서는 일반적으로 agent의 workspace directory가 이 역할을 한다.

Jenkins agent workspace
  -> git clone
  -> test
  -> build
  -> deploy

Tekton에서는 task가 pod/container로 실행되므로 파일 공유를 명시적으로 정의해야 한다. 이를 위해 Workspace를 사용한다.

PipelineRun
  -> workspace: shared-source
  -> PVC 또는 emptyDir 연결
  -> clone task가 source code 저장
  -> test task가 source code 읽기
  -> build task가 source code 읽기

Workspace는 다음 용도로 사용된다.

용도	설명
source code 공유	clone task가 받은 코드를 test/build task가 사용
build output 공유	build 결과물을 다음 task로 전달
credential mount	secret을 특정 path에 mount
config 제공	ConfigMap 기반 설정 전달
build cache	dependency cache 또는 image layer cache 구성
공통 tool 제공	조직 공통 script 또는 tool mount

PersistentVolumeClaim을 사용하면 여러 task가 같은 persistent volume을 공유할 수 있다.

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: app-ci-run
spec:
  pipelineRef:
    name: app-ci
  workspaces:
    - name: shared-source
      persistentVolumeClaim:
        claimName: source-pvc

PVC 사용 시 주의할 점은 다음과 같다.

PipelineRun 종료 후 PVC cleanup 정책을 정해야 한다.
여러 task가 동시에 write하면 race condition이 생길 수 있다.
StorageClass와 access mode에 따라 multi-node mount가 제한될 수 있다.
credential이 workspace에 남지 않도록 정리해야 한다.
build cache가 오염되면 재현성이 떨어질 수 있다.
대량의 pipeline run이 PVC를 생성하면 storage pressure가 생길 수 있다.

PipelineResources에 대한 주의점

오래된 Tekton 예제에는 PipelineResource가 등장할 수 있다. 이는 git repository, image 같은 input/output resource를 표현하던 방식이다.

그러나 현재 관점에서는 PipelineResource 사용에 주의해야 한다.

과거 Tekton 예제:
  PipelineResource로 git repository 또는 image resource 표현

현재 권장 방향:
  params + Workspaces + results + Task 조합으로 표현

이 부분은 반드시 확인 필요다. 기존 문서나 예제의 작성 시점에 따라 PipelineResource를 사용하는 YAML이 남아 있을 수 있다. 새 pipeline을 설계할 때는 현재 Tekton API와 권장 migration 방식을 확인해야 한다.

Jenkins home과 상태 관리

Jenkins 운영에서 Jenkins home은 매우 중요하다. 이 디렉터리에는 Jenkins의 핵심 상태가 모인다.

저장 대상	설명
job configuration	job 설정과 pipeline 설정
plugin data	설치된 plugin과 plugin별 설정
credential metadata	credential 관련 metadata
build history	build 결과와 기록
user configuration	사용자 설정
workspace 일부	job 실행 중 생성되는 작업 디렉터리
system configuration	Jenkins 전역 설정

Jenkins home이 손상되면 다음 문제가 생길 수 있다.

job 설정 손실
build history 손실
plugin 설정 손실
credential metadata 손실
controller 복구 지연
pipeline UI 설정 손실

따라서 Jenkins는 controller와 Jenkins home backup 전략이 중요하다. Agent는 ephemeral하게 운영할 수 있지만, controller와 Jenkins home은 stateful component로 다뤄야 한다.

Tekton의 상태 관리

Tekton은 Jenkins처럼 하나의 Jenkins home에 모든 상태가 집중되는 모델은 아니다. Tekton의 상태는 Kubernetes resource와 외부 시스템에 나뉘어 있다.

상태	위치
pipeline 정의	Git 또는 Kubernetes object
실행 기록	`PipelineRun`, `TaskRun`
실행 로그	pod log 또는 log backend
작업 파일	`Workspace`, `PVC`, `emptyDir`
credential	Kubernetes Secret
권한	ServiceAccount, RBAC
artifact	container registry 또는 artifact repository

Tekton이 완전히 stateless하다는 뜻은 아니다. 오히려 다음 요소를 함께 관리해야 한다.

Git repository
Kubernetes object backup
PVC lifecycle
pod log retention
container registry
service account와 RBAC
secret rotation
PipelineRun cleanup 정책

Jenkins는 Jenkins controller 중심의 stateful 운영이고, Tekton은 Kubernetes platform 전체에 상태가 분산되는 운영이다.

실행 모델 비교: 중앙 Orchestration vs Kubernetes-native Execution

Jenkins와 Tekton의 가장 큰 차이는 실행 모델이다.

Jenkins:
  controller가 build를 scheduling하고 agent에게 작업을 실행시킨다.

Tekton:
  Kubernetes resource가 생성되고 controller가 이를 reconcile하여 pod를 만든다.

이를 운영 관점으로 보면 다음과 같다.

관점	Jenkins	Tekton
병목 후보	controller CPU/memory, plugin, queue	cluster resource, scheduler, image pull, PVC attach
실행 격리	agent/node 단위	pod/container 단위
권한 모델	Jenkins credential, job permission	ServiceAccount, RBAC, Secret
로그 확인	Jenkins console log	pod log, TaskRun/PipelineRun 상태
cleanup	build history, workspace cleanup	PipelineRun, TaskRun, pod, PVC cleanup
scaling	agent 확장	Kubernetes node/pod scheduling 기반
장애 범위	controller 장애가 전체 CI/CD에 영향	cluster/control plane과 namespace 설계에 따라 영향

Tekton은 Jenkins의 운영 문제를 단순히 제거하지 않는다. 대신 운영 문제의 위치를 Kubernetes platform 문제로 이동시킨다.

따라서 Tekton을 도입한다는 것은 Jenkins controller를 없애는 것만이 아니라, Kubernetes cluster resource, namespace, RBAC, storage, logging, cleanup, image build 방식을 함께 설계한다는 의미다.

Kubernetes 환경에서 Tekton이 자연스러운 이유

Kubernetes가 이미 애플리케이션 runtime의 표준이라면 Tekton은 자연스럽게 맞는다.

Kubernetes 기반 delivery 흐름은 다음처럼 구성할 수 있다.

Application code:
  Git repository

Build output:
  container image

Artifact storage:
  container registry

Deployment config:
  Kubernetes manifest 또는 Helm chart

CI/CD execution:
  Tekton PipelineRun

Runtime:
  Kubernetes Pod

Config:
  ConfigMap / Secret

Permission:
  ServiceAccount / RBAC

Observation:
  metrics / logs / events / traces

이 구조에서는 CI/CD 실행 자체도 cluster 내부 resource로 표현된다. 즉, pipeline 실행, application runtime, config, secret, permission, storage가 모두 Kubernetes model과 연결된다.

이 방식은 GitOps와도 잘 맞는다.

Tekton:
  source checkout
  test
  image build
  image push
  manifest repository update

Argo CD:
  Git repository 감시
  desired state와 live state 비교
  cluster에 변경 사항 sync

이렇게 역할을 나누면 Tekton은 CI와 artifact 생성에 집중하고, Argo CD는 CD와 GitOps reconciliation에 집중할 수 있다.

Jenkins가 유리한 경우

Tekton이 Kubernetes-native라고 해서 항상 Jenkins보다 낫다는 뜻은 아니다. Jenkins가 더 적합한 경우도 많다.

상황	Jenkins가 유리한 이유
기존 Jenkins 자산이 많음	job, Jenkinsfile, shared library, plugin을 재사용 가능
legacy system 연동 필요	다양한 plugin과 script 기반 통합이 강함
UI 중심 운영 필요	build history, manual approval, parameterized build가 익숙함
Kubernetes가 주 runtime이 아님	VM, bare metal, Windows server, legacy WAS와 통합하기 쉬움
복잡한 승인 flow가 있음	Jenkins UI와 plugin 기반으로 구성하기 쉬움
사내 custom plugin이 있음	기존 확장 자산을 유지할 수 있음

Jenkins를 이미 안정적으로 운영하고 있고, Kubernetes가 조직의 중심 platform이 아니라면 Tekton 전환이 반드시 이득이라고 보기 어렵다. Migration 비용과 운영 모델 변경 비용을 함께 계산해야 한다.

Tekton이 유리한 경우

반대로 Tekton이 더 자연스러운 경우도 명확하다.

상황	Tekton이 유리한 이유
Kubernetes가 표준 runtime	CI/CD 실행도 Kubernetes resource로 통합 가능
container-first build가 필요	step별 실행 환경을 image로 고정 가능
multi-tenant CI/CD 필요	namespace, RBAC, quota 기반 격리 가능
GitOps와 결합	Argo CD 같은 도구와 역할 분리 가능
pipeline을 YAML resource로 관리	Git 기반 선언형 관리에 적합
platform team이 reusable Task를 제공	조직 표준 Task와 Pipeline template 구성 가능
agent 관리 부담을 줄이고 싶음	별도 agent machine보다 pod 기반 실행이 자연스러움

Tekton은 특히 platform engineering 관점에서 유용하다. 여러 팀이 같은 cluster 또는 여러 cluster에서 표준화된 pipeline을 사용할 수 있도록 Task, Pipeline, ServiceAccount, Workspace를 template화할 수 있다.

보안 관점 비교

Jenkins 보안 포인트

Jenkins는 controller에 많은 권한과 상태가 집중되기 쉽다. 따라서 다음 항목을 주의해야 한다.

plugin 취약점 관리
controller admin 권한 최소화
job별 permission 분리
credential scope 관리
pipeline script에서 secret 출력 방지
agent와 controller 간 통신 보안
Jenkins home backup 암호화
오래된 plugin과 미사용 job 정리
build log에 token, password, internal hostname 노출 방지

Jenkins pipeline에서 secret을 사용할 때는 log masking과 credential binding을 신중히 구성해야 한다. 또한 job이 많아질수록 누가 어떤 credential에 접근할 수 있는지 관리해야 한다.

Tekton 보안 포인트

Tekton은 Kubernetes 보안 모델을 따른다. 따라서 다음 항목이 중요하다.

pipeline 실행용 ServiceAccount 권한 최소화
namespace별 RBAC 분리
Secret mount 범위 제한
task image provenance 확인
task image 취약점 scanning
privileged build 최소화
Docker socket mount 지양
workspace에 credential이 남지 않도록 cleanup
PVC에 민감 정보가 남지 않도록 lifecycle 관리
pod security context와 network policy 적용 검토

Tekton에서는 각 step이 container image로 실행되므로 supply chain security도 중요하다. 신뢰할 수 없는 task image를 사용하면 pipeline 자체가 공격면이 될 수 있다.

Docker Socket과 Image Build 문제

CI/CD pipeline에서 container image를 build할 때 자주 나오는 문제가 Docker socket이다.

Jenkins에서는 agent에 Docker가 설치되어 있고, pipeline에서 다음처럼 image를 build하는 경우가 많다.

stage('Build Image') {
    steps {
        sh 'docker build -t my-app:latest .'
        sh 'docker push my-app:latest'
    }
}

이 방식은 단순하지만, agent가 /var/run/docker.sock에 접근한다면 보안 위험이 커질 수 있다. Docker socket에 접근 가능한 process는 host Docker daemon을 제어할 수 있기 때문이다.

Tekton에서는 Kubernetes 안에서 image를 build해야 하므로 보통 다음 방식이 고려된다.

방식	특징
Kaniko	Docker daemon 없이 image build 가능
Buildah	container image build 도구, rootless 구성 검토 가능
BuildKit	고급 build 기능과 cache 기능 제공
Cloud build service	cluster 외부 build service와 연동
Docker socket mount	단순하지만 보안상 주의 필요

Tekton이 container-first build에 잘 맞는 것은 맞지만, image build 방식은 별도로 신중하게 설계해야 한다. 특히 privileged mode, rootless build, cache, registry credential, storage 성능을 함께 검토해야 한다.

운영 난이도 비교

Jenkins와 Tekton 중 어느 쪽이 더 쉽다고 단정하기는 어렵다. 팀이 어떤 환경에 익숙한지에 따라 달라진다.

관점	Jenkins가 쉬운 경우	Tekton이 쉬운 경우
사용자 경험	Jenkins UI와 job 개념이 익숙함	`kubectl`, YAML, Kubernetes resource가 익숙함
실행 환경	VM/agent 기반 build가 많음	container/pod 기반 build가 표준임
확장 방식	plugin으로 빠르게 통합하고 싶음	Task와 image로 명시적으로 구성하고 싶음
운영 모델	중앙 CI/CD 서버 운영이 편함	Kubernetes platform 운영이 이미 준비됨
디버깅	Jenkins console log가 익숙함	pod log, event, `describe`가 익숙함
권한 관리	Jenkins permission 모델이 익숙함	RBAC, ServiceAccount, Secret 모델이 표준임

Jenkins의 복잡도는 plugin과 controller 운영에서 온다. Tekton의 복잡도는 Kubernetes resource 설계와 cluster 운영에서 온다.

Kubernetes 기반 Pipeline 예시

같은 애플리케이션을 build하고 Kubernetes에 배포한다고 가정해보자.

Jenkins 방식

1. Git webhook이 Jenkins job을 trigger한다.
2. Jenkins controller가 job을 scheduling한다.
3. Jenkins agent가 할당된다.
4. agent가 repository를 clone한다.
5. agent가 test를 실행한다.
6. agent가 Docker image를 build한다.
7. image를 registry에 push한다.
8. agent가 kubectl 또는 Helm으로 Kubernetes에 배포한다.
9. Jenkins에 build log와 결과가 저장된다.

흐름의 중심은 Jenkins다.

Git -> Jenkins controller -> Jenkins agent -> Registry -> Kubernetes

Tekton 방식

1. Git webhook이 Tekton EventListener로 전달된다.
2. TriggerTemplate이 PipelineRun을 생성한다.
3. PipelineRun이 여러 TaskRun을 생성한다.
4. 각 TaskRun은 pod/container로 실행된다.
5. clone task가 source code를 workspace에 저장한다.
6. test task가 workspace의 source code를 사용한다.
7. build task가 image를 build하고 registry에 push한다.
8. deploy task가 manifest 또는 Helm chart를 적용한다.
9. PipelineRun, TaskRun, pod 상태로 실행 결과가 남는다.

흐름의 중심은 Kubernetes다.

Git -> EventListener -> PipelineRun -> Pods -> Registry -> Kubernetes

같은 결과를 만들 수 있지만, 상태와 실행 책임이 놓이는 위치가 다르다.

Jenkins에서 Tekton으로 Migration할 때의 검토 항목

Jenkins에서 Tekton으로 옮기는 작업은 단순히 Jenkinsfile을 YAML로 바꾸는 작업이 아니다. 실행 모델 자체가 달라지므로 다음 항목을 다시 설계해야 한다.

Migration 항목	검토 질문
Jenkinsfile stage	어떤 단위를 Tekton `Task`로 분리할 것인가?
shared library	공통 `Task` 또는 공통 container image로 대체할 수 있는가?
Jenkins credential	Kubernetes `Secret`과 `ServiceAccount`로 옮길 수 있는가?
agent workspace	`Workspace`, `PVC`, `emptyDir` 중 무엇으로 대체할 것인가?
plugin step	CLI, API call, custom `Task`로 바꿀 수 있는가?
build history	어디에 보관하고 어떻게 조회할 것인가?
manual approval	Tekton에서 어떤 방식으로 표현할 것인가?
UI/UX	개발자가 `PipelineRun` 상태를 어떻게 확인할 것인가?
permission	namespace와 RBAC를 어떻게 나눌 것인가?
cleanup	`PipelineRun`, `TaskRun`, pod, PVC를 언제 정리할 것인가?

특히 Jenkins plugin에 의존하던 기능은 Tekton에서 그대로 대응되지 않을 수 있다. Tekton은 완성형 CI/CD 제품이라기보다 Kubernetes-native CI/CD primitive에 가깝기 때문에, 필요한 기능을 Task, script, container image, Kubernetes resource 조합으로 명시해야 하는 경우가 많다.

Tekton은 Framework에 가깝다

Jenkins는 설치하면 UI에서 job을 만들고, plugin을 추가하고, credential을 설정하고, build history를 확인할 수 있다. 즉, 완성형 automation server에 가깝다.

Tekton은 Kubernetes 위에서 CI/CD 실행을 표현할 수 있는 primitive를 제공한다.

Tekton이 제공하는 핵심은 다음과 같다.

Task
TaskRun
Pipeline
PipelineRun
Trigger
Workspace
controller
CRD
pod 기반 execution model

하지만 실제 platform으로 운영하려면 추가 설계가 필요하다.

Git webhook endpoint 노출
authentication
authorization
dashboard
logging
artifact retention
PipelineRun cleanup
PVC cleanup
reusable task catalog
secret management
developer self-service UX
failure notification
approval flow
policy enforcement

따라서 Tekton을 도입할 때는 “Jenkins 대체품을 설치한다”보다 “Kubernetes-native CI/CD platform을 구성한다”는 관점이 더 적절하다.

선택 기준 정리

Jenkins를 선택하기 좋은 경우

기존 Jenkins 자산이 많다.
Jenkinsfile과 shared library가 이미 잘 구축되어 있다.
다양한 legacy system과 통합해야 한다.
UI 중심 job 운영이 필요하다.
Kubernetes가 주 runtime이 아니다.
plugin을 통한 빠른 통합이 중요하다.
중앙 CI/CD 서버 운영 모델이 조직에 맞다.
non-container build가 많다.

Tekton을 선택하기 좋은 경우

Kubernetes가 표준 platform이다.
pipeline 실행도 pod/container로 격리하고 싶다.
namespace/RBAC 기반 multi-tenant CI/CD가 필요하다.
GitOps, Argo CD, Kubernetes-native workflow와 결합하고 싶다.
CI/CD를 Custom Resource로 선언적으로 관리하고 싶다.
build/test/deploy step의 실행 환경을 container image로 고정하고 싶다.
platform team이 reusable Task와 pipeline template을 제공하려 한다.

운영 검증 포인트

Tekton 또는 Jenkins를 선택한 뒤에는 도구 자체보다 pipeline 운영 상태를 검증해야 한다.

검증 포인트	확인 질문
변경 추적성	production에 배포된 artifact가 어떤 commit에서 왔는가?
재현성	같은 commit을 다시 build하면 같은 artifact를 얻을 수 있는가?
권한 분리	pipeline별 credential과 secret 접근 범위가 최소화되어 있는가?
상태 확인	실패한 run의 log와 원인을 빠르게 확인할 수 있는가?
cleanup	오래된 build history, workspace, PVC, pod가 정리되는가?
보안	token, password, internal hostname, private IP가 log에 노출되지 않는가?
확장성	job 또는 PipelineRun이 많아져도 queue와 cluster resource가 감당 가능한가?
복구성	controller, cluster, registry, storage 장애 시 복구 절차가 있는가?

자칫 실수하기 쉬운 부분

Jenkins를 낡은 도구로만 보는 경우

Jenkins는 오래된 도구이지만 생태계가 넓고 legacy integration에 강하다. 기존 Jenkins 자산이 안정적으로 운영되고 있다면, 즉시 전환보다 점진적 분리가 더 현실적일 수 있다.

Tekton을 완성형 CI/CD 제품으로 기대하는 경우

Tekton은 framework에 가깝다. dashboard, approval, notification, artifact retention, cleanup, self-service UX는 별도로 설계해야 할 수 있다.

Workspace와 PVC cleanup을 놓치는 경우

Tekton pipeline이 많아지면 workspace와 PVC가 storage pressure를 만들 수 있다. pipeline run lifecycle과 storage cleanup 정책을 함께 정해야 한다.

Docker socket을 무심코 mount하는 경우

간단한 image build를 위해 Docker socket을 mount하면 보안 위험이 커진다. Kaniko, Buildah, BuildKit 등 대안을 검토하고, 필요한 경우 권한 범위를 최소화해야 한다.

Mental Model

Jenkins와 Tekton의 차이를 다음 mental model로 정리할 수 있다.

Jenkins mental model:
  Jenkins가 pipeline을 소유한다.
  Jenkins가 job을 trigger한다.
  Jenkins가 agent에게 일을 시킨다.
  Jenkins가 build history를 보관한다.

Tekton mental model:
  Git과 YAML이 pipeline 정의를 소유한다.
  Kubernetes가 PipelineRun과 TaskRun을 상태로 관리한다.
  Pod와 container가 실제 step을 실행한다.
  Workspace와 PVC가 task 간 파일을 연결한다.

따라서 Jenkins와 Tekton의 선택은 단순 도구 선택이 아니라 CI/CD 상태를 어느 platform에 둘 것인지에 대한 architecture decision이다.

정리

Jenkins와 Tekton은 모두 CI/CD pipeline을 만들 수 있다. 하지만 두 도구의 철학과 운영 모델은 다르다.

Jenkins는 controller와 plugin ecosystem을 중심으로 동작하는 automation server다.
Tekton은 Kubernetes Custom Resource와 pod/container 실행을 중심으로 동작하는 Kubernetes-native CI/CD framework다.
Jenkins의 강점은 성숙한 생태계, UI, plugin, legacy integration이다.
Tekton의 강점은 Kubernetes-native model, container-first execution, RBAC/namespace 기반 격리, GitOps와의 결합이다.
Jenkins의 운영 부담은 controller, plugin, Jenkins home 관리에 있다.
Tekton의 운영 부담은 Kubernetes resource, pod lifecycle, PVC, RBAC, cleanup, logging 설계에 있다.
Kubernetes가 표준 platform이라면 Tekton이 자연스럽지만, 기존 Jenkins 자산과 legacy integration이 많다면 Jenkins가 더 현실적일 수 있다.

결국 선택 기준은 다음 질문으로 압축된다.

CI/CD pipeline의 실행 상태를 Jenkins controller가 소유하게 할 것인가, 아니면 Kubernetes resource와 pod lifecycle로 표현할 것인가?

개요