와! 퇴원!

저번 글을 올리고 나서 1달하고 조금이 지난 10월 11일 나는 퇴원했다. ( 아싸 이제 놀러갈 수 있겠다고 생각했었죠 이 때는 ) 의사쌤은 제발 어디 싸돌아다니지 말고 집에서 얌전하게 얼음찜질하고 안전하게 있으라고 했고 꼬박 1달이 지나서야 걸을 수 있다고 해주셨다

바로 우아콘 지원 가보자

그렇게 며칠이 지났을 까 우아콘이라는 개발자 컨퍼런스에 지원할 수 있는 찬스가 생겨 바로 지원을 해보았고, 집에서 기다리다가 합격 문자를 받아서 서둘러 짐을 챙겨서 서울로 떠났습니다.
( 아침 지하철은 역시 지옥이었습니다.. )

전에 NHN 컨퍼런스 때 온 적이 있어서 나름 익숙해 있었다. 히히

우아콘 정리

오프닝 키 노트

각가지 트랙 소개 및 여러 분야에서 소개할 세션 소개

AI

현재는 배달과 ai 기술을 접목해 배달을 해주는 로봇도 만듬

프론트엔드

우아한형제들이 자체 제작해서 사용하고 있는 크롬 확장 프로그램 우아한 웹 툴킷, 여러 프론트 세션 소개

보안

보안은 잘하면 좋지만, 문제가 생기지 않는 이상은 모르는 일이다.

그래서 이런 위험, 보안수준을 가시화해서 관리하는게 중요함

조직 문화

협업, 소통, 성장, 문화 등 여러가지 기술 외에도 중요한 것이 있다.

오프닝 키 노트 2

2023년의 변화

• 배달 경험
  • 음식 배달 주문은 점심, 저녁, 이벤트 시간 때 주문이 집중되고, 1분에 8,000건 이상 주문이 발생할 수 있다.
  • 주문한 음식이 제시간에 도착할 수 있도록 다음과 같은 노력을 하고 있음
    • 배민1 한집배달 : 배달의 효율을 높이는 것이 굉장히 제한적이었음
    • 알뜰배달 : 데이터와 기술을 바탕으로 만들어진 배달 시스템, 여러 집을 묶어서 배달을 하다 보니 어려움이 있었음
      • 시간 예측의 문제
        • 알뜰 배달 같은 경우, 배달 예측 시간을 내기 어려움.
        • 딥 러닝 등을 이용해 해결하는 중
• 탐색 경험
  • 30만개 음식점, 1만개의 B마트 상품
    • 선택지가 너무 많다보니 상품을 선택하는 과정이 쉽지 않음
    • A/B 테스트를 통해 어떻게 해야 UX를 개선할 수 있는지 고민중
    • 사용자가 더 쉽고 빠르게 탐색할 수 있는 UX를 제공할 수 있도록 이어갈 예정
  • 추천 기능
    • 주문 내역과 같은 사용자 데이터를 기반으로 개인화 추천 개선
    • 추천 로직 뿐만 아닌, 추천을 제공하는 방식 또한 개선해나가는 중
    • 기존에 사용하던 머신 러닝 기술이 아닌, GPT(생성aI)를 사용해보기로 함
      • 앞으로도 다양한 추천 기능을 지속적으로 만들어나갈 예정
• 다양한 경험
  • 배민은 MAU 20,000,000 + 서비스이다
  • 다양한 상품을 배달주문 할 수 있는 배민 B 마트 이외에, 배민스토어를 열어서 전자제품, 오프라인 마트 등 여러 스토어를 열어서 여러 상품을 살 수 있도록 함
• 사장님 경험
  • 가게 운영에 필요한 소식을 놓치지 않게 장사 캘린더를 제공함
  • 가게 운영이나 메뉴 개발에 도움이 되도록 사용자 관리 데이터를 제공

세션 1 - 프론트엔드 개발의 미래, Module Federation의 적용

• 발표자 : 박세문 / 배민커머스웹프론트개발팀

마이크로 프론트엔드란?

웹 개발의 역사

• FE + BE = 웹 개발
• 위 사항에서 문제점이 발생
  • 배포를 하는 과정에서, FE가 배포를 하면 BE가 안되고, BE가 배포를 하면 FE가 안되는 상황이 발생
  • 결국, FE와 BE가 서로 나뉘게 되어서 개발을 진행함
• FE와 BE를 나눠서 웹 개발을 진행했으나 문제점이 여전히 있다
• 오랜 시간이 지나 고도화가 진행되고, 여러 기술들이 나왔다.
  • BE
    • Microservices: 하나의 커다란 서비스에서 여러 조그마한 서비스로 나뉘어서 개발을 진행한다.
      • 도커의 역할이 가장 컸던 것 같다
  • FE
    • 컴포넌트 도입 : 재사용성, 생산성, 퍼포먼스 면에서 월등히 높아져서, 고도화 된 프로덕트를 만들어냄
      • 프로덕트가 많아짐에 따라 복잡함이 커짐
        • 사이드 이펙트, 의존성 면에서 알아보기 많이 힘들었을거임
      • 그래서 생각해 낸것이 Microservices
    • Microservices를 도입
      • 각각의 서비스에 해당하는 백엔드 서비스에 프론트엔드를 각각 개발하여, 불필요한 의사소통을 줄이고 효율을 높임

왜 마이크로 프론트엔드를?

• 전시 영역 관리 어드민
  • 각각의 서비스에 어드민이 존재하고, 관리 측면에서 각각의 어드민에 접속
    • 단, 이 같은 로직에 경우, 서비스가 확장되었을 때 문제가 생김
      • N 개의 서비스가 추가될 경우 N개의 어드민이 추가되고, N개의 인증/인가 과정을 만들어야 함
  • 그래서 전시 영역을 하나의 프로덕트로 만들기 시작
    • 이렇게 만들었을 경우, Host Application 하나에서만 관리하면 되고, 부담이 보다 줄어둔다.
• 하지만, 마이크로 서비스를 도입했을 때 이점만 있을까?
  • 유지/보수 관점으로 봤을때는 이점도 있을 수 있다
  • 하지만, 마이크로 프론트엔드를 도입하기 위한 비용, 공부 측면에서는 독이 될 수도 있다.
  • 그리고 새롭게 발생되는 문제도 있다.
    • 여러개의 프론트엔드로 나뉘었을 때, 여러개의 프론트엔드간에 소통은 어떻게 할지..
      1. Props 도입
         1. 익숙하고, 허용 가능한 패턴이지만 커플링, 의존성, 리렌더링, 프레임워크를 통일하는 게 전제 조건이다.
      2. Storage API 이용
         1. 브라우저에서 제공하는 세션 스토리지 등을 이용한다.
         2. 보안에 취약하지만, 여러 브라우저에서 사용이 가능하고 의존성이 줄어든다.
      3. CustomEvent 이용
         1. addEventListiner를 이용해 커스텀 이벤트를 추가한다.
      4. Custom MessageBus 이용
         1. 커스텀 이벤트 방식과 유사하지만, 이벤트를 만드는 메시지 박스를 구조에 맞게 설계한다.
    • 프론트엔드의 상태 공유는?
• 무엇이든 하려 하면 들어가는 것 3가지
  • 설계
  • 시간
  • 비용

마이크로 프론트엔드 아키텍쳐 설계

• CSR, SSR 모두 렌더링 리엑트 컴포넌트 단계가 존재한다.
• 프로젝트 외부에 컴포넌트를 불러와서 렌더링을 진행한다면?
  • 이것이 바로 마이크로 프론트엔드에 개념의 시작이다.

Module Federation

• 웹 애플리케이션 개발에서의 코드 공유
  • 즉, 코드를 배포가 가능한 작은 모듈 단위로 분리하여 분리된 모듈을 동적으로 로드한다.
  • 두가지 옵션이 존재
    • export option
      • 특정 모듈을 다른 애플리케이션에 노출
    • remote option
      • 특정 모듈을 다른 애플리케이션에서 로드
• 장점
  • 유연성의 향상
    • 애플리케이션을 작고 관리하기 쉬운 모듈로 분할
  • 확장성 향상
    • 개별 애플리케이션의 크기와 복잡성 감소
    • 유지관리 및 확장의 용이
  • 현업 향상
• 단점
  • 복잡성 증가
    • dependency, versioning 관리가 필요
    • 개발하고 운영하는데 난이도가 높다
  • 보안 위협
    • 애플리케이션 강 코드 공유 시 취약점 발생 가능
    • 이에 따른 보안 조치 필요
  • 성능 감소
• Nest.js는 다이나믹 임포트를 이용해 사용하게 될것
• Module Federation을 이용해서 어떤 프레임워크에 의존성을 가지지 않고, 모듈을 들고와서 임포트를 시켜준다.

도입하며 겪었던 문제점 & 해결 방법

• Typescript 지원 문제
  • Remote module을 가져오는 데 있어서 JS에는 타입이 없다.
  • 이것과 관련되어서는 이미 깃허브에 이슈가 있었다.
  • 해결 : 패키지를 사용하자.
    • federation type 관련된 패키지를 제공함. (module-federation/typescript)
    • 하지만, 프로젝트를 한번 실행시켜줘야 된다는 이상한 과정이 들어가 있음
  • 또 문제 발생 : 단뱡향만 타입을 지원한다.
    • Host는 타입 다운로드만, Remote는 타입 제공만 가능하다.
  • 두번째 해결 방법 : NativeFeferationTypeScriptHost, NativeFeferationTypeScriptRemote 라이브러리 사용
    • 이상하긴 하지만, 없는것보다는 낫지 않나 쉽다
• 의존성 비동기 문제
  • 우리가 가져오고자 하는 모듈이 임포트가 되고 그 다음에 랜더링이 되어야 하는데 먼저 랜더링이 되어버려서 발생하는 문제
  • 해결 : shared 옵션을 넣어서 해결
    • 이런 방식은 Shell ( Host ) 에서만 제공하는 것을 추천
  • Next.js 해결 : Next.js 같은 경우는 NextFederatedPlugin을 지원해서 해결했다.
• Unstable ( 안정성 부족 )
  • 빈번한 버전 업데이트
    • 며칠 지나거나, 개발을 하고 있는 도중에도 버전이 빈번하게 바뀐다.
    • 빠르게 발전하는 걸 보여주는 건 괜찮지만, 개발하는 입장에서는 좀..
  • 레퍼런스 부족

도입 이후 얻은 것 & 잃은 것

• 얻은 것
  • 프로덕트 공통화
  • 확장의 부담 감소
  • 예측 가능한 리스크 범위
• 잃은 것
  • 프로덕트의 단순함

앞으로 시도해 보고 싶은 것

• Remote Application Generator
  • 나의 편리함 = 상대방의 불편함
  • 그래서 템플릿을 제공해보자!
  • 프로젝트 템프릿, CLI command를 이용한 generator 구현
  • 배포 파이프라인 구축
• Dynamic remotes
  • 외부의 환경 변수 혹은 리모트 정보를 받아와서 Promise 기반의 처리 방식을 고민중

정리

• 마이크로 프론트엔드 도입으로 의존성은 분리했지만, 구성의 어려움은 존재, 아직 많이 개선할 부분이 남아 있음 ㅇㅇ

세션 2. 프론트엔드 모킹 환경에 감칠맛 더하기

• 발표자 : 류현승 / 코어웹프론트개발팀

우리에게 API 모킹 환경이 필요한 이유?

• 우리가 생각하는 이상적인 개발 일정
  • 기획/스펙 검토 → API 서버 개발 → 프론트엔드 개발 → QA
• 하지만 언제나 이상적인 개발 일정은 아니다.
  • 만약, API 모킹이 없다면?
    • 기획/스펙 검토 → 프론트엔드 개발과 동시에 API 서버 개발이 진행되고 API 서버 개발이 지연이 되는 경우 코드가 프리징이 있을 수 있다.
  • 다행히도 우리에게는 API 모킹이 있다
    1. 서버의 의존성을 줄일 수 있다.
       1. API 스펙을 가진 것만으로 개발이 시작될 수 있다.
    2. API 스펙 사전 검증
       1. 문제점을 사전에 발견할 수 있다.
    3. 독립적인 테스트
       1. 유연한 테스트가 가능하다.
       2. 실제 API가 없어도 테스트가 가능하다.
• 요약, 우리는 API 스펙만 있어도 API 모킹을 사용해 테스트가 가능하다.

코어 웹프론트 개발팀

• 기능 조직
  • 주문, 접수, 회원, 앱 등 여러 도메인을 담당하는 팀
  • 협업이 중요한 팀이고, API 도메인, 스펙 등이 분산되어 있음
    • 이때문에 간단한 작업에도 오래 걸리고, 신입 개발자가 와도 진입장벽이 높다는 문제점이 있다.
  • 배포에 큰 부담감이 있음
    • 팀 내부적으로 테스트 중요성에 대해 강조하고 있는 상황
• 이 때문에..
  • 높은 테스트 커버리지 요구
  • 다양한 테스트 기법 도입
  • API 호출 케이스가 증가

API 모킹 환경 되돌아보기

• 사실, 모킹 환경은 이미 도입되어 있었고, 모킹 데이터와 케이스가 준비되어 있었음
• 개선 전
  • Axios를 이용해 모킹을 진행했었다.
    • Axios에 종속된 의존성
    • 외부 라이브러리나 Axios를 활용하지 않는 API 모킹이 불가능하다.
    • 네트워크 요청을 브라우저를 통한 트랙킹 불가능
• 개선 후
  • Mock Service Worker
    • 직관적이고, 단순한 인터페이스
    • Axios와 같은 라이브러리를 거치지 않고 여러 라이브러리의 모킹 테스트가 가능해짐
    • 노드 환경을 사용하는 서비스에서도 모킹이 가능
    • 또한, 브라우저에서 네트워크 요청을 빠르게 트래킹이 가능하다.
  • MSW는 충분히 좋은 라이브러리지만, 모든 것을 해결해주지는 않았다.
    • 실제 프론트엔드를 개발했을 때를 생각해봤을 떄
      • 결국, 개발자 또한 브라우저를 통해 보는 것이 현실이다.
      • 그리고 모킹이 필요한 이유를 다시 생각해보면 API 스펙 협의 만으로 시작 가능한 병렬 개발도 있었다.
        1. 모킹 동작을 수정해야 하는 경우, 필연적으로 코드 레벨 제어가 필요하다.
        2. 갈수록 늘어나는 Mock Data 관리 부담감이 증가한다.

API 모킹 환경에 감칠맛 더하기.

• 우선, 브라우저와 MSW 사이에 중간다리 역할이 필요하다.
  • 그래서 자체개발한 라이브러리가 Mock Service GUI
  • 이것이 무엇을 해결하는 부분들?
    • API 단위로 Mock data를 1:n 맵핑할 수 있는 프리셋 기능
      • UI에서 즉시 확인 가능
    • 브라우저에서 코드 변경 없이 모킹 환경을 제어할 수 있다.
    • Mock Data 관리 부담을 완화했다.
  • 현실적인 사용 케이스 관점에서 바라보기
    • 장바구니에는 여러 장바구니가 존재할 수 있다.
    • 어떤 상황에, 어떤 API를 사용하는지는 거리감이 존재한다.
    • 그래서 나온 것이 “프로파일” 기능
      • 문서화로서의 효과도 올라가고, 파악이 용이하다.
• 하지만.. 목 데이터의 관리 부담을 줄이는 방법은 없을까?
  • API 스펙이 변경되었다면 과제 진행 중 업데이트를 놓친다면?
    • 응답 값을 체크해보면 어떨까?
  • 이를 이용하여 비교기능을 통해 달라진 부분을 띄워준다.
• 불편한 점 해소
  • 개인 설정과 API 모킹 설정은 브라우저에 저장하여, 각 개발 상황에 맞는 모킹 설정, 환경을 제공
• 테스트 코드에서의 API 모킹 제어
  • 타입 스크립트를 도입해 제네릭 제어 조건을 설정하여 문자열 리터럴 타입을 추출하고, 동적으로 처리할 수 있도록 구현했다.

앞으로 할 일들

• 이미 스웨거로 문서화를 잘하고계신답니다.. 굳굳
• 목 데이터 작성 = 같은 일을 반복하는 것
  • 스웨거를 OAS로 변환하여 볼 수 있도록 구현
• 기획자분이나, 서버 개발자와의 협업 개선
  • 프로파일 기능을 통해 해당 프로젝트에 존재하는 상황을 정의
  • 프리셋 비교 기능을 통한 API 상황 별 비교하여 띄워주는중
• 이미 베타 환경에서 배포중!

우리가 얻은 것

• 전달하고자 하는 메시지
  • 우리는 개발자로써 단순히 코드를 작성하는 것 뿐만 아닌 고객분들께 더 나은 서비스를 제공하는 것!

점심시간

이렇게 마치고 점심시간이 되니 무슨 이벤트같은 걸 한다길래 바로 가서 확인해보았다 인재 POOL에 가입하면 뽑기를 해서 경품을 준다고 해서 참여하고 경품을 뽑았더니 개발자 세트가 뽑혔다. 안에는 블루투스 키보드, 거치대 겸 무선 충전기( 무선..인가? ), 캐리어 모양 작은 가방, 노트북 거치대가 들어가있었다. ( 아싸 노트북 거치대 개꿀 )

돌아옴

그렇게 위 2개 발표를 듣고 점심을 먹은 뒤 다시 돌아왔다. 생각보다 오고가는 시간이 오래 걸려서 2개밖에 못들었지만 시간만 됬다면 다 듣고 왔을 것이다.

비하인드

??? : 시간과 예산이 더 있었더라며어어어언
시간이 부족해서 결국 2개만 듣고 나왔다. 이후에 다른 일정도 있었어서 쥬륵
만약 시간이 된다고 하면 프론트엔드와 관련된 세션을 다 듣고 여우롭게 나왔을 것이다..
아무튼 우아콘 후기는 여기까지다. 앞으로는 더뎌진 코딩 실력을 다시 세워야겠다 허허..

다시 한번 말하지만 여러분들 발 밑은 꼭 보고 다니세요 안그러면 저처럼..