단상 - 나는 어떤 개발자일까? 어떤 개발자가 되고 싶은걸까?

들어가는 말

기술 관련 공부하다가 어느 순간 막혀서 그냥 주절거려본다.

애초에 뻘글 쓰고 공부하려고 블로그를 만든 거니 목적에 충실하자.

 

같이 일하는(개인적으로 존경하는) 주니어 분과 술을 먹다가 이런 이야기가 나왔다. 

 

그분: '선임님은 그러면 뭐가 하고 싶으신 거예요'

나: '트러블슈팅? 개발? 운영?일까요 잘 모르겠어요 그냥 개발일 하는 걸 좋아하는 걸까요?' 

 

그 당시에는 제대로 답변하지 못했고, 그전까지는 제대로 생각해 본 적이 없던 것 같다.

'어라 잘 안돌아가네 고쳐야지' 이외에는 거창한 꿈이 있어서 꼭 무언가를 해야겠다는 점이 없었다.

 

예전에 학교 선배랑 술 마실 때도 비슷한 주제로 이야기를 했었는데

그때도 들은 말은 '너는 뭘 해도 그 안에서 재미를 찾아가는 놈인 것 같아'

 

그래서 조금 고찰해 보려고 한다.

 

나는 어떤 개발자일까?

그러면 회사에서 어떤 일들을 하는지 고찰해보자 

개발 java(20%), 유지보수 node.js(10%), 회의(10%), 트러블슈팅 및 버그 잡기(20%), 설계(10%), 고민상담 혹은 고민 털어놓기(10%), CS 대응(10%)

(10%는 그때그때 다른 것 같다, 쓰고 나니 슬프다. 나도 그냥 코딩만 하고 싶다)

 

지극히 주관적인 기준이니 나와 같이 일하는 분들이 보면 '네가 무슨 그런 일을 하냐고' 태클을 걸 지도 모르겠다.

 

속된 표현으로 이 분야 저 분야 '잡다하게 굴러먹다' 보니 '프로그래머'라고 표현하기는 아쉽고 '개발 좋아하는 개발일 하는 회사원'이라는 표현이 적합할 것 같다. 

 

학부 때는 토이 프로젝트로 앱 만들어보고

초년생 때에는 제조업체에서 안드로이드 개발하고(사실 개발하는 시간보다, 메일 쓰고 전화하고 엑셀 관리하면서 다른분들을 닥달하는 역할이었다.),

어릴 때 IT업체로 넘어와서 제로베이스에서 기획서 기반으로 웹 백엔드, 웹 프런트, API, 배치 등등으로 신규 서비스를 만들고,

그 이후로 유지 보수하고 운영하고 오픈소스 컴포넌트들로 구성된 플랫폼? 서비스? 상품?을 담당하고 있다.

(담당한 지 3년 정도 되었지만 담당하는 10살 가까이 되는 이 아이의 정체를 아직도 모르겠다....)

(당연하지만 이런 나를 풀 스택 개발자라고 부르지는 않는다. 데브옵스도 이런 걸 말하는 게 아니다.)

 

다만 내용물은 거시기하다.

초년생 때는 TD에 올라오는 QA 분석하고, 담당자 찾아서 할당하고, 아주 가끔 코드 수정하고

어릴 때는 개발하고, 성능 테스트하고, 개선하고, 장애 대응하고 (당연히 혼자 다 한건 아니다. 같이 했다.)

지금은 개발하고, 유지 보수하고, 장애 대응하고, 트러블 슈팅하고 (이건 일정기간은 혼자 했다... 솔직히 힘들었다.)

 

어느새 사회생활을 한 지 10년 가까이 되어 간다.

일이 힘들던 더럽던, 그 안에서 재미를 찾아가며, 모르는 게 있다는 걸 즐기며, 그래도 최소 1인분은 해야지... 하며 시간을 채워왔다.

(재미있는 건 맞는데, 잘하는 건지는 의문이다. 내 코드는 시간이 지나고 다시 보면 마음에 안 든다.)

 

지금까지의 시간이 무의미하진 않았다.

코드나 구조에서 문제가 될 부분은 얼추 보이고(많이 저지르고, 당해봤으니 배운 게 없으면 사람이 아니다), 스케일아웃은 어떻게 해야 할지, 기술 부채를 쌓으면서 달릴 때와, 밀린 숙제를 해결해야 할 때, 지속 가능한 아키텍처에 대한 고민, 문제 터지면 어떤 방법으로 접근해야 할지, 문제 터지기 전에 뭐를 감시할지 등등 많이도 배웠다.

 

신규 프로젝트로 지금은 레거시가 된 프로젝트도 해보고, 이미 레거시가 된 프로젝트를 받아서 유지 보수하다 보니,

최소한 미래에 나의 결과물을 보는 분으로부터 쌍욕을 먹지 않으려면, 어떻게 해야 할지 조금은 감이 온다.

(생각보다 내 코드 무지무지 생명줄이 길더라....)

 

아쉬운 점...?

언제나 바빴다. 바쁜 척 한걸 지도 모르겠다.

부족한 내 하드스킬을 소프트스킬로 커버한걸지도 모르겠다.

 

작업을 마치거나, 문제를 해결하면 문서화해놓고 난 뒤 관심에서 멀어졌다.

(핑계: 왜냐면 할 일은 언제나 쌓여있고, 언제나 사람은 부족했으니까)

 

일할 때에도 딱 필요한 정도로 필요한 만큼만 봤었다.

목표는 '최소한 1인분'이었다.

(돈 받고 하는 건데, 돈 받는 만큼은 해야 하지 않나, 그리고 같이 일하는 동료들을 서포트해주지는 못할망정 민폐를 끼칠 수는 없다.)

이 분야가 재미있는 건 맞는데, 개인 시간은 소중했다.

(도서관 가서 인문학 책 봐야 한다...)

 

근본이 없다.

아쉽다.

 

뭐가 부족하다고 느끼는 걸까

오늘 굉장히 재미있는 글을 보았다. 

사실은 이 뻘글을 쓰려고 마음먹은 이유이기도 하다.

 

개발에도 매크로와 마이크로가 있고, 둘 다 병행 진행한다면 더 크게 성장할 수 있을 거라고 한다.

매크로는 프로그래밍 패러다임, 디자인 패턴, 아키텍처, 개발 방법론, 개발 문화 등 거시

마이크로는 CS기본, 알고리즘, OS 모델, 퍼포먼스 관련 지식, jvm 스펙, 프레임워크, 라이브러리 소스 분석 등 미시

 

내가 잘하는 분야는 나는 못 느끼고 아쉬운 것만 보였다.

(솔직히 잘하는지는 모르겠다, 좋은 분들이 좋게 봐주시니 감사하게 그런가 보다 한다.)

 

내가 느낀 아쉬운 점은 깊이가 부족했다.

 

CS기본은 학부 때 지식들이 아직 유효기간이 남아있어서 그걸로 버틴 것 같다.

 

퍼포먼스는 모르겠다. 그냥 성능 측정 잘하고, 병목 잘 찾고, 타임아웃 잘 관리하고, 스케일 아웃으로 가능한 부분은 스케일 아웃하고, 안 되는 부분들은 개선하고, 캐싱할 수 있는 건 1차던 2차던 캐싱하고 뭐 그러면 될 것 같기도 같은데... 해본 게 그 정도 수준으로 해결되는 문제들이라서 그런 거겠지

 

예를 들면 kafka, es에 매우 의존하고 있지만, 어떻게 동작하는지는 책 보고, 장애 대응하고, 사용하면서 경험에 근거한 배움이고 주도적으로는 아닌 것 같다. (logstash는 필요해서 까 봤으니, 쟤네들도 필요하면 파보게 되는 걸까?)

물론 그 아이들이 어떤 철학을 갖고, 어떤 문제를 해결하려는지는 알고 있다.(고 착각하는 걸지도)

 

redis 도 쓴 지 오래된 것 같은데 사용하고, 구축하고, 운영할 줄만 알았지 싱글 스레드 이벤트 루프로 돈다는 건 몇 주 전에 아티클 보다가 알았다.

 

이런 쪽에 아쉬움을 느끼고 필요하다고 느끼니 마이크로 쪽에도 집중해야겠다.

언제는 뭐 알고 해 봤나 하다 보니 재미있고, 재미있으니까 더 하고 그런 거지

나가는 말

본문의 전개에서는 전혀 드러내지 않았지만

내가 되고 싶은 개발자의 모습은 있다.

'같이 일하고 싶은 개발자'

 

하지만 자신에게는 만족을 못하겠다.

그게 본문의 전개였다.

 

문론 내가 나 같은 개발자랑 일하면 여러모로 편하긴 할 것 같다.

 

부족한 게 뭔지 뻔히 알고, 아쉬우면 부족한걸 채워나가자.