오랫동안 나는 복잡한 AI 시스템을 구축해 왔다.
그것은 상당히 구체적인 제품으로 시작했다. 시간이 지나면서 실행, 도구, 메모리, 권한, 장기 실행 작업, 외부 기능, 그리고 여러 제품 형태를 포함하도록 성장했다. 그것이 커질수록, 나는 또 다른 기능을 어떻게 추가할지 묻는 데 쓰는 시간이 줄어들고, 다른 종류의 질문을 하는 데 더 많은 시간을 썼다: 어떤 기능이 어디에 속해야 하는가? 그것을 해석할 최종 권한은 누구에게 있는가? 어떤 결정은 모델에 맡겨야 하고, 어떤 보장은 소프트웨어에서 나와야 하는가? 오늘 우리가 출시하는 데 도움이 되는 메커니즘이 내일 우리가 벗어날 수 없는 경계가 될 것인가?
이 질문들은 아키텍처 질문처럼 보인다. 실제로 그것들은 소프트웨어 자체에 대한 내 사고방식을 바꿔 놓았다.
전통적인 소프트웨어는 지시를 중심으로 구축된다. 프로그래머가 경로를 미리 정의하고, 기계는 그것을 정확히 따른다: A가 발생하면 B를 하고, 입력이 C이면 D를 반환한다. 소프트웨어 가치의 상당 부분은 인간의 판단을 안정적이고 반복 가능한 단계로 바꾸는 데서 나왔다.
AI는 이 배열을 바꾼다. 처음으로, 기계는 의미 있는 범위의 상황에서 다음에 무엇을 할지 결정할 수 있다. 우리는 더 이상 모든 경로를 열거할 필요가 없다. 목표를 설명하고, 환경과 피드백을 제공하고, 모델이 계획을 세우고, 도구를 선택하고, 결과를 관찰하고, 조정하도록 할 수 있다.
그것은 모델이 더 유능해질수록 소프트웨어가 덜 중요해진다는 인상을 줄 수 있다.
나의 경험은 반대 결론으로 이끌었다. 소프트웨어는 사라지지 않는다. 그것이 책임지는 대상이 바뀌고 있다.
과거에 소프트웨어는 기계에게 다음에 무엇을 할지 말했다. 이제 모델이 다음 단계를 선택할 수 있지만, 소프트웨어는 여전히 다른 질문들에 답해야 한다: 무엇이 사실인가? 무엇이 허용되는가? 무엇이 완료로 간주되는가? 무언가 잘못되었을 때 누가 책임지는가? 지능적인 행동이 어떻게 사람들이 신뢰할 수 있는 결과가 되는가?
나는 이렇게 믿게 되었다:
모델은 가능성을 생성한다. 소프트웨어는 가능성을 질서로 바꾼다.
소프트웨어는 더 이상 단순히 AI를 둘러싼 명령 집합이 아니다. 그것은 AI가 거주하는 세계의 제도적 계층이 되어가고 있다.
아래의 원칙들은 내가 이 시스템의 여러 부분을 구축하고, 버리고, 다시 구축하고, 검증하면서 점차 생겨났다. 그것들은 특정 제품을 위한 아키텍처 가이드도 아니고, 보편적인 방법론도 아니다. 그것들은 단지 내가 다음에 무엇을 구축하든 가져갈 가치가 있다고 지금 생각하는 아이디어들이다.
1. 오늘의 인터페이스가 목적지를 정의하기 전에 무엇을 구축하는지 정의하라
장기 프로젝트에서 가장 위험한 표류는 기능 하나를 잘못 만드는 것이 아니다. 그것은 우리가 구축하려 했던 것을 점차 잊어버리는 것이다.
제품은 항상 구체적인 진입점을 통해 시작된다. 그것은 채팅 인터페이스일 수도, 데스크톱 유틸리티일 수도, 편집기일 수도, 브라우저일 수도, 작업대일 수도 있다. 이런 것들은 눈에 보이고 사용 가능하기 때문에, 쉽게 전체 프로젝트를 역으로 정의하기 시작한다: 프로젝트는 오늘 존재하는 화면이 되는 것이고, 그 미래는 현재 가장 성숙한 기능의 확장이 된다.
그러나 현재의 제품은 종종 목적지 자체가 아니라 목적지를 검증하기 위한 수단이다.
나는 의도적으로 세 가지를 분리하는 법을 배웠다: 내가 궁극적으로 구축하고 싶은 것, 그 목표를 지원하는 데 필요한 공통 기반, 그리고 사용자가 오늘 진정으로 사용할 수 있는 것.
세 가지는 연결되어야 하지만, 결코 서로를 사칭해서는 안 된다.
목적지에 대해서만 말하면, 프로젝트는 산출물 없는 비전이 된다. 현재에 대해서만 말하면, 프로젝트는 현재의 인터페이스와 임시 구현에 갇히게 된다. 공통 기반이 없으면, 모든 새로운 제품 형태는 실행, 상태, 권한, 메모리를 다시 발명해야 한다.
이 구분은 나의 많은 결정을 바꿨다. 나는 기능이 어디에 속하는지를 가장 빨리 구현할 수 있는 곳이 어디인지만 물어서 결정하는 것을 멈췄다. 나는 그것이 현재 제품에 고유한 경험인지, 아니면 미래 제품들도 필요로 할 시스템 역량인지를 묻기 시작했다. 임시 구현은 불완전할 수 있지만, 그것이 장기 목표를 재정의하도록 허용해서는 안 된다.
오래 지속되는 시스템에 가장 먼저 필요한 것은 로드맵이 아니다. 그것은 계층에 대한 감각이다: 방향은 무엇이고, 기반은 무엇이며, 오늘 시스템이 사용자에게 도달하는 방식에 불과한 것은 무엇인가.
2. “어떻게 구축할까?”보다 “누가 이것을 소유하는가?”를 먼저 물어라
소프트웨어의 복잡성 중 상당 부분은 코드가 너무 많아서 생기는 것이 아니다. 그것은 집이 없는 책임 때문에 생긴다.
개념에 명확한 소유자가 없으면, 그것은 자연스럽게 복제되기 시작한다. 인터페이스는 상태의 한 버전을 유지하고, 백엔드는 또 다른 버전을 유지하며, 구성 파일은 세 번째 버전을 유지한다. 어느 것도 명백히 틀리지 않지만, 서로 불일치할 때 어느 것도 최종 답을 줄 수 없다.
그러면 시스템은 동기화 로직을 키우기 시작한다. 한 곳의 변경이 다른 두 곳에 알려야 한다. 알림이 때때로 유실되므로 복구가 추가된다. 복구 순서가 불안정한 것으로 드러나므로 보상이 추가된다. 보상이 또 다른 상태를 만들므로 조정이 추가된다. 시스템이 설명하기 더 어려워지는 동안 코드는 점점 더 열심히 작동한다.
나는 예전에 모든 것을 어떻게 연결할지라는 질문에 즉시 끌렸다. 이제 나는 먼저 다른 질문을 한다:
- 이 개념은 진정 누구에게 속하는가?
- 누가 그것을 생성하고, 해석하고, 끝내는가?
- 그것이 비활성화되거나, 마이그레이션되거나, 삭제될 때, 시스템의 어느 부분이 그 변경의 전체 의미를 이해하는가?
- 다른 구성 요소들은 진실을 받는가, 아니면 단지 그것으로부터 투영된 뷰를 받는가?
그 질문들에 답이 나온 후에야 연결 전략이 중요해진다.
“소유권”은 코드 구성 용어처럼 들리지만, 나는 그것이 훨씬 더 넓은 원칙을 표현한다고 생각한다: 지속되는 모든 것은 전체 생명주기에 대해 책임지는 한 주체가 필요하다. 그렇지 않으면, 모두가 그것을 바꿀 수 있지만, 아무도 진정으로 그것을 이해하지 못한다.
이것은 또한 모든 사실에 대해 단일한 최종 해석자를 강하게 선호하게 만들었다. 다른 구성 요소들은 그 사실을 관찰하고, 캐시하고, 제시하고, 사용할 수 있지만, 동등하게 권위 있는 버전을 만들어내서는 안 된다.
복잡한 시스템은 많은 상태를 갖는 것을 두려워하지 않는다. 그것은 너무 많은 권위를 갖는 것을 두려워한다.
3. 사용자 경험이 아니라 메커니즘을 통합하라
시스템이 성장함에 따라, 모든 새로운 요구 사항에 대해 새로운 메커니즘을 만드는 것은 가장 자연스러우면서도 가장 위험한 선택이다.
역량이 약간 다르므로 새로운 등록 경로를 얻는다. 사용 사례가 다소 특이하므로 새로운 모드를 얻는다. 상태 조각에 아직 명확한 집이 없으므로 별도의 저장소를 얻는다. 새로운 실행 경로는 통합하기 불편하므로 기존 경로를 우회하고 또 다른 경로를 만든다.
각 결정은 개별적으로 합리적으로 보인다. 함께, 그것들은 발견, 권한, 로딩, 업데이트, 비활성화, 복구를 위한 병렬 시스템을 생산한다. 실제 비용은 몇 개의 추가 클래스가 아니다. 그것은 모든 미래 역량이 그 모든 병렬 메커니즘 전반에 걸쳐 같은 질문에 다시 답해야 한다는 것이다.
나는 점차 두 종류의 다양성을 구분하는 법을 배웠다: 사용자가 경험하는 다양성과 시스템이 내부적으로 유지해야 하는 다양성.
사용자는 매우 다른 제품, 진입점, 상호작용을 접할 수 있고 접해야 한다. 다른 맥락은 그들만의 언어와 멘탈 모델을 가질 자격이 있다. 그러나 그 경험들 아래에서, 역량은 소수의 안정적인 메커니즘을 통해 시스템에 들어오고, 권한을 받고, 생명주기를 얻을 수 있다.
메커니즘을 통합하라, 경험을 통합하지 말라.
이 원칙의 어려운 부분은 배선하기 더 쉽기 때문에 새로운 것을 만들고 싶은 유혹을 저항하는 것이다. 또 다른 메커니즘을 도입하기 전에, 나는 이제 현재의 메커니즘이 진정으로 그 필요를 표현할 수 없는지, 아니면 새로운 메커니즘이 단기적으로 더 편리할 뿐인지 묻는다.
“그것은 조금 달라 보인다”는 보통 시스템에 새로운 축을 만들 충분한 이유가 아니다.
안정적인 메커니즘은 아키텍처 다이어그램을 더 깔끔하게 보이게 하기 위해 존재하지 않는다. 그것들은 미래의 인지 비용을 줄인다: 모델, 개발자, 제품은 더 이상 같은 일을 하는 여러 거의 동등한 방식 사이에서 추측할 필요가 없다.
4. 소프트웨어는 모델의 사고 과정을 규정하는 것이 아니라 결과를 제약해야 한다
이것이 내 사고가 가장 크게 바뀐 지점이다.
모델 행동이 일관되지 않을 때, 자연스러운 충동은 이상적인 워크플로를 소프트웨어에 인코딩하는 것이다. 계획 전에 조사를 요구하고, 실행 전에 계획을 요구하고, 다음 단계가 시작되기 전에 한 단계가 완료되기를 요구한다. 모든 변경 후에 검증을 실행한다. 모델이 잘못된 경로를 택할 것 같을 때마다 또 다른 런타임 게이트를 추가한다.
이 시스템들은 대개 선한 의도로 설계됩니다. 그러나 종종 경직된 파이프라인으로 변해버립니다. 작업의 크기와 형태에 맞춰 접근 방식을 적응시킬 수 있는 모델이 단순한 요청에도 모든 단계를 완료하도록 강제됩니다. 여러 가드레일이 상호작용하며 모델이 빠져나갈 방법이 없는 교착 상태를 만들 수도 있습니다.
저는 무엇이 소프트웨어에 속하고 무엇이 모델에 남아야 하는지를 결정하기 위해 더 단순한 기준을 사용하기 시작했습니다: 그 규칙이 방법을 제약하는가, 아니면 결과를 제약하는가?
“편집 전에 읽기,” “구현 전에 제안 제시하기,” “마지막에 검증하는 것을 잊지 않기”는 방법입니다. 이것들은 모델이 유연하게 이해하고 적용할 수 있는 프롬프트, 스킬, 컨텍스트에 속합니다.
“승인 없이 데이터에 접근하지 말 것,” “확인 없이 되돌릴 수 없는 손실을 초래하지 말 것,” “사용자가 명시적으로 비활성화한 권한을 우회하지 말 것”은 결과에 대한 경계입니다. 이것들은 모델이 기억하는 것에 의존할 수 없습니다. 소프트웨어가 이를 강제해야 합니다.
반복, 유휴, 루프에 대한 기계적 가드레일도 아껴서 사용해야 합니다. 첫 시도는 허용되어야 합니다. 시스템이 어떤 행동을 차단할 때는 그 이유를 설명해야 합니다. 그리고 모델을 가드레일 뒤에 가두는 대신 복구할 수 있는 명확한 경로를 제공해야 합니다.
이것은 모델과 소프트웨어 사이의 분업을 제가 이해하는 방식을 바꾸었습니다:
목표와 방법은 모델에게 주십시오. 양보할 수 없는 경계는 소프트웨어에게 주십시오.
소프트웨어가 추론 과정의 모든 단계를 규정한다면, 우리는 AI를 안에 넣은 워크플로 엔진을 다시 만든 것에 불과합니다. 모든 경계가 프롬프트에만 존재한다면, 우리는 실제 책임을 확률에 넘겨준 것입니다.
좋은 시스템은 두 극단을 모두 피합니다.
5. 모델이 확신에 차 들리게 하는 대신 현실을 모호하지 않게 유지하라
모델의 추론은 열려 있을 수 있습니다. 그 언어는 달라질 수 있습니다. 그 계획은 수정될 수 있습니다. 그러나 일단 현실 세계에 작용하기 시작하면, 일부 사실은 모호할 수 없습니다.
과제가 실제로 시작되었는가? 변경이 실제로 일어났는가? 권한이 활성화되어 있는가? 어떤 세션이 결과를 소유하는가? 이 질문들에 대한 답은 어느 화면이 바라보느냐에 따라 달라져서는 안 됩니다.
저는 점점 소프트웨어를 AI 시스템의 현실 계층으로 생각하게 됩니다. 모델은 세계에 대한 해석을 제공할 수 있지만, 소프트웨어는 그 안에서 실제로 일어난 일을 기록합니다.
이는 인터페이스가 상태를 표현할 수는 있지만 상태 자체가 될 수는 없다는 것을 의미합니다. 요청에 첨부된 매개변수는 의도를 표현할 수 있지만 지속적인 권한을 일시적으로 무시할 수는 없습니다. 캐시는 성능을 향상시킬 수 있지만 그 출처와 같은 지위를 얻을 수는 없습니다. 시스템이 어떤 사실을 확립할 수 없을 때는, 매끄러움이라는 느낌을 유지하기 위해 가장 편리한 답을 추측하는 대신 정직하게 멈춰야 합니다.
전통적인 소프트웨어도 일관성이 필요하지만, AI는 이를 더욱 중요하게 만듭니다. 모델은 불완전한 정보로부터 이어 나가고 그럴듯하게 들리는 설명을 만들어내는 데 탁월합니다. 근본적인 사실이 이미 어긋나 있을 때, 정상에 있는 지능은 모순을 더 일관되게 느껴지게 하고 문제가 더 오래 숨겨지도록 할 수 있습니다.
따라서 제 원칙은 단순합니다: 모델이 불확실해지는 것은 허용하되, 시스템의 사실이 모호해지는 것은 허용하지 마십시오.
시스템이 모를 때는 모른다고 말해야 합니다. 권위 있는 데이터가 손상되었을 때는 행동을 거부해야 합니다. 두 출처가 충돌할 때는 조용히 더 쉬운 쪽을 선택하는 대신 충돌이 해결되도록 요구해야 합니다.
지능은 모호함과 함께 작동할 수 있습니다. 제도는 현실을 보존해야 합니다.
6. 가역성은 자율성의 전제 조건이다
우리는 종종 AI 자율성을 사용자에게 더 적은 질문을 하는 것으로 정의합니다. 그러나 사용자가 놓아줄 의향이 있는지를 결정하는 것은 확인 대화상자의 수가 아닙니다. 시스템이 그들이 보고, 멈추고, 고치고, 복구할 수 있게 해주는지 여부입니다.
모든 단계가 확인을 요구한다면, AI는 끊임없는 클릭을 요구하는 반자동 도구가 됩니다. 아무것도 확인을 요구하지 않고 기록도 되돌아갈 경로도 없다면, 자율성은 통제력 상실이 됩니다.
저는 다른 일련의 특성들에 더 주목하기 시작했습니다: 과정이 보이는가? 행동을 중단할 수 있는가? 변경을 검토할 수 있는가? 이력이 추적 가능한가? 실패 후 시스템이 의미가 명확한 상태로 복구될 수 있는가?
가역성은 무언가 잘못되었을 때를 위한 추가 보험 계층이 아닙니다. 그것은 애초에 권한을 부여하기 위한 전제 조건입니다.
행동을 되돌리기 쉬울 때, 시스템은 모델에게 더 많은 시도 여지를 줄 수 있습니다. 행동이 되돌릴 수 없을 때, 시스템은 권한을 강화하고 결정을 사용자에게 돌려주어야 합니다. 자율성의 정도는 모델에 대해 우리가 얼마나 낙관적인지에 의해 결정되어서는 안 됩니다. 그것은 결과로부터 복구할 수 있는지 여부에 의해 결정되어야 합니다.
이것은 “완료”에 대한 제 정의도 바꾸었습니다. 완료는 인터페이스의 녹색 상태가 아닙니다. 그것은 시스템이 결과, 남은 위험, 그리고 복구 경로를 명확하게 했다는 것을 의미합니다. 장기 실행 작업이 중단될 때 애니메이션이 그냥 사라져서는 안 됩니다. 변경이 거부될 때 실행 상태의 절반이 남아 있어서는 안 됩니다. 기능이 비활성화될 때 복구 로직이 다음번 애플리케이션 시작 시 그것을 조용히 되살려서는 안 됩니다.
AI가 더 독립적으로 행동하기를 원할수록, 우리는 그것이 멈추고 돌아오는 방식을 더 신중하게 설계해야 합니다.
7. 버그만 고치지 말라. 각 실패가 원칙을 남기게 하라
장기 프로젝트는 많은 실패를 겪습니다. 프로젝트를 구분하는 것은 실패가 발생하는지 여부가 아니라, 그 후에 어떤 형태로 남는지입니다.
가장 약한 대응은 즉각적인 증상을 사라지게 하는 것입니다. 더 나은 대응은 근본 원인을 식별하고 고치는 것입니다. 가장 가치 있는 대응은 한 걸음 더 나아갑니다: 이것은 어떤 부류의 실패였는가? 같은 실패가 어떤 다른 경로를 통해 돌아올 수 있는가? 시스템에 규칙, 단일 소유자, 또는 문제가 다시 자라나는 것을 막을 수 있는 구조가 빠져 있는가?
저는 증상과 수정 이상을 기록하는 습관을 들였습니다. 저는 또한 근본 원인, 소유자, 그리고 회귀를 방지할 증거를 기록합니다. 증상으로만 설명되고 책임 경계도 증거도 없는 문제는 아직 지식이 되지 못한 것입니다.
패치는 하나의 실패를 고칩니다. 원칙은 실패의 전체 부류를 줄입니다.
동기화 버그가 알림을 하나 더 추가함으로써 고쳐진다면, 그것은 다른 이벤트 순서 아래에서 나중에 돌아올 수 있습니다. 대신 실패가 모든 상태 조각에는 하나의 소유자가 있다는 원칙을 확립한다면, 미래의 설계는 자연히 더 적은 동기화 체인을 포함하게 됩니다. 오래된 진입점이 권한 모호성을 만든다면, 또 다른 특수 사례는 또 다른 분기만 추가할 것입니다. 하나의 의도에는 하나의 정규 진입점이 있다는 것을 확립하는 것은 시스템에 지속적인 결정 규칙을 부여합니다.
저는 AI가 소프트웨어 개발에 참여하는 지금 이것이 더욱 중요하다고 생각합니다. 코드는 더 빠르게 생산되고 있고, 국소적 수정은 더 저렴해지고 있습니다. 원칙이 없다면, 시스템은 전례 없는 속도로 그럴듯한 중복 구현을 축적할 수 있습니다.
AI는 우리가 패치를 더 빨리 작성하도록 도울 수 있습니다. 각 실패가 시스템에 무엇을 가르쳐야 하는지는 여전히 인간이 결정해야 합니다.
프로젝트에서 가치의 진정한 축적은 코드의 양이나 닫은 티켓의 수가 아닙니다. 과거 실패의 비용이 같은 비용을 다시 치르지 않도록 하는 원칙으로 전환되었는지 여부입니다.
8. 완료의 외관을 증거로 착각하지 말라
AI는 완결성의 느낌을 만들어내는 데 매우 능합니다. 그것은 잘 구조화된 설명, 구문상 유효한 코드, 그리고 안심이 되는 요약을 만들어냅니다. 그러나 엔지니어링의 가장 어려운 부분은 종종 그 표면 밖에 있습니다.
오류를 표시하지 않는 인터페이스는 백그라운드에서 아무것도 계속 실행되지 않는다는 것을 증명하지 않습니다. 개발 환경에서 작동하는 기능은 사용자에게 전달된 아티팩트에 그것이 존재한다는 것을 증명하지 않습니다. 한 플랫폼에서의 검증은 다른 플랫폼에서의 동일한 동작을 증명하지 않습니다. 타입 검사기를 통과하는 코드는 오래된 권위 있는 경로가 시스템의 나머지 부분에서 사라졌다는 것을 증명하지 않습니다.
시간이 지나면서 저는 “완료되었는가?”를 덜 묻고 “완료되었음을 증명하기에 충분한 증거는 무엇인가?”를 더 자주 묻게 되었습니다.
증거는 하나의 보편적인 녹색 표시가 아닙니다. 서로 다른 계층은 서로 다른 질문에 답합니다. 코드 검사는 국소적 구조를 확립합니다. 런타임 검증은 실제 실행 경로를 확립합니다. 아티팩트 검사는 사용자가 실제로 받게 될 것을 확립합니다. 복구 테스트는 시스템이 이상적이지 않은 조건에서 의미를 보존하는지 확립합니다.
AI 시대에 검증은 모델이 잘못된 코드를 작성하는 것을 막는 것만이 아닙니다. 그것은 또한 더 미묘한 위험에 맞섭니다: 결과가 논리적으로 너무 설득력 있어서 모든 사람이 그것이 이미 현실에 존재한다고 믿고 싶어질 수 있다는 것입니다.
제 가장 중요한 규칙 중 하나는 표면 상태로부터 근본 사실을 추론하지 않고, 국소적 통과로부터 전체 시스템의 정확성을 추론하지 않으며, 검증되지 않은 미래를 오늘 전달된 기능으로 제시하지 않는 것입니다.
현실을 존중하는 것은 때때로 “이것은 아직 끝나지 않았다”고 인정하는 것을 의미합니다. 그 정직함은 제품을 약화시키지 않습니다. 그것은 시스템에 계속 진화할 수 있는 신뢰할 수 있는 지점을 제공합니다.
소프트웨어는 지시에서 제도로 전환하고 있다
돌아보면, 이 작업에서 내가 얻고 간 것은 특정한 하나의 아키텍처가 아니었다. 그것은 AI 소프트웨어에 대한 다른 관점이었다.
과거에 소프트웨어는 경로를 일일이 열거하려 했다. 미래에는 그런 경로 중 더 많은 부분이 모델에 의해 그 순간 생성될 것이다. 소프트웨어는 더 이상 지능을 위해 모든 행동을 규정할 필요가 없지만, 안정적인 세계를 제공해야 한다: 명확한 정체성과 소유권, 우회할 수 없는 경계, 현실을 보존하는 상태, 빠져나가고 회복할 수 있는 방법, 그리고 어떤 결과가 실제인지 확립하는 증거를 제공해야 한다.
이는 제도와 개인 사이의 관계와 유사하다.
제도는 모든 사람을 대신해 생각하지 않으며, 모든 행동을 고정된 절차로 바꾸어서도 안 됩니다. 제도는 공유된 현실, 권리, 책임, 그리고 문제가 생겼을 때 벌어지는 일을 규정합니다. 좋은 제도는 질서를 희생하지 않으면서도 자유가 훼손되지 않도록 행동의 여지를 남겨 둡니다.
AI 시대에 소프트웨어는 이와 비슷한 역할을 하기 시작하고 있습니다.
그것은 모델의 두뇌가 아니며, 모델의 일자리를 두고 경쟁해서도 안 된다. 그것은 모델이 살아가는 세계의 법, 원장, 경계, 그리고 기억이다. 그것은 그 순간에 즉흥적으로 행해진 영리한 행동을 안정적인 역량으로 바꾼다. 그것은 우연한 성공을 반복 가능한 제품으로 바꾼다. 그것은 사용자가 편리함을 얻는 대가로 맹목적인 신뢰를 맞바꾸지 않고도 더 중요한 일을 AI에 맡길 수 있게 해준다.
나는 AI가 소프트웨어를 덜 중요하게 만들 것이라고 믿지 않는다. 오히려 모델이 더 유능해질수록, 소프트웨어는 모델이 스스로 결정해서는 안 되는 질문들에 더 많이 답해야 한다.
무엇이 참인가?
무엇이 허용되는가?
누가 소유하는가?
실패 후 어떻게 복귀하는가?
완료를 입증하는 증거는 무엇인가?
모델은 답을 탐색한다. 소프트웨어는 질문을 보호한다.
우리는 사람이 기계를 위해 모든 단계를 작성하던 시대에서, 사람이 원칙을 세우고 기계가 경로를 탐색하는 시대로 이동하고 있다. 소프트웨어의 역할도 그에 따라 바뀌고 있다: 행동을 기술하는 것에서 질서를 확립하는 것으로.
모델은 가능성을 생성한다.
소프트웨어는 그 가능성을 신뢰할 만하게 만든다.