부족하게 만들 용기 - 개발자의 딜레마
새로운 기능과 제품을 만들때 고민되는 지점이 있다.
- 누가 쓸지, 어떤 문제를 겪고 있는지
- 어떤 기능과 결과물이 필수인지
- 얼마나 완성도있게 만들지
- 언제까지 만들지
- 어떻게 사용을 편하게 할지, 사용법이 쉬운지
그러나 기획 의도와 방향을 정하고 프로젝트를 진행하면 늘 변수가 생긴다.
코딩, 개발 시간은 예측하기 어렵고 수 많은 제품 디자인적 의사결정이 필요하고
복잡도 설계와 적절한 순차적 구현 우선순위, 정책적인 함축까지 소프트웨어 엔지니어링적인 판단이 필요하다.
다행히 개발자들은 자연스럽게 개인 프로젝트부터 팀, 조직까지 경험을 쌓으며 성장하는 것으로 보인다. 어디가 어려울지 리스크도 예측하고, 언제부터 결합하여 테스트를 해봐야할지 직감적인 능력이 생긴다.
혼자서 일하는게 아니라 여러명과 함께할때도 많은 커뮤니케이션 능력이 필요하다. 점점 타인에게 기술적인 내용을 이해하기 쉽게 표현하고 설명할 수 있게된다.
복잡성 높은 어려운 구현 문제를 다루며 만족감을 얻는 개발자로 있으며, 혼돈을 감싼 사람-사람 문제를 시스템으로 해결하며 만족감을 얻는 개발자도 있다.
이는 공통점이 있다. 문제를 잘 나눈다. 문제-해결 적합성을 빠르게 인지하고 적절한 시점에 점진적인 개선을 지속적으로 전달(배포)하면서 현실 세계의 문제를 빠르게 진전(완화)시킨다.
완벽한 근본적 해결책이 아닐지라도 매일 매일 고통받는 문제를 약간이나마 소화시키고 조직의 더 큰 문제를 다루기 위해 떠난다.
아무것도 안하는것보다 한 그루의 나무를 심는 분들이 있다. 개발자로 볼수있는 빌더, 메이커 모두에게 너무나 중요한 태도이다.
한정된 예산(시간, 비용, 인원)으로 최상의 결과물을 요구받는 현실은 개인, 회사, 팀원, 팀장, 경영진의 입장이 똑같다.
우리는 과연 문제를 잘 해결하고 있는지, 완벽한 해결책을 찾지못해도 잘 진전시키고 있는지, AI를 포함한 내가 가진 능력으로 주변 사람을 돕고 있는지, 한정된 리소스로 좋은 결과물을 뽑아내는 위대한 엔지니어가 되고 있는지. 잘 생각해보아야한다.
이런 맥락에서는 늘 완벽을 추구하는게 아닌 "제가 봐도 못만들었어요." 할수있는 용기가 필요하다.
첫 단추가 중요하다. 비록 unrefined, rough, unpolished, inelegant 하더라도 엔지니어, 개발자의 강점은 다른 곳에 있다. 프로젝트, 제품, 시장(고객 마음)을 움직이는걸 목표로 해야한다.
디테일은 혼자서 하기 어렵다. 제품 기능은 늘 숙성이 필요하고, 개발자가 아닌 사람들 의견, 생각이 모여야 완성된다. 이것을 잘 듣고 수렴하는 기본 자세가 개발자에게 더 중요하다.
일부러 못만들기 위한 시도를 해보았는가? 본인의 가꾸어진 코드 수준, 당연히 해야하는 상향 평준화된 기준을 버리면서 프로젝트를 진행하는게 더 어렵다. 굉장히 자신을 내려놓고, 욕심을 버리고, 본질에만 집중해야 가능하다.
누구는 잘 만들기 위해 '더 많이 앎'을 선택한다. 얼마전에 알게된 새로운 프레임워크, 오픈소스, SaaS만 추구하는건, 이는 장비 욕심과 다름이 없다.
빨리 도달하기 위해 적절한 도구를 선택가능하도록 평소에 학습, 실험을 많이 해보는게 중요하더라도. 내 스택-장비를 갈아치울지는 본인의 의사결정이다. 정답은 없고 개인 스타일이다.
개발자(빌더, 메이커)는 세상에 할 일이 정말 많고, 가능성도 크다. 언제 없어질지도 모르는 프로젝트를 새롭게 시작하고, 무참히 쌓은 짚더미에서 큰 빌딩으로 성장한다.
내가 할줄 아는 것중에서 버릴 기술을 잘 생각해봐야한다.
하지말아야할 스킬을 고민해보아야한다.
'어드민의 본질'을 진정성있게 깨달은 분들은 더 이상 운영 환경, 데이터 제공을 위한 계층(layer)를 새로 쌓지 않는다. 'Visual Layer for API' 서비스를 제공하면서 보았다.
기본적인 운영 레이어가 있다면 서비스 회사는 많은 고민이 해결된다. 내가 할수 있지만 하지 않는 것도 큰 용기가 필요하다.
이런 선택에 더 절대적인 지지를 보내고, 도구의 수준도 함께 향상하고 있다.
앞으로도 개발자들이 더 중요한, 임팩트 있는 일을 했으면 좋겠다.
