튜닝하다 진이 빠진 채로 잡담

 
 
이제 어느덧 이코에코가 어엿한 클라우드 네이티브라고 부를 수 있을만큼 성장했다.
작성일 기준으로 Observability가 grafana, prometheus 밖에 없는 게 아쉽지만..
분산 백엔드 / 인프라를 이만큼까지 직접 구축해 본 사람도 드문 걸 알기에 나름의 자부심이 있다.
물론 틈틈이 구축한 분도 많겠지만..  GitOps, K8s, 좀 심하다 싶으면 노드별 분리까지 하는 분들을 간간히 보긴 했다.
그렇지만 Istio에, 성능 높인다고 Go 서버까지 따로 개발한 분은 아마 잘 없을 거다. 역시 문제는 '이게 얼마나 잘 어필이 되느냐'다..
스트레스 테스트와 고도화를 진행하며 성능 지표를 추출할 최소한의 Observability와 프로세스는 만들어뒀으니 내보일 건 많을 수 있겠다..만 서류 통과가 최대 난관이다.. '정말 개발자로서 최단기 영업 종료를 당하는 거 아닌가' 싶을만큼 위기감이 강하다.
 
솔직히.. 매번 입에 달고 살지만 라쿠텐 정규직 개발에(경력이 짧긴 하다.), 전공에(학점은 엉망이다. 학교는 낫뱃이다.), 프로젝트에도 투자를 많이 했으면 많이 했지 덜한 편은 NEVER, EVER 물구나무를 서서 봐도 아니고..
개발 공모전 수상에, 영어까지 가능함에도(혹시 몰라 딴 정처기까지..) 이런 찬밥은 좀 양심이 없어도 너무 없다는 생각을 한다.
물론 뽑힌다고 잘할 자신이 있는 건 아니지만 말이다. 하하.
LLM 파이프라인 래핑에, 배포 파이프라인에, 클러스터 구축에, 도메인별 분리에, gRPC 마이그레이션에, 딥다이브에, 성능 튜닝에, 바이브코딩까지 신명나게 해놓고도 자신이 없다. 그만큼 사이드 프로젝트, 특히 바이브코딩은 인정받기 어렵다는 걸 알아서 그런지도 모르겠다.
이코에코에서 한 작업이 '바이브'코딩인지도 사실 잘 모르겠다. 직장에서보다 더 SWE처럼 살았다고 생각해서.. 나름 체계적으로 풀어온 듯 싶다. 이제 이걸 잘 소화하는 건 또 다른 얘기겠다. 나한테야 개인 실험실 겸 훈련장이 생긴 거기도 하니 금전적으로 유지만 할 수 있다면 유리한 고지기도 하다.

물론 손코딩이 점점 사양산업화되는 인상이고 그만큼 문은 닫힌 상황이라 여러모로 답이 없다.이건 전직장에 있을 때 정말 강하게 받았다. 오죽하면 토스 면접 때도 '코드 레벨에서 멀어져서 봐보세요'라는 조언을 듣고 탈락하기도 했다.. 그게 더 LLM과 밀접하게, 더 LLM을 쥐어짜며 몰입하게 된 이유기도 하다. 어쩌면 파산의 이유..가 될지도 모르겠다.
 
 

새까맣게 탄 건 내 잔고와 체력이다..

 
지난 47일 간의 LLM과의 개발기를 돌아보면 좀.. 말이 안되는 일정이었다. 그걸 이뤄낸 과정은 순탄치 않았다..
가끔 산책 나갈 때 전직장 동료를 만나면서 클러스터에 대한 한탄을 하곤 한다. 그 친구는 참 그런 한풀이도 잘들어준다.
아무튼 그럴 때마다 '그냥 docker-compose로 올리지 그랬냐. 한국엔 서비스도 그렇게 올리는 곳 많은데'라는 답변이 끝이긴 했다.
사실 어느정도 맞는 말 같긴 하다.. 전직장에서도 CNP/CNS 팀을 제외하면 클러스터를 온전히 다루는 팀은 적긴 했다.
전세계 서버의 70%가 쿠버네티스 클러스터 위에서 동작한다는 건 대체 어디서 나온 지표인지 모르겠다. 아마 서버들의 규모가 커서 그런 것도 있겠다. 최대한 지식을 끌어모으고 LLM과 동거동락하며 Observability, 클러스터 디버깅으로 잡히는 실데이터와 코드만을 제1시민으로 대하면서도 '왜 이걸 하고 있지..'라는 생각이 들 때가 가끔 있긴 했다. 그래도 오래도록 마음의 짐 같았던 구조니.. 해소에 가까운 작업기였다. 클라우드 스토리지를 개발하면서도 '직접 클러스터를 짜본 적도 없는데 이걸 개발하는 게 맞나..?'라는 부채 아닌 부채에 시달리기도 했다.사실 말이 안되긴 한다. 누가 입사하기 전에 클라우드 프로덕션 코드를 짠다고.. 그게 가능했으면 OpenAI가 Azure, AWS, 하다 못해 라쿠텐 모바일이 왜 심포니걸 쓰겠나. 공공기관은 왜 NHN, KT, 네이버를 쓰냐.. 차라리 바이브코딩으로 짜고 말지..

클라우드 개발은 오픈소스와 가까운 듯 싶으면서도 정작 핵심인 플랫폼은 자본과 규모, 노하우로 돌아가는 분야라는 생각도 든다.
그래서 그런지 클러스터 설계하고, 구현하고, 붙어서 한 작업들이 의심의 눈초리를 받을 때마다 참 더럽게 억울하다..
API야 웹 통신의 표준에 가까우니, IT에 관심이 있다면 다뤄본 사람도 많고 익숙하겠지만 
클러스터와 파이프라인, 네트워크 토폴로지는 사내 플랫폼으로 개발/운영되는 경우가 많아서 경험이 없거나 모르는 사람이 보면
'이거 뭐 진짜 설계도만 있고 완전 사기나 스캠 아니야..?'라고 느껴질만큼 직관적으로 알기 힘든 부분이 많다.
양심적으로 해온 일이 그런 대우를 받을 때마다 참 마음이 아프다. 설계도, topology, 배포 파이프라인 등은 실제 클러스터에서 실측 데이터를 수집한 뒤에 공개 소스에 올릴 만큼 보수적으로 작업에 임했다.
그런 억울함이 Observability와 GitOps가 있는 이유기도 하다. 짠 입장에서도 그 둘이 없으면 맹인이나 마찬가지다.
시각화된 실시간 데이터와 코드로 입증이 가능하고, 그걸 근거로 판단을 맡기면 되니 말이다.

개발자라고 예외는 아니지만..사람들은 보통 관측과 검증보다 판단이 앞선다.

그만큼 오판이 넘친다. 판단을 내리는 사람의 역량도 제작자인 내 입장에서 가늠이 가능해진다는 것 또한 장점이다.
그래서 발생하는 노이즈들을 보다보면.. 실데이터를 기반으로 디벨롭이 가능한 LLM에게 손이 더 많이 가는 건 어쩌면 합당하다.
LLM은 정말 딱 Context Window 크기만큼 유용한 거 같다. LLM을 툴로 활용하려면 '적당한' 신뢰와 검증을 병행해야 된다.
(토큰비도.. 필요하다. 웬만하면 Opus 4.5, Gemini 3.0 Pro, GPT 5.1+ 등 작성일 기준 플래그쉽 모델만 사용한다.)

 
API는 좀 박한 대우를 받아도 억울하진 않다. 고도화 전엔 도메인별 분리까지만 적용되고, 기능은 동작만 하는 정도였다. 

현재 8개 도메인 서비스(auth, character, chat, scan, my, location, image, ext-authz)가 Istio 서비스 메시 기반 K8s 클러스터에서 운영 중이며, scan→character, my→character 간 gRPC proto 연동이 구현된 상태다. MQ 기반 이벤트 드리븐 + 도메인별 DB 분리가 정말 코앞으로 다가왔다. 물론 초안에 가까웠던 API도 CI에 린트 테스트(LLM과의 작업에서 린트 테스트는 선택이 아닌 필수다.)를 걸어둔 채로 기본적인 아키텍처(레이어드)와 작성법은 지키며 개발했다.

원래도 헥사고날을 시도해서 무신사에 지원을 해볼만큼 추상화된 아키텍처나 패턴들을 좋아했다. 그렇다고 패턴 혹은 아키텍처들을 자유자재로 다루거나, 잘 아는 건 절대 아니다. 학점이 됐든, 취업이 됐든 로우레벨로 인정을 받던 경우가 더 많아서(현업에선 아니었다. 인도계 분들한테 죄송할 따름이다.) 추상화가 쌓인 코드들 보다는 로우레벨 쪽을 더 많이 다뤘다. 실제로 로우레벨을 쪼끔 더 좋아하기도 하고..
나만 피곤하면 현존하는 가장 빠른 코드를 다룰 수 있는 거니 누구에게나 매력적인 분야라고 생각한다. 약간 모터 스포츠같은 면이 있다.
그게 Go가 됐든, Rust가 됐든, C가 됐든 말이다. 이상하게 C++은 로우레벨이면서도 그다지 빠르거나 가볍다는 인상은 잘 들지 않는다. 비대하게 커진 패키지 때문인지.. 요즘엔 언리얼이나 게임 서버 구현 도구처럼 인식되는 거 같다. (Go도 사실 따지고 보면 CNCF, 클라우드 오픈소스에서 활발하지.. 활용 사례가 한정된 건 진배없다는 생각도 든다.)

 
다 쓰고 보니 속이 좀 후련하다. 사실 별로 할 말은 없긴 했지만 말이다. 요즘 그래도 공채 뜨는 스타텁들이 있어서 희망은 가진다.
물론 다 5년차라고 적혀 있지만.. 9개월차라도 양심없이 질러야하는 판국이다. 시장도 양심이 없으니.. 나정도면 양심을 챙기다 못해 모범 사업자라고 생각한다. for real이다.. 아무튼 Observability 보강하고, 여유되면 MQ까지 붙여서 넣어보자. 좋은 화요일되길 바란다.