김상균

About

'질문은 해답보다 중요하다.' 질문을 위해 움직이는 개발자입니다.

시작

• 학교 커리큘럼은 프론트·백엔드·DB까지였고, 인프라·클라우드를 다뤄 볼 기회는 없었습니다.
• 그래서 도메인·공유기·미니 PC를 직접 사서 홈서버를 세우고 운영했습니다. 웹 퍼블리싱, 로컬 LLM, 게임 서버, AI 개인비서(iCloud + Obsidian + Claude)등 다양한 시도를 했습니다.

확장

• 홈서버 (졸업작품 추론 서버) → 기업 NAS (스타트업 인턴, 사내 인프라 구축) → 클라우드 (카카오 AIaaS, Kubernetes·하이브리드 DR) 순으로 규모를 넓혀 왔습니다.
• 단계마다 앞에서 느낀 한계가 다음 단계의 목표가 됐습니다. 단일 머신의 한계와 수동 배포의 불편이 K8s와 GitOps로 이어졌습니다.

일하는 방식

• 좌우명은 "무리해서 쌓은 하루보다 잘 쌓은 하루" 입니다. 양보다 방향을 제대로 잡고 끝까지 완결하는 것을 중요하게 생각합니다.
• 장애는 임시 복구로 끝내지 않고 재발 방지까지 자동화하고, 작업은 문서와 코드(IaC)로 남겨 다른 사람이 이어받을 수 있게 합니다.

Project 01 · 카카오 AIaaS

목표와 문제 인식

목표

• 추천 서비스를 데모가 아니라 실제로 운영 가능한 수준으로 클라우드에 올린다.
• 배포와 모델 학습을 사람이 손으로 하지 않도록 파이프라인으로 자동화한다.

문제 인식

• 주어진 자원이 고정 스펙 VM 5대였습니다. 매니지드 K8s(EKS 등)를 쓸 수 없어 클러스터를 직접 구성해야 했습니다.
• KakaoCloud는 무료로 지원받은 자원이라 최대한 활용하되, 단일 환경만으로는 장애에 안정적으로 대응하기 어렵다고 판단했습니다.
• 이전 프로젝트(TeamTalk)에서 단일 머신의 한계와 SSH + git pull 수동 배포의 불편을 겪었습니다.
• 기획·라벨링·디자인은 팀원이, 기술 구현은 제가 맡는 구조라 기술 지식이 한 사람에게 몰렸습니다. 다른 사람도 재현할 수 있는 형태로 남길 필요가 있었습니다.

접근

• 셀프매니지드 Kubernetes(k3s) · KakaoCloud 메인 + AWS DR 하이브리드 · GitOps 배포 · Terraform/Ansible 코드화 · 부하 테스트로 한계 검증.

Project 01 · 카카오 AIaaS

DR 상시 운영비 월 $110 → $49

문제

• DR 환경은 평소에 거의 쓰이지 않는데도, 구현해 보니 상시 운영비가 월 약 $110 로 예상됐습니다. 비용 대부분은 관리형 NAT Gateway였습니다.

조치

• 관리형 NAT Gateway·EIP 제거 (−$46/월): 앱·DB를 퍼블릭 서브넷으로 옮기고 공인 IP를 붙여 아웃바운드를 대체.
• DB 인스턴스 t3.medium → t3.small (−$19/월): DR 대기 상태에 맞게 다운사이징.
• 대신 보안 그룹으로 인바운드를 최소화: 앱(3000)은 ALB에서만, DB(5432)는 앱에서만, WireGuard(51820)는 KakaoCloud IP에서만 허용. SSH는 열지 않고 SSM으로 접근, IMDSv2 강제.

트레이드오프

• 퍼블릭 서브넷 구조라 보안 그룹을 잘못 설정하면 영향 범위가 커집니다. 관리자 CIDR은 본인 IP /32로 좁혔고, 민감한 환경이라면 NAT를 복원하는 것이 정석이라고 판단합니다.

월 상시 운영비 (기존 $110)

$49

DR 비용 절감

−55%

Project 01 · 카카오 AIaaS

감정 곡선 추천 모델과 ML 파이프라인

모델

• ① LLM이 장면마다 대사를 보고 라벨링 → ② RoBERTa 로 Valence(긍·부정)·Arousal(각성도)를 회귀 예측 → ③ 영화별 감정 타임라인을 스케일링·스무딩·임베딩 → ④ 코사인 유사도 로 곡선이 비슷한 영화 추천.

파이프라인

• 백엔드 cron으로 데이터를 수집하고, Argo Workflow 에서 파싱 → 전처리 → 학습 → 스코어링을 한 번에 실행합니다.
• 재학습 기준은 새 라벨 데이터가 기존 대비 25% 늘었을 때로 설계했습니다. 감정 라벨은 정답과 비교하기 어려워, 성능 지표보다 단순하고 명확한 데이터 증가량을 택했습니다.

판단

• Redis 캐시를 검토했지만, 서비스가 단순하고 이미지·정적 자원은 외부 CDN이 더 빨라 오히려 오버헤드라고 판단해 넣지 않았습니다.

한계

• 현재 파이프라인 트리거는 수동이고, KServe 서빙 → 모니터링 → 자동 재학습 루프는 다음 단계로 남아 있습니다.
• LLM 라벨의 품질 검증과 자막이 없는 신작(콜드 스타트) 대응도 남은 과제입니다.

Project 01 · 카카오 AIaaS

부하 테스트 ① — 안전하게 한계를 찾는 방법부터

목표

• 실제 트래픽이 몰렸을 때 어디서 먼저 무너지는지를 추측이 아니라 데이터로 확인한다.

설계

• 서비스 클러스터와 분리된 VPC·VM에 k6 를 두어 부하 생성기가 서비스 자원을 먹지 않게 했습니다.
• VU를 점진적으로 올리고, p95 3초 또는 에러율 5%를 넘으면 자동 중단하도록 안전장치를 걸었습니다.
• 응답 지연을 FE 페이지 · DB 조회 · BE 처리 경로별로 나눠 계측하고, Grafana·Loki로 HPA 확장과 노드 CPU를 실시간으로 봤습니다.

1차 결과

• 500 VU에서 p95 2.12초, 에러율 0% 로 안정적이었습니다.
• HPA가 FE 2 → 6개, BE 1 → 4개 로 확장됐다가 부하가 끝나면 복귀하는 것을 확인했습니다.

500 VU p95

2.12s

에러율

0%

Project 01 · 카카오 AIaaS

부하 테스트 ② — 병목을 옮기며 한계를 5배로

과정

• 붕괴점을 직접 찾아가며, 천장 하나를 없애면 다음 천장이 어디로 옮겨가는지를 단계별로 확인했습니다.

서비스 처리 한계 (700 → 3600 VU)

~5×

p95 응답 (기존 4.5s)

0.66s

스코어 API 한계 (500 → 3777 VU)

~7×

Project 01 · 카카오 AIaaS

부하 테스트 ③ — 그래프로 본 천장의 이동

캐싱 전

• FE 레플리카는 2 → 6개로 늘었지만, DB 노드(10.1.5.10) CPU가 100%에 붙어 버렸습니다. 앱 노드는 40% 안팎으로 여유가 있었습니다.
• 앱을 더 늘려도 소용없고, DB가 천장이라는 뜻이었습니다.

캐싱 후

• DB 노드 CPU는 20%대로 내려갔고, FE 레플리카가 HPA 최대치인 16개까지 늘었습니다.
• 이번에는 앱 노드 두 대(10.1.3.10 · 10.1.4.10)가 100% 에 가까워졌고, 자리를 못 잡은 Pending 파드가 5개 생겼습니다.

결론

• 천장이 DB에서 app 워커 노드의 용량으로 옮겨 갔습니다. 다음 개선은 설정이 아니라 노드 증설이라는 근거가 됐습니다.

캐싱 개선 전 — DB 노드 CPU 100% · 클릭하면 원본캐싱 개선 후 — 앱 노드 포화, Pending 5 · 클릭하면 원본

Project 02 · Wanted AI Championship

운영 사고에서 재발 방지까지 — 서버를 main의 거울로

사고

• 배포는 성공했는데 운영 AI가 규칙 기반 폴백으로 돌고 사건 API가 503. 원인은 두 겹이었습니다. ① Compose의 치환용 .env 와 컨테이너 주입용 env_file 을 혼동 ② 수동 재기동 때 pull 을 빼먹어 옛 이미지가 뜸.
• 응답 문구로 원인을 갈랐습니다. FastAPI 기본 Not Found 면 라우트가 없는 옛 이미지, 우리 코드의 Case not found 면 DB까지 정상, Storage unavailable 이면 DB 주소 없음.

재발 방지

• 뿌리는 서버 설정이 레포와 조용히 어긋날 수 있는 구조였습니다. 배포 스크립트가 git reset --hard origin/main 으로 서버를 강제 동기화하고, 서버마다 다른 값은 .env 로만 두게 했습니다. 배포 후 실제로 뜬 이미지를 로그에 남깁니다.

Project 02 · Wanted AI Championship

동시 제출 · 만료 · 권한을 DB와 서버가 보장

동시 제출

• 모든 쓰기가 상태 조건부 UPDATE 를 먼저 실행합니다. 이 UPDATE의 행 락 때문에 동시에 온 두 번째 요청은 바뀐 상태를 보고 0행을 얻고 409를 받습니다. 사과문·카드는 case_id PK·UNIQUE로 DB가 한 번 더 막습니다.
• 맞고소는 카드·리포트·상태 전이를 한 트랜잭션으로 묶고, LLM 호출은 트랜잭션 밖에서 먼저 해 실패 시 아무것도 남지 않게 했습니다.

만료

• pg_cron이 매시 삭제하고, 그 사이 최대 1시간은 조회·쓰기 양쪽의 lazy 검사가 막습니다. 쓰기까지 막지 않으면 삭제된 사건에 답변이 들어와 되살아납니다.
• 잡이 멈춰도 사용자 눈엔 정상으로 보이는 실패라, 실행 이력을 직접 조회해 매시 succeeded 를 확인했습니다.

권한

• 로그인 없이 링크용 public_token 과 A 전용 writer_token 을 발급하고 서버는 SHA-256 해시만 저장합니다. B에게는 토큰을 요구하지 않습니다. 요구하면 "링크 하나로 전달"이 깨집니다.
• RLS는 켜고 정책은 0개. 프론트에 anon 키가 노출돼도 데이터가 새지 않습니다.

Project 03 · TeamTalk

목표와 문제 인식

목표

• 범용 대형 모델은 비용이 크고 한 관점에 치우치기 쉽습니다. 역할별 소형 모델의 협업으로 저비용·다각적인 답을 만든다.
• 기획 당시 막 주목받기 시작한 에이전트 간 오케스트레이션을 먼저 직접 구현해 본다.

제약

• 추론 서버는 Mac mini M4 16GB 한 대. 7~8B 모델 여러 개를 이 안에서 돌려야 했습니다.
• 기간 1년, 4명. 모델 학습과 서비스 구현을 모두 이 안에서 끝내야 했습니다.

설계 과제

• 에이전트들이 끝없이 대화를 이어가지 않고 항상 끝나야 한다.
• 한정된 메모리에서 여러 모델이 충돌 없이 답해야 한다.
• 프론트 → 오케스트레이션 → 모델 → DB로 이어지는 데이터 흐름이 일관되어야 한다.

Project 03 · TeamTalk

LLM 응답 5분 → 3분, 약 40% 단축

문제

• 질문 하나에 응답이 5분 이상 걸려 서비스로 쓰기 어려운 상태였습니다.

원인

• 메모리 초과: 여러 모델을 동시에 메모리에 올려 두자 16GB를 넘었고, 부족분을 SSD로 스와핑하면서 전체가 급격히 느려졌습니다.
• 자원 경쟁: 여러 모델이 동시에 추론하며 CPU·메모리를 두고 경쟁해, 동시 처리가 오히려 지연을 키웠습니다.

조치

• 지연 로드(lazy load): 모든 모델을 상주시키지 않고 차례가 온 모델만 메모리에 올려 스와핑을 없앴습니다. 첫 호출의 로딩 지연은 감수했습니다.
• 직렬 큐: n8n 워크플로우 안에 큐를 구현해 요청을 하나씩 순서대로 처리했습니다. 각 추론이 자원을 온전히 쓰게 되어 처리 시간도 예측 가능해졌습니다.

한계

• 요청이 몰려 큐가 길어지면 대기 시간이 쌓입니다. 근본 해결은 수평 확장과 추론 서버 분리이고, 이 한계를 체감한 것이 클라우드로 관심을 옮긴 직접적인 계기였습니다.

응답 시간 (기존 5분+)

3분

응답 시간 단축

−40%

Project 03 · TeamTalk

팀장으로서 내린 결정 — 전체 학습 대신 LoRA

상황

• 처음에는 세 역할 모델을 모두 전체 파인튜닝할 계획이었지만, 기간과 컴퓨팅 자원으로는 끝낼 수 없다고 판단했습니다.

결정

• LoRA로 역할만 분리 학습하는 수준으로 범위를 줄였습니다. 학습은 별도 NVIDIA GPU에서 진행했습니다.
• 이상적인 설계를 붙잡고 미완성으로 끝나기보다, 가진 자원 안에서 끝까지 결과를 내는 쪽을 택했습니다.

측정 결과

• 베이스 모델 대비 지표 변화는 대부분 1% 미만으로, 뚜렷한 품질 개선은 없었습니다.
• 오히려 같은 단어를 반복하는 경향이 나타났습니다. 학습 데이터와 학습 횟수가 부족해 생긴 과적합 징후로 분석했습니다.

이후 조치

• 모델 성능을 억지로 끌어올리는 대신, 프로젝트의 핵심을 오케스트레이션 구조와 추론 인프라로 다시 잡고 거기에 남은 시간을 썼습니다.
• LoRA 결과는 숨기지 않고 한계와 원인, 개선 방향(데이터 양·다양성 확보, 학습 스텝 조정, 반복 억제 파라미터) 까지 결과 정리에 담았습니다.
• 그 결과 서비스를 끝까지 완성해 메타버스SW아카데미 최우수상을 받았고, 기획·아키텍처·결과 정리가 논문 1편에 반영되어 공저자로 등재됐습니다.

Project 04 · 지존소프트 인턴

NAS 위에 스타트업의 사내 인프라를 새로 세우다

LLM + 컴퓨터 비전으로 고객마다 다른 견적서를 하나의 양식으로 정리하고 품목을 매칭하는 물류 IT 스타트업입니다. 개발부 인턴으로 Synology NAS(DSM) 위에 인프라를 직접 구축·운영했습니다.

기간

2025.09 – 2025.10

역할

개발부 인턴 · 인프라 구축 담당

구축

메일 서버(SMTP) · Supabase 구축과 데이터 수집·관리 · 웹 서비스 배포

구조

DSM 역방향 프록시(도메인 ↔ 서비스, CNAME) → 컨테이너 Nginx(세부 라우팅) 2단 구조

보조

회사 홈페이지 프론트, 견적서 처리 n8n 워크플로우 이슈 대응, 결제 백엔드 설계·테스트

스택

Synology DSM · Docker · Nginx · Supabase(PostgreSQL) · n8n

Project 04 · 지존소프트 인턴

504 장애 ① — 레이어를 하나씩 격리해 원인 찾기

상황

• 베타 서비스 운영 중, 어느 날부터 웹훅 POST 요청이 전부 504 Gateway Timeout 으로 실패했습니다.
• 직전에 있었던 변경은 백엔드 서버(n8n을 서빙하는 Mac Studio)의 물리적 위치 이전 하나였습니다. 옮기면서 서버 IP가 바뀌었습니다.

Nginx는 proxy_pass에 도메인을 적으면 시작할 때 DNS를 한 번만 해석해 IP를 고정한다.
서버 IP가 바뀌어도 재시작 전까지 옛 IP를 계속 쓴다. curl은 매번 새로 해석하기 때문에 성공했다.

Project 04 · 지존소프트 인턴

504 장애 ② — 임시 복구에서 끝내지 않기

즉시 조치

• Nginx 컨테이너를 재시작해 새 IP를 다시 해석하게 하여 서비스를 즉시 복구했습니다.

재발 방지

• 재시작은 다음에 IP가 바뀌면 똑같이 터지는 임시방편이라, Nginx resolver + 변수 기반 proxy_pass 로 바꿔 10초마다 도메인을 다시 해석하도록 했습니다.
• 주기적인 DNS 조회 비용이 조금 생기지만, 서버 위치가 바뀔 수 있는 환경에서는 안정성이 더 중요하다고 판단했습니다.

결과

• 업스트림 IP가 바뀌어도 사람 개입 없이 자동 반영되고, 이후 같은 원인의 장애 0건.
• 원인과 조치를 문서로 정리해 사내에 공유했습니다.

# 변경 전: 시작 시 1회 해석 후 고정
proxy_pass http://n8n.example.com;

# 변경 후: 변수로 넘기면 요청 시점에 resolver로 재해석
resolver <DNS 서버> valid=10s;
set $n8n_upstream http://n8n.example.com;
proxy_pass $n8n_upstream;

Project 05 · 홈서버 운영

ARM → x86, 서비스 이전 (당시 컨테이너 19개)

목표

• Mac mini에서 돌던 서비스(프록시·웹사이트·Supabase·웹앱·게임 서버)를 데이터 손실 없이 새 서버로 옮긴다.

과정

• 이미지는 옮기지 않고 새로 빌드: arm64 → amd64라 소스와 설정만 옮기고 새 서버에서 다시 빌드했습니다.
• DB는 물리 볼륨으로 복원: 데이터 폴더의 PG_VERSION(17)이 새 이미지와 같은지 먼저 확인한 뒤 붙였고, Supabase 컨테이너 11개가 모두 healthy로 올라왔습니다.
• DNS를 바꾸기 전에 검증: curl --resolve 로 도메인 요청을 새 서버로 강제로 보내 웹 4개(200)·API(401, 정상)를 확인했습니다.
• 컷오버는 포트포워딩만: 공인 IP가 같아 DNS는 그대로 두고 공유기 포워딩 대상만 바꿨습니다. 쓰지 않는 22(SSH)·5900(VNC) 포워딩은 이때 닫았습니다.

문제

• 컷오버 후 TLS 에러. 로그를 보니 인증서 자동 발급이 컷오버 전에 옛 서버로 가서 실패했고, 도구는 1시간 재시도 대기 상태였습니다. 재시작으로 5개 도메인 인증서를 1~2분 만에 발급했습니다.

마무리

• 옛 서버를 지우기 전, 이사 짐(스냅샷) 이후 옛 서버에 새로 쌓인 데이터가 없는지 확인했습니다.
• 재부팅 후 Docker·컨테이너·Tailscale·Samba·디스크 마운트가 자동으로 복구되는지 검증했습니다.

Project 05 · 홈서버 운영

이전 후 게임 서버 접속 불가 — 범인은 저장된 옛 주소

상황

• 이전 후 3시간 플레이하고 옛 서버를 껐는데, 정전 재부팅 뒤 접속 타임아웃. IP를 직접 치면 접속되지만 3시간 기록이 없었습니다.

게임 클라이언트의 서버 목록에 "이름"은 도메인, "주소"는 옛 서버의 내부 IP로 저장돼 있었다.
→ 3시간 동안 사실은 옛 서버에서 플레이했고, 옛 서버를 끄자 연결이 끊긴 것.
→ 주소를 새 서버로 수정. 집 안에서는 공유기가 NAT 루프백을 지원하지 않아 내부 IP를, 밖에서는 도메인을 쓰도록 정리.

Project 05 · 홈서버 운영

서버 보안 강화 — 비밀번호 하나로 전부 뚫리는 구조를 끊다

문제

• NAS(SMB) 비밀번호가 리눅스 계정 비밀번호와 동일했고, SSH는 비밀번호 로그인이 열려 있었습니다. SMB가 뚫리면 SSH로 서버 전체가 뚫리는 구조였고, 로그인 실패를 막는 장치도 없었습니다.

조치

• ① SSH 키 인증 강제 (가장 치명적인 경로부터) ② fail2ban 으로 SSH·SMB 브루트포스 자동 차단 ③ SMB 암호화 강제.

실수와 복구

• authorized_keys 에 키가 있는 걸 보고 키 인증을 켰는데, 그 키는 CI 배포용 키였고 제 개인 키가 아니었습니다. 세션이 끊기면 잠기는 상황이라 즉시 롤백 → 개인 키 생성·등록 → 새 터미널에서 로그인 확인 → 재적용했습니다.

디버깅

• fail2ban에 SMB 필터가 없어 직접 작성. Samba 인증 감사 로그를 켜고 실제 실패 로그로 정규식을 맞췄습니다.
• 그래도 매칭이 안 돼 fail2ban 소스 코드를 읽어, 날짜 부분을 잘라낸 뒤 매칭한다는 내부 동작을 확인하고 정규식을 고쳤습니다. 실제 로그인 실패를 만들어 끝까지 검증했습니다.

Project 05 · 홈서버 운영

모니터링 도구가 CPU를 먹고 있었다 — dockerd 64% → 1%

증상

• GPU는 쉬는데 팬 소음이 컸습니다. dockerd 와 containerd 가 각각 CPU 60%대 를 24시간 쓰고 있었습니다.

진단

• 추측하지 않고 두 단계로 좁혔습니다. ① Netdata를 잠시 멈추고 CPU 변화를 측정 → ② Netdata 안의 docker 수집기만 끄고 재측정.
• 원인: docker 수집기가 1초마다 컨테이너 28개를 하나씩 조회하며 Docker 데몬에 요청을 계속 밀어 넣고 있었습니다.

조치

• docker 수집기만 끄고, 설정 파일을 볼륨이 아닌 서비스 폴더에 고정해 재생성해도 설정이 유지되게 했습니다.
• 잃는 것도 확인: 컨테이너별 차트 700개는 cgroup에서 직접 읽어 그대로 유지, 사라진 요약 차트는 Portainer로 대체.

Project 05 · 홈서버 운영

GPU 하나를 여러 서비스가 나눠 쓰기

문제

• 로컬 LLM(Ollama)과 이미지 생성(ComfyUI)이 GPU 메모리를 격리 없이 공유했습니다. 번갈아 쓰면 한쪽이 메모리를 반납하기 전에 다른 쪽이 올라와 경합으로 수십 배 느려질 수 있었습니다.

측정

• "반납 타이머를 0으로 하면 매번 다시 로드해야 해서 손해"라는 가정을 직접 재 봤습니다. 재로딩 비용은 ComfyUI 약 8초, Ollama 약 10초로 작았습니다.
• 예전에 기록한 "Ollama 로드 44초"는 경합 상태에서 잰 잘못된 값이었음을 발견하고 정정했습니다.

조치

• 두 서비스 모두 작업이 끝나면 즉시 GPU 메모리를 반납하도록 변경 → 경합 위험 제거, 대신 매번 8~10초 로딩은 감수.
• eGPU는 평소 떼어 두기 위해 재부팅 없는 분리/연결 스크립트 를 만들었습니다. 서비스 정지 → 잔여 프로세스 확인 → 드라이버를 의존성 역순으로 해제 → 장치 제거 순서를 지키고, 드라이버 해제에 실패하면 장치를 건드리지 않고 중단합니다.
• 다시 연결할 때는 전체 PCI 재검색 대신 해당 포트만 재검색해 NVMe·랜카드 등 다른 장치에 영향을 주지 않게 했습니다.