2024 스프링캠프 후기

• 다시보기 위치 : https://www.youtube.com/playlist?list=PLdHtZnJh1KdY3gEi7EPa2AuWn5NKRVmDf
• 2023년에 이어서 2024년 스프링캠프에 다녀왔다. (2023년 스프링캠프 포스팅 -> https://yeoon.tistory.com/108)
• 크게 3가지를 얻으려고 했다.

SpringCamp 2024

 

1. 인사이트 얻기
2. 실무에 도입할 내용
3. 동기부여

동기부여는 충분히 되었고,

얻은 인사이트와 실용적인 내용을 정리해본다.

2024 스프링캠프 - SETEC에서 진행

0. 현장 분위기

• 작년과 비교해 강연 주제가 2배로 많아졌다. (참고 - https://springcamp.ksug.org/2024/?fbclid=IwAR3SlcfgwHKlMTOF9z7TCQdp8Xab-sIniND6HWptZqbRaR5WAyv8EViMIxI)
  • Track 1, Track2로 나뉘어서 공간을 나눠 진행해 한곳을 선택해서 들어야했다.
  • 초급, 중급 난이도를 표기되어 있었는데, 관심이 있는 것 위주로 들을 수 있어서 좋았다. 
  • Kotlin이 있었다. 
    • Kotlin 관련 강연이 있었고 네이버페이, 카카오뱅크 재직자 분들의 예제 코드가 Kotlin이었다.

• 부스
  • 작년에는 제품 홍보 부스들이 있었는데, 올해는 채용 목적 부스만 있었다.
    • (작년) 현대자동차 채용, 인프런, Azure, 데보션(SK 블로그)
    • (올해) - 현대자동차 채용, 카카오페이 채용, Bolta 채용

등록부스

강연장과 카카오페이 부스

나눠준 굿즈

• 개인적으로는 카카오페이 채용부스가 너무 좋았다.
  • 무엇이든 물어보세요. 코너를 운영했는데
  • 평소 기술적으로 있던 고민을 카카오 개발자 분들한테 2:1로 마음껏 물어볼 수 있었다. (이거 돈 받아야하는거 아닌가 싶을 정도로 좋은 기회라 생각)

진짜 무엇이든 물어봤다.

[발표 내용] 

Track 1에서만 강연을 들어서 Track 1의 내용만 있다.

1. 켄트 백의 Tidy First ? (안영희 님 / 베터코드)

DDD책 한국판을 펼치면, 마틴 파울러 님, 조영호 님, 안영회 님의 추천사가 있다.

누굴까 싶었는데, 스프링캠프를 만드신 분이라고 한다.

 

올해 켄트백의 Tidy First?를 번역하셨는데

번역가의 입장에서 켄트백님과 소통하면서 책 전반의 맥락에 대한 소개를 다룬다.

책의 배경, 책의 목차인 Part1, Part2, Part3를 설명해주셨다. (한빛미디어의 Tidy First? 역자 인터뷰를 참고하면 좋다 - https://www.youtube.com/watch?v=dvi4S8LI17g)

 

엔비디아 젠슨황

올해 초 엔비디아 CEO가 "대학생으로 돌아가면 프로그래밍 안하고 생물학을 전공하겠다."는 말을 했다.

개인적으로 안영회 님의 강연이 왜 생물학을 전공해야하는지 인사이트가 된 강연이었다. (후반부 유기체 이야기 부터.. )

 

책의 등장 배경

• 켄트백이 Structured Design책(1975년 출판)를 읽고 뉴턴의 운동 법칙을 소프트웨어 설계에 적용한 명서라고 생각했다고 한다. 
• 그런데 옛날 책이라 알아보기 어려우니 현대에 맞게 책을 새로 써야겠다고 결심했다고 한다.
• 총 3권의 책으로 기획을 했고, 첫번째 책으로 Tidy First?를 2023년 출판했다.

Structured Design (1975)

• Tidy First?에서 인간관계의 맥락에서 내가 먼저 해야할 일 
• 다음 편 Tidy Together는 타인과 협업할때에 방법으로 확장할 예정이라고 한다. 

 

아래가 1권 Tidy First의 목차 Part1, Part2, Part3의 내용이다. 

Part-1 코드정리

15가지의 코드 정리 방법에 대해 다룬다.

리팩터링과 다른점은 리팩터링 + 인간관계에서의 활동을 강조했다고 한다.

Part-2 관리

• 코드 정리시점에 대해 다룬다. 
  
  • 코드 정리 안하기 (비용 대비 가치가 없으면 정리 안해도 된다.)
  • 나중에 정리하기 (Fun List - 나중에 할 목록으로 미룬다.)
  • 동작 변경 후에 코드 정리
  • 코드 정리 후에 동작 변경

• 가치는 2가지로 나뉜다. 정리 시점은 가치를 비교하여 정한다.
  
  • 지금의 기능 가치 (지금 바로 확인되는 가치 - 운영 버그 수정, 신규 기능)
  • 미래를 위한 일 (코드 정리 - 미래 확장을 위한 토대)

Part-3 이론

코드 정리를 이론으로 다룬다.

• 설계는 요소들을 유익하게 관계 맺는 일이다.
• 어떻게 구성되고, 계층을 이루고 관계를 맺고 유익히게 하기 - "유기체성”
  • 소프트웨어의 요소간 관계는 필연적이다.
    • 요소를 만들고 삭제
    • 관계를 만들고 삭제
  • 관계의 이점을 높이기가 필요하다.

유익하게 한다는 것은? 

• 현재 소프트웨어가 하는일 (출시! 사용자의 요구사항)
• 미래에 새로운 일을 시킬 수 있는 가능성 (유익한 구조에 대한 이야기)
• 미래가치를 책에서는 금융으로 설명한다. (가치 > 가격 > 비용)
  • 경제 이론, 옵션, 현금 흐름에 대한 이야기가 나와 어렵다고 한다.
• 경제이론 처럼 코드의 가치가 고객이 느끼는 가치가 커야한다는 것을 설명
• 결합도와 응집도 관리에 대한 설명

 

2. Spring AI : LLM에도 봄이 찾아오다 (황민호 님 / 카카오)

• AI의 큰 분류 소개
  • 그중 딥러닝의 한 분야인 LLM의 생태계와 중요한 개념 9가지를 빠르게 설명해준다.
• 생성형 AI 프레임워크인 Spring AI 소개한다. (https://github.com/spring-projects/spring-ai)
• Spring AI를 사용해서 SQL을 LLM으로 만들어 API 만드는 예제가 충격적이다.
• 기술이 발전해서 이게 실무에서 가능하면 기획자가 API 만드는 시대가 오지 않을까..

황민호 님 발표 슬라이드

황민호님 발표 슬라이드

 

• 요약하자면
• Spring AI 1.0.0이 내년 7월 출시 예정이다. (밀릴 수도 있다.)
• 지금 기준으로 어느정도 컨셉이 확정되어서 토이 프로젝트 단계라면 해볼만 하다.
• 과금이 걱정 된다면 Ollama를 로컬에 구축해서 사용해보자

 

3. 나는 왜 테스트 코드를 작성하기 싫을까 (조성아 님 / 네이버 페이)

네이버 오픈소스 Fixture Monkey를 만드신 분의 테스트 코드에 대한 회고 

https://github.com/naver/fixture-monkey

GitHub - naver/fixture-monkey: Let Fixture Monkey generate test instances including edge cases automatically

 

• 테스트의 이득과 비용을 간과해서 테스트 코드가 싫어진 이야기
  • 테스트의 이득 = 확장성, 피드백, 안정성
  • 테스트의 비용 = 코드 작성 시간, 유지보수 비용
• 테스트 비용을 줄인 방법을 공유한다.
  • (Given) Fixture Monkey 사용해서 코드 작성시간 단축
  • (Given) 최대한 간단한 테스트 경우의 수를 정해서 유지보수 비용 개선
  • (Then) 검증하려고하는 구체적인 값을 정해서 검증하여 유지보수 비용 개선

프로젝트와 나에게 적합한 테스트비용을 고려해서 최대한 간단하게 작성해보자 (테스트의 이득 vs 비용)

 

 

4. 실전! MSA 개발 가이드 (김용욱 님 / 삼성 SDS)

마이크로서비스 아키텍처 구축 가이드(2023년 출판) 저자이시다.

현장에서 필요한 것과 이론적 MSA 사이의 간극이 있는데 

 

API 속도, 트랜잭션 2가지 초점으로 MSA에 대한 가이드를 주셨다. 

시연 코드 : https://github.com/wharup/microservices-example-sql-vs-api

GitHub - wharup/microservices-example-sql-vs-api

 

 

• API로 속도가 나올까? 
  • 자주 참조하는 데이터를 API로 부르면 속도에 문제가 될 수 있다.
  • 잘 변하는 데이터와 잘 변하지 않는 데이터가 있다.
  • 잘 변하지 않는 데이터에 해볼만한 솔루션 소개
    
    • 데이터 복제
      • 구현이 간단해지고, 원본 데이터가 문제가 생겼을때 장애 극복 장점
      • 통째가 아니라 사용하는 속성만 복사해야한다. 그래야 동기화 빈도를 줄일 수 있다.
    • 모델링 변경
      • 기획에 따른 서비스 모델링 변경
    • 일괄 조회
      • API N번 호출하는게 아니라 SELECT IN 처럼 타 서비스 조회시 일괄로 조회 
      • JPA N + 1 문제가 MSA는 REST에서 나올 수 있음
      • 일괄조회만 잘 구현해도 실제 시스템에서 성능 문제 거의 없다.
    • 병렬조회 
      • 순간적으로 큰 부하가 생겨 사용하면 안되는 안티패턴이다.
      • 꼭 필요한 경우만 일괄조회를 병렬로 실행해야한다. (바로 다음 발표에서 카카오뱅크 홈화면의 계좌가 N개 서비스에서 조회하는데 코루틴으로 병렬 조회한다고 한다. (일괄조회를 N번))
    • 로컬캐시
      • 네트워크 호출 줄인다.
      • 레디스보다 20배 빠르다고도 함
      • 로컬캐시는 서비스간 동기화가 되지 않아 사용에 주의해야한다.
      • 동기화 옵션이 있는데 쓰면 안되는 안티패턴이다.
        • 데이터 들어나면 캐시 데이터 복사해야하기때문에 1-2초 정지 될 수 있음
• 트랜잭션 보장 없이 정합성이 맞을까?
  • 원자성 지키기 위해서 할 수 있는 조치
    • 데이터 맞추는 대사작업이 필요하다.
    • API 자동으로 재시도하는 건 안티패턴이다.
      • 2-3번까지 시도하고 쓰레드를 날리고, 회복 시간이 필요하다.
    • 이벤트로 재시도 하는 것은 좋은 도구가 될 수 있다.
      • 두번 실행해도 동일 결과가 나와야한다. (멱등성 보장) 
    • 역할 분리
    • 모델링 변경
    • 서비스 경계 변경
    • 긴 트랜잭션 분리하기
  • 독립성을 지키기 위해서 할 수 있는 조치
    • 네트워크를 타기 때문에 READ UNCOMMITED로 동작하는 문제가 있다.
    • Lock을 이용한다. - SELECT FOR UPDATE 쓰지 않는다.  Application Lock(LOCK 테이블 관리) 쓴다.

 

5. 구해줘 홈즈! 은행에서 3천만 트래픽 홈서비스 새로 만들기 (이영규 / 카카오뱅크)

• MVC 레거시 코드를 핵사고날로 분리하며 기술부채 해결
• 서비스 신규 프로젝트로 안정적으로 이관한 이야기

• 구조적 문제를 해결
  • 계층간 의존성 꼬여있는 것
  • 핵사고날 아키텍처로 접근하여 해결
    • 캐시나 Suspend가 application 계층에 있어야하는지, out-adapter 계층 위치해야하는지 고민  
    • 외부 서비스 응답의 애그리게이션 고민
    • 도메인이 핵심이고 도메인 중심으로 생각해서 풀어감
• 성능적 문제
  • 동시성 도입 - Kolin Coroutine
• 이관전략
  • 안정 장치 만듬
    • 응답값을 비교하는 서비스만들어 지표를 모니터링 - 표본검사 진행
    • A/B 트래픽 서비스
      
      • 비율을 동적으로 조작해서 언제든지 rollback 가능하도록 구축
      • 하이럼의 법칙
    • Fallback 기능 제작
      • 신규서비스 호출시 문제가 있으면 기존 서비스 호출하도록 gateway에 구현