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

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

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

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

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

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

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

 

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

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

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

 

다양한 이해도

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

 

백엔드 관점

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

 

프론트 엔드 관점

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

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