사람들의 말을 듣는 일을 공학적으로 피해 가려 하지 말 것

• 소프트웨어 현장의 핵심 난관은 대화 자체의 부족보다 듣기 부족이며, 이를 framework나 system 같은 표현으로 바꿔 해결하려는 접근은 실제 필요한 듣기를 비껴감
• 누군가의 요청을 그대로 수행하는 일은 실제 요구를 파악하는 것과 다르며, 전문성 효과와 technical/non-technical 이분법은 상대의 지식과 맥락을 놓치게 만듦
• 모두가 같은 에너지와 기술, 자금을 가졌다고 보거나 한 사람의 특성을 집단 전체로 일반화하면 사람마다 다른 제약과 판단 기준을 제대로 포착하지 못함
• 사람과 조직은 시간과 역할, 스트레스, 집단 역학에 따라 달라지며, 말한 내용과 실제 생각이 항상 일치하지 않아 고정형 요구사항은 소프트웨어 제작과 쉽게 어긋남
• 듣기 실패는 가장 가치 있는 통찰을 놓치게 만들고, 수익 기회와 경쟁 우위 상실, 오해 누적에 따른 tech debt 증가로 이어짐

---

핵심 주장

• 소프트웨어 현장에서 사람 간 대화 부재보다 더 큰 핵심은 듣기 부족이며, 이를 framework나 system 같은 용어로 바꿔 해결하려는 접근은 실제 필요한 작업을 피하는 방식
• 디자이너와 product 담당자들이 사람과의 대화를 engineering이 더 받아들이기 쉬운 표현으로 바꾸려 하지만, 더 나은 체계보다 필요한 것은 사람의 말을 제대로 듣는 일
• 사람과 대화하는 일보다 사람의 말을 듣는 일이 더 어렵다는 전제 아래, 실제로 듣기를 방해하는 대표적 함정들 정리

듣기를 방해하는 대표적 함정

• 말한 대로 해주는 것과 듣기는 다름

  • 누군가가 원한다고 말한 것을 그대로 수행하는 일과 실제 요구를 듣는 일은 동일하지 않음
  • 이 주제와 관련한 기존 접근으로 Jobs To Be Done, Outcome Driven Innovation, UX 영역의 empathy mapping 언급

• 전문성 효과로 자기 관점을 과소평가

  • 특정 분야를 오래 학습하면 "당연히 이것쯤은 알 것"이라는 전제가 생기기 쉬움
  • 상대가 그 분야의 전문가여도 같은 지식을 알고 있지는 않으며, 대신 다른 지식을 알고 있을 수 있음
  • 제대로 들으려면 상대가 무엇을 알고 있는지 더 많이 이해할 필요

• technical을 단일 범주로 간주

  • 소프트웨어 개발자에게 특히 흔한 함정으로, technical은 하나의 성질이 아니라 이질적인 지식 영역의 넓은 스펙트럼
  • "technical / non-technical" 이분법으로 사람을 보면 통찰을 놓치게 되며, 제대로 듣지 못할 가능성 확대

• 모두가 같은 자원을 가졌다고 가정

  • 같은 에너지, 같은 기술, 같은 여유 자금을 모두가 보유한다고 보면 오판 발생
  • 같은 건강을 가진 사람도 관리 방식이나 실제로 할 수 있는 행동이 서로 다를 수 있음
  • 수학에 강한 사람, 다른 능력에 강한 사람, 돈이나 여유가 적어 더 위험 회피적으로 행동하는 사람 등 차이 존재

• 한 사람의 특성을 집단 전체로 일반화

  • 어떤 특성을 가진 한 사람을 만났다고 해서 나머지도 같을 것이라 보면 안 됨
  • 예시로 고령자가 컴퓨터를 이해하지 못한다고 단정하는 태도 언급
  • 여성 전체를 개인적 가족 관계의 이미지로 환원하는 태도도 같은 오류

• 사람과 조직이 고정돼 있다고 가정

  • 거시 수준에서는 성격이 시간에 따라 변함
  • 미시 수준에서는 직장에서의 persona와 집에서의 모습이 다르며, 스트레스나 특정 조건에서 판단도 달라짐

• 말과 생각이 같다고 가정

  • 어떤 사람은 말한 그대로를 의미하지만, 어떤 사람은 그렇지 않음
  • 스스로는 솔직하게 말한다고 생각해도 실제로는 그렇지 않은 경우 다수

• 사람을 판단

  • 부실하게 문서화된 것을 오해한 사람을 미워하거나 dismiss하면 제대로 들을 가능성이 크게 낮아짐
  • 상대가 일을 못하거나 삶을 잘못 살고 있다고 가정하는 태도도 듣기를 가로막는 요소

• 80명을 80개의 개별 인간이 아닌 하나의 집단으로 취급

  • B2B는 B2C보다 오히려 더 인간적인 측면이 강하며, 관계와 역학, 조직도 밖의 soft power 같은 요소가 작동
  • 집단 역학이 추가되면서 개인 단위보다 더 복잡한 변수 발생

고정형 요구사항과 소프트웨어의 어긋남

• 사람과 조직이 변한다는 사실 때문에 fixed project management는 소프트웨어 제작에 맞지 않음
• 요구사항을 처음에 확정해 두어도 그 사이 사람은 변하고, 결과물이 나왔을 때 많아야 시작 시점의 요청과만 일치
• 출시 시점에는 더 이상 원하는 것이 아닐 수 있으며, 사람들은 기다리는 동안 각자 기대를 덧붙이기 때문에 현실은 그 모든 기대와 일치하지 않음

결과와 영향

• 사람의 말을 제대로 듣지 못하면 가장 가치 있는 통찰을 놓치게 되며, 이는 수익 기회와 경쟁 우위 상실로 이어짐
• 오해가 누적될수록 나중에 함께 작업해야 하는 코드에 새로운 요소가 추가되며, 일부 tech debt 원인 최소화와도 듣기가 연결됨
• 듣지 못하는 순간을 알아차릴수록 더 잘 들을 가능성 커짐

[GN⁺]

Hacker News 의견들

• 나는 단어를 꽤 정밀하게 선택하는 편이고, 특정 표현을 썼다면 정말 그 뜻을 의도한 것임. 그런데 많은 사람은 내가 보기엔 톤 포엠처럼 말하고, 손에 잡히는 단어로 주변을 맴돌며 공통된 뉘앙스로 이해되길 기대해서 해석 자체가 피곤함. 내가 글을 쓸 때는 모든 단어를 의도적으로 고르는데, 직장에서조차 내 표현이 부정확했던 것처럼 해석되는 일이 거의 늘 반복돼서 꽤 고통스러움. 스펙트럼 성향이 있을지도 모르지만 진단받은 적은 없음. 반년쯤 전 다른 부서가 긴 작업을 시작할 수 있게 작은 RPC를 만들고 문서를 썼는데, 한 페이지도 안 되는 분량이지만 완전하고 정확하며 간결했음. 그런데 매니저가 이유도 설명 없이 그 문서를 AI에 통과시켜 전달했고, 나는 그 사실조차 몰랐음. 하루도 안 돼 말이 안 되는 피드백이 쏟아졌고, 실제 요청 예시를 보니 endpoint 조작이 일어났음. 오타가 아니라 완전히 지어낸 주소였고, 문서에는 엔드포인트와 필수 파라미터가 죄다 틀렸고 없는 기능까지 발명돼 있었음. 평소에는 유한 편인데, 그때만큼 분노한 적이 없었고 지금도 화가 남. 고용 시장만 아니었으면 바로 그만뒀을 것 같음. 사람들 스스로 읽고 해석해야 할 언어를 AI에 맡기는 건 엄밀한 언어의 죽음처럼 느껴지고, 생성형 AI가 문명을 망치는 어떤 Great Filter일지도 몇 달째 진지하게 생각 중임

  • 나는 이 관점이 조금 낯설게 느껴짐. 말이 사고의 경계를 정확히 잘라 담는다고 보기는 어렵고, 언어는 세계와 각자의 이해를 표현하는 도구라서 비슷한 개념을 서로 다른 말로 설명하는 건 자연스러운 일임. 생각에서 단어로 옮긴 사람에게는 더 명확해 보여도, 듣는 사람에게는 그렇지 않을 수 있음. 그래서 해석의 노동을 가볍게 넘길 수는 없다고 봄. 아마 그 상황의 상대편과 얘기해 보면, 그들도 결국은 당신의 말을 해석하기 어렵다고 비슷하게 말할 것 같음
  • 나는 이 설정이 너무 강렬해서 바로 소설이 떠올랐음. Great Filter와 생성형 AI를 엮은 발상이 아주 좋고, 이건 Cory Doctorow가 당장 써야 할 이야기처럼 느껴짐
  • 나는 우선 왜 매니저가 그 문서를 AI에 넣었는지 물어봐야 한다고 생각함. 때로는 정밀함이 커질수록 가독성이 떨어지고, 압축된 언어일수록 독자는 단어 하나하나에 더 큰 인지 비용을 써야 함. 읽는다는 건 작성자의 머릿속 모델을 독자의 모델로 번역하는 과정이고, 단어만으로 자동 변환되는 게 아니라 해석 행위가 필요함. 너무 간결하면 독자를 돕는 장치가 사라질 수 있음. 한 페이지 문서가 일반 독자에게는 지나치게 짧아서 이해를 돕지 못했기에 AI 요약 같은 우회가 일어났을 가능성도 의심됨. 독자를 위한 글쓰기는 최고 맥락 독자를 위한 정확한 메모와 전혀 다른 작업이고, 특히 불특정 다수를 대상으로 쓸 때는 반복, 쉬운 예시, 익숙한 맥락, 절차의 세분화, 때로는 유머와 배경 설명까지 넣어 이해를 도와야 한다고 봄
  • 나도 최근 비슷한 일을 겪었음. 내가 4페이지짜리 명세를 썼는데, 받은 사람이 그걸 읽지 않고 LLM으로 몇 개 불릿 요약만 뽑아봤고, 그 결과 요구와 맞지 않는 제안서가 돌아왔음. 내가 반대하자 그는 그 내용이 원래 명세에 있었어야 한다고 했지만, 사실 이미 명세에 있었고 단지 그의 LLM summary에 없었을 뿐임. 나는 단어 하나하나에 집착하는 타입은 아니지만, 4페이지 문서의 정보가 10개 불릿 안에 온전히 들어갈 수는 없다고 느낌
  • 나는 오히려 이 글을 normie speak로 바꿔주는 전용 프롬프트나 커스텀 LLM이 딱 맞는 사례라고 느낌

• 나는 이 댓글란만 봐도 글이 지적한 문제를 그대로 재현하는 사람이 많아서 아이러니하게 느껴짐. 여기에 몇 가지를 더 보태고 싶음. 첫째, 아무리 지식과 토론을 쌓아도 상대가 받아들이고 싶지 않은 것은 쉽게 받아들이지 않음. 둘째, 진짜 경청은 정신적으로도 신체적으로도 자신을 취약한 상태에 두는 일임. 내 경험과 신념, 세계관과 충돌하는 말을 듣게 되기 때문이고, 사람을 판단하는 태도는 종종 자기보호 기제라서 그래서 오히려 잘 듣지 못하게 됨. 셋째, 경청은 종종 바로 해결책으로 뛰어들지 않고 상대의 고통을 흡수하고 처리하는 일임. 예를 들어 Product manager는 새 기능이나 티켓으로 바로 환원하기 쉬운데, 사실은 사용 사례를 듣고 고통 지점을 찾아 해결해야지 사용자가 요청한 기능 이름만 이해하려 해서는 안 된다고 봄

  • 나는 이 명제를 미리 전제하는 건 위험하다고 느낌. 대부분의 일은 협상의 여지가 있고, 제대로 협상하는 법만 알면 달라질 수 있다고 봄
  • 나는 특히 2번이 아주 깊이 있게 느껴졌음. 이 말을 소중한 사람에게 꼭 보내보고 싶고, 그도 정말 listen해 주면 좋겠다는 마음이 듦
  • 나는 경청이 취약해지는 일이라는 말에 공감하면서도, 그 취약함이 매번 악용되지 않음이 보장된다면 기꺼이 시간을 내서 항상 제대로 들어주고 싶다는 생각이 듦
  • 나는 정말 궁금한 게 있음. 남의 고통을 흡수한다는 게 실제로는 무엇을 뜻하는지, 그리고 거기서 어떻게 기능 정의나 티켓 작성으로 자연스럽게 넘어가는지 알고 싶음
  • 나는 이 설명이야말로 presales discovery의 본질이라고 느낌. 정말 기술이라기보다 예술에 가까운 영역임

• 나는 문제의식에는 동의하지만, 이 목록은 다소 하소연처럼 읽혔음. 효과적인 소통은 인류 전체의 핵심 문제에 가깝고, 이 글은 개발자가 경청을 못한다고 꾸짖는 뉘앙스가 있어서 약간 고압적으로 느껴졌음. 근본 문제는 사람들이 자신이 무엇을 모르는지 모른다는 데 있음. 최고의 커뮤니케이터는 번역가 같고, 메시지가 상대의 이해 속에서 자명해질 때 사람들이 비로소 듣게 됨. 모두가 귀를 막은 유아처럼 굴어서 생기는 단순한 붕괴라고 보진 않음. 그래서 우리는 시스템과 엔지니어링을 찾게 되고, 시스템이 간극 탐지와 번역 프레임워크를 내장하도록 하려는 것임. 완벽하진 않아도 개인에게 더 잘 들으라고 훈계하는 것보다 팀, 회사, 시스템 차원의 환경을 바꾸는 게 더 중요하다고 생각함

  • 나는 예전에 어떤 노인이 이걸 Noisy system으로 보라고 했던 말을 떠올림. 신호는 언제나 잡음보다 약하고, 그 안에는 한계가 있는 인간들이 들어 있음. 각자 할 수 있는 일에도 상한이 있고, 사람의 사고 모델이 업데이트되는 속도에도 한계가 있으며, 집단의 한계는 개인보다 더 낮음. 특히 큰 조직은 현실이 완전히 바뀌어도 기존 모델을 바꾸는 데 수십 년이 걸릴 수 있음. 그래서 이런 제약을 인정한 뒤 내가 시간과 에너지를 어디에 쓸지 결정하는 게 중요하다고 느낌
  • 나는 이 글이 그냥 평범한 self-help 글처럼 보였고, 심지어 예시도 부족해서 그보다 조금 더 아쉽게 느껴졌음
  • 나는 개발자이면서 다른 일도 꽤 해봐서 소통의 중요성과 개발자들이 거기서 얼마나 자주 약한지를 잘 알고 있음. 흔한 패턴은 개발자들이 나쁜 의사처럼 듣는 척하다가 너무 이른 시점에 진단을 내리는 모습임. 상대가 중요한 걸 다 말하기도 전에 필요한 걸 안다고 선언해 버리는 식임. 소프트웨어에서 고객이 원하는 것보다 중요한 건 종종 고객이 실제로 필요로 하는 것임. 소프트웨어로 문제를 우아하게 푸는 방식을 잘 아는 고객은 드물고, 대개는 소프트웨어를 깊이 고민해보지 않은 누군가가 아이디어를 들고 오기 마련임. 그 아이디어가 무가치하다는 뜻은 아니지만, 요구사항 정리와 해결책 도출은 아직 끝나지 않은 상태라는 뜻임. 그걸 완성하는 방법은 관찰과 설명, 그리고 대화임. 내 경험상 많은 개발자는 정말 잘 듣지 않고, 의사나 다른 기술직도 비슷함. 자신이 얼마나 잘 아는지 보여주며 빨리 유능해 보이려 하고, 상대를 이미 많이 본 문제 유형 중 하나로 분류해 버림. 가끔은 통하지만, 안 통하는 순간이 반드시 옴
  • 나는 농담처럼 말하자면, 정말 소통이 인류의 중심 문제라면 Bible에도 뭔가 한 구절쯤은 있었어야 하지 않나 싶음

• 나는 사람들이 말하는 것과 실제로 생각하는 것이 같다고 쉽게 가정하면 안 된다고 봄. 반대로, 말하는 사람도 듣는 사람이 같은 대상을 떠올리며 이해하고 있다고 착각하기 쉬움. 그래서 가능한 한 자세하고 모호하지 않게 써두는 게 중요함. 회의에서 누군가 6단어짜리 불릿 하나로 목표를 설명하려 든다면, 그건 사실상 아무도 목표를 이해하지 못함이라는 신호라고 느낌. 한 페이지짜리 문서도 없이 회의에 들어온다면 그 사람은 아직 그걸 충분히 이해하지 못한 상태이고, 내 진척이 그 결과물에 달려 있다면 더 선명한 그림을 요구해야 한다고 생각함

  • 나는 동료들에게 하루에도 몇 번씩 about what? 를 반복해서 물어봐야 하는 상황이 자주 있음. 어느 고객인지, 어떤 기능인지, 무슨 제품인지 구체적으로 말할 때까지 4~5번 되묻는 경우도 많음. 심지어 내가 그들이 뭘 말하는지 정확히 알고 있을 때조차 그렇게 해야 할 때가 있음
  • 나는 요구사항의 정당성도 반드시 따져봐야 한다고 느낌. 실제 필요를 모르는 상태를 감추기 가장 쉬운 방법이 과도한 요구이기 때문임. 내 경험상 필요한 것의 10배를 요구하는 일은 흔하고, 예전에 500배 비용 차이가 나는 선택지를 두고 미래를 걱정하지 않으려면 최고 사양을 사야 한다는 말까지 들은 적이 있음
  • 나는 자세하고 모호하지 않게 적는 일이 깊은 상호 이해의 전제 조건일 수는 있어도, 최근 몇 년 사이 사람들은 메시지나 티켓, 이메일의 첫 문장 이상을 정말 잘 안 읽는다고 느낌. 그래서 정보를 아주 작은 조각으로 잘게 나눠 먹여줘야 하는 일이 많아졌고, 그게 꽤 싫음
  • 나는 현실에서 이런 일이 너무 자주 벌어진다고 느낌. 내가 production 준비 안 됨이라고 말하면, 경영진은 그걸 고객에게 acceptance testing으로 팔 수 있다는 뜻으로 듣는 경우가 많음
  • 나는 여기서 문득 소련 시절 영화 Kin-dza-dza가 떠올랐음. 거기서 한 인물이 다른 사람을 두고, 그는 자기가 생각하지 않는 것을 말하고 자기가 생각하지 않는 것을 생각한다고 표현하는데, 이 대화의 혼선을 묘사하는 데 꽤 잘 맞는 말처럼 느껴짐

• 나는 고객 관계 관리 역할을 주로 맡고 있어서, 가장 중요한 일은 고객의 기대치 정렬을 현실과 맞추는 것이라고 봄. 무엇이 가능한지, 얼마나 걸리는지, 비용이 얼마인지, 언제 production에 올릴 수 있는지를 고객 기대와 일치시켜 두면 시작일이나 비용이 마음에 들지 않더라도 결국은 행복한 고객이 됨. 특히 비용은 종종 거래를 깨는 요소라서 대략적인 범위를 초기에 맞춰두는 편임. 아무리 잘 듣고 공감해도 현실은 현실이고, 고객도 그 제약을 인정하거나 받아들여야 함. 고객이 원하는 것을 전부 맞장구치는 고객 담당자는 결국 고객을 더 불행하게 만들고, 좋은 인터페이스 담당자는 고객과 내부 팀 양쪽의 말을 모두 들어 실제 전달 가능한 것과 고객 기대가 일치하도록 만들어야 한다고 생각함

• 나는 어쩌면 우리가 소통에 너무 많은 시간을 쓰고 있는지도 모른다고 느낌. 시간이 과하게 배정되면 집중력이 흐려지고, 어차피 다음 번에 또 명확히 하면 된다는 식으로 미뤄지기 쉬움. 불필요한 회의를 줄이고 minimum viable time만 배정하면 오히려 모두가 더 잘 듣게 될 거라고 봄

  • 나는 이 현상을 현실에서 아직 거의 본 적이 없음. 대부분의 회의는 사실 소통이 아니라 지시와 통보에 가깝고, 듣는 능력은 회의 길이와 무관한 별도의 기술임. 경청은 연습으로 다듬는 능력이지, 회의 시간을 줄인다고 자동으로 생기는 건 아니라고 생각함
  • 나는 결과가 다음 회의를 잡는 일인 회의에 너무 많이 들어가 봤음. 심지어 더 많은 사람을 끌어들이고, 사람이 많은 팀이 결정을 자기 쪽으로 몰아가며 정치적 영향력을 확보하고, 그게 다시 더 많은 불필요한 채용과 회의로 이어지는 패턴도 봤음. 탈출구는 커뮤니케이션을 늘리는 게 아니라 단일한 비전을 세우고, 팀 간 의존성을 줄여 각 팀이 독립적으로 일하게 만드는 것이라고 느낌
  • 나는 소프트웨어 아키텍처 일을 하면서, 다이어그램 하나가 60분 이상 논의와 여러 번의 회의를 아껴주는 걸 자주 봤음. 잘 그리지 못했더라도 사실에 충실한 그림이면 충분했고, 복잡하거나 비자명한 논리는 말보다 diagram이 훨씬 명확했음. 원격 회의라면 Ai agent와 Mermaid.js로 빠르게 그리고, 대면이면 화이트보드나 종이와 펜이면 충분하다고 봄
  • 나는 소통에 시간을 쓰는 것과 실제로 소통하는 것은 전혀 다른 일이라고 느낌
  • 나는 우리가 실제로는 소통에 시간을 너무 쓰는 게 아니라, 소통하는 척하는 데 시간을 너무 쓰는 경우가 더 많다고 봄. 정족수도 안 되는 회의를 억지로 열고, 전제 조건도 없이 진행하며, 생각 없이 만든 AI slop document를 던져놓고 사람들이 이해 못 하면 오히려 읽는 사람이 멍청한 것처럼 몰아가는 장면을 자주 봤음. 회의 첫 30분은 가스라이팅처럼 흐르고, 마지막 10분에야 시간 낭비였음을 인정하며 수습하는 식임. 원래 회의는 잘 숙성된 생각과 일관된 방향을 공유하고, 명확한 주장에 의미 있는 피드백을 받는 자리여야 하는데, 실제로는 누군가 자기 일을 stone soup식 그룹 프로젝트로 바꾸려는 시도를 다 같이 처리하는 경우가 많음. 초반에 이 회의의 목표가 무엇인지 물어보면 회의 주최자가 단순한 스터디 그룹을 열어둔 건지 드러남. 높은 시야만 가진 관리자는 일이 회의에서 이루어진다고 착각하지만, 좋은 회의 이전에 필요한 사고 작업은 잘 보지 못함. 생각이 정리되기 전에 소통을 서두르면 회의는 그냥 잡음이 됨. 이런 상황에서 가장 강력한 대응은 지금 같이 알아보자는 태도이고, 나는 Why, What, How, Who, When 순서의 의존 관계를 지키게 함. 앞단이 비어 있으면 뒤로 못 가고, 인턴이든 VP든 손쉬운 얼버무리기는 허용하지 않음. 문제를 분해하고 현장에서 생각해보고도 팀이 바뀌지 않으면, 결국 다른 팀을 찾는 게 맞다고 느낌

• 나는 이 글의 specialism effect 지적이 꽤 저평가돼 있다고 느낌. 나도 사용자가 내가 몇 년 동안 체화한 것을 이해 못한다고 답답해한 적이 있지만, 곧 문제는 그들의 지식이 없는 게 아니라 다른 곳에 축적돼 있음이라는 점을 깨닫게 됐음. 그들도 같은 시간 동안 전혀 다른 걸 깊게 익혀온 것뿐임

• 나는 사람들이 말을 안 하고 안 듣는 게 핵심 원인이라는 설명에 완전히 동의하진 않음. 만화 비유를 빌리자면, 많은 사람이 처음부터 도로 자체보다 리본 커팅을 원했고 결국 그걸 얻었기 때문에 이런 일이 벌어진다고 봄

• 나는 사람들이 자신은 말한 그대로 뜻한다고 하면서도 실제로는 그렇지 않은 모습을 꽤 웃기게 겪은 적이 있음. 상대 말을 거의 그대로 바꿔 말하며 이해 확인을 했는데, 돌아온 반응은 그건 절대 자기가 하려던 말이 아니라는 강한 부정이었음

• 나는 비기술 직군과 대화할 때 생기는 많은 문제의 핵심이, 그들이 비용 맥락 없이 그냥 X를 추가하고 Y를 바꾸자고 말하는 데 있다고 느낌. 물론 시키는 건 거의 다 할 수 있지만, 각 요청에는 비용이 있고 그걸 이해하지 못하면 신뢰할 수 있는 제품 출시와 양립하기 어려움

  • 나는 이 반응이 오히려 글의 핵심을 그대로 보여준다고 느낌. 그들이 비용을 이해하지 못하는 게 아니라, 단지 맥락이 다름일 뿐이고, 기술 담당자의 역할은 미리 비용을 알고 오길 기대하는 게 아니라 그들이 정보에 기반한 tradeoff를 하도록 돕는 일이라고 봄
  • 나는 이런 상황에서 왜 필요한지 묻는 whys가 중요하다고 느낌. 비기술적 프로세스를 이해해 보면 사실 추가나 변경이 아예 필요 없을 수도 있음. 모든 걸 다 넣으면 결국 Turing complete Excel/Email clone 같은 괴물이 된다는 점에도 동의함
  • 나는 이런 상황에서 비기술 인력은 비용을 모르고, 기술 인력은 편익을 모름이라는 식의 비대칭이 생긴다고 봄. 결국 양쪽의 소통이 있어야 괜찮은 비용 대비 편익 지점을 찾을 수 있음
  • 나는 이건 꽤 해결 가능한 문제라고 느낌. 각 요청에 대해 몇 달이 걸리는지, 얼마가 드는지 월 단위와 달러 단위로 추정해 답하면 됨
  • 나는 다만 요즘은 AI가 code thing을 대신해 주면서 구현 비용 자체가 꽤 내려간 것도 현실이라고 느낌. 좋아하든 싫어하든 그 변화는 인정해야 한다고 봄