인프콘 2023 후기 🎉

Sheryl Yun·2023년 8월 15일
2

2023 인프콘 후기

목록 보기
1/1

서론

살면서 뭔가에 당첨된 적이 없었는데 인프콘을 작년에 이어 2번이나 다녀오게 되었다. 인생에서 밀린 당첨운 다 씀

인프콘에 참여가 확정되면 인프콘 사이트에서 '시간표 공유하기' 버튼을 눌러 저렇게 선택한 강연들을 대학교 시간표처럼 만들어줘서 공유할 수 있게 해준다.

한 타임에 여러 개를 선택한 이유는 듣다가 생각보다 깊은 주제일 경우 또 다른 강연을 들으러 가기 위함인데 실제로는 거의 한 타임에 한 개씩만 듣게 된다.

검은 펜 동그라미는 위에서 골라 두었던 관심 강의, 연두색 하이라이트는 인프콘 날 실제로 들었던 강의들이다. 참여하기 전 관심 강의 중에서도 제일 우선순위로 듣고 싶은 것 1, 2, 3위를 정해놓았더니 막상 도착했을 때 어떤 강연을 들을 지 고민을 덜 할 수 있었다.


굿즈 이야기

작년 1기 인프콘에 참여했을 때 굿즈를 얻기 위해 부스에 20-30명 뒤에 줄을 서는 피를 토한(?) 경험이 있었기 때문에 이번에는 나름 일찍 도착해서(45분 전) 미리 이벤트 부스에 참여했다. 실제 강연들은 키노트 강연 포함해서 10시에 시작하고 이벤트 부스는 그보다 1시간 전인 9시에 미리 연다.

원래 이런 줄 서기 경품 타기에 흥미가 없는 편인데 강연마다 20분씩 넉넉한 쉬는 시간이 있고 도중에 1시간 동안 점심 시간도 있고 (한 타임에 도저히 들을 게 없으면 나와서 경품이나 타자는) 등의 이유로 열심히 참여하게 되었다.

오늘은 작년과 달리 뽑기 등에 당첨이 되어야 좋은 경품을 얻을 수 있는 경우가 많았다. 대부분의 부스는 QR 코드 설문조사만 하면 경품을 주는 구조였다.

작년에는 인프런 강의 10만원 권을 얻는 큰 행운이 있었지만 올해는 영 당첨되는 곳이 없었는데 다행히 점핏에서 2등에 당첨되어 귀엽게 생긴 보조 배터리를 받았다.

굿즈는 AWS와 사람인, 무신사가 꽤 좋았다. 설문 조사만 했는데 휴대용 선풍기를 그냥 뿌리는 AWS와 사람인 무신사는 받을 땐 잘 몰랐는데 나중에 집에 와서 언박싱해보니 담요부터 티셔츠까지 다채롭게 들어있어서 감탄했다 👍

(굿즈를 타기 위해 온 마음을 다해 찍은 스탬프)

인프콘은 강연 3분의 2, 굿즈 3분의 1 정도의 행사라고 보면 된다 😂 강연들도 내용이 매우 알차기 때문에 나중에 사이트에 공개되는 전체 강연 중 못 들어본 강연도 들어보려고 한다. 짧은 시간 안에 각 연사님이 실제 경험하시고 깊게 고민해보신 내용과 해결책을 정수를 꽉꽉 채워 얘기해주시는 느낌이었다.

위에 찍은 이벤트 스탬프 중에는 인프런의 채용 플랫폼인 랠릿 서비스를 소개받고 받은 스탬프도 있다. 2층에 있는 인프런 부스에서 랠릿 서비스 중 허브라는 서비스를 소개 받았는데 저렇게 프로필을 등록해두면 기업에서 채용 제안을 받을 수 있다. (목티 입고 민증 찍은 바보 😑) 현재 재직 중이면서 따로 구직 의사가 없는 경우에는 '지금 만족하고 있어요'를 선택해서 띄울 수 있다. 링크드인, 로켓펀치와 비슷한 느낌이었는데 다방면으로 프로필을 띄워두고 싶다면 이용해볼 만한 서비스인 것 같다.


참가 준비물(?) + 참여 인원 + 식사

작년에는 무겁게 노트북을 들고 갔었는데 이번에는 뒤에 받침대가 있는 연습장 뭉치와 펜, 생수만 챙겨갔다.

작년에 오픈 카톡에서 10대 1이라는 말이 알음알음 돌았는데 이번에 참여 인원을 조사해보니 사전 신청 인원만 8700명이었고(작년과 달리 유료였는데도) 실제 참여한 인원은 1300명 정도 되었다고 한다.

이 인파에 쓸려다니며 돌아다니는 동안 나의 경우 당이 급격히 떨어졌다. (배가 고픈 게 아니라 진짜로 당이 떨어짐) 만약 내년에 운 좋게 또 한번 더 참여하게 된다면 에너지바나 초코바 등 조그만 간식을 챙겨오자 생각했다.

인프콘에서는 (나중에 바뀔 수도 있지만) 점심 시간은 1시간 있되 점심 식사를 따로 제공하지는 않는다. 작년에는 삼성역 쪽의 푸드 코트만 생각하고 너무 멀다는 생각에 야놀자에 준 쿠키로 버텼는데 이번에는 9호선 봉은사역쪽(바깥 문)으로 나가면 아셈광장 계단 아래에 폴바셋, 카페 마마스 등을 발견해서 거기서 간단하게 식사를 해결할 수 있을 것 같았다.


강연 기록

강연에서 필기한 내용

1번째 강연: 소프트웨어 설계를 위한 추상적, 구조적 사고

[ 연사: 코발트 CTO ]

(이 강연만 사진을 깜박 해서 인파가 느껴지는 인프콘 풍경으로 대체)

프로그램 (Program)

  • 정의
    • 결과를 이루기 위해 수행되는 일의 계획
  • 목적
    • 특정 문제를 해결하기 위함
    • 여기서 특정 문제란 비즈니스 문제를 뜻함
    • 비즈니스 문제 = 이익(돈, 사회적 가치)를 얻기 위해 해결해야 하는 문제
  • 순서
    • 문제 이해 및 파악
      • 현실의 문제를 이해해서 추상적인 컴퓨터 로직으로 구현
    • 설계
      • 기능을 구현하기 위한 계획
      • 기획과 개발 둘 다에 해당하는 단계
    • 구현
      • 실제 코드를 작성하는 개발 단계
    • 평가
      • 테스트 및 피드백
  • 실제로 개발자는 구현 단계뿐만 아니라 프로그램의 전 단계에 관여한다.
  • 시니어는 주니어와 달리 경험을 통한 직관을 가지고 있다.
    • 쌓아온 경험을 기반으로 '이 문제는 이렇게 해결하면 될 것이다'하는 직관
  • 프로그래밍에서는 빠른 적응을 위한 유연한 방법론이 필요
    • 이 유연한 방법은 추상적, 구조적 사고로 가능하다.

추상화

  • 여러 사물에서 필요한 요소를 추출하는 행위
    • 예: 지도
      지도의 구성 요소(이미지, 눈금, 각 나라 이름, 경계선 등) 중 현실 세계에서 관심 있고 필요로 하는 것을 추상으로 뽑아내면 위도와 경도
  • 방법: 사물의 단순화 및 재해석
  • 순서: 현상/물체 인식 -> 분석, 해체 -> 필요한 점 뽑아 결합
    • 분석, 해체 단계 유의 사항: 너무 작은 단위나 큰 단위로 나누면 의미가 없어짐
      • 적절한 추상화를 고민할 필요가 있음
      • 과도한 추상화는 실제를 알 수 없게 만든다.
      • 예: 현대에 공룡 뼈만 남아 있어 공룡이 살아있을 당시 상세한 형체가 어땠을지 명확하지 않아 의견 분분

구조화

  • 순서를 주는 것
  • 일부만 봐도 무슨 느낌인지 알 수 있게
    • 예: 구체적인 변수명, 타입스크립트로 정보가 제공된 함수 등
  • 관련 법칙: MECE 법칙
    • '겹치는 것 없이 배타적이어야 한다'
    • 프로그래밍을 하며 아예 안 겹칠 수는 없지만 생각해볼 문제

(필기가 제일 많았던 첫 번째 강연)

모델링

  • 세상을 표현하기 위한 방법
  • 일반화
    • 공통점을 묶는 것
    • 예: 패턴 발견하기, 공통된 점을 추출해서 부모 컴포넌트 생성 등
  • 모델링과 추상화, 구조화는 떼 놓을 수 없다.
    • 예: 프레임워크
      • 프레임(틀) + 워크(작업): '틀에 맞춘 작업'
      • 이러한 프레임워크를 추상적이고 구조화된 사고로 만들어낸다.
    • 백엔드의 여러 프레임워크
      • 서버를 만든다는 공통의 목표를 가지고 있지만
      • 그 목표를 달성하기 위해 여러 추상화, 구조화 방법에 따라 다양한 프레임워크들을 사용하게 된다.

소프트웨어 설계

  • 개발자는 현실의 문제를 추상적인 프로그램으로 해결하는 사람
    • 비즈니스 문제를 프로그램으로 구현하는 것 = 도메인 모델링
  • 요구 사항
    • 각 화면에서 해 줘야 하는 것이 문장으로 표현된 것
  • 모델링하는 방법
    • 각 요구 사항의 문장에서 키워드를 하이라이팅으로 표시한다.
    • 키워드를 중심으로 데이터(백엔드) 및 상태(프론트엔드) 관계도를 그려본다.

아키텍처

  • 정의: 일을 하는 방법
    • 요구 사항과 조직의 특성에 따라 달라짐
  • 구성은 하향식이 좋다.
    • 성능과 조직 구조를 고려하여
    • 각 요소를 단계적/구조적으로 나타내어 최종 방법론 생성
      • 방법론: 문제 해결을 위한 방법을 위한 이론

패러다임

  • 패러다임은 사람을 위한 것
    • 컴퓨터는 패러다임이라는 것을 알 수 없다.
  • 과하게 추상화된 것은 의도적으로 구체화해서 드러내는 것이 좋다.
    • 특히 수정될 가능성이 많은 것
    • 예: 의도적으로 중복 코드 두기

리팩토링

  • 코드의 기능적 동작의 수정 없이
  • 코드 형태만 더 좋게 변경하는 것

마지막 팁

  • 개발자로서 다양한 경험 해보기
    • 예: 프론트엔드여도 백엔드 개발을 해보기
    • 사고를 확대하기 위함
  • 요구 사항을 구현하기 전에 종이에 먼저 표현
    • 단계적으로 접근할 때 도움
  • CS 공부 필수

2번째 강연: Turborepo, Next.js, TypeScript를 이용한 프론트엔드 모노레포 적용기

[ 연사: 홉스 공동 창업자이자 프론트엔드 개발자 ]

모노레포

개념

하나의 레포에서 독립적인 여러 프로젝트(레포지토리)를 관리하는 것

장점

  • 빠른 코드 수정 가능
  • CI, 테스트 코드를 한 번에 돌릴 수 있음
    • yarn test 한 번이면 모든 레포 테스트 가능
  • util A와 util B가 서로 다른 개별 레포에 있더라도 버전 맞출 필요 없이 바로 App에 반영 가능
  • 유틸이나 라이브러리를 하나의 레포에서 패키지로 관리 가능
    • 레포지토리 간 중복 코드 감소시킬 수 있음
    • 코드 컨벤션 통일이 쉬워짐
  • 대규모 리팩토링에 용이

단점

  • 과도한 의존 관계가 생길 수 있음
    • 배포 때 문제가 생길 수 있어서 설계를 잘 해야 함
  • 구동이나 테스트를 한 번 돌릴 때 무거움 (오래 걸림) = CI 속도 저하
  • 개발자 간 책임 명확도가 떨어져서 코드 오너쉽이 위배되는 경향

뒤에는 실무 명령어 소개가 이어졌다.


커뮤니케이션 잘하는 개발자의 4가지 습관

[ 연사: 토스 iOS 개발자 ]

강연 주제

다른 직군과 요구 사항에 대해 커뮤니케이션하는 방법

초반에 '오늘도 개발자가 안 된다고 말했다'라는 책 표지가 뜨는 순간 청중들이 빵 터졌다 😄

개발자 이전에 기자였던 정신을 발휘하여 다른 직군들을 취재하여 얻은 설문 결과를 소개하셨다.

같이 일하기 힘든 개발자

[ 스펙 구현형 ]

  • 무조건 안 된다고 함 (스펙 구현에만 집중)
  • 시야가 좁게 느껴진 경우가 많았다.

같이 일하고 싶은 개발자

[ 문제 해결형 ]

  • 안 된다는 말을 잘 안 한다.
  • 소통하는 법
    • 어떤 문제를 풀기 위함인지 물어본다.
      • 해결하려는 문제의 의도와 맥락 파악
    • 이 방법이 개발적으로 왜 어려운지 (직군 상관 없이) 누구나 이해할 수 있는 말로 설명한다.
    • 대안을 제시한다. ('대신 이거 어때요?')

성공적인 개발의 관건

= 고객과 사업의 문제를 풀 수 있느냐
-> 문제의 의도맥락을 이해해야 함

좋은 개발자가 되려면?

  • '된다/안 된다' 라는 흑백 논리에 갇히지 말기
  • 유저가 편하면서도(UX) 개발자의 공수가 덜 드는 방법(DX)을 고민하기
  • 혼자 생각하지 말고 주변 사람과 고민점 공유하기 (=> 질문)
    • 이 경우 옆의 개발자는 물론 다른 직군의 의견도 도움이 된다
    • 내가 갖고 있는 시야를 넓혀주는 역할
    • 내가 고민하는 문제는 보통 다른 사람이 답을 준다

같이 일하고 싶은 개발자가 되기 위해 갖춰야 할 4가지 요약

  1. 해결하려는 문제의 의도와 맥락을 먼저 파악한다.
  2. 상대방의 말을 듣고 내가 이해한 바가 맞는지 물어본다.

(연사님이 실제 소통하신 예시 사진)

  1. 안 되는 이유를 설명하기보다(괜한 기술적 설명으로 넘어가기 쉬움) 대안을 제시하는 데 집중한다.
  2. 아예 다른 선택지로 벗어나 색다른 해결 방법을 고민한다. (예: 꼭 이것만 답인 걸까? / 아예 다른 방법으로 해결할 수는 없는 걸까?)

어느 날 고민 많은 주니어 개발자가 찾아왔다 2탄: 주니어 시절 성장과 고민들

[ 연사: 김영한 개발자 님 🥳 ]

처음에 강연 시작하시기 전 강연장을 꽉 채운 청중들 방향으로 핸드폰 들고 같이 전체 사진 찍어주셔서 너무 좋았다❤ (나름 가까이 앉아 있어서 나왔을지도..!)

(😘)

강연 내용

  • 개발자로서의 성장을 위해서는 기술과 비즈니스 2가지 모두 중요

개발자의 종류

  • 기술에 대한 공부를 따로 안 하는 개발자 (X)

    • 팀 코드로 끝났다고 생각, 새로운 기술 도입 주저
    • 기술에 대한 깊은 이해 없이 주니어 수준의 업무 반복
      => 1년차 경험을 10번 반복하는 10년차 개발자가 된다

  • 기술 트렌드 찍먹 개발자 (X)

    • 공부를 하긴 함
    • 하지만 깊이 공부하지 않음
    • 팀 기술도 제대로 이해 못한 상태
  • 팀 기술을 잘 이해하는 개발자 (O)

    • 기술적인 자신감 -> 업무가 원활
    • 미리 공부해두고 업무적 이슈 해결
    • 조직에서 신뢰도 상승

회사 코드를 공부하면 얻는 장점

  • 당장 써야 함 -> 동기 충만
  • 학습 사이클 유리
    • 이론 배운 후 거의 바로 실습
      => 빨리 성장하는 주니어는 회사 코드를 잘 안다

개발 공부 순서

  • 1순위: 팀 기술 (회사 업무)
    • 정말 깊이 있게 파고 확실히 알기
  • 2순위: 업계의 다른 메인 기술
  • 3순위: 주변에서 써본다고 하는 최신 기술

비즈니스에 대한 이해

  • 비즈니스에 대한 이해를 못하면 전체 흐름을 그릴 수 없음
    • 전체 흐름을 모르면 나라는 개발자는 그저 수많은 퍼즐 중 하나이게 된다
  • 기술에 대한 학습 시간만큼 비즈니스에 대해 이해하는 것이 중요
  • 내 월급이 어디서 나오는가?를 생각
    • 고객이 우리 서비스를 구매하기 때문에
      => 우리 서비스(비즈니스)에 대해 개발자로서 잘 알아야
  • 비즈니스와 개발이 어떻게 연결되어 있는지 큰 지도를 그려보기
    • 전체 흐름을 알면 비즈니스 로직 변경 시 어디를 변경해야 할지 알게 된다.
  • 회사 서비스의 관련 자료(예: 기획서) 다 보기
    • 청사진 그리기
  • 기존에 서비스에 있는 메뉴 다 써보기
    • 지금 만든 화면 다 눌러보기
  • 이를 통해 그려봐야 하는 것
    • 데이터: 핵심 데이터(프론트: 상태)가 무엇인지
    • 프로세스: 팀의 메인 비즈니스 로직(흐름) 파악
      • 예: 입력 후 뜨는 연산, 차트, ...
      • 프로세스를 쉽게 정리해서 문서화한 뒤 공유하면 좋다
  • 이 단계를 거치고 나면 데이터와 프로세스가 겹쳐지면서 전체적인 상황을 그릴 수 있게 된다.

아키텍처

  • 아키텍처는 가변적이다 (변경 가능성이 있음)
    • 정답이 없고 중요한 것과 중요하지 않은 것을 결정하려면 비즈니스에 대한 이해가 필수이다.
    • 변할 것과 변하지 않을 것을 구분해서 변하지 않을 것은 과도한 추상화를 하지 않는다.

과도한 추상화는 트레이드 오프를 동반한다. (항상 좋은 것은 아님)

  • 인간은 컨텍스트 스위칭이 힘들다.
    • 하나를 먼저 깊게
    • 속도와 깊이는 상관 없음
    • 뭔가를 머릿속에 제대로 넣었는지 파악하라면 백지 공부가 좋다 (내 생각)
  • 한 번에 하나씩 하겠다는 거북이의 마음으로

Why 생각하기

  • 왜(why)를 알려면 근본적인 이유를 알아야
  • 그냥 하는 건 없다.
    • 무조건 '왜?'를 생각해야 올바른 대안을 찾을 수 있음
  • 뭘 받아도 무덤덤하게 해내면 빨리 성장
    • 이러려면 기술과 비즈니스에 대한 이해 필요
    • 최대한 단순하게 먼저 시작하자.
      • 고민은 적절히, 실행은 단순하고 빠르게
    • 책을 집필할 때 처음에 목차 잡기가 어려웠는데
      • 어느 정도 책을 쓰고 내용이 구체화가 되니 목차가 정리되었다.
  • 모르는 것에 도전할 때는 '용기'가 필요하다.
    • 3-6개월 간 서비스의 전체적인 틀 이해하면서
    • 팀에서 중요한 업무에 도전해야
  • '왜?'라는 고민이 쌓여 깊이가 쌓인다.

일하기 좋은 조직

  • 성장에 좋은 환경
    • 일하기 좋은 방향으로 바꾸어 나가려고 노력하는 조직
    • 고민하고 도전하는 걸 응원해주는 조직

최적화는 나중에

  • 최적화는 서비스 오픈 후에 유저 트래픽을 보고 결정해도 된다.
    • 나중에 최적화가 정-말 필요할 때 하기
    • 사실 최적화는 안 해도 된다!

다른 직군과 일할 때

  • 기획자, 디자이너와 소통할 때
    • 절대 '공격'을 해서는 안 됨
  • '왜 이렇게 했는지'를 잘못 물으면 공격이 된다.
  • 방법: '고민이 있습니다' 하고 다가가기
    • 존중하지 않는 상대에겐 고민을 털어놓지 않음
    • 살펴봤는데 이 부분이 좀 우려가 된다, 약간 걱정이 된다
    • 우선 내 편으로 만들고 나서 내가 생각해온 대안을 던짐

점진적 추상화

  • 인터페이스의 추상화는 필요한 만큼만
  • 구체화를 먼저 하고 추상화
    • 처음부터 추상화하기는 쉽지 않음
    • 추상화의 적절한 방향, 범위, 시기를 고민
  • 코드를 단계적으로 추상화하기
    • 함수 추출부터 시작해서 점진적으로 추상화
    • 그러면 더 분류하거나 생각할 것이 보이게 됨

주니어 개발자가 성장하는 법

[연사: 배휘동 님]

  • 사람들에게 질문할 때
    • 'Don't make me think.'
      • 듣는 입장에서 고민하지 않도록 구체적으로 질문
  • 효과적으로 학습하는 '방법'을 학습하면 복리 이득이 있다.
  • Divide and Conquer
    • 작게 쪼개서 정복해나가기
  • 내가 알고 있는 것과 반대되는 것을 발견할 시 즉시 메모 (feat. 다윈)

인프콘 가는 길 (팁)

삼성역에서 내려서 코엑스로 들어온 다음 별마당 도서관을 지나서 엘리베이터 1층을 올라간 뒤 그랜드볼룸(인프콘 장소)으로 가는 길이다.

삼성역에서 오게 되면 미로같은 코엑스를 헤매는 시간을 포함해서 체감상 15분 이상은 걸어야 한다. 인프콘 장소인 그랜드볼룸이 삼성역에서는 꽤 멀다.

추천하는 경로는 9호선 봉은사역 7번 출구에서 내려서 아셈광장 계단을 올라와 건물 바깥에서 바로 그랜드볼룸 안으로 들어가는 것이다. 내년에도 오게 되면 꼭 9호선으로 오리


마지막으로 참가비 겨우 2만원 내고 ㅠㅠ 털어온 굿즈 대공개

^^..

언박싱을 하지 않은 굿즈가 몇 개 있다. 휴대용 선풍기 2개, 보조 배터리 하나, 카카오에서 준 노란 수건, 무신사의 담요 등등
무신사 굿즈가 진짜 알찼다

한 부스에서 여러 가지 굿즈를 넣어준 보따리 안에 생수가 껴 있는 걸 집에 와서 발견했다. AWS와 점핏에서 준 선풍기 2대도 있었다.

저걸 다 들고 다니면서 강연을 듣다가 진이 빠져서 (사람이 많아 강연장이 꽉 차기 때문에 옆 자리에 짐을 둘 수 없음) 결국 마지막 시간 강연은 안 듣고 한 시간 일찍 나왔다.

(9호선 봉은사역을 가기 위해 아셈광장 쪽으로 가다가 발견한 건물)

(봉은사역 지하철 역에 있는 미술품)


내년 인프콘도 참여할 수 있을지 모르겠지만 담날 하루 쉴 수 있게 주말(특히 토요일)에 열리면 좋겠다 😏


2023년 인프콘 2기 후기 끝!

profile
데이터 분석가 준비 중입니다 (티스토리에 기록: https://cherylog.tistory.com/)

0개의 댓글