| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 |
- Spring
- SRE
- kotlin
- aws
- Kubernetes
- tucker의 go 언어 프로그래밍
- HARNESS
- LLM
- Claude
- golang
- AI
- 바이브코딩
- PETERICA
- go
- MySQL
- 오블완
- CKA
- Rag
- CKA 기출문제
- minikube
- AWS EKS
- 기록으로 실력을 쌓자
- 코틀린 코루틴의 정석
- 티스토리챌린지
- CloudWatch
- docker
- kotlin coroutine
- 정보처리기사 실기 기출문제
- Java
- 공부
- Today
- Total
피터의 개발이야기
AI를 잘 운영하는 개발자로 성장하기 본문
Backend + SRE 엔지니어가 AI 시스템의 운영 문제를 해결하는 과정
ㅁ 들어가며
요즘 모든 팀이 AI를 도입한다.
ChatGPT API를 붙이고, RAG를 만들고, Agent를 설계한다.
그런데 한 가지 빠져 있다.
"그걸 어떻게 운영할 건데?"
나는 Backend와 SRE를 해온 엔지니어다.
서비스를 만드는 것보다 돌아가게 만드는 것이 얼마나 어려운지 안다.
AI 시스템도 마찬가지다.
이 글은 내가 AI 시스템의 운영 문제를 어떻게 이해하고,
어떤 방식으로 해결하고 있는지를 정리한 글이다.
ㅁ AI 시스템은 왜 운영이 안 되는가
AI를 도입하면 네 가지 문제가 반복된다.
1. 결과가 매번 다르다
같은 질문을 해도 답이 다르다.
모델을 바꾸면 품질이 바뀐다.
프롬프트 한 줄이 달라지면 결과가 완전히 달라진다.
기존 소프트웨어에서는 있을 수 없는 일이다.
하지만 AI 시스템에서는 이것이 기본 상태다.
2. 틀려도 나아지지 않는다
RAG 시스템이 틀린 답을 했다.
사용자가 떠났다.
그리고 다음 날, 같은 질문에 같은 틀린 답을 한다.
실패가 수집되지 않고, 피드백 루프가 없기 때문이다.
시간이 지나도 품질이 그대로다.
3. 사람이 빠지면 멈춘다
검증을 사람이 한다.
판단 기준이 사람 머릿속에만 있다.
그 사람이 휴가를 가면 프로세스가 멈춘다.
AI를 도입했는데, 실행 구조는 여전히 수동이다.
4. 경험이 쌓이지 않는다
AI와 대화한 결과는 어디로 가는가?
대부분 사라진다.
같은 작업을 반복하고, 같은 실수를 반복한다.
경험이 시스템 자산이 되지 않는다.
ㅁ 나는 이걸 어떻게 풀고 있는가
나는 이 문제들을 Backend + SRE 관점에서 접근한다.
AI를 "도구"가 아니라 "운영해야 할 시스템"으로 본다.
비결정성 → 구조로 통제한다
AI 결과가 흔들리는 이유는 단순하다.
선택지가 너무 많기 때문이다.
해결: 입력을 구조화하고, 출력의 범위를 제한한다.
모델이 바뀌어도 결과가 같도록 시스템으로 통제한다.
이것이 Harness Engineering의 핵심이다.
좋은 AI 결과는 모델이 아니라, 설계된 시스템에서 나온다.
→ 관련 글
1. 개발자가 직접 만드는 Agent Harness
2. AI를 잘 쓰는 게 아니라, AI를 통제해야 한다
3. AI를 다루는 방법의 진화 (Prompt → Context → Harness → AIOps)
4. 하네스는 시스템을 설계하는 일이다
ㅁ 운영 부재 → 실패를 개선 루프로 연결한다
RAG 시스템이 틀린 답을 했으면,
그 실패는 다음 개선의 트리거가 되어야 한다.
나는 이런 구조를 설계했다:
질문 → 응답 → 실패 감지 → 지식 개선 → 재인덱싱 → 품질 향상
응답(rag-chat), 관찰(rag-monitor), 지식관리(rag-kms)를 분리하여
시간이 지날수록 품질이 좋아지는 RAG 시스템을 설계했다.
→ (구현 완료 후 링크 추가 예정)
ㅁ 자동화 부재 → Agent + Policy Gate
반복 검증을 사람이 하지 않아도 되는 구조.
Agent가 역할별로 분리되고, Policy Gate를 통과해야만 결과가 확정된다.
Evidence 없는 판단은 금지.
자동 확정도 금지.
구조가 판단하고, 사람은 검토한다.
ㅁ 지식 소멸 → 구조 기반 축적
AI와의 대화 결과가 사라지지 않도록,
컨텍스트를 파일 단위로 분리하고 구조화한다.
자유 텍스트가 아니라 섹션 기반 구조를 강제하여
누가 봐도 이해할 수 있는 형태로 지식을 축적한다.
→ (Context Note 완성 후 링크 추가 예정)
ㅁ 경력 경로: 왜 내가 이 문제를 푸는가
Backend Engineer (서비스 구조)
↓
DevOps (자동화, 파이프라인)
↓
SRE (안정성, 관측성, 장애 대응)
↓
AI Native Engineer (AI 시스템 설계 + 운영)
각 단계에서 배운 것이 다음 단계의 기반이 됐다.
- Backend에서 서비스 구조 설계를 배웠다
- DevOps에서 자동화와 파이프라인을 배웠다
- SRE에서 안정성과 관측성을 배웠다
그리고 지금, 이 모든 경험이 AI 시스템을 운영 가능하게 만드는 문제로 수렴되고 있다.
ㅁ 프로젝트
| 프로젝트 | 해결하는 문제 | 상태 |
| LLM System Lab | AI를 시스템으로 이해하기 | 완료, git, vercel |
| Harness Engineering | AI 출력의 비결정성 통제 | 블로그 발행 완료 |
| RAG Platform | 실패해도 개선되지 않는 RAG | 설계 완료, 구현 중 → 구현 완료 (모니터링 + 지식 개선 루프) |
| ContextChat | RAG를 서비스로 제공하기 | 구현 완료 (멀티테넌트 + Citation 검증) |
| IntentFlow | LLM 의존 최소화 + 파이프라인 통제 | 구현 완료 (의도 정확도 87%), git |
| Context Note | 지식이 축적되지 않는 문제 | 구현 완료 (구조 기반 위키), tistory, git |
ㅁ 마치며
AI를 잘 쓰는 시대는 이미 왔다.
다음은 AI를 잘 운영하는 시대다.
나는 그 문제를 풀고 있다.
이 글은 프로젝트가 완성될 때마다 업데이트됩니다.
마지막 업데이트: 2026-04-05
'AI' 카테고리의 다른 글
| SSH에서 쿠버네티스로 — 하네스 엔지니어링이란 무엇인가 (0) | 2026.04.10 |
|---|---|
| [AI] Autoresearch 기반 지식 진화 시스템 정리 (0) | 2026.04.09 |
| [AI] 나는 아직도 배우는 중이다 (1) | 2026.03.12 |
| [AI] LLM 양자화 완전 정리: GPTQ / AWQ / GGUF / BNB 차이 + 비트 수와 메모리 관계 (1) | 2025.12.11 |