[인프콘 후기] 2024 INFCON

Memo/후기+회고

[인프콘 후기] 2024 INFCON

연로그 2024. 8. 3. 15:40

1. 올해도 인프콘!

올해도 인프콘 신청에 광탈했다.😇 하지만 정말 감사하게도! 문기님의 은혜로 초대권을 받아 참가할 수 있었다.👍 2022년, 2023년에 이어 올해도 인프콘에 참여할 수 있게 되어서 정말 기쁘다. 작년에도 즐길거리가 많다고 느꼈는데 올해는 인생네컷이나 라이트닝 토크 등 더 많은 이벤트를 준비하신 게 눈에 보였다. 좋은 발표도 많은데 즐길거리도 많으니 행사 시간 8시간이 모자랄 지경이다. 매년 발전하는 인프콘 존경하고 감사합니다!

이전 인프콘 후기들 바로가기

2. 세션 메모

세션에 대한 간단한 감상과 인상깊게 들은 부분에 대한 메모를 남깁니다.

실제 세션 내용은 이후 인프콘에서 공개하는 영상을 확인해 보시길 추천드립니다.

1. 지속 성장 가능한 설계를 만들어가는 방법

시작부터 강렬한 세션이었다. 발표는 '설계를 잘하는 방법은 설계를 하지 않는 것이다, 설계와 구현은 다른 것'이라는 말로 시작됐다. 모든 걸 완벽하게 설계한 뒤에야 구현(개발)을 시작하는 게 아니라, 구현부터 시작하는 걸 권장한다. 나는 늘 설계가 중요하다는 이야기를 들어왔고, 마음 한편에 설계가 잘못되면 모든 게 틀어질 거야..!!라는 부담감을 갖고 있었다. 아키텍처에 대한 책도 뒤적여본 적도 있지만, 어떤 문제를 해결하기 위해 아키텍처를 적용한다기보다는 만들다 보니 그런 형태의 아키텍처가 적용되는 경우가 많다 보니 별로 와닿지 않았다. 한데 이 발표를 통해 설계에 대한 심적 부담감을 덜 수 있었다.

세션 메모

완벽한 설계는 존재하지 않는다
- 요구사항은 계속 변한다
- 성급한 또는 과도한 설계는 모든 것을 망치기 쉽다
개념과 격벽
- 개념: 웹툰이라는 키워드를 통해 '결제', '구매', '연재', '작가' 등의 개념을 생각해 볼 수 있다.
- 격벽: 개념 간의 경계(벽). 개념의 접근에 대한 통제를 한다.
- 격벽을 적절히 세운다면, 개념에 변경이 일어날 때 변경한 개념에 관련된 코드만 수정된다
  - 격벽이 제어를 잘하지 못하는 경우: 개념이 여기저기 흩어져있어 영향 범위가 커진다
  - 개념을 너무 크게 정의한 경우: 영향 범위가 커진다. 개념을 분리할 수 있는지 검토해 보자.
구현부터 해보자
- 분석 -> 설계 -> 구현을 차례대로 진행하는 것보다 일단 시도해 보자
- 개념과 격벽을 활용해 구현해 보는 것을 권장한다
- 증명하고 피드백받으며 계속해서 구현하자. 이때 테스트코드를 이용하면 빠른 주기의 증명 및 피드백이 가능하다.

QnA

Q: 행위를 하나의 개념으로 바꾼다면 중복되는 행위에 의해 네이밍이 중복되지 않을까요? (ex: 가게를 '좋아요'한다, 상품을 '좋아요'한다에서 좋아요라는 행위에 대한 네이밍을 각각 어떻게 지을 것인가?) 네이밍에 대한 팁이 있을지 궁금합니다
A: 단순하게 행위를 그대로 네이밍에 사용하기보다는, 그 행위 속에서 본질적인 개념이 무엇인지 분석하고 해당 개념을 이용해 네이밍 할 수 있을 것 같다
Q: 모듈이나 패키지 구조 같은 건 어떻게 결정하나요?
A: 모듈/패키지를 처음부터 잘게 쪼개기보다는 처음에는 하나의 패키지에 모든 것을 개발한다. 그 후에 패키지가 너무 커지면 리네임을 하고, 필요하다면 패키지를 분리하는 등 일단 처음에는 코드부터 작성하는 편이다.
Q: 정말 중요하고 커다란 개념을 여러 개의 개념으로 쪼개고 싶다면 어떤 식으로 진행해 보는 게 좋을까요?
A: 한 번에 옮기려고 하면 전체에 영향이 가니까 굉장히 부담스러울 것. 이관용 클래스를 따로 만든다던가, 조금씩 이관할 수 있는 방법을 택한다

2. 인프런 아키텍처 2024 ~ 2025

매년 인프런 아키텍처의 변화를 흥미롭게 지켜보고 있다. 2022년에 들었을 때는 인프라를 이제 막 구축해 가며 안정화시키는 단계였고, 2023년에는 사원수의 증가에 따라 효율적인 개발을 위해 어떻게 분리할지를 고민해 왔다면, 올해 2024년에는 성능 개선에 초점을 둔 것 같았다. 우리 회사에서는 기본적으로 인프라팀이 따로 있기도 하고, 장애날 바에는 돈 쓰고 성능을 팍 늘리자는 기조이다. 그렇기에 전혀 생각 못한 부분에서의 성능 개선을 많이 시도하신 것이 신기했다.

세션 메모

이미지 트래픽 개선
- png, jpeg 같은 파일은 굉장히 용량이 크다
- avif라는 파일포맷을 이용하면 고품질의 저용량 이미지를 제공할 수 있다. (대부분의 브라우저에서도 지원된다.)
- Lambda를 이용해 S3에 보관하기 전에 리사이징, avif로 변환하는 과정을 거침
- 적용 후 전체 이미지 트래픽의 60% 감소
json을 CDN에 캐싱하기
- 잘 변경되지 않지만 정말 자주 조회되는 데이터(카테고리)에 대한 고민
- DB 부하 -> ElasticSearch 도입해 캐싱 -> ElasticSearch에 부하 -> 로컬 캐시 활용 -> json 자체를 CDN 캐시
- 주의점: CDN은 cache-control에 따라 쿠키도 캐시 할 수 있다. 맨 처음 호출한 요청의 사용자 쿠키로 모두 덮어씌워질 수 있으니 주의.

3. 사이드 프로젝트로 커리어 레벨업!

예전에 소주콘에 참가했을 때 뒤풀이 자리에서 뵈었던 분이 인프콘에서 발표를 하고 계셔서 깜짝 놀랐다. 그 당시 새로운 기술들이 너무 많아서 무엇을 어떻게 공부할지에 대한 고민이 많았는데 그때도 현우님께서 사이드 프로젝트를 추천해 주셨었다. 뭔가의 결과물을 내진 못했지만, 직접 뭔가를 만들어가며 공부하는 응원(?) 혹은 계기(?)가 되었던 기억이 난다. 인프콘 발표에서는 더 자세한 내용을 재밌게 풀어주셨다. 사이드 프로젝트는 뭔가 거창한 것을 만들어내야 할 것 같아서 부담되었는데 2~3일 내로 빨리 끝낼 수 있는 것으로 시도해 보라는 제안이 인상 깊다.

세션 메모

2~3년 차의 고민
- 다른 회사에서 사용하는 기술들을 어떻게 써보지
- 처음 사용해 보는 기술들은 어떻게 학습하지
- 특정 기술을 사용하는 현업자와 어떻게 소통하지
- -> 사이드 프로젝트로 해결 가능!
사이드 프로젝트 '잘' 하는 법
- 몰입을 유지할 수 있는 기간(2~3일) 짧게 끝낼 수 있도록 한다
- 내가 관심 있는 분야, 혹은 내가 소비자가 될 수 있는 주제로 만들어보자
두려움 없애기 - 팀으로 하면 커뮤니케이션 비용이 커서 개인으로 먼저 도전해 보는 것을 추천

4. 혹시 당신은 데이터를 모르는 백엔드 개발자 인가요?

발표 제목이 너무 나여서 들을 수밖에 없었다.🙄 비록 지금 팀에서는 DB에 직접 접근할 일이 없지만 데이터 엔지니어가 생각하는 데이터와 백엔드 엔지니어가 생각하는 데이터가 무슨 차이가 날지 궁금했다. 아쉽게도 모든 내용을 이해하진 못했지만 백엔드 엔지니어는 단순히 데이터를 보관하는 장소 정도로만 생각하는 경우가 많고, 데이터 엔지니어는 보관뿐만 아니라 관리, 분석 등 더 다양하게 사용한다고 이해했다. 우리 회사에서는 이미 대부분의 것들이 프로세스화 되어있고, DBA분들이 잘 제어해 주시기에 앞으로의 개발 방향이 크게 달라질 것 같다는 생각이 들었다.

세션 메모

데이터의 행과 열
- 백엔드 엔지니어는 행을 읽고 쓰는 게 중요하다
- 데이터 엔지니어는 열을 읽고 쓰는 게 중요하다
DB는 단순히 데이터 저장만 하는 곳이 아니다
- 데이터의 히스토리를 파악하고, 분석할 때도 사용된다
- 분석 환경은 라이브 환경에서 사용되는 DB와 별개로 분리해서 관리된다
- GIGO; Garbage In Garbage Out: 잘못된 데이터를 넣으면 잘못된 데이터가 나온다

5. 클린 스프링: 스프링 개발자를 위한 클린코드

요즘은 클린 코드를 개발에 방해되는 요소로 인지하는 사람들도 많다. 아마 책에서 또는 유명한 사람이 이 방법이 클린 코드라고 했다는 이유만으로 불필요한 상황에 과한 개발을 하는 사람들이 생겨서 그런 인식이 생겨난 게 아닐까 싶다. 토비님은 무엇을 클린 코드라고 부르는지, 어떻게 클린 코드를 작성할 수 있는지에 대해서 단순한 코드레벨이 아닌 다른 사람과 함께 협업하는 관점에 더 초점을 두고 발표해 주셨다. 타인에게 항상 친절하라며 개발은 나 혼자가 아니라 다른 사람과 함께 하는 것임을 일깨워주신 부분이 좋았다.

세션 메모

클린 코드: 읽기 좋은, 이해하기 좋은, 확장하기 좋은, 유지보수 하기 좋은 코드
'생산성'과 '유지보수성'은 배타적이거나 대치하는 개념이 아니다
유지보수가 좋은 코드를 만든다 -> 변경 가능성이 좋아진다 -> 개발 생산성이 높아진다 -> 무한반복
익숙한 기술로 핵심 기능을 동작 가능하고 가장 단순하며 리팩터링 하기 좋은 코드를 작성한다
- 여기서 단순하고 리팩터링 하기 좋다는 기준은 '내'가 아니라 '팀'이다
- 코드는 팀이 함께 보는 것이다
테스트 작성할 시간이 없어요 -> 테스트를 빨리 작성해라
- 테스트는 잠깐, 한두 번 시도해 본다고 효과를 볼 수 있는 것이 아니다
- 많은 연습을 통해 테스트를 빠르고 효과적으로 작성하는 연습을 해야 한다
팀과 함께 결정하고, 탐험하고, 학습하고, 성장하라
- great teams make great people
- 자신의 말을 할 때도 타인의 기분을 상하지 않게 하는 것이 중요하다
- 항상 친절하라

6. 객체지향은 여전히 유용한가?

객체지향적으로 작성하는 것이 좋다고 늘 들었지만, 현업에서 코드를 작성하다 보면 항상 의문이 든다. 내가 짜는 코드는 완전한 객체지향이 아니며, 이걸 객체지향적으로 작성한다고 과연 코드가 깔끔해질까?라는 의문이다. 영호님은 이 의문에 대해 깔끔하게 정리해 주신다. 모든 일에는 정답이 없고, 상황에 따라 적절히 사용하는 것이 중요하다. 특정 아키텍처나 패러다임만을 따르려다 오히려 코드의 복잡성이 증가하는 상황을 싫어하는 내게 너무 공감 가는 말이었다. 친구가 말하길 발표 후 QnA 시간도 굉장히 알찼다고 했는데 네트워킹에 참여하느라 듣지 못해서 아쉽다. 🥲

세션 메모

모든 것을 객체지향으로 표현하기보다는, 객체지향이 유용한 상황과 절차지향이 유용한 상황을 판단할 수 있어야 한다
객체지향 설계
- 데이터 변경이 일어나도 변경의 범위가 좁다
- 다른 코드를 수정하지 않고도 데이터 변경과 타입의 확장이 가능하다
- 일관성 있는 설계가 가능하다
개발하다 보면 자연스럽게 객체/절차지향을 섞어 쓰게 된다
- 예를 들어, 도메인 레이어에서는 규칙 기반으로 상태를 변경하여 객체지향적인 작성이 가능하다. 서비스 레이어에서는 애플리케이션의 플로우 처리가 일어나며 절차지향적으로 작성하게 된다. 프레젠테이션이나 퍼시스턴스 레이어에서도 데이터 변환 등의 작업을 절차지향적으로 작성한다.
단 하나의 패러다임만 이용해서 개발하기는 어렵다.
- 다양한 패러다임을 상황에 맞게 가공해서 활용해야 한다
- 어떤 패러다임이든 유용한 케이스가 존재한다. 이거 공부 안 해도 되나요?라는 생각보다는 하나의 도구를 익혀둔다 생각하며 일단 배워보자.
- 코드의 목적과 변경의 방향성에 따라 언제 어떤 기술을 사용할지 결정하라.

3. 마무리

첫 인프콘 때는 취준생이었고, 두 번째 인프콘 때는 입사한 지 얼마 안 된 신입이었다. 올해엔 아직 신입으로 취급받는 저연차 주니어지만 매년 세션을 들으면서 인지하는 수준이 조금씩 변화하는 것이 느껴졌다. 예전에는 응? 그게 당연한 거 아닌가?라고 들었던 문제들이 지금 다시 들으니 이상적으로는 맞지만 현실적으로는 저런 문제가 발생할 수 있지 않나? 아, 나와 같은 생각을 이미 하셨고 저런 식으로 풀어나가셨구나! 같은 소감으로 이어진 것 같다. 앞으로도 연차가 쌓이고 다양한 경험을 하다 보면 같은 내용도 다르게 받아들이고 더 깊게 사고할 수 있게 될 것이라 기대하며, 설레는 미래를 기다려본다.🙂

원래는 세션 몇 개 듣기만 하다 돌아올 생각이었는데, 인프콘에 처음 참여한 친구와 함께 다니면서 다양한 이벤트를 적극적으로 참여했다. 스탬프 투어를 끝까지 완료해서 티셔츠나 컵 같은 굿즈 선물을 받기도 하고, 네트워킹 파티를 통해 다양한 사람들과 인사하기도 했다. 낯을 많이 가리는 편이라 작년 네트워킹 파티에서는 쭈뼛대기만 하다 돌아왔는데, 올해는 친구랑 함께 가서 용기가 생겼나 보다. 처음 보는 사람들에게 말을 걸며 같이 대화를 나눴다. 아는 분 드리려고 챙겼던 명함도 다 소진하고, 링크드인 친구가 늘었다. 친구와 같은 곳에서 근무하시는 분도 만나 뵈었다. 놀랍고 신기한 만남의 연속이었다.ㅋㅋㅋ

요 근래 야근은 많이 하는데 기술적 고민을 한지는 오래돼서 일이 재미가 없다고 느끼기도 했다. 역시 컨퍼런스에 다녀오니까 의욕이 생기며 뭐라도 도전해보고 싶다는 생각이 들었다. 다음 주에 출근하면 일단 http파일만 존재하는 우리 API에 테스트 코드를 하나라도 생성해 주는 게 목표다. 사이드 프로젝트로 만들만한 주제도 한번 생각해 보아야겠다.

올해도 잘 다녀왔습니다 인프콘! 감사합니다!