분위기가 확실히 달랐던 SpringCamp2024

　이제 막 반팔을 꺼내 입기 시작한 초여름의 지난 토요일, 스프링캠프 2024를 다녀왔다. 개발의 재미를 한창 알아가던 주니어 시절, 자바/스프링을 다루는 백엔드(서버사이드) 개발자라면 한 번쯤은 들어보거나 참여해 봤을 스프링캠프라는 기술 콘퍼런스를 매년 기다려왔다. 나에게 있어 스프링캠프는 조금 남 다르다. 여느 때와 다름없이 성장에 갈증을 느끼고 있을 무렵 지금으로부터 약 5년 전 SpringCamp2019 에 일꾼단(스텝)으로 참석하여 처음 진행부터 끝나는 과정까지를 온전히 경험한 기억이 있기 때문이다. 그래서인지 행사를 준비하는 준비 위원회부터 발표를 준비하는 연사자 분들의 땀방울이 얼마나 소중하고 힘드신 과정인지 조금은 더 잘 알기에 매년 참석해야지 했지만 코로나로 몇 년 동안 중단되었던 스프링캠프가 작년에 다시 시작했지만 확실히 개발에 대한 열정의 온도가 높아졌는지 티켓 판매는 1분 컷으로 참석을 하지 못했다. 올해는 반드시 가야겠다 다짐했기에 티켓 판매 시작과 동시에 예매에 성공했다. 물론 올해도 1분 만에 매진이 되었다고 할 정도로 그 열기는 대단했다.

　제목에도 적은 것처럼 여러 가지 측면에서 분위기가 확실히 달랐다. 앞서 1분 만에 티켓 판매가 매진된 것처럼 정말 많은 사람들이 참여한 것만으로도 개발에 대한 열정은 현장에서도 느낄 수 있을 정도였다. 특히 나는 이런 개발 콘퍼런스 또는 세미나에 참석하면 아는 내용일지라도 연사자의 답변을 들으며 기억에 오래 남기 위해 발표가 끝나면 항상 질문을 하는 게 목표라면 목표라고 할 수 있는데 워낙에 많은 분들이 질문을 하시다 보니 5개 세션이나 있었는데 한 번도 질문을 할 수가 없었다. 5년 전만 해도 이렇게 적극적인 분위기는 아니었던지라 발표가 끝나면 고요한 분위기를 항상 내 질문으로 깨곤 했었는데 적잖은 충격이었다. 더불어 질문의 수준 또한 놀라웠는데, 단순 xx가 뭐에요 라는 말 그대로 ‘질문’을 넘어서서 각자의 경험을 토대로 개인의 상황과 생각을 이야기 하면서 연사자의 생각을 듣고 싶다는 식의 질문의 흐름 속에서 비록 내가 연사자는 아니었지만 질문 자체에서 생각을 해볼 수 있는 기회가 되었던것 같아서 꽤 신선했던 것으로 기억된다. 반대로 장소가 협소했던 점과 개발 콘퍼런스를 다녀오면 항상 한 아름 선물들을 받아오곤 했었는데 생각보다 회사 부스들이 적은 게 아쉬웠다. 아마도 스프링캠프가 비영리단체이기도 하고 일꾼단 경험을 토대로 생각을 해보면 후원사가 풍족하지 않은 점이지 않을까 생각을 해봤다. 이곳을 찾아오신 많은 개발자 분들의 열정 만큼 후원사도 많아져서 특정 회사에서 주최하는 개발 콘퍼런스와 비슷한 수준으로 진행되면 좋지 않을까 싶었다.

　행사장 앞에서 외롭게(?) 안내를 하고 계셨던 운영진 분께서 감사하게도 나를 알아봐 주셔서 깜짝 놀랬다. 크게 두 가지의 트랙으로 총 10개의 발표가 진행되었다. 어쩌다 보니 줄곧 트랙 1에서 듣게 되었고 맨 앞 정중앙에 자리 잡고 우등생(?) 코스프레를 해보며 연사자분들의 발표 내용을 하나도 놓치지 않으려 집중해서 들었다. 발표라는 게 제한된 시간 내에 방대한 양을 이야기를 해야 하기 때문에 자칫 잘못하면 ‘찍 먹’의 형태로 발표하는 경우가 있다. 그런데 이번 발표하시는 분들의 내용을 보면 꽤 많은 고민을 한 흔적들도 보였고 발표 전에 준비 위원회 분들과 함께 리뷰를 잘 하셔서인지 시간이나 진행도 매끄러웠던 걸로 기억된다.

　발표 영상은 3~4개월 이후에 유튜브에 올라온다고 하니 관심 갖고 찾아보면 될 것 같고 간접적으로라도 발표 내용과 내 생각들을 공유하면 좋을 것 같아 적었던 메모를 남겨본다. 후다닥 메모를 하다 보니 잘못된 내용이 있을 수 있으니 어느 정도 감안하고 봐주길 바란다.

켄트벡의 Tidy First? / 안영회 님

　이 책은 내가 운영하는 스터디, 그리고 회사 팀 분들과도 스터디를 진행 중이라 아직 끝까지 읽어보진 못했지만 전체적으로 어떤 ‘기술’을 알려준다기 보다 코드를 정리하는 방법들에 대해 생각해 볼 만한 아젠다를 제공해 주는 책인 것 같다. 특히 ‘Man in the mirror’라는 표현으로 ‘나 자신부터 시작하자’라는 의미가 강렬하게 다가왔고, 주변의 환경탓만 해온건 아닌지 스스로 개척해 나갈수도 있을것 같다는 자신감을 얻었다. 책에 대한 내용 그리고 꽤 오랫동안 개발씬에 계시면서 본인을 ‘설계덕후’ 라고 칭하시며 느낀 내용들에 대해 소개해 주셨는데 그분이 직접 켄트 백과 소통하며 번역하신 책이니 끝까지 읽어보고 이 책에 대한 후기도 남겨볼 수 있었으면 좋겠다고 생각했다.

• 켄트벡, Structured Design 이라는 책, 경력이 쌓인 이후로 다시 책을 보니 너무 좋았다고. 뉴턴의 법칙이 담겨있다고 느껴져서 이 책을 쓰기 시작했다. (3부작 예정)
• 15가지 코드 정리법에 대한 내용
• 학습
  • bottom-up : 켄트벡이 선호하는 방식
  • 아기 발걸음 : 자연스러운 학습의 모양새
  • Man in the mirror : 먼저 나와 인간 관계 활동 익히기 / 나부터 시작하자.
• (다음 책 : Tidy Together)
  • 코드를 관리하는 측면
• 코드 정리와 리팩터링은 모양, 행위는 같으나 의미, 목적은 다르다.
  • 역자 인터뷰 : https://www.youtube.com/watch?v=dvi4S8LI17g
• 공진화 : 코드와 함께 사람의 개발능력도 진화한다.
• 일단 닥치는 대로 코딩 → 작업의 종류 구분 (기능변경 / 코드정리 = 인지) ⇒ 한번에 담기 (배포&통합) → 나누어 담기
  • 기능 변경과 코드 정리를 나누어라
• 자꾸 손이 가도록
  • 이왕이면 더 작게 해서, 더 자주 즐기기
  • 작은 단계로 두어서, 다음 수를 내다보기
• 일괄 처리 규모가 줄수록 검토 비용과 코드 정리 비용이 함께 줄어든다.
• 설계
  • 소프트웨어 설계는 Fractal : 작고 빈번하게 할수록(선택) 유리
  • 소프트웨어 설계는 길을 닦는 일 : 쓰임새를 지켜보며 지속해야 하는 일
• 실타래를 풀려면 실이 엉켜 있다는 사실을 알아차려야 시작할 수 있다.
• 시점이 중요 ( Tidy First? ← 책 제목에 물음표가 갖는 의미 )
  • 아에 안한다면?
  • 나중에 정리하기(재미 목록으로)
  • 동작 변경후에 코드 정리
  • 코드 정리 후에 동작 변경
• 이론
  • 요소들을 유익하게 관계 맺는 일
  • 구조와 동작
  • 경제 이론 : 시간 가치와 선택 가능성
  • 되돌릴 수 있는 구조 변경
  • 결합도와 응집도
• 설계 = 요소들 + 관계 맺는 일 + 유익하게
• 설계자의 할일
  • 요소를 만들고 삭제하기
  • 관계를 만들고 삭제하기
  • 관게의 이점을 높이기
• 소프트웨어는 두 가지 방식으로 가치를 만든다.
  • 현재 소프트웨어가 하는 일
  • 미래에 새로운 일을 시킬 수 있는 가능성
• 가치 > 가격 > 비용 - 생존 부등식 by 윤석철 → 코드의 가치 > 고객 만족도 > 비용 (시간)
  • 경제이론 : 시간 가치와 선택 가능성
  • 오늘의 1달러가 내일의 1달러보다 크다
  • 옵션
  • 옵션과 현금흐름 비교
• 결합도가 가진 두가지 성질 : 일대다 / 연쇄작용
• ‘복잡하다’의 의미 : 변화가 예상치 못한 결과를 초래한다.
• 비용(소프트웨어) ~= 결합도
• 응집도 : 관계의 양상을 부르는 서로 다른 이름
• 설계에서 중요한것
  • 따로 또 같이
  • 인터페이스

LLM에도 봄이 찾아오다 / 황민호 님

백엔드 개발자로써 Spring AI라는 존재에 대해선 알고 있었지만 이를 실무에서 어떻게 활용해 볼 수 있을까 하는 기대감에 듣게 되었다. Spring AI를 통해서 보다 쉽게 AI를 다룰 수 있는 인터페이스를 제공해 준다 정도로 이해했는데 실제로 현업에서 이를 어떻게 다뤄서 어떤 아웃풋을 만들어 볼 수 있을까 하는 기대감 때문이었는지 내용이 개인적으로는 아쉽기만 했다. 그렇지만 가볍게 운영자가 다루는 어드민 기능(어드민을 다루는 방법을 물어본다든지, 스펙을 물어본다든지 하는 대화 형태의 서비스 등)에 도입을 해서 사람이 직접 룰베이스로 처리하는 것이 아닌 AI의 도움을 받아 처리하는 것도 시도 해 볼 수도 있겠다 싶었다.

• 생성형 AI
  • 딥러닝의 한 분야
  • 텍스트(+a)가 인풋, 아웃풋은 여러 형태
• AI 컨셉
• spring ai
  • 주요 ai모델 provider 통합
  • 주요 벡터 DB 지원
  • AI 개발 편의
• Spring AI Client
• 로컬에서 ollama 로 돌려볼 수 있음
• ai를 보다 쉽게 사용하기 위한 인터페이스

왜 나는 테스트를 작성하기 싫을까? / 조성아 님

테스트 작성할 시간이 없어요 라는 피드백을 들어본 적은 있었지만 이제는 테스트가 중요하다는 점은 누구나 공감을 할 것이라 생각한다. 그럼에도 불구하고 개발을 하다 보면 테스트 작성을 기피하거나 꺼려 하는 경우가 있는데 그러한 부분이 공감이 되어 발표를 듣게 되었다. (같은 회사 분이라 더욱 궁금했던 점도 있었고) FixtureMonkey 를 직접 개발/운영하고 계시며 왜 만들었는지부터 운영하면서 등록되는 이슈들을 처리하는 사례들을 말씀해 주셨다.
본질적으로, 테스트를 작성하기 싫은 이유를 해소하기 위해 FixtureMonkey 라는 라이브러리를 활용하기도 하고 여러 ‘비용’들을 제거해 나가면서 보다 쉽게 테스트를 작성할 수 있는 환경을 만드는 게 중요하지 않을까 라고 받아들여졌다. 여러 팀에서 테스트 코드 작성 자체를 하지 않는 상황들이 많아서 테스트 코드를 작성하자는 운동(?)을 많이 시도해 본 경험으로 연사자분 말을 빌려 직접 솔선수범하며 테스트 코드가 가져다 주는 장점과 효과를 몸소 알려주는 것도 방법이 되지 않을까 싶었다.

• 테스트의 사실과 오해
  • FixtureMonkey
  • DomainFixture라는 개념을 도입해 실제 프로덕션 환경에서 발생하는 경우의 수를 테스트 하는 시도
    • 유지보수 비용 증가
  • 회고
    • Fixture Monkey를 사용해 낮아진 테스트 작성 비용과 넓어진 테스트 범위
    • 주문서 특성상 모든 코드를 테스트 해야 한다라는 생각
    • DomainFixture 유지보수 비용을 생각 못함 → 테스트의 이득과 비용에 대해 진지하게 고민하게 되는 계기
• 고민없이 가지고 있던 오해 → 테스트는 무안단물이다.
• 테스트를 작성하기 싫은 이유
  • 비용(작성, 유지보수) > 이득(확장)
  • 테스트의 본질 : 피드백 루프
    • 테스트는 나의 기대대로 동작하는지 피드백을 받는 과정
    • 테스트에 많은 기대를 하면 기대 만큼 비용이 된다.
    • 각 테스트 단계마다 사람마다 기대하는 정도가 다르다.
    • Unit - Intergration - E2E
  • 비용을 결정하는 요소
    • 작성하는 로직이 어떤 요청이 필요한지 (Given)
    • 작성하는 로직은 어떤 결과가 나와야 하는지 (Then)
  • 제거할수 있는 테스트 비용
    • Given - 테스트를 복잡하게 작성하려 한다 (작성비용)
    • Then - 하나의 테스트에서 많은 검증을 하려한다 (유지보수 비용)
  • 하나의 테스트에서 많은 검증을 하려 한다.
• 지속 가능한 테스트 방법
  • less is more
  • 나를 위한 테스트 비용을 줄이기
    • 픽스쳐 몽키 사용하기
    • 최대한 간단한 경우의 수를 테스트 하기
• 결론
  • 테스트는 작성 비용과 유지보수 비용이 있다.
  • 프로젝트와 나에게 적합한 테스트 비용을 생각해보자.
  • 테스트 비용이 부담된다면 픽스쳐 몽키를 사용해서 최대한 간단하게 작성하자.
• SimpleValueJqwikPlugin 사용하면 유의미한 값 활용

실전! MSA 개발 가이드 / 김용욱 님

여기저기서 MSA~ MSA~ 라고 말할 정도로 핫하다 못해 기본 기술화(?)가 되어가는 듯한 마이크로 서비스 아키텍처에서 조심해야 할 부분들과 팁들을 알려 주셨다. 소개해 주신 각 방법들의 장점들을 여러 가지 상황들을 코드로 구현해 오셔서 시연까지 보여주시며 제한된 시간 내에 노하우를 꾹꾹 눌러 담아 발표하시려는 게 느껴질 정도였다.
그 중 여러 서버들이 있을 때 각 로컬 캐시를 동기화 하는건 안티 패턴이라는 부분이 상당히 고민을 하게 하였다. 과거 카프카 밋업에서도 들었고 실제로 경험했던 사례 중에 로컬 캐시의 동기화 문제로 오히려 클라이언트에서 일관되지 못한 데이터를 가져가는 문제점이 있었고 이를 pub/sub 모델로 로컬 캐시를 동기화 하도록 해결했었기 때문이다. 질문하고 싶었지만 내 차례까지 오지 못했고 여기저기 찾아보니 동기화 하는 복잡도가 증가하고 성능 문제를 일으킬 수도 있으며 pub/sub 시스템의 관리 비용이 문제라고 한다. 언제나 말하지만 기술엔 정답이 없듯이 안티 패턴이 꼭 모든 사례에서 적용되는 건 아니라곤 하지만 다시 한번 생각해 볼 문제를 던져주신 것 같아 꽤 흥미로웠다.

• api로 속도가 나올까? (read)
  • 데이터를 복제
    • 필요한 속성만 복사
    • 필요한 것만 끌어가는 구조
  • 모델링 변경
    • 공통 속성은 각 서비스에 복제
    • 특화 속성은 오너 서비스에 배치
  • 일괄 조회
    • Rest API의 N+1 Problem
    • 모아서 한번에 조회 == select in → 처리시간 단축, API 호출회수 감소
    • 병렬 조회
      • 순간적으로 큰 부하가 생길 수 있음 (DDOS)
      • 꼭 필요한 경우에만, 일괄 조회를 병렬로 실행
  • 로컬 캐시
    • like ehcache
    • 로컬캐시를 동기화 하는건 안티패턴
• 트랜잭션 보장 없이 정합성이 맞겠어? (write)
  • ACID
  • 실패시 바로 재시도?
    • 안티패턴
    • 이벤트로 재시도
  • 이벤트로 처리할때
    • 긴 TX 나누기
      • 실패해도 전체를 취소가 없다면 이벤트로 분리
      • 취소할 수 없는 쓰기는 이벤트로 분리
    • 역할 분리 → 각자 알아서
      • 과정 서비스는 이벤트만 발송하고 끝
      • 나머지는 다른 서비스가 각자 하는게 좋은 설계일수도
    • 모델링 변경
      • 데이터는 오너십을 가진 서비스에 배치
    • 서비스 경계 변경 : 너무 구현하기 힘들면, 서비스를 합치거나 경계를 변경해도 괜찮다.
• 요약
  • 패턴
    • 꼭 필요한 속성만 복사
    • 일괄 조회
    • 로컬 캐시
    • 전체 취소 안하면 이벤트로 쓰기
    • 멱등성
    • 분산모델
    • 데이터는 오너십 가진 서비스에
  • 안티 패턴
    • 테이블 스키마 목사
    • 병렬 호출
    • API 시도
    • 로컬 캐시 동기화

구해줘 홈즈! 은행에서 3천만 트래픽의 홈 서비스 새로 만들기 / 이영규 님

휴대폰 배터리가 나가서 이후 사진이 없다..ㅠㅠ

카카오뱅크 서비스의 홈 영역을 새로운 서비스로 이관하는 과정에 대해 소개해 주셨다. 아주 인상적이었던 건 해결해야 할 상황을 일목 요연하게 잘 정리하고 (레거시가 많고 → 기술 부채도 해결해야 하며 → 안정적으로 이관해야 하는 목표) 기술부채도 구조적 문제와 성능적 문제로 분리하여 파악/정의한 뒤 이를 해결하기 위한 기술에 대해 풀어가는 과정이 너무 좋아 보였고 재미있었는데 개인적으로 요즘 너무 ‘일’만 하고 있는건 아닌지, 기술부채를 개선하자며 떠들어 왔었는데 이런저런 핑계로 잠잠해진 내 자신을 돌아보게 되었다. 또한 서비스의 안정성을 도모하기 위해 2차 3차 다양한 장치를 마련해가면서 안되면 말고 식의 접근이 아닌 자식 키우는 마음으로 서비스를 대하는 모습 또한 아주 기억에 남을 정도였다.

• 배경
  • 레거시가 많았다.
  • 개선 / 기술부채 해결
    • 구조적 문제
    • 성능정 문제
  • 서비스 이관을 하면서 문제도 해결해야 하는데 안정적으로.
• 기술부채 : 구조적 문제
  • 섞여있는 외부 의존성과 도메인 정책
  • 외부 데이터 구조에 강결합
  • 헥사고날 아키텍처의 도입
    • 의존성의 방향과 도메인 계층의 보호를 강제한다!
    • 동시 작업 쉬워지고 유즈케이스가 좀더 가시적으로 드러나고 지름길을 택하지 않게 된다!
    • 초기 러닝 커브 존재, 보일러 플레이트 코드가 많아지는 단점
  • Application ↔ out-adapter
    • 조회의 책임은 누구? 실제 데이터 가져오는건 out-adapter
    • 캐시의 책임은 누구? 상황에 따라 앞에 있을수도 뒤에 있을수도
• 기술부채 : 성능적 문제
  • 상황(홈화면) : 한 화면에 여러 데이터 원천들을 조회해서 조합하는 형태 (MSA)
  • 점점 많아지고 네트워크 비용 → 성능 저하 포인트
  • 동시성 적용!
    • webflux x
      • 코드에 불필요한 동시성 관련 요소들이 많이 침투
      • Mono, Flux등 복잡한 인터페이스를 따로 배워야 해서 러닝커브
      • 모니터링이 어렵고 레퍼런스가 부족
    • Kotlin Coroutine
      • None-blocking
      • 간결한 코드
      • 단순 멀티 스레드 방식보다 더 효율적으로 동작
      • 다른 방식에 비해 훨신 간결하게 사용
      • Kotlin 언어 수준에서 지원
  • Kotlin Coroutine 도입
    • suspend 키워드를 사용하면 thread local이 전파 안되는 문제
    • 필요한 곳만 suspend 사용
      • 컨텍스트 알아서 관리
      • 간결한 코드
      • 쓰레드 효율적 활용
    • 전파되는 suspend : 다른곳에서는 동시성이 필요 없는데 suspend사용이 강제됨
      • async/await 패턴으로 해결
      • 컨텍스트를 넣어줘야 하는 관리포인트가 있지만 코드 레벨에서 확인이 가능하다는 트레이드 오프
• 안정적 이관 전략
  • 은행 ← 장애가 치명적으로 민감함
  • 문제 : 너무 커져버린 환경
    • 기존코드는 자바, 새로운 코드는 코틀린(사실상 새로운 서비스)
    • 서버만의 분리 작업이기에 외부 인터페이스가 변하면 안됨
  • 응답비교 서비스 개발 : 기존 응답과 신규 응답 비교
    • gateway → 기존서비스 → (async) 응답비교 서비스 → 신규 서비스
    • 시간 차이에 의한 불일치 발생 : 알림 룰 변경으로 대응
    • 응답비교 서비스 때문에 네트워크 비용 발생 (체감 2배) : 샘플링 호출로 비교/검토
  • A/B test : 신규 서비스에 따른 문제 최소화
  • fallback : 신규 서비스에 예외가 발생하면 기존 서비스 응답으로 fallback
• 정리
  • 기술부채 해결 : 의존성 혼재 → 핵사고날 도입
  • 외부 서비스 호출 증가에 따른 성능상 우려 → 코루틴 도입
  • 기술 회고
    • 헥사고날 아키텍처 : 깃 충돌이 거의 사라지고 협업이 더 쉬워졌지만 간단한 기능 신규 구현할 때는 불편
    • 코틀린 코루틴 : (약간) 빨라진 응답, 간결한 코드!
  • 안정적 이관 전략
    • 응답의 일관성 유지 : 응답 비교 서비스 개발
    • 다른 서비스에 대한 영향도 최소화 : 표본 검사
    • 장애 최소화 및 빠른 복구 : A/B Test, fallback

　항상 이런 기술 발표를 듣고 오면 뭔가 정신이 바짝 차려지고 지금 운영하고 있는 서비스를 다시 살펴볼 에너지를 얻고 가는 것 같아서 너무 좋다. 특히 이번 스프링캠프 2024 내용들은 하나같이 실무에서 적용해 볼법한 팁과 인사이트를 얻은 것 같아서 티켓 비용, 황금 같은 토요일 오후 시간이 아깝지 않을 만큼 너무 좋은 시간으로 기억될 것 같다. 마지막으로 이 발표를 위해 준비하신 연사자 분들, 그리고 준비 위원회 분들과 이 발표를 들으러 나를 포함해 멀리서 오셨을 참여자 분들 모두가 어제보다 조금이나마 성장했기를 바라본다.