brunch

You can make anything
by writing

C.S.Lewis

by neverlish Dec 06. 2018

지그재그에서의 2년 - 3. 신입에서 3년차로

3년차 직장인 개발자의 과거 현재 미래

2년 전 오늘, 나는 개발자로서 첫 회사에 첫 출근을 했다.  20대 내내 경영학을 공부하다가, '프로그래밍'이라는 정말 하고 싶은 분야를 찾아 얻어낸 첫 성과여서, 나에게는 생일만큼이나 의미깊은 날이다.


노력해서 성장하고 계속해서 더 잘해야 재미를 계속 느낄 거라 생각하며 보낸 지난 2년은 내 인생에서 가장 열심히 보낸 시기였고, 내 선택과 노력이 어떤 형태로든 나에게는 돌아올 거라 믿으며 살아왔다. 그리고, 어느새 2년이 지났다. 너무 빨리 흘러가는 시간 속에서, 초심을 다시 떠올리고 그동안의 하루하루를 의미있는 날들로 기록을 남겨두고 싶어 글을 적는다. 3편의 글을 통해 생각을 정리하려 한다.


1. 재밌는 일을 하고 싶다!

2. 내가 바란 회사는

3. 지그재그에서의 배운 것과 느낀 것

4. 2년간의 개인적인 노력과 성취

5. 앞으로 어떤 사람/개발자가 되고 싶은가


이 글을 통해 지난 2년간의 삶을 되돌아보고 생각을 정리하여 앞으로의 내 삶을 그리는 데 실마리가 되기를 바란다.





이 시리즈의 2편 2. 내가 바란 회사는 에서 언급했듯이, 내가 바란 회사의 요건은 아래와 같았다.

수평적인 커뮤니케이션을 하는 곳, 배울 수 있는 곳, 사람 스트레스 없는 곳, 일에만 몰두 할 수 있는 곳. 


내가 2년간 다니면서 느낀 크로키닷컴(운영중인 서비스명은 지그재그이지만, 회사명은 크로키닷컴)은 위의 모습을 어느정도씩은 갖추고 있다고 느낀다. (각각의 다른 생각을 하고 각각의 니즈를 품고 있는 다른 사람들이 모여서 일하는 조직이 회사이기 때문에, 각 구성원들이 완전히 만족하는 회사는 없을 것이라 생각한다.) 돌아보면, 비전공개발자인 내가 신입으로 이 회사에서 커리어를 시작한 것은 큰 축복이었다.


이 글에서는 회사에서 좋았던 점과 내가 일을 하면서 어렵게 느꼈던 점을 이야기하고 싶다.



크로키닷컴의 좋은 점


1. 실사용자가 많은 서비스

입사 후 처음 맡은 일이, 사내 대시보드 중 DAU, MAU 그래프 관련 일이었다. 그때 접한 우상향 그래프를 보고 감탄했던 기억이 난다. 4년간 경영학을 배우며, 한번도 꺾이지 않고 지속적으로 성장하는 그래프를 본 적이 없었다. 입사 후 2년, 지금은 10-20대 여성이라면 누구나 아는 서비스가 되었다. 

돈도 잘벌고 있고(스타트업에서 비즈니스모델은 생각보다 중요하다. 월급 밀리는 스타트업이 생각보다 많다. 생존을 위한 최소 조건은 역시 $₩.), 데이터도 정말 많다.

제품을 잘 만들어도 사람들이 몰라 사용하지 않는 경우도 많은데, 우리 서비스는 실사용자가 많다. 사용자가 많다는 것은, '할 수 있는 것'이 더 많다는 뜻이다. 특히 우리 서비스와 같은 플랫폼(중개서비스)의 경우에는 사용자 규모는 더 중요하다. 우리의 할 일은 제품을 잘 만들고, 사용자들이 그 제품과 기능을 매끄럽게 잘 사용할 수 있도록 유도하는 것이다. 

기본적으로 스타트업은 일이 많다. 전에 없던 것을 새로 만들어내는 창조의 과정은, 기존의 무언가를 수정하는 것보다 몇배의 노력이 필요하다. 사람들의 니즈를 파악하고, 그들이 가장 잘 사용할 수 있는 방향으로 기획 + 디자인하고, 개발하는 과정을 끊임없이 반복한다. 여러 태스크를 병렬로 진행하고, 그 주기도 길지 않다. 그래서 일이 많다. 

일이 많으면, 마주할 수 있는 문제상황도 많고 다양해진다. 문제를 마주하고 내 나름의 생각을 해야 하고, 그러면서 조금씩 성장한다. 사용자가 많은 스타트업은 더 일이 많고, 해결해야 할 문제도 더 많다. 그만큼 내가 성장할 수 있는 여지가 더 많다.


2. 다양한 분야의 폭넓은 경험

2년간 접한 도메인과 기술 스택은 아래와 같다.

domain
- commerce
- payment(+ subscription)
- advertisement + personalization
- notifications(push, sms, etc..)
- maintenance
technical ability
- infra: aws(lambda, sqs, dynamodb)/ jenkins 
- backend: expressjs / graphql / microservice / redis / crawling / unit test
- frontend: SPA / reactive / mvvm / typescript / storybook / reactive / graphql / chart
- web : typescript / graphql / functional programming


국내 IT업계에서 일하는 웹개발자의 경우 사내에서 프론트엔드나 백엔드, 둘 중 한 분야만 전문적으로 맡아서 하는 경우가 많다. 하지만 2년간 나는 회사내에서 여러 도메인에 걸쳐, 사용자가 직접 접하는 화면단부터 연산을 하는 서버와 전체 구조를 구성하는 인프라까지, 처음부터 끝까지 만져볼 수 있는 경험을 가질 수 있었다. 


2년간의 full-stack 경험은 개발자로서 앞으로의 커리어를 구상하는 데 큰 경험이 될 것이라 믿는다. 내가 그 분야에 재미를 느낄지, 전문성을 키울 수 있을지 판단을 내릴 때, 해당 분야에 대한 사전 경험이 있으면 더 정확한 판단을 내릴 수 있을 테니까. 


3. 많이 배우고 빠르게 성장할 수 있는 문화

다양한 기술로 다양한 분야를 다룬다고 해서 실력이 반드시 성장하는 건 아니다. 개발자가 신입으로 가면 안되는 회사로 흔히들 꼽는 요건은, '사수가 없는 회사'이다. 우리 회사는 시니어개발자가 많은 회사이다.


내가 입사했을 때는 개발팀이 4명이었는데, 신입개발자(본인)을 제외하고는 모두 10년차 이상이었다. 2년이 지난 지금은 개발팀이 15명인데, 절반 이상이 10년차 이상의 개발자들이다. 그들의 코드를 많이 보며 배운다. 내가 가는 방향이 맞는지, 내가 제시한 문제해결방식이 추후에 또다른 문제를 일으키지는 않을지, 궁금할 때마다 물어볼 수 있다. 

배우고 성장하는 방향을 잡아줄 수 있는 시니어개발자의 존재는 주니어개발자의 초기 성장에 있어 필수적이다. 


혹시 이 글을 읽는 분 중에 지그재그 채용에 관심 있는 분이 있다면, 아래 연락처로 연락 주시면 감사하겠습니다. 같이 재밌게 개발해봐요. :)
neverlish@gmail.com(제 연락처) / job@zigzag.kr



회사에서 내가 부족하다 느낀 점


1. 커뮤니케이션

모든 직장인, 아니 모든 사람들이라면 사회를 살아가면서 커뮤니케이션을 어려워할 것이다. 정해진 대로만 답을 주는 컴퓨터와 대화하다가, 때로는 불확실하게 말하는 것처럼 느껴지는 사람과 대화할 때면 커뮤니케이션이 더 어렵게 느껴진다. 

내가 할 말을 상대방이 잘 이해할 수 있도록 그들이 이해할 수 있는 언어로 이야기해야 한다. 내가 알고 있는 나의 경험과 기존의 세계를 토대로 상대방의 언어를 이해해야 한다. 코드는 작성하고 나면 잘 작동하는지, 아니면 에러가 나는지 확인이 가능하다. 커뮤니케이션은 내가 잘한지 못한지 티가 나지도 않고 확인도 어렵다. 좋지 못한 커뮤니케이션의 효과는 언젠가 뒤에 스노우볼되서 나타난다. 참 어렵다. 앞으로도 어려울 거 같다.


2. 네이밍

내가 지금 작성한 코드는 언젠가 누군가가 수정해야 한다. 그 누군가는 6개월 후의 내가 될 수도 있고, 내일의 옆자리 개발자가 될 수도 있다. 그래서 나는 그 누군가가 이해할 수 있는 방식으로 코드를 작성해야 한다. 컴퓨터가 이해하는 코드보다 사람이 이해할 수 있는 코드를 작성하는 것이 더 어렵다는 말은 항상 실감이 된다. 그래서 내가 작성하는 코드의 단어 하나하나에 신중을 기울여서, 미래의 누군가가 이해할 수 있는 코드를 짜려고 하는데.... 코드 리뷰를 받을때면 네이밍 관련 이슈가 나올때가 많다. 아직은 더 많은 경험을 해야, 각 상황에 적합한 네이밍을 더 잘할 수 있지 않을까 싶다.


3. 일정 산정
지금 작업중인 협업 프로젝트는, 계획 초기에는 1개월이면 되겠지, 라고 생각했었다. 그런데 점점 진행하면서 일정을 뒤로 미루게 만드는 여러 요소가 생긴다. 예상하지 못한 기술적 난관, 추가적인 요구사항, 커뮤니케이션 착오로 생긴 문제 등등.... 그래서 지금 프로젝트는 아마 2개월 쯤 걸리지 않을까 생각한다.

함께 일하는 조직이기 때문에, 내 일이 얼마나 걸릴지 정확하게 알려주는 중요하다. 일정산정을 바탕으로 다른 분들의 계획을 조정하고, 추후 다른 일정에도 영향을 미칠 수 있기 때문이다. 그런데 내가 하는 이 일이 얼마나 걸릴지 추산하는 것이 어렵다. 입사 후 2년이 지났어도 아직도 어렵게 느껴진다. 시니어 개발자분들은 일정 산정을 어렵게 느끼지 않을까 궁금하다. :(

작가의 이전글 혼자 떠난 2박3일 오사카
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari