어쩌다 보니 개발자로 일하고 있다. 어쩌다 보니 연차로는 4년 차다. 문득 나는 무엇을 좇아 이 일을 하게 되었나 되돌아봤다. 나는 지금 큰 게임회사에서 백엔드 엔지니어로 일하고 있다. 이상치를 탐지하는 앱을 만들고 있고, API 개발도 한다.
대학생 시절, 막연히 코드를 짜서 무엇인가 만드는게 좋아 개발자가 되기로 했다. 이 회사 저 회사를 거쳐 지금은 대기업에 다니고 있다. 문득 되돌아보니 나는 엔지니어이지 메이커는 아니라는 생각이 들었다. 개발자일 수는 있지만 말이다.
사실 엔지니어냐, 개발자냐, 메이커냐 하는 표현은 말장난일 수 있다. 하지만, 내가 만나본 생각보다 많은 소프트웨어 엔지니어들은 재밌게도 이 세 가지 범주로 얼추 나눌 수 있다.
엔지니어
엔지니어는 복잡한 소프트웨어를 장애 없이 운영하고 유지보수하며 개선하는 사람이다. 필요하면 코드를 짜기도 하고, 로그, 메트릭, 트레이스를 바탕으로 시스템을 모니터링 하기도 한다. 소프트웨어의 품질을 유지하며 장기적인 관점에서 지속가능한 소프트웨어를 만들기 위해 노력하고, 고가용성을 보장하기 위해 노력한다.
보통 이미 잘 만들어져 운영 중인 서비스를 담당하는 사람으로, 서비스를 보다 고도화 하는 과정에서 리팩토링을 하기도 하고, 추가 기능을 개발하기도 하지만 주 업무는 운영되는 서비스의 안정성 관리와 모니터링이다. ‘레거시’ 라고 부르는 것과 사투하며 끊임없이 개선하고자 노력하는 사람이다.
개발자
개발자는 소프트웨어 관점에서 원 투 텐을 하는 사람이다. 비교적 초기 상태부터 제품을 빠르게 개발하고 필요할 경우 적절한 실험을 통해 PMF(Product Market Fit)을 검증하며 소프트웨어를 빠르게 발전시켜 나간다.
비교적 초기 단계의 프로덕트를 만드는 사람이지만, 이미 회사는 어느정도의 시장 검증을 마친 상태로, 망할 확률이 매우 높은 서비스를 만드는 사람은 아니다. 당연히 소프트웨어의 품질과 지속가능성이 어느정도 중요시되며, 장기적인 관점을 고려하며 코드를 짠다.
주 업무는 모니터링이나 운영보다는 코딩이고, 개발을 주로 하는 사람이기 때문에 개발자라 불린다.
메이커
제로 투 원을 하는 사람이다. 아무 것도 없는 단계에서 초기 PMF를 찾는 과정을 전담하는 사람으로, 개발을 할 수 있고, 개발을 하지만 필요한 모든 것을 한다. 필요하다면 피그마를 배워 간단한 UI도 그린다. 여러 가설을 빠르게 실험하며 지표가 잘 나오지 않은 실험은 과감히 포기한다. 새로운 아이디어는 실패하는 게 대부분이므로 지속가능한 코드를 작성하기 보다는 빠르게 시장 검증을 하는 데 집중한다.
모니터링은 관심사가 아니다. 갓 태어난 서비스는, 사용자가 없어 망할 수는 있어도 장애가 나서 망하지는 않기 때문이다. 단순히 컴퓨터 공학이나 소프트웨어 엔지니어링에 대한 이해만으로는 부족하며, 비즈니스를 이해하는 감각이 중요하다.
엔지니어, 개발자, 메이커를 표현한다면
문득 엔지니어와 개발자와 메이커는 아래처럼 표현할 수 있겠다는 생각이 들었다.
quadrantChart title "엔지니어 개발자 메이커" x-axis "새로운 것을 창조하고자 하는 욕구가 강한가?" y-axis "기술적인 관심이 큰가?" "엔지니어": [0.05, 0.95] "개발자": [0.47, 0.47] "메이커": [0.95, 0.05]
엔지니어는 기술적인 욕구가 큰 사람에게 어울린다. 대규모 소프트웨어를 안정적으로 운영하기 위해서는 분산환경에 대한 이해를 바탕으로 Kafka와 같은 시스템에 대해 이해해야 한다. 시스템은 너무나 다양한 이유로 장애가 발생하고 실패하는 데, 이런 실패를 방지하고 적절히 대응하기 위해서는 상당한 기술적 숙련도를 필요로 한다. 필요할 경우 패킷 단위, 바이트 단위까지 직접 까 보면서 문제를 해결하려는 기술적인 의지가 필요하다.
한편, 개발자는 기술적인 욕구와 창조 욕구를 모두 필요로 한다. 상당한 기술적 도전을 하기도 하지만, 무엇인가를 빠르게 만들기 위해서는 경우에 따라서 타협도 필요하다. 속도와 품질 사이에서 지속적인 저울질을 해야 하는 경우가 많다. 비즈니스의 요구를 빠르게 반영해야 서비스가 성장할 수 있으므로, 레거시를 개선하지 못한 채 끌려가기도 한다. 하지만, 안정적으로 서비스를 운영하는 기반을 마련하기 위해서는 빠른 개발 속도 뿐만 아니라 풍부한 기술적 경험도 필요하다.
메이커는 만드는 것을 즐기는 사람이다. 무엇인가를 만들고, 그것이 시장에서 증명받는 것이 즐거운 사람이다. 사람들이 내가 만든 것을 즐겁게 쓴다는 것이 행복해서 무엇인가를 계속 만드는 사람이다. 무에서 유를 창조하는 것의 즐거움을 이해하는 사람이다. 다만, 창조의 99%는 실패한다. 실패에 익숙해지고 더 빨리 성공하려면 덜어내야 한다는 것을 알고 있다. 기술적인 깊이를 추구하기 보다는 본질에 집중하고, MVP(Minimal Viable Product)에 집중한다. 재사용가능한 코드 컴포넌트와 낮은 결합도 같은 것보다는 비즈니스 임팩트에 집중한다.
결론
주변의 많은 소프트웨어 엔지니어들은 엔지니어이거나 개발자이거나 메이커다. 그들이 무엇이 되고 싶으냐도 서로 다를 수 있고, 실제 그들이 하고 있는 일도 서로 다를 수 있다.
예를 들어, 나는 최근 개발자, 엔지니어, 메이커의 분류법을 생각한 뒤 내가 어디에 해당하는가 고민해봤다. 개발자일 수는 있지만 천성은 메이커라고 생각했다.
나는 취미로 개발을 한다. 하지만, 취미로 오픈소스를 뜯어보거나 컴파일러를 분해해 보지는 않는다. 취미로 서비스를 만든다. 잘 되든 안 되든 코드를 짜서 서비스를 만들고 시장에 출시를 하고 있다.
내 회사 동료도 취미로 개발을 한다고 말한다. 하지만 내 동료는 서비스를 만들지 않는다. 좋아하는 언어는 Rust이며, 최근에는 Go 언어의 동작 원리가 궁금해 컴파일러를 까 보려고 한다. 기술에 관심이 많고, 깊게 파고 들어가는 스타일이다.
사실, 우리 모두를 아우르는 표현이 개발자 라는 게 맞겟다. 누구는 엔지니어일 수 있고, 누구는 메이커일 수 있지만 우리 모두 코드를 짠다. 우린 개발자다. 하지만 한 편으로, 누군가는 엔지니어이고 누군가는 메이커라고 생각한다. 그리고 어느 극단에도 치우치지 않은 대부분의 사람들이 개발자가 아닌가 싶기도 하다.