인프콘 2022 후기

작성: 2022.08.27

수정: 2022.08.27

읽는시간: 00 분

Development/DevLife

반응형

안녕하세요. 2023 인프콘을 기대하며 세션 시간표를 작성 해 보았습니다.

https://www.inflearn.com/infcon-2023/schedule/share?id=907252&hash=shane%409626f5a3&name=shanePark

2023년에도 참여하고 싶은 세션들이 너무 많아서 꼭 참여하고 싶었지만 추첨에 실패했었습니다.
아쉬운 마음에 인프콘 시간표 공유 이벤트에 참여했고 선정된 덕분에 인프콘 2023에도 참여할 수 있게 되었습니다.
2022년 인프콘에 참여했을때 너무 좋은 경험이었고, 높은 경쟁으로 인해서 아쉽게 가지 못했던 분들을 위해서 후기를 열심히 작성해보았습니다.

참고가 되었으면 좋겠습니다 :)

infcon

Intro

기다리고 기다리던 인프콘을 다녀왔습니다.

컨퍼런스 참여를 위해 연차를 내야 했고, 제법은 먼 거리를 다녀 왔지만 너무나도 즐거운 경험이었습니다.

참석을 원했음도 추첨 인원의 한계로 인해서 참여할 수 없었던 많은 분들이 있는걸 알기에 제가 참여했던 세션들에 대해 참여 후기를 남겨보려 합니다.

함께 참여했던 분들은 그 여운을 만끽할 수 있고, 참석하지 못했던 분들도 현장을 간접적으로나마 경험할 수 있는 글이 되었으면 합니다.

찾아가는길

daejeonIMG_8141 Medium

대전에서 가다 보니 SRT 열차를 이용했습니다. 수서역이 COEX 에서 멀지 않아 시간은 오래 걸리지 않습니다.

인프콘 2022는 강남구 삼성동 COEX 그랜드볼룸에서 열렸습니다.

사실 지방에 살다보니 잘 몰라서.. 마냥 코엑스에 가면 쉽게 찾겠거니 했었는데, 막상 도착해서는 정말 많이 헤멨습니다.

IMG_8144 Medium

코엑스를 x,y 축으로 O(MN) 복잡도의 완전 탐색을 하고 나서야 간신히 구석에 있던 인프콘 등록 테스크를 찾아낼 수 있었습니다.

줄은 원하는 티셔츠 사이즈의 라인에 서면 되는데, 매우 빠르게 진행되기 때문에 딱히 병목현상은 없었습니다.

이제 등록 데스크에서 아침에 문자메시지로 전달 받은 QR 코드를 등록 하고 나면 참가자 패키지를 받습니다.

참가자 패키지 구성품은 아래와 같습니다.

IMG_8146 Medium

  • 인프콘 반팔 티셔츠
  • 인프콘 스티커
  • 인프콘 볼펜
  • 인프콘 마스크
  • 인프콘 생수
  • 명찰 및 목걸이
  • 인프콘 스탬프 투어용 리플렛

이벤트존

IMG_8142 Medium

여러가지 인프콘 부스 프로그램에 참여 하면 참여스탬프를 3개 모을 때 마다 돌림판을 돌려 깜짝 선물을 받을 수 있습니다.

일단 행사장 구조를 다 파악하기도 전에 부랴부랴 이벤트 참여를 했습니다.

방명록존

가장 먼저 참여한 부스는 방명록 부스 입니다.

https://github.com/inflearn/infcon2022-guestbook 에 방명록을 적고 PR을 남기면 도장을 한개 받을 수 있습니다.

방명록은 Merge가 이루어지면 https://tech.inflab.com/infcon2022-guestbook/ 에 남습니다.

비즈니스존

일단 최대한 빠르게 룰렛을 한번 돌려보기 위해 방명록->비즈니스->지식공유존을 거쳐 이벤트존에서 룰렛을 돌리는 최단거리 알고리즘을 가동 했고, 그걸 위해 비즈니스 존을 들렀습니다.

사실 이미 재직중인 회사에서 인프런 비즈니스를 지원 해 주고 있기 때문에 스탬프만 받고 지났는데요, 그런 프로그램이 없는 회사라면 한번 쯤 회사에 제안을 해 보실 수 있는 좋은 기회라고 생각합니다.

지식공유존

지식 공유자를 모집 하고 있는 이벤트 부스 입니다. 사실 아직 1년차 개발자로서 지식공유자가 된다는건 머나먼 일처럼 느껴지지만, 인프런을 통해 성장에 많은 도움을 받은 만큼, 저도 블로그를에 작은 지식을 공유하는 것 부터 시작해서 머지 않은 미래에 더 많은 분들에게 제가 받은 지식을 나눌 수 있게 되길 희망합니다.

지식공유를 희망 하시는 분은 인프랩 Content MD인 유진님에게 이메일을 남겨보시면 친절하게 상담 해 주신다고 하니 고민 말고 연락 해 주세요. yujinseong@inflab.com

이벤트 룰렛

IMG_8148 Medium

마침내 3개의 도장을 받아 첫번째 돌림판을 돌렸습니다.

IMG_8149%20Medium.png 14-49-57-772

에너지바와 당충전 시간이 둘이 합쳐 약 50%의 무시무시한 커버리지를 차지하고 있는데요, 그럼에도 저는 가장 원했던 인프런 후드티에 당첨되었습니다!

IMG_8166 Medium

IMG_8242 Medium

돌림판이라는 특성상 병목이 심하게 생겨 줄도 너무 길고, 돌림판 운영 시간과 발표 세션 참여 시간이 겹치는 바람에 두번째, 세번째 돌림판은 스탬프를 다 모았음에도 참여할 수 없었던건 아쉬움으로 남았습니다.

기업부스

IMG_8162 Medium 2

당근마켓, LINE, MUSINSA, 야놀자, 오늘의집, 우아한형제들, JETBRAINS, toss의 기업 부스가 준비되어 있었는데요. 보통은 인재 풀에 등록을 하거나 간단한 설문을 작성 하고 스탬프 및 기념품을 받아가는 구조로 되어 있었습니다.

MUSINSA

IMG_8163 Medium

image-20220827150431519

무신사에서는 티셔츠를 준비 해 주었는데요, M에 동그라미 쳐 있지만 굉장히 박시한게 실제로는 XL 사이즈 쯤 되었습니다.

I am a Developer 라는 난이도가 제법 있는 문구가 적혀 있습니다.

JetBrains

image-20220827151904181

jetBrains에서는 설문조사를 하고나면 경품 탁구공을 뽑는데요, 저는 마우스패드를 받았습니다.

그 외에 원하는 스티커를 골라가면 되는데 IntelliJ IDEA 스티커는 진작에 다 나가고 없어서 YouTrack과 WebStrom을 받아 왔습니다. YT 스티커를 집자 마자 직원분이 반가워하시며 오~ 유트랙 업무에 쓰시나요 라고 물어보시기에 당황해서 아뇨.. 젯브레인스에 버그리포트 할때만 잠깐 써봤어요.. 라고 대답했습니다.

https://youtrack.jetbrains.com/issue/IDEA-291826 에 5개월 전에 이슈를 남겼을 때 2022.2 버전에서 수정 해 준다고 약속 했었는데 최근 버전에서 실제로 명시적으로 타입 캐스팅을 하도록 수정을 해 줬네요.

image-20220827151546729

image-20220827151557331

Line

image-20220827151914374

라인 부스에서는 LINE DEV 스티커와 라인 볼펜, 그리고 Armeria 방향제를 받았습니다.

그 외

IMG_8177 Medium

야놀자에서는 맛있는 초코쿠키를 줘서 한창 배고플 때 받아와서 먹고 버틸 수 있었습니다. 그 외에 다른 기업들은 시간이 부족해서 방문을 하지 못했습니다.

토스에서는 티셔츠와 슬리퍼를 줬던 것 같은데 인기도 가장 많고, 선물 사이즈도 가장 컸습니다. 모든 기업부스를 방문해보지 못한 것도 아쉬움이 남네요.

오프닝

CEO 이형주님, CTO 이동욱님, 커뮤니티 리드 홍연의님 순서로 10분씩 오프닝 키노트를 진행 해 주셨습니다.

CEO 형주님

IMG_8153 Medium

인프런이 IT플랫폼으로서 어떤 마음으로 시작을 했으며, 인프런이 얼마나 IT 생태계에 진심인지를 전달하는 영상과 프레젠테이션을 준비 해 주셨습니다.

워낙에 많은 분들 앞에서 스피치를 하다 보니 발표하시며 내부적으로 수많은 예외가 발생하신 모양 이었는데요.. 참 남일 같지 않았는데 저였다면 에러를 외부로 throw 하거나 프로그램이 종료되었을 것 같은 상황에서도 대표의 책임감으로 끊임없이 try{}catch(Exception e){} 해내신 덕에 오버헤드는 다소 있었으나 무사히 발표를 마치셨습니다.

배우고 나누고 성장하세요라는 인프런의 슬로건에 대한 진심을 느낄 수 있었습니다.

CTO 향로님

IMG_8159 Medium

인프랩이 교육사이트에서 끝나지 않고 IT 플랫폼으로 계속 확장해 나가는 과정에서 그것을 실현하기 위한 앞으로의 계획에 대해 말씀하셨습니다.

인프런과 랫릿의 통합 계획 및 불편했던 에디터의 변경 계획등을 언급 하셨는데요, 특히 한국어판 스택오버플로가 되었으면 한다는게 인상 깊었습니다.

안그래도 요즘 SEO에도 신경을 썼는지 개발 과정에서 검색을 했을때 인프런의 질문답변이 구글 검색의 첫페이지에 뜨는 경우도 많아지고 있음을 느끼고 있었는데 좋아하는 기업인 만큼 더욱 더 잘 되었으면 좋겠습니다.

커뮤니티 리드 홍연의님

연의님은 라인개발실록 유튜브 채널에서 민우님과 라인 디벨로퍼 릴레이션스 소속으로 나오신 모습만 봤었는데, 인프랩으로 직장을 옮기신 모양이더라고요.

얼마전 동욱님이 개발바닥에서 LINE에서 데브랠을 하셨던 분이 올해초에 경력직으로 입사했다고 하셨을 때 누군지는 모르고 그런가보다 했었는데 인프콘의 책임자로 올라오신걸 보니 놀랍기도 하고 반가웠습니다.

연의님은 전반적인 행사에 대한 소개 및 즐기는 방법에 대해 안내 해 주셨습니다.

참여한 발표세션들과 그 후기

제가 참여했던 세션들의 내용과 그 후기를 남겨 보았습니다. 간절히 원했음에도 아쉽게 선정되지 못한 분들이 많다보니 나름의 사명감으로 열심히 발표 세션들을 들었고, 그 내용들을 간략하게 정리 해 보았습니다. 사실 인프콘이 종료 된 후에 유투브 영상이 올라온다고 해서 영상을 보고 내용을 기억해내며 글을 작성하고 했었는데 시간이 좀 필요한지 영상이 아직 올라오지 않았더라구요.. 필기와 기억에 의존해서 글을 작성 해 보았습니다.

실리콘밸리로 떠나는 비전공자 개발자의 지난 4년 회고

IMG_8164 Medium

체대 출신 개발자의 회고라는 글로 잘 알려진 Pixelic 한정수님의 발표 입니다.

대학에서 체육을 전공하고, 무역회사 경험을 통해 온라인 무역회사도 창업 해 보고 그 과정에서 개발에 흥미를 느껴 국비지원 교육을 받으며 개발자의 길을 걷게 된 이야기에 대해 해 주셨습니다.

개발자가 되기까지의 과정에 대해서는 정수님의 인프런 강의 혹은 블로그에서 확인 하실 수 있습니다.

이번 발표에서는 개발자가 된 후 4년의 이야기에 대해서 말씀 해 주셨는데요 사실 처음 취업을 할 때 부터 누군가에게 이런 이야기를 듣기를 간절히 원해 왔지만 좀처럼 기회가 없었습니다. 처음 취업할때는 주변에 개발자는 없고 이런 이야기는 너무 듣고 싶어 면접 과정에서 이런 관련된 질문을 했다가 어이없다는 목소리로 "그게 왜 궁금해요?" 라며 면박을 받기도 했었는데 그런 의미에서 정말로 좋은 기회였습니다.

이제 시작하는 개발자들에게 정말 좋은 조언이 아닐까 싶어요. 1년전의 저에게 혹은 취업을 앞둔 분들에게 꼭 들려주고 싶은 그런 이야기 입니다.

준비를 얼마나 완벽 주의로 철저하게 하셨는지 1분도 어긋나지 않고 정확한 시간에 발표를 마치셨습니다.

1년차. 스타트업

  • 첫 직장 클라우드 캐시에서 연봉 2600만원을 받으며 커리어 시작. 개발자는 단 3명.

  • 면접에서 최종 과제로 베트남 P2P 대출시장에 대한 조사 및 보고를 해 오라고 함. 보고서의 내용에 따라 최종 합격을 결정한다는 황당한 제안

  • 일을 하지 않는 CTO. 웹툰을 보고 있지만 머리속으로는 아키텍처를 짜고 있다.

  • 7개월간 제품개발은 없고 이런이런걸 공부해 놓아라 라고만 전달받음

  • 입사 후 4개월이 지나자 임금이 체불되기 시작하고 실내흡연이 있는 사무실의 구석을 빌려 쓰며 고통받기 시작

  • 입사 7개월만에 이직할 회사를 결정하지도 못한 채 퇴사

좋았던 선택

  • 학습한 내용을 Github 이나 블로그에 정리
  • 회사에 Git & Github을 통한 리뷰 환경 문화를 구축
  • 전공자와의 CS 기초 스터디 참여 (OS, 컴퓨터구조, 알고리즘 및 자료구조)
  • 개발 커리어 세미나에 참여해 앞서간 이들의 이야기도 듣고, 같은 노력쟁이들과의 네트워크를 구축해둔 덕에 후에 취업에 도움이 됨
  • Zoom 코딩 테스트를 포기하지 않은 것. 회사일이 바빠서 포기할 뻔 했지만 연기를 요청했고 받아들여짐

후회되는 선택

  • 코딩 테스트 준비를 미리 해두지 않은 것
  • 우아한 테크캠프 2기에 지원하지 않은 것
  • 더 빠르게 퇴사하지 않은 것. 성장하기 어려운 환경과 성장이 불가능한 콘크리트 바닥은 결코 다르다.

2년차. zoom internet

  • 팀원 16명. 연봉 54% 상승

  • 수습기간 파일럿 프로젝트를 하며 1개월동안 혼자 공부했던 지난 7개월보다 많은 성장을 함

  • 처음으로 서비스 개발 및 배포를 경험해봄 (뉴스줌)

  • IDC -> AWS 로의 마이그레이션 경험

  • 회사 기술블로그에 글을 기고해봄

좋았던 선택

  • 이직 타이밍 : 편한 것보다 빠른 성장을 추구하고 주변 선배들의 네카라 이직에 자극을 받음
  • 도메인 선택 및 이직 : 백엔드의 분야에서의 꽃은 결제분야라는 생각을 하고 안정성이나 트랜잭션, 고가용성과 내 결함성등을 경험하기 위해 도메인을 선택해서 이직을 준비. 보통은 많은 회사를 지원하고 그 중 고르는게 일반적이지만 같은 도메인을 지원해서 면접 경험도 비슷하고 할수록 자신감이 생김
  • 출퇴근길 개발 읽기를 운영하며 개발지식의 범위를 넓히는데 도움이 됨
  • 동기들과의 개발 스터디를 하며 잘 하는 동기들에게 자극을 받을 수 있었음
  • 넥스트 스텝의 TDD & 클린코드 강의를 수강해서, 어려운 과제를 수행하는 만큼 얻어가는게 많았음
  • 내 나이만큼 책읽기 프로젝트를 진행하며 다양한 분야의 책을 읽어 좁아진 시야를 넓힐 수 있었음

후회되는 선택

  • 회사 업무와 개인 공부를 분리 한 것. 개발자의 성장에 사실 가장 좋은 재료는 회사에서의 업무
  • Legacy 코드에 불만을 가진 것. 사실 레거시를 개선한다는건 기술면접에서의 가치가 높고, 내가 작성하는 코드는 언제든 바로 레거시가 된다. 그땐 그게 최선이었을 뿐 이고 실제 업무에서의 대부분은 레거시를 청산하는 일

3년차: Toss payments

  • 가상계좌 결제하는 20년된 레거시를 Kotlin + Spring Boot 기반의 MSA 구조로 마이그레이션
  • CTO님의 찐한 코드 리뷰, 뛰어난 동료들을 경험 함
  • 오전 11시 출근해 새벽 3시에 퇴근하며 육아, 가족을 위해 퇴사 결정. 마침 진행하던 프로젝트도 끝났고 미국으로의 취업 준비가 필요했음

좋았던 선택

  • 코드 리뷰를 자주 요청한 것
  • 담당했던 프로젝트를 온전히 마치고 나서 퇴사한 것
  • 퇴사 이후 4개월의 휴식기를 가지며 육아, 운동, 독서의 리프레시 시간을 가진 것.

후회되는 선택

  • 토스에 합류한 것. 성장에는 좋은 환경이지만 육아를 하는 입장에서는 가능하다고 생각했는데 쉽지 않았음
  • 개발자의 길을 포기할 까 생각했던 것. 지나가 보면 가면증후군인데, 주변의 잘하는 동료들을 보며 겪었던 불안감

4년차. Pixelic

  • Full remote 환경으로 원하는 시간에 원하는 장소에서 근무
  • Asynchrous 커뮤니케이션을 경험. 커뮤니케이션으로 인해 집중력을 잃지 않아도 됨
  • Shape up 개발 프로세스
  • 합류 3개월 만에 Pre Series A 투자를 받고, Y combinator 에도 6수만에 합격. 스톡옵션이나 RSU보다 매력적인 RSA 지급

좋았던 선택

  • 6번이나 Pivot을 했던 팀에 합류 한 것. 그만큼 단단하고 유대관계와 신뢰, 역량이 좋다.
  • 낯선 기술스택(Ruby on Rails)에 과감하게 도전 한 것. 손에 쥐고있던 것들을 놓아버렸던 선택들은 대부분 아주 좋았던 선택으로 남음
  • 초반에 시스템 아키텍처를 직접 그려보고 피드백을 받는 경험을 통해 커뮤니케이션

후회되는 선택은 아직 없음. 항상 결정의 순간에 후회를 최소화 하는 후회 최소화의 방향으로 의사 결정 할 것.

인프런 아키텍처의 과거와 현재, 그리고 미래

IMG_8169 Medium

인프랩의 CTO를 맡고 계신 향로님의 발표 입니다.

오프닝에서는 인프랩의 CTO 로서 스피킹을 했다면, 이번에는 한명의 개발자로서 말씀을 해 주셨는데요, 지난 몇 년간 인프랩이 성장해나가는 과정 속에서 쌓였던 기술 부채와 고민들, 그리고 그걸 해결해 나가는 과정에 대해 재밌게 이야기를 풀어 주셨습니다.

우아한형제들에서 자바,스프링으로 개발을 하다가 Node.js 로 개발을 하고 있는 인프랩에 CTO로 이직을 했다 보니 주변에서 JVM 기반으로 싹 갈아 엎을 거 아니냐는 이야기를 정말 많이 들으셨을 텐데 지금껏 정말 많은 고민이 있었고, 지금도 많은 고민을 해 나가는 과정이라는 걸 느낄 수 있었습니다.

시즌1

적정이란 무엇인가. 물길을 건너는 목표를 이루기 위해 방법은 여러가지가 있겠지만 적정에는 제약조건이 있다.

돈과 동료가 없는데 물길을 건너야 한다면? 헤엄쳐서 건너는 수 밖에. CEO 혼자서 모든걸 해내야 했던 시즌 1.

  • 직접 개발을 최소화 하며 외부 지원을 최대한 활용
  • PHP, jQuery, 워드프레스, MySQL 호스팅 서버 1대
  • 회원수 10만까지는 어떻게 버텼지만 이후 느려지는 서비스와 의도를 알 수 없는 데이터, 워드프레스로 인한 기능 확장의 한계 및 직접 관리해야 하는 서버 배포등으로 한계.

시즌2

구현 코드의 최소화, 단일화된 라이브러리, 익숙한 패턴, 단일 프로젝트. 5개월만에 워드프레스에서 Node.js로 교체

  • BE1, FE1, Devops1, CEO

  • 한명이라도 빠지면 전체 개발이 멈추는 리스크. 그 리스크를 관리하기 위해 기술스택을 최대한 통일하자 -> js

  • 낮은 러닝 커브 (FxSQL, FxDom)

  • 최소 관리 (CircleCI, AWS Fargate)

  • 이로 인해 신규개발자들을 채용하면서 문제들이 발생함. 구현코드의 최소화로 인해 type이 없고 객체 리터럴만 있으며 테스트 코드가 없다.

  • 예측 할 수 없는 함수의 결과와, 단일화된 라이브러리에 레퍼런스가 턱없이 부족하다보니 신입 개발자들을 위해서는 익숙하지 않은 구조

  • FE+BE 단일 프로젝트로 구성되어 있어 첫 실행에 2분이 걸리고 로컬 리로드에 20초가 걸리는 엄청난 비효율

높아진 진입장벽과 낮아진 심리적 안정감을 해결 해야 할 필요

시즌3

  • BE3, FE3, DevOps1, 자바와 스프링만 알던 CTO
  • class, type, 테스트코드, 정적 분석을 통해 심리적 안정감 증대
  • ts, react, next.js, nest.js, typeorm, id, 테라폼 등을 통해 낮은 진입장벽 해결
  • FE/ BE 계층 분리 및 API 명세 기반으로 독립성 구축

어떻게 전환할 것인가에 대한 고민이 생김. 빅뱅으로 한번에 1년만에 VS 2년에 걸쳐 점진적인 개편

스타트업에서 6개월간을 멈춘다는건 일반기업에겐 2년 이상의 시간을 의미하고, 팀원들에게 매년 2~3배 성장하는 서비스를 중단없이 개편하는 경험을 선물하고 싶었음.

  • 이제 하나씩 옮기면 되는데.. 장애 발생
  • 심지어 한 기능의 장애가 여기저기 퍼지는 상황

시즌4

  • BE8, FE11, DevOps, 이제는 JS/TS도 아는 CTO

  • 시즌3가 완료가 되지 않았음에도 시즌4로 떠밀릴 수 밖에 없는 상황

  • 독립적으로 운영하는 서비스들을 다 분리해서 장애격리라는 목표를 달성하자

  • DB 장애 격리는 지금 못해.. (분산 DB로 높아지는 복잡도, 트랜잭션 관리의 어려움, 기존 쿼리의 전체 개편) 시즌5로 throw

  • 쌓여가는 비즈니스 요구사항 ( 검색엔진 도입, 전체회원 알림 서비스 등등..)

모법 답안으로 가는 길은 사실상 불가능하니, 기술의 가지수를 최소화 하고 향후 2~3년은 버틸 수 있는 기술스택을 선택하자 -> MongoDB Atlas (NoSQL, Nori형태소 분석기 지원으로 검색엔진 가능)

Node -> AWS SNS 이벤트 발행 -> AWS SQS 이벤트 구독 -> Spring Boot key에 담긴 메세지 구독 -> key로 API에서 최신 데이터 조회

  • Node -> SNS가 실패 하면 중간에 이벤트 저장소를 두면 해결 되지만 아키텍처의 복잡도가 너무 높아지기 때문에 에러로그 발생시 알람을 받아 수동으로 해결하기. 검색엔진이라는 추가 의존성이 생겼지만 격리

최종적으로는 (신) FE <-> (구) 인프런 single repo <-> (신) BE <-> 검색 엔진

대충 이라도 일단 만들고 차근차근 해선하자. 가장 중요한건 완벽 한 것 보다 고객의 요구사항 변경에 대응 할 수 있는 것.

질문답변

이어서 질문 답변 시간이 있었는데요, 이번 컨퍼런스에서 전체적으로 느끼는 건데 질문하는 분들의 질문과 답변의 수준이 매우 높다 보니 저는 질문을 할 엄두가 전혀 나지 않더라고요. 그래도 개인적으로 궁금한게 있는 분들은 여러가지 창구를 통해 질문을 하시면 답변을 받을 수 있지 않을까 생각됩니다.

질문: 전체적으로 테스트를 다 짜서 이관했나요?

답변: Unit test + Api endpoint test. 트랜잭션의 경우에는 DB 계정명을 다르게 해서 커넥션풀을 서로 다르게 가져가게 한 뒤 모니터링

한 질문자분은 파이썬으로 짠 레거시 코드를 자바 스프링으로 이관하고 하셨는데 괴로운 그 과정이 공감되었는지 동욱님이 아주 좋아하셨습니다.

나 홀로 시골 개발자의 성장 전략

IMG_8172 Medium

얄팍한 코딩사전 채널을 운영하는 고현민님의 발표 입니다. 개인적으로 현민님의 영상들을 너무 좋아하고, 특히 최근에도 graphQL 영상을 재밌게 봤습니다. 중간에 오타가 있는 부분이 있어 이메일을 드리니 바로 수정도 해 주시고 피드백에 대한 대응도 너무 좋으셔서 인상적이었던 기억이 있습니다.

머나먼 오지의 개발자

  • 자기소개 : 프리랜서, 지식공유자. 요즘에는 제법 큰 다음 강의를 준비 중
  • 포항의 스타트업에서 커리어 시작, 주변에 동종업계 종사자도 없고 컨퍼런스에 참여할 기회도 없고 사수도 없는 고독한 나홀로 개발자.
  • Struts 1 버전을 쓰는 구식 개발 스택과 구식 업무방식. 개발자 문화의 부재로 인해 개발자로서 도태될까 두려웠고 셀프성장을 위해 고군분투

방향잡고 물길 찾기 : 토이프로젝트

  • 실사용을 목표로 개발부터 배포, 자동화, 실사용
  • 다양한 삽질로 인한 경험치 상승
  • 다양한 기술 스택을 접목 해 보기. 회사에서는 내가 해보고 싶은걸 다 자유롭게 해볼수 없지만 토이 프로젝트에서는 가능하다
  • 이때의 경험이 나중에 회사에서의 실무 적용에도 크게 도움이 된다.

물 끌어올리기: 지식공유

유트브

  • 유투브를 시작한 계기 : 책이나 문서로 좀처럼 이해하기 어려운 주제를 남에게 설명해주기 위해
  • 정보를 나만의 방식으로 재구성 하면서 지식의 깊이가 깊어지고 나만의 정의를 통해 내 것이 된다.
  • 지적 댓글의 공포는 큰 스트레스. 이 부담 때문에 더욱 철저하게 준비를 하게 된다.
  • 하지만 시간 투자 대비 효율이 좋지 않음. 특히 편집에 드는 시간과 비용을 생각하면 유투브를 추천 하기는 쉽지 않음

강의제작

  • 유투브에 비해 가성비가 좋음 (유투브에 비해 촬영 외적 비용이 적음, 강의에만 집중 할 수 있음)
  • 각 주제를 마스터하는 가장 좋은 방법. 대충 할 수 없으니 억지로라도 성실히 철저하게 공부하게 됨.
  • 나만의 강의 커리큘럼을 구성함으로서 공부가 많이 됨
  • 질문에 답하며 수강생들의 시행착오를 대리 경험. 이 역시 성장에 크게 도움이 됨
  • 수익을 통한 인센티브. 힘든 과정에 대한 동기부여 및 보상이 됨

책 집필

  • 유투브나 강의 제작과는 또 다른 경험.
  • 한정된 페이지에 선별된 지식을 정제해 넣는 작업이 생각보다 굉장히 고되고 오랜 작업.
  • 개발자는 책을 쓰기에 수월한 직업. 블로그나 유투브의 좋은 컨텐츠를 보고 출판사가 먼저 컨택을 해온다.
  • 내 이름이 저자명으로 된 책을 보며 큰 성취감을 얻고 그로인해 더욱 다음 작업의 원동력이 됨.

마무리

  • 가장 중요한 건 성장을 향한 갈망. 안주의 유혹을 끊임없이 경계해야함
  • 인센티브가 있는 목적으로 동력을 불어넣기. 스스로 새로운 도전에 대한 동기와 목표
  • 나만의 성장 로드를 뚫기. 아무리 척박한 환경에서도 길을 찾자.

10만 connection 그까이꺼, Armeria 서버 한 대면 끝!

IMG_8174 Medium

얼마전에 Armeria 튜토리얼 따라해보기 를 해보면서 까지 준비 할 만큼 기대를 많이 했습니다.

심지어 40명 선착순 신청으로만 참여 할 수 있는 핸드온 세션 이기 때문에 목요일 오후 4시 30분 땡 되자 마자 바로 신청을 했고 그 덕에 참여 할 수 있었습니다. 매번 동기 서버만 작성 해 보았기에 비동기 서버가 어떤 원리로 동작하는지 그리고 어떻게 구현하는지 궁금 했는데 오랜만에 화면을 보며 코드를 따라 치는 경험도 할 수 있었고, 영상으로만 보던 Armeria 팀원분들을 뵐 수 있어 좋았습니다. 정말 재밌었고 참여하길 잘했단 생각이 듭니다.

발표는 민우님이 해 주셨고, 익훈님과 한남님도 함께 자리 해 주셨습니다.

IMG_8175 Medium

개인별로 넓직한 자리에서 랩탑을 놓고 쓸 수 있었고, 인터넷 접속을 위한 아이디,비밀번호가 적힌 종이를 지급 해 주었습니다.

준비사항

참여 전 아래의 준비를 해야 합니다.

$ git clone https://github.com/minwoox/infcon-armeria.git
$ ./gradlew build
  • Armeria는 비동기 마이크로소프트 서비스를 쉽게 at your face로 구현할 수 있게 해줌

  • 비동기 서버 개발이 처음이신분? 나 포함 겨우 5명,,

  • Tomcat의 기본 쓰레드는 200개. http response는 한번에 오지 않는다.

  • 비동기 서버는 이 개념을 이해하기가 처음에 어려울 뿐 이것만 이해하면 그 다음부터는 쉽다.

핸드온을 통해 구현할 최종 목표

image-20220827181440718

https://github.com/minwoox/infcon-armeria

Hello Armeria

image-20220827181517622

Main.java

public final class Main {

    public static void main(String[] args) {
        ServerBuilder serverBuilder = Server.builder();
        Server server = serverBuilder.http(8080)
                .service("/infcon", new MyService())
                .build();

        CompletableFuture<Void> future = server.start();
        future.join();
    }
}

MyService.java

public final class MyService implements HttpService {

    @Override
    public HttpResponse serve(ServiceRequestContext ctx, HttpRequest req) throws Exception {
        return HttpResponse.of("Hello, Armeria!");
    }
}

천천히 응답하는 백엔드

image-20220827181622171

1. 동기 backend

Backend.java

public final class Backend {

    private final Server server;

    private Backend(String name, int port) {
        server = Server.builder()
                .http(port)
                .service("/foo", ((ctx, req) -> {
                    HttpResponse response = HttpResponse.of("response from/: " + name);
                    return HttpResponse.delayed(response, Duration.ofSeconds(3));
                })).build();
    }

    public static Backend of(String name, int port) {
        return new Backend(name, port);
    }

    public void start() {
        server.start().join();
    }

}

BackendTest.java

class BackendTest {

    @Test
    void backend() {
        final Backend foo = Backend.of("foo", 9000);
        foo.start();

        final WebClient webClient = WebClient.of("http://127.0.0.1:9000");

        // 이 시점에 httpResponse는 응답을 가지고 있지 않음. 3초 후에 응답을 return 하게끔 했기 때문에
        // 응답을 가지고 있지 않은 껍데기.
        HttpResponse httpResponse = webClient.get("/foo");
        System.err.println("Thread name: " + Thread.currentThread().getName());
        // 동기서버는 3초를 기다리지만, 비동기서버에서는 기다리지 않음.

        // response는 한번에 오지 않는다.
        // aggregate 를 이용 하면 header 와 body가 따로따로 오는걸 잘 모아서 하나의 aggregated된 Response로 만들어준다.
        CompletableFuture<AggregatedHttpResponse> future = httpResponse.aggregate();
        // 지금 이 future는 body를 가지고 있지 않음. 또 다른 껍데기. 껍데기에서 껍데기를 만든 상태.

        // 비동기서버에서는 join을 절대로 사용 하면 안됨.
        AggregatedHttpResponse aggregatedHttpResponse = future.join();
        String content = aggregatedHttpResponse.contentUtf8();
        System.err.println(content);


    }
}

httpResponse는 단지 wrapper임. 생성 만으로는 무엇을 가지고 있지 않은 껍데기에 불과.

그렇지 않다면 쓰레드는 response가 도착하는 3초 동안 기다려야 하는데 그 경우에는 비동기가 아님. 쓰레드는 200개만 있는데 동시에 200개가 넘는 요청이 온다면 그걸 어떻게 처리?

2. 비동기 Backend (call back)

HTTP 응답은 Header frame과 Data frame을 가지고 있는데 한번에 오지 않는다. 프레임을 하나씩 다루거나 aggregate 해야함. 이벤트 루프를 막지 않기 위해 콜백을 활용

BackendTest.java

class BackendTest {

    @Test
    void backend() throws InterruptedException {
        final Backend foo = Backend.of("foo", 9000);
        foo.start();

        final WebClient webClient = WebClient.of("http://127.0.0.1:9000");

        // 이 시점에 httpResponse는 응답을 가지고 있지 않음. 3초 후에 응답을 return 하게끔 했기 때문에
        // 응답을 가지고 있지 않은 껍데기.
        HttpResponse httpResponse = webClient.get("/foo");
        System.err.println("Thread name: " + Thread.currentThread().getName());
        // 동기서버는 3초를 기다리지만, 비동기서버에서는 기다리지 않음.

        // response는 한번에 오지 않는다.
        // aggregate 를 이용 하면 header 와 body가 따로따로 오는걸 잘 모아서 하나의 aggregated된 Response로 만들어준다.
        CompletableFuture<AggregatedHttpResponse> future = httpResponse.aggregate();
        // 지금 이 future는 body를 가지고 있지 않음. 또 다른 껍데기. 껍데기에서 껍데기를 만든 상태.

        // join 이 아닌 callback 을 사용 해야 한다.
        // future에 callback을 등록 해서 3초 후에 응답이 발생하면 알맹이가 채워지고, 오리지널 클라이언트에게 요청
        future.thenAccept(aggregatedHttpResponse -> {
            // 이벤트 루프. 요청을 받아서 futre 껍데기 에다가 알맹이를 넣어주는 쓰레드
            System.err.println("In callback. Thread name: " + Thread.currentThread().getName());
            sendBackToTheOriginalClient(aggregatedHttpResponse);
        });

        Thread.sleep(Long.MAX_VALUE);
    }

    private void sendBackToTheOriginalClient(AggregatedHttpResponse aggregatedHttpResponse) {
    }
}

두개의 백엔드

image-20220827183244340

두개의 백엔드를 위해 Backend.java 변경

Backend.java

public final class Backend {

    private final Server server;

    private Backend(String name, int port) {
        server = Server.builder()
                .http(port)
                .service("/" + name, ((ctx, req) -> {
                    HttpResponse response = HttpResponse.of("response from: " + name);
                    return HttpResponse.delayed(response, Duration.ofSeconds(3));
                })).build();
    }

    public static Backend of(String name, int port) {
        return new Backend(name, port);
    }

    public void start() {
        server.start().join();
    }

}

메인도 변경

Main.java

public final class Main {

    public static void main(String[] args) {
        final Backend foo = Backend.of("foo", 9000);
        foo.start();
        final WebClient fooClient = WebClient.of("http://127.0.0.1:9000");

        final Backend bar = Backend.of("bar", 9001);
        bar.start();
        final WebClient barClient = WebClient.of("http://127.0.0.1:9001");

        ServerBuilder serverBuilder = Server.builder();
        Server server = serverBuilder.http(8080)
                .service("/infcon", new MyService(fooClient, barClient))
                .build();

        CompletableFuture<Void> future = server.start();
        future.join();
    }
}

서비스 변경. 두개의 클라이언트를 콜백 호출

Service.java

public final class MyService implements HttpService {

    private final WebClient fooClient;
    private final WebClient barClient;

    public MyService(WebClient fooClient, WebClient barClient) {
        this.fooClient = fooClient;
        this.barClient = barClient;
    }

    @Override
    public HttpResponse serve(ServiceRequestContext ctx, HttpRequest req) throws Exception {
        CompletableFuture<HttpResponse> future = new CompletableFuture<>();

        fooClient.get("/foo").aggregate().thenAccept(fooResponse -> {
            barClient.get("/bar").aggregate().thenAccept(barResponse -> {
                HttpResponse response = HttpResponse.of(fooResponse.contentUtf8() + '\n' + barResponse.contentUtf8());
                future.complete(response);
            });
        });

        return HttpResponse.from(future);
    }
}

데코레이터

시간 관계상 데코레이터 시작하는 부분에서 발표가 끝났고 이후 부터는 각자 알아서 주말동안 해보기로 하였습니다.

image-20220827183741266

데코레이터를 통해 MyService를 감싸는 interceptor에서 로깅을 남긴다거나 인증이 되었는지를 확인 할 수 있다.

AuthDecorator.java

public final class AuthDecorator implements DecoratingHttpServiceFunction {

    private final WebClient authClient;

    public AuthDecorator(WebClient authClient) {
        this.authClient = authClient;
    }

    @Override
    public HttpResponse serve(HttpService delegate, ServiceRequestContext ctx, HttpRequest req) {
        CompletableFuture<HttpResponse> future = new CompletableFuture<>();
        authClient.get("/auth").aggregate().thenAccept(aggregatedHttpResponse -> {
            if ("authorized".equals(aggregatedHttpResponse.contentUtf8())) {
                try {
                    future.complete(delegate.serve(ctx, req));
                } catch (Exception e) {
                    future.completeExceptionally(e);
                }
            } else {
                future.complete(HttpResponse.of(401));
            }
        });
        return HttpResponse.from(future);
    }

}

AuthServer.java

public class AuthServer {

    private final Server server;

    public static AuthServer of(int port) {
        return new AuthServer(port);
    }

    private AuthServer(int port) {
        server = Server.builder()
                .http(port)
                .service(
                        "/auth",
                        (ctx, req) -> {
                            System.err.println(this.getClass() + ": 요청 처리");
                            return HttpResponse.of("authorized");
                        })
                .build();
    }

    public void start() {
        server.start().join();
    }

}

Main.java

public final class Main {

    public static void main(String[] args) {

        final AuthServer authServer = AuthServer.of(8999);
        authServer.start();
        WebClient authClient = WebClient.of("http://127.0.0.1:8999");

        final Backend foo = Backend.of("foo", 9000);
        foo.start();
        final WebClient fooClient = WebClient.of("http://127.0.0.1:9000");

        final Backend bar = Backend.of("bar", 9001);
        bar.start();
        final WebClient barClient = WebClient.of("http://127.0.0.1:9001");

        ServerBuilder serverBuilder = Server.builder();
        Server server = serverBuilder.http(8080)
                .decorator(new AuthDecorator(authClient))
                .service("/infcon", new MyService(fooClient, barClient))
                .build();

        CompletableFuture<Void> future = server.start();
        future.join();
    }
}

테스트

multipleRequests()

    // Run main() before run this test.
    @Test
    void multipleRequests() throws InterruptedException {
        final int TARGET = 100_000;

        final long start = System.nanoTime();
        final CountDownLatch latch = new CountDownLatch(10000);
        for (int i = 0; i < TARGET; i++) {
            final WebClient webClient = WebClient.of("http://127.0.0.1:8080");
            webClient.get("/infcon").aggregate().handle((aggregatedHttpResponse, throwable) -> {
                latch.countDown();
                return null;
            });
        }
        latch.await();
        System.err.println("Elapsed time: " + TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - start) + " ms");
    }

  • 10만커넥션 그까이꺼~ 답게 10만 요청을 금방 처리 해 냈습니다.

  • 이 테스트코드에서 10만보다 숫자를 더 높이며 테스트 했을 때에는 서버는 요청은 오는대로 처리를 하려고는 하는데.. 힙메모리 부족으로 서버가 아닌 테스트 코드가 중간에 죽어버렸습니다.

어느 날 고민 많은 주니어 개발자가 찾아왔다

IMG_8186 Medium

이 컨퍼런스에서 가장 설레며 기다렸던 영한님의 발표입니다. 저는 영한님의 인프런 강의를 단 하나도 빠지지 않고 전부 들었을 만큼 스프링과 JPA를 학습하는데 절대적으로 많은 도움을 받았습니다. 개발바닥에서의 시골 청년 개발왕 되다 시리즈를 통해 전혀 생각할 수도 없었던 지난 이야기도 들을 수 있었고 매번 강의 마지막의 다음으로.. 세션을 통해서도 좋은 이야기를 들을 기회가 몇번씩 있었습니다. 강의평이나 질문 답변의 댓글들을 보면서도 선한 영향력을 본받고 싶다는 생각을 참 많이 했는데 그 이야기를 직접 들을 수 있는 기회였고 정말 좋았습니다.

나의 개발자 커리어 이야기

  • 어릴적 게임 폐인 -> 게임 프로그래머의 꿈. 최고의 컴퓨터와 그래픽카드를 구입 해서 1년간 게임 폐인으로 생활
  • 400~500 만원의 등록금이 필요한 IT 학원에 들어가고 싶어 피자배달일을 하고 몇시간씩 걸어 다니며 돈을 아낌
  • 고졸 신분으로 서울에서 취업 준비를 하며 수많은 탈락 경험
  • 첫 취업 -> 부도난 인력 파견 회사
  • IT 학원 강사로 취업해 java, spring, jsp 강의. 어려운 개념을 쉽게 설명하는 재능 발견
  • SI 에서 매일 야근, 사우나에서 취침, 근무처가 바뀌고 부도나고 월급이 밀리며 가장 힘든시기를 겪음. 네이버 다음은 그저 산 처럼 느껴졌지만 남는 시간을 쪼개머 개발 공부
  • 다음커뮤니케이션, SK Planet, 우아한형제들 을 거치며 수많은 개발자들을 채용하고 성장을 지켜봐옴

이직

  • 어떤 회사를 갈 것인가? 가고싶은 회사를 1,2,3티어로 정리하고 1티어 회사의 Job Description을 확인해 비슷한 기술의 2,3티어 회사 찾기
  • 1티어 회사를 신입으로 취업하는건 경력보다 10배는 더 어려움.
  • 일단 3티어 회사로 취업을 준비하고, 그것이 안되어도 개발을 하는 회사에 취업해 3-> 2-> 1 순서로 단계적으로 개선
  • 성장을 위해서는 개발, 운영, 개선을 하는 사이클을 겪어봐야함.
  • 개발만 해주는 회사와 자기 제품을 만드는 회사가 있는데, 개발만 하고 빠지는 회사는 성장을 할 수 없음. 서비스.플랫폼 회사에서는 내가 만든 코드를 내가 운영하고 개선하는 경험을 할 수 있고 노력만큼 성과를 받을 수 있음. 남의 제품을 개발해주는건 보상에 한계가 있음.

채용

  • 채용은 확률이다. TO는 무제한으로 열려있지만, 실력있는 개발자에 한정된 이야기.
  • 네카라쿠배와 2티어 회사에 지원 했을 때, 네카라쿠배는 합격 했는데 2티어는 탈락하는 일도 아주 빈번하게 일어난다.
  • 면접관도 사람이니 모두 선호하는게 다르다. 기술과 성장가능성, 기본기 등등
  • 티어가 높은 회사일수록 평균 기대치가 높다. 개발자의 실력과 깊이가 점점 더 중요해지는데 한명의 개발자가 담당하는 사용자 수, 트래픽, 손익, 장애 발생시의 손해가 천문학적으로 달라지기 때문에 당연
  • 지금은 개발자 채용 전쟁이다. 과거에는 하나의 TO를 차지하기 위해 여러 개발자가 경쟁했지만 지금은 좋은 개발자 1명을 두고 여러 회사가 경쟁한다. 시장에는 실력있는 개발자가 부족하고, 지금은 다른 외적 요소보다 실력이 가장 중요하다.

이력서

  • 서류에서 계속 탈락한다면 실력과 경험이 부족하니 기대치를 낮추거나 학습과 경험을 더 쌓아야 함
  • 혹은 이력서를 못쓰기 때문일 수 있으니 문제와 해결이라는 마법의 단어로 면접관을 낚아야 한다. 프로그래머는 기본적으로 문제 해결사. 본능적으로 문제는 풀어야 하고 해결방법을 궁금해 해야한다.
  • 문제기술적으로 어떻게 해결 했는지에 대해 자세히 적는다.
  • 면접관들은 기술적으로 깊이 있는 개발자들을 선호한다. 깊이라는건 무작정 수직으로 파는게 아니고 주변도 파며 들어가야 한다.
  • 본인이 잘 하는걸 구체적으로 면접관의 관점에서 생각하며 작성한다. 겸손도 중요하지만 본인 마케팅도 중요함.
  • 어떤 문제가 있었고 기술적으로 어떻게 해결했는지에 대한 해결포인트를 제시한다.

서류통과 면접탈락

  • 실제로 내공이 부족하기 때문. 내가 안다고 생각하는게 정말로 아는 건지에 대해 생각해봐야함
  • 학습 -> 체득 -> 정리의 3단계를 거쳐 내 것으로 만들어야함.
  • 면접시간은 짧다. 요점을 잘 정리해서 설명해낼 수 있어야만 한다.

학습의 3단계

  1. 학습 : 강의나 책을 통해 학습하는 과정
  2. 체득 : 실무에 적용해보거나 토이 프로젝트에 적용해 체득하는 단계
  3. 정리 : 노트나 블로그 혹은 세미나에서의 발표를 통해 학습한 지식을 정리하고 내 것으로 만드는 단계

정리의 단계까지 가야만 짧은 면접 시간동안 논리적으로 설명을 해 낼 수 있다.

지속적인 학습과 성장

  • 목표만으로는 안되고 시스템을 만들어야 한다.
  • 점수를 100점 맞겠다, 강의를 10개 듣겠다 하는 목표는 달성 하면 성공 아니면 실패. 열정을 앞세우면 목표를 준비하다가 포기 하게 된다.
  • 시스템은 하루에 3끼 밥을 먹는 것 처럼 당연한 것. 퇴근 후 30분간 운동 혹은 7:30 ~ 10:30 까지 학습 하기 등이 시스템 루틴
  • 그냥 이 시간에는 별 생각 없이 앉아서 이것을 하는 것

image-20220827192911003

  • 반복, 개선, 피드백을 통해 시스템을 꾸준히 돌리는게 중요하다
  • 피드백의 싸이클은 빠를 수록 좋다. 대표적인게 테스트케이스

면졉과 피드백

  • 면접을 자주 보는 개발자A는 피드백을 많이 받기 때문에 확률이 올라간다.
  • 완벽하게 준비하고 면접보려는 개발자B는 피드백을 받지 못하기 때문에 확률이 떨어진다.

시스템을 통해 성장해야함. 업무시간 이후 학습하는 개발자는 그렇게 많지 않다.

두 종류의 개발자 이야기

  • 본인이 매주 잘한다고 생각하는 보통의 개발자 A

  • 본인이 매우 부족하다고 생각하는 팀내에서 인정받는 개발자 B

  • 주니어 3년차쯤 되면 사실 개별적으로 공부 하지 않아도 왠만한 업무는 처리해낼 수 있음.

  • 업무를 잘함 -> 잘한다고 스스로 생각 -> 성장이 멈춤 -> 우물안 개구리가 됨

  • 공부를 하면 할 수록 더 배울게 나오기 때문에 본인이 배워야 할 것이 많다고 생각한다. 실력이 있어도 자연스럽게 겸손해 지고 그로 인해 지속적인 성장이 가능하다. 기술적 겸손함을 갖춰야함

  • 대나무에 마디가 있는 것은 더 크게 성장하기 위함.

시스템을 통해 내공을 쌓으면 좋은 회사와 좋은 연봉은 알아서 따라온다. 개발은 팀웍이기 때문에 성장을 통해 주변 동료에게 인정 받고, 함께 일하고 싶은 개발자로 남는 것이 중요하다.

IMG_8201 Medium

발표가 끝난 후에는 개인적으로 찾아가 짧게나마 대화를 나눌 수 있었습니다.

저는 영상으로 자주 뵈어서 친숙하지만 반대의 경우는 아님에도 불구하고 반갑게 이름을 불러 맞이해 주셔서 감사했습니다.

개발바닥 공개방송

IMG_8185 Medium

업로드된 영상을 하나도 빠짐없이 시청하는 유일한 유투브 채널 (얼마전 호돌맨의 3시간 리액트 영상 빼고..) 인 개발바닥의 공개 방송에 참여했습니다.

다소 어수선하기는 했지만 바로앞에서 호돌맨 향로의 조합을 볼 수 있어 좋았고, 그 내용도 유익해 참 재밌었습니다.

흔하지 않은 기회인 만큼 준비된 질문과 답변보다는 참여한 분들과의 보다 자유로운 소통시간을 가졌으면 어땠을까 하는 약간의 아쉬움은 있었습니다.

인프콘 후기

아쉬웠던 점

전체적으로 너무나도 즐겁고 만족스러웠지만 몇가지 아쉬웠던 점이 있었습니다.

  • 발표자 분들에게 할당된 시간이 짧았습니다. 사실 각 세션의 시간이 짧은걸 보고 컨퍼런스 전부터 너무 짧지 않나 싶긴 했는데, 준비해주신 내용에 비해 시간이 짧다보니 발표자 분들이 시간에 쫓기는 듯한 느낌이 들었습니다. 한정된 시간에 한정된 컨퍼런스 룸들 안에서 많은 연사분들을 모시기 위한 어쩔 수 없는 트레이드 오프였음을 이해 하지만 그래도 아쉬었습니다.
  • 준비된 이벤트들을 즐길 시간적 여유가 부족했습니다. 기업 부스들에도 충분히 들르고 돌림판도 돌리고 싶었는데 그러기에 시간이 너무 부족했습니다. 스탬프를 찍고도 돌림판을 돌리지 못한게 아쉬웠지만 다른 세션들을 듣기 위해서는 포기할 수 밖에 없었습니다.

좋았던 점

  • 주니어 개발자들도 충분히 즐길 수 있는 컨퍼런스라서 너무 좋았습니다. 다함께 즐기는 개발자들의 축제 같은 느낌 이었습니다.

  • 듣고 싶은 발표를 골라 들을 수 있다는게 재밌었습니다. 평소에 뵙고 싶었던 개발자분들을 한번에 정말 많이 뵐 수 있는 기회였습니다.

  • 무료였습니다. 참가자 인원당으로 환산시 15만원 가량의 비용이 발생했을 것 같은데 어떤 금액도 청구되지 않았습니다. 추첨을 통해 어렵게 참여 했음에도 이래도 되나 싶을 정도로 아무런 비용이 발생하지 않는게 참 감사했습니다. 인프런에게 또 한번 은혜를 입었습니다.

    다음번에 또 열린다면 그때는 제법 부담스러운 비용이 발생하면 좋겠습니다.. 그만큼 다시 참석 하고 싶은 마음이 큽니다.

  • 첫 주최라는게 믿기지 않을 정도로 군더더기 없이 진행 되었습니다. 덕분에 온전히 즐길 수 있었습니다.

마치며

IMG_8241 Medium

엄청난 경쟁률에도 불구하고 운 좋게 선정되어 정말 기쁜 하루였습니다. 정말 바쁘게 지나간 하루였고, 집에 수많은 기념품도 가지고 올 수 있었습니다.

인프콘은 사실 컨퍼런스라기 보다 하나의 콘서트가 아니었을까 할 정도로 너무나도 즐거운 시간을 보냈습니다.

이런 큰 행사를 성공적으로 준비해준 인프랩 스탭들, 인프런 강의를 마음껏 들을 수 있게 지원해준 저희 회사 아르고넷, 그리고 좋은 발표를 준비 해 주신 발표자 분들 모두에게 진심으로 감사의 인사를 전합니다.

더 나은 개발자가 되기 위해 많은 도움 받고 있는 만큼, 그 이상으로 베풀 수 있는 좋은 개발자로 성장하기 위해 노력하겠습니다.

감사합니다.

반응형