▲

AI 코파일럿은 이제 충분함, 우리는 AI HUD가 필요함

 (geoffreylitt.com)
1P by GN⁺ 20시간전 | ★ favorite | 댓글 1개
  • Mark Weiser가 1992년에 발표한 AI '코파일럿' 메타포 비판이 지금도 유효함
  • Weiser는 '보조자'가 아니라 사용자 경험에 자연스럽게 녹아드는 인터페이스를 주장함
  • 현대 항공기의 HUD(헤드업 디스플레이) 개념이 이러한 철학을 잘 보여줌
  • 오토메이션이나 에이전트 UI 대신, 사용자 감각을 확장하는 HUD 스타일 UI의 가치가 여러 사례로 드러남
  • 일상적 작업에는 코파일럿이 효과적이지만, 창의적/비정형 상황에서는 HUD가 인간의 능력을 더욱 강화함

1992년 Mark Weiser의 코파일럿 비판

  • 1992년 Mark Weiser는 MIT Media Lab의 '인터페이스 에이전트'에 관한 행사에서 AI를 '코파일럿'으로 비유하는 관점에 비판을 제기함
  • 컨텍스트 인지와 자동화 등 오늘날에도 유효한 문제들을 당시에도 논의함
  • Weiser는 '코파일럿'(가상 인간처럼 조종사의 보조 역할을 하는 AI) 대신, 사용자가 정보를 자연스럽게 감지할 수 있는 시스템을 옹호함
  • 그의 이상은 '눈에 띄지 않는 컴퓨터' 로, 사용자의 신체 일부처럼 자연스러운 연장선이 되는 환경임

HUD(헤드업 디스플레이)와 Weiser의 철학

  • 현대 항공기의 HUD(HUD, Head-Up Display) 는 투명 디스플레이에 수평선/고도 등 핵심 정보를 오버레이하여, 조종사 시야에서 자연스럽게 제공함
  • HUD는 코파일럿과 달리 대화가 필요 없고, 자연스럽게 인지 능력을 확장하는 효과를 줌
  • 이러한 HUD 개념은 Weiser가 제시한 사용성에 부합함

소프트웨어에서의 HUD 실현

  • 스펠체크는 'AI 협력자'처럼 대화하지 않고, 오타에 빨간 밑줄을 자동으로 그어주는 방식으로 작동함
  • 이처럼 즉각적이고 시각적인 정보 제공이 사용자의 새로운 감각을 만들어내는 HUD의 한 예시임
  • AI를 활용한 커스텀 디버거 UI 역시 프로그램 동작을 직관적으로 시각화해, 사용자가 문제를 직접 파악하고 이해할 수 있게 해줌
  • 이러한 접근법은 전통적 오토메이션이나 '가상 보조자' UI와 구분되며, 인간의 감각을 직접적으로 확장함

HUD와 코파일럿의 트레이드오프

  • 저자는 HUD가 항상 코파일럿보다 낫다는 관점은 아니며, 각각의 장단점이 존재함을 설명함
  • 루틴하고 예측 가능한 작업(예: 직선 비행)에는 코파일럿 방식이 효율적임
  • 비정형적이고 창의적인 문제(예: 비상착륙 시 상황 인지)에는 HUD처럼 인간의 인지를 보조하는 도구가 큰 힘을 발휘함
  • AI 설계자는 '어시스턴트'에서 벗어나 HUD 등 인간 감각 확장형 UI도 반드시 고려해야 함

결론

  • 미래의 AI 디자인에서는 코파일럿 방식과 HUD 방식 모두의 가치와 트레이드오프를 인식할 필요가 있음
  • 평범한 자동화는 가상 보조자에게 맡기고, 더 뛰어난 결과를 원한다면 HUD처럼 인간 전문가에게 '새로운 슈퍼파워'를 제공하는 방법이 가장 강력할 수 있음
▲
GN⁺ 20시간전  [-]
Hacker News 의견
  • 나는 소스 파일의 각 토큰이 모델에게 얼마나 놀라운지 보여주는 히트맵을 토글하는 기능이 유용할지 매우 궁금함. 빨간색 토큰은 오류, 나쁜 네이밍, 잘못된 주석일 확률이 높음
    • 예측 불가한 코드가 참신한 알고리즘 때문일 때도 있지만, 이런 경우엔 더 좋은 문서화가 꼭 필요함. 코드에 제대로 설명을 달아주면 그 자체가 덜 놀랍게 됨. 즉, 소스의 특정 부분이 놀랍지 않게 구조화하는 것이 가능하며, 그게 좋은 엔지니어링 관행일지도 모름. LLM 덕분에 모두가 좋은 문서화의 중요성에 신경 쓰게 됐음. 다른 사람뿐 아니라 AI가 시스템을 읽고 이해하게 하려면 더더욱 필요함
    • 아이디어가 정말 멋지다고 생각함. 반대로, AI의 제안도 신뢰도별로 히트맵을 만들어주면 정말 유용할 듯함
    • 나는 에디터안에 이런 기능이 들어갔으면 좋겠음. 글쓰기가 너무 예측 가능하거나 식상한지 확인하는 데에도 좋음. perplexity 계산도 어렵지 않으니, 에디터 UI에 통합만 하면 됨
    • 흥미로움. 나는 우리가 LLM 초창기 열풍 때부터 나온 ‘낮은 과실’을 충분히 활용하지 못했다고 종종 느낌. 이런 게 바로 그런 아이디어임
    • 진짜 환상적인 아이디어라고 생각함
  • 10년 전쯤 Bret Victor가 피드백 지연을 최소화하는 것이 삶의 원칙이라고 말한 적이 있음. 빠른 반복 주기가 코딩을 더 잘하게 할 뿐 아니라 창의적인 인사이트에도 기여한다고 했음. 다양한 예시 프로그램을 만들어서 대안을 보여줬고, OP에서 언급된 HUD 사례 역시 그가 “시간을 되짚어 코드를 이해한다”는 시연과 매우 유사함. 관련 영상
  • 이 아이디어가 마음에 들어서, 코딩 전반에 어떻게 적용할 수 있을지 생각해봤음. 상상해보면: 코드를 작성할 때 LLM이 테스트를 생성해주고, IDE가 그 테스트를 실시간으로 돌려줌. 매 키 입력마다 테스트 10~100개가 <1ms 안에 실행되고, 결과는 눈에 거슬리지 않게 표시됨. 테스트는 코드 옆별도의 패널에서, 마지막 실행에 통과/실패 여부는 빨간/초록 점으로 구분됨. 어떤 테스트가 있고 없고, 그 상태만 봐도 작성 중인 코드가 ‘밖에서’ 뭘 하는지 알 수 있음. 만약 LLM이 작성하지 않는 테스트가 필요하다고 생각하면, 프롬프트가 잘못됐거나 코드가 의도와 다르다는 신호일 수 있음. 실시간 속성이 코드를 다듬는데 큰 도움임. 전통적인 TDD로 하고 싶으면, 사용자가 테스트를 쓰고 LLM이 코드를 작성해 테스트를 통과시킬 수도 있음
    • 테스트를 사람이 먼저 작성하고 LLM이 코드를 만드는 방식이 훨씬 더 나음. 왜냐하면 테스트가 곧 코드의 ‘진실’이자 ‘의도’이기 때문임. 입력과 출력을 결정하는 주도권을 내려놓으면, 개발자는 더 이상 운전석에 앉는 게 아님
    • 진지한 C++ 코드베이스에서는 이런 방식이 실현 불가임. 컴파일 시간만 해도 불가능하게 만들고, LLM이 테스트를 추측하는 것도 코드 전체를 작성하지 않으면 힘듦. 예를 들어 새로운 자료구조를 만드는데 LLM이 어떻게 그걸 알겠음
    • 코드 작성 시 LLM이 테스트를 생성해서 IDE가 매번 돌려주는 게 좋은 방식은 아님. 테스트는 불변성을 보장하는 코드라 LLM이 막 만지면 곤란함. 테스트는 사용자가 명확히 바꿀 때에만 바뀌어야 하고, 그 자체만 바뀌어야 함. 이런 제약 아래서는 이미 일상적 워크플로우가 되어버림. JavaScript 테스트 프레임워크의 watch 모드처럼 말임. 그런 워크플로우는 이미 10년 전부터 개발자들이 해오던 것임
    • 테스트가 제대로 작성됐는지 확인하는 테스트도 필요하지 않겠음? 아니면 LLM이 테스트 자체가 잘못돼도 그저 통과시키기만 할 것임. 혹은 시스템을 속이는 코드만 쓸 수도 있음. 결과적으로 LLM과 인간이 각자의 경계를 자유롭게 넘나드는 환경이어야 잘 되는 셋업이 생길 것임. 명확한 요건만 쓰고 AI가 양쪽 대부분을 처리하는 게 훨씬 생산적이고 streamlined함
    • 매 입력마다 전체 테스트 스위트를 돌리는 건 ROI가 너무 낮음. 대부분의 키 입력은 ‘미완성’인 프로그램이므로, 테스트 실행 시점을 더 똑똑하게 정해야 합리적인 균형을 맞출 수 있음
  • 결국 모든 것이 "인간이 디지털 정보를 다루는 이상적인 인터페이스가 무엇인가?"라는 문제로 귀결됨. 우리는 매일 점점 더 많은 정보를 받아들이고, AI때문에 그 양이 줄지 않고 더 늘어남. 복잡하고 전문적인 정보 (예를 들면 에러 로그)까지 요약해주면, 그 전엔 못 본 사람들이 정보에 접근할 수 있는 새로운 길이 열림. 그렇다면 우리가 이 많은 정보를 어떻게 효율적으로 다뤄야 할까? 지금은 각종 인터페이스, 사이트, 대시보드, 이메일, 채팅이 있는데, 앞으로 10년 뒤에도 다 필요할지 의문임. 내가 단일 채팅 인터페이스에서 모든 정보를 받을 수 있으면 굳이 사이트에 들어갈 필요가 있을까? AI가 우리 대신 웹사이트, 앱, 웹 UI를 만들어 주는 게 이제는 좀...중복적으로 느껴짐
    • 웹사이트란 곧 회사나 위키피디아같은 신뢰할 수 있는 곳에서 ‘공식적인’ 정보를 받는 수단이었음. 이런 신뢰성이 강력했기에 "line of death"나 자물쇠 아이콘, 피싱 대책, 동형문자 공격 대응에도 공을 들인 것임. 다 이 사이트가 신뢰할 만한 공식정보라는 가정 아래 움직였던 것임. 사람 모두가 LLM을 비판 없이 의존하는 세상에선 ‘신뢰’가 뭔지 정말 헷갈림. LLM이 보통 맞다고 해도, 아주 중요한 순간에도 그걸 믿을 수 있을까?
    • 6세대 전투기 디자이너들도 똑같은 문제에 부딪히고 있음. 조종석이 기체와 조종사의 인터페이스인데, 점점 역할이 줄어듦. 7세대가 되면 인간이 가치 있는 역할을 할 수 있을지 의문임. (그래도 국제법이나 Skynet-리스크 관리 등 이유로 인간 개입이 필요하면 남을 수 있음) 아마 모든 분야의 인터페이스도 이렇게 진화할 것임. 점점 복잡성이 줄어들고, 인간은 단지 시스템에 원하는 걸 고수준 개념으로 설명해주면 됨. 꼭 자연어가 아니라, 정밀한 명세가 필요하다면 그에 맞는 인터페이스일 수도 있음
    • 모든 사람은 다르니까, 인터페이스를 일반화하지 말고 즉석에서 다이나믹하게 커스터마이즈해야 함
    • 스마트폰이 정말 완벽하고 사실상 충분히 활용되고 있다 보기 어려움. 나에겐 가장 마음에 듦
  • AI가 실시간으로 복잡한 시각화를 만들어주는 기능은 정말 유용하다고 생각함. 예를 들어 특정 코드 경로에서 메모리 릭을 디버깅할 땐, AI가 해당 경로의 메모리 할당/해제를 시각화해 문제를 파악하게 도와주는 방식임. 개별 문제에 적합한 시각화툴을 AI가 직접 만들어주는 시대가 열릴 듯함. Jonathan Blow가 LambdaConf에서 발표한 최근 토크가 이 아이디어와 딱 맞닿아 있음. 그는 다양한 방식으로 프로그램을 시각화해 잠재적 문제를 찾는 툴을 보여줬음. AI가 그런 툴을 잘 만들 수 있을 것 같음. 영상 모두보기
  • Claude Code의 TODO 아이템과 연결된 변경점을 바로 HUD로 보고 싶음. 인라인 주석은 나중에 누적돼서 LLM이 제대로 정리해주지 않으니 원하지 않음
  • HUD가 아직 대중적으로 확산되지 않은 가장 큰 이유 중 하나는 현재 사용되는 디스플레이 매체의 한계 때문임. 모니터나 모바일 기기는 주변적이고 비침투적인 정보를 제공하는 데 서툼. AI 에이전트가 버그를 고치거나 복잡한 태스크를 처리할 때, 결과 기다리는 시간이 애매함. 너무 짧아서 딴 걸 하기엔 힘들고, 그렇다고 화면만 계속 보기도 어색함. HUD가 있으면 훨씬 짧은 피드백 루프를 가질 수 있음. AI가 뭘 하고 있는지 곁눈질로 보면서 즉시 개입하거나, 아니면 그냥 다른 일을 계속할 자유가 생김. 전체 집중 아니면 완전 방관, 이런 극단적 선택 대신 ambient한 인식 속에서 개입 강도를 그때그때 선택할 수 있다는 점이 중요함. 그래서 VR/AR이 AI HUD의 핵심 킬러앱이 될 수 있다고 생각함. 공간 컴퓨팅 덕분에 AI 도움을 2D 화면에서 눈을 떼지 않고도 받아볼 수 있음. 이런 접근은 요리나 자전거 수리 같은 물리적 작업에서도 특별히 도움이 클 것임
    • 나는 ultrawide 모니터와 랩탑 화면을 연동해서 똑같이 활용하고 있음. 게임에 몰입하거나 다른 작업을 하면서 한쪽 구석 tmux 창에 Claude를 띄운 뒤, 다음 스텝이나 중요한 변화가 있을 때마다 바로 확인함
  • HUD 방식의 코딩 인터페이스는 사실상 AREPL이라고 생각함. 디버깅엔 잘 맞지만, 채팅창이나 인라인 Q&A가 훨씬 더 다양하게 쓸 수 있다고 느낌. 전반적으로 챗 이외의 대체 인터페이스 논리에 동의는 하지만, 현실적으로는 채팅이 이미 스마트폰에서 압도적인 인터페이스임. HUD는 AR 글라스 같은 진짜 HUD에 더 잘 맞을 듯함
  • 나는 배경에서 오랫동안 자율적으로 동작하고, 필요할 때 정보를 ‘푸시’해주는 AI 모델도 가능하다고 봄. 상황을 지능적으로 감지하고, 필터링하고, 요약하여 내용을 전달하고, 필요하면 추천까지 해주는 방식임. 특히 여러 고객을 100가지 상황별로 모니터링해야 하는 비즈니스 현장에서는 훨씬 자연스러움
    • 사실 상황을 정의하고, 관련 데이터를 수집하는 게 제일 어려운 부분임. 자율 시스템이 그걸 해주는 문제 자체는 이미 오래전에 기술적으로 해결된 바 있음
  • "AI를 위한 디자인을 진지하게 한다면, 단순 코파일럿 이상의 인간 내면을 확장하는 형태를 고민해야 한다"는 주장에 동의함. 사실 auto-complete도 이미 그런 역할을 하고 있음. 실제로 LLM과 대화도 할 수 있지만, 단순 명령만 내리거나 자동완성도 가능함. 저자가 언뜻 강조하려는 건, AI가 우리와 나란히, 똑같은 방향을 바라보며 함께 일해야 한다는 점임. 테이블 맞은편에서 논쟁만 하는 '가상 인간' 같은 코파일럿이 아니라, 우리가 시키는 것은 즉시 해주는 진짜 협력자가 필요하다고 봄
    • 저자임. 맞음, GitHub Copilot의 자동완성 UI가 정말 (아이러니하게도) 좋은 HUD 예시임. 탭 자동완성은 마치 두뇌의 일부처럼 스며듦. 그런데 최근 코딩 환경이 chat 에이전트 쪽으로 가고 있음. 더 높은 추상화 수준에서 “탭 자동완성” UI가 어떤 모습일지 상상해볼 필요가 있음. 부수적 디테일에 발목 잡히지 않은, 정말 직접적인 느낌의 코드 설계 방식이 될 수도 있음
답변달기