22년 8월 회고

작년 11월 개발자가 된 이후로 회사에서도 많은 일들이 있었다. 투자 받은 이후 사무실을 굉장히 좋은 곳으로 옮기기도 했고, 팀 리더분이 퇴사해서 팀에 리더자리가 공석이 되었다. (지금은 임시 리더분이 계신다) 또 최근에는 조직개편이 되어서 정들었던 컨텐츠 크루를 잠시 떠나게 되었다. 뭔가 앞으로도 꽤 많은 변화가 있지 않을까 싶다.

블로그에는 기술적인 트러블 슈팅이나, 새롭게 알게 된 것들을 많이 적고 싶었는데 그러지는 못해서 아쉽다. 기대하기로는 이번 달 부터는 매월 회고록을 작성하면서 그 달의 생각과 기술적으로 새롭게 알게 된 것들을 정리해볼까 한다. 일단 계획은… 아무튼 이런 기록을 남기는 습관을 만들기 위해서 일단 지금까지의 회고를 간단하게 작성해보려고 한다. 첫 회고이니 만큼 좀 넓은 범위의 이야기를 해볼 생각이다.

제품에 애정을 갖는 것

이번에 조직개편을 하면서 새삼 놀랐던 것은 내가 만들던 제품에 얼마나 큰 애정이 있었는지 알게 되었다는 것이다. 만약 진정성 없이 그저 개발만 했었다면 동기부여도 잘 되지 않았을거고 사용자에게 어떻게 하면 더 좋은 경험을 줄 수 있을지 이렇게까지 고민해보지 못했을 것 같다. 기술적인 역량은 당연한 것이고 그걸 뛰어넘어 더 '좋은 제품을 만드는 개발자’가 되려면 진정성을 갖고 제품을 사랑하는 것이라는 것도 배울 수 있는 기회였다. 그대로 새롭게 이동한 커리어 크루에서도 잘 해보자!

누군가 짠 코드

취업 이후 가장 많이한 것은 누군가가 짠 코드를 수정하는 일이었다. 물론 새롭게 작성한 코드도 많았지만 그 와중에도 내가 작성하지 않은 코드를 수정하는 것은 불가피했다. 그러면서 솔직히 불만이 없었다면 거짓말이었을 것 같다. 입사 초반에는 대놓고 불만을 토로했는데, 지금와서는 어리석은 짓이었다고 생각한다. 이미 작성 된 코드는 이미 일어난 일이다. 그리고 그때는 그게 옳았을 수도 있고, 더 좋은 코드를 생각할 수 있는 여건이 되지 않았을 수도 있다. 지금 당장 내가 짠 코드를 봐도 못마땅한 것들이 계속 보이는데 어쩔 수 없지 않았을까… 막상 내가 '못마땅한 코드’를 짜는 당사자가 될 수도 있다고 생각하니까 간사하게도 누군가 짠 코드에 대해서 이해심을 가지려고 노력하는 모습이 웃긴다.

누군가 짠 코드를 보면서도 성장할 수 있는 방법은 두가지 정도가 있는 것 같다. 첫 번째로 왜 이렇게 짰을까? 를 생각해보면서 코드 당사자(?)의 사고를 생각해 본다. 그러다 보면, '이래서 이렇게 할 수 밖에 없었구나’를 알게 되고 그걸 넘어서 '이렇게 했다면 어땠을까?'까지 간다면 베스트다. 두 번째로는 왜 이 코드가 못마땅한지 정확하게 파악해 보는 것이다. 보통 코드가 못마땅한 건 컨벤션이나 네이밍같은 것 보다는 기능의 수정이 어렵고 이해하기 어려운 경우가 대부분이다. 결국에는 설계의 문제인 경우가 많다. 그렇다면 어떻게 했으면 좋았을까를 내가 다시 생각해보는 것이다. 여건이 된다면 직접 리팩터링도 하면 베스트다.

아무튼 앞으로도 계속해서 개발을 한다면 대부분이 누군가 짠 코드를 수정하는 일이 될 텐데 여기에 불평 불만을 갖는 건 좋을 게 전혀 없다.

앞으로

개발자로서 성장하는 건 뭘까? 예전에는 지식을 많이 쌓는 일이라고 생각했었다. 자바스크립트에 대한 동작원리나 다양한 API를 더 많이 알게 되는 것이 성장인 줄 알았는데 이건 그냥 배움인 것 같다. 미시적으로 느끼는 건 하나의 기능을 설계하더라도 축적된 경험을 통해서 다양한 케이스에 대한 대응을 할 수 있는 설계를 할 수 있는 것에 대한 중요성을 느끼고 있다. 결국 올바른 경험의 축적이 성장과 가장 가까운 정의가 아닐까 싶다. 성장과 배움은 비슷하면서도 분리되기 때문에 이 두가지를 확실히 구분해서 이끌어가는 방향으로 나아갈 생각이다. 배움 측면에서는 네트워크와 인프라에 지속적으로 관심을 가져야 할 것 같다.

앞으로는 트러블슈팅이 있을 때 마다 기록하려고 더 노력해 보려고 한다. 최근에는 window.open 메서드가 실행될 때 어떨 때 파업차단으로 처리되고 어떨 때 그냥 열리는지에 대해서 고민한 적이 있었는데 이 부분도 확실히 정리해서 포스팅 해보고 싶다.