5년간 회고기록(with 이직, 도입기, 역량강화)

 

눈 깜빡하니 5년 차개발자가 되었다.

 

이 회고는 기술적인 내용은 다루진 않고 나의 첫 회고이자 1~약 6년 차가 되어가는 나를 회고해 본다.

 

첫 회사

첫 회사에 속한 조직에선 정말 많은 개발자분이 계셨다. (물론 지금도 그 회사엔 예전 동료들이 많이 있다)

 

입사 시 물류 개발을 위한 신규 팀이 개설되어 같은 팀원분들의 경력이 꽤 되시는 분들이 많이 있었다. 네 명의 선배 개발자분들과 네 명의 신입 개발자로 채워졌었다. 뭘 하든지 다 새로운 것들이라 팀원들끼리 새벽 4시까지 개발하고 첫 실서비스 운영을 하는 것에 개발자로서 첫 발걸음이 설레던 때였다.

 

당시에 도대체 5년 차 이상 개발자들은 어느 정도 내공을 가지고, 있어야 하는 것인가 하며 동기들과 많은 이야기를 했던 것 같다. 이런 이야기를 선배 개발자분들에게도 몇 번 이야기한 적이 있었는데 허허허 웃기만 하시고 ‘그렇지 않아요…’ 라고 말씀하시던 분의 웃음을 이제는 알 것 같기도 하다.

 

지금 5년 차를 넘어가고 6년 차를 앞둔 상황에서 지금 내 연차가 지금 수준에 적합한 수준인가를 매일 되새기고 있다. 결론적으론 ‘한참 부족한 상태’라고 느껴진다.

 

3년 차가 되었을 때 어느 정도 프로세스를 파악하고 기획서가 오면 어떤 식으로 설계하고 시작해야 할지 프론트와 백 단은 어떤 식으로 구성할지, DB 설계는 어떻게 할지 빠르게 생각해서 개발을 진행했었다. 일하는 게 어렵지 않다고 느껴졌고, ‘이미 있는 걸 가져다가 쓰면 금방금방 개발되네’가 되어버린 것이다.

 

당시 어떤 부장님이 한 말이 있었다. ‘이젠 how to가 아니라 where to를 잘해야 한다.’는 말이 굉장히 인상 깊었고 그 말뜻을 잘못 이해하여 나의 능력이 많이 정체되었다고 생각된다. 당시에는 내가 직접 만드는 것보다 남들이 만들어 놓은 코드를 쓰는 게 더 효율적이라고 착각하며 다른 사람들 코드를 ‘복붙’하여 기능 갖다 붙이기에 급급했다. 말 그대로 돌아만 가는 코드를 작성하는 ‘코더’가 되어버렸다. 이렇다 보니 난 프론트도하고 백도 하는 풀 스택 개발자이고 혼자서 서비스하나 다 만들 수 있는 능력이 되는 사람이라는 오만한 생각을 가지게 된 것이다.

 

자기객관화

진리의 ‘3년 차’ 시기에 ‘이직’이라는 것을 해보려고 했다. 하지만 내 수준과 상태를 깨닫는 데는 오랜 시간이 걸리지 않았다. 서류는 바로 탈락하고 그나마 면접이 있는 곳에서도 기초적인 질문조차 답하지 못하는 나를 발견하게 된 것이다. 나는 이직이 아니라 ‘자기 객관화’를 명확히 해야 했다.

그때부터 부족한 기초 지식, 내가 사용했던 기술들에 대한 동작 원리와 기술들을 정리하기 시작했다. 그걸로 부족하다고 느껴 사내 레거시를 걷어 내기 위해 리액트 버전 상향(v15 → v17)과 클래스형 → 함수형 컴포넌트로 생성해 보고, 남들이 지원하지 않았던 RN 서비스 개발을 지원해서 다른 플랫폼의 환경에 직접 노출하기도 했다.

당시에 RN을 지원하는 expo라는 플랫폼으로 다른 서비스들도 운영하고 있었게 파일 업/다운로드를 아무도 해결하지 못했던 것을 3주 밤을 새우면서 해결법도 찾고 expo 개발자에게 메일도 보내보고 해결 프로세스를 사내 위키 문서로 공유하기도 했다(당시 중요한 기능인데 사내 s3 서비스로 운영하던 문서도 없어 애를 먹었던 기능을 노가다로 모든 케이스를 뽑아내어 해결했었다).

그 외에도 복붙해서 사용하던 redux-saga를 사이드 이펙트 관리를 위한 로직 컨벤션 유도, 타입스크립트 첫 도입 등 8개월이라는 기간 동안 ‘나’를 위하기도 하고 ‘팀’을 위하기도 한 도전을 많이 했던 것 같다. 하지만 중요한 문제가 있었다. 바로 ‘나만’ 이런 고민을 하다 보니 동료 개발자들은 ‘왜? 굳이 있는 거 쓰면 되지’라는 자세와 공유해도 읽어보는 사람들이 없었다. 그때부터 확실히 이곳을 떠나야겠다는 마음을 먹게 된 것 같다.

 

퇴사 그리고 이직

첫 퇴사… 많은 분이 마중 나오고 첫 상경에 응원을 많이 해주셨다. 너무나 고마운 분들😂

 

합격 후 설레는 마음에 사전 탐방도 했다!

내부 리모델링을 해서 생각 이상으로 깔끔하고 좋았던 사옥!

 

이직(부산에서 서울까지)

‘자기 객관화’를 하고 난 후 나와 비슷한 생각을 가지거나 더 넓은 생각을 가진 곳으로 가고 싶었다. 퇴근 후 새벽까지 이직 준비를 하게 되었고 약 3개월 동안의 준비 기간 후 현재 ‘이스트소프트’라는 회사에 오게 되었다. 이 회사를 선택하게 된 이유는 크게 세 가지였다.

 

1. 프론트엔드 개발로는 유명하진 않지만, 꽤 많은 MAU를 보유한 서비스를 보유하고 30년간 잔뼈가 굵은 ‘개발자 중심’ 회사라는 것. (+나쁘지 않은 복지)

2. 오래된 회사인 만큼 레거시 한 문화가 많이 있을 거로 생각했고, 내가 도전해 볼 수 있는 환경에 많이 노출될 것 같다는 생각.

3. ‘서울’ 인프라

 

첫 회사를 부산에서 시작했으나, 지방에선 마땅히 이직할만한 규모 있는 IT 회사를 찾기가 어려웠다. 결국 선택은 서울이었다. 무엇보다도 현재 내 실력으론 네카라쿠배는 얼토당토 않은 선택. 결론은 ‘자기 객관화’를 했야만 했다.(지금 있는 곳이 못하다는 말이 아니다.)

 

이직 후 지금까지 느끼고 있는 생각이 있다. 여기 개발자들은 정말 마음가짐부터 다르다. 신입으로 들어오는 백엔드 개발자분들과 1, 2년 차 된 프론트 개발자분들의 수준과 퍼포먼스에 많이 놀랐다. 이미 나보다 높은 수준의 지식과 도전을 하는 것을 옆, 앞, 뒤에서 사방으로 느꼈기 때문이다.

 

정말 많이 반성했고 자극제가 주변에 분포해 있어서 행복하기도 했다. 내가 가진 건 다양한 서비스 경험과 여러 포지션의 개발 경험 그것뿐이었다. 내가 여기서 살아남고 지금 연차보다 더한 퍼포먼스를 보여주어야 했다. 이직 준비 때 보다 여기 와서 공부를 몇 배는 더 많이 한 것 같다. (해도 해도 부족한 게 느껴진다…)

 

사내 활동

프론트 개발이 중심인 회사가 아니다 보니 프론트 시니어는 당연히 없었고, 팀의 규모도 적은 편이다(현재는 필자 포함 4명). 시니어 프론트 개발자가 굉장히 귀하다는 것을 이때 느끼게 되었다. 그래서 생각을 바꾸었다. 시니어를 ‘기다리는 것이 아니라’ 이 회사에서도 시니어 프론트 개발자가 ‘궁금하게끔’ 만들게하기로🔥

 

타 팀과의 교류 활동

회사의 다른 법인인 줌 인터넷 개발자에서 프론트 개발팀이 있어 연고가 없지만 실장님을 통해 ‘사내 프론트 교류회’를 열게 되었다. 특별한 건 아니고 같이 밥이나 티타임을 가질 수 있도록 자리를 마련할 수 있도록 요청했다. 다행히 그쪽에서도 흔쾌히 받아주셔서 각 팀에서 사용되는 프로세스, 기술, 스터디, 책 추천, 컨벤션 등 많은 것을 공유하게 되었다. (오히려 우리가 도움을 더 많이 받은 것 같다)

첫 교류회 후 교환한 정보 리스트

서로 좋았던 정보 공유 현장

북 스터디 개설

회사에 들어오고 나서 기술적으로 사내 시스템을 강화하는 ‘테크 오거나이저’ 일을 맡게 되었다. 사실 열정페이로 진행하는 일인데, 업무 외 적은 시간을 투자하여 팀, 사내 시스템 개선 및 도입을 위해 추천을 받게 되었다. 어차피 내가 하고 싶었던 일들을 공식적으로 할 수 있게 되어서 흔쾌히 받아들였고, 그 중 첫 번째 오거나이저 일이 ‘북스터디’였다.

 

지난 2022년 인프콘 세션 중에 10년간 북 스터디를 운영 사례에 대해 듣게 되었다. 개발자는 항상 공부해야 하고 기술적인 탐구를 계속 해야 하지만 최소한의 ‘기준점’을 두고 공부하기가 쉽지 않다. 너무나 많은 정보의 홍수로 인해 여러 블로그를 헤집어가면서 찾기엔 정확한 정보와 범위를 두기가 어려웠다는 것이다.

 

이를 잘 잡아 줄 수 있는 것이 ‘책’이었다는 것이다. 개발자가 출간한 책의 목차를 기준으로 학습하면 방향성을 잡기가 매우 쉬워지기 때문이다. 해당 세션에서 요약한 북 스터디 운용법에 대한 내용은 이렇다.

1. 질문 만들어오기(어떻게 공부할 것인지?)
2. 핵심 질문 답하기(무엇이, 왜 어떻기에 대한 질문과 토론 및 답변에 대한 정리)
3. 강의식
4. 전달짧은 리뷰(10~ 15분 정도 스터디 범위를 훑어보며 공부했던 것을 떠올리기)
5. 책같이 살펴보기(탐색한 책을 짧게 공유하고 어떤 것을 정할지 토의 및 선택)
6. 그룹 작게 나누기
7. 과제(빈칸 채우기 퀴즈, 완전한 문장으로 만들기 등)
8. 같이 서평 작성하기더 시도해 볼 것(직접 해보기, 플래시 카드 작성, 리더가 필요 없는 스터디 개설, 내용보다 공부 방법)

 

저 모든 것을 다하기엔 스터디 운영 경험이 제로라 팀원들의 스터디 경험자들의 의견들을 많이 수렴하고 북 스터디 운용법을 혼용해서 간단히 운영했다.

1. 책같이 살펴보기 - 평소 공부하고 싶었던 내용인데 혼자 하기 힘들었던 것들 체크
2. 처음부터 어렵고 많은 양의 내용을 다루는 책 선정하지 않기(300쪽 이내 도서 선별)
3. 장소와 시간에 구애받지 않기(게더타운 적극 이용)
4. 깃헙을 생성하여 기록하기 + PR
5. PR과 스터디에 나왔던 질문에 대한 답변 보충
6. 서평 작성

꼭 프론트만이 아닌 백엔드 개발자분들도 같이 할 수 있는 스터디도 진행 중인데 넓은 영역을 스터디 할 수 있어서 굉장히 만족하고 있고 스터디 참석한 모든 분도 만족 중이며 지금도 계속 지원자를 모집하고 스터디를 진행하고 있다. (첫 스터디 운영이라 아주 부족하지만 좀 더 규모 있게 진행된다면 이스트 공식 스터디 레포로 이용할 예정이다.)

현재 운영중입 스터디 Github Repo

[참고] - 스터디 운영 링크

 

프론트 팀 공유 위키

규모가 작다 보니 팀별로 관리되는 문서가 따로 없었다. 그러다 보니 개인적으로 정리하던 것을 구전으로 알리거나, 채팅으로만 전달되는 것을 방지하기 위해 프론트 팀만을 위한 공유 위키 문서를 작성하게 되었다. 기존 혼자서 노션에서 정리했던 기술 정리 및 아티클 등 팀의 상향 평준화를 위해 전부 공유할 수 있도록 했다. (하나하나 다 이전하다 보니 하루를 꼬박 투자했던 것 같다.)

 

디자인 시스템 구축(Storybook + Atomic Design Pattern)

두 번째 테크 오거나이저 활동으로 디자인 시스템 도입을 하게 되었다.

Perso라는 서비스 개발을 진행하면서 앞서 팀원분이 스토리북과 아토믹 디자인 패턴을 도입했으나, 첫 시도여서 그런지 이미 익숙한 작업을 하게 되면서 잘 진행이 되지 않았다. 무엇보다 Storybook과 아토믹 디자인 패턴은 개발자뿐만이 아니라 디자이너, 퍼블리셔분들과 같이 협업해야 가능했는데 타이트한 일정 때문과 익숙했던 작업 스타일을 벗어 내기가 힘들었던 것 같다. (다들 적극적으로 수행했지만, 시간과 경험이 부족했다고 생각한다. 현재는 제대로 Storybook을 활용할 예정)

 

두 번째 서비스 진행 시 Storybook과 아토믹 디자인 패턴을 버리기가 뭔가 아쉬웠다. 이번엔 좀 더 개인적인 시간을 더 투자해서라도 제대로 저 조합을 이용하고 싶었다. 다행히 퍼블리셔와 개발팀이 마음이 맞아서인지 처음 화면 설계를 아토믹 디자인 패턴으로 설계하는 것부터 엄청난 시간 소모를 했고, Storybook을 정상적으로 이용하기 위해 addon과 모든 에러 제거 및 docs 활용 등 약 3개월에 걸친 trade off 끝에 정상적인 ‘디자인 시스템’을 구축하게 되었다. 디자인 팀과 퍼블리셔팀과 정말 큰 노력 끝에 결실을 보았다.

 

디자인 시스템 구축의 목표는 아래와 같다.

1. 기획 - 디자인 - 퍼블 - 개발 각 팀 간의 업무 프로세스 간소화
 > 스토리북 서버를 배포하여 실제 운영 서비스가 어떤 디자인 컨셉을 가지는지, 어떤 식으로 구성되는지, 기획, 디자인이 의도대로 잘 반영되었는지 일일이 전달할 필요가 없게 되었다.

2. 사내 서비스 디자인 시스템 첫 도입
 > 사내 모두가 해당 서비스가 어떤 식으로 운영되고 동작하는지 모두가 확인하고 프로토타입으로 동작해볼 수 있게 되었다.

3. addon 커스텀 기능 개발
 > 퍼블리셔 팀을 위해 각 서비스에서 사용되는 디자인 문서, 스타일 가이드, 메일 폼이나 약관 폼과 같은 static 한 페이지 구성을 테스트해 볼 수 있도록 마크다운, HTML 수정 기능, 페이지 및 컴포넌트 다운로드 기능 등 편의를 위해 커스텀 개발을 진행했다.

[참고] - 도입기 발표 정리 링크

마지막으로

첫 입사 당시 난 SQL은 학교에서 이론만 배운 정도였고, API 통신은 해본 적도 없으며, React는커녕 Javascript를 제대로 다루지도 못했었다. (프론트/백엔드의 개념도 입사 2년 차 때부터 인지하기 시작했다)

 

개발 경력은 5년 차이지만 실제 순수 프론트 개발 경력으로는 이제 3년 차가 되었다. 지금 내 경력은 물경력이라 생각되어 꾸준히 노력 중이다.

 

내가 어쩌다가 ‘웹 개발’ 자가 되었을까? 더 나아가서 어쩌다가 ‘프론트엔드 개발자’가 되었을까?

 

사실 의식의 흐름대로 내가 흥미가 가는 위주로 학습하다 보니 현재의 위치에 자리 잡게 된 것 같다. 앞으로도 ‘자기 객관화’를 통해 오만한 생각을 하지 않고 나를 위해서, 팀을 위해서, 다른 개발자를 위해서 더 노력할 수 있게 전환점이 되었던 해였다고 생각된다.