사용자는 신경 쓰지 않는다 - 하지만 당신은 신경 써야 한다

• 사용자는 코드 자체의 내재적 속성보다 제품 작동을 중시하지만, 나쁜 코드는 성능·버그·개발 속도에 직접적인 하위 영향을 미침
• “사용자는 기술 스택이나 테스트를 신경 쓰지 않는다”는 말은 피상적으로 맞아도, 코드 품질이 낮을수록 버그 수정과 기능 추가가 더 어렵고 느려짐
• 다리 검사, 취한 조종사, 불안정한 건물 기초의 비유처럼, 사용자가 과정 자체를 보지 않아도 그 결과는 안전과 신뢰에 영향을 줌
• 이런 통념이 인기 있는 배경에는 자신이 잘 못하는 것을 평가절하하려는 자아 방어 기제가 작용할 수 있음
• 진지한 소프트웨어 작업은 다양한 관심사와 관점의 혼합이며 그 모두가 성패에 기여하므로, 코드 품질을 가볍게 여겨선 안 됨

---

반복되는 클리셰와 그 한계

• 소프트웨어 업계에는
  • “고객은 테스트를 신경 쓰지 않고 제품이 작동하는지만 신경 쓴다”
  • “사용자는 기술 스택을 신경 쓰지 않는다”
  • “공학적 우아함은 시장 가치와 같지 않다”
  • “사용자는 AI가 썼는지 사람이 썼는지 또는 어떤 프레임워크를 썼는지 신경 쓰지 않고 제품 작동만 신경 쓴다”
    는 식의 말이 반복됨
• 이런 말들은 모두 “고객은 그것을 신경 쓰지 않는다” 는 같은 주제의 변형임
• 마치, 노련한 실용주의자가 이상주의적이거나 근시안적인 이들에게 세상의 냉정한 진실을 알려주는 듯한 태도를 취함
• 하지만, 이는 전부 헛소리(horseshit) 이며
  같은 논리를 다른 분야에 적용하면 허점이 드러남
  • 도로 이용자는 다리가 최종 점검을 받았는지 신경 쓰지 않는다, 차를 받쳐주는지만 신경 쓴다
  • 승객은 조종사가 술에 취했는지 신경 쓰지 않는다, 비행기가 정시에 도착하는지만 신경 쓴다
  • 사무직 노동자는 고층 건물의 기초가 안정적인지 신경 쓰지 않는다, 돈 버는 것에만 신경 쓴다
• 이런 비유는 표면적으로는 맞지만, 명백한 하위 영향(다운스트림 효과) 을 무시함

무시되는 다운스트림 효과

• 고객이 컴퓨터 코드의 내재적 속성에 관심이 없다는 점은 맞지만,
  코드 품질은 성능, 버그 존재 여부, 버그 수정 시간, 기능 추가 시간에 영향을 줌
• 코드가 나쁠수록 이런 문제를 해결하기가 더 어렵고 더 느려짐
• AirBnB, OpenAI, Meta 같은 기업은 엄청난 시장 장악력, 막대한 VC 지원, 의심스러운 합법성으로 이런 우려를 밀어붙일 수 있음
  하지만, 그런 회사가 아니라면 같은 방식으로 문제를 덮기 어려움

‘Folk Wisdom’의 지속성과 소프트웨어의 여러 관심사

• 통념의 끈질긴 생명력 (The Persistence of Folk Wisdom)

  • 1차 효과만 중요하다고 보는 생각은 소프트웨어에서 매우 인기 있는 민간 통념으로 자리 잡고 있음
  • 사람들은 자신이 잘하지 못하는 것을 할인하거나 축소하는 경향이 있음
  • 좋은 코드를 만들 능력이 부족하다고 인식하면, 좋은 코드가 중요하지 않을 뿐 아니라 좋은 코드를 만들 수 있는 사람들이 오히려 문제라는 관점을 취하기 쉬움
  • 그런 관점에서는 고객이 신경 쓰지 않는 것들로 출시를 막는 사람들이 문제처럼 취급됨
  • 이 태도는 자기 약점을 피하고 다른 사람에게 책임을 전가하는 자아 방어 기제(ego defence mechanism) 로 작동함

• 우리는 사회 속에 산다 (We Live in a Society)

  • 진지한 소프트웨어 작업은 서로 다른 관심사와 서로 다른 관점의 혼합물임
  • 기술 영업(tech sales)부터 기술 스택(tech stack)까지, 사용자 경험(UX)부터 고유 식별자(unique identifiers)까지 다양한 요소가 소프트웨어 노력에 들어감
  • 이 모든 요소가 성공 또는 실패에 기여함

[GN⁺]

Lobste.rs 의견들

• 이런 문장은 전달하는 방식도, 읽는 방식도 좋고 나쁠 수 있음
  예를 들어 “고객은 테스트에 전혀 관심 없다. 제품이 동작하는지에 관심 있다”는 말은 “버그를 내보내라”가 아니라, 특정 테스트 이념보다 제품이 실제로 동작하는 것에 집중하라는 뜻으로 읽을 수 있음
  테스트는 코드가 동작하게 만드는 수단 중 하나이므로, 테스트 커버리지가 높고 통과해도 제품이 안 되면 실패이고, 테스트 말고 다른 방식으로 제품을 잘 동작하게 해도 괜찮고, 형식적 교리를 따르지 않아도 버그를 잘 잡으면 괜찮다는 식으로 해석 가능함
  또 사용자와 비즈니스 관점에서는 “제품/기능이 존재하지 않음”도 버그일 수 있어, 기존 버그 수정과 기능 출시가 항상 깔끔히 분리되지는 않음
  다만 실제로는 이런 문장이 “요령 피우고 쓰레기를 출시하라”는 뜻으로 쓰이는 경우도 들어 봤음

  • “사용자와 비즈니스 관점에서는 제품/기능이 존재하지 않음도 버그”라는 점에 대해, 글쓴이로서 명시적으로 다루지 못한 부분이 있음
    형편없는 프로그래밍이 몇 달 단위로 봐도 “실용적”이라는 생각은 완전히 거부함
    설계가 나쁘고 테스트가 부족한 코드베이스에서 새 기능을 만드는 일은 느리고 비쌈
  • “단위 테스트는 많을수록 좋다”거나 병목도 아닌 코드를 며칠씩 최적화하는 엔지니어도 많아서, 그런 경우에는 위 해석들이 꽤 적절함
    개발자는 가치가 생기는 곳에 시간을 쓰는지 의식해야 하고, 경영진도 왜 그런 일을 하는지 이해하는 게 이상적임
    이해 부족과 잘못된 인센티브 구조가 합쳐지면 결국 “요령 피우고 쓰레기를 출시”하게 됨

• 솔직히 이런 말을 하는 사람들은 사용자도 별로 신경 쓰지 않는 사람처럼 보일 때가 많음
  사용자가 동작하는 제품을 받게 하려면, 개발 과정 안에 그 가능성을 높이는 장치들이 있어야 한다는 점은 이미 며칠 전 댓글에서도 말했음
  이런 정서는 사용자가 제품에 대해 제대로 피드백할 방법도 없고, 실제 사용 지표도 없는 상황에서 자주 등장함
  사용자가 당장 보거나 신경 쓰지 않아도 영향을 받는 실패 시나리오도 많음
  대표적으로 보안은 데이터가 온라인 유출본에 올라오기 전까지는 사용자가 “안전하지 않음”을 신경 쓰지 않을 수 있고, 성능도 훨씬 좋아질 수 있다는 걸 알기 전까지는 문제로 느끼지 못할 수 있음

  • 이런 주제는 일반 청중에게 설명하기 어려움
    어떤 개선 과정이든 한 요소만 골라 최적화해서 좋은 결과를 얻기는 어렵지만, 토론에서 진전을 만들려면 종종 그렇게 할 수밖에 없음
    그래서 실제로 눈에 보이는 문제가 어디인지 피드백 경로를 맞춰 가며 논의를 보정하는 게 도움이 됨
    이런 글은 소프트웨어 프로젝트의 성공에 영향을 주지만 서로 배타적으로 보이는 요소들을 떠올리게 하려는 시도라고 봄
    기술적 감각이 있는 사람들만 아는 일을 말로 풀어내고 옹호하는 건 가치가 있지만, 많은 기술자들이 보이지 않는 작업의 균형을 맞추거나 효과적으로 설득하지 못하는 듯하고, 나도 그 부분을 계속 연습 중임

• 내부를 신경 쓰는 건 중요하고, 실제로 사용자에게도 이익이 됨

• 이 관점이 마음에 듦
  반대쪽 극단인 과잉 엔지니어링으로 가고 싶지는 않지만, “빠르게 움직이고 망가뜨리기” 사고방식에서는 벗어났으면 함
  경험상 웹 개발 세계에서는 거의 전염병 같음
  LLM이 가능하게 만든 저품질 소프트웨어의 유입이 오히려 사용자들이 신뢰성 있는 소프트웨어를 보상하게 만들었으면 좋겠음
  점점 grug brain 개발자가 되어 가는 중이라 널리 퍼진 감각인지는 모르겠지만, “기능 하나 더 추가하자”에 지쳤음
  우리는 소프트웨어 비용을 출시일로만 재는 실수를 자주 하고, 그 수명 동안 생길 유지보수 비용은 거의 포함하지 않음
  “어렵지 않아요, 일주일도 안 걸려요!”라고 하면서도 매년 2~4주씩 유지보수, 수정, 확장, 업데이트, 통합, 문서화에 들어갈 시간은 말하지 않음

• 비슷한 결의 말을 자주 함
  “최종 사용자는 소프트웨어가 테스트 커버리지 100% 인지, lbl0 같은 레이블이 붙은 문서 없는 어셈블리로 100% 작성됐는지 신경 쓰지 않는다. 정확성, 성능, 사용자 경험을 신경 쓴다”
  하지만 소프트웨어 엔지니어링은 바로 그 목표에 더 쉽게 도달하고 품질을 좋은 수준으로 유지하게 해 줌
  문제는 이 길도 화물 숭배와 과잉 엔지니어링으로 이어질 수 있고, 나도 분명 그 죄가 있음
  그래도 결국 사용자에게 실제 가치를 전달해야 함

• Boeing과 Airbus처럼 증명 가능한 최적 결과가 존재함
  왜 두 회사의 기체가 그렇게 비슷해 보이는지, 누가 먼저 설계했고 누가 훔쳤는지가 핵심이 아님
  아무도 훔치지 않았고, 서로 다른 팀의 세계 최고 엔지니어들이 같은 제약 안에서 설계하다 보니 벗어나는 설계는 정의상 열등해짐
  파레토 프런티어 위에 있어야 하고, 그렇지 않으면 잡아먹힘
  우리 분야에서도 어딘가에 최적점은 존재하며, 문제는 거기에 도달할 도구, 예산, 적절한 사람이 있는지와, 실제로 거기 도달했는지 알아낼 만큼 충분한 사용자가 있는지임