나약한 생각을 버리고, 어떻게하면 멋진 개발자가 될지를 고민하자

 

 

최근 특정 프로젝트에 대해 굉장히 지친 상태가 될 만큼 QA가 길어진 프로젝트가 하나 있었다.
기획은 아주 조그마했지만, 그 기획에 엉켜있던 지금까지의 많은 컨텍스트와 기술 부채들이 걸림돌이 되었던 것이다.

분명 내가 했던 것들도 아닌데...과거의 개발자들과 기획자들이 지금 당장의 빠른 임팩트를 내어보기 위해 나중의 후폭풍은 생각하지 않고 우선 지금 당장의 문제를 해결할 수 있는 방식을 택하다보니 발생한 결과들이었다.

어떻게든 닥친 문제를 해결할 수 있는 역량 자체도 어쩌면 좋은 것이지만, 장기간 해당 코드의 유지보수를 생각하는 부분이 정말 중요한 것 같다는 생각이 들어, 최근에 코어그룹 엔지니어들에게 "나중의 문제가 발생하지 않는 방식의 코드를 생각하는 관점을 가지자"는 얘기를 한 적도 있었다.

그래서 그런지 요즘 코드를 구현할 때, 나중의 내가 혹은 누군가가 현재 작성하는 코드 부분을 들여다봤을 때 의도를 알 수 있도록, 그리고 나중에 문제가 발생할 것 같은 부분들을 계속 생각하면서 구현하게 되는 습관이 들이려고 하다보니 확실히 코드의 일관성도 잡히는 것 같고 코드에 주석을 상세하게 남기는 것도 습관화가 된 것 깉다.

 

내가 쓰는 주석은, 무엇을 어떻게 구현한 코드인지 설명하는 주석이 아니라, 왜 이렇게 구현할 수 밖에 없었는지 배경 설명이 필요한 주석이다. 가끔 컨퍼런스 같은 곳 가면 '본인들은 주석을 다는 것을 싫어한다. 코드로 대화하면 되지 않냐' 라고 말하는데, 넓고 깊은 서비스를 개발해 보지 않은 주니어 개발자들이 겉멋만 들어서 하는 말로 밖에 보이지 않는다. 

그 넓은 비즈니스 컨텍스트와 깊은 기술적인 부분들을 어떻게 코드로 설명할 것인가? 컨텍스트 배경이 필요할 때마다 관련 엔지니어나 PM을 찾을 것이 아니라면, 그리고 1,2년만에 들여다본 본인의 코드를 누군가가 봤을 때 정말 100% 의도를 이해시킬 수 있다는 자신감이 있는게 아니라면 주석을 아낌없이 작성해야만 한다. 그 코드를 바라볼 미래의 나 혹은 누군가에게 감사함을 얻게 될 것이다. 

 

그러다가 오늘 문득 House Keeping 기간이 필요할 것 같다는 생각이 들었다.
올해 초부터 지금까지 급급한 프로젝트 일정으로 진행하다보니 기술 부채들이 쌓인 것도 있었고, 앞으로도 이러한 작은 기획 하나에 오랜 기간 얽매이지 않으려면 기술적 재정비 기간이 필요할 것 같다는 생각이 들었다.

그래서 그룹 채널에 공개적으로 현재 진행 중인 큰 프로젝트 하나가 끝나면 일주일의 House Keeping 기간을 고려해 달라는 장문의 글을 작성했다. 왜 기간이 왜 필요한지, 이 기간을 어떻게 사용할 것이고 지금까지 이러한 기간이 없음으로써 어떤 문제가 있었으며 앞으로 이러한 일이 발생하지 않도록 하기 위해 필요하다는 논리적인 글로 채워 작성을 했다.

그리고 답변을 기다리는 중, 다른 채널을 둘러보다가 문득 우리 사내 CTO께서 "Claude를 이용한 AI 동영상 풀이 제작" 이라는 멋진 기술을 만들어 내서 비즈니스 적으로 굉장히 도움이 될 만한 기술을 공유한 것을 보게 되었다.

그 쓰레드를 보면서 놀라면서도, 문득 오늘 내가 코어그룹 채널에 작성했던 글이 생각났다.

어쩌면 내가 되어야 하는 모습은 CTO와 같은 그런 모습이고, 회사에 비즈니스적으로 도움이 되는 사람이 되어야 하는데, 나는 오히려 겨우 홈페이지 작업 하나 하면서 본인 일이 힘들다며 본인을 달랠 수 있는 시간을 달라고 떼를 쓴 사람이 된 것 같았다. 너무 창피했다.

그래서 이미 많은 사람들이 봐버렸고 너무 늦었지만, 늦게라도 그 글을 지우고 반성했다.

CTO와 같은 역량을 가지려면, 그리고 정말 회사에 필요한 인재가 되려면 "비즈니스에 도움이 되는 기술을 연구하고 선보이는 사람, 그리고 기술로 내가 소속한 회사와 서비스에 기여를 하는 사람"이 되어야 겠다는 생각을 했다.

안그래도 빠르게 움직여야 하는 시기에..., 개발이 힘들다고 재정비 시간을 달라며 투덜대는 개발자가 아니라!!