90DaysOfDevOps (Day 81)

고태규·2026년 1월 30일
devops

DevOps

목록 보기
76/87
post-thumbnail

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 81 - Leveraging Kubernetes to build a better Cloud Native Development Experience

1. Okteto에 대한 발전 배경 (문제 제기)

1-1. 배포에서 개발로의 관점 이동

2014년 쿠버네티스 초기 시절, 업계의 주된 관심사는 워크로드를 어떻게 쿠버네티스에 배포할 것인가였다.

당시에는 배포 자체가 난제였기에 'Kubernetes the Hard Way'와 같은 학습 자료나 Rancher Desktop 같은 솔루션들이 등장하며 배포의 복잡성을 해결하려 했다.

하지만 시간이 흐르며 상황은 변했다.

개발자의 본질은 인프라 배포가 아닌 코드 작성에 있다.

개발자는 불필요한 배포에 시간을 쏟기보다 비즈니스 로직 구현에 집중하기를 원한다.

1-2. 전통적인 개발 루프의 고통

일반적인 클라우드 네이티브 애플리케이션 개발 프로세스이다.

  1. SRS(요구사항) 분석 및 코딩: 개발팀이 기능을 구현한다.

  2. 컨테이너화: Dockerfile을 작성하고 이미지를 빌드한다.

  3. 레지스트리 Push: 빌드된 이미지를 컨테이너 레지스트리에 업로드한다.

  4. Pull 및 배포: 쿠버네티스 클러스터에서 이미지를 받아(Pull) 배포한다.

문제는 기능 추가나 버그 수정이 필요할 때마다 이 과정을 무한 반복해야 한다는 점이다.

  • 시나리오: 로컬에서 코드를 수정했다. 이 변경 사항이 운영 환경과 유사한 쿠버네티스 환경에서 어떻게 동작할지 확인해야 한다.

  • 비효율: 코드를 한 줄 고칠 때마다 이미지 Build -> Push -> Pull -> 배포 과정을 거쳐야 한다.

  • 리스크: 로컬에서는 잘 작동하던 코드가 실제 클러스터에 배포되었을 때 의존성 문제 등으로 터질 수 있다. "내 컴퓨터에서는 되는데?"라는 상황이 발생한다.

1-3. 제1원칙에 입각한 해결책

이 문제의 핵심은 피드백 루프가 너무 길고, 운영 환경과의 괴리가 크다는 것이다.

이를 해결하기 위한 이상적인 솔루션은 다음과 같다.

"이미지를 매번 빌드하지 않고, 로컬 머신의 변경 사항이 쿠버네티스 클러스터 내부의 애플리케이션과 즉시 동기화되어 Preview 환경에서 바로 확인할 수 있다면 어떨까?"

이것이 바로 Okteto가 해결하고자 하는 지점이다.

2. 솔루션: Okteto (The Solution)

Okteto의 핵심 기능은 로컬 개발 환경과 클러스터 환경의 실시간 동기화다.

이를 통해 개발자는 매번 이미지를 빌드/배포하는 과정 없이, 로컬에서 코드를 저장하는 즉시 클러스터에 반영된 결과를 확인할 수 있다.

  • Okteto CLI & Cloud: CLI와 관리형 클라우드 서비스를 모두 제공한다.

  • Preview 환경: PR 단계에서 변경 사항이 적용된 라이브 프리뷰를 자동으로 생성할 수 있다.

  • 동기화 메커니즘: 로컬 파일 시스템의 변경 사항을 컨테이너 내부로 즉시 전송한다.

2.1. 핵심 아키텍처 및 작동 원리

Okteto은 단순한 파일 복사가 아니다.

기존에 배포된 애플리케이션의 컨테이너를 개발용 컨테이너로 교체하는 기술이 핵심이다.

  • 배포 교체:

    • okteto up을 실행하면, Okteto는 기존의 운영용 Pod를 내리고 개발 도구(컴파일러, 디버거 등)가 포함된 Dev Container로 교체하여 재실행한다.

    • 개발이 끝나면 원래 설정으로 자동 복구된다.

  • 양방향 파일 동기화:

    • 로컬 PC의 소스 코드 디렉토리와 클러스터 내 컨테이너를 네트워크로 연결한다.

    • 로컬에서 파일을 저장하는 순간, 변경된 파일만 즉시 컨테이너로 전송되며, 컨테이너 내부의 Hot Reload 도구가 이를 감지해 프로세스를 재시작한다. (소요 시간: 0.5초~2초)

  • 자동 포트 포워딩:

    • 별도의 Ingress 설정이나 kubectl port-forward 없이도, 로컬호스트(localhost:8080)로 요청을 보내면 터널링을 통해 클러스터 내부의 컨테이너로 안전하게 전달된다.

2-2. 주요 기능 상세

  • Okteto Manifest (okteto.yml)

    • Okteto가 어떻게 동작해야 하는지 정의하는 설정 파일이다.

    • Dockerfile만 있어도 자동 추론하지만, 정교한 제어를 위해 작성한다.

    • # okteto.yml 예시
name: my-api
image: okteto/node:18  # 개발에 사용할 도구가 포함된 이미지
command: ["bash"]      # 컨테이너 시작 시 실행할 셸
sync:
  - .:/usr/src/app     # 로컬의 현재 폴더(.)를 컨테이너의 /usr/src/app과 동기화
forward:
  - 8080:8080          # 포트 포워딩 설정
  - 9229:9229          # 디버거 포트 연결 (원격 디버깅 가능)

    • 이 설정을 통해 어떤 이미지로 교체할지, 어떤 폴더를 동기화할지를 지정한다.

  • Preview 환경

    • GitHub/GitLab과 연동하여 PR가 생성될 때마다 격리된 네임스페이스에 해당 코드를 배포한다.

    • Before: "내 로컬에서 돌려봤는데 잘 돼. 머지해줘." (검증 불가)

    • After: "PR 34번 프리뷰 링크 생성됐어. 거기서 직접 눌러봐." (확실한 검증)

    • DB, Redis 등 연관된 모든 서비스를 포함한 전체 스택을 띄워주므로 통합 테스트에 유리하다.

    • PR이 닫히거나 머지되면 해당 환경(네임스페이스)은 자동으로 삭제되어 리소스 낭비를 막는다.

  • 원격 디버거 연결

    • 파일 동기화뿐만 아니라 디버깅 포트도 연결된다.

    • 로컬 IDE에서 중단점을 찍으면, 쿠버네티스 클러스터에서 실행 중인 코드가 멈추고 변수 상태를 검사할 수 있다.

3. 데모 시연 및 동작 원리

발표에서는 'Movies with Compose'라는 React, Node.js, MongoDB, Nginx로 구성된 마이크로서비스 애플리케이션을 통해 Okteto의 장점을 어필했다.

3-1. 초기 설정 및 배포 (okteto up)

  • 애플리케이션 준비: docker-compose.yml 또는 Dockerfile이 있는 프로젝트를 준비한다. 쿠버네티스 매니페스트가 없어도 된다.

  • 명령어 실행: okteto context로 클러스터를 지정하고 okteto up을 실행한다.

  • 자동화된 프로세스:

    • Okteto는 소스 코드를 분석하여 필요한 이미지를 빌드하고 Okteto Cloud 혹은 지정된 클러스터에 배포한다.

    • 각 서비스(API, Frontend, DB 등)와 외부 접속을 위한 엔드포인트(URL)를 자동으로 생성한다.

3-2. 개발 컨테이너 활성화

배포가 완료되면 Okteto는 사용자에게 "어떤 서비스를 개발 모드로 전환할 것인가?"를 묻는다.

  • 사용자가 특정 서비스(예: API)를 선택하면, Okteto는 해당 서비스의 기존 운영 컨테이너를 개발 컨테이너로 교체한다.

  • 해당 개발 컨테이너는 로컬 머신의 소스 코드 디렉토리와 볼륨 동기화가 설정되어 있다.

  • 터미널은 해당 컨테이너의 Shell로 바로 연결된다.

3-3. 실시간 코드 수정 및 반영

시연에서는 영화 목록이 중복해서 출력되는 버그를 수정하는 과정을 보여주었다.

  1. 버그 확인: 생성된 프리뷰 URL로 접속하여 버그를 확인한다.

  2. 코드 수정: 로컬 IDE에서 server.js 파일을 열어 db.collection('movies')를 올바른 컬렉션으로 수정하고 저장한다.

  3. 즉시 반영: 별도의 docker build나 kubectl apply 명령어가 필요 없다. 저장하는 순간 Okteto가 변경된 파일을 컨테이너로 동기화한다.

  4. 결과 확인: 브라우저를 새로고침하면 수정된 코드가 즉시 반영되어 버그가 해결된 것을 볼 수 있다.


3-4. Dockerfile만으로 충분하다

가장 강력한 장점 중 하나는 복잡한 쿠버네티스 지식이 없어도 된다는 점이다.

Dockerfile이나 docker-compose.yml만 있다면, Okteto가 이를 기반으로 쿠버네티스 배포를 자동으로 처리하고 프리뷰 환경을 구축해준다.

4. 결론

과거에는 배포 자체가 목적이었다면, 지금은 얼마나 빠르고 효율적으로 개발하고 검증할 수 있는가가 핵심이다.

따라서 프레젠테이션은 Okteto가 다음과 같은 가치를 제공한다고 주장한다.

  • Inner Loop 단축: 코드 수정부터 확인까지의 시간을 획기적으로 줄여준다.

  • Prod-like Dev: 로컬(Docker Desktop 등)이 아닌 실제 쿠버네티스 클러스터 위에서 개발하므로, 배포 시 발생할 수 있는 환경 차이 문제를 사전에 방지한다.

  • 오픈 소스: Okteto CLI는 오픈 소스이며 활발한 커뮤니티 지원을 받고 있다.


profile
고태규
이전 포스트

90DaysOfDevOps (Day 80)

다음 포스트

90DaysOfDevOps (Day 82)

0개의 댓글