Backend & DevOps Engineer

복잡한 배포와 데이터 흐름을 자동화 가능한 시스템으로 바꿉니다.

Backend와 DevOps를 경계 없이 다루며, 반복되는 운영 문제를 시스템과 자동화로 해결합니다.
BackendDevOpsInfrastructureAI Context
SCROLL TO EXPLORE
01 / AT A GLANCE

What I
built.

먼저 전체 그림을 보여주고, 아래에서 각 시스템을 자세히 살펴봅니다.
01 / CI

CI Pipeline

Branch와 Version 정책을 기준으로 테스트·빌드·아티팩트 생성을 자동화한 CI Pipeline

Branch→Jenkins→Version→E2E
02 / CD

CD / GitOps

Docker Registry와 Ansible로 On-Premise 환경을 표준화하고 GitOps 기반 점진 배포를 구축

Manifest→Komodo→Fleet
03 / BACKEND

Backend

DICOM 수신부터 Queue·AI Inference·Report까지 연결한 비동기 Backend 처리 시스템

API→Queue→Worker→AI
04 / LLM-WIKI

LLM Wiki

CRM·Issue·Repository의 Context를 Agent와 Ontology로 구조화한 Knowledge Platform

Event→Agent→Wiki→LLM
CI로 만들고 → Infra로 표준화하고 → GitOps로 배포하고 → Backend와 LLM Context까지 연결했습니다.
02 / PROFILE

Engineering
Profile

Backend와 DevOps를 경계 없이 다루며, 반복되는 운영 문제를 시스템과 자동화로 해결해 왔습니다.
“개발이 끝나는 지점이 아니라,
운영 가능한 시스템이 되는 지점까지 설계합니다.”
3Y 10M
EXPERIENCE
110+
ON-PREMISE SERVERS
CORE STACK

Backend / DevOps / AI

PythonFlaskFastAPIRedis Queue DockerJenkinsGitLab CIKomodoAnsible TerraformAWS LambdaDICOMLLM AgentOntology
03 / SELECTED PROJECTS

Systems I
built.

전체 개요를 먼저 보고, CI / CD / Backend / LLM-Wiki의 실제 설계와 구현으로 내려갑니다.
PROJECT 01 / CI
CI/CD & Ansible
Automation
DEVOPS ENGINEER

GitLab의 Branch Naming 규칙과 Jenkins Pipeline을 연결해 버전 계산, 테스트, 빌드, 아티팩트 생성까지 자동화했습니다. 이후 Docker Registry와 Ansible을 통해 설치·운영 환경까지 표준화했습니다.

GitLabJenkinsSemantic VersioningDocker RegistryAnsible
01 / SOURCE

GitLab

Branch / Merge Request

02 / TRIGGER

Jenkins

Webhook Pipeline Trigger

03 / VERIFY

E2E Test

Quality Gate

04 / VERSION

Versioning

Branch Policy → SemVer

05 / PACKAGE

Artifact

Docker Image / Build Artifact

06 / DELIVERY

Registry

Push & Next-stage Delivery

Branch Naming & Versioning Policy

SEMANTIC VERSIONING

Branch prefix를 릴리즈 의도와 직접 연결했습니다. major/*는 Major, feature/*는 Minor, 그 외 변경은 Patch 버전을 증가시킵니다.

major/*
호환성이 깨지는 변경 또는 대규모 릴리즈
MAJOR ↑
feature/*
신규 기능 추가 또는 기능 확장
MINOR ↑
fix/*
버그 수정 및 작은 개선
PATCH ↑
hotfix/*
운영 환경 긴급 수정
PATCH ↑
others
기타 유지보수 변경
PATCH ↑
예시 · current 1.4.2
major/login-api-v2 → 2.0.0
feature/dashboard → 1.5.0
fix/login-bug → 1.4.3
hotfix/security → 1.4.3

CI Pipeline Flow

GITLAB → JENKINS
01
Merge Trigger

개발 Branch가 staging에 merge되면 CI를 시작합니다.

02
Version Resolve

Branch Prefix를 읽어 Major / Minor / Patch 증가 규칙을 계산합니다.

03
Jenkins Trigger

staging → main merge 시 GitLab Webhook으로 Jenkins Job을 자동 실행합니다.

04
E2E & Version Check

E2E 테스트 통과 여부와 이전 버전 대비 버전 상승 여부를 검증합니다.

05
Build Strategy

Major는 Docker Image를 빌드하고, Minor/Patch는 코드 기반 아티팩트를 생성합니다.

06
Artifact Delivery

생성된 이미지/아티팩트를 Registry 또는 다음 배포 단계가 사용할 수 있게 저장합니다.

Installation Automation

ANSIBLE

서버별 수동 명령 입력을 Playbook 기반 단일 명령으로 전환해 최초 PC/서버 셋업 절차를 표준화했습니다.

01
Host CheckOS / Host / 사전 조건 점검
02
Base Setup필수 패키지 및 기본 환경 구성
03
Config Deploy환경 변수·설정 파일 배포
04
Service Start서비스 기동 및 등록
05
Health Verify기동 상태와 결과 검증

Why this mattered

OUTCOME
릴리즈 일관성Branch와 Version 정책을 코드화해 사람의 판단 편차를 줄였습니다.
품질 게이트E2E와 버전 검증을 통과한 결과만 아티팩트로 생성되도록 구성했습니다.
환경 표준화Ansible Playbook으로 신규 서버를 동일한 절차와 상태로 구성했습니다.
운영 부담 감소반복적인 빌드·설치 작업을 자동화해 수동 작업과 휴먼 에러를 줄였습니다.
PROJECT 02 / CD
On-Premise GitOps
CD Platform
DEVOPS ARCHITECT & LEAD ENGINEER / 100%
THE PROBLEM110여 개 온프레미스 서버를 개발자가 직접 접속하거나 Ansible Push로 배포하던 구조. 외부망 서버와 사내망 사이의 연결 제약까지 있어 대규모 GitOps 배포가 어려웠습니다.

CD의 핵심은 110여 개 On-Premise 서버에 한 번에 Push하는 것이 아니라, 중앙에서 원하는 상태를 선언하고 각 서버가 안전하게 따라가도록 만드는 것입니다.

CONTEXT

On-Premise scale

외부망 서버와 사내망 서버가 혼재하고 서버 수가 많아 중앙 Push 방식의 운영 부담이 컸습니다.

INFRA

Registry + Ansible

Docker Registry를 중앙 Artifact 저장소로 구성하고, 최초 PC/서버 환경은 Ansible로 표준화했습니다.

CD

GitOps / Komodo

Manifest 변경을 배포 신호로 사용하고 Test → Canary → Early → Fleet 순으로 점진 배포했습니다.

SCOPE110+ Servers
STRATEGY4 Rings
FLEET6 Batches
CONTROLGitOps
01 / DELIVERY SYSTEMCI → INFRA → CD
READY
01
CIBuild & Release Decision
⌘
GitLabbranch / merge
⚙
Jenkinspipeline
v
VersionSemVer policy
▣
Buildtest / artifact
feature / fix / hotfix → version policy → E2E → artifact
↓ artifact ↓
02
INFRAFoundation for Deployment
◫
Docker Registryimage / artifact store
◇
Ansibleinitial PC setup
⌁
On-Premiseserver environment
server baseline · package · config · service start · status verify
↓ manifest ↓
03
CDGitOps Deployment
≡
Manifestrollout.json
K
KomodoGitOps sync
PROGRESSIVE ROLLOUT110+
TEST1
CANARY3
EARLY10
FLEET6 batches
Pull → Deploy → Verify · Batch rollout · promotion control
Click RUN to simulate Test → Canary → Early → Fleet promotion.

Key Decisions

  • Docker Registry를 중앙 아티팩트 저장소로 구축
  • Manifest Repository를 분리해 GitOps 구조화
  • 4단계 Cohort/Ring으로 점진적 배포
  • Fleet은 20개 단위 6 Batch로 순차 처리

Verification

Test 검증 후 Canary → Early → Fleet으로 버전을 Promotion하고, Fleet에서는 Pull / Deploy / Verify를 분리해 Registry Network Traffic Spike를 방지했습니다.

110+ON-PREMISE SERVERS
90%+DEPLOYMENT TIME REDUCTION
6FLEET BATCHES
PROJECT 03 / BACKEND
Medical AI
Backend Pipeline
LEAD BACKEND DEVELOPER
THE PROBLEMDICOM 수신부터 메타데이터 추출, AI 추론 서버 라우팅, 리포트 생성까지 이어지는 의료영상 처리 흐름을 수동 개입 없이 안정적으로 연결해야 했습니다.

Backend는 각각의 기능을 따로 만드는 것이 아니라, 의료영상이 들어온 뒤 분석과 리포트 생성까지 이어지는 비동기 처리 흐름을 안정적으로 연결하는 데 초점을 맞췄습니다.

INPUT

DICOM ingestion

C-STORE / StoreSCP로 영상 데이터를 수신하고 파일 상태와 메타데이터를 확인합니다.

PROCESS

Async pipeline

Redis Queue 기반 Worker가 분석 작업을 비동기로 처리하고 Timeout과 Error 상태를 관리합니다.

OUTPUT

AI / Report

AI Inference Server로 요청을 라우팅하고 결과를 PDF/DICOM 형태로 변환해 후속 시스템에 전달합니다.

INPUTDICOM
QUEUERedis Queue
ENGINEAI Server
OUTPUTReport
DATA FLOW
DICOM / C-STORE / StoreSCP
Redis Queue — Async Worker
Timeout Detection + Metadata Extraction
AI Inference Server Routing
PDF Report / DICOM Conversion

License Platform

FastAPI 기반 발급/검증/만료 관리 REST API를 만들고 AWS Lambda + API Gateway를 Terraform으로 IaC 관리했습니다.

Admin Dashboard

React 기반으로 재설계하여 실시간 리소스 모니터링, Analysis Error Trace, 재처리 및 Queue 관리 UX를 개선했습니다.

PROJECT 04 / LLM-WIKI
Agent-based LLM
Knowledge Platform
SYSTEM ARCHITECT & BACKEND DEVELOPER / 100%
THE PROBLEM아키텍처, 솔루션 스펙, CRM 요청, 버그 수정 등 파편화된 Context를 LLM이 빠르게 검색하고 이해할 수 있는 SSOT가 필요했습니다.

LLM-Wiki의 목표는 문서를 많이 만드는 것이 아니라, 흩어진 업무 Context를 LLM이 안정적으로 찾아갈 수 있는 구조로 만드는 것이었습니다.

SOURCE

Context events

CRM, Issue/Bug, Repository 등 여러 시스템에서 변경 이벤트와 정보를 수집합니다.

AGENT

Summarization

Agent가 원본 정보를 Wiki 형식으로 정리하고 관계를 유지할 수 있는 Context를 생성합니다.

SSOT

Ontology + metadata

crm / dev / ops Ontology와 Frontmatter를 사용해 링크, Load Tier, Evidence를 구조화합니다.

INPUTCRM / Issue
PROCESSAgent
MODELOntology
OUTPUTLLM Wiki
KNOWLEDGE GRAPH
CRM
ISSUE / BUG
REPOSITORY
AGENT
WIKI / SSOT
LLM QUERY
CONTEXT PIPELINE

Event → Agent → Structured Context

Event Detection — Issue / CRM / Bug / Repository
Agent Summarization — Wiki format
Ontology — crm / dev / ops
Frontmatter — Links / Load Tiers / Evidence
Queries — Context ingestion optimization
04 / ENGINEERING PRINCIPLES

How I
engineer.

프로젝트마다 달랐던 문제를 관통하는 세 가지 원칙입니다.
01

AUTOMATE WHAT REPEATS.

반복되는 운영 작업은 사람의 숙련도가 아니라 시스템의 규칙으로 처리합니다.

02

STRUCTURE WHAT SCALES.

서버 수와 Context가 커져도 유지되는 구조를 먼저 설계합니다.

03

VERIFY WHAT MATTERS.

배포와 데이터 처리의 마지막 단계까지 상태를 검증하고 실패를 관찰 가능하게 만듭니다.