▲

아무도 전체 시스템이 어떻게 작동하는지 모른다

 (surfingcomplexity.blog)
1P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • 현대 기술 시스템은 너무 복잡해 한 개인이 전체를 이해할 수 없는 구조로 발전했음
  • 소프트웨어 개발과 AI 활용이 늘어나면서, 개발자들이 내부 메커니즘을 이해하지 못한 채 구축하는 사례가 증가함
  • Simon Wardley는 이해 없이 시스템을 만드는 위험을, Adam Jacob은 AI가 개발 방식을 바꾸고 있음을, Bruce Perens는 이미 복잡성이 한계를 넘었음을 지적함
  • Louis Bucciarelli는 전화 시스템 사례를 통해, 기술이 여러 층위로 얽혀 있어 누구도 완전한 이해에 도달할 수 없음을 보여줌
  • 글은 AI가 이 복잡성을 심화시키지만, 사실상 인간은 오래전부터 부분적 이해 속에서 기술을 다뤄왔다는 점을 강조함

기술 복잡성과 이해의 한계

  • Twitter의 쇠퇴 이후 LinkedIn에서 기술 이해와 복잡성에 관한 논의가 활발히 이루어짐
    • Simon Wardley, Adam Jacob, Bruce Perens의 게시물이 상호 연관된 주제로 소개됨
  • Wardley는 기초 원리를 모른 채 시스템을 구축하는 위험성을 경고함
    • “Magic”이라는 표현은 내부 동작을 숨기는 프레임워크를 비판적으로 지칭하며, Ruby on Rails가 대표 사례로 언급됨
  • Jacob은 AI가 소프트웨어 개발 방식을 근본적으로 변화시키고 있음을 지적함
    • AI는 효율성을 높이지만, 개발자가 하부 구조를 이해하지 못한 채 작업하게 만드는 경향이 있음
  • Perens는 Wardley가 우려한 상황이 이미 현실화되었다고 언급함
    • 현대 CPU와 운영체제의 복잡성으로 인해, 많은 개발자가 실제 동작 원리를 잘못 이해하고 있음

Louis Bucciarelli의 ‘전화기’ 사례

  • Bucciarelli는 1994년 저서 Designing Engineers에서 기술적 문해력의 한계를 논의함
    • 대부분의 사람은 전화기의 작동 원리를 물리적 수준에서 설명하지 못함
    • 통신망의 라우팅, 신호 처리, 위성 전송, 기업 운영, 규제 구조 등 다층적 요소가 얽혀 있음
  • 그는 “누구도 자기 전화기가 어떻게 작동하는지 완전히 알지 못한다”는 결론에 도달함
    • 이는 복잡한 기술 시스템이 인간의 완전한 이해를 초월한다는 점을 상징함

기술 인터뷰와 ‘지식의 한계’

  • 저자는 Netflix 근무 시절 Brendan Gregg과의 대화를 회상함
    • Gregg은 면접에서 지원자의 지식 한계와 그에 대한 반응을 평가했다고 함
    • 그는 “아무도 시스템 전체를 완전히 이해하지 못한다”는 사실을 전제로 면접을 진행함
  • 이 접근은 모르는 것을 인정하는 태도가 기술적 역량만큼 중요함을 보여줌

복잡성의 본질과 AI의 영향

  • Wardley, Jacob, Perens, Bucciarelli의 견해는 서로 다른 층위에서 복잡성의 불가피성을 드러냄
    • Wardley: 이해 없는 구축의 위험
    • Jacob: AI가 가져온 효율과 거리감
    • Perens: 이미 존재하는 복잡성의 현실
    • Bucciarelli: 시스템 전체 이해의 불가능성
  • 글은 AI가 이 문제를 심화시킬 것이라 인정하면서도, 부분적 이해 속에서 기술을 다뤄온 인간의 오랜 현실을 상기시킴

독자 논의 요약

  • 댓글에서는 AI가 학습과 이해를 약화시킨다는 우려가 다수 제기됨
    • 일부는 “LLM이 코드를 대신 작성하면서 이해의 사슬이 끊어진다”고 지적
    • Wardley는 “이전에는 위계적 체인 속에서 이해가 유지됐지만, LLM은 그 체인을 제거한다”고 설명
  • 다른 독자는 “AI의 이점이 위험보다 크다는 단정은 섣부르다”고 반박함
  • 전반적으로 AI 시대의 기술 이해 상실과 학습의 단절이 주요 논점으로 부각됨
▲
GN⁺ 6시간전  [-]
Hacker News 의견들

  • 요즘 프로그래밍에서 걱정되는 건, 위층(제품의 목적)도 아래층(구현 방식)도 모르는 ‘중간층 개발’ 이 늘고 있음
    예전엔 비즈니스는 몰라도 코드의 의미는 이해했는데, 이제는 코드가 어떻게 작동하는지도 몰라도 된다는 분위기임
    Claude를 쓰다 보면 점점 상황 인식 능력이 떨어지는 느낌이 듦. 테스트가 통과하고 버튼이 눌리면 끝이라는 식의 개발 문화 속에서, 나는 더 이상 배울 것도, 기여할 것도 없는 존재처럼 느껴짐

    • ‘오너십’을 강조하지만 실제로 주도권을 가지려 하면 접근 제한과 정보 부족에 부딪힘
      특히 대기업일수록 투명성이 부족함. 마감일을 맞추려고 야근했는데, 나만 모르게 일정이 연기된 경우도 있었음
      만약 내가 단순한 도구로 취급된다면 그 역할만 하겠음. 하지만 진짜 오너십을 원한다면, 의사결정 테이블에 앉을 자리가 필요함
    • 반대로 나는 Claude 덕분에 오히려 집중력이 높아졌다고 느낌
      예전엔 반복적인 설정 작업에 시간을 낭비했지만, 이제는 핵심 기능에만 집중할 수 있음. 덕분에 머릿속에 전체 구조를 더 잘 유지할 수 있음
    • 이 현상은 농업 자동화와도 비슷함. 요즘은 트랙터에 앉아 있기만 해도 기계가 다 해줌. 결국 사람은 단지 좌석 센서용 무게일 뿐임
    • 나는 Claude가 완전 자동 개발보다는 작은 수정 중심의 인터랙티브 코드 편집을 지원했으면 함
      예를 들어 IDE에서 몇 줄 선택 후 음성으로 “이 부분을 이렇게 바꿔줘”라고 말하면 즉시 반영되는 식임
      속도만 충분히 빠르다면 마우스+음성 제어는 접근성 도구로도 훌륭할 것 같음
    • 사실 이런 문제는 예전부터 있었음. 의존성 지옥이 대표적임
      LLM이 오히려 이런 복잡성을 줄여줄 수도 있다고 생각함. 나는 적당한 추상화를 좋아하지만, 내부를 완전히 모르는 건 싫음

  • 이 글은 사람들이 내부를 모른 채 추상화(abstraction) 를 사용하는 현상에 대한 이야기임
    하지만 그건 자연스러운 발전 과정임. 누군가는 그 추상화를 설계하고, 위층이 쓸 수 있게 만들어줬음
    “내가 Wi-Fi 드라이버를 모르니 코드도 몰라도 된다”는 논리는 성립하지 않음

    • 문제는 이제 대부분의 사람이 새로운 추상화를 만들 능력을 잃을 위험이 있다는 점임
      과거엔 ‘필요한 복잡성’을 직접 다루며 사고력을 키웠지만, 지금은 단순히 파이프 역할만 하는 경우가 많음
    • LLM이 만든 코드가 너무 장황해서 검토 시간이 더 오래 걸림
      해결책은 범용 언어 대신 DSL(도메인 특화 언어) 로 추상화를 감싸는 것임. SaaS라면 API-first보다 DSL-first 접근이 더 낫다고 봄
    • 사실 Clean Code와 OOP 문화도 이미 과도한 추상화로 성능 손실을 초래했음
      AI가 그보다 더 나쁘다고는 생각하지 않음. 중요한 건, 자신이 기반으로 삼는 추상화를 이해하는 것임

  • 의존성 트리가 실제로 가장 큰 문제를 일으킴
    Node.js 프로젝트만 봐도 수백 개의 종속 패키지가 있음. 대부분 내부를 몰라도 괜찮지만, 인터페이스가 자주 깨지면 위험해짐
    팀들이 EOL(지원 종료)이나 취약점을 추적하지 않는 경우가 많음. “이게 아직 유지보수 중인가?”조차 모르는 게 현실임

    • 이런 문제를 SBOM/SCA 도구로 모니터링하는 게 이상적임
      하지만 AI 이전에도 이미 버전 충돌로 인한 의존성 지옥에 빠진 프로젝트가 많았음

  • 사람들은 모든 걸 알 필요는 없지만, 기초를 잃는 무지는 위험하다고 생각함
    요리를 예로 들면, 밀을 재배할 필요는 없지만 계란을 굽는 법조차 모르면 문제임
    기업이 모든 음식을 표준화해 조리해준다면, 그건 진보일까 퇴보일까 하는 질문임

    • 대부분의 사람은 사냥이나 농사법을 몰라도 됨. 공급망이 충분히 분산·중복되어 있기 때문임
      언젠가 로봇이 음식 생산을 완전히 대체한다면, 요리법을 몰라도 상관없게 될 것임
    • 어디까지가 괜찮고 어디서부터 위험한지의 기준선은 사람마다 다름
    • “계란을 굽는 법을 모르는 게 왜 위험한가?”라는 반론도 있음.
      재료 과학까지 알아야 의존을 피할 수 있는 건 아니지 않겠음?

  • CPU 명령어와 캐시 같은 하위 계층은 수십 년간 검증과 문서화가 철저히 되어 있음
    반면 LLM이 만든 코드는 그만큼 신뢰할 수 없고, 내일 리팩터링이 필요할 수도 있음

  • 나는 하위 계층의 세부 동작은 몰라도, 내 코드가 어떻게 작동하는지는 이해함
    아래층을 모르는 것과 내 책임 영역을 모르는 것은 완전히 다름

    • 과거엔 복잡한 시스템이라도 각 부분을 아는 사람이 있었음
      지금은 아무도 모르는 코드 조각이 생기는 게 진짜 위험함

  • AI가 상황을 더 악화시킨다는 주장에는 동의하지 않음
    오히려 LLM은 거의 모든 지식을 학습했기 때문에, “전화기가 어떻게 작동하나?” 같은 질문에 체계적으로 설명할 수 있음
    인간은 ‘무엇을 모르는지도 모르는’ 한계가 있지만, LLM은 언어로 표현된 지식이라면 거의 다 다룸
    물론 추론이나 코드 생성은 약하지만, 지식 통합 능력은 인간보다 뛰어남

    • 하지만 LLM은 ‘아는 것’이 아니라 ‘그럴듯하게 생성하는 것’임
      진짜 문서를 대체할 수는 없음. 다만 인간처럼 “무엇을 찾아봐야 하는지”를 알려주는 데는 매우 유용함

  • 좋은 설계는 전체를 몰라도 시스템이 작동하게 만드는 것임
    문제는 AI가 만든 시스템이 아니라, 우리가 그 실패 양상과 한계를 아직 잘 모른다는 점임
    결국 인간과 AI를 어떻게 조율해 필요한 시스템을 만들지, 그 조직적 설계 능력이 핵심임

  • 나는 컴퓨터의 내부를 완전히 알지는 못하지만, 실용적인 스크립트 자동화로 문제를 해결함
    x86 어셈블리를 공부하지 않아도 Python으로 인프라를 관리할 수 있음
    하지만 경험 많은 개발자들이 그 지식을 공유할 책임이 있다고 생각함. 나도 언젠가 그 역할을 이어가고 싶음

    • “실용주의”만 내세우면 결국 과도한 전문화로 이어짐
      호기심을 잃지 말고, 선배 개발자들과 적극적으로 대화해야 함
    • 기본기를 알려주려 하면 “그건 필요 없다”는 반응이 많음
      하지만 기초 이해의 중요성을 아무리 강조해도 무시당하는 현실이 답답함
    • 참고로 좋은 학습 자료로 cpu.land 같은 사이트가 있음

  • “URL을 입력하면 무슨 일이 일어나는가?” 같은 질문에 실제로 답할 수 있음
    나는 미 해군 잠수함 원자로 기술자로 일하며 전자 이론부터 시스템 트러블슈팅까지 배웠음
    이후 IT로 전향하면서도 같은 태도로 문서와 실험을 통해 끝까지 파고듦
    이런 습관 덕분에 문제 해결 시 랜덤한 지식의 연결이 큰 도움이 됨
    VMEbus 위키 문서도 참고할 만함

    • 나도 비슷한 반응이었음. 대부분의 예시를 화이트보드에서 즉석으로 설명할 수 있음
      단, 나는 모르는 걸 참지 못하는 성향이라 아마 예외적인 경우일 것임
    • 이해의 깊이는 다양함. 웹 개발자는 네트워크 스택까진 알지만, 무선 신호의 아날로그 세계는 또 다른 차원임
답변달기