4년차 개발자의 11번가 2년 경험 요약 (백엔드, 데이터엔지니어)

 

온프레미스 데이터 플랫폼 팀의 데이터 엔지니어가 하는 일(feat. 11번가 데이터 플랫폼 2020년 회

 

지난 2년여 간의 11번가 근무를 마치게 되었습니다 (2019.09 ~ 2021.12). 

 

11st Logo - Image from Korea Herald

 

그 2년 중 약 1년은 데이터 플랫폼팀의 데이터 엔지니어로, 나머지 1년은 기프티콘개발팀의 백엔드 엔지니어로 근무했는데요. 

 

다음 회사에서 근무를 시작하기 전 시간이 있을 때에, 11번가에서의 지난 2년을 돌아보며 한것들, 배운 것들, 더 배울 것들, 떠올랐던 질문들을 정리해보고자 합니다:

 

• 데이터 플랫폼팀의 데이터 엔지니어
• 기프티콘개발팀의 백엔드 엔지니어
• 마무리하며

 

---

데이터 플랫폼팀의 데이터 엔지니어

이전 회사에서 데이터 엔지니어로 근무했었지만 그곳은 클라우드 환경이었습니다. 그렇기에 처음에는 온프레미스 환경에 대한 기대와 빠르게 배워서 업무에 적응해야 한다는 긴장감을 가지고 있었는데요. 이후 적응을 하고나서는 클라우드를 통해 제품을 사용해왔던 서비스(YARN, Hive, Spark, Storage 등)들의 뒷단에 대한 이해를 넓힐 수 있었습니다.

 

했던 것들

데이터 플랫폼팀에서 했던 일들은 온프레미스 데이터 플랫폼 팀의 데이터 엔지니어가 하는 일(feat. 11번가 데이터 플랫폼 2020년 회고) 에 정리해두었습니다. 이 블로그의 첫 글인데, 벌써 1년이 넘는 시간이 흘렀네요.

 

 

배운 것들

전반적으로 인프라 운영 업무가 주를 이루다 보니, 데이터 환경을 인프라로 안정적으로 운영하는 방법에 대한 고민을 많이 했었습니다. 이전의 클라우드 환경의 회사에서는 필요한 데이터를 가공하고, 처리하고, 데이터 상품을 개발하는 일이 주였기에 제 기대보다는 꽤나 운영적인 측면이 강했습니다. 

 

그렇기에 인프라를 구성하고, HA(High Availability)와 같은 아키텍쳐를 고민하고, Infra as a code를 실행해나가는 부분들에서 팀원분들과 같이 일하며 많이 경험한 것 같습니다. 또한, 다양한 도구들을 폭넓게 비교검토해보면서 POC를 진행하고 장단을 따져서 기술적인 선택을 하는 부분도 여러 번 경험할 수 있었던 것 같습니다. 

 

더 배울 것들

파트 상으로는 데이터 거버넌스 파트였기 때문에 HDFS, Yarn, Hive, Spark, Dremio, Ranger 등의 서비스의 모든 것을 주도적으로 운영할 수 있는 기회는 많이 없었던 것 같습니다. 

 

그리고 업무 상의 요구사항을 빠르게 처리하여야 했기에 시스템의 부분 부분을 코드 레벨까지 살펴보며 Contribution을 하거나 깊게 이해하지는 못했던 것 같습니다. 특히, 분산시스템의 공통적인 요소들인 RPC, 컨센서스 등의 핵심적인 부분을 추가적으로 이해한다면 이후의 비트코인과 같은 분산시스템을 이해하는 데에도 큰 도움이 될 것 같습니다. 

 

떠올랐던 질문들

어렴풋이 기억나는 것과 현재 돌아볼 때 궁금한 점들은 아래와 같습니다:

 

• HDFS의 내부에서 로컬파일시스템과 어떻게 상호작용하는 것인가?
• YARN은 어떻게 동작하고 Mesos, Kubernetes 등과는 어떤 유사성과 차이점이 있는가?
• HDFS의 edit logs, fsimage는 어떤 구조로 되어 있는가?
• Spark 소스 코드는 어떤 아키텍쳐로 되어 있는가?

 

 

기프티콘개발팀의 백엔드 엔지니어

사내의 커리어 스토어를 통해 옮겼습니다. 운이 좋게도 바라고 바라던 백엔드 엔지니어의 업무를 할 수 있게 되었는데요. 처음 사용해보는 Java와 익숙하지 않은 Spring, 배포 및 업무방식 등 배울 것이 많다는 사실에 흥분되었었습니다. 

 

아웃소싱되던 서비스를 내재화하면서 생겨난 팀이라, 20명 가까이가 채용되기 전까지 4개월이나 걸렸는데요. 이 기간 특별히 업무가 나눠지고 할당되지 않아서 조금 루즈하기도 했던 것 같습니다. 이후 업무가 할당되고 조금 자유로운 서비스를 맡게되어 레거시를 갈아엎으면서 Java, Spring Boot, Spring Batch, Maven, Gradle, Apache Http, Apache Tomcat 등에 조금 익숙해질 수 있었습니다.

 

Gifticon Backend Mapping - Image from Author

주로 아래의 글들에서 다루는 내용들을 많이 고민했던 시기인 것 같습니다:

• Spring Framework란?
• 개발자가 읽어본 '서비스 기획 스쿨'
• 오라클 DB 아키텍쳐 살펴보기 (Database, Instance, Files, Memory, Process)
• DDD란? ((Business) Domain-Driven (Software) Design)
• 확장성 및 안정성 있는 시스템에 관하여 (feat. 패스트캠퍼스 온라인 'THE RED : 4천만 MAU를 지탱하는 서비스 설계와 데이터 처리 기술')
• Spring MVC Internals (내부구조)
• 웹서버, 앱서버 그리고 CGI (Web & Application Server and CGI)
• 서블릿(Servlet)의 구조와 접근방식 (feat. CGI)
  
  
• 아파치 톰캣 내부구조 (Apache Tomcat Internals)
• 서블릿의 세션 관리 (Servlet Session Management)
• 레거시를 파악하고 변경해나가기: 우선순위와 고려사항들

 

했던 것들

담당한 엔쿠폰이라는 서비스는 2000년대 중반 만들어져서 그 동안 외주로 운영되오던 서비스였습니다. 또한, 서비스 인수인계 시에도 여러 정치적인 이유로 그다지 적극적으로 인수자로부터 인수인계를 받진 못했는데요. 그렇기에 초반부에는 환경 정리에 많은 시간을 할애하고, 이후 리팩토링과 버젼 업그레이드를 중심으로 업무가 진행되었던 것 같습니다.

 

특히 [1]과 유사한 활동들을 많이 수행한 것 같습니다.

 

 

로컬, 개발, 상용 환경 및 프로세스 정리

일부 코드는 배포 프로세스를 타서 버젼관리되고 일부는 '손배포'되어 버젼관리도 믿을 수 없었습니다. 그렇기에 '손배포' 서비스는 서버 바이트코드만 확보해두고, 버젼관리되던 서비스들은 로컬, 개발, 상용 셋업을 진행했습니다. 

 

이러한 '버젼관리된 서비스들' 중에서도 로컬, 개발, 상용 환경이 제대로 설정되어 있지 않은 것들은 가능하다면 환경 정리까지도 하는 작업을 꾸준히 진행했습니다. 

 

모니터링, 로깅 정리

인수인계를 온전히 다 믿을 수는 없었고, 시스템에 대한 신뢰도 많이 부족했습니다. 그렇기에 초반에 시스템 및 서비스 모니터링, 로깅을 하나하나 확인해보며 조금이라도 더 안정성을 높이기 위한 방법을 많이 고민했습니다.

 

기본적으로 인프라에서 제공해주는 도구를 사용해 서버들에 모두 CPU, memory 알람이 설정되어 있는지, 데몬 서비스 다운 시에 알람은 즉각적으로 받을 수 있는지 등을 목적으로 진행했습니다.

 

 

테스트가 손쉽게 추가할 수 있도록 프레임워크 변경하기, 테스트를 추가하기

또 다른 안전장치인 꼼꼼한 테스트를 추가하기 위해 노력했는데요. 1) 테스트 쉽게 지원되지 않는 프레임웍, 2) 테스트를 쉽게 작성하기 어렵게 의존성이 넓게 연결된 코드 등의 어려움이 있었습니다. 

 

2)는 나중에 다시 생각하기로 하며 코드 변경을 최대한 피하고, 1)을 위주로 프레임웍 버젼을 올리거나 테스트가 가능할 정도의 국소적인 코드 변경만을 하며 테스트를 추가해나갔습니다. 

 

이러한 코드 변경 시에 혹시도 모를 함정을 피하기 위해 소나큐브를 도커로 간단하게 올려 정적 분석을 수행하기도 했습니다. 

 

배치 형태의 작업들을 Spring Batch로 일원화하기

가맹점 정보 업데이트, 쿠폰 라이프사이클 처리, 유효기간 지난 핸드폰 번호 마스킹, 정산과 같은 다양한 작업을 위해 수많은 배치가 다른 repository에서 생성되어 크론탭으로 수행되고 있었습니다. 이 중에는 '손배포'로 수행되며 버젼관리도 믿을 수 없는 것이 많았는데요.

 

이러한 배치 작업들을 Spring Batch로 한 군데로 옮기고 가능하다면 스케쥴을 젠킨스로 수행해서 수행 내역을 관리하였습니다. 

 

 

Web-Was 형태의 서비스들 리팩토링, 인프라 개선

앞서 언급한 테스트 추가에서 주된 대상이 바로 WebWas 서비스들이었는데요. 그렇게 테스트로 조금 마감처리?된 것들을 대상으로 리팩토링을 수행하고 Was L4와 같은 인프라 설정들을 정리하는 활동을 진행했습니다.

 

 

끊임없는 '미사용' 폐기

오래되고 외주로 운영되다 보니 비효율적으로 자리만 차지하고 있는 것들이 많았습니다. 사업적으로 요청만 하면 손쉽게 repo하나를 폐기할 수 있는 것들, 이미 형식적인 요청만 남고 실제로 데이터는 빈 것만 존재하는 것들 등 서비스, DB 테이블, 프로세스 등 미사용하는 것들이 많았습니다. 또한, 사용하고 있는 repo이나 필요없는 코드도 많이 있는 것도 있었습니다.

 

예전부터 필요없는 코드 100줄을 삭제하는 것을 코드 100줄을 추가하는 것만큼 가치있다고 생각했는데요. 그러한 관점을 가지고 꾸준히 미사용을 줄여 나가려고 했던 것 같습니다. 

 

 

배운 것들

Java와 Spring에 많이 익숙해질 수 있었습니다. 또한, 서비스 개발의 환상을 벗기고 이상적인 방향으로 조금씩 개선해나가는 부분에서 많이 배울 수 있었던 것 같습니다.

 

특히 그러한 부분에 있어서 테스트의 중요성과 '테스트란 무엇인가?, 어떤 의미를 가지는가?'에 대해 많이 고민해볼 수 있었던 것 같습니다. 레거시를 바꿔나가면서, '어떻게 하면 내가 더 자유롭게 개발할 수 있도록 환경을 구성할 수 있을까?', '어떤 안전장치가 있어야 내가 좀 더 큰 보폭(?)으로 개발을 성큼성큼 할 수 있을까?'라는 생각을 많이 했습니다. 이 점은 Refactoring, Clean Code 등을 읽으며 다양한 관점에서 노력했던 부분이었던 것 같습니다.

 

더 배울 것들

대부분 B2B였기에 수많은 트래픽을 받고 있는 B2C를 운영하는 부분에 대한 경험은 할 수 없었던 것 같습니다. 또한, 다른 분이 진행하셨던 C++ 코드를 Java로 변경하는 작업에서의 socket 통신, 전문통신 등을 깊게 보고 이해하지는 못했던 것 같습니다. 

 

서비스 자체도 마이크로서비스라고 생각될만큼 각 서비스의 크기가 작았으나 전체 시스템의 규모는 크지 않았기에 좀 더 복잡하고 마이크로서비스의 갯수도 많은 시스템을 경험해보고 싶은 것 같습니다. 

 

 

떠올랐던 질문들

돌아보면 아래와 같은 질문들에 대해 더욱 살펴보면 좋을 것 같습니다:

 

• Spring 내부는 어떤 구조로 작성되어 있는가?
• Graal VM은 어떻게 이뤄져 있는가?
• socket 통신은 구체적으로 http와 어떻게 다른가?
• 어떻게 마이크로서비스로 진화해갈 수 있을까?
• 모바일 쿠폰 시스템을 어떻게 통합의 방향으로 단계적으로 이행할 수 있을까?
• 실시간 모바일 쿠폰 번호 생성을 위해서 기존 시스템을 어떻게 개선할 수 있을까?
• POS/VAN, 가맹점, 브랜드사, 고객사 등의 도메인을 어떻게 정리할 수 있을까?
• 블록체인 기반으로 어떻게 쿠폰 시스템을 구축할 수 있을까?
• 어떻게 하면 내 PR의 컨택스트가 리뷰어에게 좀 더 공유될 수 있을까?
• 전체 서비스를 어떠한 방향으로 이끌어야 기업의 목적을 달성하는 동시에 구성원의 흥미도 이끌 수 있을까?
• 서비스를 개발해나가는 기획말고 서비스를 정리하고, 간명화하는 기획이 있다면 어떠한 모습일까?
• 첫 대면 시의 긴장되는 상황에서 어떻게 하면 좋은 커뮤니케이션으로 리드해 나갈 수 있을까?
• 기업의 문화는 어디에 주로 기원하는가?

 

 

마무리하며

많은 감사한 분들의 지원과 격려 속에서 따뜻하고 열정적으로 근무할 수 있었던 11번가 였던 것 같습니다. 기업의 문화 역시도 신뢰를 바탕으로 많은 부분에서 개선해나가며 따뜻한 성장을 경험할 수 있도록 해주었습니다. 

 

감사한 마음과 고마운 마음을 느끼고 배울 수 있었습니다. 

 

 

Reference

[1] 동영상 플랫폼 개발 프레임워크의 Spring Boot 전환기

 

 

레거시를 파악하고 변경해나가기: 우선순위와 고려사항들