스타트업에서 대규모 서비스 기업으로 이직한 주니어 개발자의 2018년 회고

2017년 회고를 쓴 것이 엊그제 같은데 어느새 2018년 회고를 쓰게 되었다.

2018년 한 해 동안 개발자로서의 나는 무엇을 배웠고, 얼마나 성장했을까.

스타트업에서 대규모 서비스 기업으로 이직한 주니어 개발자의 한 해를 돌아본다.

이미지 출처

목차

1. 회사에서 경험한 것들
2. 회사 밖에서 경험한 것들
3. 역경, 그리고 극복
4. 정리, 그리고 다짐

---

1. 회사에서 경험한 것들

활발한 코드 리뷰

• 이전 스타트업에서는 혼자 2-3개의 프로젝트를 진행했기에 코드 리뷰를 할 일이 없었다. 그래서 코드 리뷰에 갈증을 느끼고 있었다.
• 현재 회사에서는 하나의 프로젝트를 여러 명이 협업하여 진행하기 때문에 코드 리뷰가 활발하게 진행되고 있다.
• 시니어의 피드백도 좋았지만, 그보다 좋았던 것은 코드 리뷰를 할 때 모두가 서로의 감정이 상하지 않도록 배려해준다는 것이었다.
• 지식의 높낮이와 상관없이 서로를 존중하는 것. 코드 리뷰의 기초이자 가장 중요한 점이라고 생각한다.

아래는 몇 개의 코드 리뷰 샘플들이다.

이건 올해 받은 코드 리뷰 중 제일 기분 좋았던 리뷰이다. (소심한 자랑.. 칭찬은 개발자를 춤추게 합니다. ^^;)

업무 근육이 강해졌다.

• 내 경우는 단순히 기술 스택만 바뀐 것이 아니라 회사의 규모 자체가 크게 바뀌었는데, 스타트업에 비해 업무 프로세스가 훨씬 견고하게 정립이 되있고, 협업하는 부서들이 아주 많아졌다.
• 메일 쓰기, 문서 정리하기, 설득하기, 도움 요청하기 등등.. 처음에는 이런 것들을 익히는 게 낯설고 힘들었다. 나를 번아웃에 빠지게 만드는 요인 중 하나이기도 했다.
• 그렇지만 시간이 지나서 요령이 붙었고, 이제는 꽤 능숙하게 쓸 수 있게 되었다.
• 지금은 생각이 많이 바뀌었다. 메일 쓰기, 도움 요청하기, 문서 정리하기 등은 정말 중요한 협업 능력이다.

P.S 1) 밑에서 언급하겠지만 글또가 많은 도움이 되었다.

P.S 2) 내 생각을 바꾸는 데에 일조했던 글을 공유한다.

3.5년간 대기업에서 배운 5가지

새로운 개발환경

• 주 기술 스택이 Java, Spring, Linux 에서 C#, .NET, Window 으로 변경되었다.
  그렇지만 패러다임이 바뀐 것이 아니었기 때문에 익숙해지는데 별로 어렵지 않았다.
• 그래도 역시나 삽질은 했다.
  (당연히 되어야 할 것 같은데 안 되는 것들이 많았다. 예를 들면 배포? 알고 보면 뭔가 빼먹었다거나. 역시 한 번에 잘 되는 건 없었다.)

대용량 데이터 경험

• 이전에는 상상도 하지 못했던 규모의 데이터들을 핸들링하는 경험을 했다.
• 빅데이터 플랫폼 (Hadoop Ecosystem .. )을 이용해서 서비스를 개발했고, 곧 런칭 예정이다.
• 그렇지만 빅데이터 플랫폼은 아직 사용하는 수준에 머물러 있다. 노하우를 얻으려면 더 많은 공부와 경험이 필요하다는 것을 느낀다.

아래는 내가 올해 겪었던 빅 데이터 플랫폼 경험을 정리한 글이다.

람다 아키텍쳐 (Lambda Architecture) 정리

---

2. 회사 밖에서 경험한 것들

원칙

• 본업(회사)에 지장을 주지 않을 정도의 리소스를 할당할 것
• 돈이 1순위가 아니라 나의 성장이 1순위일 것
  • 내가 성장할 수 있고, 그럼으로써 회사에도 도움이 될 기회들을 찾아보았다.

활동 1) 글또

글또는 개발자 글쓰기 모임이다. 자세한 설명은 이전에 쓴 글의 링크로 대신한다.

글또를 시작하는 다짐 글

무엇을 배웠나?

1. 블로그에 글을 꾸준히 발행할 수 있게 되었다.
2. 읽는 사람을 배려하여 글을 쓰는 방법을 고민했다.
3. 이 과정에서 내가 더 많이 공부하게 된다.
4. 글솜씨가 조금씩 늘고 있는 것 같다.
   • 결국, 이것이 업무에 도움이 되더라. 메일 쓰기, 문서 정리하기 등

활동 2) Dev Tycoon

곧 사회로 나가는 후배들에게 내가 그간 배운 것들을 공유해주는 스터디를 하고 있다.

학생에서 개발자로 잘 성장하라는 의미에서 이름을 Dev + Tycoon이라고 지었다.

이 스터디는 진행한 지 3개월이 조금 지났고, 내 시간도 꽤 많이 투자했다.

처음에는 그냥 보람으로 시작했는데 돌이켜보니 후배들을 가르치며 나도 얻은 것이 많았다.

1. 코칭 스킬
   • 어떻게 가르쳐야 효과가 좋은지 (ex : 지난 시간에 알려준 것들을 서로에게 설명해보기)
   • 어떤 것을 배우고 싶어하는지 알게 됨
2. 나도 모르는 부분을 알게 됨
   • 설명해주기 위해서는 우선 스스로 해당 내용을 잘 알고 있어야 함
   • 가끔 나도 설명하다 막힐 때가 있음, 그러면 나도 모르는 부분을 다시 한 번 공부하게 됨

그리고 지금은 좀 더 효율적인 커뮤니케이션을 위해 다양한 도구들과 프로세스를 고안 중이다.

1. Trello
2. Github
3. Slack 에 1, 2 연동
   • 다양한 Slack 봇 구현 중

위 내용을 주제로 Facebook Developer Circle: Seoul에서 주최한 스터디 리더 캠프에서 경험담을 공유했다.

그리고 내년부터는 페이스북으로부터 스터디 장소와 식비를 지원받게 되었다. Yeah!

이 내용은 언젠가 별도의 포스팅으로 공유할 예정이다.

3. 역경, 그리고 극복

레거시(Legacy)야 잘 지내보자.

• 레거시를 좋아하는 개발자는 거의 없을 것이다. 나 또한 그렇다.
• 업력이 오래된 회사는 누구나 가지고 있는 레거시지만 .. 스트레스를 많이 받았다. 코드를 쳐다보기도 싫을 정도로. (매직넘버를 찾아 테이블 더미를 뒤지고 있을 때면 여긴 어디 나는 누구?)
• 그리고 전 회사의 레거시와 다른 점은 매출과 굉장히 밀접한 시스템들이라 레거시를 함부로 고치지 못한다는 점이다. (뭐, 사실 그걸 떠나서 너무 복잡하고 시스템도 커서 고치기도 힘들다.)

내가 특히 레거시에 스트레스를 많이 받았던 것은 코드 스멜을 참기 힘들어하는 사람이었기 때문이다.

• 아마 개발자로 월급을 받기 시작한 시절부터 클린 코드, 리팩토링, TDD의 중요성을 가르침 받아왔기 때문인 것 같다. (PS. 이건 정말 감사한 일이며, 나는 지금도 위의 것들의 중요성을 가르쳐준 분을 멘토로 모시고 있다.)

그렇지만 레거시를 대하는 태도를 바꾸고 나서는 괴로움에서 많이 해방되었다.

지금은 레거시를 보면 아래와 같이 처리한다.

1. 당연하겠지만 내가 기능 추가를 하는 부분에 레거시가 있으면 리팩토링을 한다.
   • 보이스카우트 규칙, 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
2. 그 외 부분에서 레거시를 발견하는 경우는 아래와 같이 한다.
   • 리팩토링 비용이 적은 경우 (코드 변화가 많지 않고, 사이드 이펙트가 없을 것이라는 확신이 드는 경우) 리팩토링한다. 당연히 관련된 부분에 대해 테스트를 해본다.
   • 리팩토링 비용이 많이 든다고 판단되는 경우 리팩토링 하지 않는다. 대신 다음 작업자가 인식할 수 있도록 주석을 남겨둔다. 기술 부채가 너무 크다고 판단되는 경우 팀에 공유한다.

과도한 책임감의 폐해

나는 남에게 피해를 끼치는 것을 싫어하는 성격이다. 업무적으로는 특히나 그렇다.

그리고 경력직으로 입사했기 때문에 맡은 업무에 대한 책임감이 컸다.

내가 맡은 일에서 문제가 발생하면 모든 것이 내 책임이라고 생각했고, 모든 일을 완벽하게 잘 끝내야만 한다고 생각했다.

그러다 보니 문제가 생겼다.

1. 내 힘으로 통제할 수 없는 변수가 생긴다. (아주 잦다.)
2. 예상된 일정에 지장을 주게 된다.
3. 어떻게든 할당된 시간 안에 업무를 끝내고자, 야근한다.

얼마 지나지 않아, 이게 진짜 심각하게 잘못하고 있다는 것을 깨닫고 반성했다.

내 진행 상황과 모든 잠재적 위험 요소는 팀에 공유해야 한다. 특히 팀장님께 꼭 공유해야 한다.

이유는 아래와 같다.

1. 리소스 배분에 문제가 생길 수 있다. 내가 아주 바쁜 상황인데, 팀장님이 인지하지 못하시면 나에게 업무가 추가적으로 들어올 수 있다.
2. 이로 인해 프로젝트에 문제가 생길 수 있다. 그러면 모두가 힘들어진다.

지금은 잠재적으로 일어날 수 있는 모든 위험 변수들을 계산해서 팀에 공유한다.

업무를 진행하며 일어나는 모든 진행 상황도 주간 회의와 Tracking 가능한 시스템에 남겨둔다. (JIRA, Wiki, Mail 등)

최근 내가 진행한 Task 중 모든 도메인에 영향을 미칠 수 있는 잠재적인 리스크가 매우 큰 Task가 있었다.

1. 설계 시 이 부분을 충분히 고려했고, 기획자분과 우리 팀에 해당 리스크에 대해 상세히 공유했다. 그리고 이러한 점을 계산해서 일정을 산출했다.
2. 예상대로 문제가 생겼다. 그렇지만 리스크가 충분히 공유되어 있었기에 팀장님의 확인 하에 팀원분들이 즉각적으로 지원을 해주셨고, 덕분에 Task를 마무리 할 수 있었다. (함께 고생해주신 팀원 분들께 정말 감사하다.)
3. 그리고 나는 휴가를 무사히 다녀올 수 있었다.

정리, 그리고 다짐

정리하자면 올 한 해는 여러 사람과 손발을 맞춰나가며 적응하고, 성장하는 한 해였다고 생각된다.

회사 밖에서도 다양한 시도를 해봤다. 내년쯤에 어떤 형태로도 결과물이 나와 있을 것 같은데, 나쁘지 않을 것 같아 기대된다.

부족한 점은 개선하고, 올해 얻은 경험과 지식으로 내년엔 더 많은 것을 할 준비가 되어 있다고 느낀다.

수고 많았다. 나의 2018년.