시니어 소프트웨어 엔지니어는 어떻게 일할까?

그들을 지켜보면서 신입 개발자였던 내가 스스로 배우고 발전할 수 있었던 방법

본문은 위시켓과 번역가 전리오가 함께 만든 해외 콘텐츠 기반 번역문입니다. 프로그래머를 위한 다양한 정보를 다루는 블로그 매체 ‘Better Programming’의 글을 번역했습니다. 작가는 마이클 치(Michael Chi)로 그는 소프트웨어 엔지니어입니다. 본문은 작가가 신입 개발자로 일하면서 본 시니어 개발자들의 모습과 그들로부터 어떤 점을 배웠는지에 대한 내용입니다. 신입 개발자분들에게 도움이 될만한 글로 번역해 전해드립니다.

신입 개발자로 첫걸음을 뗐을 때 저는 운이 좋게도 시니어 개발자 한 분이 저의 멘토가 되어 지도해주셨습니다. 제가 걸어가고 있는 길을 이미 지나가 본, 그 과정에서 저보다 훨씬 더 많은 경험을 했던 누군가로부터 많은 것을 배울 수 있는 기회였습니다. 함께 일하는 팀에 여러분을 적극적으로 가르쳐주고자 하는 시니어 엔지니어가 있다면 그것은 큰 축복입니다. 만약 시니어 개발자가 되는 것이 목표라면, 그런 사람과 함께 일하는 경험 자체만으로도 엄청난 시간을 절약할 수 있습니다.

이번 글에서는 저의 멘토를 비롯한 여러 시니어 개발자들이 일하는 모습은 물론이고, 그분들을 통해서 배울 수 있던 개인적인 교훈을 여러분께 공유해보겠습니다.

그들은 고객들에게 문제를 제기한다.

어떤 제품을 직접 구현하기 전에 우리는 고객들과 함께 구체적인 기능들을 결정해야 합니다. 시니어 개발자들은 일반적으로 개발팀을 이끄는 사람들이기 때문에 회의에도 당연히 참석합니다. 그런데 고객들은 가끔씩 자신이 실제로 필요한 것이 무엇인지를 정확히 모르는 경우도 있습니다. 그들은 갖고 싶다고 생각하는 기능이 자신들에게 필요한 것이라고 여기기도 하지만, 실제로는 그렇지 않을 수도 있습니다. 그런 경우에 시니어 엔지니어들은 그러한 기능을 구현하는 게 불가능하다고 문제를 제기합니다. 물론 거기에서 그치는 것이 아니라, 그들은 고객의 실제 필요에 더욱 잘 맞는 다른 아이디어를 제안합니다.

스티브 잡스는 언젠가 이렇게 말했습니다.

사람들은 무언가를 직접 보여주기 전까지는 자신들이 무엇을 원하는지 알지 못한다.

그렇다고 고객들이 아무것도 모른다는 의미는 아닙니다. 하지만 어떤 기능을 구현하는 방법에 대해서는 개발자들이 훨씬 더 잘 알고 있기 때문에, 그들에게 보다 적합한 아이디어를 제시할 수 있는 것입니다.

개인적인 교훈

• 언제나 자신의 일이 제공하는 비즈니스적인 가치에 대해서 생각해야 한다.
• 요구되는 기능의 실현 가능성에 대해서 생각한다. 혹시 더 나은 솔루션이 있지는 않은가?
• 고객들의 의견에 언제나 동의할 필요는 없다. 정중하게 문제를 제기하고 자신의 생각을 표현한다. 만약 그들의 생각이 틀렸다 하더라도, 훌륭한 기업문화를 가진 조직이라면 그러한 견해를 포함해서 모든 사람들의 의견을 소중하게 생각한다.

그들은 할 일이 끊이지 않는다.

저의 상사는 일대일로 만난 자리에서 제게 이렇게 설명했습니다. “시니어 개발자들에게 할 일이 끊이지 않는 이유는, 그들이 조직 내의 코드베이스(codebase)[1]에 상당한 영향력을 갖고 있기 때문입니다. 그들은 리포지터리(repository, 저장소)를 생성하고 발전시키는 데 있어서 처음부터 관여해 왔기 때문에, 그동안에 누적된 기술적인 부채(technical debt)[2]까지도 기억하고 있습니다. 게다가 그들은 시스템 내에서 변화가 필요하거나 최적화해야 하는 부분을 찾아내기 위해서 언제나 노력하고 있습니다.”

물론 이 회사가 구글 정도의 규모는 아니지만, 그래도 회사 한 곳에서 오랫동안 일해 온 시니어 개발자들이라면 그들이 그 회사의 코드베이스에 미치는 영향력은 상당히 큽니다. 일부 리포지터리는 그들이 직접 만든 것도 있어서, 만약 그곳에 뭔가 문제가 있으면 다른 개발자들은 가장 먼저 그들에게 연락을 하기도 합니다. 그리고 프로젝트를 서둘러 진행하느라 잠시 미뤄두었던 문제들을 기억해두고 있다가, 잠시 여유가 생기는 시간에는 문제들을 다시 살펴보면서 해결하기도 합니다.

가끔씩 아무것도 할 일이 없다고 느끼는 건 오직 신참 개발자들뿐입니다. 신참 개발자들에게 가장 중요한 것은 당장 주어진 업무를 끝내고, 단기적인 과제를 완료하는 것이기 때문입니다. 참고로 저도 이번 글을 다 쓰면, 작성하던 소스코드를 다시 열어봐야 합니다.

개인적인 교훈

• 여유 시간이 생기면, 다른 팀이 하는 일을 살펴본다. 그리고 가능하다면, 그들을 도와준다. 그러면 조직 내의 다른 부서에서 하는 일이 무엇인지도 파악할 수 있고, 자신의 영향력을 더욱 확대할 수 있다. 때로는 개발 중인 시스템에서 개선할 수 있는 부분을 찾아낼 수도 있고, 새로운 프로젝트를 시작할 수도 있다.
• 정말 아무것도 할 일을 찾을 수 없다면, 본인이 했던 복잡한 프로젝트나 유용하게 사용했던 라이브러리에 대한 내용을 문서로 정리한다.

그들은 다른 팀에 대해서 잘 알고 있다.

이번 항목은 앞의 내용과도 연관되는 것입니다. 저의 멘토는 다른 팀들이 무슨 일을 하고 있는지를 잘 알고 있습니다. 그리고 우리가 어떤 내용을 변경해야 할 때는 그것이 다른 팀들에게 미치는 영향이 무엇인지에 대해서도 고려합니다. 그뿐만이 아니라, 우리는 다른 팀의 개발 일정까지도 고려해서 저희가 해야 할 업무의 우선순위를 조정하곤 합니다.

특히 다른 팀에서 사용하는 것과 동일한 라이브러리를 기반으로 작업한다거나, 다른 팀에서 관리 권한을 가진 리포지터리에서 작업한다면 더욱 신경을 써야 합니다. 다른 팀들이 어떻게 돌아가고 있는지를 파악한다면, 서로 간의 마찰을 줄일 수 있기 때문에 개발 부서의 모든 사람들에게도 도움이 되는 것입니다. 물론 아마존이나 페이스북처럼 회사 내에 수백 개의 개발팀이 존재한다면 이렇게 하기가 불가능할 것입니다. 그러나 적어도 자신과 가까운 팀의 사정에 대해서는 파악하는 것이 좋습니다. 단지 자신의 업무에만 몰두하지 말고, 주변에서 무슨 일이 일어나고 있는지를 늘 신경 써야 합니다.

늘 이런 태도를 갖고 임한다면, 평소에 일하고 싶었던 다른 팀으로 옮겨갈 수 있는 기회가 생기기도 합니다. 여러분이 현재 몸 담고 있는 팀에 인력이 충분하고, 여러분이 다른 팀의 업무를 이미 도와주고 있다면, 회사에서도 여러분이 팀을 옮기는 것에 그다지 반대하지는 않을 것입니다.

개인적인 교훈

• 앞의 내용과 동일합니다.

그들은 먼저 다른 사람의 말을 잘 듣고, 그다음에 설명한다.

저는 가끔씩 바보 같은 질문을 할 때가 있습니다. 눈앞에 바로 해답이 있는데 그걸 못 보는 경우도 많습니다. 제가 어떤 문제에 부딪힐 때마다 저의 멘토가 그 해결책을 제시해주곤 하는데, 그럴 때면 저는 왜 그런 생각을 하지 못할까 하는 생각이 들기도 합니다. 때로는 제가 뭔가에 대해서 잘 알고 있다는 생각이 들 때도 있고, 그들과 함께 어떤 기능의 구현에 대한 구체적인 방안을 논의하고 있다고 느낄 때도 있습니다. 그리고 어떤 때는 제가 AWS 비용을 절감할 수 있는 방안을 찾아냈거나, 그나마 알고 있는 알고리즘에 대한 지식을 뽐낼 기회라는 생각이 들 때도 있습니다.

그들은 언제나 저의 말을 성실히 들어줍니다. 그다음 그것이 잘못됐다면, 차분하게 그 이유에 대해 설명합니다. 하지만 그 잘못한 점에 대해 핀잔하지 않기 때문에, 저는 패배감이나 부끄러움을 느끼지 않았습니다. 물론 제가 잘 아는 것에 대해서 설명할 때도 그들은 잘 들어주며, 제가 하고 싶은 것을 할 수 있게 허용해 줍니다. 어떤 상황에서도 시니어 개발자들은 다른 사람들이 말하는 것을 잘 경청하며, 필요한 내용에 대해서는 기꺼이 설명해주곤 합니다. 그런 모습은 후배 개발자들을 가르치는 태도에서도 드러나고, 어떤 라이브러리에 대한 내용을 몇 페이지의 문서로 정리해서 설명할 때도 마찬가지입니다.

개인적인 교훈

• 자신이 꼭 해야 하는 일이 아니더라도, 필요한 부분에 대해서는 틈틈이 문서로 정리하거나 직접 설명해준다.
• 커뮤니케이션은 아주 중요하다. 그리고 기회가 된다면 문서를 작성하거나, 어떤 개념을 설명함으로써 커뮤니케이션을 직접 실천하도록 한다.

그들은 소스코드를 들여다보는 걸 두려워하지 않는다.

저희 회사에서는 아주 많은 자바스크립트(JavaScript) 패키지를 사용하고 있는데, 그중에는 마지막으로 수정했던 날짜가 무려 8년 전이었던 코드도 있었습니다. 라이브러리들은 점점 더 빠르게 업데이트되고 있기 때문에, 8년 전에 작성된 코드를 지원하지 않는 경우도 가끔씩 발생합니다. 그래서 저희 회사에도 그와 관련한 많은 버그가 있습니다. 스택오버플로(StackOverflow)와 같은 사이트에서는 수많은 버그들에 대한 정보가 올라와 있지만, 저희 회사가 8년 전에 어떤 웹 애플리케이션을 만들면서 생긴 그 버그들에 대한 내용은 온라인에서 전혀 찾아볼 수 없었습니다. 그렇지만 그때 만든 라이브러리는 여전히 저희 회사의 깃허브(GitHub)에 남아 있습니다. 즉, 라이브러리를 만든 소스코드도 그대로 남아 있다는 것입니다. 그러니 그걸 활용하면 됩니다.

예전에 개발 프로젝트를 진행하면서 어떤 버그가 발생했는데, 구글에서 열심히 찾아봐도 해당 버그의 원인을 알아낼 수가 없었습니다. 아니면 제가 충분히 찾아보지 않았던 걸 수도 있습니다. 그렇게 어려움에 빠져 있는 상황이었는데, 때마침 저의 멘토가 슬랙(Slack)을 통해서 우리가 사용하는 라이브러리에 버그가 있다고 지적해주었습니다. 그분은 문제가 있다는 걸 알고는, 그 라이브러리의 8년 전 소스코드까지 직접 열어보았던 것입니다. 그분이 그렇게 하는 동안, 저희는 그저 이러쿵저러쿵 말만 늘어놓고 있었습니다.

오픈소스(open source) 라이브러리에 대한 문제점들이 공개(open)되어 있는 이유도 거기에 있다고 생각합니다. 사람들이 실제로 그 부분을 파고 들어서 소스코드를 살펴보고, 그 라이브러리에 존재하는 버그를 찾아내기 때문입니다. (오픈소스 자바스크립트 라이브러리인) 리액트(React)의 소스코드를 들여다보기가 겁나서, 그냥 오픈소스 라이브러리라면 언제나 옳다고 생각하는 저와 같은 개발자들과는 다른 것입니다. 오픈소스 라이브러리가 그 소스코드를 공개하는 데에는 나름의 이유가 있다는 점을 이해해야 합니다. 어떤 기술을 다른 사람들과 함께 디버깅하면서 발전시키는 데 있어서는, 오픈소스가 가장 좋은 방식이기 때문입니다.

개인적인 교훈

• 혹시 자신이 사용하고 있는 라이브러리에 버그가 있는데, 구글로 검색해 봐도 도움이 되는 정보를 찾을 수 없는가? 그렇다면 사용하고 있는 함수(function)의 소스코드를 직접 들여다 보라. 그러면 어떤 문제점을 발견할 수도 있고, 아니면 해결책을 위한 힌트를 얻을 수도 있다.
• 소스코드를 읽는 즐거움을 느낀다. 소스코드는 자신이 사용하고 있는 라이브러리가 가진 단 하나의 실체이다.

결론

시니어 개발자는 단지 코딩을 잘한다고 되는 것이 아니라, 그 외에도 다른 수많은 노력과 경험을 쌓아야 합니다. 여러분도 언젠가 시니어 개발자가 되고 싶다면, 그런 사람들에게서 직접 배우는 건 어떨까요? 경험이 풍부한 사람과 교류를 할 때는 그들이 일하는 모습을 잘 지켜보고, 그러면서 얻은 내용들을 분석해보세요. 그러면 정말 귀중한 사실들을 배울 수 있고, 여러분이 나아가야 할 방향에 대해서도 많은 조언을 들을 수 있습니다.

심지어 그런 시니어 개발자들도 다른 관리자들이나 다른 직원들로부터 무언가를 배웁니다. 경험 많은 수많은 개발자들과 함께 일하면서도 스스로 발전하지 못한다면, 거기에는 변명의 여지가 없다고 생각합니다.

[1] 어떤 프로그램이나 애플리케이션을 구축하기 위해서 개발자들이 작성한 소스코드 전체

[2] 시간에 쫓겨서 급하게 완성품을 출시하려고 하다 보니, 개발 과정에서 발생한 기술적 결함을 부채(빚)처럼 쌓아두고 가는 것