미드레벨 개발자가 생각하는 좋은 개발자

최근에 면접을 보러 다니면서 '당신이 생각하는 좋은 개발자는 어떤 모습인가요?'라는 질문을 많이 받았다. 
사람마다 경험이나 처한 상황에 따라 느끼는 바가 차이 날 수 있는 부분이라 정답은 없는 질문이었다고 생각한다. 
7년 가까운 경력을 되짚어보면 막연하게 머리에 그려지는 좋은 개발자의 이미지는 있었지만, 다듬어진 문장으로 표현하자니 정리가 되지 않아 답변을 엉성하게 해버리고 말았다. 
수차례 같은 질문을 받으면서 내가 생각하는 좋은 개발자는 어떤 모습일까 정의를 내리고 싶어졌다. 
같이 일하는 경험이 좋았고 내게 깨달음을 주었던 좋은 개발자 분들은 어떤 강점을 가지고 있었는지, 그리고 지금의 나는 강점들 중에 어떤 것에 가치를 더 높게 매기는지 정리해 보았다.
어디까지나 개인적인 경험에서 느꼈던 점을 바탕으로 정리한 것으로 지극히 주관적인 의견임을 밝힌다.

 

내가 생각하는 좋은 개발자의 특징

 

그동안 함께 일해봤던 좋은 개발자분들을 떠올려 종합해 보니 아래와 같은 특징을 가지고 있었다.

1. 기술에 대한 탐구심이 강하다.
2. 문제를 명확하게 정의한다.
3. 합리적인 해결방안을 선택한다.
4. 계획했던 시간 안에 목표를 달성한다.
5. 비개발직군의 동료와 소통에 능하다.
6. 팀의 문제는 내일처럼 관심을 갖고 해결한다.

위의 역량들을 골고루 갖추고 있을수록 좋은 개발자에 가까울 것이라고 생각한다. 
내가 이러한 역량들을 꼽은 이유에 대해서는 지금부터 하나씩 정리해 보겠다. 
'질문을 잘한다', '구성원들과 잘 지낸다'처럼 '같이 일하고 싶은 동료'에 가까운 특징들은 개발뿐 아니라 다른 직군에서도 중요한 역량이기에 제외했다.

 

1. 기술에 대한 탐구심이 강하다

기술에 대한 탐구심이 강한 사람일수록 근본적인 동작 원리를 파고드는 성향이 있다. 
이런 성향의 사람은 디버그에서 강점을 발휘한다. 
개발자가 버그를 대하는 태도에는 크게 "돌아가면 된 거다"와 "정확하게 원인을 분석하고 해결한다" 2가지로 나눌 수 있을 것 같다. 
"돌아가면 된 거다"의 태도로 디버그를 하면 처음에는 운 좋게 넘어갈 수도 있다. 
이것저것 설정도 건드렸다가 그래도 안되니 코드도 몇 줄 추가하는 식으로 만져본다. 잘 동작하는 것처럼 보인다. 
하지만 근본적인 문제를 해결하지 않고 임시적, 우회적인 방법으로 해결한 경우 나중에는 이 해결책들이 진짜 문제의 원인에 다가가는 것을 방해하는 장애물로 다가오는 상황이 발생할 수 있다.
결국 진짜 문제를 방치하고 계속 어설픈 해결방법으로만 대응하다 프로그램이 복잡해지는 상황을 초래한다. 
반면 "정확하게 원인을 분석하고 해결한다"의 태도로 디버그를 하면 처음에는 시간이 오래 걸릴지도 모른다. 
하지만 근본적인 문제를 해결하면서 어떤 코드로인해 문제가 발생했고 해결하기 위해선 어떤 조치를 해야 하는지 학습하게 된다는 장점이 있다. 이러한 경험이 쌓이다 보면 실력이 업그레이드되었다는 걸 어느 날 문득 깨닫는 순간이 찾아오기도 한다.
근본적으로 문제를 해결하는 사람들은 보통 팀에서 해결사 역할을 하는 경우가 많았다. 
처음보는 버그가 발생하더라도 근원지부터 하나씩 짚어가면서 진단하기 때문에 결국에는 원인을 색출해서 해결하는 사람들이다. 
나는 운이 좋게도 이런 성향의 사람들을 만나 영향을 받은 덕분에 많이 성장할 수 있었다.

 

2. 문제를 명확하게 정의한다

좋은 개발자는 무언가 개발을 하기 전에 문제를 명확하게 정의하는 과정을 선행한다.
보통 프로덕트를 만드는 과정은 해결하고자 하는 문제와 해결 방법, 즉 기획배경과 요구사항을 기획서로 정리하면서 시작한다.
개발자가 기획서대로 따라 만들기만 해도 요구사항대로 완성할 수 있다면 좋겠지만 현실에서는 그리 순탄하게 흘러가지만은 않는다.
기획서의 요구사항이 기존의 다른 기능이나 정책들과 충돌하는 경우,  해결하려는 문제 정의가 잘못된 경우, 적용하려는 문제 해결 방법이 과한 경우 등 여러 케이스가 있을 수 있다. 
제품에 대해 잘못 인지하고 있던 부분이 있거나 도메인에 익숙하지 않아서 일 수도 있고, 시스템의 구조적 한계를 기획자가 완벽히 이해하기란 어렵기 때문이다.
그렇기에 개발자도 스스로 문제를 다시 해석해보고 개발자의 관점에서 정의해야한다.
어긋나는 부분을 개발에 착수하기 전에 최대한 찾아내고 기획자와 논의해서 요구사항을 명확히 할 필요가 있다. 
물론 사전에 이러한 과정을 거치더라도 처음부터 누락되어서 논의하지 못했다거나, 중간에 미처 발견하지 못했던 사항들로 인해 작업 중간에 조율하는 경우도 생길 수 있다.
하지만 사전에 신경써서 찾아내려고 노력했기 때문에 발견하더라도 추가 작업에 필요한 리소스가 대부분 적게 든다.
미리 문제를 오목조목 뜯어봐도 추가 작업은 생길 수 있다.
하물며 기획서만 보고 곧이곧대로 만드는 경우 어떤일이 생길지는 안봐도 뻔하다.
다른 사람이 정의한 문제를 그대로 받아들이고 코딩부터 시작하는 개발자의 경우는 어떨까?
작업을 시작한 다음 기획 오류나 미비한 사항을 발견하기 때문에 재작업의 비용이 높아진다.
변경 내용에 따라서는 지금까지 만들어온 구조를 허물고 다시 만들어야 할 수도 있기 때문이다.
좋은 개발자는 이런 위험성을 잘 알고있기 때문에 작업을 시작하기 전에 문제 정의를 철저히 한다.

 

3. 합리적인 해결방안을 제안할 줄 안다

망치를 들면 모든 게 못으로 보인다는 말이 있다. 
자신이 알고 있는 방법만으로 모든 문제를 해결하려는 잘못된 모습에 대한 비유적 표현이다. 
개발에서도 굳이 사용하지 않아도 되는 기술 또는 디자인패턴을 따라서 간단한 문제를 어렵게 만드는 경우가 있다. 
부끄럽지만 주니어시절의 나도 그렇게 일을 하는 사람 중 한 명이었다. 
처음부터 객체 간 의존관계를 줄이고 확장성을 높이겠다고 추상화를 과도하게 한다거나, 재사용성을 위해 여러 상황에 대처 가능한 잡다한 옵션을 추가해서 복잡한 모듈을 만들어 버리곤 했다. 
하지만 시간이 지나고 보면 더 확장할 필요가 없는 객체였거나 재사용할 곳이 없는 경우가 있었다. 
경험 부족에서 오는 명백한 오버엔지니어링이었다. 
좋은 개발자는 망치뿐만 아니라 톱, 니퍼, 드릴 등 다른 문제해결 도구들도 잘 알고 있는 경우가 많다. 
이들은 다양한 해결책을 알고 있고 여러 경험을 통해 어떻게 하면 적은 비용으로 문제를 효율적으로 해결하는지 알고 있다. 
텃밭을 가꾸는 일은 모종삽으로 충분하다. 하지만 경험이 없는 사람들은 처음부터 나중에 농장을 만들 거라는 상상을 하며 포클레인을 준비하는 실수를 하기도 한다.
모종삽으로 작업하다가 나중에 텃밭을 더 크게 가꾸고 싶거나 농장으로 발전시키고 싶어지면 그때 가서 포클레인을 고려해도 늦지 않는다. 
개발도 마찬가지라고 생각한다. 
처음엔 필요한 만큼 개발을 하고 나중에 확장이 필요하면 그에 맞게 리팩토링을 하는 것이 더 효율적이다.
좋은 개발자는 불필요한 리소스를 투입하거나 시스템을 필요 이상으로 복잡하게 만들지 않는다.

 

4. 계획했던 시간 안에 목표를 달성한다

개발을 하다 보면 작업일정을 맞추기 위해 야근을 하는 일이 생긴다. 
일정 조절에 실패해서 야근을 하는 데는 여러 이유가 있다. 
예상보다 작업 내용이 많아서, 구조가 마음에 들지 않아 리팩토링이 필요해서, 일이 정말 미친 듯이 많아서 등 다양하다. 
그런데 주변에는 제 시간 안에 일을 마무리하고 척척 일을 해내는 사람들이 꼭 하나 둘 쯤은 있다. 
이들은 정말 필요한 경우가 아니면 거의 야근을 하지 않는다. 
야근하게 만드는 원인들을 이 사람들은 어떻게 다루고 있는지 생각해 보다 느낀 점은 이렇다. 
동시에 이것저것 작업을 벌여놓지 않고 하나씩 집중해서 차례대로 진행한다. 
앞서 언급한 '문제를 명확히 정의한다, 합리적인 해결방안을 제안할 줄 안다'를 잘할수록 필요한 작업을 명확하게 도출해 낸다. 
예상 작업과 실제 작업의 오차가 적기 때문에 일정 산정의 오차도 적은 편이었다. 
리팩토링보다 요구사항의 기능 구현에 초점을 맞추어 구현하고 테스트하는 작업에 중점을 둔다. 
구조가 마음에 들지 않는다고 리팩토링을 하다가 심취해서 정작 기능을 구현하지 못하는 상황을 만들지 않는다. 
리팩토링은 정말 필요해지는 시점에 수행했다. 
일이 미친 듯이 많은 경우는 상황에 따라 다른 것 같다. 
매니저와 논의해 작업과부하를 해소할 수 있다면 좋겠지만 그마저 여의치 않다면 이들도 사람인지라 언젠간 체력이 고갈되기 마련이다. 
고생한 만큼 회사에서 공로를 인정해 적절한 보상을 하거나, 본인이 관심이 있는 작업이라서 성장하는 느낌을 받는 동기부여가 생기는 것이 아니라면 퇴사게이지가 쌓여 결국 퇴사를 선택하는 것 같았다. 
신기했던 건 이런 유형의 사람들은 야근을 거의 하지 않음에도 야근을 해가며 작업일정을 맞추는 사람들보다 많은 일을 처리했다. 
야근에 시간을 뺏기지 않다 보니 컨디션도 항상 좋은 모습을 유지했고 운동, 자기 계발등에도 시간을 투자하면서 일과 삶의 균형이 무너지지 않게 관리를 잘하는 모습이 인상적이었다. 
작업에 대한 집중과 몰입력이 대단한 사람들이어서 배울 점이 많았다.

5. 비개발직군의 동료와 소통에 능하다

 

좋은 개발자는 기획, 디자인, 마케팅 직군의 동료들과 논의할 때 개발자의 관점에서 문제가 되는 부분을 그들의 언어로 잘 전달한다. 
그들이 이해할 수 없는 기술적인 용어들로 장황하게 떠들며 '안 돼요', '못해요'라며 찍어 누르기 보단, 비개발 직군 동료들이 최대한 이해할 수 있게 설명하면서 공감대를 형성하는데 최선을 다한다. 
비개발스러운 설명을 잘하는 분들은 예시 상황이나 비유적 표현을 적절하게 활용했다. 
해본 사람들은 알겠지만 순간적으로 그들의 요구사항을 빠르게 파악하고 이에 맞는 적절한 상황을 가정해서 문장으로 전달하는 건 쉬운 일이 아니다. 
평소에 얼마나 다양한 관점으로 문제를 바라보고 본질에 집중했는지 그 내공을 충분히 느낄 수 있었다. 
게다가 단순히 상황 설명을 전달하는데 그치는 것이 아니라 대안을 제시해 일이 진행되게끔 이어나가는 능력이 탁월했다. 
무작정 개발팀의 의견을 강요하는 것이 아니라 일을 진행하는데 필요하고 합당하다면 그들의 요구도 수용할 줄 알았다.
시스템의 완성도와 비즈니스의 성장 어느 한쪽에 치우치지 않고 당장 필요한 결정을 내리는 모습은 모든 문제를 기술적인 관점 우선으로 해결하려던 내게 많은 깨달음을 주었다.

6. 팀의 문제는 내 일처럼 관심을 갖고 해결한다

좋은 개발자는 팀에 관련된 일이라면 관심을 갖고 해결하는데 주저하지 않는다. 
직접적으로 업무와 관련이 없더라도 본인의 노하우나 경험으로 도움을 줄 수 있는 상황이라면 기꺼이 발 벗고 나선다. 
이렇게 관심을 갖고 해결하려 나서다 보니 시스템에 대한 전반적인 이해도가 높아지고 다양한 문제상황에 대한 해결능력이 향상된다. 
놀라운 건 본인의 업무 또한 알아서 잘 챙기면서 팀의 문제도 처리한다는 점이다.
이런 유형의 개발자는 팀의 전반적인 기술력과 생산성이 향상되는 결과를 만들어낸다.
팀 분위기 측면에서도 팀원들에게 문제가 생기는 것에 겁먹지 않고 스스로 해결해보려 하는 자신감도 심어주는 역할도 하는 것 같다.
이런 유형의 동료와 같이 일하며 배운 점도 많았지만 스스로 해낼 수 있다는 자신감을 많이 얻을 수 있었다.
슈퍼맨 같은 동료를 보며 나중에 나도 저렇게 되고 싶다는 생각을 많이 했던 것 같다.

 

마무리

요약하자면 지금의 내가 생각하는 좋은 개발자는  문제를 정확히 인식해서 상황에 걸맞는 해결책을 제시할 줄 알고, 이런 내용을 다른 사람에게 잘 설명하고 도움을 줄 수 있는 사람인 것 같다.
아직 시니어 레벨, 팀장으로서의 경험이 없는 미드레벨 개발자의 기준에서 느낀점들이라 조직관리 측면에서의 인사이트를 다루지는 못했다.
시간이 지나 관리 업무를 경험하다 보면 지금의 생각과는 또 달라질 것이라 생각한다. 
훗날 팀장 업무를 맡게된다면 다시 이글을 꺼내보고 어떤 생각을 하고 있을지 기대가 된다.