다녀왔습니다, TEOConf 2024

2024년 12월 7일

들어가면서

개발자라면 누구나 한번쯤은 가 보고 싶은 곳, 바로 컨퍼런스입니다. 다양한 개발자들이 모인 곳에서 함께 세션을 듣고, 네트워킹하며 인사이트를 얻어갈 수 있는 시간을 가지는 행사예요. 저는 늘 이런 컨퍼런스에 한번쯤 가 보고 싶었습니다. 뭔가 멋있어 보이기도 하고, 나와 같은 직군에 종사하는 분들을 만나면 어떤 이야기들을 들을 수 있을까 궁금하기도 했기 때문입니다. 그래서 올해 초 FEConf 2024에 다녀오기도 했습니다. 아쉽게도 첫 컨퍼런스 경험이었지만, 얻어간 것들이 적다는 생각이 많이 들었습니다. 직접 사용해보지 못한 기술들에 대한 이야기와 어려운 개념 때문에 인사이트보다 물음표를 더 많이 떠안고 집에 돌아와야 했어요. 배움이 아직 적은 저에게, 첫 컨퍼런스는 마치 ‘그들만의 리그’와 같은 경험이었습니다.

그러던 중 지인에게 TEOConf 2024(이하 테오콘)가 열린다는 소식을 듣게 되었습니다. 이번 컨퍼런스도 저번과 같이 그냥 빈손으로 돌아오면 어떡하지라는 생각을 하던 차에, 소개 페이지에서 본 문구가 관심을 끌었습니다.

TEOConf 2024는 모두에게 열려있는 컨퍼런스라는 컨셉으로, 누구나 자신의 경험과 지식을 공유할 수 있는 즐거운 네트워킹의 장을 마련합니다.

‘모두에게 열려있는 컨퍼런스’라는 문구가 흥미를 자극했고, 뒤이어 소개된 세션들의 제목도 저에게는 더 친숙하게 다가와 신청하게 됐습니다. 뽑는 인원수가 그렇게 많지는 않아 혹시 떨어지면 어쩌나 했지만, 정말 운이 좋게도 당첨되어서 다녀오게 됐습니다. 테오콘은 네트워킹 세션이 존재하는데, 이를 위해 사전에 5인 정도의 규모로 조가 편성되어서 어떤 분들을 만날까, 이야기는 잘 해볼 수 있을까 두근거리는 마음을 안고 발걸음을 옮겼습니다.

TEOConf 2024 후기

대략적인 진행 순서는 아래와 같았습니다. 테오콘의 공간 대여를 진행한 ‘항해 플러스’에 대한 소개와, 팀빌딩과 팀네트워킹을 마친 뒤 세션을 듣고 각 세션별로 팀 네트워킹을 진행하는 순서로 진행됐어요.

시간표

• 입장, 오프닝과 스폰서 소개 - 항해 플러스!
• 팀빌딩과 팀네트워킹
• 세션1
• 세션2
• 세션3
• 세션4
• 테오의 Q&A
• 선물교환식과 마무리

팀빌딩과 팀네트워킹

항해 플러스에 대한 소개를 듣고 난 뒤에는 팀빌딩과 팀네트워킹 세션이 진행됐습니다. 각자 서로에 대해서 소개하고 짧은 이야기를 나누면서 아이스브레이킹을 진행할 수 있는 세션이었어요. 일정이 끝날 때까지 서로 어색한 상태로 있으면 어떡하지라는 걱정이 들었지만, 다들 능동적으로 참여해 주시고 특히 저희 팀의 MC를 자처해서 맡아주신 분(고마워요 요마!) 덕분에 금새 화기애애한 분위기가 됐습니다. 초성퀴즈나 음악 1초 듣고 맞추기 같은 간단한 레크리에이션도 진행했는데, 이후 세션이 끝날 때마다 해당 세션에 대해 서로의 의견을 교환하는 세션 네트워킹 시간에 더 자유롭게 이야기를 꺼낼 수 있게 됐습니다. 테오콘의 배려가 돋보이는 진행이었어요. 그럼 본격적으로 세션에 대한 이야기를 하나씩 해 볼까요?

세션1: 30인의 심리 싸움, 오프라인 주식게임 제작기

• 어느 날 찾아온 개발 권태기를 극복하기 위한 사이드 프로젝트
• 예능 프로그램에서 봤던 게임을 소셜 게임 형태로 구현하기
• 개발할 때 신경썼던 두 가지: 한정된 시간 내에 빠르게 개발하기, 고가용성
• 모임 서비스 MUNTO에 주식게임을 런칭한 후기
• 소셜 게임 프로젝트를 진행하며 얻은 것과 앞으로의 미래

테오콘의 시작을 연 첫 번째 세션은 하이안의 ‘30명의 심리 싸움, 오프라인 주식게임 제작기’였습니다. 하이안은 4년차 프론트엔드 개발자로, 부업과 재태크에 관심이 많은 호기심 부자라고 스스로를 소개했어요. 어느 날 갑자기 번아웃이 찾아온 그는 회사 밖의 삶을 찾고 동기부여를 얻기 위해 사이드 프로젝트를 시작했습니다. 예능 프로그램 더 지니어스의 게임 중 하나였던 ‘폭풍의 증권시장’을 소셜 게임으로 만들고 이를 직접 운영하며 수익을 얻는 과정을 진행하면서, 어떻게 번아웃을 극복하고 성장할 수 있었는지를 알아볼 수 있었습니다. 특히 개발자로 기획, 디자인, 개발, 마케팅이라는 과정을 전부 스스로 진행하는 과정이 인상깊었습니다. 개발 과정에서는 한정된 시간 내에 개발을 완료하기 위해 불필요한 기술 스택을 배제하고, 고가용성을 확보하기 위해 익숙한 기술을 사용하며 신뢰 가능한 AWS 클라우드 등을 선택하는 등 어떤 부분에 중점을 두고 개발을 진행했는지가 잘 드러나서 좋았어요.

또한 번아웃을 느꼈을 때 이를 극복하기 위해 작은 아이디어라도 직접 실행에 옮기게 된 모습이 인상깊었습니다. 단순히 아이디어로만 남기지 않고, 이를 실제 프로덕트로 구현해 수익까지 창출해낸 실행력이 저에게도 큰 동기부여가 되어 주었습니다.

세션2: Trunk Code Quality로 일관성 있는 코드를 쓰는 개발자 되기

• 일관된 코드 작성의 중요성과 어려움
• 린터 및 포맷터 관리의 중요성
• Trunk에 대한 소개와, React Native Step Counter를 개발하면서 적용해 본 후기

두 번째 세션은 앤드류의 ‘Trunk Code Quality'로 일관성 있는 코드를 쓰는 개발자 되기’ 였습니다. 글을 읽고 계신 여러분 모두 린터(Linter)와 포맷터(Formatter)에 대해서 잘 알고 계실 거라고 생각합니다. 전자는 소스 코드를 분석해 문법, 잠재적 버그, 스타일, 컨벤션과 관련된 문제를 찾아내는 도구입니다. 후자는 소스 코드를 자동으로 지정된 스타일 규칙에 맞게 정렬하고 재구성하는 도구이고요. 저는 린터로는 ESLint, 포맷터로는 Prettier를 주로 사용합니다. 이러한 린터와 포맷터는 전략없이 사용하게 된다면 런타임 버전과 설정 충돌 등으로 개발자의 골머리를 앓게 하는 원인이 되기도 합니다.

앤드류는 평소 일관된 코드 작성의 중요성과 어려움에 대해 고민해오던 중, 회사에서 진행한 React Native 기반의 Step Counter를 자체적으로 개발하면서 Trunk라는 DevEx 툴킷을 접하게 됐습니다. 공식 문서에서, Trunk는 자신의 역할을 이렇게 정의하고 있습니다.

"Trunk is a developer experience(DevEx) toolkit that enables you to ship code quickly while maintaining the necessary guardrails for excellent engineer teams."

코드를 빠르게 배포하면서, 필수적인 가드레일(코드 스타일)은 유지할 수 있도록 도와주는 도구인 셈이지요. Trunk에 대해서 조금 더 소개하자면, 기존의 오픈소스 린터, 포맷터, 정적 분석 도구를 설치, 관리, 실행하고 일관된 출력을 제공할 수 있습니다. C++로 작성되어 있어, 단순히 기존의 린터들을 husky등을 사용해 차례대로 실행하는 것 보다 더 빠르기도 하고요. 또한 코드 베이스 전체를 검사하는 대신 새로운 변경 사항에 대해서만 검사를 실행하는 등 더 나은 생산성을 확보하기 위한 차별점도 가지고 있습니다. 앤드류가 개발해야 했던 Step Counter 기능은 다양한 언어를 사용하고 있었고, 각 언어에 따른 코드의 스타일도 구체적으로 지정되어 있었기에 Trunk를 적용하면서 더 나은 개발 경험을 확보할 수 있었습니다. 또한 오픈소스 라이브러리로 만들어 배포하기도 했습니다.

앤드류의 세션은 개발자가 코드 품질에 대해서 지녀야 할 책임감과, 지속 가능한 소프트웨어 개발을 위한 방법에 대해서 한번 더 생각해 볼 수 있는 기회가 되었습니다. 다음 프로젝트에는 Trunk를 꼭 사용해 봐야겠어요.

세션3: 출근해서 바로 써 먹을 수 있는 커뮤니케이션 팁

• 보다 나은 생산성을 위해 생각해볼 수 있는 것: 커뮤니케이션
• 팁 1. 팀원들과 디테일에 대한 생각 맞추기
• 팁 2. 대화할 때 배경지식 even하게 맞추기
• 팁 3. 궁금해 할 점 예측하고 미리 대답하기
• 팁 4. 대안이 있다면 같이 제시하기
• 팁 5. 전달할 내용 한번에 전달하기
• 팁 6. 예측가능하게 작업상황 자주 공유하기
• 팁 7. 이슈 가능성 미리 공유하기
• 팁 8. 마감일과 중요도를 파악하기

세 번째 세션은 동훈의 ‘출근해서 바로 써 먹을 수 있는 커뮤니케이션 팁’이었습니다. 교육 스타트업에 재직중인 그는 보다 나은 생산성을 위한 방향에 대해서 고민하던 중, 커뮤니케이션을 개선할 수 있는 방법에 대해 고민하고 8개의 팁을 공유했습니다. 세션의 목표는 제목처럼 내일 당장이라도 출근해서 써먹을 수 있는 커뮤니케이션 팁에 대해서 소개해주는 것이었습니다. 동훈은 업무상 비동기 커뮤니케이션(채팅, 메일 등 실시간 상호작용을 기반으로 하지 않는)을 하게 되는 경우가 더 많다고 했습니다. 이러한 비동기 커뮤니케이션 상황에서는 상대의 답장이 언제 올지 모르기 때문에, 자신의 커뮤니케이션 스킬에 집중하는 방향을 선택했습니다.

저는 평소 교육 프로그램에 참여해 팀 프로젝트를 진행하면서 소프트스킬에 대한 긍정적인 피드백을 많이 받았습니다. 그럼에도 불구하고 스스로는 아쉬운 부분이 있다고 느낀 경우들이 종종 있었습니다. ‘처음부터 이렇게 이야기했다면 대화 자원을 덜 소모해도 됐을텐데’, ‘보다 나은 답변을 받기 위해서 내 질문 방법을 개선해야 하는 것이 아닐까?’라는 고민을 하곤 했어요. 그래서 동훈의 세션이 더 도움이 됐습니다.

소개된 모든 팁들에 공감했지만, 그중 가장 와닿았던 팁은 이슈 가능성 미리 공유하기였습니다. 프로젝트를 진행하면서 처음 구현해보거나 익숙하지 않은 작업을 진행해야 할 때, 다음과 같이 이야기해볼까요?

"페이지네이션 컴포넌트는 익숙하지 않아서 구현을 완료하기까지 시간이 더 걸릴 것 같습니다. 예정대로라면 7일에 PR을 올릴게요."

팀원들은 7일까지 제가 작업을 최대한 진행할 것이라는 사실과 함께, 익숙하지 않은 작업을 하다 보니 시간이 더 걸릴수도 있겠다는 점을 인지할 수 있습니다. 이를 통해 미리 이슈 가능성에 대해 공유하고, 하염없이 기다리기만 하는 상황을 방지할 수 있어요. 이렇게 커뮤니케이션 방법을 개선한다면 프로젝트를 진행하면서 불필요한 자원을 소모하는 경우가 줄어들게 되고, 원활하게 작업을 이어갈 수 있을 거예요.

세션4: 주니어 개발자의, 200일간 혼자만의 짧은 글쓰기 챌린지로 성장하기

• 글쓰기가 개발자 성장에 도움되는 이유
• 글을 쓰기 시작한 계기
• 실패기
• 짧은 글쓰기 챌린지 시작
• 성공할 수 있었던 이유
• 마치며

마지막 세션은 병스커의 ‘주니어 개발자의, 200일간 혼자만의 짧은 글쓰기 챌린지로 성장하기’였습니다. 에듀테크, 블록체인 도메인에서 FE 개발자로 근무하고 있는 그는 프로덕트 디자이너로 첫 커리어를 시작했고, 이후 개발자로 전환했어요. 정보를 얻고자 알게된 아티클 문화로부터 디자이너들도 글을 써서 공유한다는 것을 알게 되었고, 개발자로 전향하며 그들이 글을 공유하는 문화는 훨씬 더 거대했다는 것을 깨닫게 되었습니다. 직업을 갖기 전에도 어떤 소재이든 글을 쓰는 사람이 되고 싶었던 그는 이후 기슬 블로그를 직접 생산하는 사람이 되는 것을 목표로 정했어요. 이를 통해 기술적 성장을 이룰 수 있기 때문이었습니다.

물론 첫걸음부터 성공한 것은 아니었습니다. 가장 어려웠던 것은 꾸준하게 글을 작성하기였는데, 글쓰기를 위한 소재가 없고, 시간내기가 어렵다는 나름의 변명이 있었습니다. 이를 해결할 수 있는 방법으로, 병스커는 ‘30일간의 매일 짧은 글쓰기 챌린지’를 시작했어요. 그리고 글쓰기에 대한 부담감을 덜기 위해서 글의 주제를 조금 더 자유롭게 작성했습니다. 소제에 제한을 두지 않고, 그날 겪은 에피소드나 풀리지 않는 고민등을 짧게 작성해 나갔습니다. 또한 꾸준하게 글을 쓰기 위해서, 스마트폰을 통해 언제 어디서든 글을 써내려갈 수 있는 환경을 만들었어요. 그렇게 짧은 글쓰기 챌린지는 이제 어느덧 300일을 바라보고 있게 됐습니다.

병스커의 세션은 저에게 자기반성의 시간이기도 했습니다. ‘꾸준한 회고를 통해 성장한다’는 모토로 기술 블로그를 운영하는 저였지만, 정작 꾸준하게 글을 작성하지 않고 있었어요. 그리고 과거의 병스커처럼, 저 역시도 소재가 부족하다거나 시간내기가 어렵다 등의 핑계를 대면서 글쓰기를 이어가지 못했습니다. 막상 글을 써야겠다는 생각이 들었을 때에도, ‘기술 블로그인데, 그래도 좀 퀄리티 있는 글을 적어야 하지 않을까? 어떤 주제를 잡아야 하지?’등의 고민을 하며 초안조차도 쉽게 작성하지 못하고 다시 뒤로가기를 누르는 저를 볼 수 있었습니다. 그러다보니 글쓰기 습관이 잡히지 않았고, 회고 스터디를 진행하면서도 스터디 전날 부랴부랴 글을 짜내곤 했어요. 이제는 저도 병스커처럼, 짧은 글이라도 노션이나 SNS에 남기는 것을 시작으로 글쓰기 습관을 꾸준히 다져야겠다는 생각이 들었습니다.

테오의 Q&A

모든 세션이 끝나고 난 뒤, 테오의 Q&A가 진행됐습니다. Q&A 세션에서는 테오콘 신청 당시 받았던 사전 질문을 살펴보며 이에 대한 답변을 해 주는 시간이었어요. 정말 다양한 질문이 있었지만, 질문의 주된 골자는 다음과 같이 요약할 수 있을 것 같습니다.

"어떻게 해야 개발자로서 성장할 수 있을까요? ‘잘 하는’ 개발자가 되려면 어떻게 해야 할까요?"

아마 글을 읽고 계신 여러분도 마음 한켠에 품어두고 있는 질문이라고 생각합니다. 몇년 사이 AI가 급부상하고, 어려워지는 상황 속에서 개발자가 어떤 역할을 해야 하는지에 대해서 많은 이야기들이 오갔습니다. 그래서 다들 불안함을 느끼기도 하는 것 같고요. 지금부터 써내려가는 이야기는 세션을 들으며 테오의 의견을 요약한 것입니다.

테오는 앞선 질문에 대한 해답을 주기 전에 질문을 하나 던졌습니다.

"우리는 왜 불안함을 느낄까요?"

불안함이라는 감정은 현재에 안주하고 싶지 않고, 성장하고 싶다고 생각할 때 느껴지는 감정입니다. 이러한 불안함을 떨쳐내는 방법은 신뢰와 자기확신을 기반으로 앞으로 나아가야 하고요. 그러나 믿음에는 근거가 있어야 합니다. 그리고 테오는 그러한 근거는 성장, 기여, 기록의 세 가지 방법으로부터 빚어질 수 있다고 말했습니다.

첫 번째로, 성장하기 위해서는 내가 회사에서 무엇을 하고 있는지, 그리고 무엇이 중요한지를 돌아봐야 합니다. 일을 잘 한다는 것은 곧 자신의 쓸모를 회사에 증명하는 과정입니다. 입사 초기 주니어 개발자의 경우 개발의 기초 체력을 키워야 합니다. 흔히들 하는 공식 문서 톺아보기처럼 심화 개념에 대해 공부하며 개발자로서 기반을 다지는 과정이 여기에 속합니다. 이후에는 성과를 낼 수 있고, 누군가를 도울 수 있는 방향으로 학습을 진행해야 합니다. 덧붙여서, 무엇이 중요한지 모른 채 열심히만 하는 것은 올바른 성장의 방향이 아닙니다. 또한 회사의 업무가 너무 단조로워서 내가 정체되어 성장할 수 없을 것 같아 두렵다는 생각이 들 때에는, 스스로 필요를 만들어 학습하는 것을 권장합니다. 이 역시 성장의 일종이며, 우리의 뇌는 필요한 것을 학습할 때 활성화되기 때문입니다.

두 번째로, 기여를 한다는 것은 남의 일을 돕는다는 뜻이기도 합니다. 이때 오해하지 말아야 할 것은, 이는 남의 일을 빼앗거나 단순히 대신 해주기만 하는 호구가 되는 방향이 아니라는 점입니다. 물론 이러한 이야기가 오갔을때 흔히 사람들은 이렇게 이야기하곤 합니다.

"하지만 내 일도 벅차지 않나요?"

그럼에도 불구하고 그걸 어떻게 해낼 수 있을지 고민하고 해결하는 것이 주니어 이후 개발 실력을 향상시킬 수 있는 방법입니다. 테오는 주니어부터 시니어 개발자까지의 단계를 이렇게 정의합니다.

• 도움이 필요한 사람(주니어)
• 누구의 도움이 없이도 문제를 해결할 수 있는 사람
• 주어진 업무 외에도 무언가를 더 해낼 수 있는 사람
• 다른 사람들을 도울 수 있는 사람(시니어)

이렇게 성장하기 위해서는, 내가 도움을 줄 수 있는/받을 수 있는 사람의 범위를 한 명씩 늘려가 보는 것이 중요합니다.

마지막으로, 성장하고 기여하기 위해서는 기록의 힘을 무시할 수 없습니다. 나의 성과를 보여줄 수 있는 부분을 조금씩 기록해 나아가, 이렇게 쌓인 기록은 곧 성장의 증거가 되기 때문입니다.

나오면서: 성장하는 개발자를 꿈꾼다는 것

이렇게 저의 두 번째 컨퍼런스 경험은 끝났습니다. 기대했던 것 보다 더 많은 것들을 얻어갈 수 있었던 시간이었어요. 기회가 된다면 다음 번에도 다시 참여하고 싶습니다. 그럼 테오콘은 저에게 어떤 도움이 됐을까요? 개발자로서의 제 모토는 코드 그 너머의 변화를 추구하는 개발자입니다. 조금 더 풀어서 설명하자면 이렇습니다. 매일 수많은 사람들이 사용하는 웹 서비스에서, 일상적인 경험을 더 나은 방향으로 변화시키는 프론트엔드 개발자가 되는 것입니다.

그러나 이런 모토를 가지고 있음에도 불구하고, 구체적으로 어떤 방법을 통해 제가 꿈꾸는 개발자가 될 수 있는지는 아직까지 물음표였습니다. 학습의 방향을 올바르게 설정하지 못하고, 무엇이 중요한지 모른 채 열심히만 하는 상태였어요. 얼마 전 교육 프로그램에 지원하면서 자소서와 포트폴리오를 만들기도 했는데, 만들다 보니 제가 설정한 모토에 대한 근거가 부족하다는 것을 깨닫기도 했습니다. 불안함을 느끼고 성장하려고 했지만, 성장의 방향이 잘못 설정되어 있었습니다.

하지만 테오콘 이후로 학습의 방향성을 잡을 수 있게 됐습니다. 테오가 이야기했던 ‘성장, 기여, 기록’이라는 측면에서 살펴볼까요?

성장

• 개발 기초 체력을 다지되, 단순 기술 습득을 넘어 나의 모토(사용자 경험 개선)에 초점 맞추기
• 하이안처럼 번아웃 상황에서도 새로운 도전을 통해 성장 기회를 만들기
• 앤드류의 사례처럼 코드 품질과 개발 생산성을 높이는 도구들을 학습하고 실제로 적용해보기
• 동훈이 제시한 것처럼 기술적 스킬 뿐만 아니라 커뮤니케이션 능력도 함께 발전시키기

기여

• 사용자 경험을 개선할 수 있는 프로젝트에 참여하거나 기존 프로젝트 리팩토링하기
• 다른 개발자들과 지식을 공유하고 서로 성장할 수 있는 네트워크 형성하기
• 오픈소스 프로젝트에 참여해 기여해보기

기록

• 병스커의 사례처럼 꾸준한 글쓰기 습관 만들기
• 핑계대지 않고, 짧은 글이라도 매일 작성하는 습관 들이기
• 성장 과정과 기여 활동을 기록해 나의 성장 증거로 삼기

이러한 방향성을 가지고 꾸준히 실천한다면, 모토가 모토로만 남지 않고 실현될 수 있겠죠?

사족이지만, 예전에 제가 개발자로서 가지고 있는 모토는 ‘완벽한 개발자’였습니다. 무엇이든 마스터하려고 했었어요. 예를 들면, JS 마스터 같은 것들 말입니다. 그리고 라이브러리와 프레임워크를 자유자제로 다루고, 어떤 알고리즘 문제를 봐도 척척 풀어내며 신들린 성능 최적화와 함께 접근성까지 고려하는 정말 궁극의 개발자가 되고 싶었습니다. 물론 지금 생각해보면 거의 공상에 가까운 비현실적인 모토였지만요. 이제는 명확한 방향성을 가지고 앞으로 나아갈 때입니다. 마지막으로 완벽에 대해 고민하던, 동시에 올바른 노력을 하지 않았던 저에게 그것이 얼마나 부질없는 고민이었는지를 깨닫게 해 줬던 문장을 하나 인용하면서 글을 마무리할게요. 성장하고자 하는 여러분, 모두 화이팅입니다!

"완벽은 없음. 완벽이라는 목표는 계속 변함. 멈추지 않음. 따라갈 수 있지만, 붙잡을 수 없음."