devFancy BE Developer

2024 당근 테크 밋업 - 메모 및 후기 (SERVER)

2024-11-24
devFancy
Technology

2024 당근 테크 밋업 중 SERVER 파트에서 관심있는 세션들을 들으면서 인상 깊었던 부분들과 개인 생각을 간단히 메모하고자 이 글을 작성했습니다.

실제 세션 내용은 2024 당근 테크 밋업 에서 발표한 영상을 참고해 주시면 됩니다.

빠르게 변화하는 운영 도메인에서 살아남는 코드 만들기

부제목: 확장성과 설정 가능성

발표자: Julius (당근 - 운영개발팀 고객경험파트)

반복되는 비슷한 코드 작업에 지치신 분, 더 효율적이고 생산적으로 일하고 싶은 모든 개발자에게 이 세션이 인사이트를 제공할 수 있길 기대합니다.

세션에 대한 메모

  • 운영개발팀이란?

    • 안전하고 도움받기 쉬운 당근 서비스를 만드는 것을 목표로 한다.

    • 신고 & 문의 화면을 담당하며, 당근 서비스를 이용 중 악성 사용자를 신고하거나 문의를 남기고자 하는 상황을 지원한다.

    • 이러한 신고 및 문의를 처리하는 내부 어드민 도구와 처리 과정을 자동화 한다.

  • 빠르게 변하는 운영 환경 (강산이 1년마다 변한다)

    • 당근은 중고거래를 시작으로, 현재는 비즈프로필, 알바, 중고차, 부동산 등 다양한 지역 기반 서비스로 확장하고 있다.

    • 목표: 새로운 서비스도 안전하고 도움받기 쉬운 환경을 제공하는 것이다.

    • 빠르게 대응하기 위해 필요한 것

      • 기존 기능을 새로운 서비스에 쉽게 확장할 수 있어야 한다.

      • 기존 서비스 변경에 신속히 대응해야 한다.

      • 실시간으로 발생하는 운영 이슈에도 빠르게 대처해야 한다.

  • 확장성과 설정 가능성 (from ChatGPT )

    • 확장성: 새로운 기능을 추가하거나 기존 기능을 수정시 최소한의 변경, 사이드 이펙트로 대응할 수 있는 능력이다.

    • 설정 가능성: 시스템이 코드 수정 없이 외부 설정만으로 다양한 동작을 조정하고 관리할 수 있는 능력이다.

  • 새로운 서비스가 출시될 때 개발자는 아래와 같이 세 가지 단계로 작업을 하게 된다.

    • [1] 외부 서버에 데이터 요청 코드 작성 (ex. 중고거래 서버, 비즈프로필 서버, 알바 서버, 중고차 서버, 부동산 서버 등)

    • [2] 데이터 가공 로직 작성 (ex. 운영 시스템 서버)

    • [3] 화면에 표시하기 위한 뷰 작성 (ex. 문의 처리 화면)

문제 상황

  • 문제 상황: 여러 서비스가 계속해서 출시되고, 문의 처리 화면에서 표시되는 정보가 많아지고 코드 복잡도가 증가한다.

    • API 메서드 길이가 200줄을 넘고 디버깅 및 유지보수가 어려워진다.

    • 코드를 추가하거나 수정할 위치를 찾기 어렵고, 응답 시간이 길어지면서 성능이 저하된다.

해결 방안 1단계: 서비스별 API 분리

  • API를 개선하고 확장성을 확보하기 위해 기존의 거대한 API를 각 서비스에 맞는 API로 분리한다.

    • 사용자 정보 조회 -> 중고거래 정보 조회, 비즈프로필 정보 조회, 광고 정보 조회

    • 각 서비스 별로 정보를 조회하기 위한 API를 만든다. -> 200줄이 넘는 메서드를 읽어보지 않고 특정 서비스의 변경이 필요할 때, 해당 서비스의 API만 확인하면 된다.

    • 성능 측면에서 보면 여러 서비스의 사용자 정보를 병렬로 로드하거나 필요한 정보만 로드할 수 있도록 만들 수 있다.

    • 하지만 각 서비스 정보 조회 API를 보면, 여전히 너무 많은 코드가 API 메서드 1개에 작동되고 있다.

해결 방안 2단계: 역할 기반 분리

  • 각 서비스별로 사용자 정보 조회 API 내부에서 역할 에 따라 분리한다.

    • 사용자 정보 조회를 두 가지 작업으로 나눌 수 있다. (ex. 비즈프로필)

    • [1] 각 서비스 서버에 필요한 데이터를 요청한다. -> 데이터 요청 (ex. BizProfileClient)

    • [2] 전달받은 데이터를 화면에 표시하기 위한 형태로 가공한다. -> 데이터 가공 (ex. BizProfilePresenter)

    • 각 서비스 별로 사용자 정보 조회 에서 역할이 분리된 각 클래스를 볼 수 있다.

    • 역할이 분리하고 난 뒤에 다른 서비스에 있는 사용자 정보 조회 를 봤더니, 결국에는 모든 API가 비슷한 형태로 된 것을 확인할 수 있다.

해결 방안 3단계: 서비스별 API 통합

  • 분리되어 있던 각 서비스별 사용자 정보 조회 API를 하나의 API로 통합하기로 한다. (API 형태가 비슷하기 때문)

    • 구조가 비슷한 API를 통합하고 파라미터 기반 동작으로 전환한다.

    • 하나의 API에서 서비스 이름을 파라미터로 받아 적합한 Client 와 Presenter 를 선택하도록 설계한다.

    • 하지만 이는 서비스가 추가될 때마다 이 분기문 길이가 길어지면서 다시 코드가 복잡해지는 문제가 발생한다.

해결 방안 4단계: 메타 프로그래밍 도입

  • 위의 문제를 해결하기 위해 메타 프로그래밍 기법을 도입한다.

    • 메타 프로그래밍 이란 코드 자체를 데이터로 보고 실행 중에 동적으로 변경시킬 수 있도록 하는 기법을 의미한다.

    • 여러 언어(JavaScript, Java, C++ 등)에서도 이 메타 프로그래밍 을 쓸 수 있다.

    • 정리하면, 초기에 문제가 되었던 200줄이 넘는 코드와 평균 응답 시간이 2초(2000ms)가 걸렸고, 한 메서드 안에서 여러 서비스에 대한 사용자 정보를 순서대로 요청하고 응답받는 구조이다.

    • 이로 인해, 서비스가 늘어나면 자연스럽게 응답 시간도 늘어나는 상태이다.

    • 그래서 서비스별로 분리하고 메타 프로그래밍을 적용한 코드와 같이 필요한 서비스의 Client 와 Presenter 클래스만 작성한다.

    • 변경이 필요한 시점에도 해당 역할을 하는 클래스만 찾아가면 변경할 수 있을 정도로 모든 코드를 읽어보지 않아도 된다.

    • 한 번에 API를 호출해서 하나의 서비스 정보만 조회하도록 분리하면서 평균 응답 속도를 0.2초(200ms) 로 단축했다.

    • 새로운 서비스를 추가하더라도 한 번 API 호출 할 때 하나의 서비스 정보만 불러오기 때문에, 응답 시간에는 영향을 미치지 않는다. 이는 확장성의 의미인 최소한의 사이드 이펙트 로 새로운 기능을 추가할 수 있는 상태가 되었다.

  • 규칙 기반 UI 생성

    • UI 구성 요소를 보면 섹션 제목, 레이블, 값과 링크 로 구성된다. -> 이러한 구조는 서비스마다 비슷한 형태의 JSON 데이터로 표현 가능하다. -> 규칙을 만들고, 정해진 규칙에 따라 가공된 데이터를 기반으로 UI 생성 로직을 만든다.

    • 처리 순서: [1] 규칙에 따라 가공된 데이터 -> [2] 규칙 기반 UI 생성 로직 -> [3] UI

  • 다시 살펴보는 개발자의 할 일 변화 (전 -> 후)

    • [1] 외부 서버에 데이터 요청 코드 작성 -> Client 추가

    • [2] 데이터 가공 로직 작성 -> Presenter 추가

    • [3] 화면에 표시하기 위한 뷰 작성 -> 규칙 기반 UI 생성 로직으로 자동화

  • 확장성의 열쇠

    • 최소한의 변경 -> 분리, 중복 제거, 가독성, 자동화

  • 설정 가능성이 필요한 경우 -> 자세한 예시는 1,800만명이 쓰는 서비스 운영하기 영상을 참고한다.

    • 동작 변경이 빈번한 경우

    • 민감 이슈로 빠른 대응이 필요한 경우

    • 외부 서비스와 연관도가 높은 경우

    • 테스트 목적으로 일시적 변경이 필요한 경우

  • 약속을 공유하는 방법

    • 규칙 기반의 UI 생성 로직 처럼 약속들을 모두에게 공유하는 것이 중요하다.

    • 문서 보다는 코드 안에서 주석을 추가한다. (-> TMI. 읽기 쉬운 코드는 그 자체로 문서로 일부 긍정적인 예외 케이스를 제외하고는 주석 사용을 지양한다)

    • 주석을 작성하는 곳은 개발자가 작업하는 동안 자연스럽게 볼 수 있는 곳이어야 한다.

세션에 대한 리뷰

  • 해당 세션은 빠르게 변화하는 서비스 환경에서 코드의 확장성과 유지보수성을 높이는 설계 전략을 다룬 점에서 매우 유익했다.

  • 예전에는 당근은 중고거래 서비스를 중심으로 운영되었다면, 이제는 비즈프로필, 알바, 중고차, 부동산 등 다양한 서비스가 추가되면서 복잡한 운영 도메인을 관리해야 하는 상황이 되었다.

  • 발표에서는 새로운 서비스 코드를 적용하는 과정에서 발생할 수 있는 문제를 구체적으로 설명하고, 이를 해결하는 과정을 처음 도메인을 접한 사람도 이해할 수 있도록 간단하고 명확하게 전달해 주셔서 인상 깊었다.

  • 특히, 새로운 서비스 추가 시 필요한 정보만 가져오도록 설계하고, 이를 코드로 구현하는 과정을 통해 효율적이고 확장 가능한 시스템을 설계하는 방식에 대한 인사이트를 얻을 수 있었다.

  • 데이터를 요청하는 코드를 Client 클래스로, 데이터를 가공하는 코드를 Presenter 클래스로 분리하여 역할과 책임을 명확히 하는 과정이 인상적이었다.

  • 또한, 처음 들어본 메타 프로그래밍은 실행 중에 동적으로 동작을 변경할 수 있는 기법으로, 복잡한 로직에서 단순화와 확장성을 모두 잡을 수 있는 가능성을 보여줘서 신기했다.

당근알바 초기 엔지니어링 전략: 빠르게, 빠르게, 더 빠르게

부제목: 빠르게, 빠르게, 더 빠르게

발표자: Mark (당근 - 당근알바팀)

새로운 제품이 겪는 Cold Start 문제를 해결하는 과정에서 어떤 엔지니어링을 했는지, 생산성과 사용자에게 전달된 가치 측면에서 소개합니다. 또한 초기 엔지니어링 전략이 팀과 제품에 어떠한 영향을 미쳤는지 공유합니다.

세션에 대한 메모

  • 당근알바란 ?

    • 동네, 근거리를 핵심 가치로 일손과 일자리가 필요한 이웃을 연결하는 서비스

  • 초기에 제품을 빠르게 만드는 것이 초기 사용자에게 더 많은 가치를 전달해주는 것이라 생각했다.

  • 이러한 제품에 대해 빠르게 만들기 라는 미션을 달성하기 위해 제품의 생산성을 고민하게 되었다.

빠르게 데이터 분석하기

  • 데이터 분석은 사용자의 피드백을 가장 빠르게 얻을 수 있는 수단이다.

  • 가설 -> 실험 -> 검증의 루프를 돌면서 빠른 의사결정에 도움을 준다.

  • 하지만 제품 구현 이외에 데이터 분석에 필요한 추가적인 엔지니링으로 인해 산성이 저하되는 문제가 발생했다.

  • 이러한 문제를 해결하기 위해 두 가지로 나눠서 보기로 했다.

    • [1] 데이터 분석에 드는 비용 -> (1) 데이터 분석을 위한 엔지니어링 비용, (2) 데이터 분석 활동에 드는 비용 -> 이러한 비용 문제를 해결하기 위해 이벤트 기반 분석 서비스를 활용했다.

      • 데이터 분석을 위한 별도의 저장 공간이 필요 없다.

      • 원하는 시점에 API를 호출함으로써 간편하게 데이터를 저장한다.

      • SQL이 아닌 웹에서 직관적으로 데이터를 조합한다.

      • 데이터 분석 결과를 간편하게 시각화한다.

      • 데이터 분석 도구: Amplitude, Mixpanel

    • [2] 데이터 분석으로 부터 얻는 생산성

      • 사용자 피드백을 빠르게 확인하여 가설과 실험에 대한 의사결정 비용 감소

      • 데이터 분석 결과를 통해 사용자에 대한 이해를 바탕으로 팀 구성원 간 효율적인 의사소통

필요한 것만 구현하기

  • 실험 목적 달성에 필요한 만큼만 구현하고, 실험 결과에 따라 추가로 구현한다.

  • 현재 가용 가능한 엔지니어링 리소스를 최대한 효율적으로 활용하기 위해 현재에 필요한 기능만 구현한다.

효율적으로 에러 대응하기

  • 에러 대응에 드는 비용을 두 가지라고 생각한다.

    • [1] 현재 하고 있던 작업에서 에러를 대응하기 위한 컨텍스트 전환 비용 -> 컨트롤 할 수 있는 영역 -> 원인 파악 후 수정

    • [2] 에러 대응에 걸리는 시간 -> 컨트롤 할 수 없는 영역

  • 에러 대응 프로세스를 다음과 같이 진행한다.

    • (에러 리포트를 받으면) 하고 있던 작업을 멈추고

    • 발생 빈도와 당근알바의 핵심 기능에 미치는 영향을 먼저 확인한다.

    • 발생 빈도가 높지 않거나 핵심 기능에 미치는 영향이 적다면 바로 대응하지 않고 모니터링을 걸어둔 채, 현재 하고 있던 작업을 빠르게 마치도록 한다.

    • 반대로, 발생 빈도가 높거나 핵심 기능에 미치는 영향이 크다면 빠르게 원인 파악을 들어가고, 현재 작업과 에러에 대한 대응하는 두 가지 중 사용자에게 더 큰 가치를 전달하는 것인지를 고민하고

    • 그 과정에서 현재 작업을 완료하는 것이 더 중요하다면, 현재 작업을 완료하고 에러를 대응하기로 한다.

  • 이 에러 대응 프로세스에서 가장 중요했던 지점은 이 에러가 어떠한 양상으로 서비스에 영향을 미치는지 파악하는 것이다.

    • 그래서 이 부분에 대한 가시성을 최대한 많이 확보하기 위해 Sentry, Grafana, Datadog, Apollo Studio 등 모니터링 툴을 활용한다.

    • 그리고 서비스 로그를 최대한 활용해서 현재 서비스의 상태를 빠르게 파악한다.

  • 우리에게 중요한 것은 제품의 퀄리티가 아닌, 현재 작업에 집중하는 것이다.

    • 제품을 빠르게 만들어서 제품의 가치를 사용자에게 인정 받고 시장에 성공해서 안정적인 궤도로 오르는 것이 중요하다.

클라이언트와 효율적으로 협업하기

  • 서버와 클라이언트는 서로간의 관점 부분에 있어 차이가 있다.

    • 서버 - 다양한 환경에서 사용될 수 있도록 목적에 맞는 데이터를 반환한다.

    • 클라이언트 - 네트워크 비용, 사용자 경험 등을 위해 한 번에 관련 데이터를 가져온다.

  • 이 논의에서 핵심은 응답의 데이터 구조가 정해져 있다는 것 이다.

    • 응답의 데이터 구조가 정해져 있기 때문에, 응답의 데이터 구조를 바꾸기 위해 서버와 클라이언트가 지속적으로 의논한다.

    • 해결책은 응답의 데이터 구조를 유연하게 가져가는 것 이다.

  • 따라서 제품의 서버와 클라이언트가 데이터를 유연하게 가져가기 위해 GraphQL를 도입했다.

    • 클라이언트에게 데이터를 가져오는 것에 대한 책임을 맡김으로써 서버와 클라이언트 간 논의가 불필요하게 되었고,

    • 클라이언트는 더욱 능동적으로 화면 구성 변경에 대응할 수 있게 되었다.

세션에 대한 리뷰

  • 해당 세션을 들으면서 ‘효율적으로 에러 대응하기’ 부분에서 기존에 내가 하는 작업 방식과는 전혀 다른 접근법을 접하면서 큰 충격을 받았다.

  • 특히, Mark 님이 당근알바팀에서 처음으로 “가장 중요한 것에 집중하고, 덜 중요한 것은 잠시 미뤄두는” 경험을 하셨다는 이야기가 인상 깊었다.

  • Mark 님도 처음에는 에러 대응을 바로 하지 않고 우선순위를 설정하는 과정이 낯설고 찜찜했지만, 결과적으로 제품을 빠르게 개선하며 사용자 만족도를 높이는 데 성공했다는 점을 말씀하시면서 그 부분이 나에게 많은 깨달음을 줬다.

  • 나 또한 에러가 발생하면 무조건 우선적으로 해결해야 한다는 강박에 사로잡혀 있었다.

  • 해당 세션을 들으면서, 현재 하고 있던 작업이 에러를 대응하는 작업, 둘 중 누가 더 사용자에게 더 큰 가치를 전달하는 것인지를 고민하고 그 과정에서 현재의 작업이 더 중요하다면 현재의 작업에 집중하기로 해야겠다고 생각의 전환을 하게 되었다.

  • 이 세션을 통해, 에러 대응과 현재 작업 중 어느 쪽이 더 사용자에게 가치를 제공하는지를 고민하고, 필요하다면 현재 작업에 집중하는 선택이 중요하다는 점을 배웠다.

  • 또한, GraphQL 을 도입해 서버와 클라이언트 간 협업을 효율화한 사례를 보면서, 기술적 관심이 생겼다.

  • 이 기술을 학습해 현재 회사에서 적용 가능한 상황을 탐색해보고 싶다는 생각이 들었다.

Review

  • 두 세션만 들었지만, 현재 내 상황에 적합하고 실질적으로 도움이 되는 내용이 많았다.

  • 이러한 유익한 세션을 당근 회사가 유튜브에 무료로 제공해준 것에 정말 감사했다.

  • 앞으로 기회가 된다면 실무나 개인 프로젝트에서 이 기술들을 활용해보고, 이를 통해 깊은 이해와 사고력을 키우고 싶다.

  • 최근에 현 회사에서 깊은 기술적 고민을 한지가 조금 오래되기도 하고, 일에 있어서 큰 재미를 느끼지 못했다. 평일 출퇴근 시간과 주말에 다른 회사에서 발표한 영상을 들으면서 마음 속에 있던 불씨가 조금씩 생기게 되었고, 뭐라도 시도 해보자 하는 의지와 도전심이 생겼다.

  • 현재 참여중인 IT 커뮤니티 SIPE 동아리에서 스프링 퍼포먼스 트랙 스터디를 진행하고 있는데, 주문 API 설계 과정에서 위의 기술들을 적용해 볼 수 있다면 시도해 봐야 겠다는 생각이 들었다.

  • 위의 두 가지 세션 이외에도 SERVER 파트와 관련된 다양한 세션 내용들이 있지만, 해당 부분들에 대해 관심있는 세션이 있다면 추후에 정리해보려고 한다.

  • 그리고 PLATFORM 파트에서도 개인적으로 눈길이 가는 비용이 왜 튀었는지 저도 몰라요 세션과 온콜, 알림만 보다가 죽겠어요 세션도 출퇴근 길 or 주말에 보면서 인상 깊은 부분이 있다면 정리해 보려고 한다.

Refernece

Recommend

Index