10월 11일 일요일
AI가 일을 빨리 만들어 낼수록 조직은 생성량보다 검토할 수 있는 양, 사람이 맡을 판단, 소프트웨어가 끝까지 수행할 목표를 다시 설계해야 한다.
속도의 이익은 검토 가능한 양까지만 남는다
AI가 만든 코드와 문서가 사람의 이해를 앞지르면 생산량은 늘어도 결정과 책임은 쌓인다. 도입의 단위부터 사람의 판단 용량에 맞춰야 한다.
완성된 모양과 끝난 판단은 다르다
AI가 코드를 쓰고 화면을 만들며 문서를 늘리는 비용은 빠르게 낮아졌다. 하지만 무엇을 만들지, 모호한 요구를 어떻게 해석할지, 어떤 예외를 감수할지, 누가 오래 운영할지는 여전히 사람의 판단이다. 원문이 말하는 ‘슬롭’은 AI가 만들었다는 이유로 붙는 낙인이 아니다. 생성 속도가 판단 속도를 앞질러, 끝나지 않은 사고가 완성품처럼 보이는 상태다. 이때 가장 위험한 것은 기계가 나쁜 선택을 한 사실만이 아니라 팀이 선택할 지점이 있었다는 것조차 알아채지 못하는 일이다. 한 시간짜리 시제품이 그럴듯하게 움직이면 마지막 통합, 실제 요구사항, 테스트, 제품 결정까지 거의 끝났다는 착시가 생긴다. 그러나 빠르게 도착한 변경 제안도 누군가는 읽고, 시스템에 맞는지 확인하고, 실패했을 때 책임져야 한다. 생성이 공짜에 가까워져도 이해와 소유의 비용은 사라지지 않는다.
병목은 작성에서 평가로 이동한다
문서와 코드가 너무 많이 만들어지면 팀은 더 생산적인 것이 아니라 더 큰 평가 대기열을 갖게 된다. 코드 줄, 파일 수, 변경 제안 수는 결과물의 가치나 유지 가능성을 증명하지 않는다. 오히려 구조가 흐린 시스템에서는 에이전트가 기존의 혼란을 더 빠르고 크게 복제할 수 있다. 그래서 도입 전 질문은 ‘얼마나 많이 생성할 수 있는가’가 아니라 ‘사람이 핵심 흐름과 경계, 데이터 변화, 실패 방식을 어느 크기까지 실제로 검토할 수 있는가’여야 한다. 검토 용량을 넘으면 기능을 더 쪼개고, 한 번에 바꾸는 범위를 줄이며, 요구사항과 완료 기준을 먼저 적어야 한다. 다이어그램은 장식이 아니라 복잡한 시스템의 본류를 짧게 보여 주는 검토 표면이 된다. 팀이 줄 단위 세부를 모두 외우지 않더라도 서비스 경계와 상태 변화, 중요한 예외를 한눈에 확인하게 해 준다.
도구보다 운영 규율을 먼저 자동화한다
좋은 AI 활용은 더 큰 변경을 한 번에 맡기는 방식과 반대 방향으로 간다. 작은 검토 단위, 일관된 관례, 명시된 완료 조건, 계획과 검증을 분리한 흐름이 먼저 있어야 한다. 관례가 분명하면 사람과 에이전트 모두 선택지를 덜 헤매고, 무엇이 기존 방식에서 벗어났는지 빨리 찾는다. 완료의 뜻도 ‘코드가 생겼다’가 아니라 테스트와 문서, 실제 동작 확인, 장기 책임자까지 포함해야 한다. 보상 기준 역시 빨리 합친 변경 수보다 유지 가능한 설계, 명확한 평가 장치, 사용자 가치에 연결되어야 한다. AI는 계획·분해·검토·반대 관점의 검사 안에 배치하고, 사람이 무엇을 만들지와 무엇을 만들지 않을지를 끝까지 소유해야 한다. 그러면 생성 속도는 판단을 밀어내는 압력이 아니라, 더 작은 실험을 반복할 여유로 바뀐다. 검토 대기 시간도 함께 기록한다.
화면을 배우는 일에서 목표를 맡기는 일로
에이전트가 여러 앱을 오가며 결과를 만들기 시작하면 제품의 주 사용자는 사람만이 아니다. 연결보다 계획·권한·회복 가능성이 경쟁력이 된다.
사람이 대시보드와 검색 문법을 직접 배우지 않아도 된다면, 소프트웨어와 업무 절차는 무엇을 새로 책임져야 하는가?
사람이 원하는 것은 대시보드 자체가 아니라 질문의 답과 끝난 업무다. 지금까지는 Slack에서 맥락을 읽고, 관측 도구에서 로그를 찾고, 오류 추적 서비스에서 이슈를 확인하고, 편집기에서 고친 뒤 코드 저장소에 변경을 올리는 식으로 사람이 여러 화면과 문법 사이를 번역했다. 자연어를 검색식으로 바꾸는 AI 버튼은 한 화면 안의 부담을 줄였지만 여러 앱을 가로지르는 일 전체를 끝내지는 못했다. MCP처럼 AI가 서비스 기능을 호출하게 잇는 공개 방식은 문을 열었지만, 문이 많아질수록 어떤 도구를 어떤 순서로 써야 하는지, 과거 실패를 어떻게 기억할지, 앱 사이 맥락을 누가 이어 줄지라는 새 문제가 생긴다. 화면이 사라진다는 과장이 아니라, 화면 조작이 업무의 중심에서 밀려나고 목표·제약·승인 기준을 전달하는 일이 앞에 오는 변화다.
- 01
연결 수보다 선택 부담을 줄인다
도구를 많이 연결하면 능력이 자동으로 커지지 않는다. 정의가 한꺼번에 쏟아지면 에이전트는 잘못된 도구를 고르거나 선행 단계를 놓칠 수 있다. 제품은 모든 기능을 평평한 목록으로 노출하기보다 목표에 맞는 도구를 찾아 주고, 필요한 순서와 조건을 좁혀 주어야 한다. 사람이 메뉴를 외우던 부담을 에이전트의 도구 선택 혼란으로 옮겨 놓지 않는 설계가 필요하다.
- 02
업무 전체를 하나의 결과로 본다
원문의 사례에서 버그 제보는 한 앱의 검색으로 끝나지 않는다. 메시지의 맥락을 가져오고, 로그와 오류를 함께 조사하고, 코드베이스를 살핀 뒤 수정 제안까지 이어진다. 통합 인터페이스는 각 앱의 기능을 대신 만드는 것이 아니라 필요한 식별자와 자료를 단계적으로 넘겨 업무의 연속성을 지킨다. 평가 기준도 버튼을 잘 눌렀는지가 아니라 사용자가 요청한 결과를 여러 앱에 걸쳐 안전하게 완성했는지로 바뀐다.
- 03
새 사용자는 화면을 보지 않는다
눈이 없는 에이전트에게 화려한 화면은 설명서가 되지 않는다. 무엇을 할 수 있는지 발견할 방법, 입력과 출력의 일관성, 권한의 범위, 실패했을 때 멈추고 다시 시작할 지점이 더 중요하다. 사람에게는 승인과 예외 처리를 위한 화면이 계속 필요하지만, 제품 전략은 사람용 사용성과 함께 에이전트가 목표를 오해하지 않고 수행할 수 있는 인터페이스를 별도로 다뤄야 한다.
도입 순서는 연결 가능한 앱의 수를 늘리는 데서 시작하지 않는다. 자주 반복되는 한 업무를 고르고, 사람이 오가던 화면과 판단 지점을 적은 뒤, 에이전트가 가져올 정보와 실행할 행동, 반드시 사람에게 돌려줄 승인을 구분해야 한다. 다음으로 도구 검색과 실행 순서, 앱 사이에 넘길 최소 맥락, 실패 후 복구 지점을 제품 계약으로 만든다. 사용자가 화면을 덜 열게 되더라도 책임과 상태가 보이지 않으면 좋은 자동화가 아니다. 사람은 목표와 예외를 정하고, 소프트웨어는 여러 앱의 번역과 반복을 맡되, 중요한 선택을 다시 사람에게 이해 가능한 형태로 보여 줘야 한다. 실제 평가는 앱별 호출 횟수보다 하나의 요청이 어디에서 멈췄는지, 사람의 재작업이 줄었는지, 실패 뒤 같은 상태에서 안전하게 이어졌는지를 따라야 한다. 승인 대기 시간도 기록한다.
아직 못 읽은 북마크
북마크를 고르는 중…