[2020-11-11] 5년차 개발자

나에게 5년차라는 개발 연차는 조금 특별하다.

첫 회사에서 내가 속한 조직에는 시니어 개발자가 없었다. 내가 입사했을 때 1년 정도 차이가 나는 선배개발자가 한분 있었고, 입사한 후 6개월 텀으로 1~2명 정도의 신입 개발자들만 채워졌다.

당시에 동료들과 나는 5년차 개발자에 관해 이야기를 많이 했다. 회사에 5년차 정도의 개발자 한분만 오셨으면 좋겠다고 매일 이야기했다. 당시에 나는 5년차 개발자는 엄청난 내공을 가지고 있는 환상 속의 시니어 개발자라고 생각했다. 2년차로 막 들어섰을 무렵 합류하신 팀장님과 면담에서 내 목표를 물은 적이 있다. 나는 그때 최대한 빠르게 시니어 개발자가 되는 것이라고 답했다. 굉장히 멋쩍게 웃으셨는데 이제는 그 웃음의 의미를 알고 있다.

내가 생각하는 시니어 개발자의 방향과 잘 맞아떨어지는 Tech HR 컨퍼런스 김범준 CTO(발표 당시)님의 2.주니어 개발자와 시니어 개발자의 차이 발표를 듣고 현재 우아한형제들에 합류하고 싶다고 생각한 계기가 되기도 했다. 아무튼 그때의 나는 5년차가 주니어가 시니어가 되는 시기라고 생각했었다.

이제 5년 전에 내가 갈망하던 그 5년차가 되었다. 4~5년차를 몰아서 회고해본다.

1. 회사

누가 나에게 현재 회사의 좋은 점을 물어볼 때 나는 항상 '도전 거리가 넘친다' 라고 말했다. 현재 회사는 아직 갖추지 못한 것들이 많다. 아직도 무수히 많은 신규시스템들이 계속 생기고 있다. 그리고 계속 성장하고 있다. 내가 입사했을 때도 이미 많이 성장했던 상태였음에도, 입사했을 때보다 트래픽이 몇 배나 상승했고 현재도 계속 상승 중이다. 트래픽, 과제, 비지니스 적으로 모두 도전 거리가 넘치는 회사이다.

나는 입사 후 2년간 결제 시스템 개편, 주문 시스템 개편, 프론트 시스템 개편, 배달예상시간 시스템 신규 구축, A/B테스트 시스템 신규 구축을 했다. 현재는 프론트 시스템을 포함한 5개 시스템을 운영하고 있고, 또 다른 신규 시스템 오픈을 앞두고 있으며, 또 다른 거대한 시스템의 개편 시작을 앞두고 있다.

정말 바쁘게 일하고 있고, 앞으로도 바쁠 것 같다.

1-1. 설득

달리는 기차의 바퀴를 갈아 끼우는 일 또한 매우 어렵지만, 개편마다 내가 가장 힘들었던 것은 설득이였다. 나는 나보다 적은 연차의 사람들과 개편을 한 적이 없다. 이제는 나보다 연차가 높은 사람들만 설득이 힘든 일이 아니란 것을 잘 알지만 그때 당시에는 나보다 고연차의 사람들을 설득하는 상황이 더 큰 부담으로 다가왔다.

나에 대한 신뢰가 걱정되기보다는 이러한 설득 과정이 사람 간 관계를 망칠까 우려했었다. 다행히 날 지지해주는 팀장님과 잘 받아들여 주는 구성원들이 있었기에 상처를 입거나 한 일은 없었지만, 매번 조심스러웠다.

아무튼 이런 과정에서 세우게 된 설득의 규칙이 생겼다.

이전 시스템을 부정하지 않는다.

몇달 전 내가 짠 코드를 오늘의 내가 볼 때 형편없어 보일 때가 많다. "나는 성장한 걸까?" 라고 느낀 적도 있었지만, 대부분은 당시에 내가 다루던 관점과 현재의 관점의 차이에서 온 '틀림이 아닌 다른 방향'을 추구하는 코드로 변경했었다. 내가 개선해야 할 시스템도 마찬가지일 수도 있다고 생각한다. 때로는 시간이 지남에 따라 당시의 관점이 현재의 시스템에서는 틀린 것이 되어있을 수도 있다고도 생각한다. 틀린 방향을 추구했던 것이 있다 한들, 당시의 구성원은 지금의 내가 생각하는 방향보다 더 좋은 방향을 추구해나가고 있을 수도 있다. 실제로 그런 구성원들을 더 많이 보았다.

때로는 이전 시스템을 만들었던 당사자들과 함께 개편을 했고, 때로는 이전 구성원들 없이 개편을 했다. 당사자들이 있건 없건 한번 부정적인 생각을 하기 시작하면 계속 떠올리게 된다. 이런 것들이 나에게는 집중을 방해하는 큰 요소가 되었다.

어떤 시스템이든 만들어졌을 시기와 상황이 있었을 것이다. '내가 개선해야 하는 시스템은 당시의 문제를 해결하기 위한 최고의 선택으로 만들어졌을 것이다' 라고 믿기로 했다. 이렇게 믿기로 한 후 더 현재의 문제점에 집중할 수 있게 되었다. (물론 많이 어긋나있을 때 한숨을 많이 쉬기는 한다)

문제를 적나라하게 드러낸다.

이전 시스템을 부정하지 않음으로써 더는 불필요한 감정소모는 없었다. 단지 현재 문제에 집중할 뿐이다. 그래서 문제를 적나라하게 드러낼 수 있다. 드러내야 할 문제들은 코드의 수준, 디자인, 아키텍처, 설계 등 다양한 분야였다. 이 시스템은 이제 나와 내 동료가 함께 만들어나가야 할 시스템이다. 현실과 이상에서 오는 괴리감으로 인해 후에 올 스트레스는 거대하다. 그러한 거대한 스트레스를 마주하지 않기 위해 지금 바로잡아야 한다.

어중간한 설득으로 합의되지 않았을 때 그 문제는 언젠가 반드시 마주하게 되어있다. 그래서 한번에 확실한 합의를 통해 해결하는 것이 가장 좋다. 그러기 위해 최대한 적나라하게 드러내야 한다. 내가 경험한 대부분 이론들은 항상 장단점이 있었다. 내 머리에 있는 것을 남에게 이해시키는 것에 서툴기도 하지만, 무엇을 잃고 무엇을 얻는 것이 맞나 하는 판단에서 확실한 설득이 어려웠다. 이럴 땐 권위 있는 전문가들의 서적이나 블로그 등을 많이 활용했었다. 씁쓸하지만 이 방법을 사용하는 것은 꽤 효과적이었다.

의견과 생각을 말해 달라고 요구한다.

항상 확신을 하고 설득에 임하지만, 내가 잘못 생각하고 있을 수도 있다는 여지는 남겨둔다. 그러나 대부분 자발적으로 이에 반기를 내지 못한다. 말해달라고 요구하는 이유는 크게 두 가지 이다.

첫번째, 나는 설득을 위해 시간을 들여 생각과 이론을 정리했으나 듣는 사람 쪽은 상대적으로 충분히 생각할 시간이 부족하기 때문이다. 짧은 시간 안에 확신에 찬 의견의 반대 의사를 잘 다듬어지지 않은 채 뱉는 것은 큰 용기가 필요할 것이다.

두번째, 나는 어떠한 디자인 패턴과 아키텍처 이론도 100% 녹아들 수 없다고 생각한다. 이러한 이론들은 대게 몇 가지 상황을 보여주며, 어떠한 문제를 해결할 수 있다는 점을 제시한다. 제시하는 문제점을 해결하는데 많이 적용하고 있지만, 항상 변형과 예외는 존재했다. 권위 있는 지식인들의 이론으로 시스템의 80% 정도를 해결하고 있다면, 남은 20%를 채워야 한다. 이 20%는 개인마다 무수히 많은 견해차가 나올 수밖에 없다. 나오지 않는 것에 의구심을 품어야 한다고 생각한다.

그래서 말해달라고 요구를 해야 한다. 나로서 필요한 건 상호 간의 합의이다. 조금이라도 의구심이 드는 점들을 이 때 알아차리지 못하고 합의되지 못했을 때도 결국 그 문제는 후에 다시 마주하게 될 것이다.

이와 별개로 내가 생각하지 못했던 점을 제시해줬을 때 그 문제를 해결하기 위한 시간이 나를 많이 성장시키고 있기도 하다.

1-2. 운영

2019년도 즈음 심하게 개발하기 싫은 적이 있었다. 지금 생각해보니 두 가지 이유에서였다.

첫 번째는 고독함이다. 회사에 친한 동료가 많이 있지만, 그것과는 다른 것이었다. 계속 말한 대로 나는 개편과 새로운 프로젝트에 투입되기 바빴다. 그렇게 정신없이 2년 정도가 흐른 것 같다. 어느 순간 돌아보니 다른 사람들은 어딘가에 소속되어 자리를 잡고 있었고, 나는 뭐 하는지 모르는 정체성 없는 개발자가 되어있었다. 현재 팀은 서비스와 밀접하여 여러 부서와 상호작용을 많이 해야 하는 팀인데 나는 이 안에서도 회사의 요구사항으로 단독으로 몇 개의 시스템을 개발하기도 했고, 이 프로젝트 저 프로젝트를 옮겨 다니며 초기 빌딩을 도왔다. 다들 함께 일하는데 혼자 일하기까지 하고 있으니 정체성 혼란이 정점을 찍은 시기였다.

두번째는 개발에 대한 방향성이다. 나는 좋은 프로젝트와 좋은 코드를 추구한다. 이 좋은 프로젝트와 좋은 코드라는 것은 모두 운영을 잘하기 위하므로 이어진다. 그러나 나는 운영을 하지 않았다. 그래서 책을 통해 학습하고, 토이 프로젝트에서 시도를 해보거나, 내가 떠난 뒤 운영을 하는 분들에게 피드백을 받기 위해 노력했다. 그러나 이런 간접 경험은 갈증을 전혀 해소시켜주지 않았다. 이게 결국 스스로에 대한 의구심으로 이어져 자신감을 계속 떨어트렸다.

위 두 가지 원인으로 개발하면서도 잡생각이 너무 많아졌고, 일이나 개발에 대해 생각하기 싫은 수준까지 왔다. 당시에는 번아웃으로 인지 못했지만 지금 돌아보니 그게 번아웃이였구나 싶다.

그래서 결국 운영을 요구했고, 잘 받아들여 줘 당분간 다른 개편이나 프로젝트에는 참여하지 않고 운영에 집중할 수 있는 환경이 만들어졌다. (오래가진 못했다) 아무튼 소속감이란 게 생기고, 운영하면서 많은 시도와 검증을 하면서 번아웃은 거의 사라졌다.

달리는 바퀴를 닳지 않게 관리한다.

모든 코드는 작성과 동시에 레거시가 된다. 레거시가 된 프로젝트를 언제까지 개편만 할 수는 없다. 평소에 이상을 보이는 것들을 잘 관리해야 했다.

CI 환경 구성은 도움이 많이 되었다. CD를 땔 수가 없지만, CI를 좀 더 강화하고자 별도 분리된 환경도 따로 만들었다. 자동화된 과정으로 테스트 결과와 정적 분석의 결과를 조금 더 상세하게 알람으로 받을 수 있게 하였다. 팀의 규칙이기도 하고 자동으로 결과 알람이 계속 발생하다 보니 조금 더 의식하게 되었다. 테스트 작성을 조금 더 의무화할 수 있었고 기본적인 컨벤션을 잡을 수 있었다.

안정된 의존관계 원칙과 안정된 추상화 원칙에 대하여 라는 글은 코드의 디자인적 측면에서 도움이 많이 되었다. 예를 들어 하나 이야기하자면 배달에 대한 비용을 계산하고 코드였다. 이 계산을 거의 모든 기능에서 사용해야 한다. 안정성이 높다고 할 수 있다. 그러나 코드는 굉장히 구체적으로 작성되어 있었다. 비지니스적 이슈로 코드를 변경해야 할 때면 눈이 빠지게 코드를 보아야 했다. 말 그대로 고통의 지역에 있었다. 이 부분에 대해 추상적으로 변경하고 난 후 변경에 유연한 구조를 갖을 수 있었고, 추상화를 하다보니 구현체에서 어떤 책임과 역할을 응집해야 할지 보기 쉬워졌다. 고통에서 벗어날 수 있었다.

나느 위의 안정된 의존관계 원칙과 객체지향에서 말하는 의존관계의 방향을 중요하게 생각한다. 그리고 의존관계를 컴파일 레벨에서 모듈, 패키지, 클래스 단위에서 제한하여 더욱 안정적인 의존관계를 갖는 개발이 가능하도록 노력하고 있다. 기술블로그에 작성했던 멀티모듈 설계 이야기 with Spring, Gradle 은 이런 관점 중 모듈에 조금 더 집중하여 작성하였다. 이 내용이 운영하며 계속 발전하기도 했고, 패키지, 클래스 단위까지 이야기하지는 않았었어 묶어서 한 번 더 정리를 해보고 싶다.

그리고 객체지향의 기조를 기본으로 따르고 있다. 객체지향인 디자인이 좋은 프로젝트와 좋은 코드를 만드는 데 많은 도움을 준다고 강하게 믿고 있다. 객체지향에 대해서 적어도 내 주변의 모든 구성원이 동의하고 있는 내용이라 함께 학습하고 때려 맞으며 발전시키고 있다.

불편함을 보고 모른척하지 않는다.

2.0 까지 해본 개발자 라는 글은 나를 절로 고개 숙이게 만드는 글이었다. 그래서 많은 운영 툴들을 만들게 되었다. 서비스에 영향을 주지 않는 선에서 QA, 운영자를 위한 기능을 될 수 있으면 만들었다.

간혹 편해졌다고 이야기해주는 때가 있었는데 상당히 뿌듯했다.

재미를 주려고도 많이 노력했다..

인적 SPOF 을 만들지 않는다.

버스 지수(bus factor)는 팀원 중 몇 명이 버스에 치여죽어야 프로젝트가 심각한 상태에 놓이는지를 나타내는 지표다. 버스 지수 1은 특정인 1명만 빠져도 망한다는 의미인데 위험한 상태이다.

"코드는 내가 아니다" 라는 말이 있다. 이런 말이 있기도 한 이유는 코드나 프로젝트에 강한 애착을 둬 타인이 프로젝트에 손대는 것을 꺼리는 사람들이 있기 때문이기도 하고, 코드가 본인을 비추는 것으로 생각하여 본인이 작성한 코드를 남에게 공개하기 어려워하는 사람들도 있기 때문이다.

이것은 반드시 고쳐야 할 사고라고 생각한다. 코드는 문제를 해결하기 위한 수단일 뿐이다. 서비스 개발자라면 해결해야 할 문제는 비지니스일 것이다. 비지니스를 잘 되게 하려면 내가 모르는 버그로 장애가 발생할 것을 더 두려워해야 하고, 개발 생산성을 높이기 위해 노력해야 하고, 내가 없어도 다른 사람들이 문제를 해결할 수 있어야 한다.

이런 문제를 방지해줄 수 있는 것이 코드리뷰와 페어프로그래밍 도입이었다.

코드 리뷰의 장점은 이미 많은 곳에서 소개하고 있기도 하다.

• 본인이 작성한 코드를 본인이 다시 보아도 전체 흐름을 이미 알고 있는 대전제가 머릿속에 있어서 다른 예외가 보이지 않을 때가 종종 있지만, 타인의 관점에서 다른 시야로 새롭게 코드를 볼 때는 잘 보일 때가 많다. 그래서 버그를 감지해낼 확률이 더 높다. 함께 검증한 코드이기 때문에 장애시 멘탈 관리에 도움이 되기도 한다.
• 서로 코드를 보며 표준적인 코딩 스타일을 맞출 수 있다. 표준이 생기면 명확함이 생겨서 코드 작성에서도 고민하는 시간이 줄고, 서로 간의 가독 상승효과로 이어져 생산성을 높일 수 있다.
• 어떤 문제를 어떻게 해결했는지가 간접적으로 전파된다. 버스 지수를 높일 수 있다.

하지만 코드리뷰는 서로 전혀 다른 컨텍스트를 이해해야 하기 때문에 시간이 많이 들기도 하고, 각자의 일로 시간이 부족한 상황에서는 제대로 이루어지지 않는다. 이런 문제는 페어 프로그래밍으로 보완했다.

페어 프로그래밍의 효과는 코드리뷰와 비슷하다. 코드리뷰가 다수에게 다소 추상적으로 공유된다고 하면, 페어 프로그래밍은 소수에게 명확하게 공유되는 효과가 있다. 그러나 페어 프로그래밍은 다수가 하나의 일을 하므로 속도가 1/n 으로 줄게 된다.(페어에 익숙해진다면 인당 0.7 ~ 0.8 정도의 수준까지는 끌어올릴 수 있다고 생각한다.) 그래서 업무 분배를 할 때부터 이를 고려해서 업무를 할당을 해야한다. 시간을 약간 손해를 보지만 얻게 되는 것이 더 크다.

위의 이유로 코드리뷰와 페어를 꼭 하고 싶었고 무사히 안착 되었다. (전체를 페어를 했는데 맡은 시스템의 규모가 크기도 하고 개수도 많다 보니 컨텍스트 스위칭 비용도 만만치 않았다. 전체 인원을 고려하여 적당한 듀얼리티를 완성하는 것도 좋을 것 같다.)

1-3. 리딩

운영하기 시작하면서 6명 규모의 파트에서 리딩해야했다. 초기에는 PO 가 파트에 함께 있어 개발에 대한 리딩만 하면 되었는데, 조금 지나고 조직이 변화하면서 개발 파트가 됨에 따라 책임과 역할이 커졌다. (PO 가 함께 하고 개발에 대한 리딩만 하면 되던 때가 가장 좋았던 것 같다.)

주변에서 빠른 것 같다는 이야기도 많이 들었다.

리더가 개발에 멀어질 수밖에 없는 이유를 알 것 같다.

나는 아주 오래전부터 리딩이란 것을 하기 싫어했다. 내가 그동안 본 수많은 리더들은 리더가 되면서 개발을 서서히 내려놓았다. 나는 오래오래 개발을 하고 싶은데 개발을 내려놓을 수밖에 없는 환경이 된다는 것이 끔찍했다. 이번에는 정식적인 리더는 아니고 팀 아래 파트 리딩이라서 가볍게 시작했지만, 위임의 정도가 커서 많은 것들을 경험했다.

의사결정을 해야 하는 일이 많고 의사결정을 위한 논의를 해야 하는 일이 많다. 이러한 시간으로 직접 개발할 시간은 점점 줄어든다. 어느 순간 내 개발 생산성이 현저히 줄어든 것을 알 수 있었다. 결국, 일이 되게 해야 하기 때문에 내가 작업하는 양을 줄이고 구성원들에게 위임을 많이 하게 된다. 코드 리뷰나 다른 활동을 통해 프로젝트의 구현을 계속 따라가는 데에는 많은 노력이 필요하다. 노력의 정도와 상관없이 일이 너무 많으면 불가능한 케이스도 있다고 생각한다. 이런 시간이 지속됨에 따라 내게 개발은 점점 추상화된다. 이런 시점이 오면 선택과 집중을 자연스럽게 떠올리게 될 것이고, 결국 개발은 위임하고 리딩에 집중하게 될 것이다.

다행히 나는 우리가 흔히 아는 팀장 수준의 역할을 맡은 것은 아니라서, 위임을 늘리고 구현을 따라가는 데 노력이 필요한 수준에 머물러있다. 언젠가 팀장과 같은 역할을 주려 한다면 전력을 다해 벗어나야...

1-4. 주니어 케어

운영을 시작하면서 내가 케어해야 할 주니어들이 생겼다. (나도 주니어지만) 내가 신입 시절 원했던 선배 개발자 역할을 이분들에게 잘할 수 있을지 설레기도 하고 겁도 났던 것 같다.

신입 시절 선배 개발자가 없었기 때문에 아쉬웠던 것은 시간에 대한 낭비였다. 양질의 정보를 찾기 위해서 많은 시행착오를 겪어야 했다. 때로는 방향을 잡는 데에만 상당한 시간이 필요했고, 때로는 잘못된 정보를 걸러내지 못해 시간 낭비를 했다. 다른 방향으로 나아가다가 처음으로 다시 돌아와야 했던 일도 많았다. 내가 나중에 후배 개발자들을 만난다면 그들이 시간적인 낭비를 하지 않도록 도와야겠다고 많이 생각해왔다.

그렇지만 내가 신입 시절 선배 개발자가 없었기 때문에 얻었던 것 역시 있었다. 시간을 더 사용했지만, 무식하리만큼 많은 정보와 기술을 받아들였다. 수없이 많은 가정과 실험을 통해 어렵게 정답에 가까이 다가갔다. 힘들게 얻어진 물고기 잡는 법은 쉽게 잊히지 않았다. 내가 나중에 후배 개발자들을 만나면 스스로 생각하는 시간을 충분히 갖도록 해야겠다고 생각해왔다.

시간을 낭비하지 않지만, 스스로 생각하는 시간을 충분히 갖도록 한다는 것은 쉽지 않았다. 답보다는 방향을 제시하려고 노력했고, 생각과 선택을 강요하지 않으려고 노력했다. 그렇지만 잘못되었다고 생각되는 방향은 단호하게 거절하려고도 노력하고 있다. 시간을 주는 것과 단호하게 거절해야 하는 상황을 구분하는 것은 아직도 어렵긴 하다.

후배 개발자들을 케어하면서 내가 설명을 하는 방식에 변화를 주어야겠다고 느끼게 되었다. 어떠한 문제에 관하여 이야기할 때 간혹 너무 장황한 설명이 되어 이해가 어려워질 때가 있다. 이것은 내가 가진 학습법에서 비롯된 것으로 생각한다. 나는 책을 보조 수단으로 활용하고 실행을 우선으로 옮기는 야생형 학습에 익숙한 개발자이다. 그동안 내 학습은 문제를 해결하는 방법에만 집중하고 그들이 사용하는 언어는 크게 생각하지 않았다. 간단히 예를 들면 나는 디자인패턴의 이름을 외우려고 하지 않았고, 패턴 이름을 알고 있어도 이름보다는 문제와 해결 방법으로서 설명해왔다.

변화가 필요하다는 것을 가장 크게 느끼게 한 것은 어떠한 세미나에서였다. 이 세미나의 연사분은 개발자들 간의 약속된 언어를 잘 사용했고, 그 배경을 뒷받침하는 권위 있는 지식인의 말 등을 잘 활용했다. 설명도 훌륭했다. 내가 크게 느꼈던 이유는 세미나에서 일부 이야기는 내가 이전에 이야기했던 것과 같은 방향의 내용이었는데 그 임팩트가 달랐기 때문이다. 이 몇 가지 장치들이 간결하지만 많은 의미를 주기도 하고 주장에 대한 신뢰를 주기도 했다.

그래서 요즘은 이전에 읽었던 책들을 언어적인 측면에서 다시 보고 있다. 이전에 나는 대부분 책을 목차대로 읽어본 적이 없다. 필요한 부분을 그때그때 읽었지만, 이제는 목차 순서대로 읽으며 빈틈을 보완해야 할 때인 것 같다.

후배 개발자들과 만나면서 많은 생각을 하는 시기이다. 운이 좋게 내가 만난 후배 개발자들은 과거의 나보다 훨씬 뛰어나다. 그래서 오히려 내가 배우는 일이 많다. 내가 아주 작게 피드백을 주어도 확실한 결과로 응답을 주는 친구들과 함께하고 있다. 함께 성장할 수 있음에 감사하고 있다.

2. 외부활동

2-1. 발표

스프링 캠프 2019

테스트를 주제로 발표하였다. 국내 자바 진영에서도 테스트에 대한 세미나가 하나 있으면 좋겠다고 생각했었는데 좋은 기회가 와 발표를 할 수 있었다. 발표의 제목 그대로 우리가 무엇을 테스트해야 하는지, 어떻게 테스트할 것인지에 집중하여 지속 가능한 테스트를 작성하도록 안내하기 위한 발표이다. 코드리뷰할 때 첨부할 수 있을만한 자료가 생겼다는 점에서 만족하는 발표이다. (물론 이제와서 다시 보니 보완해야할 점도 많이 보인다.)

우아한 테크 세미나

기술 블로그에 작성하였던 내용이 좋은 반응을 얻어 발표로까지 이어졌다. 의존 관계라는 측면에서 접근하여, 컴파일 레벨에서 안전하고 올바른 의존 관계를 만들기 위한 고민을 발표로 옮겼다. 잘 정돈된 내용이기보다는 시도라는 측면에서 글을 작성하였는데 좋은 반응을 얻었다. 현재는 당시 발표하였던 것보다 더 발전된 결과물을 얻었다. 조만간 업데이트 해야할 것 같다.

토비의 봄 TV 스페셜

유투브에 출연하기도 했다. 스프링 캠프에서 발표하였던 내용을 발표해줄 것을 요청받고 토비님께서 재직 중이었던 회사에 방문하였다가 과장없이 반 강제적으로 방송실로 들어가게 되었고, 방송을 찍게 되었다. 매우 많이 떨리기도 했지만 신기하고 재밌던 경험이다. 집에 와서 영상을 확인하는데 내 얼굴은 크게 나오는데 토비님 얼굴은 작게 나오도록 잡혀있는 구도를 보고 영상을 다시 보지 않았다.

우아한테크의 밤

동욱님(JOJOLDU) 과 패널 토크에 참여했다. 여러 질문에 대한 Q&A 방식으로 진행되었는데 동욱님이 말을 너무 잘해서 상대적으로 비교가 된 것 같다. 준비된 Q&A 방식이라 크게 부담이 없었고, 같은 길을 다른 방법으로 걸어온 동욱님과 할 수 있어서 더욱 즐거웠고 많이 배울 수 있는 시간이었다.

이후로 2019년에 너무 많이 에너지를 쏟아서 일부러 2020년에는 아무런 활동도 하지 않았다. 나는 게을러서 스스로를 고통 속으로 넣어야 움직이는 타입이다. 그동안의 활동이 고통스러웠지만 스스로를 밀어 넣었었다. 그래서 그런지 많이 지치기도 한다. 2019년에는 생각 이상으로 이런 시간이 많아 지쳤고 2020년에는 아무런 도전도 하지 않았다. 1년을 쉬었으니 이제 다시 무언가를 시작해보아야겠다.

2-2. 리뷰어 활동

우아한 테크코스 1기와 2기의 리뷰어 활동을 했다. 존경하는 박재성 교수님께서 추진하시는 교육이기에 리뷰어 활동을 제안해주셨을 때 고민하지 않고 수락했다. 이제와서는 조금 더 신중하게 고민을 해야 했지 않았나 생각을 하고 있다.

테크코스 교육을 마친 분 중 두 분은 현재 같은 팀에서 일하고 있고 신입이라고는 믿기 힘들 정도로 정말 잘 해주시고 계신다. 잘 키워 보내준 코치들에게 감사와 존경을 표한다. 직접적인 교육에 참여하지는 않았지만, 구성원들이 성장해가는 걸 보면서 커다란 보람을 느꼈고 함께 일하면서 다시 한번 만족하고 있다.

그러나 리뷰어를 하는 과정은 정말 어려웠다.

• 개발 초심자들을 리뷰한다는 것에 대한 책임감은 막대하다. 학생들의 소중한 시간을 양질의 리뷰로 지원해야 하는데 시간적인 이유로 이걸 제대로 하지 못하는 일이 생겼을 때 생각이 복잡해진다.
• 요구사항과 교육의 방향을 함께 이해해야 한다. 때로는 교육에서 제시하는 방향이 내가 추구하는 방향과 맞지 않을 수도 있다. 리뷰이에게 혼란을 주지 않도록 나 역시 교육의 방향과 요구사항을 최대한 이해할 필요가 있다.
• 컨벤션만 잡는 거면 정적분석으로 자동화할 수 있다. 그러나 리뷰어가 해야 할 일은 컨벤션만 잡는 게 아니고 올바른 개발을 할 수 있는 시야를 제시해야 한다. 대부분의 커다란 사상이나 이론은 이해를 돕기 위한 많은 설명이 필요하다. 그래서 참고할만한 책이나 블로그를 찾아보아야 한다. 그리고 그런 참고자료가 없다면 내가 제시해야 한다. 그리고 이것을 각 리뷰이가 처한 상황에 맞게 제시해야 한다.

2기 과정의 리뷰가 곧 마무리된다. 제안을 해주어야 할 수 있지만, 제안이 오더라도 미안함과 부족한 느낌이 남아있는 상황이라 다음 리뷰어 활동을 할 수 있을지는 아직은 모르겠다.

힘들긴 했지만 배울 수 있었고 보람 있고 재미있는 경험이었다.

3. 코딩덕후(co-duck.com)

코딩덕후를 운영한지 2년을 넘어 25번째 시즌을 진행하고 있다.

코덕은 여전히 좋은 토이 프로젝트로서 나에게 새로운 경험들을 주고 있다.

3-1. 1주년

코덕 1주년을 기념하여 2019년 연말정산 글을 작성하여 코덕이 어떻게 운영되고 있는지를 기록했고, 1주년 기념 스티커를 배포했다. 생각보다 많은 분이 스티커를 신청해주어 신기하기도 했다.

스티커를 제작하는 게 그렇게 비용이 드는 일인지 몰랐다. 그동안 세미나를 다니며 별 생각 없이 수집했던 그 스티커들이 새롭게 느껴졌다. 비용을 최대한 줄이기 위해 구성원들과 스티커 재단을 가위로 직접하고 하나하나 우편봉투에 담고 하나하나 주소를 출력하여 발송했다. 당시에는 이게 뭔 짓인가 생각했지만 그래도 추억에는 오래 남을 것 같다.

3-2. 기획

구성원들에게 일을 위임하고자 기획서도 작성해보았다. 할 줄 아는 것이라고는 PPT 밖에 없어서 한땀한땀 PPT 로 작성했다. 그렇게 완성된 기획서를 구성원들에게 전달했는데 대부분 이해를 못 했다.

이해를 시키는 데에 상당히 오랜 시간이 걸렸다. 그리고 '이 정도는 개발하면서 챙기겠지' 하면서 넘겼던 부분들이 많았는데 하나도 챙겨지지 않았다. 돌이켜 지금 일하고 있는 기획자분들의 기획서를 다시 생각해보니 정말 많은 생각으로 작성되고 있다는 것을 깨달았다. 기획하시는 분들에 대한 존경이 상승했다.

결국은 일부 직접 개발을 하였지만, 이렇게 얼마 전 코덕에 모임 기능이 배포되었다.

3-3. 새로운 기술

아키텍처, 디자인, 자바, 스프링 등의 측면에서도 많은 시도가 있었지만 Github Action을 도입한 것이 꽤 소득이 있었다. 

첫번째로는 젠킨스를 통해 트리깅되는 배포를 옮겼고, 두 번째로 젠킨스에서 돌아가던 배치를 모두 옮겼다. 이로써 젠킨스를 사용할 일이 없어졌고 젠킨스를 제거하며 인스턴스 1대 분량의 여유를 확보했다.

Github Action은 일정 시간 자원을 무료로 사용할 수 있게 제공하고 있다. 사용자의 활동을 수집하는 배치가 하루에 10회 이상 수행되는데 한 달로 시간을 측정해보았을 때 초과를 했다. 그래서 Spring Batch의 기존 Step에 멀티스레드를 사용하도록 Partitioner를 달았다. 수행시간이 대폭 개선되면서 꽤 여유 있는 여분시간을 남길 수 있게 되었다.

코덕이 아니였다면 이런 새로운 기술 도전이나 딥다이빙을 해볼 일이 훨씬 적었을 것이다.

3-4. 현 상황과 추후 방향

코덕은 여전히 적자 운영 중이다. 가입자 수는 얼마 전 1400명을 돌파했다. 그러나 트래픽은 아주 약간 상승한 정도이다. 이런 적자 운영이 계속될 테지만 당분간은 코덕 운영은 계속할 것이다. 코덕으로 인해 나는 작은 보람들을 얻고 있고 새로운 경험을 하고 있으니 대가로는 충분하다고 생각된다.

이대로 머무를 것은 아니다. 코덕에는 사용자를 계속 방문하도록 하는 장치가 없고 사용자를 오래 머물게 할만한 컨텐츠도 부족하다. 이런 사실을 잘 알고 있기 때문에 이번에는 트래픽을 늘리기 위한 시도를 해보려고 한다. (코덕에 녹여보고 싶은 피처들이 많다.)

그러나 인력이 많이 부족하다. 현재 3명의 서버 개발자와 1명의 프론트 개발자와 함께하고 있는데, 다들 본업에서도 바쁨에 허덕이고 있는지라 일을 진행하는 게 쉽지 않다. (이 중 두 명은 곧 결혼한다.) 그래서 스터디 겸 코덕을 운영할 모임을 만들어보려고 한다. 시국이 시국인지라 이 모임을 어떻게 운영할지 고민을 하는 중이다.

마무리

결국 난 환상 속의 시니어가 되지 못했다. 막히는 것 투성이고, 모르는 것 투성이다. 그래도 환상 속의 시니어가 되려고 노력해서 보통 5년차의 개발자 정도는 된 것 같다. 이제는 내가 미래에 되고 싶은 개발자의 모습은 환상이 아니다. 주변에 보고 배울 수 있는 선배 개발자들이 많이 생겼고, 내가 그들의 연차에 그들의 모습처럼 될 수 있을지 겁이나는 지경이다. 많이 보고 배우며 단물을 빨아 먹어야겠다.

_{내가 개발자로 밥 벌어먹고 살 수 있게 해주신 특히나 영향을 많이 준 분들께 감사인사를 하며 마무리..
실크 로드를 깔아주신 동욱님 감사합니다.
경쟁해준 홍구님 감사합니다.
개발 인생 전환점을 갖게 해주신 재성님 감사합니다.
기술을 보는 법 알려주신 태기님 감사합니다.
넓은 시야 보여주신 주현님 감사합니다.
좋은 프로젝트,코드 알게 해주신 영한님 감사합니다.}