어느덧 연차가 쌓여가면서 순수 주니어가 아닌 중니어적인 역할이 주어지다 보니 성장통 아닌 성장통을 겪고 있습니다. 전 아직도 개발이 즐겁습니다. 여러 팀이 하나의 프로젝트를 위해 모여, 공동의 목표를 향해 노력하며 그 결과물을 만들어내는 과정에서, 프론트엔드 개발자로서 제 역할을 수행하는 것은 정말로 보람찬 일입니다.
이런 회고를 작성하는 이유는, 나중에 제게 더 큰 책임이 주어졌을 때, 중니어가 되기 위해 겪었던 성장통과 그간 해왔던 고민을 다시 생각하고, 그 경험을 바탕으로 더 나은 개발자로 성장하여 시니어가 되기 위한 성장통을 현명하게 극복하고자 정리를 해보았습니다.
지금 이 시점에서 생각하는 좋은 개발자, 잘하는 개발자는 무엇일까요?
초기에 되고자 했던 개발자의 모습은 어떤 요구 사항을 알맞게 이해하고 빠르게 피처를 개발할 수 있는 사람이었습니다. 전달받은 기획안 안에 있는 요구사항은 모두 반영하고 정해진 스프린트 기간 안에 구현해내는 사람이었습니다. 이때는 주로 기능의 완성과 코드의 구현에 집중하여 아웃풋을 빨리 만들어 내는 것에 대하여 만족하였습니다.
아웃풋들이 서비스에 반영되기 시작하면서 사소한 버그나 이슈들은 고객들이 서비스를 판단하는 이미지를 쉽게 망가트리게 된다는 것을 알게 되었습니다. 서비스의 이미지를 좋게 만드는 방법은 어렵지만 망가트리는 일은 아주 쉽습니다. 또한 고객들의 요구사항은 천차만별로 다양하고 합리적인 요구사항은 반영이 필요했습니다. 회의를 통해 기획 문서는 다양하게 바뀌기 시작했고, 이에 대응하기 위해 개발자와 다른 팀 간의 원활한 협업, 유연하고 확장 가능한 코드 구조가 중요해졌습니다. 이제는 단순히 빠르게 개발하는 것을 넘어서 코드 가독성이 좋고 유지보수가 쉬운, 변화와 확장에 유연하게 설계 개발을 할 줄 아는 사람이 더 잘하는 개발자가 아닐까 생각하게 됩니다. 다양한 디자인 패턴의 고민과 비즈니스 로직의 분리, 응집도와 결합도에 대한 고민의 중요성을 알게 되었고, 클린 아키텍처를 고민하는 개발자가 잘하는 개발자라고 생각하게 되었습니다.
그러나 재직 중이던 회사가 어려워지자, 그 원인을 생각해보니 단순히 서비스를 만들어 내는 것을 벗어나 고객에게 공감과 가치를 주어야 서비스가 유지될 수 있다는 생각이 들었습니다. 고객들은 서비스를 코드 레벨에서 판단하지 않습니다. 서비스의 기술적 완성도만큼이나 그 서비스가 대상 고객에게 어떠한 가치를 제공하는지가 중요하다는 것입니다. 처음에는 기술적인 문제와 솔루션에만 몰두했지만, 시간이 지나면서 고객의 요구와 그들의 불편함을 해소해 주는 것이 진정한 서비스의 가치라는 것을 깨닫게 되었습니다. 그러면서 점점 피처를 개발하면서 두 가지 측면에서 고민을 하게 되었습니다.
- 스피드가 생명 (빠르게 피드백을 개선해서 적용하면 고객들이 좋아하겠지?)
- 퀄리티가 생명 (시간이 걸리더라도 고민한 설계를 통해 유연한 변화에 대응하면 고객이 좋아하겠지?)
이 두 가지 고민 사이에서 균형을 찾는 것은 매우 어렵습니다. 빠르게 개발하여 고객의 요구사항을 반영한다는 것은 빠른 피드백과 개선의 기회를 제공하지만, 그 과정에서 코드의 퀄리티와 유지보수성이 떨어질 위험이 있습니다. 반면, 퀄리티를 중시하여 철저한 코드 검토와 설계 고민을 거친다면, 배포까지의 시간이 길어져서 고객의 빠른 피드백을 받는 것이 어려워질 수 있습니다.
이러한 딜레마 속에서 프로젝트의 단기와 장기의 목표를 분명히 설정하면 결정하는데 도움이 되었습니다. 단기적으로는 고객의 급한 요구사항을 빠르게 반영하여 서비스의 경쟁력을 높이는 것이 중요하고, 장기적으로는 코드의 퀄리티와 확장성을 고려한 개발이 필요합니다. 그렇기에 1번과 2번 사이 적절한 포인트를 찾아 비즈니스 목표와 코드 퀄리티를 핸들링 할 줄 아는 사람이 잘하는 개발자라고 생각하게 됩니다.
세상에는 뛰어난 기술력을 지닌 개발자들이 많이 있습니다. 그들의 코드를 보며 감탄하는 순간도 있고, 그들이 난이도가 높은 기술적 탐구를 통해 새로운 도구나 솔루션을 개발하는 것을 보며 자신의 한계를 느끼기도 합니다. 현재 제 연차 쯤 되면 주니어 병(?)이라는 은어가 있습니다. 이는 자신이 충분한 지식과 경험을 갖추었다고 생각하면서, 시니어 개발자들의 조언을 무시하거나 구식이라고 여기는 태도를 의미합니다. 이런 태도는 팀 내에서 갈등의 원인이 될 수 있습니다. 이런 경험을 통해 깨달은 것은 기술적 능력만큼 중요한 것이 바로 '에티튜드'라는 것입니다. 에티튜드는 단순히 기술적인 능력을 넘어서, 개발자의 태도와 가치관, 그리고 그것이 팀과 조직에 어떻게 영향을 미치는지에 대한 깊은 인식을 포함합니다. "저분과 함께 팀을 이루고 싶다" 라는 말을 듣는 개발자, 그것이 바로 조직과 동료들이 찾는 이상적인 개발자의 모습이라 생각하며 회고를 마칩니다.
