백엔드 개발자의 인프콘 2024 후기 - 1 (장문 주의)

8월 2일 삼성 코엑스 그랜드볼룸에서 열린 인프콘 2024가 열렸다.

항상 인프콘은 탈락했던 터라, 꼭 가고싶었는데 이번에 가게 되어 들었던 세션을 회고해 보고자 한다.

아, 물론 각 세션의 전체 내용을 요약하지는 않는다. 살짝 예고편(?) 정도로만 소개할 예정이다.
전체 내용은 인프콘 2024 다시보기 영상이 인프런에 올라오니 이 후기를 보고 관심이 간다면 찾아서 보는것도 좋을 것 같다.

인프콘 2024

 

내가 들었던 세션은 아래 5가지다.

1. 지속 가능한 설계를 만들어가는 방법 - 김재민 님
2. 인프런 아키텍처 2024 - 이동욱 님
3. 경력이 늘수록 CS이론이 중요해지는 이유 - 최호성 님
4. 클린 스프링: 스프링 개발자를 위한 클린코드 전략 - 이일민(토비) 님
5. 객체지향은 여전히 유용한가 - 조호성 님

Datadog 기업 부스

세션 외에도 다양한 기업 부스 및 인프런 측에서 준비한 행사들이 많았어서 혼자 갔는데도 전혀 심심하지 않았고,

다양한 굿즈들이 준비되어 있어서 굿즈들을 모으는 재미도 있었다. 또한 스태프들도 많아서 전혀 불편함 없이 잘 즐기고 왔다.

 

우선 각 세션별 후기를 적어보고자 한다.

지속 가능한 설계를 만들어가는 방법 - 김재민 님

요즘 회사에서도 설계에 대해 정말 많이 생각을 하고 있다. 설계라는 것은 너무 지나쳐도 안되지만 대충해서도 안되기 때문이다.

'기술 부채' 라는 말이 있다. 말그대로 채무인건데, 우리는 가끔 설계를 안일하게 하여 이 부채를 쌓아두었다가 결국 갚지 못하고 나중에 고통받는다. 이 부채들을 새 프로젝트에선 줄이고 싶은데, 마침 적절한 세션이 있어서 바로 들어보았다.

 

발표자 분께서는 가장먼저 지속 가능한 설계를 만들어가는 방법으로 '설계를 안하는 것'(?)이라는 말을 하셨다.

사실 처음엔 띠용 했지만 일단 들어보자 하는 마인드로 계속 듣게 되었다. 사실 이러한 기선제압(?)으로 인해 더 집중해서 들을 수 있게 되었던 것 같다.

 

'개념'과 '격벽' 이라는 키워드를 매우 강조하셨다. 개념이라고 하면 서버에서는 도메인쯤으로 생각할 수 있을것이다.

서비스를 만들때는 이러한 개념들이 정말 많이 나오게 되는데, 발표에서 나왔던 예시는 '대출'이였다. 대출은 어떤 개념들이 있을까?

대출 신청, 대출 실행, 대출 상환 등 여러가지 개념들이 있다.

 

이러한 개념들이 많아지면 어떻게 될까? 겪어본 분들은 알겠지만 매우 정신이 없어진다. 어떤 기능은 어떤 개념에 넣고.. 어떤 기능은 뭔가 이 개념에는 넣기는 애매하고.. 저 개념에 넣어야 하나..? 등으로 고민을 길게 해본 개발자들이 분명 있을것이라고 생각한다.

 

그래서 결국 결합도가 높아지고 소프트웨어는 정신이 없어진 소프트웨어가 되버리고 만다.

격벽은, 이렇게 개념 간의 무분별한 참조를 막기 위해 격벽을 세워 개념을 통제해야 한다는 하나의 '방화벽' 같은 것이다.

그렇게 도식화 하여 발표하고 있던 중 들었던 생각이 '어..? 이거 설계하고 있는거 아닌가..?' 라는 생각이 들 찰나에 발표자분 께서
내 마음을 읽었는지 '설계하고 있는것 같지만, 이해를 위해 도식화 하여 보여드린 것이다. 실제로는 모두 코드로 만들어져 있다' 라고 강조하셨다.

 

어쨌든 이러한 개념과 격벽을 잘 활용하게 되면 코드 변경 시 관련 코드만 수정되고, 잘못 활용하면 관련 없는 코드도 수정해야 한다.

객체지향의 캡슐화와 비슷한 개념인것 같은데 조금 다르다.

대출 서비스의 개념을 정리하면 대출 신청, 대출 실행, 대출 상환으로 나눌 수 있다.

 

예제: 대출 서비스 개념 정리

개념과 격벽에 대한 정리

대출 서비스의 개념을 정리하기 위해 개념들을 나누고 구현을 바로 시작한다.

개념들을 정리하다 보면 개념들의 상태(기능)들이 생기게 된다. 여기서 대출 상환쪽 상태들을 정리하다 보니 '상환 실패' 라는 상태가 생기게 된다. 상환 개념을 다시 정리해보면 '상환 성공' 과 '상환 실패' 두가지 케이스로 나누어 지게 된다.

 

상환을 실패한다면 어떻게 되는걸까? 말 그대로 돈을 빌리고 못갚은것이 된다. 추가적인 연체 이자도 있을 것이다.

그리고 이렇게 상환이 실패했을 때는 재시도를 해야한다는 부가적인 기능도 도출된다.

 

발표자 분께서는 이러한 상황 실패 케이스에 대해서 '격벽'을 세워보았다. 그랬더니 사실 상환 개념에서는 상환 성공과 상환 실패 상태가 나왔을 때 이미 개념적으로 자기 역할을 다 했다는 것을 느끼게 되었다.  상환 재시도라는 개념이 따로 있지만, 이것은 상환 실패 개념에 종속된다고 볼 수 있고, 추가 이자도 실패 이후로 추가 이자를 받을 뿐이라서 상환 개념의 역할은 아니라는 것을 느꼈다.

 

그래서 격벽 기준으로 테스트 코드와 검토를 거쳐보니 '연체' 라는 개념이 나오게 된다.

상환 개념은 상환 성공과 상환 실패만을 다루고, 상환 실패 이후의 처리는 연체 개념으로 이관하는 것이다.

 

결론

누구나 그럴싸한 계획을 가지고 있다. 처맞기 전까지는 - 마이클 타이슨

위와 같은 방식으로 발표를 약 30분 정도 이어가셨고 말씀하고자 하시는 부분이 정확하게 캐치가 되었다.

즉, 지속 가능한 설계를 위해서는 '구현'이 우선시 되어야 하고, 이는 소프트웨어의 장점이라는 의미였다.

요구사항은 끊임 없이 변화하고 이는 완벽한 설계는 불가능 하다는 뜻이 된다.

불필요하게 과도한 설계를 피해야 하고 필요한 만큼의 설계를 한 후에 구현하고 검증하고 변경하는 과정을 반복해야 한다고 한다.

 

이러한 과정에서 개념과 격벽의 개념을 도입하여 무작정 구현하는게 아니라 정리와 검증 과정을 거치는 단계를 거치다 보면 지속 가능한 설계를 만들 수 있다고 하셨다.

발표를 듣고나니 나는 '소프트웨어' 를 개발하고 있다는 것을 잠시 잊었었던 것 같다. 소프트의 사전적 의미는 부드러운, 연한 등이 있다.

이러한 것을 망각하고 너무 완벽한 설계를 고집하고 있던게 아닌지 반성할 수 있었던 세션이였다.

 

위 세션 기사도 올라와서 추가한다.
https://m.ddaily.co.kr/page/view/2024080212183225754

"발주처의 완벽한 SW설계는 없다"…변경 수요 가능한 SW설계방법이 중요

 

 

인프런 아키텍쳐 2024 - 이동욱 님

인프런 아키텍처 2024 ~ 2025

인프런 아키텍처는 2023버전을 들었어서 더 궁금했던 세션이다.

큰 조직을 목적조직으로 나누고 목적조직에 따라 커다란 레거시 복제하여 해결을 하고있는 부분들이 정말 인상적이었다.

 

이번 인프콘 2024 컨퍼런스에서도 뭔가 인사이트를 얻을 만한 내용들이 분명 있을것 같아서 해당 세션에 참여 하였다.

혹시 인프콘 2023 영상이 궁금하다면 아래 링크를 통해 볼 수 있다.

https://www.inflearn.com/course/%EC%9D%B8%ED%94%84%EC%BD%982023-%EB%8B%A4%EC%8B%9C%EB%B3%B4%EA%B8%B0

[지금 무료] 인프콘 2023 다시보기 강의 | 인프런 - 인프런

세션 초반에는 글로벌 진출을 위한 조직 개편 이야기를 하셨다.

여기서 환율 상승 이야기가 나오는데, 환율 상승 == 클라우드 비용 증가 이기 때문에 비용 절감 이야기 위주로 이번 세션은 진행되었다.

트래픽 최적화

글로벌 진출을 위해선 무료 강의 등을 만들어서 해외쪽에 홍보를 해야하는 상황인데, 이때 수익이 전혀 발생하지 않는 상황에서 트래픽 비용을 계속 내야하는 상황이다. 비용 절감이 무조건 필요한 상황에서 비효율적인 트래픽을 개선하기 위해 불필요하게 발생되는 트래픽을 개선하기로 하셨다고 한다.

 

인프런에 들어가보면 강의 썸네일 이미지가 나오는데, 이게 생각보다 어마어마하게 트래픽 비용이 발생한다고 한다.

세션에서 나온 방법들은 아래와 같다.

1. 이미지 크기 개선

화면에 필요한 만큼만 이미지를 리사이징한다. 아마 커뮤니티 서비스나 콘텐츠 서비스를 하고 있는 개발자는 보통 이정도 인프라는 다 구현해 두었을 것이다. 쿼리 파라미터에 사이즈 값을 입력하고 클라우드 프론트에서 캐시된 것을 내려주면서 이미지 트래픽 최적화를 진행한다.

 

그런데 이것만으로는 한계가 있다. PNG, JPG 같은 경우에는 이미지 파일이 크기 때문에 AVIF라는 이미지 포맷을 이용했다고 한다.

AVIF 이미지 포맷은 엄청나게 고품질인데 저용량의 파일이다. 이는 품질 자원 고효율 압축이 가능하다는 것인데, JPG에 비해서는 최대 50프로까지 용량 개선이 가능하다. 이 이미지 포맷을 적용하고 있는 서비스도 한국에 일부 있다고 한다.

그래서 인프런은 이미지 리사이즈만 하지 않고 파일 포맷도 AVIF로 전환을 해서 내려주도록 하고, 이것은 람다에 있는 코드를 수정하면 가능하다. URL 파라미터에 포맷값을 수정하는 방식으로 진행했다.

 

또한 AVIF는 대부분의 브라우저에서도 지원을 해주기 때문에 이 포맷을 통해 이미지를 내려준다고 해도 브라우저에 노출되는 것은 큰 문제가 없다.

참고: https://caniuse.com/avif

AVIF image format | Can I use... Support tables for HTML5, CSS3, etc

 

이제 PNG와 JPG만 쓰다가 AVIF라는 포맷으로 변환하는 로직만 바꿨는데 전체적으로 60프로 이상의 트래픽 비용을 계산할 수 있었다고 한다.

PNG를 51KB 짜리 파일을 사용했는데, 이것을 WEBP포맷으로 변환하면 42KB가 되고, AVIF를 썼을 때는 20KB이하로 되었다.

 

2. JSON에 대한 CDN 캐싱

인프런 페이지에서 강의 쪽 탭을 마우스 클릭하면 여러 가지 카테고리 정보들이 나온다.

인프런 강의 카테고리

 

이러한 카테고리 정보는 추가될 수도 있고 삭제되거나 이름이 변경될 수도 있다. 그래서 DB에서 관리를 하고 백엔드에서 카테고리 정보를 내려준다고 한다. 여기에서 사용되는 트래픽 크기가 무려..

하루에 150GB.. 한달에 4.5TB..라고 한다..

이 카테고리를 그리기 위한 JSON 데이터를 내려 주는데 한달에 4.5TB를 사용하고 있던 것이다.

 

이렇게 트래픽 크기가 크다보니 DB 부하가 굉장히 높았고, 이것을 해결하기 위해 생각한 방법이 외부에 있는 원격 캐시로 데이터를 캐싱시켜서 데이터베이스 요청을 줄이는 것이였다.

하지만 결과적으로는 엘라스틱 캐시를 3대이상 운영해야 했고, 이는 DB 스펙을 한단계 더 높이는 비용과 맞먹어서 큰 의미가 없었다.

ㅂ

그 다음 사용한 방법은 로컬 캐시이다. 로컬 캐시는 서버 애플리케이션 단에서 캐싱을 하는 것인데, 위와 같은 카테고리 데이터는 복잡한 캐싱이 필요하지 않아서 선택한 방법이라고 했다.

Nest에서는 캐시 매니저 라는게 있고, 자바 진영에는 ehcache 라는 로컬 캐시 솔루션이 있다.

Cache Manager: https://docs.nestjs.com/techniques/caching

Documentation | NestJS - A progressive Node.js framework

Ehcache: https://www.ehcache.org/documentation/

Documentation

로컬 캐시로 전환하고 나니, 별도의 엘라스틱 캐시 등은 필요하지 않게 되었다.

그리고 데이터베이스의 부하는 눈에띄게 줄어든 상태가 되었다.

 

하지만 비용적으로 한가지 더 문제가 남았다. EC2의 트래픽이다.

결과적으로 데이터베이스 쪽에서의 부하는 줄였지만, 더 앞단인 EC2 서버가 받는 트래픽은 하루 150GB 한달로는 4.5TB를 여전히 받고 있었다는 것이다.

 

발표자 분께서 생각해 봤을때는 카테고리 JSON 데이터는 변경이 자주 일어나지 않고, 로컬 캐시까지 갈 필요 없이 CDN에서 캐싱하면 되지 않느냐 라는 생각을 했다고 한다. 즉, 캐시 계층을 앞으로 옮겨서 결과적으로 한 번 내려준 데이터는 CDN에서 캐싱을 하고 카테고리 데이터가 갱신되기 전까지는 바로바로 JSON을 내려주기만 하면 EC2까지 트래픽이 들어오지 않는다.

 

결과적으로 하루 150GB 한달 4.5TB의 트래픽은 CDN 비용으로만 처리하게 되었다고 한다.

결론

이 뒤에도 약 20분정도 발표를 진행 하셨다. Express -> Next.JS 전환 과정도 설명을 해주셨고, 분량 문제로 다는 작성하지 못하지만 의미있는 시간이였다.

인프런 아키텍처 2023과 비교하면, 조금 더 디테일 한 부분들이 발표 주제로 선정되어서 조금 더 집중해서 들었어야 하는 점이 인상깊었다.

글이 너무 길어질 것 같아 2편으로 나누어 작성합니다.