핵심요약
이 글의 핵심은 이제 변호사, 의사, 현장 기술자 같은 도메인 전문가도 AI로 소프트웨어를 만들 수 있게 되었다는 점이다.
하지만 빠르게 만든 데모가 오래 신뢰할 수 있는 제품이 되는 것은 전혀 다른 문제이며, 그 차이를 메우는 것이 거버넌스다.
글은 이 문제의 해법으로, 기능과 지식을 계약처럼 선언하고 추적 가능하게 만드는 계약형 AI를 제시한다.
도메인 전문가는 이제 직접 소프트웨어를 만든다
예전에는 좋은 아이디어가 있어도 개발자를 거쳐야 제품이 나왔다.
이제는 상황이 달라졌다. 캘리포니아의 변호사 Mike Brown은 ADU 인허가 문제를 돕는 CrossBeam을 6일 만에 만들었고, 심장 전문의는 진료 후 안내 시스템을, 우간다의 도로 기술자는 도로 상태를 경제성 평가로 연결하는 시스템을 만들었다.
중요한 점은 이들이 코딩 실력으로 이긴 것이 아니라, 현장을 깊이 이해하고 있었다는 사실이다. AI는 삽이었고, 실제 설계도는 도메인 지식이었다.
해커톤이 증명한 것은 절반뿐이다
많은 사람은 "이제 코딩보다 도메인 지식이 중요하다"는 교훈만 봤다.
하지만 글은 더 불편한 교훈을 꺼낸다. 해커톤은 "만들 수 있다"는 것만 증명할 뿐, "믿고 쓸 수 있다"는 것은 증명하지 못한다는 점이다.
6일짜리 데모는 발표 날에는 잘 보일 수 있다. 그러나 6개월 뒤에도 규정 변경을 반영하는지, 예외 상황을 다루는지, 왜 그런 판단을 했는지 설명할 수 있는지는 전혀 다른 시험이다.
데모의 정답과 운영의 정답은 다르다
도메인 전문가가 만든 시스템은 처음엔 꽤 정확할 수 있다.
예를 들어 CrossBeam이 다루는 ADU 인허가는 서류 누락, 잘못된 조항 인용, 서명 부족처럼 행정적 오류가 많다. 이런 문제는 현업 변호사가 특히 잘 안다.
하지만 운영 단계에서는 질문이 더 무거워진다. 법이 바뀌면 어떻게 갱신할까. 잘못된 안내로 시공이 지연되거나 검사에서 탈락하면 책임은 누구에게 있을까. 기관이 "왜 승인 가능하다고 판단했는가"를 물으면 설명할 수 있을까.
즉, 데모의 핵심은 정답 생성이고, 운영의 핵심은 책임 가능한 정답 유지다.
도메인 전문성은 필요조건이지 충분조건이 아니다
유용한 AI를 만들 때 진짜 어려운 일은 코드를 쓰는 일이 아니라, 시스템이 무엇을 알아야 하고 어디까지 해야 하는지 정하는 일이다.
도메인 지식이 없는 개발자는 그럴듯하지만 틀린 결과를 만들기 쉽다. 반대로 도메인 전문가는 더 정확한 초안을 만들 수 있다.
그렇다고 해서 제품이 완성되는 것은 아니다. 기관이 필요한 것은 "전문가가 있을 때만 돌아가는 시스템"이 아니라, 전문가가 떠난 뒤에도 설명 가능하고 감사 가능하며 유지되는 시스템이다.
기관이 AI를 도입할 때 부딪히는 벽
병원, 로펌, 공공기관이 AI를 도입하면 비슷한 문제가 반복된다.
처음에는 프로토타입이 인상적이다. 하지만 시간이 지나면 규정이 바뀌고, 예외 사례가 쌓이고, 만든 사람이 떠난다. 그 순간 시스템은 똑똑한 도구가 아니라 설명할 수 없는 상자가 된다.
기관은 성능만 원하는 것이 아니다. 누가 어떤 기준으로 바꿨는지, 어떤 범위에서만 써야 하는지, 실수가 생기면 어디서 추적해야 하는지를 원한다.
계약형 AI란 무엇인가
글이 제안하는 해법은 계약형 AI다.
핵심 생각은 단순하다. 시스템의 능력을 "암묵적 프롬프트"나 "작성자만 아는 코드"에 숨기지 말고, 계약처럼 명시하자는 것이다. 무엇을 알고, 무엇을 할 수 있고, 무엇을 하면 안 되는지를 선언하고, 버전과 변경 이력을 관리하며, 감사 가능하게 만드는 방식이다.
이 관점에서는 계약이 단순한 문서가 아니다. 제품의 경계이고, 설명 책임의 뼈대이며, 전문가가 떠난 뒤에도 남는 운영 지식이다.
세 가지 계약: 지식, 범위, 학습
첫째는 지식 계약이다.
시스템이 무엇을 사실로 알고 있는지, 그 근거가 어디인지 연결한다. CrossBeam의 참고 문서 28개가 흩어진 파일이 아니라, 출처가 추적되는 구조화된 지식이 되는 셈이다. 법이 바뀌면 이 지식층을 갱신하고, 그 아래 추천도 함께 바뀌게 할 수 있다.
둘째는 범위 계약이다.
"이 AI는 인허가를 처리한다"처럼 넓게 말하지 않고, 어느 지역, 어느 규정, 어떤 신청 유형까지 다루는지 선을 분명히 긋는다. 쉽게 말해 지도에 활동 가능 구역을 그려 놓는 것이다. 이 경계가 분명해야 오용이 줄어든다.
셋째는 학습 계약이다.
운영 중 발생한 실패와 수정이 그냥 로그로 묻히지 않고, 검토 가능한 학습 기록으로 남는다. 잘못 분류한 도로 손상 사례나 부정확했던 의료 안내가 통제된 개선 데이터가 되어 다음 판단을 더 낫게 만든다.
진짜 경쟁력은 지식의 축적 방식이다
글은 "도메인 전문성이 경쟁력"이라는 말이 반만 맞다고 본다.
진짜 경쟁력은 개인의 머릿속 지식이 아니라, 그 지식이 조직 안에서 축적되고 전파되고 검증되는 방식이다. 다시 말해, 순간적으로 똑똑한 시스템보다 시간이 갈수록 더 믿을 수 있게 되는 시스템이 강하다.
변호사는 6일 만에 앱을 만들 수 있다. 하지만 로펌이 필요한 것은 6년 동안 규정 변화와 책임 문제를 견디는 시스템이다. 이 간극을 만드는 것이 거버넌스다.
인사이트
앞으로 AI 시대의 승자는 "누가 더 빨리 만든다"보다 "누가 더 오래 설명 가능하게 운영한다"에서 갈릴 가능성이 크다.
도메인 전문가가 직접 만드는 흐름은 계속 커질 것이다. 다만 개인의 통찰을 조직의 자산으로 바꾸려면, 지식의 출처, 사용 범위, 학습 이력을 남기는 구조를 처음부터 설계해야 한다.
실무에서는 AI를 만들 때 먼저 성능보다 경계를 적어보는 습관이 유용하다. 이 시스템은 무엇을 아는가, 어디까지 책임지는가, 틀렸을 때 어떻게 고치는가. 이 세 질문에 답할 수 있어야 데모가 제품으로 자란다.
출처 및 참고 : The Lawyer Who Won
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.