로깅 파이프라인 구축 및 Observability 통합을 마치고 잠시 잡담

 
MQ 도입 전 Observability 증강을 마쳤다. 작업 기간이 짧아 무난했다고 생각할 순 있지만..
이틀동안 LLM과 사전 조사, 데이터 분류, 정책 결정, trace.id 전파 방법, 통합 프로토콜 선정 기타 등등으로 소모한 토큰수가 압도적으로 많았다. 그만큼 일 진행이 정말 빨랐기 때문에 첫날하고 둘째날 쯤 시스템 디버깅하면서 로깅 정합성 맞출 땐 두통 오는 거 같더라.
컨텍스트 압축이 잘되어서인지 이번엔 자동으로도 클러스터 디버깅이 잘된 파트가 꽤 됐다.
보통 PR 작성은 작업 내용을 기반으로 LLM이 해주지만 latest 앱 파드의 Rolling Update는 수동으로 개입하는 구성이라서 직접하곤 했는데 이번엔 알아서 잘하더라. (gh cli로 commit[pre-commit hook] ->push->PR 내용 작성까지 터미널에서 다한다.)
편함을 맛보니 merge까지는 양심상 맡기지 않았지만 조금 흔들린다. 라벨과 assignee도 붙여달라니까 알아서 해줘서 거기까지만 하는 중이다. 배포 전략 도입의 우선순위가 계속 미뤄질 핑계거리가 생겼다. 아마 한다면 Canary로 할 듯 싶다. Istio 환경이니 추가 구축 부담은 적다.

 
얼마 전부터 Opus 4.5를 고정으로 작업하면서 토큰 비용이 올라간 것도 있지만 실측 데이터 기반으로 블로그 포스팅 기록도 자동화시키며 거기에 소모된 비용도 많다. (데이터가 쌓이는 만큼 포스팅이 예뻐진다.)
초안 작성과 베스트 프랙티스를 잡아두고 Operator+CR로 실구축과 배포를 한 뒤, 16 nodes 클러스터에서 발생하는 실측 데이터를 기반으로 시스템 디버깅과 문서화 잔버그 수정, 테스트, 다시 구현을 반복했다. 인프라가 고도화될수록 로컬 테스트가 단순 기능 테스트화된다.. 그래서 개발용 소형 클러스터를 따로 줬었나보다.
초안 작성 땐 구글, 넷플릭스, Uber, CNCF, 지식 생산자, 오픈소스의 경우 공식문서만 일급시민으로 두고 나머지 정보는 모두 드랍시켰다. 이코에코 EDA 로드맵은 디벨롭에, 디벨롭, 편집을 거듭한 끝에 단일 파일이 4000자가 넘는다.
블로그에 모두 올리진 않았지만 저 파트에서 토큰이 엄청나게 소모됐다. CDC까지는 기존에 작성해뒀던 문서가 있는지라 빨리 끝나지 않을까라고 생각했는데.. 언급했듯 EDA는 패턴의 러닝커브도 높고 가치판단의 연속이라 LLM과 계속 디벨롭하며 토큰이 빠르게 소진됐다.

Istio Sidecar 덕에 패킷 트레이싱이 마이크로초 단위로 잡힌다.

 
이전에 파두기만 했던 Jaeger와 OpenTelemetry도 본격적으로 정비했다. 성능 테스트 즈음 시도했다가 OpenTelemetry 쪽 버그를 잡지 못해서 우선순위가 미뤄졌었다. 그런데 trace.id 기준으로 LLM과 함께 푸니 깔끔하게 트레이싱이 잘되더라. 개인적으로 만족도가 높았다.
로깅 파이프라인 구축을 진행하면서 분산 트레이싱과 주요 메트릭 대시보드 품질을 올리는게 필요하다고 생각돼서 함께 작업했는데 꽤 만족스러운 결과다. 쿠버네티스, 도커에 붙지 못하는 사람들이 봐도 이코에코 클러스터가 어떻게 구성되어 있고, 실시간으로 어떤 상태인지 인지하게끔 만드는 게 목표였다. 누군가 이코에코를 보면 '모놀리식으로도 충분한 구성이지 않냐' 할 수 있지만.. LLM으로 구현에 드는 품이 극도로 낮아진만큼 분산 아키텍처로 풀더라도 사이드 이펙트는 적을 거라고 생각했다. 실제로 ‘완전히 옳았다.‘라고 보긴 어렵지만 어느정돈 그랬다. 모놀리식 서버는 배포된 기능을 하나 고치기 위해 전체 서버를 갈아야한다. 로직 의존성이 엉킬 위험도 있어서.. 이코에코처럼 문제가 되는 파트별로 파드와 컨테이너를 말기는 쉽지 않았을 거다.

추가 파이프라인 구축 작업이 점점 압축되고, 인프라의 수정, 증강, 개선 사이클이 빨라진 건 GitOps로 기반을 깔아 코드 기반 선언적 관리를 충족시킨 점이 컸다. 현재 LLM이 코딩 퍼포먼스만 편향되게 높은 점에서 시스템 디버깅보다 GitOps로 관리하는 편이 유리할 거라 여겼다. 시스템 디버깅은.. iptables를 떠올리면 연상이 되겠지만 유지보수에 용이한 방식은 아니다. 트러블슈팅과 ArgoCD self-heal을 전제로 한 사전 CR 테스트를 제외하면 웬만해선 코드로만 클러스터 및 서버를 관리한다.
선언적 관리의 경우 Operator 측에서 매번 담당하는 피쳐들을 감시하고 원복시키니, 한 번 정상적으로 돌아가는 상태를 잡아두면 리소스, 부하 등 각종 이슈로 시스템이 다운되더라도 CRD/CR에 명시된 스펙대로 self-heal된다. (ArgoCD server랑 develop에 diff가 하나라도 잡혀서 OutofSync가 나면 수동으로 복구시켜줘야 한다..)
그 Operator들은 단일 앱으로 분류돼서 ArgoCD root-app이 감시하며 상태를 잡아주니 추가 구성이 들어와도 굉장히 탄력적으로 클러스터가 유지된다. 노드별로 격리시켜서 운용한 점도 한 몫한다.

사실 EDA가 난해한만큼 사이드 이펙트(주로 휴먼 이슈다. 감당을 못해서 힘든 경우가 많은 걸로 안다.)가 커서 '포트폴리오로 적합하냐'엔 쉽게 답하지 못하겠다. 양날의 검..을 넘어 오히려 안좋은 인상을 주기 쉽다. (기술부채를 폭증시킨다는 점에서)
그렇지만 기술적인 난이도로 차일피일 미루고 있자니 이미 범용 사례가 많은 구조기도 하고..무엇보다 나온지 꽤 오래 됐다.
EDA까지 아니더라도 큐잉을 붙인 MSA는 쿠버네티스와 함께 왔으니 벌써 10년..?은 넘었을 거다.
쿠버네티스가 구글 사내 시스템이었던 점, MapReduce, Reactor Pattern, Proactor Pattern 등 현대 서버 및 파이프라인의 근원 기술 등장 시점이 1990년 후반에서 2000년대초인 걸 감안하면 실제로 상용화된 시점은 더 오래됐을 수 있다.
차세대라는 이유로 미루기엔 너무 긴 시간이 지났다. '오버 엔지니어링'에 걸려서 한국계 주요 서비스를 제외하면 상용화된 곳이 그리 많지 않은 걸로 안다. 한 때 독일계에 인수되기 전, 배민이 반짝반짝하던 시절 한국에서 유행을 타면서 은근히 많이 도입한 듯 싶긴 하다. 이 시절 3-4학년 혹은 취준생들이 많이 갈렸다. 도커로 깔고 들어가는 분위기도 이 때 잡힌 듯 싶다.
언제나 인상과 실제 데이터는 구분해서 봐야 한다. 데이터상으로 K8s 점유율은 서버 규모로 70%지만 실제로 운용하는 법인 단위의 비율은 그에 한참 못미친다. ‘한국 규모의 트래픽은 PHP로도 감당이 된다.‘라고 하니 맞는 말일 수 있다.
그렇지만 기술부채, 오버 엔지니어링만큼 경계해야 하는 건 '하위 호환성을 챙기기 어려울만큼 시스템이 고이는 일'이라고도 생각을 해서 사이드 프로젝트로나마 hands-on으로 감을 잡고 싶었다.

그시절 EDA에 가졌던 동경을 푸는 일이기도 하지만 '주니어에게 MSA는 과하다.'라는 말에 멈칫해 도커 컴포즈로 컨테이너+NGINX로만 올리다가 Robin 서버 개발에서 정말 많이 헤멘 기억이 있기도 해서.. EDA를 마주치면 그러지 않고 싶었다.
간혹 'SaaS는 PPT대로 안하지 않냐.'라는 곳도 있긴 한 걸로 아는데 인도계들은 "진짜 한다." 
애당초 CNP 서버인데 분산 클러스터를 기술부채를 이유로 미룬다는 건.. 사실상 핑계에 가깝다.
EDA까진 아니었고 Master, Worker로 나뉜 스토리지 클러스터에서 IO Manager를 에이전트로 삼아 ISCSI로 RDVM RW를 컨트롤하는 구조였다. MinIO 카피였던 Rakuten OStore도 크게 다르지 않았던 걸 보면.. Object Storage나 SDS의 구조도 정해진 스테레오 타입이 있나 보다. 스토리지 원격 제어 프로토콜과 기타 락 및 순수 로우레벨 서버라는 점을 제외하면 MSA 플랫폼 범주에서 크게 벗어나지 않는다.그 팀도 자체적으로 K8s-Istio-GitOps 전면 오버홀을 수행한 전적이 있는만큼 기술적인 역량과 욕심은 충분했지만.. 그만큼 관성도 컸다.
Rakuten Ostore의 경우 원본인 MinIO가 Go임에도 C언어를 택해서 동시성 이슈가 많이 터지기도 했고..
이 때 헤드님이랑 인도 개발 팀장님이 기술 토의를 엄청한 걸로 안다. 저녁에 귀가할 때 줌이 켜져있길래 몰래 참석해서 귀동냥한 내용이라 정확하진 않지만(심지어 인도 영어다. 두 분 다 신사적이지만 격앙된 상태였기에 말 속도는 평소의 배수였다.)..
그 파트 ETA는 출시 직전까지 계속 발목을 잡았으니 클라우드 플랫폼 규모의 동시성을 순수 C로 풀기엔 하드한 구간이 존재했나 보다.
Replication이 특히 어렵나 보더라. 내부용으로 우선 사용하니 GA에는 빼자는 의견도 있었다. 난 분산 GW에 인증/인가 로직 버그 픽스하고 로컬 캐시에 계정 잡아주는 Install-time 로직 구현정도가 다여서 별 말 못했다. 그거 하고 CNI 팀으로 갔으니.. 잘하진 못했다.
 

한국에서 진행하는 OpenAI 주최 해커톤이란다. AI SaaS 현업 분들을 대상으로 하는 듯 싶으니 관심있는 분들은 신청하셔라.

 
'Multi-agent로 해커톤하는 시기에 EDA는 좀 한물간 거 아니냐.' 싶은 분들이 계실지도 모르겠다.
Multi-agent를 찾아본 건 아니지만 결국 다중 오케스트레이션이니 클라우드 네이티브에서 크게 벗어난 구조는 아닐 거라고 생각한다.
서버 역할을 하던 게 모델이 되거나, GPT API를 쓰면 툴콜링 혹은 RAG가 되고, 퍼플렉시티나 Cursor처럼 래핑과 UI에 집중한 그런 형태지 않을까..? 짐작만 한다. Agent 툴(Cursor) 헤비 유저로서 할 말은 아니지만.. 소비자 대상으로 하기엔 아직 토큰 비용이 너무 비싸다.
API 콜당 받는 것도 아니고 사용량에 따라 받으니 이거 무슨.. 감당이 안된다. 나야 투자 겸 자아실현 목적으로 쓰더라도 말이다.
아무리 뭐 열심히 디벨롭을 하고 있다곤 하지만 회사 밖을 나온 주니어 입장에선 실시간으로 상한다는 느낌을 지울 수가 없다.. 쌓인 기술부채 푸는 겸 공부도 하면서 쉬엄쉬엄 지원과 병행해도 되지 않을까 싶다.

수상한 이후로 지원을 2-4곳정도 더했지만.. 광탈했다. 고도화에 들어간 이후론 한동안 제출하진 않았으나.. 쩝이다. 파산나기 전에 해야지 뭐 어쩌겠냐. 다음 회사가 LLM을 너무 배척하지 않는 곳이면 좋겠다.

씁..요즘 작업을 하면서도 잘 모르겠다. 이 기세면 정말 세대가 크게 나뉘거나, OpenAI가 아웃되고 구글이 바통을 쭉 이어가거나..
이런 걸 보면 구글 쪽 인력들 역량이 대단한 듯 싶다. 구글 회사의 연혁으로 치면 나랑 비슷한 나이인데 조직과 개인의 발전 속도는 참 하늘과 땅차이다. 보통은 스타텁이 주도권을 잡으면 대기업이 못따라가기 마련이지만 이거도 페북시절 얘기니.. 벌써 15년은 더 지난 거 같다. (라-텐은 산호세 스타텁인 로빈과의 기술역량 차이를 계열사 겸 자회사 형태의 수직계열화로 해결했다.)
OpenAI, LLM이 반짝이다 못해 터질랑말랑한 건 맞지만 하입이 시장의 실수요보다 과도하게 빠른 면도 없지 않아 있다.
ChatGPT는 서비스로 하입을 받았으면서 모델을 통한 SaaS부터 번지는 점도..'지금의 추론시간과 성능으론 일반 소비자에게 임팩트를 주긴 이르다.'는 시장의 합의가 형성된 거라고 생각한다.
사실 따지고 보면 컴퓨터가 등장하던 시점에도 일반 소비자에겐 닿지 않았다. 클라우드도 어느정돈 마찬가지다. 클라우드의 주시장은 플랫폼인데 AWS는 모두에게 열려있음에도 일반 소비자는 아이클라우드 이상 접근하지 않으니 말이다. 그럼에도 CNP 매출은 우주를 뚫는다..
그만큼 유지비용이 크기 때문에 US정도 규모의 경제가 나지 않으면 CNP만으로는 만성적자로 향하는 구조다. 이래서 빅테크들은 답이 없다.. LLM이 ' MAGA로 굳어졌던 고착 상태에서 권태로움을 느낀 사람들이 새로운 주제를 잡고 싶다는 바람에서 하입이 증폭된 게 아닐까.'라는 생각도 한다. 그렇긴 해도 튜링 시스템, 폰 노이만 구조로 컴퓨터가 처음 등장한 시점부터 '인공지능'으로 불리며 발전하다가 인터넷, OS, 스마트폰, SNS를 거쳐 SW가 곧 테크로 동치되는 시점까지 온 거기도 하니..

'인공지능이라고 불리는 LLM이 AGI까지 가지 못해도 비결정론적 컴퓨팅 시스템이 하나 더 생긴 게 아닐까..?'라는 생각도 한다. 학점도 낮은 게 말은 참 많다. 좋아한다고 다 잘하는 건 아니다 하하.