좋은 소프트웨어 개발자란?
이번 글에서는 좋은 소프트웨어 개발자란 무엇인지에 대해 개인적으로 생각하는 바를 적어볼까 합니다.
42서울이라는 교육기관에서 1000명에 가까운 개발자들과 함께 생활하고, 현업에서 다양한 연차의 개발자들을 만나며 느낀 점들을 바탕으로 정리한 내용입니다.
좋은 개발자의 정의
제가 생각하는 좋은 개발자의 정의는 현장에서의 역량을 기반으로 합니다.
현장에서 개발자로 일하며 얼마나 가치를 만들어내는가가 중요하다고 보는데, 그 가치는 크게 문제해결력, 협업능력, 프로다운 자세에서 나온다고 생각합니다. 이 세 가지 역량이 높은 개발자가 좋은 개발자라는 것이 제 결론입니다.
문제해결력
기업이 개발자를 채용할 때 기대하는 바는 결국 "지불한 급여 이상의 부가가치를 창출해주었으면 좋겠다"일 것입니다.
그 부가가치를 구체적으로 풀어보면 다음과 같습니다.
- 기능 요구사항을 빠르고 정확하게 개발해줄 것
- 시스템에 문제가 생겼을 때 빠르고 정확하게 해결해줄 것
- 보안 사고, 데이터 유실, 시스템 장애 등 서비스에 치명적인 문제들을 사전에 예방해줄 것
- 서비스가 커질수록 기하급수적으로 늘어나는 코드 유지보수 비용의 상승폭을 둔화시켜줄 것
- 클라우드 비용 등 서비스 운영 비용을 최소화해줄 것
그렇다면 이러한 기대를 충족할 수 있는 개발자는 어떤 개발자일까요?
저는 CS(Computer Science) 지식을 바탕으로 기능 구현에 사용된 기술의 동작 원리를 이해하는 개발자라고 생각합니다.
요즘은 라이브러리와 프레임워크가 다양한 기능을 제공하고 추상화도 잘 되어 있어서, CS 지식이 부족하거나 내부 동작 원리를 모르더라도 기능자체는 얼마든지 구현할 수 있습니다.
하지만 내부 동작 파이프라인의 특정 지점에서 문제가 발생한다면 어떻게 해결할 수 있을까요?
어느 부분에서 어떤 문제가 발생했는지를 알아야 그 부분을 고쳐 해결할 수 있습니다.
그러려면 내부 동작 파이프라인 전체가 어떻게 굴러가는지 이해해야 하고, 그 과정을 이해하는 데 CS 지식이 필요한 경우도 많습니다.
코드 레벨에서 컴파일러가 알려주는 에러 메시지는 매우 친절합니다. 그래서 상대적으로 고치기 쉽습니다.
하지만 여러 서버가 함께 동작하는 기능에서는 에러 메시지가 구체적이지 않은 경우가 많습니다. 때로는 코드가 아니라 코드가 동작하는 운영체제 쪽에서 문제가 발생하기도 하고, 내가 짠 코드도 운영체제도 멀쩡한데 남이 짠 코드(라이브러리, DBMS 등)에서 문제가 터지기도 합니다. 모든 것이 정상인데 네트워크 환경에서 문제가 생기는 경우도 있습니다.
이런 상황에서 문제를 해결하려면 내가 만든 기능이 어떤 요소들로 구성되어 어떻게 동작하는지를 이해해야 하며, 그 과정에서 CS 지식이 필요한 부분에도 대응할 수 있어야 합니다.
또한 CS 지식과 내부 동작에 대한 이해가 부족한 상태로 구축된 코드와 시스템은 잠재적인 장애, 성능 이슈, 보안 이슈를 유발하기 쉽습니다. 아무리 오랜 기간 신뢰를 쌓아온 업계 최고의 서비스라도 단 한 번의 치명적인 사고로 무너질 수 있다는 점을 생각하면, 결코 가볍게 볼 수 없는 부분입니다.
협업 능력
현장에서는 대부분의 경우 혼자 일하지 않습니다. 팀 단위로 함께 개발하는 경우가 대부분인데, 여기서 중요한 것은 의사소통 비용을 낮추고, 동료의 생산성을 저하시키지 않는 것입니다.
의사소통 비용이란 일을 진행하기 위해 필요한 소통을 하는 데 드는 비용을 말합니다. 일반적으로 서로 친밀하고 이해도가 높을수록 편하고, 빠르고, 간단하면서도 정확하게 소통할 수 있어 의사소통 비용이 낮아집니다.
동료의 생산성 저하를 유발한다는 것은, 함께 일하는 동료와 사이가 좋지 않거나 상대의 기분을 상하게 만들어 업무 생산성을 떨어뜨리고 의사소통 비용을 높이는 행위를 말합니다.
아무리 본인의 생산성이 뛰어난 개발자라 하더라도, 다른 팀원들의 생산성을 크게 저하시키는 사람이라면 좋은 개발자라고 할 수 없습니다.
직업인으로서의 태도
직업인으로서의 태도란, 돈을 받고 일하는 만큼 본인의 욕심보다 회사의 방향과 이익을 우선에 두는 자세를 말합니다.
개발자라면 누구나 새로운 기술을 써보고 싶은 욕심, 더 멋진 구조로 코드를 짜보고 싶은 욕심이 있습니다. 하지만 회사의 상황과 우선순위를 고려하지 않는 행동은 조직에 손해를 끼치게 됩니다. 자신의 욕심과 조직의 방향이 충돌할 때, 후자를 택할 줄 아는 태도가 필요합니다.
또 하나 중요한 것은 예측 가능한 일정을 산정하는 능력과 그것을 지키려는 책임감입니다. 작업 요구사항이 들어왔을 때, 자신이 지킬 수 있으면서도 빠른 완수가 가능한 일정을 제시할 수 있어야 합니다. 그리고 한 번 약속한 일정은 끝까지 책임지고 지켜내려는 태도가 뒷받침되어야 합니다.
그렇다면 좋은 개발자가 되기 위해서는 어떻게 해야 할까?
좋은 개발자가 되기 위해 필요한 노력은 크게 세 가지로 정리할 수 있습니다.
첫째, 꾸준히 CS 지식을 쌓고, 개발하는 과정에서 자신이 사용한 기술의 동작 원리를 깊이 파고드는 습관을 들이는 것입니다. 당장 기능을 구현하는 데 필요하지 않더라도, 내부 원리를 이해해 두어야 언젠가 마주칠 문제를 빠르고 효과적으로 해결할 수 있습니다.
둘째, 동료들과의 의사소통 비용을 낮추기 위한 노력입니다. 동료와 친해지려는 꾸준한 시도, 그리고 동료가 어떤 사람인지 이해하려는 관심이 쌓일수록 협업은 훨씬 가벼워집니다. 더불어 조직 생활 전반에서 다른 사람의 기분을 상하게 하지 않으려는 세심함도 함께 챙겨야 합니다.
셋째, 자신이 직업인이라는 사실을 잊지 않는 것입니다. 개인의 욕심이 앞설 때마다 한 발 물러서서 회사의 방향과 이익을 먼저 살피고, 예측 가능한 일정을 약속하고, 한 번 약속한 일은 끝까지 책임지려는 자세가 필요합니다.
마치며
정리하자면, 제가 생각하는 좋은 개발자는 현장에서 실질적인 가치를 만들어내는 사람입니다. 그리고 그 가치는 결국 탄탄한 문제해결력, 원활한 협업능력, 그리고 직업인으로서의 성숙한 태도에서 나옵니다.
기술은 빠르게 변하고, 새로운 도구와 프레임워크는 끊임없이 쏟아져 나옵니다. 그 흐름 속에서도 변하지 않는 본질은, 결국 원리를 이해하는 깊이, 함께 일하는 사람들을 향한 태도, 그리고 자신이 맡은 일에 대한 책임감이라고 생각합니다.
저 역시 아직 부족함이 많지만, 이 세 방향을 잊지 않고 꾸준히 나아가려 합니다. 이 글을 읽는 분들에게도 자신만의 '좋은 개발자'를 정의해 보는 작은 계기가 되었으면 좋겠습니다.