어쭙잖은 프로그래머로 산다는 것

가끔 그런 생각을 하곤 한다.
나에게는 어떤 유능한 도구를 만들거나, 프레임워크를 만들거나 하는 어떤 경험은 해본 적이 없다 보니 나에겐 선망의 대상.

굉장히 어려운 영역에 있다고 생각한다.

내가 하는 개발은 서비스 영역이라, 다른 부분들도 어렵지만, 특히 코드의 퀄리티 혹은 추상화에 대한 부분은 늘 어렵다.

이 업계에 몸 담은지도 그래도 좀 시간이 흘렀음에도 내가 느끼는 것은 더 나은 개발자가 되는 것은 무엇일까?

그리고, 프로그래머로 산다는 것은 무엇일까?
어쩌면, 누군가에게는 이 일이 그저 적절하게 사는데 필요로한 경제활동의 영위 정도 일 수도 있고,
누군가에게는 꿈을 펼칠 수 있는 어떤 발판이 될 수도 있고,
또 다른 누군가에게는 이 일을 하는 사람들에게 도움이 되는 것들을 만들어 가는 데 뜻이 있고 능력이 있을 수 있다.

유튜브 개발 관련 영상을 보다 보면, 급이 낮은 프로그래머와 높은 프로그래머를 나누는데는 여러 가지가 있다고 한다.
하드웨어부터 수학등 뭐 굳이 필요한 것은 아니지만, 있다면 더 좋은 프로그래머가 되는 틀림 없는 것은 분명하다.

그렇다고, 어중간한 프로그래머는 필요 없는 것일까?
실력의 급을 명확하게 가를 수 있을까? 어떻게 보면 프로그래머의 영역도 결국 경험의 차이인 것이고, 내가 경험하지 못했던 부분은 나에게 생소하다.

내가 해보지 않았다고 내가 못한 사람인가? (물론, 못할 수도 있지.)
그런데, 늘 유능한 프로그래머만이 팀에 있는게 중요한 포인트는 아니라고 생각한다.

프로그래머든 아니든 어떤 협업의 주체에서 일을 해야 하는 관계는 나 혼자만 잘한다고 잘 되는 것은 아니다. 고로, 내가 무언가 부족한 부분이 있더라도 괜찮다.

결국, 이 업계에서 오래 있으면서 여러가지 변화를 체득하고, 나만의 언어로 기술을 표현할 줄 아면 되지 않을까?

유퀴즈를 보다가 무릎을 치게 되었는데, 그게 바로 어느 기업의 부사장까지 올라갔다가 책방 주인이 되신 분의 이야기였는데, 굉장히 공감했다.
https://youtu.be/kB2puzk_IfQ

https://youtu.be/p-Kzlcff6sI

그리고, 생각 외로 반성도 많이 하게 되었다.
나는 늘, 감정을 잘 드러내는 팀원이었고, 사람이었다. 지난 몇 년을 돌아보더라도, 나는 누군가 나에게 도발을 취하면 나도 도발하며 맞대응하는 전략의 화법이나, 감정을 짜냈고 늘 경계하며 살았다.

그리고 그 감정이 무엇일까? 돌아봤는데, 내가 지닌 어떤 엔지니어로써의 능력이 굉장히 높지 않음에 대해 들킬까 하는 마음이 아녔을까? 늘, 이렇게 방향을 정해야 될까? 몇 년 차인데, 이 정도 시간 안에는 어느 수준의 코드 퀄리티는 내놓아야 하지 않을까?

조마조마했다. 늘 그랬다. 막연한 불안함을 지니고 일하다 보니, 늘 마음 한구석에는 더 잘하고 싶은 욕구가 있었다.

그러다 어느 순간 조금씩 내려놓고, 팀 스포츠라는 부분을 받아들이고 이해했다.

처음에는 유능한 개발자는 아니더라도 그래도 어느 정도 족적을 남길 수 있는 엔지니어가 되어야지! 마음먹곤 했다. 그런데, 그렇게 마음을 먹으니, 코드를 더 좋게 작성할 수 없다. "더 좋게"는 물론 상대적이지만, 내 나름의 상대적인 코드 퀄리티로 치자면 그렇다.

가끔 왜 이렇게 해놨을까? 이해가 안 되며, 이 정도로 이 업계에서 계속 일 할 수 있을까? 계속 나를 의심했던 것 같다. 어떤 코드의 자존감으로 치자면, 굉장히 낮은 거겠지?

늘 최선의 코드였지만, 뒤돌아 보면 아쉬운 코드들, 나의 흔적들은 다른 이들이 보더라도 이해하기 쉬운, 고치기 쉬운 코드 그리고 효율적이면 좋겠다는 염원을 늘 가지고 있음에도 포기가 안됐던 나날들이 되려 족쇄였고, 더 많은 버그를 만들어 냈다.

시간이 지나니, 팀 스포츠를 깨닫고 나니 내가 잘할 수 있는 영역에 최선을 다 하자. 남들이 빼먹은 부분을 내가 보완하자. 혹은 내가 빼먹은 부분은 누군가 날 보완해주겠지?라는 생각을 했다.

결국, 코드의 퀄리티 또한 팀 스포츠였고, 팀의 커뮤니케이션 레벨이 책임 진다.

프로덕트의 스펙들을 얼마나 이해하고, 얼마나 많은 방향들을 점검해봤는지? 에 대한 팀원들 간의 스포츠 게임이다. 스펙에 대한 이해도에 따른 높낮이가 평평하지 않고 굴곡진다면, 분명 버그를 만들어 낼 수밖에 없다.

내가 이해하는 바와 다른 이가 이해하는 바가 알맞은 정도여야 좋은 코드가 서비스에 포함된다. 그리고 좋은 업무 프로세스가 정착된다.

늘 나 자신의 능력을 의심하는 것보다 내가 다른 사람들을 보완할 수 있는 부분이 무엇일지? 관점을 옮기는 게 오히려 나에게도 더 큰 배움의 기회가 된다.

다른 사람과 이야기를 많이 해보는 게 결국 중요하다. 물론, 그게 틀린 설계, 잘못된 코드일지라도 정답으로 가는 길에 있는 아주 작은 점들이 될 것이므로 이야기를 많이 해나가는 조직이 유리하다.

고로, 프로그래머로 산다는 것은 태도가 중요하고, 마음 가짐이 결국 말에 담기고, 그 말들이 모여서 좋은 시너지를 만들고, 시너지가 모여 좋은 서비스, 사용자에게 닿아 있는 서비스가 된다고 생각했다.