인프콘 2023 후기 - 듣고 배우고 느끼고

주싱·2023년 8월 16일
12

읽고/듣고/배우기

목록 보기
5/7

전날 아이들과 하루종일 수영장에서 놀았던 탓인지 피곤한 몸을 이끌고 아침 해를 보며 용산행 기차를 탓다. 저녁에 돌아오는 기차 안에 나는 거의 녹초가 되어 있었던 것 같다. 그러나 오늘 듣고 배운 것들이 내 인생에 씨앗으로 뿌려져 언젠가 싹트고 자라서 열매 맺을 일이 있을거라 생각한다. 힘들지만 즐겁고 유익한 시간이었다.

인프랩의 미래 - 교육을 넘어 라이프타임 커리어 플랫폼으로


인프런에 유입되는 키워드 중 ‘사이드 프로젝트’의 비율이 ‘스프링’과 ‘리액트’를 합친 비율보다 크다는 데이터 분석 결과가 흥미로웠다. 사이드 프로젝트는 성장과 취업을 위한 중요한 매체가 된다는 것을 알 수 있었다. 그리고 ‘나이키의 경쟁사는 아디다스나 리북이 아닌 닌텐도다’라는 말로 시작하며 랠릿의 비전에 대해 설명해 주셨는데 신선하게 느껴졌다. ‘우리는 노션에 있는 모든 이력서를 랠릿으로 옮기는 것을 목표한다’ 멋지다. 그리고 꼭 이루셨으면 좋겠다. 내 노션 이력서는 이미 랠릿에 옮겨져 있지만 아직 랠릿 이력서가 잘 활용되고 있지는 않다. 그러나 미래의 판도는 아무도 모르니까. 인프런의 키노트 세션은 다른 대규모 컨퍼런스들의 키노트와는 약간 다른 느낌을 받는다. 개발자인 우리 가까이 있는 느낌이랄까? 급하게 커피 수혈하고 들어가느라 조금 늦었지만 즐거운 컨퍼런스 시작이었다.

소프트웨어 설계를 위한 추상적, 구조적 사고


(코발트, 이선협님)

발표의 핵심 소제인 소프트웨어 ‘설계’에 대한 설명으로 발표가 시작되었다. 설계는 실세계의 문제를 컴퓨터로 해결하기 위한 시작점, 다른 표현으로 실세계와 컴퓨터 세계 사이에 있는 단계라는 표현이 좋았다. 또한 시니어 개발자라면 풍부한 경험에 의해 직관적으로 좋은 설계를 할 수 있지만 한계점이 있고, 이를 위해 어떤 문제를 만나도 유연하게 문제를 해결할 수 있는 방법론이 필요하다고 어필하셨다. 그리고 그 중 하나가 오늘 설명할 추상적이고 구조적인 사고라고 했다.

개발자가 하는 거의 모든 일은 추상적이고 구조적인 생각을 통해 온다고 하셨는데 무척 공감되었다. 발표자님의 추상화에 대한 설명을 요약해 본다. “추상화란 대상을 분석하고 해체하여 다시 재조립하는 과정을 통해 되어진다. 이를 통해 대상을 단순화하고 재해석하는 것이 목적이라고 할 수 있겠다. 그러나 지나친 추상화는 실체를 파악하기 어렵게 만들 수도 있음으로 목적에 맞게 적절한 추상화가 중요하다.” 이 설명 가운데 특히 추상화는 실체를 파악하기 어렵게 만들 수도 있음으로 적절한 수준의 추상화를 강조하신 부분이 좋았다. 위 사진 처럼 어떤 관점에서의 추상화는 원래 대상이 무엇인지 알 수 없게 되기도 한다. 이어서 추상화의 수준은 협의가 필요하다는 중요한 이야기를 전해주셨는데 예전에 어떤 글에서 설계는 설득의 과정을 포함한다고 말해주셨던게 기억나서 다시 머리 속에 되뇌이게 되었다. 조직의 결정은 협의되어야 한다!

구조화에 대해서도 설명해 주셨다. 만약 우리가 전달하려는 컨텐츠(코드든 기술 문서든) 전체가 단순히 나열되어 있다면(구조화 없이) 전체를 다 읽기 전에는 어떤 내용인지 파악하기 어려운 문제가 생기는데 구조화를 통해 이런 문제를 해결할 수 있다고 했다. 구조화는 큰 그림에서 시작해서 점점 세부적인 것들을 다루는 Top-down 방법과 세부적인 것들을 완성하며 점점 큰 개념을 잡아가는 Bottom-up 방법이 있는데 이를 상호보완적으로 활용할 수 있음을 설명해 주셨다. 뒤에 김영한님 발표에도 비슷한 맥락의 표현이 있었던 것 같다. 책을 쓸 때 개요부터 잡고 세부 글을 쓰거나, 세부 글을 다쓰고 개요를 잡는 것이 아니라 둘을 왔다 갔다 하며 컨텐츠가 완성되어 지는 것 같다고 하셨는데 현실 세계를 살아가는 나에게 역시 정말 공감되는 말인 것 같다. 그리고 구조화 역시 많은 장점이 있지만 어떤 경우에는 고정된 틀로 인해 창의적인 사고를 막는 등의 부작용도 생길 수 있음을 균형있게 설명해 주셔서 좋았던 것 같다.

출시 3일만에 앱스토어 2위를 달성한 사이드 프로젝트


(Skrr, 김현준님, 김아인님)

발표자 분을 유튜브에 올라온 EO 채널 영상에서 먼저 만났었다. 실제로 뵙고 이야기 듣고 싶어서 다른 발표들을 제쳐두고 101호로 갔다. 고등학생 두분이 나와서 발표를 이어갔는데 나는 저 시절에 무엇을 했는지 생각해 보지 않을 수 없었다. 김현준님께서 EO 영상에서 자신은 특별한 사람이 아니라고 하며 이유를 설명했는데 이유가 무척 인상깊었다. 이유인 즉슨 자신이 속한 세대의 사람들은 이런 서비스를 만들고 마케팅 하기에 너무 좋은 환경이 만들어져 있어서 그냥 누구나 할 수 있는 걸 자신은 어렵지 않게 한 것 뿐이라고 했다. 그리고 선배 세대에서 너무 좋은 환경을 만들어 주신 것 같다고 했다. 내가 이 세대가 아니라 진짜 그런지는 모르겠지만 아마도 아무리 좋은 판이 깔려있어도 실제로 해보는 사람은 많지 않을 것 같다고 생각했다. 그래서 당신은 특별한 사람 같다고 생각했다.

김현준님이 먼저 발표를 하셨는데 다음과 같은 것들에서 인사이트를 얻고 배움을 얻었다.

  • 비지니스의 성공을 위해 덜 중요한 것(앱 이름, 아이콘)과 더 중요한 것(디자인, UX)을 나누어 생각하는 모습
  • 덜 중요한 것에 최소한의 자원을 사용하고, 더 중요한 것에 더 많은 자원을 신중히 사용하는 모습
  • 좋은 가설을 세우고 가설을 검증하는데 집중하는 모습
  • 실패를 회고하며 배우는 모습
  • 실패 후 또다른 기회(일본 시장)를 찾고 다시 실험하는 모습

이어서 김아인님의 발표가 이어졌는데 겉멋들지 않은 파닥파닥 살아있는 젊은 엔지니어를 보는 것 같았다. 아직 수익이 보장되지 않은 실험적인 서비스에 과금이 될지도 모르는 클라우드 서비스를 사용할 수 없어 홈서버를 사용했다는 의사결정, 그리고 사용자 경험 최적화를 위해 Flutter는 Android에만 적용하고 iOS에는 Swift를 사용하기로 한 의사결정이 인상깊었다. 두 선택이 최선이었는지 내가 알 수 없지만 ‘이유’가 있는 의사결정이 멋지다고 느껴졌다.

발표를 듣고 기술 수준을 향상시키려는 노력도 중요하지만 실제 서비스를 만들어 런칭하고 사용자를 서빙해 보는 경험이 정말 중요한 게 아닌가 다시 한 번 생각하게 되었다. 마지막으로 발표 마지막 장표처럼 아직은 작다면 작다고 할 수 있는 두 분이, 언젠가 커서 사회에 좋은 영향력을 미치는 좋은 서비스를 계속해서 만들어 주면 좋겠다고 생각했다.

왜 구글의 시니어 개발자는 코딩을 안할까?


(Google, 이다니엘)

트위터에서 좋은 글로 자주 접하던 다니엘님을 실제로 뵙게 되었다. 발표는 다니엘님이 구글에 입사했을 당시의 일화로 시작되었다. 그때 당시 마법사(탑탑탑 클래스) 수준의 시니어 개발자와 미팅을 하게되어 몇 가지 질문을 했는데 재미있는 답변을 받으셨다고 한다.

  • Q : 요즘 개발하면서 어떤 언어를 제일 자주 쓰시는 것 같으세요?
  • A : 영어
  • Q : 그럼 IDEA는?
  • A : Google Docs
  • ….

이 처럼 구글에 다니면서 만난 시니어 개발자들은 코딩을 거의 하지 않는 것 같아 보였는데 ‘그들은 도대체 무슨일을 하는 걸까?’ 라는 질문에 답을 주는 컨셉의 발표가 이어졌다. 이론적 설명으로 먼저 개관해 주셨다. 개발이란 것은 코딩과 시간과 사람의 합으로 표현할 수 있는데 주니어 시절에는 코딩에 많은 시간을 할애한다면 시니어가 될 수록 시간과 사람과 관계하는 일을 많이 하게 된다는 것이다. 그리고 이어서 그렇다면 실제적으로 구글의 시니어는 어떤일을 하는지 곱빼기 코딩, 진명, 정원사라는 3가지 컨셉으로 설명을 이어갔다.

첫째 곱빼기 코딩. 개발자를 포함한 모든 직장인은 회사의 아웃풋에 기여하는 기본적인 목적을 가지는데 주니어 개발자라면 더하기 기여를 한다면 시니어 개발자라면 곱하기 기여를 한다고 설명해 주셨다. 더하기 기여의 예로는 직접 코드를 작성해서 기능을 만들거나 버그를 고쳐서 안정적인 제품을 만드는 일 등이 있겠고 곱하기 기여라면 아래와 같은 실제적인 일들을 한다고 소개해 주셨다.

  • 주기적인 리팩토링 (스파게티화 막는다)
  • 좋은 테스트 패턴을 적용, 추후 테스트 작성이 쉽게 한다 (회귀 방지)
  • 흔히 하는 실수를 예방하도록 좋은 실천 가이드, 또는 시스템을 통해 예방 (Linter Role)
  • 새로운 기능의 안전한 배포를 위해 A/B 테스팅 프레임워크 도입
  • 자주쓰는 기능을 모듈화해서 바퀴를 재발명하지 않도록 한다.

종합해 보면 주니어 시절에는 직접적으로 기능을 만들어 기여한다면 시니어가 될 수록 점점 더 다른 사람이 더 쉽게 안정적으로 제품에 기여 할 수 있는 배경, 구조를 만드는 일을 하게 된다는 것이다.

둘째 진명. 정확히 기억나지 않는데 마법사가 사물의 진짜 이름을 알게 되면 사물을 마음대로 조정할 수 있는 능력을 가지게 되는 판타지 소설 이야기를 소개해 주셨다. 개발자에게 비지니스의 문제를 이해하게 되는 것이 판타지 소설에서 마법사가 사물의 이름을 알게 되는 것과 같다고 소개해 주셨다. 개인적으로 너무 신선하고 마음에 와닿는 비유인 것 같다. 그리고 시니어 개발자는 비지니스 영역에서 문제의 배경, 문제 정의, 그리고 문제 해결을 위해 기술적으로 어떤 요구가 있는 파악하는 역할을 한다고 설명해 주셨다.

셋째 정원사. 구글의 시니어 엔지니어는 개발팀의 문화를 가꾸는 일을 한다고 했다. 예를 들면 단순히 코드리뷰를 해주는 것을 넘어 코드리뷰를 위한 가이드를 만든다거나, 멘토링을 하는 걸 넘어 멘토링 프로그램 자체를 지원하는 개념이었다. 구글에서는 이렇게 커뮤니티에 얼마나 기여했는지가 승진의 요건이 된다고 하셨고 이런 점이 구글의 좋은 점이라고 생각한다고 말씀하셨다.

마지막으로 “내가 쓰는 변수는 사람이다… 주니어는 망치로 일을 한다면, 시니어는 망치를 사용하는 것이 적절한지 또는 망치를 휘두를 때가 맞는지 고민한다” 같은 주옥같은 말을 소개해 주셨고 내 안에 큰 울림이 있었다. 최근에 구직을 하면서 내가 새로운 회사에 들어가면 어떤 역할을 해야하는지 고민이 있었는데 오늘 발표를 들으며 큰 도움이 된 것 같다. 잊고 있었던 소중한 것들을 다시 기억나게 해주는 고마운 발표였던 것 같다.

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


(인프런 지식공유자, 김영한님)

발표장에 들어서니 영한님을 좋아하는 많은 개발자들이 발표장을 가득채우고 있는 듯 했다. 주니어라고 말하기에 나이가 많아진 나지만 새로운 영역에 도전하며 주니어 시절 처럼 학습이 필요한 때라 생각되어 발표장에 들어갔다. 여러 좋은 이야기들이 있었지만 나에게 깊이 와닿는 몇 가지만 정리해 본다.

먼저 우아한 형제들을 그만두고 교육자의 길로 접어든 이야기를 해주셨다. 자신은 우형에서 서비스를 만드는 일이 너무 즐거웠지만 교육자의 길로 업계 전반의 성장에 기여하고자 하는 마음으로 회사를 나오게 되었다고 했다. 앞서 다니엘님의 발표에서 시니어에 대한 정의와 맥을 같이 하는 것 같다. 곱하기 기여를 위해 새로운 선택을 하신 영한님의 행보를 응원한다.

이어서 기술적 학습 이야기도 해주셨지만 그 보다 비지니스에 대한 이해를 강조하신 부분이 좋았다. “내가 코드를 작성한다고 월급이 들어오지 않는다”는 짧고 굵은 이야기를 전해주셨는데 맞다. 내가 코딩을 아무리 많이 해도 결국은 코드가 비지니스 세계의 문제를 해결해야 내 월급이 들어오는 것이다. 뿐만 아니라 비지니스 영역을 제대로 이해하지 않으면 전체적인 관점에서 문제를 바라보고 최적의 해결책을 도출해 내지 못하는 경우가 많고 그래서 퍼즐의 한 조각만을 다루는 개발자로 시간을 보내게 된다고 설명해 주셨다. 또한 우리가 흔히 말하는 좋은 코드는 비지니스 영역의 변경을 쉽고 안정적으로 다루기 위해서 존재한다고 표현할 수도 있는데 비지니스 영역에서 무엇이 바뀌는지 이해하지 못하면 엔지니어링 측면에서의 좋은 코드 역시 작성할 수 없음을 역설해 주셨다.

마지막으로 성장을 위해서는 컴포트존을 적절한 시기에 벗어나는 용기가 필요하며, 성장하기 좋지 않은 토양을 가진 회사는 분명히 존재하기 때문에 좋은 토양을 가진 회사를 선택하는 것도 중요하다고 했다. 여기서 좋은 토양이란 당장 좋은 회사라기 보다는 일하기 좋은 방향으로 나아가려 노력하는 조직이라고 설명해 주셨다. 이 대목에서 내가 이직하기로 한 회사는 좋은 토양이 되는 회사인가 자문해 보았는데 사실 정보가 제한적이라 좋은 토양인지 판단할 수 있는 근거가 미비하다. 역시 가보는 수 밖에 없구나 생각했다.

인프런에서 수천 개의 테스트 코드를 이렇게 다루고 있어요


(인프랩, 이민우님)

인프런의 CTO이신 동욱님께서 테스트에 대해 많은 강조를 하시는 걸 봐와서 인프런은 테스트 코드를 어떻게 작성하고 관리하는지 궁금했다. 그러나 발표장에 앉았는데 이번 시간은 쉬지 않으면 도저히 안 될 것 같은 몸의 신호가 몰려왔다. 그래서 몸에게 휴식 시간을 주기로 하고 테라로사에 가서 커피를 한잔하며 숨을 돌렸다. 아쉽지만 이 발표는 다음에 온라인으로 들어야겠다.

함수형 프로그래밍 3대장 경험기 - 클로저, 스칼라, 하스켈


(컨스텍츠, 김대현님)

몸에 휴식을 주다 조금 늦게 발표장에 들어가게 되었다. Clojure, Scala, Haskell 언어들에 대해 개관해 주셨고 함수형 프로그래밍에 있는 핵심 개념 몇 가지를 소개해 주셨다. 그 중에서 함수형 프로그래밍의 ‘참조 투명성’ 개념을 사용하면 함수를 수학적으로 옳다고 증명할 수 있는 등식 추론 개념을 소개해 주셨다. 일반적으로 부수효과가 있는 코드들은 테스트 코드에 의존해서 코드를 검증하더라도 모든 케이스를 확인했다고 할 수 없어 검증의 한계가 있다. 그런데 함수 호출을 값으로 대체할 수 있는, 즉 어떤 입력 X에 대해 Y가 결정되어 있는 순수함수는 우리가 고등학교 때 수식이 옳음을 증명하듯 검증할 수 있다는 것이다. 개인적으로 최근에 함수형 프로그래밍 언어 자체보다 객체 지향 언어에 함수형 언어의 특징을 살려서 코딩하는 것에 관심이 많아졌다. 그래서 불변성, 멱등성, 참조투명성 같은 개념들을 객체 지향언어에 적극 활용하려 노력하고 있다. 개인적으로 인프런에 ‘객체 지향언어에서 함수형 언어의 특성을 십분 활용하는 방법’ 같은 강연이 생기면 좋겠다는 상상을 하며 강연장을 나왔다.

시니어 개발자 너머의 성장 (대규모 조직을 위한 스태프 엔지니어)


(스포티파이, 남상수님)

스포티파이가 스웨덴 회사인 것을 처음 알았다. 그리고 스웨덴 본사에서 일하는 첫 번째 한국 개발자라고 자신을 소개해 주셨다. 이번 인프콘은 글로벌한 발표자들이 많은 것 같다. 발표를 들으며 스태프 엔지니어란 개념을 처음 접해 보았다. 이전까지 시니어 엔지니어의 역할에 대해 두루뭉술한 개념만 가지고 있었는데 스태프 엔지니어의 역할에 대해 콕 찍어서 설명해 주셔서 좋았다. 스태프 엔지니어 역시 일반적인 시니어의 역할 처럼 개인 보다는 팀이 함께 잘 할 수 있는데 도움이 되는 역할을 하는데, 한 걸음 더 나가 팀 내에서 보다 여러 팀에 영향을 미치는 조금 더 큰 의사결정이나 문제 해결에 집중하는 역할임을 이해하게 되었다. 발표를 들으며 나의 예전 회사에서의 문제들이 떠올랐다. 회사가 크게 하드웨어팀과 소프트웨어팀으로 나누어져 있었는데 각각에 정통한 리더들이 영입되었다. 내가 일하면서 어려웠던 건 하드웨어 엔지니어와 소프트웨어 엔지니어의 다른 특성들 때문에 둘이 조화를 이루지 못하는 부분이었는데 각각의 리더들도 하드웨어와 소프트웨어 각 분야에서만 전문가이고 서로를 이해할 수 있는 지식이나 경험이 부족했던 것 같다. 이 두 팀 사이에 스태프 엔지니어가 있었으면 정말 좋았겠다는 생각이 들었다. 물론 그런 인사를 찾는 것 자체가 무척 어려운 일이라는 생각도 들었고 그래서 높은 연봉을 받을 수 있겠다는 상상도 했다. 문득 예전 회사에서 그런 자리를 제안해 준다면 내가 적임자가 아닐까 이런 괴상한 상상을 했다. 마지막으로 성장은 여정이라고 생각한다는 말로 발표를 마치셨는데 나도 계속해서 이 여정을 이어가고 있다.

내년을 기약하며


온라인으로 봐왔던 몇몇 분들을 발표자로 또는 스쳐지나며 본 것 같다. 그러나 말을 걸거나 하는 스타일이 아니라 조용히 아 저분 계시네 생각하며 지나쳤다. 짧게 읽기 모임을 했던 토비님을 멀리서 뵈서 반가웠고, 다니엘님 실제로 뵈니 반가웠다. 다른 몇몇 분들도 반가웠다. 일명 내향형 반가움이다. 기업부스에 커피챗을 했던 헤렌이 있어서 CTO님이 계신가 살짝 봤는데 안계셨다. 그래서 유일하게 인사를 해야지 마음먹은 분도 못보고 왔다. 하루 종일 말은 한마디도 안했지만 얻어 온 것은 많은 하루다. 특히 시니어 개발자로의 역할에 대해 많은 인사이트를 얻어온 것 같다. 2024년 인프콘도 꼭 당첨되어 갈 수 있으면 좋겠다. 내년 인프콘이 열릴 때까지 새 회사에서 하루하루 열심히 살아야겠다. 그리고 혹 나누고 싶은 재미있는 이야기가 생기면 또 발표자로 나서는 도전도 해보고 싶다. 감사하다.

profile
소프트웨어 엔지니어, 일상

6개의 댓글

comment-user-thumbnail
2023년 8월 16일

글 잘 봤습니다.

1개의 답글
comment-user-thumbnail
2023년 8월 18일

정리해주실 글 잘 읽었습니다. 개인적으로 '왜 구굴의 시니어 개발자는 코딩을 안할까?' 부분이 인상깊네요. 진명 부분에서 어떤 시니어로 성장해야하는지 적당하고 와닿는 비유를 통해 배웠습니다. 고맙습니다.

1개의 답글
comment-user-thumbnail
2023년 8월 19일

정리해주신 글 잘 읽었습니다. Joosing님 글을 읽고 댓글을 다는것은 처음이네요. 😀
인프콘을 가지않았지만 생생한 현장내용이 글에 담겨있어서 ,글 너머 생생한 현장에 있다고 생각이드는 글이였습니다.

적절하다 ..라는단어가 최근에는 가장 어렵게 느껴지는것같습니다.
적절한 추상화 , 적절한 시기에 컴포트존 벗어나기.. 적당히, 남들하는만큼 적절하게 .. :0 흑백논리로 모든것들을 맞다/틀리다 관점에서 볼순 없겟지만 .. 가끔 추상적인 표현이 어떤 기준에 맞추어서 수치화로 표현되면 좋을것 같다는 생각이 듭니다. 😕

1개의 답글