Career

라인넥스트에서의 2년 7개월 회고

Kaden Sungbin Cho 2024. 7. 13. 15:53
반응형

2021년 12월부터 2024년 7월까지 라인넥스트에서 백엔드 엔지니어로 근무하였습니다.

 

이 경험을 퇴사 직후 돌아보며, 추후 의사결정에 도움이 될만한 기억으로 정리해봅니다:

 

 

  • 당시 라인넥스트의 컨택스트
  • 진행했던 일과 기술적인 사항들
  • AAR (After Action Review)

 

당시 라인넥스트의 컨택스트

2021년 12월 저는 라인플러스에 NFT 월렛 백엔드 개발자로 입사하게 되었습니다. 하지만 직후 블록체인 관련 계열사 분리에 따라 라인넥스트로 2022년 1월 1일에 분사하여, 소속이 변경되게 되었습니다.

 

라인넥스트(이전의 라인플러스 소속의 블록체인 관련 조직)는 2010년도 후반부터 꾸준하게 블록체인 사업에 투자해왔습니다. 2021년 12월 입사 시에는 지속적으로 연구개발해온 체인 플랫폼 조직과 그것에 기반해 일본 NFT 월렛, 체인 API를 기능으로 노출하는 제품 등을 다루는 체인 프로덕트 조직 2개로 구성되어 있었습니다.

 

일본 NFT 타깃이 아니라 본격적으로 DOSI라는 이름의 글로벌 NFT 마켓 플레이스를 만들자는 의사결정이 이뤄졌고, 그에 따라 많은 채용이 이뤄져 다수의 동료들과 함께 합류하게 되었습니다. 추측으로는 이러한 의사결정의 기반으로 21년의 코인 시장의 강세와 기존에 존재했던 일본 NFT 월렛의 일부 기능으로 판매되었던 NFT 반응이 기초가 된 것으로 보입니다.

 

2022년 4월 최초의 DOSI 프로덕트가 웹 기반 애플리케이션으로 상용 출시되었습니다. NFT 공급자는 라인넥스트에 온보딩 절차를 통해 허가받은 브랜드사로 상품에 NFT 소유권에 연동한 여러 보상을 제공하였고, 브랜드사의 결정에 따라 해당 NFT가 DOSI 애플리케이션 내에서 C2C 거래가 가능한 기능을 제공했습니다. 그렇기에 기본적으로 인증, Fiat & Crypto 결제, 이커머스의 기능들이 필요했습니다. 이후 결제 기능을 좀 더 고도화하여 2022년 9월 베타 출시라는 형태로 다양하게 마케팅 활동을 진행하였습니다 (1). 

 

2022년의 코인 시장은 큰 하락을 맞이하였으나, 초기의 DOSI 상황은 그리 나쁘지만은 않았던 것으로 보입니다. 다수의 한국 유저가 투자(또는 투기)를 목적으로 진입하여 원화로 많이 구매한 것으로 볼 수 있습니다 (1). 

 

이후 (2022년 후반기 ~ 2023년 상반기) 결제와 관련해서는 지속적으로 신규 결제 수단의 추가를, 계정계로는 Bitmax Wallet 통합 (3), 커머스적인 부분으로는 마중물이 될 수 있는 브랜드사의 랜딩이 지속되었습니다 (2). 또한, 그 마중물이 외부 브랜드에만 오직 의존하는 형태를 피하기 위해 Citizen이라는 자체 브랜드를 지속적으로 키우고 다양한 재미요소를 추가하였습니다 (4). 

 

지속적인 통합의 흐름과 2023년 하반기부터 조금씩 시작된 코인 시장의 강세에 따라 라인넥스트는 기존에 존재하던 논커스토디얼 월렛 DOSI Vault (5)와 DOSI 애플리케이션, 일본 전용으로 출시되었던 LINE NFT를 DOSI 애플리케이션에 모두 통합하며 정식 출시를 진행하였습니다. 동시에 크레센도 투자사로부터 1800억원의 투자를 유치하였습니다 (6). 또한, Klaytn과 Finschia가 체인 통합을 합의하여 KAIA가 탄생하게 되었습니다 (7).

 

이후 NFT라는 이름보다는 범용적인 Item으로 네이밍을 변경하고 앱 멤버십, 티켓, 게임 아이템 등을 거래할 수 있는 디지털 커머스로 PMF를 찾아가고 있습니다. 

 

진행했던 일과 기술적인 사항들

개인적으로는 대부분의 시간을 월렛팀의 백엔드 롤(일부 데이터 엔지니어)로 근무하였기에 인증 및 결제, 정산(일부)에 관여할 수 있었습니다. 또한, 프로덕트의 상황에 따라 기능조직 또는 목적조직에 속하며 2년 7개월이라는 기간 동안 10회 이상의 소속 변경을 경험하며 각각의 상황에서 특징적인 부분들을 경험하였습니다.

 

조직운영

조직운영과 관련해 느낀 부분들은 아래의 개념들과 연관되어 있습니다:

 

먼저, 콘웨이의 법치과 관련해서는 프로덕트의 각 단계와 목적에 맞게 2년 7개월 간 대략 10회 이상의 소속변경을 경험하며 원하는 프로덕트를 위한 조직 구조 준비를 경험하였습니다. 기획자, 디자이너와 한 팀에 속해 목적조직으로의 상황과 개발 조직에 속해 한 기능단위로 존재하는 개발조직이 어떻게 다른지, 장단이 무엇인지 알 수 있었습니다.

 

DDD와 고부가가치개발과 관련해서는 대만, 베트남, 외부지원사, 외부연동사 등과 관계하며 '내가 어떤 일을 해야 지금 상황에서의 밥값을 하고 있는 것인가?'에 대해 좀 더 심도 깊게 생각해볼 수 있었습니다. 수많은 일들 중 내가 리소스를 사용해야하는 임팩트 있는 일이 무엇일지 우선순위를 고려하고, 막무가내의 리소스 지원 또는 사용을 지양하는 관점에 기반하였습니다. 실질적으로는 꾸준하게 리스트업하고, 고민하고, 필터링하고, 선택하는 과정이었습니다. 

 

PM과 관련해서는 엔드유저를 관찰한 사업이 발생시킨 이슈, 리드 단의 결정, 디자인, 기획, 개발, QA 등으로 이어지는 촘촘한 흐름에서의 스케쥴링을 간접경험하였습니다. 역시 요구된 일정을 준수하기 위한 우선순위에 대한 파악과 스콥의 조정, 의존성 제거 및 분석을 유기적으로 하나의 흐름으로 만들어야 하는 부분이 인상적이었습니다.

 

 

도메인

도메인이라는 부분에서는 진행했던 백엔드 업무가 어떤 현실의 문제를 해결하기 위한 것이었고, 그것을 위해 어떤 것들을 low-level 기술 외적으로 공부하였는지 기술하였습니다.

 

인증

메인으로 담당했던 인증이라는 부분은 모든 서비스에 대부분 기본적으로 필요한 사항이기에 좋은 경험이 되었습니다. 인증과 관련해 실무적인 관점에서의 좋은 자료를 찾기가 어려웠는데, Manning의 'API Security in Action'은 개념 설명과 더불어서 너무나도 좋은 코드 샘플들이 많아서 감탄하며 읽었던 기억이 나네요 (주니어 책 추천 리스트에도 넣어두었습니다).

 

OAuth

OAuth와 관련해서는 RFC 문서들을 차분하게 읽어보는 것을 추천드립니다. 스펙에 대한 설명을 꼼꼼히 읽고 특히 각 문서의 마지막 부분에 추가된 Security 관련 attack 포인트와 이유를 이해하면 왜 스펙이 이런 형태로 설정되었는지 아하 모먼트를 느낄 수 있었습니다.

 

주요 RFC로는 아래 4가지가 있습니다:

 

Token

토큰과 관련해서는 간단한 uuid도 사용되지만, 여러 상황에서 스펙까지 정리된 다양한 토큰들이 존재합니다. 관련 스펙에서 여러 고려사항에 대한 설명과 같이 전반적인 토큰에 대한 개념도 이해할 수 있기에 일독을 권합니다:

  • JWS

https://datatracker.ietf.org/doc/html/rfc7515#section-5
https://datatracker.ietf.org/doc/html/rfc7515

  • JWE

https://datatracker.ietf.org/doc/html/rfc7516

 

  • JWT

https://datatracker.ietf.org/doc/html/rfc7519

 

 

Abuse

로그인과 관련해 다른 방향성으로 전개된 부분은 Abuse를 막는 것입니다. 문자 인증(SMS Pumping)으로 인해 비용이 과다 발생하여 문자 인증 요청 전에 Re-captcha를 추가하거나 특정 단위별로 문자 요청 throttle을 적용하는 형태, 문자 대신 다른 형태의 저비용의 인증(메신저, 유저가 문자를 보내도록 등)을 제공하는 방향 등이 고려되었습니다:

 

 

기타

OAuth의 구현과 관련해서는 Keycloak과 같은 오픈소스 도구들도 고려되었습니다. 간단한 사항에 대해서는 직접 구현하는 것이 어렵지 않기에 Security 팀의 보안 리뷰를 받아가며 직접 구현을 진행하게 되었습니다. 

 

OAuth의 인증과 인가에 더해서 추가적인 어떤 정보를 OAuth 클라이언트에 제공하려다보니 Open ID Connect, OIDC 와 같은 스펙들도 살펴보고 그 목적을 검토하며 참고하기도 하였습니다:

 

 

결제

초기 시점이라서 또는 블록체인 결제의 특성으로 인해 그런지 몰라도, 결제는 속도보다는 안정성과 추적 가능성을 위주로 보수적으로 개발이 진행된 것 같습니다. 

 

다양한 PG를 제공할 수 있도록 결제 시스템 자체의 아키텍쳐를 구성하고, Fiat과 Crypto 결제를 유사한 흐름으로 제공하기 위해 결제 상태 머신(CREATED, STARTED, APPROVED, FINALIZED, REFUND_STARTED, REFUNDED, CANCELED 등)을 디자인하는 사항들이 주요 쟁점이었습니다. 

 

구현에 있어서는, 다양한 결제 수단고 플로우가 추가되어가는 상황에서 기존의 아키텍쳐를 진화시키고 일관되고 정리된 아키텍쳐를 유지하는 어려움에 대해 많이 고민했습니다. 또한, 숫자에 이격이 발생하지 않도록 방어적으로 코딩하는 부분이 큰 이슈였네요. 

Fiat과 관련해서는 중심 결제수단인 신용카드의 기본적인 흐름 및 PG에 대한 이해가 필요하였고, Crypto와 관련해서는 스마트 컨트랙트를 사용해 안전하며 기존 결제 흐름과도 유사한 형태를 구성하기 위해 구조를 잡았습니다.

 

고려했으나 적용하지 못해서 아쉬움이 남았던 부분은, 회계 기록방법 그대로 DB를 관리하는 복식부기 형태의 방식이었습니다. 

 

정산

정산은 결제와 매우 분리된 형태로, 실시간 시스템과는 다르게 매우 보수적으로 '배치' 기반의 운영으로 구성되었습니다. 이는 과거의 11번가의 정산 경험과도 유사한데요. 정산이 되는 주기, 단위를 고려해 배치로 처리를 진행하고 각 단계마다 처리가 시작 또는 종료되는 시점에 다양한 validation 로직을 넣어 숫자가 틀리지 않도록 하는 것이 주요 핵심 사항이었습니다. 

 

결제는 특정 주기별로 모든 필요한 데이터를 정산으로 넘겨주기에, 정산에서는 실시간 데이터를 봐야하는 Admin 부분이 아니라면 넘겨 받은 데이터를 기반으로 독립적으로 배치를 수행하고 롤백할 수 있었습니다. 

 

기술

Kotlin & Spring In Microservice

Kotlin, Spring Webflux 그리고 Microservice에 익숙하지 않아 초반에 여러 책을 읽었습니다 (코틀린, 스프링 책 추천). 

 

주요 고려사항들

특히, 분산환경에서 트랜잭션을 관리하는 부분, 롤백을 적절히 처리하는 부분에 대해 많은 이슈가 발생하고 고민했었습니다.

 

다른 사항들로는 JVM Warmup과 여러 timeout에 대한 부분들입니다. Timeout과 같은 경우, 간헐적인 요청이 파악하기 어려운 이유로 실패하는 주요 원인이기도 하였기에 전반적인 call chain에서 꼼꼼하게 확인하였습니다:

 

* https://www.baeldung.com/spring-webflux-timeout

* https://projectreactor.io/docs/netty/release/api/reactor/netty/http/client/HttpClient.html#responseTimeout-java.time.Duration-

* keepalive: https://stackoverflow.com/questions/46614123/netty-client-takes-very-long-before-broken-network-is-detected

* netty : https://projectreactor.io/docs/netty/release/reference/index.html#_timeout_configuration

* response timeout vs read & write timeout:

    * https://stackoverflow.com/questions/64179173/netty-httpclient-response-timeout-vs-read-timeout#comment113504510_64182367

    * https://github.com/reactor/reactor-netty/issues/1159

* https://stackoverflow.com/questions/266281/best-practices-for-web-service-timeouts#:~:text=Your%20timeouts%20should%20be%20about,after%20two%20and%20before%20four.

* https://stackoverflow.com/a/4210173/8854614

 

 

개발도구

IntelliJ 기능은 해마다 발전해서 퇴사할 때쯤에는 Github copilot 기능을 On 하여 사용하였습니다. 기본적으로 Configuration을 git에 저장하여 팀 컨벤션을 맞추고, Cognitive Complexity 관련 플러그인을 사용하여 복잡도 관리를 하였네요.

 

개발환경

모니터링

기본적으로 devops가 주요하게 관리하는 운영형태로 제공해주는 DataDog, 로그 수집 서비스 등을 유용하게 사용하였습니다.

 

 

클라이언트

클라이언트 레벨로는 Mobile Web에서 App으로 확장되며 백엔드, 데이터 엔지니어 역할 관점에서 아래와 같은 사항을 고민했습니다:

 

 

블록체인

블록체인은 다양한 방식으로 깊이 들어가보려고 노력했으나, 비기너 이상으로는 진입을 아직 하지 못한 것 같습니다.

 

 

Storage

MySQL은 메인 DB로 전반적인 도메인 데이터 저장을 위해 사용하였습니다.

 

Redis는 세션 저장, 분산 락 등을 목적으로 코드의 주요 흐름에서 메인으로 사용하였습니다:

MongoDB는 알림 노티, OAuth의 내부 구현 등을 위해 ttl과 같이 서브 DB로 사용하였습니다.

 

 

AAR

 

Reference

(1) https://medium.com/@DOSI_official/2022%EB%85%84-dosi-%EB%B2%A0%ED%83%80-3%EA%B0%9C%EC%9B%94-%EA%B0%84%EC%9D%98-%EC%8B%A4%EC%A0%81-%EB%8F%8C%EC%95%84%EB%B3%B4%EA%B8%B0-72038ebb5d02

(2) https://medium.com/@DOSI_official/hellbound-%EC%9B%90%EC%9E%91%EC%9E%90-%EC%97%B0%EC%83%81%ED%98%B8-%EA%B0%90%EB%8F%85-%EC%B5%9C%EA%B7%9C%EC%84%9D-%EC%9E%91%EA%B0%80%EC%99%80-%ED%95%A8%EA%BB%98%ED%95%9C-ama-live-e381e36abc55

(3) https://linecorp.com/en/pr/news/en/2023/4502

(4) https://medium.com/@DOSI_official/dosi%EC%9D%98-citizen-%EB%A9%A4%EB%B2%84%EC%8B%AD%EC%9D%B4-%EC%98%A4%ED%94%88%EB%90%98%EC%97%88%EC%8A%B5%EB%8B%88%EB%8B%A4-cfdf5bab704c

(5) https://medium.com/@DOSI_official/link-%EC%9B%94%EB%A0%9B-dosi-vault-12%EC%9B%94-%EC%B6%9C%EC%8B%9C-%EC%98%88%EC%A0%95-ed48b3450e54

(6) https://medium.com/@DOSI_official/2024%EB%85%84-1%EC%9B%94-dosi-%EC%A0%95%EC%8B%9D-%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%B6%9C%EC%8B%9C-%EC%82%AC%EC%A0%84-%EC%95%88%EB%82%B4-c0c6eab31eb1

(7) https://www.blockchaingamer.biz/news/30451/klaytn-finschia-proposal-approval/

(8) https://engineering.linecorp.com/ko/teams/TPM

 

 

 

 

 

 

 

 

 

 

반응형
저작자표시 비영리 변경금지