기술 업무의 실패한 상품화

• 기술 업무를 공장처럼 표준화해 재현 가능한 산출물로 만들려는 경영·벤더의 기대는 크지만, 많은 현장은 아직 그런 방식으로 안정적으로 상품화되지 못함
• McDonald's식 운영은 품질 자체보다 서로 다른 장소와 인력이 같은 결과물을 내게 만드는 규율에 가깝고, 여러 경영 서적도 IT 운영을 이런 생산 흐름으로 바라봄
• 엔터프라이즈 소프트웨어 판매는 SQL·데이터·개발 업무를 드래그앤드롭과 일관된 인터페이스로 대체해 인력을 교체 가능하게 만들겠다는 약속에 가까움
• 실제 조직에서는 나쁜 소프트웨어 라이선스와 잘못된 추상화가 기술 문제를 해결하지 못하며, 결국 뛰어난 엔지니어가 나쁜 데이터 모델과 기술 결정을 직접 고쳐야 하는 경우가 많음
• 창의성, 취향, 전문성, 사람 간 연결이 필요한 업무는 Jira 보드나 Agile 점수로 완전히 환원되지 않고, 대규모 생산 인프라 안에서도 개별 사람이 시스템을 움직임

---

McDonald's가 보여주는 표준화의 난이도

• 뛰어난 데이터 엔지니어였던 첫 매니저는 요리에 깊이 몰입한 사람이었고, McDonald's 운영의 복잡성을 여러 차례 높게 평가함
• McDonald's의 가치는 산출물 품질 자체보다, 교육 수준과 지역이 다른 직원들이 같은 버거를 만들도록 하는 최적화와 규율에 있음
• 서로 다른 장소의 미숙련 인력이 일정한 결과를 내게 만드는 일은 단순하지 않으며, 이 사례가 기술 업무의 상품화 논의로 이어짐

경영 서적은 IT를 공장처럼 다룸

• The Phoenix Project는 IT 운영을 제조 공장 업무와 비슷한 문제로 놓고, 조직 내 작업 흐름과 커뮤니케이션 관리를 중심에 둠
• 비슷한 정서를 가진 책으로 The Unicorn Project, Investments Unlimited, The Goal이 이어짐
  • The Goal은 실제 공장 운영을 바꾸는 이야기이며, 다른 책들에 영감을 준 작품으로 다뤄짐
• High Output Management도 레스토랑에서 일이 흐르는 방식을 예로 들며, 잘못된 타이밍에 계란을 삶으면 고객에게 도착할 때 토스트가 식는다는 식으로 작업 흐름을 설명함
• 이 계열의 사고에는 규모의 경제, 처리량, 작업 흐름 같은 주제가 반복적으로 등장함

벤더 피치의 핵심은 기술보다 대체 가능성

• 한 벤더 컨퍼런스의 여러 제품 피치는 기술 세부사항보다 충분히 좋은 업무 산출물을 재현 가능하게 전달하겠다는 약속에 초점을 맞춤
• 특정 제품은 SQL을 직접 쓰지 않고 드래그앤드롭 편집기로 의존성을 설정할 수 있다고 홍보함
  • 실제로는 애플리케이션이 Postgres에 연결되므로 SQL이 사라지는 것이 아니라, 라이선스가 붙은 추상화 계층이 SQL을 대신 작성하는 구조임
• 이런 피치는 경영진에게 “느리고 문제 많은 SQL”을 일관된 인터페이스와 시장의 도구 전문가로 대체해, 조직 안에서 데이터 전달을 매끄럽게 만들 수 있다는 메시지로 들릴 수 있음
• Agile이 평균적인 기능 장애 조직에서 구현되는 방식도 비슷한 문제를 드러냄
  • 엔지니어를 기계, 산출물을 부품, story point를 생산 단위처럼 세고 다음 주 목표 달성률을 확인하는 방식임

많은 기술 업무가 아직 상품화되지 못한 이유

• McDonald's는 대체로 5분 안에 일정 품질의 감자튀김을 제공하지만, 많은 기술 조직은 가치 있는 것을 배포하지 못한 채 나쁜 소프트웨어 라이선스를 구매함
• 기술 문제와 나쁜 데이터 모델을 돈으로 해결하는 길은 문제 해결에만 집중하는 뛰어난 엔지니어를 확보하는 것에 가까움
• 상품화가 가능해 보이는 영역도 많지만, 실제로는 작동하지 않는 제품을 파는 회사와 이를 사는 무지한 의사결정자의 조합일 때가 많음
• 일부 의사결정자는 법적 준수를 충족한다는 명목으로 저임금 지역의 전화 지원을 활용하고, 취소하려는 고객을 신경 쓰지 않는 방식도 택할 수 있음
  • 지원 담당자에게 연락해야 할 때 먼저 판매 라인에 전화해 권한 있는 현지 담당자에게 빠르게 연결될 수 있는지 시도한다는 경험도 소개됨

창의적 기술 업무에는 사람의 요소가 남음

• Rich Hickey의 Hammock Driven Development는 연구를 무의식에 넣고, 명상하고, 잠을 자며 설계 해답을 얻는 식의 작업 흐름을 다룸
• 프로그래머들은 문제에서 떨어져 있을 때 답이 떠오르는 현상을 경험하곤 하며, 이는 단순히 위젯을 더 빨리 찍어내는 업무와 다름
• 사회에는 더 빨리 찍어내는 종류의 일이 많지만, 가치 있는 많은 결과물은 정의하기 어려운 창의성과 생산 현실이 만나는 지점에서 나옴
• 책, 음식, 레스토랑 운영 같은 사례에서도 대량 생산이나 전달 체계를 정제할 수는 있지만, 아름다운 결과물에는 취향과 돌봄이 필요함
• 기능 개발을 Jira 보드와 Agile 이야기로 줄이려 해도, 사람과 연결되지 않으면 가치 있는 결과를 얻기 어려움
• iPhone에 들어가는 칩을 설계하는 지인의 사례처럼, 테스트와 대량 생산 인프라가 있어도 특정 개인이 아프면 다음 릴리스가 지연될 수 있을 만큼 개별 사람이 중요한 역할을 함
• 사회가 상품화 위에서 돌아가는 현실은 있지만, 특정 공예에 대한 이해와 사람의 복잡성·필요·취약성을 무시한 순수 상품화만으로는 기술 업무를 운영할 수 없음

[GN⁺]

Hacker News 의견들

• 예전에는 기술 업무로 불리던 것의 상당 부분이 이제 범용 상품화됐다는 점을 글쓴이가 놓친 것 같음
  예전에는 메일 병합이 정말로 주소 라벨을 잔뜩 출력해 편지와 봉투에 손으로 붙이는 일이었고, Word 2.0쯤이 1990년대에 그 문제를 풀었으며 MailChimp가 21세기에 이를 상품화했음
  복식부기도 고도로 훈련된 사람이 하던 기술 업무였지만, 지금은 가게 주인이 바코드를 찍고 고객이 탭 결제하면 됨
  Scratch보다 복잡한 것에 쓸 수 있는 드래그 앤 드롭 인터페이스는 아직 없지만, 어려운 부분은 라이브러리를 엮는 기술 작업이 아니라 요구사항 수집임
  고품질 암호화 라이브러리를 넣거나, 웹사이트에 대화형 지도를 가져오거나, 웹사이트를 WYSIWYG로 편집하는 일은 그 어느 때보다 쉬워졌음
  지루해하는 18살을 IDE 앞에 앉혀 ERP를 만들게 할 수는 없다는 점에서 글쓴이가 맞지만, IT의 많은 잡무는 이제 확실히 상품이 됐음

  • 맞는 말이지만, 잡무의 양은 해마다 일정하지 않음
    기술 산업의 잡무는 줄기보다 늘고 있다고 봄: 현재 잡무가 X만큼 있고, 새 기술 Z가 나와 X를 0.1X로 줄이지만, 동시에 Z가 새로운 작업 방식을 가능하게 하면서 그 부산물로 또 다른 잡무가 생김. 그러면 현재 잡무는 Y가 되고, Y는 대략 X에 가까워짐
    2000년대에 기술 발전이 멈췄다면 90년대에서 비롯된 잡무는 오늘날 거의 0이 됐겠지만, 새 기술은 자동화와 잡무를 함께 가져옴
    최근 예시는 AI 도구임. 소리, 이미지, 영상, 텍스트를 생성하는 도구는 있지만 차별화된 제품이나 경험을 만들려면 ChatGPT, Stable Diffusion 같은 도구들을 조합하는 잡무가 필요함
  • 30~40년이 지나면서 상품화하기 쉬운 영역은 이미 거의 사라졌을 수 있음
    더 상품화할수록 문제는 더 고차원으로 올라가고, 채용하는 전문 엔지니어도 스택의 더 위쪽으로 이동함
    최근 SaaS화된 스타트업 제품 중에는 아직 원하는 일을 실제로 해주지 못하는 제품 비율이 높아 보임. 돈을 받고 서비스를 쓰게 만든 뒤, 고객의 사용 사례를 구현 대상으로 수집하고 다른 고객에게 상품화하려는 식이라 리드타임이 길어지고 지식재산도 새어 나감
    SQL 템플릿화는 경영진이 늘 오해하는 대상임. SQL은 업계에서 놀랄 만큼 오래 살아남았고 실제로 꽤 잘함. 그 위에 얹는 래퍼나 DSL의 99%는 훨씬 나쁘게 만들며, 조금이라도 평범하지 않은 작업은 결국 SQL로 내려가야 함. SQL 전문가를 채용하는 대신 존재하지도 않는 SaaS식 DSL SQL 래퍼 X 전문가를 키워야 하는 상황이 됨
  • 타당한 비판이라 생각하고 더 곱씹어볼 필요가 있음
    근본 문제는 이런 제품들이 해당 분야에서 일하지 않는 구매자에게 “사서 꽂으면 문제가 해결되는 가전제품”처럼 보이도록 설계된다는 데 있을 수 있음
    많은 제품은 실제로 문제를 해결하지 못하고, 남들이 산다는 이유로 해결하는 것처럼 보일 뿐임. 그리고 구현이 성공했다고 거짓말해야 승진이 가능해짐. 메일 병합 같은 것은 정말 주전자처럼 이미 풀린 문제이고, 그런 문제는 직접 시도해보며 해결하면 됨
    더 큰 문제는 내 고용주가 Workday를 주전자 같은 것으로 믿고 샀지만, 우리 조직 구조가 너무 끔찍해서 모델링 자체가 안 된다는 사실은 고칠 수 없었다는 점임
    올해 처음으로, 대기업에서 충분히 나쁜 조직 구조는 일종의 기술 부채라는 걸 깨달았음. 누가 누구 밑에서 일하는지, 이 사용자가 이 데이터베이스에서 무엇을 볼 수 있는지 알아내려고 온갖 이상한 일을 하게 됨
  • 일부 측면은 정말 상품화됐음. 하지만 더 큰 그림은 어떨까?
    1994년이나 2004년에 비해 지금 사업을 운영하고, 웹사이트를 만들고, 여행을 계획하고, 청구서를 내는 일이 얼마나 단순해졌을까?
    이전 세대는 삶의 속도가 더 느긋했고 그래서 더 충만한 생활을 했던 것처럼 느껴질 때가 있음. 지금은 시간이 너무 빠르게 지나가고 스트레스도 높음
    얼마 전 은행에서 60세 이상인 사람 최소 세 명이 간단한 일을 처리하지 못해 헤매며 직원에게 도움을 청하는 걸 봤음. 온라인 뱅킹으로 쉽게 가능해야 할 일인데 예외 상황 때문에 시스템이 지원하지 않았고, 결국 예약을 잡아야 했으며 가장 빠른 일정이 3~4개월 뒤였음
    그중 한 명은 장작을 사서 집을 데우려고 막힌 계좌에서 돈을 인출해야 했지만, 은행 직원은 3개월을 기다리라고만 했음
    2년 전 아버지는 시칠리아에서 집으로 간단한 전화를 걸 방법을 찾지 못했음. 1970년대였다면 근처 바에 들어가 동전 몇 개만 넣으면 됐을 일임
    예전에는 보통 사람이 전등, 자동차, 난방, 자동문이 아닌 문 정도는 스스로 고칠 수 있었지만, 지금은 전문가를 불러야 함
  • 사람의 프로세스에 적용한 Amdahl의 법칙 같은 용어가 있는지 궁금함. “수확 체감의 법칙”의 반대편 같은 느낌임

• 기술 업무를 완전히 상품화하려는 시도는 나쁜 생각이고, 앞으로도 실패하길 바람
  다만 The Phoenix Project를 두 번 읽었고 Scrum 대부분을 싫어하지만, 그 책이 그런 걸 주장한다고 보지는 않음
  내가 얻은 핵심은 반복 가능한 업무를 수행하고 관리할 명확한 시스템을 두고 가능한 곳은 자동화하기, 진행 중인 일을 줄여 사람들이 수많은 작업에 묶이지 않게 하기, 정보를 널리 공유하고 여러 팀원이 같은 작업을 할 수 있게 하기, 실제로 비즈니스에 필요한 일을 하고 있는지 확인하기, 소음과 계획되지 않은 일을 줄여 직원들이 무질서한 늪을 헤매는 대신 즐길 수 있는 고부가가치 업무를 하게 하는 것임
  The Phoenix Project의 요지는 사람을 교체 가능한 자동인형으로 만드는 게 아니라, 자동화나 체계화가 불가능한 정말 가치 있는 일을 할 여유와 시간을 주는 시스템을 만드는 데 있음
  공장을 운영해봤고 개발자도 해봤기 때문에 양쪽을 보는데, 개발자를 생산 공장 노동자로 만드는 건 말이 안 되지만 알려진 작업과 반복 가능한 단계처럼 공장 일처럼 보이는 업무는 비슷하게 다뤄야 함

  • The Phoenix Project 전체는 사실상 Goldratt의 The Goal을 베낀 뒤 s/manufacturing/IT/g를 하고 현대식 참조로 업데이트한 것에 가까움
    책을 싫어한다는 뜻은 아님. 반쯤은 읽었고, 팀마다 시스템 중심으로 사고를 바꾸도록 읽히려 했음. 다만 The Goal보다 훨씬 깊거나 통찰적이라고까지는 못하겠음
  • 이 내용에는 전적으로 동의하고, The Phoenix Project에서 얻을 수 있는 긍정적인 부분이 바로 이것들임
    문체를 놀리긴 했지만 실제로 읽을 가치가 있었음. 알려진 작업이나 반복 가능한 단계에서 사람들이 잘못하는 많은 것들을 Phoenix Project식 사고 탓으로 돌릴 수는 없음
    다만 프로그래밍에서는 알려진 작업을 반복 단계로 수행하는 일이 드묾. 그런 일이 생긴다면 이해관계자 관리에서 전술적 실수를 해서 자동화할 시간이 없어진 경우가 많음
    사려 깊게 읽으면 마지막 문단 같은 결론으로 이어지지만, 내가 만나는 관리자 대부분은 위젯 생산과 시스템 설계의 차이를 이해하지 못한다는 걸 확실히 알고 있음
  • 회사에 DevOps 물결이 닥쳤을 때 The Phoenix Project는 주황색 DevOps Handbook의 “방법” 뒤에 있는 “이유”로 배웠음
    지속적 학습, 자동화, 계측은 위의 1~5를 가능하게 하는 도구들임
    The Phoenix Project에서 “더 열심히 일해서 더 많은 일을 더 빨리 하라”는 메시지를 받지는 않았음
  • Scrum 자체만 보면 사실 딱히 문제 삼을 게 없음
    https://scrumguides.org/scrum-guide.html
    보통 끔찍한 것은 사람들이 Scrum이라고 부르며 그 위에 얹는 잡다한 것들임. 엉터리 Scrum에 맞서는 가장 좋은 방법은 싸우는 게 아니라 실제 교리에 순수주의적으로 충성하는 척하는 것이었음. 덜 반골처럼 보이고 영향도 더 쉽게 줄 수 있음

• 제목이 헷갈렸음. “commodify”는 “판매 가능하게 만들다”, 즉 상업화한다는 뜻 아닌가? 기술은 이미 수십억 달러를 벌었지 않나?
  글쓴이가 말하는 건 commoditization, 즉 기술 업무를 아무 대체 가능한 직원도 할 수 있는 일반 업무로 만드는 쪽 같음
  https://en.wikipedia.org/wiki/Commoditization에 따르면 commoditization은 독점적인 것이 일반재가 되는 것이고, commodification은 판매 불가능했던 것이 판매 가능해지는 것이라고 정리할 수 있음
  내가 지나치게 꼬투리 잡는 걸까? 둘은 다른 의미라고 생각했음
  수정: Wiktionary를 보니 https://en.wiktionary.org/wiki/commodification에서는 서로 바꿔 쓰이기도 한다고 나옴. 그냥 흔한 혼동인 듯함

  • 내가 이해하기로는 “commodify”가 “판매 가능하게 만들다”라는 뜻은 아님
    https://www.merriam-webster.com/dictionary/commodify
    “내재적 가치나 예술 작품 같은 것을 상품으로 바꾸다”라는 뜻이므로, commodify는 commoditization에 관한 말에 가까움
  • 나는 늘 글쓴이가 쓰는 의미로 들어왔음
    석유가 상품인 이유는 생산자가 많고 모두 같은 것을 만들기 때문에 어느 쪽에서 사도 상관없기 때문임

• McDonald’s 비유에서 개발자는 기계 앞에서 일하는 십대가 아니라 기계를 설계한 엔지니어임. 그 비유에서 컴퓨터가 십대임
  프로그래밍은 일이 아니라 메타 작업임. 한 번 명령 목록을 만들면 컴퓨터가 그 일을 24시간 계속 수행하고, 나는 다른 일을 위한 새 명령 목록을 작성하러 감
  같은 명령 목록을 두 번 작성한다면 기본적으로 잘못하고 있는 것임. 그래서 항상 새로운 일을 하게 되고, 같은 일을 두 번 하지 않으니 얼마나 걸릴지 알기 어려움

  • IT를 공장이라고 부르는 근본 가정을 잘 짚었고, 그 가정이 왜 틀렸는지도 드러남
    IT는 공장이 아니라 공장을 만드는 일임
    많은 개발자와 관리자 갈등은 “관리자”라는 말이 너무 뭉뚱그려진 데서 온다고 봄. McDonald’s 관리자는 직원들이 제품을 만들어내는 프로세스를 따르는지 감독함. 프로세스를 안 따르는지는 명확하고, 프로세스는 유효하다고 전제되며, 결과물이 안 나왔는지도 명확함
    반면 프로그래머는 기계가 따를 프로세스를 개발하기 위해 고용됨. 이 직원을 관리하는 사람에게도 프로그래머가 따를 프로세스가 있을 수 있고, 그걸 따르는지는 명확할 수 있지만, 그 프로세스가 유효한지, 특정 행동이 정해진 결과로 이어질지, 결과 자체가 명확한지는 불확실함
    그런데도 두 역할 모두 “관리자”라고 부름
    이 기계 비유에서 프로그래머는 사람을 관리하는 게 아니라 기계를 지휘하는 다른 유형의 관리자임. 다만 그 기계들은 세상에 풀려나고, 프로그래머가 계속 감시하지는 않음
  • “프로그래밍은 일이 아니라 메타 작업”이라는 말은 엄청난 통찰이거나 완전한 헛소리인데, 앞으로 5년은 지나야 어느 쪽인지 알 수 있을 것 같음
  • 글쓴이로서 덧붙일 말은 별로 없고, 이 말이 정확하다고 봄. 제대로 했을 때를 가리켜 나도 메타 작업이라는 말을 써왔음
    물론 다른 댓글처럼 이 개념이 완전한 헛소리일 가능성도 있음. 다만 몇 년 뒤 이게 바보 같은 생각이었다고 깨닫더라도, 혼자 창피한 것보다는 누군가 같이 창피해질 사람이 있다는 점이 낫긴 함

• 약 10년 전 기계공학자인 친구 몇 명이 내가 소프트웨어 개발을 공부한다는 걸 보고 놀랐음
  “아직 할 일이 많이 남아 있나? 필요한 건 기존 시스템으로 다 할 수 있지 않나?” 같은 말을 했음
  오해는 새로운 문제를 해결하는 시스템을 만드는 일이 쉽고 이미 상품화됐기 때문에 더 이상 코드를 쓸 필요가 없다는 생각임
  현실에서는 소프트웨어 구축이 UI 설정만큼 쉬운 경우가 드묾. 논리 규칙과 흐름을 표현하는 텍스트가 필요하고, 시스템 변경을 추적하고 롤백하기 위한 버전 관리가 필요하며, 결국 프로그래머가 필요함
  코딩은 사라지지 않고 추상화 수준만 올라감

• 기술 업계는 오랫동안 개발자를 상품화하려고 해왔고, COBOL이나 Java도 그런 흐름에 있었다고 봄
  하지만 무엇을 추상화하든 다시 드러나는 본질적인 성질이 있음. 요구사항이 단순해 보이고 고수준 프레임워크가 있어도, 우리 소프트웨어 상당수는 여전히 제대로 동작하지 않음
  글쓴이 말처럼 진짜 해결책은 실력 있고 신경 쓰는 개발자임. 그걸로 커리어를 만들 수 있음

  • 보일러플레이트를 넘어서면 우리는 대부분 상품화된 문제를 풀고 있지 않음
    같은 분야에서 오래 일해보면 패턴은 비슷하게 반복되지만, 각자 비즈니스 요구사항이 조금씩 다름. 스택의 각 계층마다 이 차이가 커지고, 전체적으로는 비상품적이고 맞춤형인 일이 엄청나게 많아짐
    그래서 두 제품이 정확히 같지 않고, 모든 것을 생산하는 하나의 거대 전 세계 기업만 존재하지 않는 것임
  • 개발자들도 개발자를 상품화하려고 함
    자기 자신을 테일러주의적으로 쪼개는 형태의 자기 상품화 기회가 오면 개발자들이 들뜨는 모습을 셀 수 없이 많이 봤음
    의료 업계는 자동 상품화 논의가 나올 때 내가 드는 반례임. 감정적으로 두 가지 호소력이 있음. 환자는 의사를 이리저리 옮겨 다니는 걸 싫어함. 상품화에는 어느 정도 전문화 증가가 따르고, 인계가 하나 늘 때마다 실패 지점도 하나 늘어난다는 걸 이해함
    두 번째는 지위와 작업 방식을 더 높은 지위처럼 꾸밀 수 있다는 점임. 첫 번째를 앞세우고 두 번째는 서브텍스트로 읽히게 두면 보통 잘 먹힘. 노동자들은 더 일반화된 역량을 유지하고, 인계보다 서로 상담하는 방식에 의존하게 됨
    조립 라인은 순서가 정해진 전문화이고, 의료 전공의 근무시간과 관련한 인계 오류를 보면 됨

• 운영, 혁신, 유지보수. 셋 중 아무거나 셋을 고르면 됨
  같은 팀이 하거나 서로 아주 가까운 팀들이 하는 편이 더 좋음
  이상적으로는 팀의 각자가 세 기능을 다양한 정도로 모두 수행해야 함. 개선의 영감이 거기서 나오기 때문임
  이 세 기능을 세 그룹과 세 관리 계층으로 나눌 수도 있지만, 결과가 대체로 평범하고 사람들은 불행해짐. 특히 유지보수 팀에 갇힌 사람들은 감사받지 못하지만 핵심적인 일을 함
  팀이 세 기능을 모두 책임지게 만들 수도 있지만, 특정 하나에 과적합된 관리자를 뽑는 일이 많음. 공교롭게도 그 하나는 다음 분기에 더 좋은 보상으로 이어지는 기능임
  하나의 문화 안에서 운영 우수성, 성실한 유지보수, 그리고 깊이 생각할 시간을 동시에 옹호하기는 어려움. 어려운 게 당연함

• 비즈니스 인텔리전스/분석가 역할을 보면, 업계는 SQL을 쓰는 사람을 Tableau 같은 도구를 쓰는 사람으로 대체하려고 함
  “아무 데이터 저장소에나 연결하면 비기술 인력이 드래그 앤 드롭으로 할 수 있다”는 식임
  문제는 몇 가지 있음. 첫째, 출력이 선형적으로만 늘기 때문에 더 많은 저임금 인력을 채용해야 한다는 점을 잊음. 전부 UI 기반 작업이라 사람이 손으로 크랭크를 돌려야 함
  둘째, 매우 복잡하고 정리되지 않은 비즈니스 로직 변환 코드가 여전히 생기는데, 이제는 UI 안에 묻힘. 그 로직이 무엇인지 아는 사람은 PM이나 비즈니스 팀뿐임
  엔지니어링 조직은 비즈니스 질문에 답하기 위한 꽤 원시적인 고품질 테스트된 데이터셋을 제공함. 어려운 부분은 원천 데이터에서 이상한 방식으로 비즈니스 산출물을 얻는 문제를 푸는 것이었음
  이제 그 해법은 Tableau 워크북에 저장되고 다른 입력으로 쓸 수 없음. 새 Tableau 워크북에 UI에서 복사해 붙여넣어야 함
  Tableau 클라우드 서비스를 샀으니 BI 팀이 SQL 추출을 더 엄격하게 만들고 유지할 수는 있음. Tableau는 Databricks 사업 일부를 가져가려는 것처럼 보이지만, 이제 그 일을 비엔지니어링 팀이 하고 있음. 잘될지는 모르겠음

  • 정중히 반대함. 원시 데이터에서 의미 있는 답을 얻는 것도 어렵지만, 가장 어려운 일은 비즈니스 사람들이 올바른 질문을 하게 만드는 것이었음
    예를 들어 “우리 사용자는 어느 나라 출신인가?”라는 전형적인 질문이 있음. 가입 양식에 적은 국가를 말하는 건지, 현재 서비스에 접속 중인 국가인지, 결제 수단의 국가인지, 태어난 국가인지, 시민권 국가인지, 현재 거주 국가인지, 배송지인지, 청구지인지가 모두 다름
    데이터셋이 충분히 크면 각각 다른 답이 나옴. “글로벌 핀테크” 영역에서는 이런 이상한 경우가 보통이 될 것임
    전형적인 저임금 Tableau 사용자는 보이는 국가 코드를 찾아 count를 돌린 뒤 그걸 진실이라고 선언할 가능성이 큼
    조금 더 똑똑한 Tableau 사용자는 엔지니어에게 SQL을 써달라고 부탁할 것임
    데이터셋과 원천 시스템을 아는 사람이 있어야 비즈니스에 반문하고, 제대로 된 질문과 맥락을 강제할 수 있음
    Tableau류 도구는 매일 같은 SQL 쿼리를 pgAdmin에 붙여넣고 CSV를 이메일로 보내는 식의 “기술 작업”을 대체하는 데는 좋지만, UI 중심의 저숙련 작업자가 더 잘 생각하게 만들지는 못함
  • 비즈니스 “리더”에게 1번은 버그가 아니라 기능임
    비용에 대한 산출의 선형 확장은 스프레드시트로 모델링할 수 있고, 고객에게 전가하거나 청구할 수 있음. 비즈니스 계층의 모두가 이런 역학에 편안함을 느낌
    반면 전담 전문가가 적은 노력으로 1000배 산출을 만들 수 있지만 하루가 걸릴지 일주일이 걸릴지 확신하지 못하는 상황은 모두를 불확실하게 만들고 리더를 불안하게 함. 모두가 편안한 평범함을 원한다면 팔기 어려움
    2번은 아이러니하게도 더 많은 전문가, 다만 다른 종류의 전문가를 필요하게 함. 그 모든 로직을 유지해야 하기 때문임
    결국 일자리 프로그램처럼 굴러가며 더 비싸지겠지만, 정치적으로 영향력 있는 영지들에 비례한 가치를 배분할 것이고 그래서 성공할 것임
  • 훌륭한 사업 파괴기처럼 들림
    먼저 백엔드 사람들이 비즈니스를 모른다며 모두 해고하고 Tableau를 새 백엔드로 삼음. 백엔드 사람들이 비즈니스 요구사항을 흡수하고 다듬어왔다는 사실은 무시됨
    이후 비즈니스 사람들이 자신들이 만든 엉망진창의 거미줄에 얽히면 Tableau 컨설턴트를 부르고, 그들은 돈을 빨아먹으면서 가치 있는 것은 아무것도 만들지 않음

• 구조공학 쪽에서 왔는데, 소프트웨어는 다른 공학 분야보다는 도시계획에 더 가깝게 보임
  너무 방대함. 시간이 지나면서 백엔드, 프론트엔드, 펌웨어, 머신러닝 엔지니어, 데이터 과학자, 보안 분석가, 커널 개발자처럼 특정 작업 유형을 설명하는 다양한 직무가 늘어나는 건 놀랍지 않음
  표준이 발전하면 어느 시점에는 이런 자리에서 일하려면 매우 구체적인 인증이 필요해질 수도 있다고 봄. 다른 형태로 바뀔 수도 있지만, 결정화 효과는 분명히 보임
  소프트웨어를 공장으로 생각하는 것도 가능하고 유용할 수 있음. 하지만 모든 것이 그 비유에 들어맞지는 않음. 예를 들어 제품 통합을 생각하거나, 앱이 아니라 서비스인 경우가 그렇음
  공장은 무언가가 만들어진다는 뜻을 내포하지만, 많은 경우 소프트웨어는 최종 결과물이 아니라 그 자체가 가능하게 하는 수단임

• 소프트웨어에서는 대부분의 일이 점근적으로 자동화돼왔음. 그래서 그 일이 한때 노동이었다는 사실을 잊음
  소박한 파일 복사를 생각해보면 됨. 말하자면 “자동 필경사”임
  복사는 우리 시스템이 수행하는 엄청난 양의 복사가 보이지 않을 정도로 자동화됐고, 경제적 차별화 지점으로서도 사라졌음
  게다가 메타적으로도 유용함. 복사 프로그램 자체도 같은 알고리즘으로 쉽게 복사됨
  요점은 소프트웨어 작성이 수학처럼 늘 알려진 것과 알려지지 않은 것의 경계에서 시간을 보내게 된다는 것임. 완전히 알려지고 특성화된 영역은 모두를 위해 문제를 해결하는 동시에 그 활동의 경제적 토양을 태워버리는 방식으로 자동화되기 때문임
  소프트웨어 업무에는 어떤 영역이든 미지의 영역으로 들어가 부를 찾는 탐험, 즉 연구의 요소가 항상 들어감. 그 새 영역이 영광스럽든 비극적으로 평범하든 마찬가지임
  소프트웨어 전문성이 없는 관리자가 자동으로 할 수 있는 영역은 쉽게 열매를 딸 수 있게 길들인 과일나무와 같음. 그런데 그런 나무에는 더 이상 열매가 없음
  그 관리자의 문제 정의가 다시 성가신 창의성과 전문성을 요구하는, 자동화하기 어려운 영역으로 올라가지 않는다면 더 이상 차별화되거나 가치 있는 일을 하는 게 아니게 됨