엔지니어와 메이커의 정의 | 메이커

메이커

앞서 우리는 엔지니어에 대해 알아보았다. 다들 알고있는 개발자의 상이지 않은가?

앞에서 보았던 것 처럼 엔지니어 성향을 가진 사람들은 기술에 대한 열망과 호기심이 강한 개발자라고 할 수 있었다.

하지만 우리 곁에는 엔지니어와 같은 개발자만 존재하지는 않는다.
 

이젠 메이커에 대해 살펴볼텐데 예시를 하나 들어보자.

어느 한 플랫폼 서비스의 코어 개발자로 근무하는 시니어 개발자 A는 신규유저 유치 이벤트를 위해 플랫폼에 새로운 기능을 추가해야 하니 기존 플랫폼의 인프라를 충당하고 기능개발을 완료하라는 요구사항 티켓을 전달받는다. 아무래도 기존의 시스템과 잘 어우러지고 늘어나는 인프라에 안정적으로 대응해야하니 A 는 보수적인 태도로 기존 구조의 설계를 검토하고 일정을 산정하여 보고하려 한다. 그러자 옆에서 동료의 모습을 보고 있던 개발자 B 가 이렇게 이야기를 한다. "이거 굳이 기존 플랫폼 건드릴 필요 있을까요? 잠깐 진행되고 없어질 기능이라 새로운 서버에서 개발하고 기존 플랫폼에는 연동만 잘 해주면 더 짧은 일정안에 가능할 것 같습니다." 하여 기존 A가 산정한 방법과 일정 대신 B 가 산정한 방법과 일정으로 프로젝트를 진행했고, 회사는 짧은 기간안에 큰 이벤트 효과를 얻을 수 있었다.

A와 B의 차이점은 무엇이었을까? A는 주어진 요구사항에서 최대한 기술적으로 뛰어난 해결책을 생각해내려 했고, B는 주어진 요구사항 이전의 문제 자체에 집중하여 A가 생각한 방식보다 기술적으로 뛰어나진 않지만 합리적인 선에서 기술과 타협하여 문제를 더 빠르고 효과적으로 해결했다.

 

이처럼 엔지니어가 주어진 요구사항 안에서의 기술적인 문제에 중점을 두는 개발자인것과 다르게, 메이커는 실제로 발생한 문제의 해결에 중점을 두는 개발자이다.

 

메이커 성향을 가진 개발자들의 특징

자기 주도성

메이커 성향을 가진 개발자들 또한 엔지니어 성향을 가진 개발자들과 마찬가지로 메이커 성향을 가진 개발자들 또한 지식을 습득하고 새로운 기술이나 도구를 배우는 데에 적극적이다. 더 나아가 때때로 새로운 프로젝트를 스스로 추진하여 새로운 기술과 도구를 적용하고 탐구하며 이 과정을 통해 자신을 계속해서 발전시키고 성장시키고는 한다.

 

이들이 자기 주도적인 학습을 통해 얻은 기반지식은 아무리 어려운 문제가 주어지더라도 확보 해놓은 지식들을 조합하여 남들보다 선제적으로 문제의 해결 가능여부와 해결책을 생각해낼 수 있도록 만들어준다.

 

또한 개발자 출신의 IT 스타트업 창업자들 또한 이 기준에서 메이커 성향을 가진 개발자이다.

올인원 비즈 메신저 채널톡의 최시원 대표
개발자라면 모를 수 없는 프로그래머스의 이확영대표
숙박업의 디지털 전환을 꿈꾸는 온다의 오현석 대표

이외에도 정말 많은 기업들의 대표가 알고보면 개발자로 커리어를 시작한 경우를 찾아볼 수 있다.

필자는 이들이 가진 문제를 해결하고 싶어하는 성향과 그 문제를 실제로 해결할 수 있겠다는 자신감을 주는 기술적인 역량이 그들 스스로 사업을 시작하도록 하는 계기가 되어주었다고 본다.

 

대충 만들기

처음 창업전선의 대표로써, 혹은 스타트업에 초기 창립멤버로  뛰어드는 엔지니어 성향의 개발자들이 흔히 하는 실수가 있다. 그것은 실제 비즈니스를 하는것보다 짜임새있는 설계와 읽기좋은 코드를 짜내는데에 정신이 팔리는 것이다. 물론 "Clean Code" by Robert C. Martin 책이 남녀노소를 가리지 않고 개발자의 성경으로 여겨질만큼 클린하게 짜는 것이 중요하긴 하지만 본질적으로 해결해야 할 문제는 크고 쓸 수 있는 자원은 제한 되어있다.

 

같은 상황에서 메이커 성향을 가지고 있는 개발자들은 제한된 자원으로 최대한의 성과를 내기 위해 창의적인 방법을 모색하며 도입부에서 말한 것과 같이 기술적인 우아함보다 실질적인 문제의 해결에 더 무게를 두고 있기 때문에 우아하지 못하다고 평가되는 라이브러리 또는 프레임워크라도 효율적인 측면에서의 장점이 뛰어나다면 감수하고 사용하는 모습을 보여주기도 한다. 심지어 노코드로 코딩 없이 MVP(최소기능제품)를 만들어내는, 같은 개발자의 입장에서 어처구니 없어보일 수도 있는 사례도 찾아볼 수 있다.

 

하지만 대충 만든다고 그저 못나기만 코드는 아니다. SNS로 히트를 친 하상욱 시인의 한마디가 있다.

 

남이 하는 일이 쉬워 보인다면, 그 사람이 잘하고 있기 때문이다.

잦고 많은 실험에 대응할 만큼의 빠른 개발속도에 최소한의 좋은 코드와 설계의 적절한 균형을 맞추어 코드를 작성하려면 당연히 그냥 개발만 하는 것 보다 역량이 더 높아야 한다. 정말 올바르게 된 메이커는 사실 이미 엔지니어링에는 도가 텄다는 뜻이다.

 

실험, 프로토타이핑

메이커 성향을 가진 개발자들은 남들보다 빠르고 독창적인 방법을 활용하여 새로운 기술을 적용해보고 실험을 통해 자신의 아이디어를 검증하는 능력이 뛰어나다. 또한 이들은 아이디어를 구현하기 위해 빠르게 프로토타입을 제작하고 실험한다. 이를 통해 아이디어의 타당성을 확인하고 개선하는 과정을 거치는 것이다.

 

이 특징은 한편으로 어떤 사람들의 눈살을 찌뿌리게 하는 부작용을 가지고도 있다. 가볍고 빠르게 실험하는 모습이 마치 대충 일하는 듯한 인식을 주거나 전문성이 떨어지는 것 처럼 보이게 만든다. 특히 유지보수성을 제 1의 목표로 삼는 엔지니어들에게 자주 눈엣가시가 된다.

 

특히 다른 개발자들과 맞닥뜨리게 되는 불편한 상황이 이 특징에서 나오는데 예를들어 어째서 처음에 이 코드를 만든 개발자는 이토록 얼기설기 얽어놓은 설계를 해놓은건지, 어째서 기존 서비스와 다른 스택으로 개발을 했는지 등의 챌린지를 받고는 한다. 그렇다고 이 챌린지들을 듣고만 있으라는 것은 아니다. 여기 개발자 A의 이야기가 있다.

개발자 A 는 Java 와 Spring Boot 기반의 솔루션을 운영하는 회사의 새로운 팀에 합류하게 되었고, 해당 팀에서의 유일한 개발자였던 A는 팀이 해결하고자 하는 문제들을 다방면으로 파악하고 분석했으며 단신임에도 불구하고 팀이 움직이는 속도에 맞추어 해결방법들을 빠르게 제시하기 위해 빠르게 코드를 작성하거나 수정할 수 있는 Python, 기능을 손쉽게 추가할 수 있고 다양한 유틸리티들을 지니고 있으며 훌륭한 Boilerplate 를 제공하는 Django 를 선택한다.
하지만 그로부터 1년 뒤 팀의 서비스는 안정적으로 피봇되었지만 여전히 회사의 인력풀은 Java 개발자에 쏠려있었으며 그동안 이루어진 많은 제품적인 실험들과 기능추가로 여러차례 덧대어진 코드베이스는 함께하게된 개발자들에게는 큰 시련이 되어 급기야 초기 개발자인 A 의 원망까지 한다.

개발자 A는 팀을 궤도에 안착시키는데에 큰 역할을 해냈으며 그 업적은 기릴만 하다.

하지만 결과가 좋은 것과 대비하여 과정 중에 생성된 좋지않은 코드들은 이후 개발자들에게 어려움이 되었을 뿐이다.

 

먼저 코드의 의도와 그로인해 얻은 효과들을 함께 일하는 개발자들에게 설명하여 이해시킬 필요가 있으며, 실험이 완료되어 지속가능해진 코드들은 반드시 빠른 시일안에 유지보수에 알맞는 코드로 리팩토링을 거칠 필요가 있다. 또한 경우에 따라 선택했던 스택으로 구축된 코드들을 포기하고 회사의 주력 언어인 Java 로의 이관도 생각해볼 수 있다.

 

비개발적인 역량

메이커 성향을 가진 개발자들은 다른 개발자나 특히 비개발직군과의 협업에 비 개발직군의 동료들과 협업하는데에 있어 높은 커뮤니케이션 능력을 보여준다.

 

폭포수 모델보다 애자일 모델이 주가 된 지금의 제품개발 문화에서는 프로젝트의 시작부터 모두 같은 방향을 보고 나아갈 수 있도록 팀원들과 함께 논의하고, 일의 진행 상황을 공유해야한다.

 

이들이 가진 기술적인 지식들을 각자가 속한 업계의 도메인과 융합하여 새로운 아이디어를 먼저 제안하는데에 능숙하며 간혹 제품에 대한 이해도가 실무 PO 들과 비슷할 정도의 개발자들은 직군 특성상 가장 먼저 데이터를 조회 및 분석할 수 있다는 점을 활용하여 새로운 가능성을 제시하거나 퍼널의 허들이 되는 부분을 파악해 공유하는 사례도 생긴다.

 

제품에 대한 이해도가 높기 때문에 누락된 기능이나 논의중에 고려되지 않아 발생한 설계상의 구멍 등을 발견한다면 곧바로 공유하고 자가대응할 수 있는 역량 또한 가지고 있다.

 

물론 이들이 가진 강점이 목소리를 크게 내는 것 만은 아니다.

 

의미있는 인사이트를 제공하기 위해서는 개발적인 역량도 어느정도 수준 이상 가지고 있어야 한다. 인사이트를 제품의 개발 초기단계부터 지속적으로 제공하여 짧게는 적은 커뮤니케이션으로 빠른 개발을 진행할 수 있다는 장점을 가질 수 있고 제품의 목적과 의도를 개발자도 함께 인지하고 있기 때문에 길게는 탄탄한 설계측면에서의 이점을 가져갈 수 있다.