INFCON 2024

 

 

인프콘에 가기까지

어느 날 메일을 확인하는데 인프런으로부터 유저 인터뷰를 요청하는 메일이 와있었다. 

 

혜택에 그렇게 가기 힘들다는, 내가 2년 연속 광탈한 그 인프콘 티켓이 있었지만 워낙 이런 당첨 운이 없기 때문에 큰 기대없이 작성해서 제출했다. 그래서 내가 어떤 내용을 작성했는지 스크린샷을 남겨두지도 않았다. 그런데。。。

 

 

내가 당첨이라니⎝⍥⎠!  문자로 먼저 받자마자 싱글벙글한 채로 과장님께 자랑해서 나중에 로또라도 당첨된 줄 아셨다고 했다. 감사합니다 인프런, 사랑해요 인프콘!

 

 

인프콘 2024

이름표와 팜플렛, 인프콘 가방 그리고 생수를 받아 입장한 인프콘! 팜플렛에는 스탬프 투어 페이지가 있어서 인프콘에서 어떤 프로그램에 참여할 수 있는지 한 눈에 확인할 수 있었는데 다 참여해서 굿즈는 꼭 받아가리라 다짐했다,, 언제 또 올 수 있을지 모르니까 🥲 그리고 돌아다니면서 느낀 건데 팜플렛에 스탬프 투어가 있어서 그런지 이벤트에 참여하시는 분들이 많아서 다들 혼자 오셔도 자연스럽게 참여하게 되는 분위기였다. 네트워킹하는 장소에 참여자들 이름을 새긴 화면이 있었는데 그때는 발견 못했지만 사진 올리면서 내 이름을 발견했다 💚

사실 너무 설레서 사진을 많이 못 찍었다

 

 

세션은 총 6개를 들었는데 늦게나마 간략하게 정리해본다.

 

 

1. [지속 성장 가능한 설계를 만들어가는 방법 | 토스페이먼츠, 김재민]

소프트웨어를 개발할 때 항상 언급되는 '설계'.
여러분은 설계란 단어를 보면 어떤 것이 떠오르시나요?
이 발표에서는 설계란 무엇이고, 어떻게 접근할 지에 대해 생각할 거리를 던집니다.
그리고 몇 가지 관점과 예제로 살펴봅니다.
결론적으로 우리가 개발할 때 정말로 집중해야 할 것이 무엇인지에 대해 이야기해 보려 합니다.

 

"설계를 잘하는 법은 설계를 하지 않는 것이다."라는 파격적인 문장으로 세션이 시작됐다. 핵심은 "설계"보다는 "구현"에 있으며 구현을 잘하기 위한 핵심적인 개념을 소개해 주셨다. 그 두 키워드는 개념과 격벽인데 개념 간의 참조를 격벽을 통해 어떻게 제어할 수 있는지를 대출 서비스, 커미스 서비스와 관련된 코드를 통해 설명해 주시는데 이해가 정말 잘 갔다. 

 

특히 대출 서비스에서 신청, 실행, 상환을 개념으로 두고 볼 때 상환 실패에 따라 파생되는 클래스(상환 재시도, 이자 추가 등)들을 방지하기 위해 연체라는 개념을 추가해서 해결하는 과정을 보는 게 재미있었다. 저절로 "우리 코드는 어땠지?" 하고 떠올리게 됐다.

 

또 기억에 남는 말씀은 우리가 만드는 것은 하드웨어가 아닌 소프트웨어라는 것. 요구 사항이 계속해서 변하는 것에 대해 조금 더 유연한 사고를 가질 수 있게 되었다. 

세션 내용을 토대로 정리해 본 간략한 표

 

<<Note>>

• 지금 이 순간에 할 수 있는 최소한의 구현하기
• 끊임없이 증명하고 피드백하며 개념과 격벽 재정의하기
• Test와 Code로 위의 과정을 해낼 수 있는 환경 구성하기
• 위의 과정을 통해 설계를 완성해 나가자!

 

 

2. [인프런 아키텍처 | 이동욱]

작년 발표 이후 1년간 인프런 아키텍처가 어떤 변화가 어떤 이유로 진행되었는지 소개 합니다.

새로운 구조나 아키텍처로 개편하는 과정에 대한 이야기들은 많지만 그런 개편 이후 1년, 2년이 지나서 어떤 결과가 만들어지는지에 대한 소개는 많이 없습니다.

인프런에서는 2022년부터 지속적으로 아키텍처를 점진적으로 개선하고 있으며, 2년전의 결정이 지금은 어떻게 되었는지 등 결과도 함께 경험하고 있습니다.

최근 1년 간은 비용 절감, Next.js 기반의 SSR, CSR, SPA 환경과 기존 Express SSR 과의 공존, 글로벌 플랫폼을 가기 위한 기반 작업 등등 여러 관심사를 해결하기 위한 노력들을 해왔습니다.

인프런 서비스가 지난 1년 간 어떠한 문제를 해결하기 위해 어떤 노력들을 해왔는지 소개합니다.

 

개발바닥 영상으로만 보던 그분을 드디어 실물 영접했던 세션. 인프런이 작년에는 어떤 고민을 했으며 현재 어떤 과정을 거치고 있는지를 알 수 있었다. 비효율적이 트래픽을 개선하기 위해 이미지 트래픽과 카테고리 정보들을 캐싱해가며 선택했던 기술들에 대한 이야기를 나눠주셨는데 정말 재미있었다. 관련 키워드는 avi 파일, Caching, Cloud Front로 관심이 있으신 분이 이 글을 보고 계신다면 꼭 인프콘 다시보기로 보시길 바란다. 어떤 것을 채택했거나 채택하지 않은 이유와 그 결과로 몇 퍼센트의 트래픽 비용이 감소되었는지 혹은 무의미한 결과를 얻었다든지 하는 각종 히스토리를 같이 훑는 느낌이었다.

 

그리고 레거시 프로젝트를 개편하기 위해 사용자과 개발자에게 라우팅할 api를 다르게 설정하고 싶을 때 인프런이 왜 traefik을 채택했는지에 대한 이야기도 들을 수 있었다. 

 

 

<<Note>>

 

펠리컨적 사고를 지니자! 일단 시도하고 넘어지더라도 뒤가 아닌 앞으로 넘어지자.

 

 

 

3. [경력이 늘수록 CS이론이 중요해지는 이유 | 최호성]

어렵게 취업에 성공했더라도 CS이론에 대한 한계 때문에 이직을 고민하는 경우가 많습니다. 특히 새로운 플랫폼과 프레임워크 변화에 빠르게 대응해야 하는 상황이 연속된다면 고민이 더 커지는 것이 현실입니다. 그리고 경력이 늘 수록 CS이론에 대한 결핍은 더 크게 느끼게 됩니다. 결국 CS이론을 공부하는 것이 문제해결 방법이겠습니다. 그러나 무엇을 어디서부터 시작해야 하는 것인지 방향을 정하는 것조차 비전공자에게는 쉬운 일은 아닙니다. 이러한 문제를 해결하고자 지난 2~30년 간 제가 했던 경험을 하나의 예로 공유하고자 합니다.

 

이 분은 유튜브에서 널널한 개발자 TV라는 채널을 운영하고 계신다. 내가 정말 영향을 많이 받았던 주니어 개발자 스터디를 같이 하신 분이 채널 멤버십까지 가입해서 보던 채널이라 이후에 나도 구독하며 영상을 보고 있었다. 항상 커뮤니티에 학생들 강의 저렴하게 보라며 쿠폰을 올리시면 사용은 안 하더라도 괜히 응원하고 싶은 마음에 보일 때마다 좋아요를 눌러드리곤 했다. 

 

이번 세션은 비교적 가볍게 들을 수 있었는데 개발자들이 초기에 CS 이론을 공부하지 않았을 때 나중에 어떤 성장의 한계를 느끼게 되는지, 그리고 현재 개발자들이 이와 관련해서 어떤 고민을 가지고 있는지에 관련된 내용이었다. CS 이론을 공부했을 때 언어, 프레임워크에 대한 이해도가 높아지고 그렇게 되면 상대적으로 환경 전환이 쉬워진다는 말씀에 그동안 선배 개발자 분들에게 많이 듣기도 했고 나도 느꼈던 부분이라 굉장히 공감이 갔다. 그리고 CS 이론을 익히기 위해서는 어쩔 수 없이 반복적으로 봐야한다고 하셨는데 이번에 네트워크 관련 책을 읽으면서 많이 까먹었다는 사실을 느껴서 평소에 틈틈히 봐야겠다는 생각을 했다. 역시 말씀을 잘하셔서 정말 물 흐르듯 흘러갔던 세션이었다.

 

 

<<Note>>

• 개발자의 기본기가 충실하다면 새로운 프레임워크가 놀랍지 않다.
• CS 근본은 변화하지 않는다.
• 상대적으로 환경 전환이 쉬워진다.

 

 

 

4. [목적 조직 구조 안에서 개발 팀이 일하는 법 | 인프랩]

드디어 세션 사진을 찍다

예전까지 많은 IT 회사에서는 PM팀/디자인팀/개발팀 으로 구분되는 기능 조직의 형태로 운영해왔습니다.

반면 현재는 서비스 내 여러 제품을 중심으로 한 각각의 목적 조직 (해당 제품과 관련된 PM, 디자인, 개발이 한 조직에 모인) 형태를 하고 있습니다.

같은 직무가 아닌 서로 다른 직무의 사람들이 소수로 모여있는 조직에서 개발자는 어떻게 일을 해야할까요?

어떤 방식으로 소통하고, 성과를 내고, 성장을 할 수 있을지에 대해 인프랩 개발 조직의 이야기를 전달합니다.

 

 

이번 세션은 여러 직군들이 한 팀에 포함된 목적조직으로 어떤 식으로 업무를 해나가는지에 대한 이야기를 패널들과의 토크 형식으로 진행됐다. 예를 들면 아래와 같은 형태이다.

 

Q3. 여러 조직들 간 어떻게 협업하는가?

A. 주에 2회 모임이 있다. 첫 번째 모임은 개발 팀 전체 모임으로 회사의 목표를 다시 상기시키는 역할을 하며 한 주 동안 발생했던 장애 대응에 대해 공유하기도 한다. 두 번째 모임은 각 파트의 모임으로 파트 별로 기술적인 내용에 대해 이야기를 나눈다. 예를 들어 슬로우 쿼리가 발생한 이유와 해결 방법에 대한 이야기나, 코딩 컨벤션 및 자동화 방법 등에 대해 공유한다. 그래서 주문, 결제 조직이 아니라도 개발 히스토리에 대해 공유 받을 수 있다.

 

각 답변들을 들으면서 인프랩은 문서화나 기술 공유가 활발히 이루어진다는 걸 알 수 있었다. 나는 항상 다른 팀은 어떤 개발 방법론을 도입했는지 어떤 기술을 쓰며 인프라 구성은 어떻게 되어있는지 혹은 장애가 발생했을 때 어떻게 대응했는지를 궁금해 하는데 딱 이 내용이 나와서 놀랐다. 내가 지금 맡은 프로젝트에서는 겪지 못하지만 어깨 너머로라도 듣고 싶고 배우고 싶은데, 공유 문화가 정착되지 않은 곳에서는 그렇게 하기가 쉽지 않다고 느낀다. 그런 면에서 인프랩의 기술 문화가 굉장히 부러웠고 또 한번 공유의 힘을 느끼게 된 시간이었다.

 

 

 

5. [클린 스프링: 스프링 개발자를 위한 클린코드 전략 | 토비(이일민)]

클린 코드가 제시하는 코딩 센스를 가지고 우수한 유지보수성을 가진 애플리케이션을 개발하는 원칙과 전략을 스프링 개발에 적용하는 방법을 살펴봅니다.

 

대스타 토비님의 세션. 아마 이전 세션이 끝나고 굿즈를 수령하러 짐을 두고 나갔던 것 같은데 밖에 줄이 엄청나게 늘어져있는 걸 보고 놀랐던 기억이 난다.

 

이번 세션은 "클린 코드"에 대한 내용이었는데 "클린 코드를 작성하면 구현 능력이 떨어진다."라는 이야기부터 시작이 됐다. 우선 클린 코드란 유지 보수성을 추구하는 코드를 말한다. 읽기 좋고, 이해하기 좋으며 확장성이 좋은 코드가 과연 생산성을 떨어뜨릴까? 토비님은 생산성과 유지 보수성은 대치의 개념이 아닌 서로 영향을 주는 관계라고 말씀하셨다. 클린 코드 없이 빠르게 구현한다면 기술 부채가 생기고 시간이 지나면 지날수록 이 부채를 해결하기가 어려워지고야 만다. 그렇기 때문에 "클린 코드 선순환"을 생각해야 하는데 그 과정은 다음과 같다.

• 유지보수성이 좋은 코드는 변경 가능성이 좋다.
• 빠르게 변경하면 생산성이 올라간다.

 

위 이야기와 더불어 다른 이야기도 들으면서 지난 번에 읽은 <이펙티브 엔지니어>가 생각났다. 그 책에서도 기술 부채에 대한 이야기가 나오고 팀으로서 성장하는 것이 얼마나 중요한지에 대해 나오는데 훌륭한 시니어 개발자 분들이 들려주고자 하는 이야기는 다 같구나라는 생각이 들어 더 재미있고 뜻깊었다. 

 

 

<<Note>>

• 핵심 기능에 집중하여 동작하는 코드를 가장 단순하고 리팩토링하기 좋게 작성하자.
• Great teams make great people. 나만을 위한 클린 코드는 없다. 팀과 함께 결정하고 탐험하고 학습하고 성장한다.
• 친절하자. 자신의 말을 하더라도 다른 사람의 기분을 나쁘게 하지 말자.
• 나에게도, 동료 개발자들에게도 친절한 코드를 작성하자.

 

 

6. [하루 1억 건 이상을 처리하는 견고한 포인트 시스템 구축하기 | 버즈빌, 서주은]

버즈빌의 리워드 광고 서비스를 통해 유저는 하루에도 수십 번 이상 광고를 보고 포인트를 적립받습니다. 이렇게 쌓이는 포인트는 일 1억 건 이상이며 이를 안정적으로 처리하는 것은 매우 도전적인 과제입니다. 또한, 포인트 데이터는 돈과 관련된 중요한 데이터이기에 한 치의 오차도 없이 정확하게 관리되어야 합니다.

이러한 요구사항을 충족시키기 위해 학교에서 배운 낙관적 락을 어떻게 활용했는지 살펴보고, 초기 설계부터 최종 설계까지의 고민 과정을 공유합니다. 또한, MySQL과 AWS의 관리형 NoSQL 데이터베이스인 DynamoDB를 이용해 구현하는 방법도 소개합니다.

 

현재 회사에 포인트 적립 기능이 구현되어있지만 잘 알지 못하기도 하고 다른 회사에서는 어떻게 구현하시고 어떤 고민을 하셨는지가 듣고 싶어서 듣게된 세션이다. 전반적으로 포인트 시스템을 개발하시면서 어떤 시행착오를 겪었는지에 대한 이야기를 들려주셨다.

 

포인트에는 다양한 타입이 존재하는데 어떻게 포인트를 얻느냐에 대한 방법들로 구분된다. 예를 들어, 광고를 클릭했다면 "광고 클릭", 미션을 완료했다면 "미션 완료"와 같은 타입이다. 처음에는 각 타입에 따른 내역 테이블을 생성해서 관리했는데 한 유저의 포인트 합계를 계산하려면 모든 내역 테이블을 조회했어야 해서 성능이 저하되었고 여러 고민을 하다가 결국에는 point_history 테이블에 포인트 잔액 필드를 추가하고 내역을 계속 쌓게 구현하셨다고 했다. 이때 동시성 문제로 인해 낙관적 락을 적용했는데 version과 id로 유니크 키를 생성해서 활용했다고 하셔서 우리 회사는 어떻게 동시성 문제를 해결하고 있을까 궁금해졌다.

 

이외에도 데이터가 점차 쌓여가면서 데이터베이스 성능을 개선하기 위해 DynamoDB를 선택, 분석에 관련된 데이터는 Data lake로 S3를 활용한 이야기도 해주셨는데 둘에 대해 더 자세히 알지 못해서 그 장점을 빠르게 이해하지 못해 아쉬웠다. 

 

이번 세션이 끝나고 나서는 Q&A 시간도 참여해서 따로 마련된 장소에서 소수의 인원들과 이야기를 나눌 수 있었다. 사실 분석 데이터를 관리하고 활용하는 부분에 대한 이야기를 더 자세히 듣고 싶어 참여했지만 기반 지식이 부족한 것 같아 질문은 하지 않고 다른 분들의 질문에 대해 답변해 주시는 것을 열심히 듣고 왔다. 나중에 또 참여할 기회가 생긴다면 그때는 적극적으로 질문하고 값진 조언을 얻을 수 있으면 좋겠다.

 

 

<<Note>>

금융 시스템 구축을 위한 엔지니어링 규칙

• Immutable and Durable - 데이터의 불변성과 내구성
• Data recorded at the smallest grain - 데이터는 가장 작은 단위로 표현되어야 한다.
• Idempotency - 멱등성

 

 

인프콘이 끝나고

길이 무진장 길었던 무신사 부스에서 받은 굿즈와 여기어때 부스에서 받은 캠핑 의자를 포함한 여러 굿즈들을 받다 보니 어느새 나눠주신 가방에 짐이 한가득 채워졌다. 그리고 다행히도 이 짐들에 내가 다짐했던 인프런 굿즈도 포함시킬 수 있었다.

 

잠깐 굿즈 받을 때 얘기를 해보자면 4시가 훨씬 지나면 소진될까봐 시간에 맞춰서 가야겠다는 생각을 했었다. 그래서 세션이 끝나자마자 자리를 박차고 나가서 2층으로 갔는데 어떤 긴 줄이 행사장 바깥까지 이어져있었다. 설마하고 안쪽으로 들어가서 확인해 보니 아니나 다를까 굿즈 줄이 맞았다. 그래서 다시 급하게 뒤로 줄을 서면서 세션에 시간 맞춰서 들어가긴 힘들겠구나 했는데 다행히 세션이 시작된지 얼마 안 됐을 때 자리에 앉을 수 있었다. 운영팀 분들이 줄 정리도 잘해주시고 굿즈를 빠르게 나눠주셔서 운이 좋았던 것 같다. 

 

 

굿즈들이 모두 퀄리티가 좋고 귀엽고 예쁘고 다해서 집에 와서 구경하고 사진찍는 데만 한참이 걸렸다. 컵은 깨뜨릴까봐 무서워서 아직 꺼내놓진 못하고 티셔츠만 입고 다니는 중이다 (꜆ ˙-˙ )꜆ 💚

 

사실 이렇게 큰 개발 행사에 참여한 게 처음이어서 비록 내가 당장 적용할 수 없는 이야기들과 기술들일지라도 직접 시니어 개발자 분들에게 시행착오 과정과 개선 방법을 들을 수 있다는 것이 더 행복하게 느껴졌다. 예전에는 "멋있다. 나도 저렇게 되고싶다."에 그쳤다면 이번에는 "우리 회사에는 어떻게 구현되어 있더라? 내가 구현한다면 어떻게 해볼 수 있을까?"를 생각하게 되서 더 재미있었다. 다음 행사에 참여했을 때는 더 느끼는 바가 많아졌으면 하고 바라게 됐다.

 

그런데 듣고 싶은 세션들을 시간대가 겹쳐있는 바람에 듣지 못한 건 조금 아쉽긴 했다. 특히 조영호님 세션은 책을 너무 잘 읽었고 또 주제가 "객체지향은 여전히 유용한가?"라서 정말 고민이 많았다. 작년에 어느 기업 2차 면접에 갔는데 "객체지향의 사실과 오해"라는 책에 대한 질문을 받은 적이 있다. 그래서 어떤 책인지에 대해 설명하고 느낀점을 이야기하니 면접관이 굉장히 퉁명스럽게 "당연한 소리 아닌가?"하며 굳이 왜 읽었냐는 식으로 핀잔을 줬었다. 심히 좋지 않은 경험이었어서 그런지 더 듣고 싶었던 것 같다. 지금은 인프런의 은혜로 다시보기를 볼 수 있기 때문에 참으로 다행이고 감사하다. 당연한 거 더 더 배우고 똑똑해져야겠다.

 

아무튼 굉장히 좋은 기억으로 남은 인프콘이었다. 내년에도 기회가 있기를!

감사합니다 인프런, 사랑해요 인프콘!