🏠 세상은 풀스택 장인을 필요로 합니다.
2023-12-16
2021년도 쯤에 Anton Keks 의 발표를 하나 봤다.
발표의 제목은 “The World needs Full-stack Craftsmen”.
이 발표는 지금까지 내가 성장해온 방향에 큰 영향을 끼쳤고, 꼭 한 번 다시 정리해보고 싶었어서 다시 정리해본다.
The World needs Full-stack Craftsmen
발표자는 codeborne 의 CEO 인 Anton Keks.
2010년 설립, 39명의 풀스택 개발자. 다른 직군은 거의 없다.
에스토니아에서 가장 큰 기업들과, 전세계에 다양한 기업들을 클라이언트로 가지고 있다.
클라이언트들은 어떻게 그렇게 적은 사람들로 이렇게 빠르게 일하나며 언제나 놀란다. (70명이 하는 프로젝트를 4명의 팀으로 완성함)
누군가 효율성 때문에 고민하면, 그 팀의 크기를 절반으로 줄이라고 조언하며, 그것이 더 팀을 빠르게 만들것이라고 주장.
문제: IT 의 비용 증가
IT 는 비즈니스와 정부와 같은 paying customer 들을 서포트 하기 때문에 존재한다.
그러나 현재 IT 산업은 지나친 전문화(Overspecialization)로 효율성이 하락.
웹 개발, 안드로이드 개발, ios 개발을 위해 똑같은 UI 를 3번에 걸쳐서 만들어야함.
대부분의 앱들은 사실 불필요(웹 앱으로 대체 가능), 필요한 전문성만 불필요하게 더 늘어났다.
거기에 끝이 아니라, 백엔드 개발자들도 존재하고, 마이크로서비스, 플랫폼 팀도 있다.
이건 낭비다!
이건 마치 왼쪽 귀 전문 의사에게 갔을 때 의사가
“왼쪽 귀는 아주 괜찮습니다” 제가 이제 오른쪽 귀 전문 의사를 추천해드릴게요.
라고 하는 것과 같다. 얼마나 비효율적인가?
풀스택 의사였다면 이미 진단을 끝내고 처방을 내주었을 것이다.
현재 IT 프로젝트들은 과하게 전문화되어있다.
한 프로젝트에 20명의 사람이 있을 때, 주요 1~2명(etc. ios developer) 이 그만두거나 버스에 치이면 아무도 터치할 수 없는 코드만 남고 프로젝트가 망할 수 있다. 20명 분의 프로젝트 매니징 비용, 임금을 위해서 언제든 망할 수 있는 더 느리고 비싼 프로젝트가 될 뿐이다.
풀스택 개발자의 장점
풀스택 개발자는 지나친 전문화로 인한 IT 의 비용 증가에 좋은 해결책이다.
- 많은 영역에 대한 폭넓은 이해도
- 작업을 위한 최적의 툴을 선택할 수 있다.
- 새로운 기술을 빠르게 배울 수 있다.
- 남을 블레임 하거나 콕 찝어서 욕할 필요가 없다. (collective code ownership)
XP의 collective code ownership.
프로젝트의 모든 측면을 배우고, 직접 수정, 빌드할 수 있다. 문제가 생기면 다른 팀이 해결하기를 기다리지 않고 직접 해결할 수 있다. 다른 누군가가 하겠지 하고 남겨두지 않는다.
힘은 책임에서 나온다.
풀스택 개발자되기 첫걸음
“어떻게 모든것을 알 수가 있나요?” → 사실 모든 것을 다 알 필요는 없다. 그것은 불가능하다.
풀스택은 그 “특정 프로젝트를 끝내는데 필요한 기술들”에 대한 풀스택이다.
기술과 전문영역은 계속해서 새로 오고 간다.
ai 와 자동화는 오고 있다. 유연해야 하고 배움을 멈추지 말아야 한다.
풀스택 개발자는 더 유용해지고, 그러므로 더 많은 보상을 가져간다.
고객과 직접 소통하는 소프트웨어 장인 (Craftsmen)
IT 업계의 사람들과 커뮤니케이션 하는 것은 어렵고 그 중에서도 개발자와 커뮤니케이션 하기가 가장 힘들다.
미들맨을 통해 고객과 이야기하는 것은 협상이 불가능하게 만든다.
메신저(프록시)를 향해 아무리 이야기를 많이해도, 제대로 전달이 될 수 없는 구조이다. 개발자들은 메신저를 통하지 않고, 그들의 고객과 직접 소통할 필요가 있다.
고객과 직접적으로 소통하지 않으면 위와 같은 결과들이 나올 수 밖에 없다.
물론 비효율적으로 잘못된 결과를 만들어냄에도 불구하고, 우리(IT)는 돈을 많이 받는다.
가난한 고객은 IT 업계로부터 버그와 잘못된 상품을 받게된다.
느린 IT 로 인해서 며칠간 시장 출시를 하지 못하는 분들에게 유감을 표한다.
스스로를 craftsman 으로 지칭하는 것은 우리가 단순한 개발자나 프로그래머가 아니라는 사실을 상기시킨다.
소프트웨어 장인은 이와 같아야 한다
- 고객과 직접적으로 이야기한다.
- 고객이 해결을 위해 제안하는 것 그대로 하지 않고, 이면에 숨겨진 문제를 이해한다
- 해결책을 제안한다.
- 문제를 작은단위로 부수고, 유저 중심적인 story로 적는다
- UI flow 를 디자인한다
- 코드를 짠다
- 퇴행을 막기 위한 자동화 테스트를 쓴다
- 실제 유저에게 전달한다
- 시스템 디자인/아키텍처를 리팩토링으로 개선한다.
스타트업의 사람들은 살아남기 위해 풀스택 장인정신을 실현해야 한다.
모든 것을 가능한 한 단순하게 만들되, 그보다 더 단순하게 만들지는 마라. - 아인슈타인
언더엔지니어링을 경계하라
지나친 전문화를 오버엔지니어링이라고 본다면, 언더엔지니어링은 다른쪽의 극단.
초기 스타트업에서 매우 흔하다.
실제로 필요한 것보다 지나치게 나쁜 코드를 작성하는 것. 나쁜 코드는 조직의 속도를 늦춘다.
언더엔지니어링은 기본적인 연습의 부족.
장인은 무엇을 하지 말아야 하는지를 알기에, 5배는 더 효율적일 수 있다.
우리는 코드를 쓰는 것 만을 하는 것이 아니라, 결국 문제들을 해결하는 것이다.
발표 3줄 요약
- 현재 IT 는 전문 영역이 너무 많이 분리되어 있다
- 각 분야의 전문가들끼리의 커뮤니케이션 코스트는 프로젝트의 비용을 늘린다
- 미들맨을 없애고 개발자가 직접 고객을 만나라
- 개발자는 장인이 되어야 한다
후기
- 코드에 대한 온전한 책임(collective code ownership)을 가진다는 것은 영향력의 증가를 뜻한다.
- 백엔드 개발자가 문제를 발견했어도, 프론트엔드가 할 일이라 생각하고 못 본척 할 수도 있다.
- 반면에 풀스택은 모든 코드에 접근할 수 있고 수정할 수 있다.
- 못 본채 하는 건 허용되지 않는다. 직접 고쳐야 한다는 것은 곧 책임진다는 것.
- 책임은 힘이 된다.
- 프로젝트에 크고 긍정적인 영향력을 가져올 수 있음.
- 발표자가 SI 업체의 대표이기 때문에 일반적인 스타트업과는 다르게 생각해야 할 부분도 있기는 하다.
- 자기 회사의 프로덕트를 계속해서 운영해야 하는 경우 롤이 명확하게 나뉘어진 것의 안정성도 무시할 수 없다.
- 무엇보다 풀스택은 사람 구하기가 힘들다.
- 보통 전문화된 영역이 있어야 큰 회사로 이직할 때 유리하기 때문에 풀스택을 잘 하지 않으려 함.
- 극초기 스타트업이라면 PMF 를 찾기 전까지는 풀스택 개발자만으로 운영하는게 좋다고 생각.
- 기술 기반의 창업이 아니라면 초기 스타트업의 스택에는 특별한 전문성이 필요하지 않음.
- 소수의 풀스택 개발자 위주로 운영되는게 효율 면에서 베스트라고 생각한다.
- 위에서 이야기한 개발팀의 파괴력을 정말 강하게 만들어줄 수 있다.
- 언더엔지니어링은 수행만이 살 길
- 풀스택을 하게 되면 아무래도 전문성이 분산되기 때문에 년차에 비해 실력 발휘가 부족할 수 있음.
- 실력이 부족해서 적정엔지니어링을 “못”하고 언더엔지니어링을 하는 건 바람직하지 않다.
- “약간”의 노력으로 코드를 더 좋게 만들 수 있다면 그렇게 하는게 당연히 맞다.
- TDD, DDD, MSA 등등 일반적으로 오버엔지니어링이 되기 쉬운 힙해보이는 기술들을 “약간”의 노력을 더하면 쓸 수 있을정도로 능숙하게 쓸 수 있다면 안 쓸 이유도 없다는 것.
- 물론 구축 뿐만 아니라, 복잡도 증가에 따른 생산성 저하도 없을(혹은 약간 있을) 정도로 능숙해져야.
- 미리미리 공부를 많이 하는 수밖에..
- 고객과 직접 이야기하는 개발자가 될 수 있다면.
- 이전 스타트업에서는 고객을 직접 만나서 소통해보지는 못 했지만 CS 대응을 직접 해봤던 경험은 있었다.
- 장애와 불편에 대한 깊은 공감대가 생기고, 더 나은 프로덕트에 대한 책임감이 강화.
- 상대적으로 내향적인 사람들이 많은(나도..) 개발자들이지만 가능하다면 고객을 만나보는게 좋지 않을까.
- 내가 만든 프로덕트가 실제 세상에 영향을 끼치는 것을 목격하는 건 정말 꿈같은 일.