개발자로 크게 성장한 계기와 노력

<code class="language-plaintext" style="border-radius:0px;border:0px solid var(--chakra-colors-gray-200);box-sizing:border-box;color:rgb(80, 88, 96);font-family:SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace;font-size:16px;font-weight:400;overflow-wrap:break-word;padding:0px;">📌 글 작성

성장에 관심이 많은 F-Lab 백앤드 멘토 Elkein
스타트업 여럿과 NHN, 넷마블, 크래프톤 등을 거쳤으며
게임 산업, 클라우드 플랫폼 개발, 웹 개발 등을 두루 경험한 19년 차 엔지니어

개요

개발자라는 직업이 핫해질 줄 몰랐던 시기였지만, 나는 내 직업에 진심이었고, 잘하고 싶었다. 지금은 개발자라는 직업이 좀 더 각광받는 직업이지만, 그렇지 않던 시기에도 개발자라는 직업을 가졌을 때 갖춰야 할 소양이나, 역량은 일정 수준 이상의 요구치가 있었다.

이를 가르쳐 주거나, 알려주는 사람이 전무했던 나는 대부분의 조언을 책을 통해 얻게 됐는데, 책에서 읽거나, 실제 일하면서 느낀 과정 등을 통해서 내가 성장하는 데에 도움이 됐던 노력에 대해서 언급해 보고자 한다.

여가 시간의 활용

개발자로서의 경쟁력을 업무 시간의 노력만으로 달성하기란 쉽지 않다.

그래서 업무 외적인 여가 시간의 일부를 다양한 관점에서의 성장을 노력했다.

지속가능한 개발자 성장 스킬 5가지 (f-lab.kr)

자세한 내용은 위 글을 참고하면 좋을 것 같다.

Dev Toy

새로운 시도

취미로 개발하면서 더 많은 성장 동력을 얻을 수 있다.

회사의 상황에 따라 다르지만, 대부분의 경우 개인의 지적 호기심을 회사에서 풀어내기란 쉽지 않다.

또한 프로젝트에 상황에 따라서 Stable함을 지향해야 되는 경우도 있기에 더더욱 개인 프로젝트를 통해서 발전해야 될 때가 많다. 나는 꾸준히 다양한 Dev Toy를 진행하는데, 목적을 뚜렷이 하면 할수록 더 진행이 잘 됐다.

목적

• 새로운 기술 습득
• 원리 이해
• 내가 직접 쓸 제품
• 서비스할 제품
• 포트폴리오

업무 역량 발전

업무적으로 부족한 역량도 Dev Toy로 끌어올릴 수 있는 경우가 많다. 익숙해져야 하는 기술을 기반으로 한 간단한 기능의 앱을 만들어보는 것만으로도 많은 부분에서 이해도가 올라올 수 있다는 것을 알게 됐다. 특히 이미 구축되어 있는 구조 내에서 하는 작업과, 처음부터 빌드업하는 과정은 다른 경험이기에 이러한 부분에서 얻는 인사이트가 도움이 될 수 있었다.

문제 해결사

개발자라는 직업을 어떻게 규정짓는가 역시 개발자로써 성장하는 데에 큰 도움이 됐다. 내가 주니어일 때, IT 서적 전문 서점 강컴이 있었다. (지금은 사라졌다) 해당 서점에서 개발자 필독서로 세일즈 됐던 서적 중에서,대체 뭐가 문제야 | 제럴드 M. 와인버그 - 교보문고 (kyobobook.co.kr)라는 책이 있다.

이 책의 메시지는 문제의 본질, 해결 방법에 유연함을 깨닫는 데에 도움을 주는 책인데, 개발자가 문제 해결사 관점으로 접근했을 때 좀 더 고차원적인 개발자가 될 수 있다는 것을 알게 해준 좋은 책이었다.

지금도 개발자의 포지션을 코딩으로 한정 짓는 사람과 아닌 사람은 시간이 갈수록 크게 다른 결과를 보여줬다.

개발자는 코드만 작성하는 사람이 아니다.

개발자의 포지션을 코딩으로 한정 짓는 경우에는, 기획서, 디자인, 구현 방식, 어쩌면 세부적인 코딩 방식까지 모든 것을 동료나 리더가 정해준 작업만 하려고 하는 경우가 많다. 이러한 성향의 개발자는, 서비스가 구현되고 운용하는 경험까지 순환되는 전반적인 제품의 퍼포먼스를 낮추게 된다.

즉 같은 시간 대비 더 작은 경험을 하게 되고, 그 경험마저 다른 사람이 판단하고 결정지은 내용을 실행에 옮길 뿐이라서, 그 체감과 회고가 어려운 문제도 생기게 된다.

문제 해결을 즐기다 보면, 더 많은 것을 경험하게 된다.

또한 장애나 이슈 해결을 즐기기보다는, 개발을 방해하는 요소로 생각하는 개발자들도 종종 만나게 되는데, 개발은 구현이 끝이 아니다. 많은 조건이 붙어야만 잘 동작하는 코드, 약속된 상황에서 하나라도 어긋나면 이상 동작을 보이는 코드는 좋은 결과물이 아니다.

또한 내가 내지 않은 문제라고 해도, 문제의 원인을 파악하고, 해결하고, 재발방지를 하는 경험은 동일한 실수를 반복하지 않기 위해서도, 새로 개발할 때의 고민 포인트 관점에서도 아주 유의미한 경험이다. 문제를 경험했다면, 성장할 기회를 맞이했다고 생각하는 태도가 개발자 개인의 성장 관점에서 크게 도움이 되는데, 이러한 마인드를 가지는 데에 <대체 뭐가 문제야>가 큰 도움이 됐다.

다양한 이해도

많은 개발자가 백엔드, 프론트엔드라는 파트에 한정지어서 접근하는 경우가 많다. 사실 좋은 개발 결과물을 위해선 협업하는 파트에 대한 일정 수준 이상의 이해도가 필요하다. 가능하다면 급할 때나, 간단한 작업을 수정하거나, 이슈 대응, 버그 수정 등은 가능한 수준까지 이해도가 있으면 더 좋다.

백엔드 관점

• 프론트 엔드가 어떤 식으로 API Request, Response DTO, 예외 응답, API의 단위가 작성되면 좋은지 이해하려면, 직접 프론트엔드 개발을 해보면 좋다.
• Admin Web은 백엔드에서 개발하는 경우도 많은데 이러한 부분에서 장점이 될 수 있다.

프론트 엔드 관점

• 백엔드에서 왜 자원단위 코딩에 집착하는지, 특수화된 API를 만드는 것을 좋아하지 않는 이유
• 데이터를 어디서 정렬하는 것이 좋은지
  • 서버에서 처리하는 것이 항상 좋지만은 않다.
• 캐싱이 어느 지점에서 되는 게 효율적인지

다양한 범위를 넘나드는 개발자가 되었을 때 시야도, 판단력이 좋아져서, 좋은 결정으로 이어지는 경험을 여럿 하게 됐다. 대략 이해하고 있는 것을 넘어서, 직접 해보면 꽤 차이가 나는 것들이 있고, 이를 통해 성장할 때도 꽤 많았기에, 변화하는 기술 스택을 따라가는 것, 다른 파트의 개발을 따라가는 것은 성장에 큰 도움이 됐다.

가져다 쓰면서도, 이해하고 쓰기

위에서는 다양한 분야에 대해 이해해야 된다고 했는데, 또 한편으로는 깊이 있는 접근이 큰 도움이 된다.

많은 회사들이 채용 과정에서 컴퓨터 과학 기초의 중요성에 대해서 설파한다. 현대 개발은 프레임워크와 좋은 패키지가 많아서, 잘 가져다가 쓰기만 해도 서버도, 앱도 쉽게 만들 수 있다.

하지만, 이슈를 겪고 해결하는 과정에서는 깊이 있는 이해가 매우 중요하다. 잘 만든 걸로 알려진 수많은 프레임워크나 패키지는 이슈가 생겼을 때 명확하게 어떤 이슈고 어떻게 해결해야 하는지 알려주지 않는다. (그렇게 만들기 어렵기도 하다) 그렇다 보니, 가져다 쓰더라도 그 원리를 이해하고, 흔적들과 근거들을 바탕으로 추론하고, 증명해야 한다. 그러한 증명이 가능한 대다수의 사람은 프레임워크를 활용하는 것이지, 끌려가지 않는다.

실용주의 프로그래머(20주년 기념판) | 데이비드 토머스 - 교보문고 (kyobobook.co.kr)

개발자 필독서로 꼽히는 실용주의 프로그래머에서도 우연에 맡기는 프로그래밍이라는 항목이 있는데, 원리를 이해하지 못하고 사용한다면 우연에 맡기는 프로그래밍이나 다름없다고 볼 수 있다. 효율적이기 위해 잘 가져다가 쓰지만, 시간이 주어지면 얼마든지 같은 패키지나 프레임워크를 만들 수 있고, 그 원리를 명확히 이해하고 쓰는 능력을 가져야만 기술에 끌려가지 않을 수 있음을 많은 장애와 이슈들에서 배웠다.

프로덕트 위주의 마인드

나는 바퀴를 만들어 쓰던 시기부터 시작한 개발자다. 그 시기에도 제품을 만들었지만, 제품을 만들기 전 일정 기간을 바퀴를 만드는 일정이 주어지고, 실제 바퀴를 만든 일이 많았다. 물론 C++이라는 언어를 썼던 당시 환경도 영향이 있었고, maven, npm, nuget등의 패키지 저장소에 충분한 바퀴가 공유되지 않기 때문이기도 하지만, 바퀴를 만드는 일이 익숙해져버렸던 시기가 있었다.

바퀴를 만들다 보면, 자연스레 동작 원리를 직접 구현하고, 자신이 만든 프레임워크나 패키지의 이슈를 직접 해결하게 되다 보니 생산성은 낮아져도 높은 이해도는 가지게 된다. 이에 지나치게 빠져서, 원리를 이해하는 방식으로 개발해야만 한다고 생각한 시기도 꽤 길었다. 오픈 소스의 시대가 왔음을 느끼고 이를 잘 활용하고, 원리를 이해하고 사용하는 선에서 균형 잡힌 마인드를 가져야 함을 깨닫고 나서 전반적인 개발 효율이 좋아져, 같은 시간에 더 많은 경험을 쌓을 수 있었다.

나처럼 오래된 개발자만 이런 줄 알았는데, 의외로 많은 주니어 개발자들도 프로덕트 지향적인 마인드보다, 기술에 집착하는 경우가 많기에 언급했는데, 기술 지향적인 접근이나 성향 자체가 나쁘다기보다는 균형 잡힌 시선과 생각을 가지는 것이 중요하다고 생각한다.

마치며

사실 좋은 개발자가 되기 위해서는, 더 많이 성장하기 위해서는 시간을 많이 부어야 하는 면이 존재한다.

그럼에도 깨달음을 얻고, 마인드가 바뀌어야 하는 부분도 많았다. 그렇게 마인드가 바뀌고, 받아들이고 생각하는 것이 달라질 때마다 많이, 계속 성장할 수 있는 계기이자 동력이 되었다.

이러한 생각과 변화에는 좋은 동료들과의 대화나 협업도 도움이 됐지만, 관성적으로 하고 있는 일을 되돌이켜 볼 때 많은 계기가 되었다. 매너리즘에 빠질 때마다 다양한 고민과 고찰로 더 큰 성장을 하는 계기를 얻길 바란다.