프론트엔드 코리아 2024 후기 : 성공한 개발자들의 비책..?

고민을 해소해 주신대요

성공한 개발자들의 비책이라니?!

 

지금 다니는 회사(이벤터스)에서 행사 큐레이션을 담당하고 계신 마케터 이OO님이 어느날 저에게 행사 하나를 던져 주시며 이렇게 말씀하셨습니다.

성공한 개발자 되자~~!!

 

어떻게 하면 성공한 개발자가 될 수 있는 걸까요?

그 전에, 어떤 개발자를 성공한 개발자라고 정의내릴 수 있을까요?

여러 궁금증을 가지고 참여해본 행사, 프론트엔드 코리아 2024 (Frontend Korea 2024) 후기입니다.

https://event-us.kr/frontendkorea/event/87668

프론트엔드 코리아 2024 (Frontend Korea 2024) - 이벤터스

 

 

 

시작에 앞서: 성공한 개발자 정의하기

우리는 어떤 사람을 성공한 개발자라고 말할까요?

개발을 잘 하는 사람,

연봉을 많이 받는 사람,

좋은 회사에서 일하는 사람,

사람들이 많이 쓰는 제품을 만들어 낸 사람...

 

사람들마다 생각이 다르겠지만, 우리 사회에서는 보통 연봉을 많이 받는 개발자를 성공한 개발자라고 말하는 것 같습니다.

적어도 자본주의 시장에서는 상품에 가치를 매길 때 객관적이면서 수학적으로 명확한 지표인 돈을 사용하니까요.

개발자도 노동 가치를 제공하는 상품이라는 관점에서 생각해 보면 어느 정도 맞는 말 같습니다.

 

이 행사의 연사로 나온 분들이 재직하시는 회사를 살펴보면 29CM, 컬리, 토스, 카카오로 모두 업계에서 연봉을 많이 준다고 알려진 회사들입니다. 그리고 이런 회사들은 높은 연봉을 지출할 수 있는 높은 매출(또는 높은 금액의 투자)을 가지고 있습니다. 높은 매출이 발생하려면 제품을 구매하는 사용자들도 많아야 할 것이고, 그 수많은 사용자들을 만족시키는 퀄리티의 제품을 만들어내기 위해서는 당연히 개발도 잘 해야겠죠. 결국 앞서 언급했던 성공한 개발자의 조건들은 모두 연봉과 크고 작은 상관관계가 있다고 말할 수 있겠습니다.

 

성공한 개발자 == 가치있는 개발자 == 높은 연봉을 받는 개발자 라는 명제가 맞다고 가정했을 때, 발표 내용은 전반적으로 의미있었던 것 같습니다. 연봉으로써 높은 가치를 인정받기 위해 필요한 개발자의 능력을 소개하는 좋은 내용이었어요.

 

본격적으로 발표 내용들을 소개하기 전에 개발자의 가치를 높이 인정받으려면 어떻게 해야 하는가에 대한 비유 하나를 먼저 소개해드리려 합니다. 이 행사의 마지막 연사로 나오신 바닐라코딩의 대표 Ken 님이 개발자의 가치를 음식점에 비유한 내용인데, 저는 이게 참 와닿았습니다.

적당한 가격에, 적당한 퀄리티의 음식이 나오는 식당이 있다면,
여러분은 다음에 다시 그 식당을 방문하실 건가요?
뭐... 시간이 되면, 가끔 가겠죠.
다른 음식점이 너무 붐비거나 하면 한 번씩 가겠죠.
그런데, 진짜 맛있고 진짜 싸고 진짜 퀄리티 좋은,
가성비 미친 식당이 있다면 여러분은 그 식당에 매일 갈 수도 있겠죠.
그래서 여러분들은 그런 가치를 사업주에게 제공해야 해요.
적당한 가치가 아니라,
미친듯한 가치를 제공해야 한다구요.

 

 

 

발표 세션: 기술적인 내용이 아니었던 이야기들

행사의 타임 테이블

 

처음 이 행사를 봤을 때, 막연히 개발자들을 위한 행사니까 당연히 기술적인 내용이 있을 거라고 생각했습니다.

하지만 이 행사의 발표 내용에는 기술적인 내용이 거의 없었어요.

대부분 커뮤니케이션, 협업, 자기계발 방법에 관한 내용들이었습니다.

 

저도 스스로 다시 생각해보니, 회사에서 일할 때 보통 기술적인 것은 큰 문제가 아니었습니다. 기술은 익히면 다 쓸 수 있거든요. 중요한 건 비즈니스적 가치, 즉 직면한 문제를 해결해서 가치를 창출해낼 수 있는가에 대한 문제입니다. 그래서 저는 일하는 분야에 대한 도메인 지식이 중요하다고 생각하는데, 이 얘기는 아래 Opinion 문단에서 다시 다루겠습니다.

 

29CM 프론트엔드 개발자 한지원 님은 강점 혁명이라는 키워드로 발표해 주셨습니다.

강점 테스트라는 것이 있는데, 직장인 버전 MBTI 테스트 같은 느낌으로 각자가 가진 다섯 가지의 강점을 보여준다고 합니다. 29CM에서는 (비공식적으로) 이 강점 테스트 결과에 따라, 업무 분장을 할 때 각자가 가진 강점을 살릴 수 있는 역할이 주어진다고 해요.

 

사람이 약점을 살리기 위해 노력하는 것 보다는 강점을 살리는 쪽으로 노력하는 것이 더 시간 효율적으로 성장할 수 있다는 내용이었습니다.

 

https://brunch.co.kr/@swchoi06/51

컬리의 프론트엔드 개발자 김세림 님은 1:N으로 백엔드 개발팀과 협업했던 경험을 말해 주셨습니다. 컬리에서는 프로젝트가 주어졌을 때 기능 조직이 꾸려진다고 합니다. 기능 조직은 어떤 기능을 만들어내기 위해 각 직무에서 담당자들이 모여 팀을 이루는 조직입니다.

 

그런데 세림님이 이번에 맡으신 프로젝트에서 네 팀의 백엔드 개발팀과 혼자 협업하는 형태로 기능 조직이 꾸려졌다고 합니다. 그러다보니 많은 문제가 생겼는데 이를 해결하는 과정이 너무 힘들었고, 발표 내용은 이를 회고하며 어떻게 하면 다음에는 더 나아질 수 있을까에 대한 내용이 주를 이뤘습니다.

 

문제 내용 몇 가지를 소개드리면...

- 백엔드와 API로 소통하는데 개발자들마다 인터페이스가 다 달랐다. 예를 들면 같은 시작일 종료일을 두고 누구는 fromDate, toDate를 쓰고, 누구는 startDate, endDate를 쓴다.

- 같은 박스를 두고 누구는 Box, 누구는 Package라고 칭한다. 심지어 다른 팀에서 Package라는 네이밍을 전혀 다른 목적으로 사용하는 경우도 발생했다.

- 이런 내용이 정리도 되어 있지 않아서 문서를 요청했으나 문서마저도 서로 다른 양식으로 왔다.

- 소통할 때 답변도 늦게 와서 개발 일정이 자꾸 밀렸다.

 

그리고 이 문제를 바탕으로 셀프 평가 후 이런 액션 아이템을 정의하셨어요.

• 받고 싶은 문서의 예시를 함께 공유하기
  • 그들도 내가 원하는 게 뭔지 모른다. 원하는 걸 구체적으로 제시하자
• 그들의 팀 문서에 기록이 남을 수 있는 문서로 요청하기
  • 퇴사와 같은 부재시에 대비하기 위한 히스토리 남기기
• 디엠보다는 채널, 채널보다는 문서
  • 휘발성이 낮고 공유성이 높은 쪽을 선택하자
• 통일이 필요한 부분에 대해서는 적극적으로 요청하기
  • 코드의 명칭은 도메인과도 연결되는 부분. 혼란을 최소화 해야 한다
• Due Date를 요구하자
  • 프로젝트에 Due Date가 있다면 이를 근거로 당당하게 Due Date를 요청하자
• 관점의 오차범위 최소화 하기
  • 기획을 바라보는 관점이 다를 수밖에 없으니 서로 오차를 줄이는 시간을 최대한 확보하자

 

저는 문서를 요청할 때 그 예시를 함께 공유하라는 내용이 가장 와닿았습니다. 실제로 직장 동료들로부터 DB 데이터를 뽑아달라는 요청을 받는 경우가 종종 있는데, 양식 없이 요청하시는 경우에는 제가 임의로 정리해서 드리고는 합니다. 그런데 그렇게 뽑아드린 데이터는 원하는 데이터가 아니었던 경우도 있습니다. 반면 예시 양식을 주시면서 데이터 요청을 하시면 확실히 어떤 데이터를 원하시는 건지 파악이 쉬웠던 경험이 있네요.

 

토스플레이스의 프론트엔드 개발자 도현솔 님은 "React, 그 너머의 FE 개발자" 라는 주제로 발표해 주셨는데요, React라는 표현은 기술적인 요소들을 상징적으로 나타내는 비유였습니다. 기술적인 것을 넘어서 FE 개발자가 계발해야 하는 다른 요소들, 예를 들면 커뮤니케이션 방식 같은 내용을 다뤄 주셨습니다.

 

프로덕트 이름이 자꾸 바뀌는 바람에 개발 전반에 악영향을 미치고 있었는데, 이를 회사 전체 채널에 성토하는 글을 올리셨다는 경험이 기억에 남네요. 회사의 다른 많은 사람들도 이를 문제라고 인식하고 있었지만, 누가 나서서 말하지는 않는 상황이었다고 합니다. 현솔님이 용기있게 이를 알리고 공론화해서 결국 회사 전체의 생산성을 향상시키는 데 도움이 되었죠.

 

또 현솔님은 매일 아침 출근 시간을 이용해서 기술 칼럼을 읽고 좋은 내용을 공유하신다고 합니다. 이는 작은 행동일 수 있지만 많은 사람들에게 좋은 영향을 미칠 수 있고, 나아가 회사 전체의 이익을 높일 수 있습니다. 이렇듯 전반적으로 FE 개발자로서 가치를 끌어올리기 위해 할 수 있는 기술 외적인 부분들을 다루는 내용이었습니다.

 

카카오의 프론트엔드 개발자 이동건 님은 "회사는 학교가 아니다" 라는 다소 자극적인 제목을 들고 오셨지만, 실제 발표 내용은 회사에서도 학교에서처럼 성장할 수 있는 다양한 방법에 관한 것이었습니다. 본인의 취업 준비 경험, 카카오 인턴 경험, 카카오 재직 경험에서 실패와 극복, 성장에 포커스를 맞춰 발표해 주셨습니다.

 

Ken Huh 님이 발표해주신 "개발자의 가치를 올리는 방법"도 재미있었습니다. Ken 님은 30살에 연봉 1억을 받는 개발자가 되는 것이 목표였습니다. 연봉 1억이 필요했던 이유는 그 돈으로 뭔가를 사기 위해서가 아니었습니다. 개발자의 가치를 매길 수 있는 지표가 연봉이었기 때문이었습니다. 본인의 가치를 끊임없이 확인하고 싶으셨다고 해요.

 

앞서 소개해 드린 음식점 비유처럼, 개발자의 가치를 인정받으려면 적당히 잘해서는 안된다는 말씀이 인상 깊었습니다. 항상 극한의 가치를 사업주에게 제공하는 개발자가 되어야 한다고 하셨는데, 이는 비단 개발 직무가 아니더라도 적용할 수 있는 내용이라고 생각합니다. 저도 저의 가치를 높이기 위해 주어진 일보다 더 많은 일을 하려 노력하는데, 잘 하고 있다는 것을 확인받은 것 같아서 위로가 되는 내용이었습니다.

 

 

 

Opinion: 성공한 사람들의 특징

언제나 느끼는 거지만, 성공하는 사람들의 공통된 특징은 실패했을 때 좌절만 하지 않고 실패의 원인을 분석해서 더 나아지고자 노력한다는 것입니다. 실패하고 아무것도 하지 않는다면 성장할 수 없습니다. 실패가 가진 가치는, 다음에는 같은 실패를 되풀이 하지 않기 위한 플랜을 만들 수 있게 해준다는 것에 있습니다.

 

이번 행사의 주제가 개발자의 가치를 올리는 방법, 성공한 개발자가 되는 비책이었는데 그 내용들을 보면 실패를 극복하고 성장하는 내용들이 대부분이었습니다. 실패를 대하는 자세가 참 중요하다는 것을 다시 한 번 깨닫게 되었습니다.

 

그리고 개발 외적인 부분들이 확실히 중요하다는 것을 느꼈습니다. 평소 업무를 할 때 느꼈던 부분과 비슷했습니다. 개발만 잘 해서는 높은 매출을 발생시키기 어렵습니다. 비즈니스를 정확히 이해하고, 이해 관계자들과 적절한 소통을 해서 만들어진 제품이 더 높은 매출을 발생시킬 가능성이 높겠죠.

 

그래서 저는 개발자가 제품의 분야에 대한 도메인 지식을 갖추는 것이 중요하다고 생각합니다. 문제를 해결하는 방법을 기획자가 기가 막히게 짜서 준다고 하더라도, 그 문제에 대한 배경 지식 없이 좋은 개발 결과물을 내기는 어렵습니다. 같은 페이지를 만든다고 하더라도, 목적이 뭔지, 왜 이렇게 기획이 나왔는지에 대한 배경 지식이 있다면 로직을 구현할 때 더 명확하고 효율적인 코드가 나옵니다. 그리고 이런 이해도가 높다면 어떤 부분이 변하고 어떤 부분이 변하지 않는지도 예상할 수 있게 되기 때문에 추후 변경에도 더 유연한 코드를 짤 수 있게 됩니다.

 

또 커뮤니케이션을 하는 태도도 참 중요하다는 것을 느꼈습니다. 실제로 저는 최근까지 회의에 들어가면 다소 날이 선 말투를 사용하고는 했습니다. 일부러 그런 것은 아니고, 실시간으로 많은 생각을 하다 보니까 말투까지는 미처 신경쓰지 못한 것이죠. 하지만 동료 분들은 이런 저의 말투 때문에 제가 부정적인 생각을 가지고 있다고 느끼셨고, 해결할 수 있는 문제인데도 해결하지 못한다고 생각하시는 상황까지 발생했습니다. 그 이후로는 회의에서 말투와 태도에 주의를 기울이고 있는데, 예전보다 긍정적인 분위기로 회의가 진행되고 문제가 해결되는 것을 느끼고 신기했던 경험이 있습니다. 이번 행사에서도 비슷한 내용들, 커뮤니케이션을 하는 태도와 관련된 내용이 다뤄지는 것을 보고, 실제로 중요한 내용이라는 사실을 다시 한 번 느꼈습니다.

 

전체적으로 저를 돌아볼 수 있게 만드는 좋은 내용의 행사였습니다. 하나 아쉬웠던 것은 개발자 네트워킹을 통해 사이드 프로젝트 할 팀원을 구하거나 하고 싶었는데, 명함은 몇 장 돌렸지만 그분들과 네트워킹에 성공한 것 같지는 않습니다. 🥲 역시 이런 행사 자리에서 짧은 시간 안에 사람을 사귀는 일은 참 어려운 것 같아요.