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

24년 11월, 라쿠텐 심포니 코리아 합격 당시 받았던 오퍼레터. 영문이라 멋지다. 페이는 업무 강도 + 영어 소통이 전제인 걸 감안하면 소박하다.

 
 
오랜만에 글을 쓴다. 요즘 산만한 시기기도 하고 다시 마음을 잡자는 의미에서 털고 가야 할 듯싶었다.
24년은 취준, 25년은 상경 + 첫 독립 + 첫 직장 + 첫 연애로 꽤 정신없이 보냈다. 여자친구 만나도 맨날 일 얘기만 하고.. 다니면서도 걱정과 불안이 많았다. 인턴 경험 없이 바로 일본계 정규직 개발로 점프해서 그런지 여러 면에서 부족했다. 현재는 퇴사한 상황이다.

 

일본계 소규모지사 개발직.. 무섭긴 했지만 몇 없는 정규직 개발 오퍼라 일단 들어왔었다. 당시엔 '영어를 실무에서 써볼 수 있다.'는 메리트가 컸다.

개발은 K8s(3 VM nodes - RockyOS: 1xmaster + 2xworker) + GitOps(K8s Operator + Artifactory + Jenkins + Helm-charts) 환경에서 진행됐다.

돌아보면 당시 환경이 좀 특이했다. 분명 라쿠텐 한국지사인데 외관만 보면 신논현에 위치한 중소기업처럼 보였다.
내부는 라쿠텐 매뉴얼에 맞게 인테리어가 돼있었기에 깔끔했지만 뭔가 스타트업스러운 인상이었다. 그리 넓지 않은 오피스에 라쿠텐 심포니, 인사이트, 트래블, 이치방의 한국지사 인력들이 모여있다. 원래는 각 법인이 별도 공간을 사용했지만 본사 측 요청에 따라 심포니가 거점으로 쓰던 오피스에 모여 현재의 모습이 됐다고 한다. 이쯤 되면 라쿠텐 코리아로 병합할 만도 한데 그러진 않고 있다.
라쿠텐 본사 거점인 크림슨 타워도 다수의 계열사가 공유하는 걸 보면 회사 기조인가 보다.
분리된 법인이라기엔 인력이 섞이는 경우도 있어 약간 부서 같은 느낌도 든다. 라쿠텐 모바일 및 심포니 한정일지도 모르겠다.
처음엔 이 지사가 뭘로 돈을 버는지도 짐작이 안 됐다. 그저 본사의 돈인가.. 싶었지만 꼭 그런 건 아니더라.
라쿠텐 심포니 매출($500M/year)의 80%가량이 클라우드 플랫폼 로열티에서 나오고 있었다.
그럼에도 한국지사는 Cloud BU 기반이 전혀 없던 상황이라 '이건 좀 너무한데..?'라는 생각도 들었다.
Cloud BU는 한국지사 한정으로 '신설이니 그렇다.'라고 이해하자. 나도 깡통에 가까운 신입이었으니 쌤쌤이다.
 
암튼 입사 절차는 아래와 같았다. 사전 영어 테스트, 영문 인적성, 2회에 걸친 라이브 코딩 + 면접을 통해 입사했고 서류 접수부터 합격까지는 2개월 정도 걸렸다. 1차 면접은 차후 버디가 될 Santosh, 2차 면접은 US지사 엔지니어 분이 진행했다. 모두 화상으로 진행됐다.
당시가 2024년 10월 즘인 걸로 기억한다. OPIc IH를 막 딴 시점이었지만 실제로 외국인과 회화 경험은 전무했기에 엄청나게 긴장을 했었다. 카카오테크 부트캠프를 이수 중이었는데 해외대 출신 분께 속성으로 1:1 스피치 교정도 받고 그랬다.
돌아보면 참 감사하다. 그분도 바쁘셨을 텐데 면접 전 자신감을 얻는데 도움을 많이 주셨다.
면접은 간단했다. 기초적인 CS 지식 문답 -> resume에 기록한 프로젝트를 설명 -> Cpp 라이브 코딩 순으로 진행했다.
당시만 해도 클라우드에서 로우 레벨을 다루는 이유가 궁금해서 여쭤보기도 했었다.
"링크드 리스트를 생각하면 된다. 스토리지를 병렬로 엮어 구현한 플랫폼이 있다."라는 답변을 받았었다.
실제 마주하고 개발해야 했던 클라우드 스토리지 서버는 그보다 훨씬 복잡했지만.. 굉장히 추상적으로 설명해 주셨던 듯싶다.
 

 
 
첫 취업 이후 1주정도가 지난 시점 헤드님이 한국지사에 방문하셔서 나와 인용님을 두고 상세한 설명을 해주시긴 했다.
RS Cloud의 헤드님은 연세가 만으로 68세정도 되는 인도계 미국인이다. 연세에도 불구하고 총기가 넘치는 분이셨다.
엔지니어 출신으로 Erasure Coding의 추상적인 개념을 비트로 나열하며 설명해 주셨다.
IIT CS 학부를 졸업하고 미국 AI 석사를 마친 직후, 당시엔 AI 관련 수요가 없어서 로우레벨 개발로 시작하셨단다.
한국에는 두 번 방문하셨는데 시간이 나면 화이트 보드를 두고 QKV를 설명해 주시곤 했다.
'열정이 대단하다..'라는 생각이 들면서도 한편으론 저런 분도 커리어가 순탄치 않았으니
"취준은 평생 하는 거다."라는 조언에 무게가 실리기도 했다.

헤드님의 개괄적인 설명이 끝나자 인용님께서 '왜 한국에서 풀타임 개발자를 뽑았냐'를 여쭤보기도 했다. 답변은 굉장히 명확했다.
1. 본사인 도쿄와 동일한 시간대를 공유한다.
2. Junior SWE 시장가가 연 5천만원 정도로 비교적 합리적인 가격대다.
3. 인도계 혹은 제3세계 개발자들은 경력을 쌓고 US로 이동하는 경우가 많다. 그렇지만 한국은 비교적 덜하다.
그러면서 클라우드 BU가 한국지사 한정으로 신설이고, 인원수도 적으나 discourage 하지 말라는 격려도 붙이셨다.
솔직히 설명만 들으면 떨리지 않을 수가 없었는데.. 아무튼 그랬다.
 

 
 
'회사에 대한 믿음이 정말 없었다.' 싶었던 예 중 하나가 페이였다.
취준생 시절에야 뭘 몰랐으니 계약서에 적힌 금액만 보고 '달에 한 400 정도는 들어오겠지'라 생각했다.
그런데 첫 달에 찍힌 실수령이 290인 걸 보고 적잖은 충격을 받았었다.
듣고 보니 12월은 9일부터 시작해서 25일 치를 넣어준 거더라. 25일 입금이었으니 6일은 더 쳐준 거였다..
이후엔 실수령 322로 정상적으로 잘 들어와서 안심하고 그랬었다. (한편으론 포괄이라 슬프기도 했다.)
버디와 면접도 하고, 메일로 날아온 라쿠텐 e-sign에 서명하고, 한국까지 오신 헤드님을 보고도 이리 의심할 정도니..
돌아보면 '회사에 대한 불신이 어마무시하게 깔렸었구나.'라는 생각도 들어 부끄럽다.

그렇지만 조심해서 나쁠 건 없으니, 혹시라도 취준생이라면 네이버 실수령 계산기를 먼저 두드려 보는 걸 추천한다.
취준생 친구들과 얘기를 나누다 보면 핀트가 안 맞는 부분이 직장인 페이다. 적힌 액수가 정말 곧이곧대로 꽂히지 않는다..ㅜ
세금과 4대 보험은 정직하다. 실수령 계산기에 맞지 않는 회사라면 기본조차 지키지 않는 거니 입사를 심사숙고해 볼 필요가 있다.
역량이 부족했던 내 입장에서 할 말이 아니긴 하지만.. 직장인의 역량이 퍼포먼스라면 회사의 역량은 투명한 월급이다.
특히 한국계 SW 개발 직군은 인력 기반 산업임에도 유독 이런 괴담들에 취약하다. base salary + bonus + RSU 체계가 국제 표준이라는 걸 반드시 명심하자. RSU에 대한 언급은 다니던 중 잠깐 나오긴 했다.
RSU를 부여받으면 일정량의 라쿠텐 주식을 0.99불로 행사하는 권리를 제공한다. 부여 여부는 부서 혹은 팀 차원에서 결정된다.
권리 행사 후 매도하면 해외 주식으로 분류돼 수익의 22% 가량이 세금으로 나간다..
라쿠텐 주식을 보면 알겠지만 12-13년에 스파이크가 뛴 이후론 시총 2.03T엔(원화로 약 20조)인 상태로 20년정도 횡보 중이다.
내수 규모를 생각하면 오버밸류는 아니라고 생각되지만.. 암튼 그렇다.

 
입사 이후엔 한국지사 표기 직무는 Cloud Engineer, 팀에선 Jr. Storage Developer Role로 배정받았다.
표기가 좀 헷갈리긴 했지만 클라우드 플랫폼 개발을 맡는 SWE 롤이라고 받아들였다. 
보통은 SWE가 개발자인 게 맞는데.. 한국은 "Developer"의 정체성이 강한 건지 몇몇 업체들은 엔지니어 롤이 좀 특이한 걸로 안다.
이력서 쓸 때마다 머리 아픈 지점이다. 다 구구절절 설명해야 하니..
혹시라도 클라우드 엔지니어 직무를 희망하는 사람이 있다면 JD를 반드시 읽어보길 바란다.
표기상 같은 클라우드 엔지니어일지라도, 클라우드 플랫폼을 개발하는 직무와 이를 활용하는 직무는 다른 직종이라 봐도 무방하다.
전자는 클라우드 BE, 후자는 DevOps에 가깝다고 이해하면 되겠다.
와중에 네트워크(3rd party CNI)와 상단 Orchestration을 개발하는 직무도 하는 일과 필요한 사전 지식이 상당히 다르다.
이렇게까지 세밀하게 운용하려면 산학 연구단이 하나 필요하지 않나 싶다. 현실은 석/학사 엔지니어들이 이리저리 옮겨 다니며 개발하는 상황에 가까웠다. 적어도 라쿠텐 심포니는 그랬다.

담당했던 CNP 스토리지 서버의 구조를 묘사하면 위와 같다.
우선 Control Plane(Storage Manager) <->  Data Plane(RIO / RDVM)으로 디커플링 한다.
Control Plane에서 REST -> Task Queue -> RPC 변환을 거쳐 핸들링을 수행하고
Data Plane 내 Compute node의 RIO에서 IO Flow를 지정, 실제 IO는 Worker node의 RDVM에서 수행한다.
 

/* net.c (Control Plane)*/
s = cpr_time_stat_begin();
count = epoll_wait(rpc->recv_efd, &events[0], RPC_EPOLL_MAX_RECV, -1);
cpr_time_stat_end(&wd->stats, s);
for (i = 0; i < count; i++) {
...
cpr_spin_lock(&rx->lock);
if (conn->state != CONN_CLOSING) {
    rc = epoll_mod(rpc->recv_efd, conn->fd, EPOLLIN);
    if (rc < 0 && errno == ENOENT) { rc = 0; }
    ASSERT(rc == 0);
    rx->epollin_set = 1;
}

--- 

/* devio.c (Data Plane) */
cpr_reader_lock(&SNAP_SLICE(snap)->snaplock);
/* ... bmap_update_entry 등 스냅샷/블록 매핑 업데이트 ... */
cpr_reader_unlock(&snap->slice->snaplock);

 
해당 스토리지 서버의 특이한 점은 Control Plane은 epoll_oneshot을 전제로 한 non-blocking으로 구현됐지만 Data Plane(RDVM)에서 발생하는 IO는 워커 스레드에서 락을 걸며 blocking으로 수행된다는 점이다. Control Plane의 큐 오프로드 기반 오케스트레이션이 Data Plane의 작업 완료까지 보장하지 않는다.
한 번은 fio로 진행한 스냅숏 읽기 테스트에서 RDVM 상태 값이 write lock으로 오 점유되어 Data Plane에서 성능저하가 관측된 적이 있다. 스냅숏 경로의 write lock으로 인해 읽기 동시성이 사라져 Data Plane에서 정지 구간이 발생한 경우다.
버그 픽스 자체는 간단했다. 읽기 작업임에도 write lock으로 점유된 경우를 찾아 read lock으로 변경하니 해결됐다.
그러나 구조적 관점에서 볼 때 스냅숏, 세그먼트, 볼륨 등 논리적인 레이어마다 RW 락이 존재하는 환경에서 단일 락 오용으로 스레드가 멈추는 것은 설계상 취약하다. Data Plane이 동기식 blocking I/O에 의존하는 한, 워커 스레드는 디스크 I/O 완료를 기다리며 블록 되고, 이 시간 동안 락을 보유하면 다른 요청 처리가 불가능하다.
 
https://smileostrich.tistory.com/entry/What-is-IOuring-Inside-IOuring

What is IO_uring? (Inside IO_uring)

 

이런 구조적 병목을 해소하고자 Data plane에 IO_Uring을 적용하는 로드맵이 존재했다.
IO_uring은 디스크 I/O를 커널에 위임하고 서버는 완료 큐만 관리하는 방식으로, 워커 스레드가 I/O 대기 중 블록 되지 않는다.
IO_uring 도입은 Proactor Pattern으로 전환을 목표로 둔 사전 작업이다.
입사 초기에 CTO님께서 가장 먼저 건네주신 자료도 Proactor Pattern 논문이었다. (당혹..)
Reactor Pattern과 Proactor Pattern의 차이를 Cursor의 답변을 통해 간단히 정리하고 넘어가자.

등장 시기
	Reactor: 1990년대 중반에 패턴으로 정식화(Plop/Schmidt 계열). OS의 readiness 다중화(select 80s, kqueue 2000, epoll 2002)와 함께 보편화.
	Proactor: 1990년대 후반에 패턴으로 정식화. Windows의 IOCP(중·후반 90s)가 대표 구현, POSIX AIO는 제한적 확산. 2019년 Linux io_uring 등장으로 재부각.
구조적 차이(동기/비동기 본질)
	트리거 기준
		Reactor: “준비됨(ready)” 알림 → 앱이 I/O 수행
		Proactor: “완료됨(completion)” 알림 → OS가 I/O 수행 완료 통지
	I/O 수행 주체
		Reactor: 앱 스레드가 non-blocking read/write 호출
		Proactor: 커널/OS가 실제 I/O 실행, 앱은 완료 콜백만 처리
	API/디멀티플렉서
		Reactor: select/poll/epoll/kqueue + non-blocking FD
		Proactor: IOCP/POSIX AIO/io_uring 제출(submit) + 완료 큐에서 수거
	핸들러 타입
		Reactor: 이벤트 핸들러(읽기/쓰기 가능) → 이후 직접 I/O
		Proactor: 완료 핸들러(결과/바이트 수, 상태 코드 수신)
	버퍼/수명
		Reactor: 준비 신호 후 앱이 버퍼 할당·I/O 실행
		Proactor: 제출 시 버퍼 고정/등록 → 완료 시점까지 커널이 사용
	에러/재시도
		Reactor: EAGAIN/부분 읽기 처리·재시도 로직 필요
		Proactor: 완료 결과가 최종 상태(성공/실패/바이트 수)
	동시성 모델
		Reactor: 이벤트루프(코어당 1개)+작업 스레드(옵션)
		Proactor: 커널 비동기 실행+완료 큐 소비 스레드 풀
	타이밍/취소
		Reactor: poll 타임아웃 기반
		Proactor: 제출 단위 타임아웃/취소(예: io_uring timeout/cancel) 지원

한 줄 요약: Reactor는 “준비 알림+앱이 직접 I/O(동기적 호출을 비블로킹으로 조합)”, Proactor는 “OS가 I/O 수행+완료 알림(진짜 비동기 완료)”.

 

'스토리지면 스토리지지, 스토리지 서버는 뭐냐?'라는 질문이 생길 법도 하다.
실제 퇴사 직전까지만 해도 옆 부서의 시니어 백엔드 분조차 이게 뭐 하는 서버인지 잘 모르고 계셨다.
ISCSI라는 프로토콜을 사용하면 범용 네트워크 망을 거쳐 원격으로 디스크 IO를 통제할 수 있다.
여기에 Erasure Coding을 적용해 디스크 복구 및 분산 저장 로직을 입히면 실제 물리 디스크처럼 운용할 수 있게 된다.
Erasure Coding도 개념은 다소 복잡하나, 간단히 설명하면 SW 방식으로 구현된 RAID 시스템이다.
RAID는 CS를 공부한 분이라면 얼핏 들었을 개념이다. 하드 디스크에서 패리티 비트를 기반으로 복구 및 분산 저장을 수행하는 그 RAID다.
이 구성을 서버 단위로 확장해 소비자에게 원격으로 스토리지를 제공하는 게 스토리지 서버이며, 클라우드 플랫폼의 원형이다.
설명이 너무 날림이라 여겨질 수도 있지만 양해 부탁한다. 뉴비라 그렇다.

보통 클라우드하면 Ansible, Terraform, AWS, VM 등 오픈소스 혹은 SaaS 제품을 떠올리기 마련이다.
라쿠텐 CNP(Robin Storage)를 포함해 대다수 클라우드 제품의 핵심은 '원격으로 컴퓨팅 리소스를 컨트롤한다.'에서 출발한다.
그 대상이 디스크가 아니라 GPU가 된다면 엔비디아의 CUDA가 된다. 전직 Robin Storage 엔지니어가 어떻게 엔비디아로 이직했는지 유추할 수 있는 부분이다. 아키텍처 및 패턴 외에도 Disaster Recovery, Replication, Snapshot, IO Flow 등 각종 전략들이 친절하게 디자인되어 있었다. 현대적인 프로덕션 아키텍처와 스토리지 서버 전략들을 처음 접한 지라 꽤 신기하기도 했고 학습 난이도가 상당히.. 높았다.
한 달 동안 울면서 머리에 넣으려 했다. 80%의 실패, 20%의 성공..이라고 생각한다. (이 과정에서 인도식 영어 듣기를 익힌 건 덤이다.)

본사인 크림슨타워. 사옥 안에 카페테리아(x2)와 아이스링크장까지 있다.. 옆에 비즈니스 호텔도 붙어 있지만 상당히 비싸다. (저 돈이면 한국지사를..쿨럭)

 
라쿠텐의 CNP는 Robin Storage라는 산호세 발 인도계 스타트업을 인수해서 구축한 제품이다.
Teleco 벤더에서 자유로운 OpenRAN 기반 CNP 모델로 유럽 쪽 학회에 발표, 학회의 신뢰를 바탕으로 독일의 1&1과 라쿠텐 모바일을 고객사로 만들 수 있었다. 라쿠텐 심포니에게 인수된 시점도 이쯤이니 22년이 로빈의 전성기였지 않나 싶다.
이런 걸 보면 기술 기업이 글로벌로 진출하려면 우선 학회부터 공략해야 하나 싶더라.
그러다 23년쯤 독일에서 클라우드 플랫폼발 통신망 장애가 크게 난 이후로 CNP 추가 고객은 잡진 못했지만.. 이건 TMI다.
잠시 설명을 덧붙이면 라쿠텐 모바일은 저가 통신사로 현 라쿠텐 그룹이 집중하고 있는 신사업이다.
라쿠텐 심포니의 모기업으로, Cloud BU에선 두 법인의 인력이 서로 섞여가며 원팀으로 활동한다.
이외에도 라쿠텐의 전신인 이치방(커머스), 뱅크, 페이, 메신저 등 전방위적인 서비스를 제공 중이다.
 
1월에 여행 겸 본사 방문차 도쿄로 갔을 때 라쿠텐 모바일을 포함한 5-6곳의 통신사가 가격 경쟁을 하는 걸 본 기억이 있다.
라쿠텐 모바일은 그중 최저가였다. 통신사로선 후발주자이기도 할뿐더러, 실제 라쿠텐 심포니 Cloud의 매출 대비 담당 인력수를 보면 그럴 만하다.  RS Cloud BU는 전 지사를 합쳐도 200명 남짓이다. 인도, US, JP, SP, 한국 가릴 것 없이 엔지니어 분들이 정말.. 하드워커다.
Cloud BU 개발 인력은 인도지사가 가장 크다. 신제품은 구현부터 설계, 개발 리딩까지 인도지사에서 진행하기도 한다.
보통 일정 수립은 Robins Storage가 전신인 US에서 맡는다. 도쿄 방문 때 듣기론 RS JP도 Storage 팀원은 1명인 걸로 안다.
이때 만났던 JP 팀원은 후술할 Rakuten Object Storage 신규 개발 팀에서 버디로 배정되기도 한다.
아무래도 RS Cloud BU의 전신인 Robin Storage가 인도계 미국 스타텁이다 보니 인력 다수가 인도계다.
RS 뿐 아니라 모회사인 Rakuten Mobile 헤드도 인도계인 걸 보면 라쿠텐 신사업은 인도계한테 점령을 당한 모양이다.
JP의 Cloud BU는 크림슨 타워의 상층을 사용 중인데 라쿠텐 모바일, 심포니 VM, QA 인력이 많다.

뿌리인 라쿠텐 이치방은 유저수 1억 명, 일본 커머스 점유율 30%가량으로 시장 지배력을 보유한 상황이기에 이를 앞세워 브랜드 생태계를 꾸린 모양새다. 통신사, 클라우드, AI에 진출하는 이유도 다른 게 없다. 커머스로는 성장이 끝났고 오히려 자리를 지켜야 하는 형세라 그렇다. 이미 큐텐 JP, 아마존 JP와 일본 내수를 나눠먹는 중이라 쿠팡천하인 한국 커머스와는 다소 차이가 있다.
외산 및 신생 업체에게 위협을 받는 내수 기반 플랫폼이라는 측면에서 오히려 네이버와 유사하겠다. 쿠팡도 별 다른 해외 매출이 없다면 멀지 않은 미래에 이래 되지 않을까 싶긴 하다. 쿠팡의 인도계 기반 리더, 현업풀 및 수많은 국외 거점들을 보면 추구하는 방향성은 이미 라쿠텐과 유사해 보이긴 하나.. 거긴 나스닥 상장사니 미래가 다를 순 있겠다.
번외로 얼마 전 한국에서 불미스러운 정산런을 벌였던 큐텐 KR과 큐텐 JP는 전혀 다른 회사다. 큐텐 JP의 사명에서 유추할 수 있듯 큐텐 KR에서 출발했으나, 현재는 eBay JP에게 매각된 상태다.

도쿄 본사에 방문했을 때 RS JP의 인도계 QA 엔지니어와 잠깐 산책을 한 적이 있다.
인도는 의사 아님 소프트웨어 엔지니어를 노리고 경쟁한다더라. 인도계의 SW 사랑이 유난한 건 워낙 유명해 알고 있긴 했다.
그런 말을 농담 삼아하던 분도 IIT였다. 나보곤 서울대 나왔냐고 물어보더라. 머쓱하지만 부산대라고 했다.
엘리트답지 않게 칠하고 유쾌해서 좋았다. 인도계 분들 성향이 전반적으로 그렇긴 하다.
르세라핌을 좋아하는 분이었다. KPOP의 입지가 대단한 게 외국인들은 한국하면 삼성과 KPOP 말곤 잘 모른다.
SWE여도 예외는 아닌 게 심포니 US VP님을 제외하면 네이버와 카카오도 몰랐다. 나도 입사 전엔 라쿠텐 잘 몰랐으니 그럴만하다.
RS US 헤드 분들이 한국에서 구글맵이 안돼 헤매고 계실 때 네이버맵으로 안내하니 이게 뭐냐고 묻기도 하셨다.
 
사견이지만 이런 걸 보면 한국 및 일본계 서비스는 좀 고립된 환경이기도 하고..
그 안에서 꽤 오랜 기간 동안 네카라쿠배를 달달 외우며 줄 세우는 걸 보면 숨이 턱턱 막힐 때가 있다.
물론 나도 네쿠라토두에서 부르면 버선발로 뛰어가기야 하겠지만..
범지구적인 관점에서 보면 요로 보고 절로 봐도 한국 SW는 그러고 있을 상황이 아니긴 하다.
한국계는 레거시에 가까운 웹 서비스임에도 AI, 클라우드에 대한 경각심이 별로 없어 보인다.
이건 전 직장에 대한 애사심일 수도 있겠으나, 카나나와 라쿠텐 AI의 성능차에서 단적으로 나타난다.
한국계 서비스들은 신사업을 겉핥기로 접근하는 인상이 강하다. (이건 한국 SW 인력풀 편중의 문제일 수도 있다.)
미흡하다면 일본계처럼 '돈을 줘서라도 사야 한다.'에 가까운 입장이다. 

 
아무튼 라쿠텐 CNP의 첫인상은 매우 만족이었다.
GitOps부터 Kafka, K8s 등 공고로만 보던 모던 인프라가 눈앞에 있는 게 신기했다.
현대적인 아키텍처, 최근 공공기관 장애로 언급이 많은 DR 등 다방면에서 인도 / 미국계 인력들이 공을 들여온 게 보였다.
클라우드 개발 업체로서 성장할 시간 자체가 10년 정도로 꽤 풍부했고, K8s 기반 오버홀은 인수 시점에 진행됐다.
전현직 엔지니어 인력풀의 이력이 화려하다. RS Cloud BU 엔지니어 중 IIT CS 학부 -> 미국 석박사 -> 빅테크를 밟고 온 경우가 많았다.
IIT 중심의 라쿠텐 모바일 및 심포니의 인력풀 관리 기조는 현재까지 유지되고 있다. (라쿠텐은 IIT와 취업 연계가 되어 있다.)
그런데도 이상하리만치 내부 코드는 깔끔하지 못하다. 커밋할 때마다 무슨 C로 하드 엔지니어링하는 기분이었다.
 

한국지사엔 US지사 CTO, VP, 네트워크 팀장님 세 분이 방문하셨다. 자녀 분들이 한국 컨텐츠와 과자에 관심이 많다고 한다.🇰🇷

 
하루는 CTO님께서 한국지사를 방문한 적이 있었는데 그때 문서화가 부족한 이유를 여쭤보기도 했다.
그분 대답은 '엔지니어들이 문서화를 별로 좋아하지 않는다.'였던가.. 좀 호방하게 말씀하셨다.
'실리콘밸리 개발자들도 다 같은 사람이구나' 싶은 순간이었다. (퇴사 스택이 쌓이는 순간이기도 했다.)
 
사실 뭐 IIT니, 빅테크 출신이니, 라쿠텐이 어쩌니 해도 입사 후 5달간 한국지사의 클라우드 엔지니어는 쌩신입인 나와 함께 입사하신 인용님이 끝이었다. 심지어 입사한 분야마저 스토리지 서버 / 네트워크로 서로 달랐다.
여러모로 답이 없는 상황이었지만 그럼에도 인도계 퍼포먼스에 준해야 한다는 마음으로 임했다. (결과적으론 대실패했다.)
입사 초기엔 나보다 인용님이 더 불안해하셨던 걸로 기억한다. 그럴 만한 게 전 직장인 티맥스 클라우드와 비교하면 업무 환경이 낯설었을 거다. 아무리 5년 차 클라우드 네트워크 엔지니어라고 해도 갑자기 인도계 인력들과 리모트로 협업해야 했으니..  그래도 그분은 1-2달 정도 SP지사 버디와 밀착 페어 프로그래밍을 하며 적응하셨다. 앞서 설명했듯 나에게 배정된 버디는 인도지사의 Santosh였다.
Santosh와는 퇴사 후에도 Viber와 링크드인으로 연락을 주고받을 만큼 나름대로 친밀한 관계를 유지 중이다.
그렇지만 내가 개발을 잘 수행했다고 할 순 없다ㅜ 얘기가 길어지니 퇴사까지의 썰은 이후에 풀겠다.
 

롤체 740판.. 정상은 아니다.

 
곧 백수 2개월 차다. 가진 건 학부 졸업장과 라쿠텐 심포니 한국지사 9개월 경력, 전세로 얻은 오피스텔이 끝이다.
퇴사하고 1-2달 정도 진탕 놀다가 재취준을 시도하는 중이다. 근데 실적이 말이 아니다. 한국계 대겹, 스타텁 가리지 않고 줄 서류 탈락 중이다.. 서류를 합격한 경우가 링크드인으로 연락을 받았던 케이스를 제외하면 전무하다. (토스 DevOps, 데이터독 TSE)
OPIc IH, 외국계 정규직 개발 경력, BE 사이드 프젝, 부산대 컴공이면 낫뱃한 상황이라고 여겼는데 여러모로 당황스럽다.
취준생 시절 혹시 몰라 따놓은 정처기도 있긴 하지만.. 이게 어필이 되는 IT 회사는 아마 없을 거다. 

확실히 요즘 개발자 취업이 어렵긴 하다. 24년도 쉽지 않았는데 재취업까지 얼마나 걸릴지 모르겠다.
카카오 공채 코테(1차 광탈), 네이버 클라우드 코테(아직 응답 없음)로 살짝 코테 감은 돌려놨으니 깡체급으로 임한다는 마인드다.
웬만하면 한국계에서도 직전 직무를 이어서 클라우드 BE로 포지션을 잡고 싶다.
작년엔 게임 개발자한다고 뛰쳐나갔는데 사람 취향이라는 게 다이내믹하다. 그만큼 클라우드 스토리지 서버가 매력적이었다.
원격으로 분산된 컴퓨팅 리소스를 병합하고 임대해 주는 서버라니.. 파워풀하다.
범지구적인 컴퓨팅 리소스를 끌어 오려는 AI의 야심에 핏한 건 덤이다.
이러다가도 서비스 BE 자리 붙으면 좋다고 가겠지만 현시점에선 클라우드 BE가 1순위다.
핏한 직무를 잡는다는 게 말처럼 쉽진 않다. CNP를 가진 한국계 회사 자체가 드물뿐더러 들어가기가 만만치 않다..ㅜ

취준생->현업->재취준을 거치며 든 인상은 개발 직군 상황이 꽤 척박하다.
뭐 주 2회 재택에, 나름 나쁘지 초봉에, 서초 오피스 근무에 아주 배가 불렀다고 할 순 있겠다.
그렇지만 SWE 직군의 업무 강도와 투자 비용을 감안하면 한국 및 일본계의 페이가 높은지도 모르겠다.
무엇보다 실제 개발을 맡는 실무 인력, 특히 동년배 한국계 주니어의 수가 정말 적다.
인도계는 젊은 SWE 인력이 꽤 많다. 인구수 자체가 넘사벽이기도 하지만, 그 세계선에선 2030이 다수다.
이천 하닉 간 동기는.. 그냥 언급하면 배만 아프니 생략하겠다. 공대생이면 학점 잘 챙기고 대학원을 가는 게 답이다.
 

 
일단 살아야 한다는 마인드로 새싹 해커톤 팀에 BE로 참여해서 회의랑 기획하다 보니 다시 0 레벨로 돌아간 거 같더라.
그래도 제로 베이스 프로젝트다 보니 Cursor 쓰는 맛이 아주 좋다. Claude Sonnet 4.5 Max로 작업 중인데 인프라와 서버 코드가 아주 쭉쭉 나온다. 그만큼 토큰비로 쭉쭉 빠져서 걱정이다. 여하튼 커리어가 좀 터프하게 꼬였다고 생각한다. 새싹 해커톤 팀은 인용님께서 연결해 주셨다. 이 자리를 빌려 감사를 전한다.