▲

더 나은 AI 도구를 만드는 법

 (hazelweakly.me)
10P by neo 1일전 | ★ favorite | 댓글 1개
  • 현재의 AI 툴 대부분이 인간 중심 학습 프로세스(회상·실행·집단적 반복)를 반영하지 못함 — 이는 궁극적으로 인간·AI 모두의 성장 루프를 망치는 역방향 설계임
  • 인간은 지식이 아닌 '과정(프로세스)'을 배우며, 집단적·누적적 반복을 통해 혁신함. 하지만 대부분의 AI 툴은 "버튼 클릭→AI가 알아서 처리" 패턴으로, 인간의 주도적 회상·학습 루프를 제거하고 있음
  • 바람직한 AI 툴은 “설명→시연→가이드→강화(Explain, Demonstrate, Guide, Enhance)” 단계에서 인간의 능동적 참여와 회상을 유도해야 하며, 자동화가 아니라 '증폭'을 목표로 삼아야 함
  • 예시: 관찰/복구 툴에서 AI가 바로 조치하는 게 아니라, 프로세스 설명·행동 안내·문제 해결 가이드·사후 개선 제안 등 각 단계마다 인간의 사고와 학습을 촉진하는 역할이 필요
  • 이런 인간 중심 패턴이 자리잡으면, 집단적 지식 성장과 AI의 품질도 동반 강화되는 긍정적 피드백 루프가 가능해지며, 시스템 툴링 전반에 혁신을 가져올 수 있음

서론: 인간 학습과 AI 툴링의 본질적 문제

  • AI 도구는 인간 협업과 학습을 지원하는 방향이 아닌, 비효율적이고 역방향으로 제작됨
  • 인간의 역량을 강화하는 방식이 아니라, 비판적 사고와 문제 해결을 저해하는 방향으로 도구가 설계됨
  • 이런 상황은 이미 눈에 띄는 역효과를 낳고 있으며, 더 효과적인 방향으로 전환이 필요함

현행 AI 도구의 한계: 역방향 개발

  • 현재 AI 도구의 대다수는 아래 패턴을 따름
    • AI 버튼 클릭 → 마법처럼 즉시 결과 제공
    • 데이터 표시와 AI 제안
    • 간단한 프롬프트와 자동 실행
  • 이 방식은 인간의 문제 정의·기억·회상·과정 학습·지식 전파·반복적 개선을 핵심 학습 루프를 생략함
  • AI가 인간의 핵심 장점을 대체하려 하고, AI 자체도 그 부분에서 취약함
  • 결과적으로 인간의 문제 해결·사고 능력 퇴보 → 양질의 데이터 생성 불가(이로써 I 발전도 저해) → 악순환 루프 형성

인간은 어떻게 학습하는가?

  • Retrieval Practice 이론에 따르면, 인간은 정보를 입력받는 것이 아니라 능동적 회상을 통해 학습함
  • 단순한 암기가 아닌, 직접 정보를 뇌에서 ‘꺼내는’ 과정에서 진짜 학습 효과 발생
  • 학습에서 가장 핵심은 지식 자체보다 프로세스 습득임
    • 예를 들어 제빵을 배울 때 재료를 외우는 것보다 케이크를 만드는 절차(과정) 를 배우는 것이 효과적임
  • 이처럼 실천적 과정 중심 설계가 협업 도구에 더 적합함

혁신과 집단적 성장의 원리

  • 혁신의 본질은 신기술을 개발하는 개인에게서 나오지 않고, 작은 반복적 개선의 집단적 누적에서 비롯됨
    — 소수의 천재적 창조가 아니라, 기존 지식 위에 복수의 사람이 ‘덧씌우고 개선’하는 과정이 본질
  • 인간은 독자적 혁신보다는 모방과 반복, 기존 사례의 변형에 최적화된 존재임
  • 뇌기반 집단 학습 이론은 이런 집단적 혁신이 인간에게 본질적으로 적합함을 보여줌
  • 문제 해결과 혁신을 별도로 보지 않고, 문제 해결력·지식 전파·집단 학습이 곧 혁신의 원동력임
  • 핵심은 프로세스 중심의 학습, 적정 난이도의 노력, 집단적 반복·강화, 인간 보조적 AI 임
  • AI 툴은 인간의 ‘사고 보조자’여야 하며, 스스로 판단하고 대체하는 존재가 되어선 안 됨

올바른 AI 인터랙션 설계

  • AI는 동료나 인턴보다는 '건망증 심한 강사'에 비유 가능
  • AI의 목적은 사용자가 스스로 배우고, 어떻게 배워야 하는지 배우도록 안내하는 것임
  • 효과적인 교육 프로세스(EDGE: Explain, Demonstrate, Guide, Enhance)를 증강하는 방향으로 설계
    • 설명(Explain): 프로세스 안내, 누락 단계 제시 등 (단순히 “버튼만 클릭하세요”가 아님)
      • 누락된 단계 제안
      • 프로세스 안내서 제공 및 해설
      • 인간이 직접 프로세스를 떠올리고 실행하는 과정 강조
      • 잘못된 예: 즉시 '실행' 버튼 제공, 오류 툴팁 등 회상 과정 소외
    • 시연(Demonstrate): 쿼리 변환, UI 시연, 인터랙티브 데모 등 직접적 “자동 실행”이 아닌, 참여 유도 중심
      • 자연어 쿼리를 시스템 쿼리 문법으로 변환
      • UI 탐색 지원(요청 시 바로 관련 화면 안내)
      • 짧은 15초 데모·인터랙션형 튜토리얼 제공
      • '자동 실행'은 지양: 신뢰도 저하, 미세 조정 불가, 인간 역량 저하
      • 데이터 추가 및 인간 회상 기록(페어링, 멘토링 등)도 AI가 학습 재료로 삼아야 함
    • 가이드(Guide): 질문 유도, 문제 구간에 대한 토론, 행동 계획 수립 등 소크라테스식 질의/검증
      • 사용자가 계획을 제공한 경우, 다음 액션·가이드 제안
      • 필요한 문서, 코드 담당자, 관련 자료 안내
      • 관찰/학습 모델, 기록화 유도
      • 응답 검증, 정보 교차검증, 명확성 확인
      • 잘못된 예: 답변 유도 없이 지원, 요청하지 않은 정보 과다 제공, 권위적 태도, 사용자의 '계속 진행' 버튼 남용 가능성
      • 인간의 합리적 추론 반복을 방해하지 않는 범위에서 보조해야 함
    • 강화(Enhance): 행동 이후 개선 제안, 반복 패턴 학습, 실전 기록의 포스트모템화 등 미세한 학습 계기 제공
      • 액션 직후/중, 점진적 개선 제안
      • 반복 작업에 대한 단축키/추가 기능 동적 노출
      • 프로세스 자체 개선 제안: 인프라 파이프라인 개선, 알림 수정, 직관 사용 시 계측 개선 권유 등
      • 사고 후 기록(노트→학습 자료화), 관찰을 통한 미시학습 촉진 등
      • 인간 추론 허브를 유지, 자동 최적화보다는 회상 강화 프롬프트를 자연스럽게 도입
  • 특히, 각 단계마다 인간이 회상·선택·실행하는 구조를 견고히 하고, AI는 이를 증폭시키는 역할에 집중해야 함
    • 실제 사례(사건 관리·관찰 툴) 제시에 기반해, 각 단계별로 양질의 AI 인터랙션 예시와 안티패턴을 설명

총괄 원칙

  • 인간 학습을 지속적으로 강화
  • 팀워크 촉진 : 집단적 협업과 정보 공유
  • “빈칸→정답” 자동화 대신, 프로세스 참여·실행 중심 가속화 (단 자동화로 직접 대체하지 않음)
    • '무(無)에서 바로 결과' 지양
  • “노력 없는 사용성”이 아니라, 적절한 노력·참여를 요구하는 툴
  • 팀 학습·경험이 결과물에 반영되도록 지원

코드 작성에 적용되는 좋은 예시 : '역방향' 아닌 '순방향' 설계

  • AI로 바로 코드 생성하는 것이 아니라,
    • 초안 문서 작성 → 아키텍처 그림 → 테스트 계획 → 테스트 코드 → 스텁 코드 → 코드 생성
  • 코드 검증 후 전체 프로세스 역방향으로 테스트·문서·아키텍처 재정비
  • 각 단계마다 질문·검증(회상 강화) 을 중시, 검증 불가 상태에서 예·아니오만 묻지 않아야 함
  • 회상 기반 개발 방식은 고품질 학습/테스트 데이터를 생성, AI 학습도 보완

크로스펑셔널(비개발, 예: 고객 지원) 확장 가능성

  • 예: 사고 발생으로 운영 중단 상황에 고객 지원팀이 AI를 통해 개발팀과 소통
    • AI가 1차 초안을 제공하고, 개발팀 검증 후 정확도 높임
    • 지원팀, 개발팀 등 여러 조직 간 실시간 정보 흐름, 컨텍스트 전환 부담 최소화
    • 핵심 전문가가 과다 인터럽트 당하지 않으면서, 필요시 상호 소통 원활
    • 개발팀의 맥락적 기술 답변을 AI가 대중적 설명문으로 쉽게 변환
  • 이런 구조가 실현되면, 조직 내/외 집단 학습과 협업 효율이 극대화될 수 있음
  • 다중 계층 지원/통합도구로 발전 가능

결론

  • 현행 AI 도구는 인간의 집단 반복 학습·문제해결 능력을 약화시키는 방식(역방향)으로 개발됨
    • 협업 강화, 인간 주도 프로세스 지원을 강조하는 전환 필요
  • 그렇게 할 때 비로소 인간과 AI가 상호 증폭적 성장을 이루는 선순환 가능
  • 도구 설계 시 인간을 단순히 '루프 내'가 아니라, 인간 자체가 곧 루프임을 잊지 말아야 함
  • 이제야말로 시스템 도구에 인간 중심 혁신이 요구됨
    • 협업적, 과정 중심, 증폭형 AI 툴이 혁신의 열쇠
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 이 글은 혼란스러운 부분이 있음. Weakly가 마치 2025년 기준 antirez가 좋아한다고 밝힌 방식처럼, 조금 더 수동적이고, 조언 위주로만 작동하는 코딩 에이전트를 말하는 듯하지만 실제로는 운영 이슈를 조사하고 해결하는 역할의 에이전트를 다루고 있음. Weakly의 주장은 에이전트가 Clippy처럼 조언만 하고 사람한테 운전대를 주라고 하는 것임. 그런데 굳이 사람이 로그를 뒤져가며 이상치를 찾고 가설을 세우는 데서 어떤 가치가 있는지 모르겠음. 컴퓨터가 체스를 더 잘 두는 이유와 마찬가지로, AI가 이런 일은 원천적으로 사람보다 잘하는 툴임. Weakly가 조언과 실제 행동 사이에 선을 확실히 긋는 거 같은데, 나는 그 선이 옳다고 생각하지 않음. 물론 AI에게 자율 실행을 전적으로 맡길 수 없는 영역도 있지만(예: Terraform apply 실행), 반대로 굳이 막을 이유가 없는 영역도 많음. 인시던트 해결의 목적은 결국 사고를 해결하는 것임

    • 아직 아무도 만족스럽게 인시던트를 해결해주는 AI 툴은 없음. 책임 문제도 있고, 올바른 실행을 보장하기 위해서라도 사람의 개입이 꼭 필요함

    • 본질적인 문제는 실제 운영 환경에 AI의 접근권한을 줄 것이냐에 있음. 최근 AI가 “하지 말라”는 명령에도 데이터베이스를 삭제한 사례를 보면(‘not’ 같은 부정 명령을 AI가 항상 제대로 인식하지 못하기 때문), 실제 안전상 큰 우려가 있는 상황임

    • 어디까지 에이전트에게 자율권을 줄 수 있을지가 궁금함. DevOps 모범사례라면 대부분의 변경사항은 코드 커밋이나 여러 환경에 프로모션을 거친 후에야 프로덕션에 반영되는 구조일 것임. 애플리케이션 코드뿐 아니라 인프라 자체도 포함임. 이런 상황에서 인시던트 대응 작업 중 에이전트에게 자율 실행을 허용할 만한 부분이 어디까지인지 궁금함

    • 직접 디버깅을 해보는 것도 일정 부분 가치는 있다고 생각함. 특히나 목표가 프로그래밍 실력 자체를 끌어올리는 데 있다면 더더욱 그렇다고 느낌. 체스를 예로 들면, Leela나 Stockfish처럼 AI가 훨씬 빠르고 깊게 분석할 수 있지만, 진짜 실력 향상은 직접 포지션을 분석해보는 경험에서 나온다고 생각함. 체스 프로 선수들도 반복적으로 전술 연습을 하며 늘 브레인을 단련함. AI와 사람이 함께하면 더 빨리 배울지 독립적으로 배울지, 나도 답을 잘 모르겠음. 그리고 이런 능력 자체가 앞으로 의미있는지에 대해서도 생각이 엇갈림

    • 이상 감지, 인시던트 관리 관련 논의에서 중요한 부분 중 하나는 모든 문제가 동일하지 않으며, 많은 문제는 어느 정도 자동화가 가능하다는 점임. 언제 어떤 문제를 AI 같은 인지 프로세서에 넘길지, 언제 사람 엔지니어가 직접 개입해야 하는지 경계가 중요함. AI가 대규모 패턴 탐지는 잘하지만, 의미 있는 패턴인지까지 계속 잘 맞히는 것은 아님. 물론, 이런 빈틈을 사람이 항상 메울 수 있는 것도 아님

  • AI 툴/제품의 관점에서 앞으로는 "지능형 워크스페이스(Intelligent Workspaces)"로 가야 한다고 봄. 단순 챗봇에서 벗어나야 함
    관련 링크
    기본적으로, 모든 설정, 레버, 제어권을 인간에게 주면서 AI 기능이 긴밀하게 통합된 환경/플랫폼이 중요함. 이건 단순 VSCode 포크 그 이상으로 어려운 일임

    • 챗봇이 지능형 워크스페이스보다 구현이 훨씬 쉬움. 그리고 AI는 인간 인터랙션 없이도 잘 동작함. 나는 채팅이 아닌 다른 인터페이스로 AI를 활용하는 방법이 더 다양해졌으면 함

    • 최근 Claude Code로 프로젝트를 하고 있는데, 내 인스턴스가 다른 개발자의 인스턴스와 대화하며 협업할 수 있으면 좋겠음. CLAUDE.md를 수정해 문서를 유지할 수는 있지만, CC 자체에 팀 협업 기능이 내장되어 있으면 정말 좋을 것 같음. 좋은 제안 있으면 공유 바람

  • 이 글은 혁신이 왜 종종 외부자에게서 나오는지 잘 보여준다고 생각함. 필자가 대형 조직의 엔지니어링 관리자나 수석 엔지니어 경력이 강하게 묻어있어서, 내 경험과는 크게 공감되지 않음. 만약 이런 스타일이 AI 툴링의 정석으로 굳어진다면, 인간 워크플로에 대한 특정 추정에 기반해 AI가 정체되는 현상이 나타날 거라 우려함. 나는 15년 동안 (비프로그래머) 도메인 전문가 보조 ML 애플리케이션 R&D를 해왔는데, 필자의 원칙과는 다소 다릅니다. 시야가 이렇게 다르다는 건 디자인 공간이 매우 크며, 특정 방식이 정답이라는 결론을 내리기엔 너무 이르다고 봄. 앞으로 AI 툴링이 어디로 갈지 아직 아무도 모름

    • 물론 한 가지 해석은 내가 만든 ML 시스템이 지난 15년간 사람의 역량을 평준화하거나 대체해왔다는 얘기도 가능함. 하지만 각자 처한 위치에 따라 해석이 다르다는 데는 동의함. 다만, 인간(그리고 인간의 지식/검색능력)이 워크플로의 중심에 최대한 있도록 하는 것이 좋은 관행이라는 생각임

  • AI 코딩에서 항상 걱정하는 부분은 실력 유지가 어려워지는 현상임. 직접 코드(보일러플레이트 포함)를 타이핑하는 과정이 꼭 Mr. Miyagi의 페인트칠 같은 훈련임. 이런 반복적 훈련 덕분에 머릿속에 패턴이 깊게 남아, 더 높은 수준의 설계 결정을 내릴 때 큰 힘이 됨

    • 과거 기술(글쓰기, 인쇄 등)도 어쩌면 필체나 수사력을 저하시켰을 텐데, 오히려 생각하는 능력은 증폭시켰음. “Bicycle-for-the-mind” 같은 Steve Jobs의 아이디어가 대표적임. 다만, 이런 논리를 AI에 적용할 땐, 예전 기술은 유통의 병목을 풀었지만 AI는 창의 프로세스 그 자체를 직접 겨냥한다는 점이 다름. 창의적 작업에서 AI 활용은 오롯이 내 창의력 자체의 발달을 방해하지 않는 한에서만 바람직하다고 생각함. 인간의 자기 통제력/자각에는 한계가 있음

    • 나는 밤이나 샤워할 때 종종 문제를 머릿속으로 곱씹으며 "코드"를 떠올림. 언어 구조가 머릿속에 깊게 박혀 있지 않았다면 이런 상상 코딩도 힘들었을 것임

    • 일상에서도 비슷한 예를 찾을 수 있음:

  1. 언제 손글씨로 의미 있는 글을 써봤는지 기억도 안 남. 내 손글씨는 이제 정말 엉망임
  2. 내비게이션 없으면 운전길을 찾을 엄두를 못 냄. 지도 읽기? 이제는 꿈같은 얘기임

  • 트랜지스터를 수작업으로 납땜하던 시절도 있었음. 하지만 이제는 기술이 워낙 발전해서 과거처럼 직접 하려면 부담이 큼. 이렇게 계속 사고의 초점을 확장했다 축소했다 하면서, 나는 아직도 코딩이 그립기도 함. 여전히 코딩을 많이 하긴 함

  • “Every augmentation is an amputation(모든 증강은 어떤 부분의 절단)” - Marshall McLuhan

  • 나는 그래서 딥 리서치(Deep Research)를 정말 좋아함. 항상 질문부터 던지고, 내가 배우고 싶은 걸 스스로 더 명확히 정의하게 끔 만듦. 단순한 UX 변화가 서비스 사용자의 학습에도, 반대로 비판적 사고 없이 도구에 의존하게 하는 결과에도 큰 차이를 만든다고 느낌

    • 그런데 그 질문 자체를 정말 유심히 본 적 있는지? 딥 리서치가 요긴할 때도 있지만, 때로는 그 “질문”이 그저 있어 보이려고 추가된 것처럼 느껴짐. 이미 내가 신경 써서 명확히 써둔 부분까지 꼭 굳이 다시 묻는 경우가 많음. 실제 검색 과정엔 큰 도움 안 되는 것 같음

    • 나는 테크니컬 라이터로서 Deep Research를 쓰지 않는 편임. 오히려 내 업무에 방해가 됨. 연구, 메모, 요약 과정 자체가 내가 주제를 깊이 이해하도록 도와주는 핵심임. 기록물 자체는 그 결과물일 뿐임. AI가 그 일을 대신해주면 메모를 얻게는 하지만, 그만큼의 이해를 얻지 못함. AI가 써준 문서 읽는 것으로 직접 경험을 대체할 수 없음

  • 이 글은 AI 도입의 핵심을 혼동한다는 생각임. AI 도입의 목적은 사람을 더 똑똑하게 만들기 위해서가 아니라, 인간 창의력이 의미 있게 보상받지 않는 반복 업무를 없애서 전체 프로세스의 생산성을 올리는 데 있음

  • 내 경험상, 코딩할 때 AI를 가장 잘 활용하는 방법은 다음과 같음:

    • 고급 find/replace처럼, 구조체 초기화 같은 부분을 한꺼번에 "이거 다 Y로 바꿔줘"라고 지시할 때. (regex는 너무 빡셈)
    • 에이전트 작업 프로세스에서는, 사람처럼 대하지 말고 더 높은 수준의 조각 작업을 단계별로 지시하는 게 효과적임. “기능 구현해줘” 보다 “새 파일 만들고 스텁 함수 정의” → “첫 번째 함수부터 x 동작 넣기” → “두 번째 함수는 첫번째 함수 먼저 호출 후 Y 하기”처럼 쪼개서 지시
    • 익숙하지 않은 코드베이스에서 정보 찾거나, 특정 구현법 묻기. “copilot, 앱 라우트 다 어디에 정의돼 있어?”처럼, 예전에는 IRC 고수에게 번번이 물었을 일들을 빠르게 확인할 수 있어서 매우 편리함

  • 최근 아버지께서 발표 자료 준비 도와드림. 아버지는 정보는 충분히 갖고 계시지만, 비디자이너라서 슬라이드를 예쁘게 꾸미는 데 어려움이 있었음. 여러 AI 슬라이드 생성 앱을 써봤는데, 멋있어 보여도 실제로 사용자가 바라는 "디자인 개선"에는 도움이 안 됐음. 결국 수작업으로 더 예쁘게 꾸미는 게 훨씬 낫다는 결론임

  • 특히 “아키텍처와 테스트 설계부터 시작해서 실제 코드에 적용한다”는 흐름이 100% 더 효과적이었다는 데 전적으로 동감함. 워크플로 습관만 바꾸면 별도 툴이 없어도 가능함(물론, 전용 툴이나 표준 프롬프트가 있으면 더 좋음)

    • 나도 이게 꼭 필요해서 직접 아키텍처 툴을 만들기 시작함. 건설적인 아키텍처만 있으면 구현은 현재 AI에게 넘기는 것도 충분히 가능함. 단, 이 도구들이 docker-compose 같은 장기 실행 프로세스 로그를 읽는 데 아직 약함. 그리고 실제 수행해야 할 일은 다음과 같음:
      • 문제 조사
      • 기능 설명
      • API 계약 정의
      • 기본 구현 계획 작성
      • 인증/권한 설정
      • 테스트 전략과 효율적 테스트 셋업/해제 마련
      • 라이브러리 문서화 및 AI를 위한 공식 문서 검색
      • 그리고 AI가 import 등에서 자주 실수함, 장시간 동작하는 프로세스도 취약점
    • 여기서 “vibe”라는 말 안 써도 똑같은 문장이 될 정도로 본질적인 얘기임

  • 인간은 누적적 반복(지속적 개선)에 정말 특화된 종임. 그래서 브레인스토밍이 그룹에서 특히 효과적인 거임. 인지 심리학에는 이런 집단적 학습과 혁신의 누적적 “문화” 이론이 있을 정도임. 우리가 흔히 “거인의 어깨 위에서”라는 말을 쓰는데, 단순히 멋진 말이 아니라 실제로 인간의 작동 원리임. 창의성은 결국 검색, 그것도 사회적 검색임. 뇌의 내부가 아니라 뇌와 환경의 상호작용, 사회/문화적 층위에서 발전해감. 그래서 나는 LLM이 진짜 “이해”하는지를 고민하지 않음. 그저 검색하고, 아이디어를 만들어내고, 실제로 검증한다면 그걸로 충분함. 또한, 기반(Substrate)이 무엇이든 검색 자체가 더 중요하다고 생각함. 다만, 기반에 따라 접근할 수 있는 검색 공간은 달라질 수 있음

답변달기