좋은 개발자가 되고 싶다면 다음 5가지 소양을 갖추세요.

좋은 개발자란 무엇일까요?

개발자로 일하게 되면 항상 고민하게 되는 질문 중 하나입니다. 그리고 저는 좋은 개발자와 그렇지 않은 개발자를 나누는 것이 엔지니어로서 업무를 대하는 태도에 있다고 생각합니다. 경력이나 능력에 무관하게 말이죠.

이번 포스팅은 필자가 미드 시니어 엔지니어로 성장하는 과정에서, 주변의 좋은 개발자들을 보면서 정말 존경할만하다고 느꼈던 5가지 자세들을 정리해 보았습니다.

판단은 주관적인 것이겠지만, 항상 성장에 대한 고민을 갖고 계신, 이 글을 읽으시는 많은 분들께 도움이 되고자 합니다.

1. 항상 의문을 제기하세요.

첫 번째는 엔지니어가 가져야 하는 가장 기본적인 자세라고 생각합니다. 모든 일에 의문을 제기하고 그 의문을 해결하기 위해 지식을 구하고 공부하고 노력하는 것입니다. 훌륭한 엔지니어들과 일하면서 가장 놀랐던 부분은, 그들이 의문을 제기하는데 두려워하지 않는다는 점이었습니다. 소프트웨어는 방대한 분야입니다. 수많은 사람들이 산업에 종사하고 있고, 기술은 지식을 습득하는 속도보다 빠르게 진화합니다. 모르는 건 잘못된 일이 아니며, 계속해서 알려고 노력하는 자세가 무엇보다 중요합니다.

때로는 알고 있는 지식과 현실의 문제가 충돌하는 경우들이 있습니다. 특히 시니어들의 경험에서 나온 지식과 학교에서 공부한 지식 간에 차이가 있는 경우들이 많습니다. 항상 의문을 제기하고 모르는 부분은 확실히 이해하도록 합니다.

명심하세요. 세상 어디에도 바보 같은 질문은 없습니다.

2. 긍정적으로 생각하세요.

기술적으로 프로젝트의 방향을 잡아주는 건 개발자의 아주 중요한 역할 중 하나입니다. 특히 시니어가 되어간다면 더욱 그렇습니다. 하지만, 이때 주의해야 하는 건 지나치게 냉소적으로 변하는 것입니다.

개발자는 문제를 해결하는 사람입니다. 문제를 냉철하게 분석하고 시니컬해지는 건 엔지니어의 좋은 자세이지만, 결국은 우리는 가치를 만들어내야 합니다. 문제가 해결되지 않는다면 결국 얻을 수 있는 것은 없습니다. 개발자는 문제를 기술을 통해 해결하는 사람입니다.

때로 기획자 또는 동료 엔지니어가 바보 같거나 허황된 아이디어를 갖고 조언을 구할 때가 있을 것입니다. 현실적으로 쉽지는 않지만, 항상 상대방의 입장에서 이해하고 도움을 주세요. 무작정 상대방의 아이디어를 비난하거나 요청을 거절하기보다는 “좋은 개발자” 이자 “좋은 사람” 이 되기 위해 노력해야 합니다.

우리는 팀으로 일하고, 커뮤니케이션 과정에서 많은 어려움을 겪게 됩니다. 우리는 그럼에도 긍정하고, 결국 팀의 일원으로 문제를 해결할 방법을 찾아야 합니다.

3. 의사소통은 말로 하세요.

개발자는 코드로 말한다고 굳게 믿는 엔지니어들이 있습니다. 일리는 있지만, 좋은 개발자는 말로 의사소통을 한다고 생각합니다. 정말 자신의 코드가 소설책처럼 깔끔하고 논리가 누구나 이해할 수 있다고 생각하시나요? 물론 그런 경우도 많습니다만, 대부분의 경우 말로 전하면 더 효과적입니다.

맥락 없이 코드만 던져놓고 이해를 바라는 건 이기적입니다. 최대한 자세하게 의사를 전달하고, 가능하다면 직접 커뮤니케이션하는 것이 좋습니다.

팀에서 어떤 기능의 구현을 담당해서 작업을 마쳤다고 가정해 봅시다. 개발자인 당신은 기능을 Main Branch에 반영하기 위해 Pull Request를 올리고 확인해달라고 요청했지만 쉽사리 승인이 나지 않습니다. 왜일까요?

코드의 작성자 입장에서는 테스트도 잘 마쳐진 훌륭한 코드이겠지만, 해당 기능을 구현하지 않았지만 책임을 분담해야 하는 팀원들의 입장에서는 아직 이해가 가지 않았을 가능성이 높습니다. 더 좋은 방향이 있을 수도 있고요. 그래서 결국은 커뮤니케이션이 중요합니다.

이는 반대도 마찬가지입니다. 코드 리뷰 시에 상대방의 코드가 부족한 부분이 있다면 예의를 지켜서 충분히 커뮤니케이션하세요. 자신의 경험에 비춰봤을 때 상대방의 코드가 부족하다고, 당신이 옳다는 뜻은 아닙니다. 단지 당신은 상대방의 의견과 다른 옵션을 갖고 있을 뿐이고, 그 아이디어를 기반으로 협업할 수 있을 뿐이죠.

소프트웨어 개발이란 팀플레이이고, 중요한 건 자신의 코드가 남들보다 뛰어난 것이 아니라 팀이 우수한 서비스를 제공할 수 있게 서포트하는 것입니다. 협업이란 대화입니다.

4. 중요한 건 아이디어입니다.

필자도 그랬었지만, 많은 주니어 개발자들은 코드를 먼저 시작하는 경우가 많습니다. 막연한 아이디어를 코드로 옮기다 보면 해결책이 구체화되는 경우가 많지만, 보다 발전하고 싶다면 먼저 생각하고 코드의 우선순위를 미루는 게 좋습니다. 지금은 작은 관점에서 코드를 개발하시게 되겠지만, 결국엔 보다 큰 관점에서 서비스를 설계하고 어떤 분들은 팀을 리딩도 하게 될 겁니다.

작업의 규모가 커지고 복잡해지면, 먼저 개발을 시작하는 건 성급한 자세입니다. 설계가 미리 안 되어있고, 현재 할당된 작업이 없다면, 차라리 휴식을 취하는 게 나을 수도 있습니다. 성급한 코드화는 작업에 있어 의존성을 만들어냅니다. 결국 생각이 구현에 갇히는 주객전도의 상황이 될 수 있습니다.

특히 이 내용은 필자가 주니어 개발자일 때 많은 시니어 분들이 주신 조언들입니다. 당시 필자는 개발 자체가 재미있어서 늘 기능 개발에 성급히 뛰어들었고 구현해냈지만, 종종 코드 전체를 다시 리팩토링하거나 설계를 바꾸는 등 실수고 있었습니다. 이는 팀의 입장에서 봤을 때 전혀 좋지 않죠.

먼저 충분히 팀과 커뮤니케이션해서 요구사항을 명확히 합니다. 그다음, 설계하고, 코드는 가장 나중이어도 상관없습니다. 결국 코드는 가치를 만들어내는데 필요한 도구 중 하나입니다. 개발에 갇혀서 큰 그림을 등한시해서는 안 되겠습니다.

5. 항상 겸손하세요.

마지막으로 가장 중요한 태도입니다. 특히 뛰어난 개발자일수록 자존감이 높은 엔지니어들이고, 오만해지기 쉽습니다. 하지만 대부분의 개발은 협업이고, 모든 비즈니스는 일종의 커뮤니케이션입니다. 자존감이 높아졌다고, 오만하게 행동 하는 건 좋은 자세가 아닙니다.

좋은 개발자들은 오히려 더 겸손하고, 끊임없이 배우려 듭니다. 그들의 지식과 이해는 놀라운 수준이지만, 사실 더 뛰어나다고 생각을 한 것은 그들의 자세입니다. 그들은 경청하고 타인의 생각을 자신의 지식수준에 가두지 않습니다. 그렇기 때문에 계속 발전할 수 있는 것이겠죠.

시작점이 어떻든, 겸손하게 계속 배우려 한다면 결국 발전하게 되어있습니다. 지식은 거인의 어깨 위에 쌓아 올려져있으며, 인터넷의 존재로 인해 소프트웨어는 운 좋게도 그 부분에 있어서 가장 유리한 학문 중 하나입니다.

이번 포스팅에서는 필자가 항상 되려고 추구하는 뛰어난 Tech Lead 들과 존경할 만한 선후배 개발자분들의 모습을 보며 느낀 바를 작성해 보았습니다. 저의 성장에 도움이 되었듯이, 수많은 다른 엔지니어 분들의 성장에도 도움이 되셨으면 하는 바람입니다.