2024하반기, 2025상반기 회고

약 1년만에 블로그 글을 쓴다. 그동안 글을 안쓴 이유를 돌이켜보면, 나 스스로 담금질이 필요하다고 생각했다.

처음 경험하는 storage 도메인에서 적당히 아는 상태로 글을 쓰고 싶진 않았다.

 

물론 블로그에 글로 정리하면 학습 효과를 증폭시킬 수 있다. 하지만 그 에너지를 아끼고 싶은 마음도 있었다. 새로운 팀에 빠르게 적응하고, 팀에서 사용하는 storage 기술로 대학원 졸업 논문을 쓰고 싶었기 때문이다.

 

그렇게 1년이란 시간 동안 여러 경험을 했고, 이제는 글로 정리 할때가 됐다고 느껴서 8월이지만 회고글을 쓴다.

 

1. S3 Object Storage 개발

팀 상황

2024년 5월부터 합류한 네이버 Storage Platform 팀에서는 이미 오래전부터 사내 서비스팀들에게 Object Storage 를 제공하고 있었다. 하지만 S3 스펙과는 달랐고 시간이 흘러 어느새 S3 는 디펙토가 되었다.

 

네이버 클라우드 법인에서도 Object Storage 서비스를 클라우드 상품으로 제공하고 있었다. 하지만 더 큰 발전을 위해서 우리팀과 힘을 합치기로 했다. 그래서 2024년부터 본격적으로 S3 스펙을 준수하는 Object Storage 를 같이 개발하고 있다.

cf) 법인을 이동하며 팀을 합친건 아니다. 여전히 서로 다른 법인의 다른 팀이었지만 원팀으로 같이 함께 개발 및 운영하고 있다.

 

통합 테스트 환경 구축

팀에 합류하고 가장 먼저 통합 테스트 환경을 구축하는 일을 맡게 됐다. 그런데 팀에서 원하는 통합 테스트는 내가 기존에 알고 있던 개념과 조금 달랐다. 그동안 경험한 통합 테스트란 dev, alpha 환경 서버들에 애플리케이션들을 띄워서 http api 나 브라우저에서 직접 테스트 하고, 애플리케이션과 연동된 db, kafka 등은 개발 환경에 따로 설치된 것을 활용했다.

 

하지만 이 팀의 통합 테스트는 개인 PC 또는 개인적으로 쓰는 VM 에서 Object Storage 가 동작하기 위한 모든 애플리케이션들(s3-gateway, metadata-manager, metering, orchestration, storage engine 등) 뿐만 아니라 db, kafka, redis, consul, etcd 들을 모두 함께 docker container 로 띄워서 연결시키고 테스트 돌리는것을 의미했다. 다시 말해 개인별로 db, kafka 를 갖고 각자 테스트 돌릴 수 있는 것이다.

cf) dev, alpha 환경에서 애플리케이션들을 모두 띄워놓고(db, kafka 포함) QA 가 테스트하는것도 당연히 존재한다. 하지만 그걸 통합 테스트라고 부르진 않고 있다.

 

이렇게 모든 프로세스들을 docker 로 띄우면 테스트 자유도가 높아져 다양한 장애 테스트도 쉽게 가능하다. 예를 들면 파일 3000개를 쓰고 지우는 과정에서 특정 애플리케이션이 잠깐 중단되도(docker container 를 내리거나 gofail 을 활용해서) 과금을 담당하는 metering 애플리케이션은 문제없이 잘 처리되는가를 테스트 해볼 수 있다.

 

각 애플리케이션들을 dockerizing 해서 띄우는 기술적인 부분들은 크게 어렵지 않았다. 하지만 테스트를 성공시키기 위해서 모든 애플리케이션 간 연관관계를 정확히 이해하는 과정이 쉽지 않았다.  원론적으로는 기능을 개발한 담당자가 직접 통합 테스트를 만드는게 맞다. 하지만 그 당시 우리 모두 너무 바빴다. 12월 출시를 위해 각자 위치에서 단위테스트까지는 충실히 작성했지만, 중간 중간 전체를 연결시켜보긴 어려웠다.

 

그러다보니 통합 테스트 환경을 구축하는 내가 먼저 S3 API 들을 테스트하고 결과들을 보여줄 수밖에 없었다. 처음 내 역할은 테스트 환경을 구축해서 동료들이 쓸 수 있게만 하는 거였지만 세상일이 그렇게 깔끔하게 흘러갈 순 없다. 이런 테스트 문화에 익숙하지 않은 분들도 많았다. 결국 내가 직접 만들면서 보여줬다.

cf) D-day 를 잡고 dev, alpha 환경에 배포해서 테스트하는 프로세스도 있었지만 주기가 길었다. 개발하면서 바로바로 알고 싶었기 때문에 이 통합 테스트를 만들게 된거다. 

 

테스트를 만들면서 하나하나 익혀 가다보니 자연스럽게 전체 아키텍처의 flow 를 이해하게 됐다. 아래 그림은 특정 API 에 대한 sequence 를 표현한거다. 개인 블로그이기 때문에 자세히 공개할 순 없어서 블러 처리했지만 복잡하게 여러 모듈들이 협력 하는것을 알 수 있다.

파란색 box 가 docker container 를 의미

 

그리고 개발자가 특정 모듈에서 개발하고 PR 을 올리면, 그 PR 브랜치 버전의 애플리케이션과 다른 애플리케이션들(develop 브랜치 버전)로 docker container 가 띄워져 테스트들이 수행되고 문제가 없으면 github PR merge 가 가능하도록 만들었다.

 

2024년 개인 목표는 12월 말까지 중요 애플리케이션들을 모두 docker container 로 띄워서 여러가지 장애 시나리오 테스트를 만들고, 문제를 조기에 발견 하는거였다. 나는 QA 에서도 발견하지 못한 중요한 버그를 찾아냈고 이 팀에서의 개인 목표는 달성했다.

 

2024년 동료 평가 일부

• 봉수님 바뀐 조직과 업무에 적응하는 것도 쉽지 않으셨을 텐데, integration-test를 리딩하면서 기초부터 차근차근 잘 만들어주셨어요. 특히 어려운 점이 있을 때마다 바로 공유하고 의견을 묻고 토론을 통해 좋은 결정을 하려고 노력하시는 점이 좋았습니다. 또한, 스스로 업무 스터디를 조직해 프로젝트에 빨리 기여하려고 하시는 모습에 저도 배울 점이 있다고 느꼈습니다. 앞으로도 그 모습 유지 부탁드립니다.
• 새로 S3 Project에 참여해서 새로운 업무를 하고, 그 중에 Integration Test를 맡아서 책임감 있게 잘 하고 계십니다.
  S3나 Integration Test 모두 쉽거나 익숙한 일이 아닌데도 스스로 방향성을 잘 세워서 목표하는 바를 이뤄가고 있다고 생각합니다.
• Integration test 파트의 업무를 매니징해야 하는 상황에서 00님, 00님과 적절히 논의하셔서 방향을 잘 잡아주신 부분이 큰 도움이 되었습니다. 협업할 때 필요한 만큼의 커뮤니케이션을 효율적으로 해주시는 부분이 인상적이었습니다. 필요하면 빠르게 주변에 도움을 구해서 어떻게든 해결해주셔서 함께 일하는데 도움이 되었습니다.
• 일정 준수를 위해서 목표 달성을 위한 계획을 잘 구조화 시키고, 업무가 지연되지 않도록 책임감 있게 진행하시는 모습이 인상 깊었습니다.
• 주문서 작업을 진행하면서 궁금한 부분은 적극적으로 질문하고 언제나 앞장서서 운영을 이끌어가는 모습이 매우 인상적이었습니다. 문제를 정확히 이해 하려는 자세와 적극적인 소통은 팀의 분위기를 더욱 활기차게 만들었으며 프로젝트의 완성도를 높이는 데 큰 역할을 했습니다. 이러한 장점과 능력은 S3 프로젝트에서도 좋은 영향을 발휘할 것이라고 확신합니다.

 

2025년 metadata

올해부터는 S3 metadata 를 담당하게 됐는데, Object Storage 에서 metadata 도 layer 가 있다. bucket, object 에 대한 기본 정보와 인증, 암호화 같은 metadata 가 있고 그 밑에는 실제 파일이 어디에 어떻게 저장되는지에 대한 metadata 가 있다. 나는 그중에 후자, 좀 더 storage engine 에 가까운 metadata 를 다루고 있다. 이렇게 layer 를 나누면 indirect 로서 물리 파일 이동에 대한 자유로움이 있다. 다시 말해 storage 추상화를 통해 다양한 storage 를 지원하고 storage 간 데이터 이동 기능을 제공할 수 있다.

 

 

2. 대학원(2022.09 ~ 2025.08)

진학 계기

'비트코인 블록체인 바이블' 이란 책을 재밌게 읽고 저자께 책의 오탈자를 메일로 제보했는데, 평소 독자에게 피드백 등 궁금한게 많으셔서 전화통화를 희망하셨다. 그래서 1시간 정도 블록체인에 대한 이야기를 나누면서 그분이 서강대학교 AI·SW대학원(구 정보통신대학원) 블록체인 학과를 진학중이라는것을 알게 됐다. 나는 평소에도 대학원 진학에 관심은 있었지만 비싼 등록금을 낼 만큼의 가치가 있을지 확신이 없었다. 그래서 그분께 여러가지를 물어봤다. 

 

일단 대학원을 통해서 얻는 두가지 이득, '학벌세탁', '인맥' 이 나에겐 별 도움이 안될거라는건 인지하고 있었다. 대학원 가서 최종 학력을 바꾼다고 그걸 인정해주는 회사도 아니고 나 스스로도 의미부여를 안했기 때문이다. 그리고 나는 인맥을 잘 만들 성격도 못되고 비지니스적으로 도움이 되기에 개발자라는 직군은 한계가 있다. 또한 저자는 대학원 가서 깊이있게 배울 수 있을거란 기대는 하지 말라고 하셨다. 전공은 나뉘어 있지만 다같이 골라서 듣는 수업이기에 교수 및 강사들이 수업 난이도를 적절히 맞추기 어렵기 때문이었다.

 

그럼에도 나는 진학을 선택했다. 이유는 단순했다. 안하면 앞으로 계속 생각날거 같아서였다. 그렇다면 한살이라도 젊었을 때 빨리 가는게 낫겠다 판단했다.

 

대학원 생활

블록체인 학과로 진학했지만 예상했던대로 블록체인 과목과 수업 내용은 별거 없었다. 겉핥기 정도의 기술, 산업 동향이 전부였다. 그래서 나는 일찌감치 전략을 바꿨다. 분산처리시스템, HDD/SSD 저장시스템, Linux운영체제, 고성능 컴퓨팅 시스템, 데이터베이스론 등의 CS 수업을 들으면서 초식을 다졌다. 학부때와는 달리 아는게 많아진 상태에서 수업을 들으니 더 재밌었고, 교수님이 수업 내용이 어려운 학생들을 배려해 적당히 설명하고 넘어가려할 때는 계속 질문하면서 디테일을 채웠다. 그 과정에서 두번이나 성적 장학금도 받아봤다. 

 

대학원 1~4학기까지는 네이버페이 주문서 시스템 개편 일을 하면서 다녔다. 그래서 일이 바쁠때는 학교 갔다 와서 다시 집에서 일한적도 있다. 그래도 중간고사까지는 학교에 직접 가고, 그 이후부턴 zoom 온라인 강의로 진행해서 체력적으론 편했다. 하지만 확실히 zoom 강의일때는 교수님이 학생들 반응을 못보니 설명을 많이 생략하면서 진도를 빨리 빼는 경향이 있었다. 그래서 수업 질만 따졌을 땐 직접 학교가는게 좋은데, 회사를 생각하면 zoom 강의가 너무 소중했다.

 

대학원 학생들과는 많이 친해지지 못했다. 교류 행사는 많았는데 주로 학교 근처인 신촌, 홍대, 을지로 등에서 만나다 보니 멀어서 참석하기 힘들었다. 굵직한 행사에는 종종 갔지만 간헐적 교류로 친분이 이어질순 없었다. 그래도 소중한 인연 몇명을 얻어서 그걸로 만족한다.

 

논문

2025년 1Q 때 우리 Object Storage 시스템 전체를 k8s 환경에서 운용하는게 현실적으로 가능한지 poc 를 진행했다. storage 비용 절감이 올해 목표 중 하나였기 때문이다. PM 몇천대를 k8s 로 전환해 아껴 쓸수만 있다면 큰 비용 절감을 이룰 수 있다.

cf) 아래 그림에서 DB 를 metadata 서버 안으로 표현 했지만, 실제로는 다른 서버에 독립적으로 존재한다.

 

하지만 관건은 stateful 애플리케이션이다. 데이터를 직접 I/O 하는 storage engine 애플리케이션이 다른 노드에서 뜨게 되면 데이터를 찾을 수 없는 문제를 해결해야 했다. longhorn 이나 cubeFS 등 여러 오픈소스들이 있지만, 바로 쓰기엔 성숙도가 낮았고 단순히 오픈소스를 장착시킨다고 문제가 해결되는게 아녔다. 우리가 이미 구현해 놓은 여러 기능들이 오픈소스 기능과 중복되었기 때문에 잘 발라내서 적용해야 하는데 쉽진 않았다.

 

그래서 우리의 storage engine 애플리케이션을 얼마만큼 수정하면 k8s 에서 운용할 수 있을지 따져봤다. 결론부터 얘기하면 ROI 가 안나왔다. PM 기반이라는 전제로 짜여진 로직들이 너무 많았다. 그리고 IDC 3개에 걸쳐진 k8s cluster 를 다른팀에서 개발중이었지만  우리 storage 는 규모가 너무 컸다. 그러다보니 k8s 로 간다고 하더라도 진짜로 서버 비용을 아낄 수 있을지도 미지수였다. 성능은 PM 보다 좋을 수 없는데 비용이 절감되는게 확실치 않으니 k8s 로 전환하는게 맞다고 주장할 수 없었다.

 

poc 는 그렇게 끝났지만 storage engine 이 k8s 에서 운용되기 위해서 갖춰야 할것들에 대해서 깊게 고민하게 됐고, 관련해서 논문을 썼다. 간략하게 설명하면 k8s 환경에 맞게 IDC 장애를 인지시켜, 정상일 땐 데이터를 Erasure Coding 으로 IDC 3개에 분산 저장시키다가

 

 

IDC 장애가 발생하면 Erasure Coding 파라미터를 동적으로 변경시켜 문제 없는 IDC 로만 데이터를 분산 저장시키는 메커니즘을 다뤘다.

 

 

이를 위해 직접 IDC 3개를 걸친 k8s cluster 를 만들었고 IDC topology 를 제공하는 기능도 만들었다. 개인 학위 논문이기 때문에 Object Storage 오픈소스중 하나인 minio 에 소스코드를 수정해서 활용했다.

대학원 총평

3000만원이 넘는 등록금을 낼 만한 가치가 있냐는 질문을 나 스스로 계속 했다. 그리고 나는 '가치가 있다' 는 답을 내렸다. 대학원 수업에서 다시금 CS 기초 지식들을 다지기도 했고, 논문을 쓰면서 처음으로 문제를 정의하고 왜 해결해야 하는지 설득 하는것도 경험해봤다. 그동안 회사에서 리더가 정해준 일을 주체적으로는 진행해봤어도, 일 자체를 만들어 왜 해야하는지 설득 시키면서 해본적은 없었다. 그리고 논문을 쓰면서 성능이 좋아졌다는 주장을 실험으로 증명해내는 모든 과정속에서 많이 성장했다. 마지막으로 논문을 완성시켰다는 경험이 나에게 큰 자신감을 줬다. 해냈다는 경험이 근거 있는 자신감이 되어 앞으로의 더 큰 일도 충분히 해낼 수 있다는 마음으로 연결되고, 그것이 나에게 큰 힘이 된다.

 

또 다른 발전은 체력이다. 대학원 첫학기를 회사일과 병행해보니 강한 체력이 뒷받침 되지 않으면 무너지겠다는 생각이 들었다. 그래서 2023년 1월부터 지금까지 끊임없이 헬스장 PT 를 받고 있다. 현재는 PT 수업 포함 주 6일 1시간 30분씩 운동해도 무리가 없을 정도로 체력이 많이 향상 됐다.

 

대학원도 그렇고, 회사 일도 그렇고 절대 내가 계획한대로 흘러가지 않았다. 하지만 어떻게든 더 나은 방향으로 갈수 있게 부단히 발버둥쳤다. 결과적으로 이렇게 연결되는 무형의 가치가 있어서 나 스스로 등록금 값어치는 했다고 믿고 있다.

 

3. Next Step

이제 다음 계단을 오를 준비 하고 있다. 최근 '인재전쟁, 공대에 미친 중국' 다큐멘터리를 보고 생각이 많아졌다. 사실 sw 쪽에선 이미 한참 전부터 중국이 앞서고 있다는것을 알고 있었다. 하지만 영상으로 그 열기를 직접 보니, 인재도 아닌 범부인 나는 앞으로 무엇을 해야 할까 고민이다.

 

모든 길은 AI 로 가는 시대다. 자연스럽게 'storage for AI 가 되기 위해선 나는 어떤 기술력을 갖춰야 할까?' 라는 생각을 하게 됐다. 떠오르는 생각들은 있지만 아직 여물지 못해서 글로 남기진 않겠다. 일단 storage 에 대해서 더 깊이 알아야 한다.

 

그래서 내년부턴 한단계 더 깊이 내려가서 metadata 뿐만 아니라 물리적으로 저장되어 있는 storage engine(분산 파일시스템)도 새롭게 담당하기로 했다.