요약
스타트업은 기술자를 길러 내지만, 그 기술자는 자기 제품이 어떻게 쓰이는지 외면하기 쉽습니다.
Clojure 개발자 잭 텔먼이 스타트업 두 곳에서 일한 경험을 돌아본 글입니다. 그는 기술 문제에 몰두하느라 사업 모델과 제품의 쓰임을 제대로 보지 못했다고 반성합니다.
왜 중요한가
- 회사가 멈춰 설 때 기술을 고치는 일이 답이 아닐 수 있으며, 저자는 근본 문제를 사업 모델에서 찾았습니다.
- 면접은 자료구조와 복잡도를 묻지만 현장에는 제품 맥락을 아는 엔지니어가 필요합니다.
- 저자의 결론대로면 제품의 나쁜 쓰임은 개인의 양심을 넘어 기술자 집단의 책임이 됩니다.
핵심 내용
- 첫 회사 루나는 성장이 멈추자 올 성장에 대비하며 코드만 조심스럽게 다뤘고, 재구축을 주장한 저자는 3주치 퇴직금을 받고 나왔습니다.
- 장소 데이터 회사 팩추얼은 대형 고객이 적어 광고 쪽으로 기울었고, 2020년 포스퀘어와 합병했습니다.
- 디지털 광고는 효과를 재기 어려워, 거래 사슬의 각 단계가 바로 앞 구매자에게 팔릴 만한 것을 팔았다고 합니다.
- 스타트업은 절차가 적고 실패 피해가 작아 신기술을 쉽게 들이며, 그래서 기술자 훈련장이 됩니다.
- 저자는 라이선스로 나쁜 용도를 막을 수 없다며 공동 책임을 말하지만, 구체적인 방법은 모르겠다고 인정합니다.
HN 반응
- 자기 자본으로 꾸리는 작은 회사나 산업 자동화처럼 현실 문제를 푸는 곳에서 보람을 찾았다는 경험담이 이어졌습니다.
- 제품 관리자와 마케터를 뽑아 그 말을 들으면 된다는 반론과, 기술자가 평가하기 쉬워 우대받는다는 분석이 나왔습니다.
기술자 겸 제너럴리스트라면 작은 회사를 노리는 게 좋은 전략입니다. 실리콘밸리 밖이라면 더 좋고요. 진짜 풀뿌리 사업, 겉보기엔 소프트웨어가 아닌 정말 흥미로운 문제 영역에 들어가게 될 수도 있습니다.
저는 소프트웨어를 위한 소프트웨어 산업을 도저히 견디지 못하겠습니다. 당신도 나도, 우리 모두 임의로 만든 헛짓거리 기계를 쌓아 올렸고, 그것들이 쓸데없는 비즈니스의 그물로 서로 얽혀 있습니다. 우리는 중복된 일자리와 쓸모없는 관리직을 비난하지만, 우리 업계가 순전히 자기 좋자고 얼마나 많은 소프트웨어를 만들어 왔는지도 한 번쯤 돌아봐야 합니다. 소프트웨어의 덧없는 변덕에 얼마나 많은 인력과 시간을 쏟았습니까. 냉소적으로 말해서 미안합니다.
덜 냉소적으로 말하자면, 회사가 작고 자체 자금으로 굴러갈수록 제너럴리스트가 잘 크고 사업 영역도 현실 세상에 닿아 있어 영향력이 있을 가능성이 높다고 봅니다. 벤처 투자를 받은 회사는 광고로 피벗할 수 있으면 아마 그렇게 할 겁니다. 기술 중심지에서 벗어나면 임금은 낮아도 더 보람 있는 일을 찾을 수 있을지 모릅니다.
진입하기는 어렵지만, 산업 자동화는 엄청나게 만족스러울 수 있습니다. 코드 자체는 '진짜' 소프트웨어 엔지니어링에 비하면 꽤 단순하지만, 현실 세계의 진짜 물리적 문제를 풀고 눈에 보이는(그리고 종종 수익성도 좋은) 물리적 결과가 나옵니다. 분야가 워낙 여러 갈래에 걸쳐 있어서 직접 손으로 만지는 일을 좋아하면 언제든 그렇게 할 수도 있습니다. 말하자면 궁극의 '풀스택' 개발 직군입니다.
경력 있는 소프트웨어 개발자가 산업 자동화로 들어가려면 어떤 길이 있나요?
원 댓글 작성자는 아니지만, 저는 예전에 작은 박물관 전시물 제작 업체에 '기술 담당'으로 신입급으로 들어간 적이 있는데, 거기서 같이 일하던 많은 분들(납품업체나 외부 협력 제작사 사람들)이 PLC나 래더 로직 같은 걸 가르쳐 줬어요.
정말 엉망진창인 분야라서 구체적인 사정은 회사마다 천차만별입니다. 규제가 더 많은 분야의 회사는 지멘스 같은 고급 장비로 표준화할 자금이 있을 수 있지만, 작은 제조업체는 표준이 아예 없을 수도 있고, 그러면 록웰, 앨런-브래들리, 허니웰, 그보다 더 마이너한 브랜드의 PLC가 뒤섞여 있는 걸 보게 됩니다. 많은 벤더가 '독자' 언어를 쓰지만 전부 기본적인 수준이고, 본질적으로 비주얼 베이직, C, 자바스크립트 비슷한 것들입니다. 여러분이 익숙한 정식 소프트웨어 개발 환경 같은 건 없습니다. 규제가 덜한 환경에서는 PLC나 자동화 부분을 정비나 시설 관리 담당자들이 맡고 있는 경우가 많습니다.
제가 지금 겪고 있는 문제를 예로 들어 보겠습니다. 우리에겐 진공로(vacuum furnace)가 몇 대 있습니다. 티타늄을 쓸 만한 임플란트로 만들려면, 먼저 티타늄을 발화점보다 높은 온도에서 구워야 합니다. 그래야 분자가 충분히 느슨해져서 단조 과정에서 쌓인 응력이 풀리거든요. 이 공정에는 감도가 서로 다른 열전대 8개와 압력/진공 센서 최소 3개가 모두 '차트 레코더'에 물리적으로 배선되어 있습니다. 열전대 '데이터'란 말 그대로 전압 값이고, 차트 레코더가 그걸 해석해서 정수로 바꾼 뒤 RAM에 저장합니다. 이 장비들은 20년쯤 된 것들이고 24시간 분량의 데이터밖에 담지 못해서, 이 공정 단계가 제대로 수행됐다는 걸 누군가에게 증명해야 할 때를 대비해 그 값을 저장해 줄 서버와 네트워크로 연결해야 합니다. 기술적으로 복잡한 건 아니지만, 이 장비들은 다루기가 쉽지 않고 설정을 바꾸려면 직접 물리적으로 연결해야 하는 경우가 많습니다.
다른 제조 시스템, ERP 시스템, 데이터 분석과 시각화와의 정말 의미 있는 연동 가능성이 온갖 곳에 있고, 이 분야에는 기술이 조금이라도 있는 사람이 부족해서 아무도 손대지 못하는 '손쉬운 과제'가 그야말로 수백만 개 있습니다. 제가 일해 본 회사 대부분은 해결책이 뭐가 되든 신경도 쓰지 않아서, 해결책을 설계하는 데 재량이 엄청나게 많이 주어집니다.
제 생각에 가장 좋은 점은 뭔가를 이루고 있다는 느낌이 든다는 겁니다. 진짜 영향을 주고 있다는 느낌이요. 작업 현장을 돌아다니면 내가 짠 코드가 물건을 만들고 있는 게 보입니다. 뭔가를 하고 있죠. 문제를 들고 찾아온 엔지니어가 누군지 알고, 내가 해법을 내놓아서 그 사람이 편해졌다는 것도 압니다. 분기 보고서의 추상적인 숫자를 올리려는 게 아니라, 실제로 쓸모 있는 것을 만드는 일이니까요.
와, 저도 그런 일 하고 싶네요.
요즘 들어 돈 받고 할 수 있는 소프트웨어 일이 결국 소셜 미디어 감시, 무장 드론, 그리고 그 둘을 돌리는 클라우드 인프라만 남을까 봐 겁이 났거든요.
이 직군에서 만난 사람들은 모두 걸어온 길이 달랐습니다. 저처럼 소프트웨어 엔지니어였던 사람도 있고, IT나 네트워크 기술자로 있다가 자동화에 발을 들이면서 전자, 전기, 기계 하드웨어를 더 배운 사람도 있습니다. 전기 기사나 통신 기술자, 유압 설비공, 기계 엔지니어로 일하다 PLC 프로그래밍을 배운 사람들도 있고요.
더 넓게 보면 임베디드 시스템도 있습니다. 다만 그쪽도 '진짜' 소프트웨어 엔지니어링에 비해 항상 단순한 건 아니지만요.
임베디드 소프트웨어가 산업 자동화보다 확실히 더 '진짜' 코딩이긴 합니다. 다만 그건 산업 현장 수준에서는 그쪽으로 깊이 파고들 계기가 많지 않기 때문이기도 해요.
이 글은 우리가 배우려면 실패를 키워야 한다는 입장인 것 같습니다. 실패를 키울 필요는 없습니다. 실패는 이미 차고 넘치니까요. 사람들이 자기 실수를 직접 저지를 수 있게 해 줘야 한다는 건 맞지만, 그건 같은 얘기가 아닙니다.
실패를 키우는 것과, 성공을 추구하다가 실패할 수도 있다는 각오를 키우는 것은 다릅니다. 많은 사람이 실패하는 것(또는 실패했다고 여겨지는 것)을 너무 두려워해서, 100% 안전하지 않은 일은 아예 시도조차 하지 못합니다.
맞아요. 제 말은, 경험이 없는 사람들에게는 이 좋은 조언을 납득시키기 어렵고 믿지 않는다면 억지로 따르게 해선 안 된다고 말하는 것과, 실패할 기회를 빼앗을 수 있으니 이런 조언을 하지 말아야 한다고 말하는 것은 다르다는 겁니다.
“이걸 어떻게 해결하죠?”
정말 뭘 하는지 아는 다른 사람들, 즉 프로덕트 매니저, 마케터, 디자이너 같은 사람들을 고용하고, 여기서 중요한 부분인데, 그들의 말을 듣는 겁니다. 기술자가 아닌 사람들, 번쩍이는 위젯을 만드는 일을 하지 않는 사람들이 있고, 그들에게는 그래도 쓸모 있는 기술이 있습니다. 우리가 그냥 열심히 생각한다고 해서 쉽게 따라 할 수 없는 기술이요.
분업을 지금 다시 발견하고 있다니 믿을 수가 없네요. 일부 테크 브로는 정말 그 정도로 맛이 갔나 봐요.
저희가 다들 워낙 똑똑해서 그렇죠. 이해해 주셔야 해요.
여담인데, 사람들이 이런 회사에서 일한 경험을 회사 이름까지 밝히며 노골적으로 쓰고, CEO와 동료들에 대한 일화까지 풀어놓는 게 흥미롭습니다.
존 케일(John Cale)이 속담을 바꿔 한 말을 빌리자면 이렇습니다.
"내려오는 길에 계단에서 만나자. 뭔가 잘못된 게 있었는지 보게 될 테니까."
저도 제가 일했던 곳에 대해 이야기하고, 과거에 글로 쓴 적도 있습니다. 하지만 무능하거나 잘못한 사람들을 보호하려면 이름을 바꿔야 하고, LLM이 엮어 낼 수 있는 일화를 그냥 쏟아내서는 안 된다는 걸 많은 사람이 모르는 것 같아서 흥미롭습니다.
블로그 글 하나 때문에 입이 가볍다는 평판을 얻지 마세요.
받아들이기도, 삼키기도 힘든 사실입니다. 결국 우리는 애초에 그 소프트웨어를 의뢰한 의사결정자들에게서 몇 단계 하류에 있는 겁니다. 그들은 장기적인 관점이 있고, 설령 우리가 단기적으로 이게 장기적으로는 잘 안 풀리겠다고 알아봐도 마찬가지입니다. 그걸 안정적인 월급과 양립시키기는 어렵습니다.
그러면 제품 결정에 직접 뛰어들어 방향을 조금이라도 틀어 보려고 영업팀과 일할 수도 있지만, 그것도 나름의 문제가 다 있습니다(글에서도 한 직장에 대해 "영업 담당자들을 꼬드기는 영업 담당자들을 꼬드기는 브랜드들을 꼬드길 만하다고 생각한 건 뭐든 팔았다"고 했죠).
대부분 회사에서 소프트웨어의 장기적인 전망이 이렇다면, 사람들은 어떻게 보람을 찾습니까?
방향을 조금 틀어 보려고
...그렇게 하다 보면 어느 순간 당신이 장기적인 관점을 갖고 결정을 내리는 사람이 되고, 몇 단계 하류에 있는 누군가가 당신 아이디어의 문제점을 알아보게 되겠죠?
VC 공식에서 벗어나서, 나 자신과 주변 사람들에게 세상에 무엇이 있어야 하는지 물어보세요. 세상에 없는 게 뭘까요? AI를 공동 창업자 삼아 기본 기술인 html, css, js, sqlite로 프로토타입을 만드세요. 반응을 얻으세요. 고객 응대를 직접 하면서 사용자에 대한 진실을 확인하세요. 그러다 진짜 반응이 오는 걸 찾으면 그때 규모를 키우는 얘기를 하세요. 훨씬 많이 배우고 더 잘하게 될 겁니다.
AI한테 물어보지만 않는다면요. AI는 계속 똑같이 밋밋한 스타트업 아이디어만 내놓고, 거버넌스/규제 증빙 수집 시장은 아마 스타트업으로 꽤 붐빌 것 같아요.
무엇이 있어야 하는지, 세상에 없는 게 뭔지에 답하려면 세상이 어떻게 되기를 바라는지에 대한 비전이 있어야 합니다. 어디로 갈지는 우리가 지금 어디에 있는지 답한 뒤에 물어야 하고, 그 전에는 우리가 어디서 왔는지, 예전엔 어땠는지 물어야 합니다. 그다음에는 우리가 온 곳에서 지금 있는 곳까지 어떻게 왔는지도요.
정답은 없습니다. 아마 우리가 상상하고 싶은 것보다 훨씬 주관적인 여정일 겁니다.
결국 사람들이 무엇이 되기를 바라는지는 당신이 정하게 됩니다. 무지한 채로 하더라도요.
어느 현자의 말을 인용하자면, 혁명에 노래와 춤이 없으면 난 안 간다.
말도 안 됩니다. 필요한 건 주변에 물어보고 들어 주는 것뿐입니다. 말 그대로 주사위를 던져 아무 나라 X에 가서, 처음 만난 사람에게 뭐가 있으면 삶이 나아지겠냐고 물어보면 됩니다.
어쩌면 그 사람 집 지붕의 빗물받이가 새서 고쳐 줄 사람이 필요할 수도 있습니다. 그렇다면 같은 문제를 겪는 사람이 더 있을 테고, 빗물받이 수리공이 있으면 사람들이 좋아하겠죠.
물론 '거창한 비전'이 있고 (역시 주변에 물어봐서) 그 비전을 공유하는 사람들이 있다는 걸 알게 됐다면, 얼마든지 그 일을 하세요. 하지만 쓸모 있는 일을 찾는 데 '비전'은 정말로 필요하지 않습니다.
무엇이 필요한지는 아무도 모릅니다. 그러려면 삶의 의미를 알아야 하니까요. 적어도 그걸 생각할 시간이 있도록 인류부터 보존해야 할지도 모르겠네요.
아무 [가난한] 나라에 회사를 차려서 사람들을 고용하고 괜찮은 급여를 줄 수도 있습니다. 적자를 감수하고 그냥 돈을 대도 됩니다.
그러면 오랫동안 사람들 주머니에 월급이 들어갑니다. (그 돈으로 빗물받이도 고칠 수 있죠!)
회사가 뭘 해야 할지 주변에 아이디어를 물어보는 것도 합리적으로 들립니다.
그런데 지뢰 수요가 높고 AK-47로 피벗할 여지가 있다고 해 봅시다.
아니면 광고에 눈동자를 팔면 돈이 된다는 걸 알게 되거나요.
다음 증기기관을 만드는 것보다는 확실히 훨씬 쉽습니다.
살면서 몇 시간쯤은 과대망상을 품어도 괜찮습니다. 사람마다 각자 뭘 떠올릴지는 아무도 모르니까요.
저는 핵심 기술을 만드는 엔지니어였습니다. 새로운 기술로 유행을 따라가려다 보니 작업량이 기하급수적으로 늘어나는 걸 봤죠. 그래서 기본으로 돌아갔습니다. https://www.dreamlist.com 과 https://santawho.com 을 만들었는데, 지금처럼 재밌었던 적이 없고 누구에게도 허락을 구하지 않고 계속 해 나갈 수 있습니다.
기술자(technologist)가 관리하기 더 쉬워서라고 생각합니다.
반면 프로덕트 엔지니어는 평가하기가 꽤 애매합니다. 배리 보엠(Barry Boehm)부터 시작해 많은 방법론이 도입됐지만 시간이 지나면 서서히 맞지 않게 되고, 평가하기 어려운 부분도 많습니다. 본질적으로 조직 관리론의 문제입니다. 조직 관리론의 이상은 다양성이 모여 시너지를 낸다는 것이지만, 반대로 그런 다양성이 있으면 조직 내 의사결정이 느려집니다.
반면 기술자는 속도나 코드 품질을 관찰하기가 아주 쉽습니다. 사실 대부분의 사람은 스타트업을 창업하기보다 기술을 배워서 돈을 버는 커리어를 택하고, 그런 관점에서는 '커리어'가 창업자의 커리어보다 직원의 커리어로서 강조되는 경향이 있으니, 그래서 기술자가 강조되는 것 아닐까요?
회사가 역량으로 가치 있게 여기는 것은 결국 측정할 수 있는 평가입니다. 그리고 프로덕트 엔지니어링은 생각해 보면 의사결정자들과의 논의를 전제로 합니다.
'이 기능을 꼭 구현해야 하나요?'
'고객이 정말 이 기능을 필요로 하나요?'
'비즈니스 모델이 틀린 건 아닌가요?'
대부분의 의사결정자는 위계상 높은 사람들이고, 그들과의 마찰은 피할 수 없습니다. 다시 말해 기존의 역할 경계를 넘나드는 일이라 조직 역학에서 갈등이 더 잦아집니다.
그것이 결국 조직에 이득인지 손해인지는 아무도 알 수 없는 일입니다.
퇴직금이 3주치라고요?!
다이나믹 프라이싱이라니. 역겹네요. 정말 고맙기도 하셔라.