주니어 개발자 포트폴리오, '시스템 설계자'로 업그레이드하는 DevOps 로드맵

코딩만 잘하는 개발자에서 '시스템 설계자'로: 포트폴리오 다각화 로드맵

혹시 이런 고민을 해본 적 없으신가요? "내 코드는 완벽한데, 왜 배포 과정에서 자꾸 문제가 생길까?", "면접관들이 자꾸 '어떻게 운영할 건가요?'라고 묻는데, 막막하다."

주니어 개발자로서 기술 스택을 쌓는 과정은 마치 벽돌을 쌓아 건물을 짓는 것과 같습니다. 하지만 시장은 이제 단순히 벽돌(코드)을 잘 쌓는 사람을 넘어, 그 벽돌을 가장 효율적이고 안정적인 방식으로 지탱하고, 전력 공급부터 구조 설계까지 책임질 수 있는 '건축가'를 원하고 있습니다.

만약 현재의 포트폴리오가 단순히 'CRUD 기능 구현'에 머물러 있다면, 지금이야말로 커리어의 다음 단계를 고민하고 '운영 및 배포(Ops)' 관점을 추가해야 할 때입니다. 이 글은 단순한 기술 나열이 아닌, 당신의 포트폴리오를 '실제 운영 가능한 시스템'으로 업그레이드하는 구체적인 로드맵을 제시합니다.

개발과 운영의 경계가 사라진 시대, 왜 DevOps 지식이 필수인가?

과거에는 개발팀(Dev)과 운영팀(Ops)이 분리되어 일하는 것이 일반적이었습니다. 개발자는 빠르게 기능을 만들고, 운영팀은 그 기능이 실제 환경에서 돌아가도록 고생하는 구조였죠. 이 과정에서 발생하는 '배포 지옥(Deployment Hell)'이 수많은 기술 부채를 낳았습니다.

DevOps는 이 두 영역의 경계를 허물고, 개발 초기 단계부터 운영의 안정성과 자동화를 염두에 두는 문화이자 방법론입니다. 단순히 툴을 많이 안다는 의미가 아닙니다. **'어떻게 하면 코드를 가장 빠르고, 가장 안전하게, 반복 가능하게 배포할 수 있을까?'**라는 시스템적 사고방식이 핵심입니다.

이제 기업들이 원하는 인재는 단순히 백엔드 API를 짜는 개발자가 아닙니다. 그들은 **'엔드투엔드 시스템 설계자'**입니다. 즉, 사용자 요청이 들어와서 데이터베이스에 저장되고, 캐싱되고, 최종적으로 사용자 화면에 표시되기까지의 전 과정을 책임지고 자동화할 수 있는 사람을 말합니다.

💡 개발자 vs. DevOps 엔지니어 포트폴리오 비교

포트폴리오 다각화를 위한 3대 핵심 기술 스택 로드맵

DevOps 역량을 포트폴리오에 녹여내기 위해 반드시 마스터해야 할 세 가지 핵심 축이 있습니다. 이 세 가지를 연결하는 것이 곧 '자동화된 시스템'을 구축하는 경험입니다.

1. IaC (Infrastructure as Code): 인프라를 코드로 관리하기

클라우드 리소스를 수동으로 클릭해서 만드는 것은 '운영자의 실수'가 개입될 여지가 큽니다. IaC는 이 모든 것을 코드로 정의하여 버전 관리하고, 필요할 때마다 동일하게 재현할 수 있게 만듭니다. 대표적인 툴이 Terraform입니다.

[Terraform을 사용한 AWS S3 버킷 생성 예시]

# main.tf
resource "aws_s3_bucket" "my_portfolio_bucket" {
  bucket = "my-unique-portfolio-bucket-2024"
  acl    = "private"

  tags = {
    Environment = "Dev"
    ManagedBy   = "Terraform"
  }
}

이 코드를 실행하면, AWS 콘솔에 접속하지 않고도 필요한 S3 버킷이 완벽하게 생성됩니다.

2. CI/CD 파이프라인 구축: 빌드부터 배포까지 자동화하기

CI/CD(지속적 통합/지속적 배포)는 코드가 커밋되는 순간부터 테스트, 빌드, 그리고 실제 서버에 배포되기까지의 전 과정을 자동화하는 과정입니다. GitHub Actions는 이 과정을 가장 쉽게 구현할 수 있게 해주는 훌륭한 도구입니다.

[GitHub Actions YAML 워크플로우 예시: 코드 푸시 시 테스트 및 빌드]

name: CI/CD Pipeline Test & Build

on:
  push:
    branches: [ main ]

jobs:
  build_and_test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3 # 코드 체크아웃
    - name: Set up Java
      uses: actions/setup-java@v3
      with:
        java-version: '17'
    - name: Build and Test
      run: |
        mvn clean install # Maven을 이용해 빌드 및 테스트 실행

이 워크플로우는 main 브랜치에 코드가 푸시될 때마다 자동으로 테스트를 실행하고, 성공하면 다음 단계(배포)로 넘어갈 준비를 마칩니다.

3. 컨테이너화와 오케스트레이션: Docker와 Kubernetes

애플리케이션을 어떤 환경(개발자 PC, 테스트 서버, 실제 운영 서버)에 배포하든 동일하게 동작하도록 패키징하는 것이 Docker의 역할입니다. 그리고 수많은 컨테이너들을 마치 하나의 거대한 시스템처럼 관리하고 자원을 할당하는 것이 **Kubernetes (K8s)**의 역할입니다.

🚀 '경험'을 '결과물'로 만드는 실전 프로젝트

이 세 가지 기술을 결합하여 하나의 완성도 높은 프로젝트를 만드세요.

[프로젝트 예시: 간단한 API 서버 구축 및 배포]

1. 개발: Spring Boot 등으로 API 서버를 만듭니다.
2. 컨테이너화: Dockerfile을 작성하여 이 서버를 컨테이너 이미지로 만듭니다. (Docker 사용)
3. CI/CD 자동화: GitHub Actions (또는 Jenkins)를 설정하여, 코드가 푸시될 때마다 자동으로 테스트를 실행하고, 이미지를 빌드하여 Docker Hub에 푸시합니다. (CI/CD 구현)
4. 배포: 클라우드(AWS ECS, Google Cloud Run 등)에 배포하고, 로드 밸런서를 통해 접근 가능하게 만듭니다. (실제 배포 경험)

이 과정 자체가 당신의 포트폴리오가 됩니다. 단순히 "이 기술을 사용해봤습니다"가 아니라, "이런 문제를 해결하기 위해 이 기술 스택을 조합하여 이 파이프라인을 구축했습니다"라고 설명할 수 있어야 합니다.

💡 핵심 요약: 면접관에게 어필할 키워드

• "저는 단순히 코드를 짜는 개발자가 아닙니다. 안정적인 운영 환경까지 고려하는 개발자입니다."
• "IaC (Infrastructure as Code) 개념을 이해하고 있으며, CI/CD 파이프라인을 직접 구축해봤습니다."
• "Docker를 통해 환경 의존성을 제거하고, 컨테이너 기반으로 배포 프로세스를 표준화했습니다."

포트폴리오 프로젝트를 검증 가능하게 만드는 방법

DevOps 포트폴리오에서 면접관이 확인하고 싶은 것은 도구 목록이 아니라 실제로 동작하고, 다시 만들 수 있는가입니다. 흔한 약점은 README의 스크린샷만 있고 재현 절차가 없는 것입니다.

약점이 생기는 원인

• 클라우드 리소스를 콘솔에서 만들고 코드로 남기지 않아 재현 불가
• CI 파이프라인이 한 번 성공한 뒤 방치돼, 지금은 실패 상태
• 비밀값을 저장소에 커밋했다가 지운 흔적이 커밋 기록에 남음

점검 절차

# 1) 깨끗한 환경에서 처음부터 재현되는지
git clone <repo> /tmp/check && cd /tmp/check
terraform init && terraform plan          # 인프라 코드
docker compose up -d && curl -fsS localhost:8080/health
# 2) CI 상태 확인 (GitHub CLI)
gh run list --limit 5
# 3) 커밋 기록에 비밀값이 남았는지
gitleaks detect --source . --log-opts="--all"

보완 방법

• README에 "5분 안에 실행하기" 절차(필요 도구 버전, 명령, 예상 출력)를 적고, 위 1번을 CI에서 매주 실행합니다.
• 장애 상황을 하나 만들어 보고(예: 컨테이너 강제 종료, 디스크 가득 참) 알림·복구가 어떻게 동작하는지 기록하면, 운영 역량을 보여 주는 근거가 됩니다.
• 비밀값이 커밋 기록에 남았다면 해당 키를 폐기·재발급하고, 필요하면 기록에서 제거합니다.

유지 관리

• 클라우드 비용이 계속 나가지 않도록 데모 환경은 terraform destroy로 내려 두고, 필요할 때 다시 만드는 절차 자체를 포트폴리오의 일부로 보여 줍니다.