(2024.12.09 - 2025.08.31) 첫 직장 회고 - 2

현재 진행 중인 작업이다. 14-nodes로 확장하고 고생을 좀 했다..

 스크립트 돌릴 때는 항상 시간이 빈다. 인프라 구축은 terraform/ansible 기반의 IaC로 구성해서 aws 콘솔을 돌아다니며 설정할 필요는 없지만 그래도 여전히 구축에는 시간 낭비가 심한 건 사실이다.
클러스터 구조는 4-nodes -> 8-nodes(sync) -> 14-nodes (async, MQ)로 매번 바꿔가며 시도 중이다.
 

AWS에 EC2 vCPU limit 증가는 요청한 상태다. 친절한 답변은 받았으나 아직 vCPU limit이 증설되진 않았다.

 
14-nodes의 경우 1 노드당 vCPU 2개를 할당받아 총 28개의 vCPU가 필요하지만..
현재 내 계정의 ec2 vCPU 점유한도가 16개인 관계로 14-nodes로 확장하려면 7개의 인스턴스를 도쿄 리전으로 보내야 한다.
그러기엔 복잡도가 끝도 없이 올라갈 듯싶어 8-nodes 동기식으로 진행 중이다. 이럴 때면 mdcap 몇 줄이면 VM 턱턱 내주던 전직장이 그립다. 아무튼 각설하고 terraform/ansible이 인프라를 만들어 주는 동안 이전 회고나 이어서 작성하겠다.
 

 
지금의 미약한 역량을 만들어 주느라 고생해 준 VM들이다. 사내 VPN이 없으면 접근조차 안되기에 제공된 맥북을 몸에 지니고 다녔다.
보통 개발용 클러스터를 구축할 땐 3개의 노드로 진행했다. (1 xMaster + 2 xWorker)
저 소규모 클러스터에서 작성한 코드가 반영돼 운용되는 클러스터의 규모는.. 짐작이 안된다.
라쿠텐 심포니 CNP(Cloud Native Platform)에서 돌아가는 1&1과 라쿠텐 모바일의 총사용자가 2천만이니 아마 꽤 클 거다.
자세한 수치는 QA 팀에서 알지 않을까 싶다. 도쿄의 QA 썰로는 제품도 방대한데 매번 전화받고 안내하느라 바빴다고 한다.
감당 가능한 IO 용량 자체가 PB 단위임에도 안정성이 매우 x100 중요한 프로덕션이었다.
 
그래서인지 Git으로 merge를 올리기 전까지 리뷰가 꼼꼼하다. 사실 프로덕션이라면 웬만해선 다 그럴 거다.
첫 프로덕션이었던 로빈에선 버디였던 Santosh와 1-2시간 화상 미팅 및 개발을 진행했다.
로빈에서 주로 했던 건 스냅샷 lock 지점 병목과 Control Plane <-> Data Plane 간 상태값을 주고받는 RPC 개발이었다.
멋모르고 git을 올릴 때 worktree 없이 두 브랜치에서 병행 작업을 하다가 변경 사항이 섞인 채로 git commit이 나간 적이 있다.
버디 왈로는 '이렇게 브랜치가 꼬이면 코드 리뷰가 힘들다.'며 꼭 diff를 찍는 습관을 기르라 하셨다. 개발하고, 미팅하고, 피드백받고.. 그래도 사내 어학비는 반드시 챙겨야 한다는 마음으로 주 1회 원어민 미팅(잡담) 받고.. 그렇게 정신없이 3개월 정도를 보냈다.
 
 

 
이때 밤도 꽤 세고 그랬다. 엘든링도 병행할 때라..
원칙상 9to6+주2회 재택이라도 신입 입장에선 회사에 앉아있는 시간으론 그 정보량이 커버가 안된다.
리모트로 버디가 붙었다곤 하나 프로덕션이 어지간히 어려웠던 게 아니었다.
K8s에 떠있는 로우레벨(C) 스토리지 서버를 건드리는 건 진짜 머리털이 빠지는 작업이다.
커널 단에 가까워서 시스템콜 코드가 많은 것도 스트레스지만 전 포스팅에도 말했듯 lock이 진짜 문제다..
괜히 헤드님이 Proactor와 IO_Uring에 눈독을 들이시던 게 아니었다. 그런데 그거 다 전환하는 것도 쉽지 않을 거다.. 
그래서 그런지 인도계 엘리트 분들의 머리숱이 그렇게 많진 않다. 다행인 점은 난 아직까진 풍성하다는 거다.

수습기간동안 작성했던 업무 성취도 평가. 영문과 일본식 규격이 섞인 카오스다.

 
당시 Artifactory에 올라간 도커 이미지 및 스크립트로 K8s 클러스터를 구축할 수 있어서 사용은 꽤 간편했다.
환경을 갖춘 뒤 내부 스토리지 서버 소스를 고치거나 개발, TC 만들고, 커밋하고, diff 찍고, 테스트하고, 리뷰받고.. 의 반복이었다.
참 좋은 경험이지만 재취준생이 된 입장에선 답답한 면도 있다.
학부 전공 4년, 카부캠에서 각종 사이드 프젝 뛰고, 영어하고, 외국계 클라우드 개발 실무를 9개월 뛰어도 3학년 시절보다 낮은 서합률이라는게 납득이 안 가는 상황이다.. 그래도 다 도움이 될 거라 믿는다.

 
그러다 3개월 후 Santosh로부터 Rakuten OStore라고 Object Storage 개발팀이 있는데 거기로 가봐라는 말을 들었다.
Robin은 아무래도 성숙한 프로젝트다 보니 신입이 만지기엔 고리타분할 수 있다는 말을 붙이셨다.
참 이런 걸 보면 인도계 분들은 퍼포먼스 리뷰에선 가감이 없지만 대외적인 소통 면에서 상당히 친절하다.
취준생 시절 EC2, Docker, GitHub Actions, Spring, Sync로 배포/개발하던 입장으로선 GitOps, K8s + Istio, Reactor 패턴인 로빈도 스택 면으로 하이엔드여서 더 있고 싶었지만.. Santosh와 US 팀장님의 말로 보았을 때 '여기선 퍼포먼스가 안나오니 맞는 팀을 찾아준다.'는 느낌이 강했다. 그렇게 Rakuten OStore로 이동했다.

 
OStore 팀은 확실히 Robin과 개발 방식이 다르긴 했다. 유지보수가 중심이던 로빈에 비해 신제품 개발팀인 OStore는 담당 피처별 ETA 관리부터 팀 전체 미팅까지 꽤 타이트했고 개발 강도도 높았다. 주 2-3회 줌미팅으로 US 헤드님과 VP님이 참관하셨다. Rakuten Symphony Storage에서 22명의 인원이 차출되어 개발하던 제품으로 이미 1년 정도 개발이 진행되고 있던 상황이었다.
Rakuten 사내에서 사용되는 MinIO와 S3를 대체하는 것이 1차 목표, 구글 등의 엔터프라이즈 고객에게 제공하는 것이 2차 목표였다.
제품은 7월에 출시했고, 향후 행방은 모른다. 아마 S3 비용을 줄이고자 Rakuten 제품 몇몇 곳에서 쓸 듯싶다.

 
Rakuten Ostore는 오픈소스였던 MinIO를 타겟으로 한 제품이다. MinIO와 다른 점은 버킷 격리가 논리적인 분리가 아닌 실제 물리 DB의 격리로 이뤄져 있다는 점이다. 한 버킷이 다운되더라도 그 영향이 다른 버킷까지 퍼지지 않는 점은 매우 좋지만 분산된 지역별 버킷의 정보를 단일 DB에 메타데이터로 담다 보니 이를 관리하는 과정에서 어려움이 발생한다.

다수의 DB의 메타데이터를 단일 DB에 기록하려면 중간에 작업을 통합 관리하는 큐를 둬서 RW의 순서를 잡아 주는 게 아무래도 용이하다.
OStore에선 WAL 테이블을 큐로 활용해 DB 레이어와 서버 레이어 간 추상화를 시도했다.
WAL + 별도 큐를 함께 운용해 이중 영속화를 시도하는 Robin의 경량화 버전이라고 이해했다. (OStore와 Robin은 모노레포로 구성됐다.)
이건 현재 진행 중인 사이드 프로젝트에도 도입해 볼 예정이니 그때 만들면서 살펴보자.
내가 맡은 부분은 GW의 Install-time 로직이었다. MinIO 제품을 만져보던 중, 루트 계정이 단일 생성되고 메모리에 보관되는 걸 확인했다. 간단한 작업일 듯싶었지만 구조가 구조인지라.. 분산된 GW 모두 동일한 루트 계정 정보를 가져야 했기에 각 GW의 캐시마다 값을 주입할 필요가 있었다. 이외에도 DB에 저장되는 값과 노출되는 값은 분리해야 하는 둥 요구사항이 꽤 됐기에 난항을 겪었다.
로직 디자인은 버디인 Ishika의 지도 아래 진행했다. 발생할 수 있는 가짓수를 나누며 Confluence에 기록했다.
로직 디자인을 기반으로 승인이 나면 그때부터 구현, TC 제작, 커밋, PR로 이어진다.
구현 당시엔 Mandar라는 OStore 개발 리드님께 리뷰도 많이 받고 그랬다. 정말 열정적인 팀장님이시다.
이분은 잠을 거의 안 주무시는 거 같다. 나보곤 일찍 자라고 하시면서.. 암튼 좋은 분이시다.
저 Install-time 로직 개발 ETA를 썩 잘 맞추진 못한 터라 K8s 네트워크 CNI 개발팀으로 이동됐다.

네트워크 팀 얘기는 다음 장에서 풀겠다.
 

 
현업 개발 당시엔 AI를 정말 공격적으로 사용했다.
라쿠텐은 AI 사용을 권장하는 스탠스다. 자체 AI를 보유하고 있고 OpenAI, Anthropic 등 각종 AI 엔터프라이즈 계약을 맺었다.
미키상은 신사업에 한해서 돈으로 푸는 스타일이다. 클라우드(심포니), 통신사, 메신저, AI 등을 인수합병으로 흡수한 걸로 안다.
재직원 임금은..좀 짜다. 일본 내에서도 서비스 체급 대비 임금이 낮은 편인지 아사카이에서 관련 내용을 심심찮게 언급하곤 했다.
아사카이는 모두 영어로 진행한다. 외국인 인력이 많기도 하지만 일본인 인력 분들도 영어를 잘하신다.
도쿄 방문 당시, 팀 미팅 때 30대-50대 페어를 맞춘 재무팀 분들과 RS Cloud VP님이 임금 관련 얘기를 하곤 했다.
VP님께서 'US 쪽 인플레가 심해서 리서쳐 임금을 올려야 합니다.'라고 운을 띄우면 재무 쪽에서 '고민해 보겠다.' 식의 대화흐름이었다.  
한국지사에도 일본 분들이 계시지만 그분들은 보통 한국어-일본어로 소통을 하셔서 영어 숙련도가 어떤지는 잘 모른다. 난 한국어와 영어만 가능하다. 일본어는 전혀 모른다.
 

 
물론 그때는 공격적이라고 해봐야 사내 AI 및 GPT Pro에 복붙하기가 끝이어서..
지금처럼 홀몸인 상태로 Cursor + Claude로 IaC부터 API 서버까지 쭉 뽑는 상황과는 많이 다르긴 하다.
이제 구축+허물기 반복 작업에 들어갈 시간이다. 프로젝트 진행 상황 및 회고는 별도의 장에 기록해 두겠다. 잘됐으면 좋겠다.