Development/DevLife

[인프콘 2022후기] 인프런 아키텍처의 과거와 현재, 그리고 미래

📝 작성 : 2022.08.27  ⏱ 수정 : 
반응형

전체적인 INFCON2022에 대한 후기는 INFCON 2022 후기 글을 참고 해 주세요.

IMG_8169 Medium

개인 코멘트

인프랩의 CTO를 맡고 계신 향로님의 발표 입니다.

오프닝에서는 인프랩의 CTO 로서 스피킹을 했다면, 이번에는 한명의 개발자로서 말씀을 해 주셨는데요, 지난 몇 년간 인프랩이 성장해나가는 과정 속에서 쌓였던 기술 부채와 고민들, 그리고 그걸 해결해 나가는 과정에 대해 재밌게 이야기를 풀어 주셨습니다.

우아한형제들에서 자바,스프링으로 개발을 하다가 Node.js 로 개발을 하고 있는 인프랩에 CTO로 이직을 했다 보니 주변에서 JVM 기반으로 싹 갈아 엎을 거 아니냐는 이야기를 정말 많이 들으셨을 텐데 지금껏 정말 많은 고민이 있었고, 지금도 많은 고민을 해 나가는 과정이라는 걸 느낄 수 있었습니다.

시즌1

적정이란 무엇인가. 물길을 건너는 목표를 이루기 위해 방법은 여러가지가 있겠지만 적정에는 제약조건이 있다.

돈과 동료가 없는데 물길을 건너야 한다면? 헤엄쳐서 건너는 수 밖에. CEO 혼자서 모든걸 해내야 했던 시즌 1.

  • 직접 개발을 최소화 하며 외부 지원을 최대한 활용
  • PHP, jQuery, 워드프레스, MySQL 호스팅 서버 1대
  • 회원수 10만까지는 어떻게 버텼지만 이후 느려지는 서비스와 의도를 알 수 없는 데이터, 워드프레스로 인한 기능 확장의 한계 및 직접 관리해야 하는 서버 배포등으로 한계.

시즌2

구현 코드의 최소화, 단일화된 라이브러리, 익숙한 패턴, 단일 프로젝트. 5개월만에 워드프레스에서 Node.js로 교체

  • BE1, FE1, Devops1, CEO

  • 한명이라도 빠지면 전체 개발이 멈추는 리스크. 그 리스크를 관리하기 위해 기술스택을 최대한 통일하자 -> js

  • 낮은 러닝 커브 (FxSQL, FxDom)

  • 최소 관리 (CircleCI, AWS Fargate)

  • 이로 인해 신규개발자들을 채용하면서 문제들이 발생함. 구현코드의 최소화로 인해 type이 없고 객체 리터럴만 있으며 테스트 코드가 없다.

  • 예측 할 수 없는 함수의 결과와, 단일화된 라이브러리에 레퍼런스가 턱없이 부족하다보니 신입 개발자들을 위해서는 익숙하지 않은 구조

  • FE+BE 단일 프로젝트로 구성되어 있어 첫 실행에 2분이 걸리고 로컬 리로드에 20초가 걸리는 엄청난 비효율

높아진 진입장벽과 낮아진 심리적 안정감을 해결 해야 할 필요

시즌3

  • BE3, FE3, DevOps1, 자바와 스프링만 알던 CTO
  • class, type, 테스트코드, 정적 분석을 통해 심리적 안정감 증대
  • ts, react, next.js, nest.js, typeorm, id, 테라폼 등을 통해 낮은 진입장벽 해결
  • FE/ BE 계층 분리 및 API 명세 기반으로 독립성 구축

어떻게 전환할 것인가에 대한 고민이 생김. 빅뱅으로 한번에 1년만에 VS 2년에 걸쳐 점진적인 개편

스타트업에서 6개월간을 멈춘다는건 일반기업에겐 2년 이상의 시간을 의미하고, 팀원들에게 매년 2~3배 성장하는 서비스를 중단없이 개편하는 경험을 선물하고 싶었음.

  • 이제 하나씩 옮기면 되는데.. 장애 발생
  • 심지어 한 기능의 장애가 여기저기 퍼지는 상황

시즌4

  • BE8, FE11, DevOps, 이제는 JS/TS도 아는 CTO

  • 시즌3가 완료가 되지 않았음에도 시즌4로 떠밀릴 수 밖에 없는 상황

  • 독립적으로 운영하는 서비스들을 다 분리해서 장애격리라는 목표를 달성하자

  • DB 장애 격리는 지금 못해.. (분산 DB로 높아지는 복잡도, 트랜잭션 관리의 어려움, 기존 쿼리의 전체 개편) 시즌5로 throw

  • 쌓여가는 비즈니스 요구사항 ( 검색엔진 도입, 전체회원 알림 서비스 등등..)

모법 답안으로 가는 길은 사실상 불가능하니, 기술의 가지수를 최소화 하고 향후 2~3년은 버틸 수 있는 기술스택을 선택하자 -> MongoDB Atlas (NoSQL, Nori형태소 분석기 지원으로 검색엔진 가능)

Node -> AWS SNS 이벤트 발행 -> AWS SQS 이벤트 구독 -> Spring Boot key에 담긴 메세지 구독 -> key로 API에서 최신 데이터 조회

  • Node -> SNS가 실패 하면 중간에 이벤트 저장소를 두면 해결 되지만 아키텍처의 복잡도가 너무 높아지기 때문에 에러로그 발생시 알람을 받아 수동으로 해결하기. 검색엔진이라는 추가 의존성이 생겼지만 격리

최종적으로는 (신) FE <-> (구) 인프런 single repo <-> (신) BE <-> 검색 엔진

대충 이라도 일단 만들고 차근차근 해선하자. 가장 중요한건 완벽 한 것 보다 고객의 요구사항 변경에 대응 할 수 있는 것.

질문답변시간

이어서 질문 답변 시간이 있었는데요, 이번 컨퍼런스에서 전체적으로 느끼는 건데 질문하는 분들의 질문과 답변의 수준이 매우 높다 보니 저는 질문을 할 엄두가 전혀 나지 않더라고요. 그래도 개인적으로 궁금한게 있는 분들은 여러가지 창구를 통해 질문을 하시면 답변을 받을 수 있지 않을까 생각됩니다.

질문: 전체적으로 테스트를 다 짜서 이관했나요?

답변: Unit test + Api endpoint test. 트랜잭션의 경우에는 DB 계정명을 다르게 해서 커넥션풀을 서로 다르게 가져가게 한 뒤 모니터링

한 질문자분은 파이썬으로 짠 레거시 코드를 자바 스프링으로 이관하고 하셨는데 괴로운 그 과정이 공감되었는지 동욱님이 아주 좋아하셨습니다.

반응형
1 2 3 4 5 6 7 8 ··· 14