슈퍼 개발자라는 단어는 어려운 문제를 엄청 빨리 풀어내는 영웅적인 모습으로 상상되는 것 같아요. 실제로 회사에서 그들을 만나기 전까지 저는 그렇게 떠올렸답니다.
그러나 슈퍼 개발자라는 느낌을 주는 사람은 개발을 엄청 잘하는 사람보다는 일과 소통을 잘하는 개발자였어요. 그저 코딩을 잘하거나 알고리즘을 잘 짜는 어느 한 곳에 치우친 모습이 아니라, 다양한 능력치가 밸런스 있게 잡힌 모습이었습니다.
서평 제안을 받아 한빛 미디어에서 올해 7월 출판한 따끈따끈한 책인 <육각형 개발자>를 읽어보았는데요. 이 책에서는 개발자의 능력을 6가지로 분류했고, 이를 골고루 지닌 개발자가 좋은 개발자라고 말하고 있습니다.
🔴 구현 기술에 대한 이해
요즘은 이미 누군가 만들어둬 안정성이 보장된 프레임 워크나 오픈소스를 활용해 개발하게 되는데요. 내부 구현을 모두 이해할 필요 없이 코드에 적용하곤 합니다. 저자도 사용하는 모든 기술에 대해 깊게 이해할 필요는 없다고 말해요. 다만, 깊게 알아야 하는 순간이 되면, 그때는 딥 다이브하라고 해요.
실제로 무언가를 깊게 알게 되는 건, 이런 순간들인 것 같아요. 무심코 적용했던 기술이 기대와 달리 동작해 오류를 발생시켰을 때, 그때 내부 구현을 살펴보게 됩니다. 그리고 이런 순간들이 스스로를 한 걸음 더 성장하게 합니다. 하루나 일주일을 돌아보면 이런 순간들이 꽤 많은 것 같아요. 다른 이의 코드를 리뷰하다가, 이전에 개발해본 비슷한 코드를 작성하다가 무심코 이건 어떻게 동작하는 걸까 궁금해서 찾아보기도 합니다. 때로는 예상치 못한 오류가 발생해 그걸 깊게 찾아보면서 알아보기도 하죠.
🟠 소프트웨어 품질과 코드 이해
새로운 프로젝트보다 기존 프로젝트를 유지보수하기가 더 어렵습니다. 기존 프로젝트는 레거시 코드를 가지고 있고, 새로운 기능을 추가할 때 이 코드들을 이해하고 조화로운 코드를 작성해야 하니까요. 여담이지만 개발자가 일하는 시간의 60%를 코드를 읽는 데 사용한다고 하죠.
신규 프로젝트 기회보다는 기존 프로젝트를 유지보수하는 기회가 훨씬 많습니다. 이를 위해서는 코드 많이 읽고 이해하는 능력이 중요합니다. 또한 유지보수를 통해서 다양한 오류 상황을 경험하고, 이를 해결하는 노하우도 쌓을 수 있습니다. 자칫 지루하게 보일지 모르지만 이런 것들이 실제 시니어 개발자가 되는 자양분이 된다고 생각해요.
🟡 응집도, 결합도
클린 코드 관점에서도 아키텍처 관점에서도 중요한 개념인 응집도와 결합도를 알맞게 구현했는가가 개발자의 소양으로 나옵니다. 응집도는 동일한 모듈 내에 관련 기능이 함께 모여있는 정도이고, 결합도는 다른 모듈이 서로를 의존하는 정도를 말합니다.
같은 기능은 함께 뭉쳐있고, 다른 기능은 서로 덜 의존하는 게 좋은 모델이겠죠? 응집도는 높게, 결합도는 낮은 시스템이 좋은 시스템입니다.
이걸 한 번에 구현하기는 어려운 것 같습니다. 서비스 초기에는 기능이 별로 없어서 한곳에 모아둔 코드가 적당히 응집되었다고 생각되지만, 시간이 지나면서 그 클래스에 너무 많은 기능이 모여있게 되고 응집도를 높이기 위해 여러 클래스로 나누게 됩니다. 서비스의 성장에 따라 알맞은 정도로 나누고 합쳐야 합니다.
🟢 리팩터링과 테스트
우리는 새로운 기능을 추가할 때도 리팩터링을 합니다. 기존 코드에 조건을 추가하거나 조금 다르다고 기존 코드를 복붙해서 조금만 바꿔서 추가하는 방식이 아니라요. 이런 코드가 쌓이게 되면 깨진 유리창처럼 코드는 점점 건드리기 싫어지고, 지저분하게 쌓이게 됩니다. 변경하려고 하는 부분이 이런 부분을 건드린다면, 일정에 무리가 없는 선에서 이 부분도 깨끗하게 고쳐둬야 합니다.
책에는 TDD와 테스트 자동화에 대한 이야기가 나옵니다. TDD가 한창때 뜨거운 감자였는데요. TDD를 엄격하게 따르는 개발자는 그렇지 않은 개발자를 이해하지 못했었고, 반대 진영에서는 반드시 그럴 필요는 없다고 말했어요. 저는 TDD를 하기도 안하기도 합니다. 요구사항을 보고 어떻게 개발할지 방법을 떠올리는 게 어렵지 않으면 바로 로직을 건드립니다. 그런데 어떻게 해야 할지 조금은 막막하면 테스트부터 작성합니다. 요구사항에 맞게 테스트 케이스를 하나씩 추가하다 보면 조금씩 감이 잡히게 됩니다. TDD를 하면 모두 실패했던 테스트를 하나씩 초록불로 바꿔 가는 재미가 있더라구요.
🔵 아키텍처, 패턴
아키텍처의 품질을 정의하는 용어에는 여러 가지가 있는데요. 가용성, 성능, 확장성, 보안, 유지보수성, 복잡도, 비용 등이 있습니다. 이때, 우리는 엔지니어이기 때문에 트레이드 오프를 고려합니다. 확장성과 가용성을 좋게 하다보면 복잡도와 비용이 올라가고, 추후 유지보수성이 안 좋아질 수 있습니다. 이처럼 엔지니어링에는 모든 걸 좋게 하는 완벽한 아키텍처란 없습니다.
요구사항에 따라 PM과 우선순위를 정하고, 여기에 최적화된 방법을 찾아내는 거죠. 이때 우리는 패턴을 적용하게 되는데요. 특정 맥락에서 반복되는 문제해결법을 패턴이라고 부르고, 패턴을 사용하게 되면 마치 모범답안을 참고하듯 시간을 단축하고, 이미 패턴을 적용한 사람들의 지식과 노하우를 얻을 수 있습니다.
🟣 업무관리, 공유, 리더십과 팔로우십
마지막으로 업무와 태도에 관한 요소인데요. 저자는 업무를 작게 나누어 실행하고, 위험 요소(가장 위험한 건.. 시간 내 완수하지 못하는 것!)를 제거하기 위해 반나절 고민해도 모르겠다면 도움을 요청하라고 말합니다. 제 주니어 때를 돌이켜보면, 질문하면 내 모자람을 들키는 것 같아서 많이 끙끙댔었는데요. 결국 그러다가 혼자 샛길로 간 코드를 개발해 팀장님의 의아함을 산 적도 있고요. 자연스레 시간을 끌어봤자 나 혼자서는 안된다라는 깨달음을 얻었던 것 같아요.
그 이후로 "내게 시간이 더 주어진다면 혼자 해결할 수 있는가?"라는 질문을 던져 그게 아니라면 바로 동료들에게 도움을 요청합니다. 도와주는 상대가 슈퍼 개발자일 필요가 없습니다. 연차가 적고 많음도 상관이 없어요. 함께 문제를 풀기 위해 머리를 맞대면 무조건 해결책을 찾을 수 있었습니다. A로 가려고 해도, 그 길이 안 보인다면 좀 돌아서 B로 가도 되니까요. 함께 고민하면 돌아가는 방법도 더 빨리 찾게 됩니다.
리더십과 팔로우십에 대한 부분도 인상깊었는데요. 테크니컬 리더의 역할은 문제를 이해하고, 다양한 의견과 방법을 청취하여 소프트웨어 품질을 유지하는 것이라고 말해요. 팔로우십은 전문성을 바탕으로 능동적으로 일을 수행하면서 리더가 성공할 수 있도록 지원합니다. 리더가 시키는 일을 묵묵하게 한다기 보다는, 진심으로 리더가 성공할 수 있도록 적극적으로 일을 수행해야 한다는 깨달음이 다시금 들었어요.
저도 오랜만에 개발자의 태도에 대한 책을 읽으면서 스스로를 다시금 돌아보게 되었어요. 육각형이긴 한 것 같은데, 찌그러졌고 일부 모서리는 조금 짧은 것 같습니다. 🔴 구현 기술에 대한 이해는 계속 노력해야 할 것 같고요. 🟠 유지보수를 통해 노하우도 더 쌓아야겠고, 🔵 아키텍처와 패턴에 대한 공부가 더 필요한 것 같아요.
일할 때마다 스스로 질문할 포인트들을 얻었어요.
구현 기술에 대해 너무 얕게 이해하고 사용하는가, 새로운 기술을 지나치게 추구하려고 하는가, 응집도와 결합도를 고려하여 리팩터링했는가, 테스트를 대충 작성하지 않았는가, 최적화된 아키텍처를 설계했는가, 좋은 팔로우십을 발휘하고 있는가.