Supabase 코플스톤 - 사내 AI 규칙 대신 시험으로 관리하기

에이전트가 고객이 된 데이터베이스 회사

Supabase는 앱 뒤에서 데이터를 저장하고 꺼내 주는 데이터베이스 서비스를 오픈소스로 만드는 회사입니다. 공동창업자이자 대표인 폴 코플스톤이 스타트업 투자사 Y Combinator(YC)의 대담 프로그램 Lightcone에 나와 지난 1년을 돌아봤습니다. 그가 밝힌 숫자로는 가입자가 1년 전 약 300만 명에서 1,300만 명이 됐고, 관리하는 데이터베이스는 800만 개에서 5,000만 개 가까이로 늘었습니다.

고객의 얼굴이 바뀌었다는 점에서 이 대담은 들어 볼 만합니다. 진행자는 새로 생기는 활동의 70%가량이 AI 에이전트(사람 대신 코드를 쓰고 실행하는 AI)에서 나온다고 했고, 코플스톤도 올해 숫자를 끌어올린 것은 에이전트 쪽으로 크게 옮겨 간 흐름이라고 답했습니다. 엔지니어가 아닌 현업 전문가가 직접 만들기 시작했다는 점도 짚었습니다. 예전에는 엔지니어를 설득해야 아이디어를 실현할 수 있던 사람들입니다.

AI를 누구보다 먼저 받아들인 회사가 안에서 무엇을 바꿨는지, 노바폴드가 국내 조직의 눈으로 읽어 봤습니다. 따옴표 안 인용은 영상 자막을 노바폴드가 우리말로 옮긴 것이고, 시각을 누르면 해당 장면으로 이동합니다.

코플스톤이 꼽은 세 가지 판단

첫째, 에이전트가 쓰기 좋은 제품이 먼저입니다. 코플스톤은 회사가 화면 중심의 대시보드 회사, 다른 프로그램이 연결해 쓰는 회사를 거쳐 지금은 코드가 먼저인 회사가 됐다고 정리했습니다. 올해 대시보드를 찾는 사람이 거의 없다는 것을 보고, 화면에서 되는 일은 코드로도 똑같이 되어야 한다는 메모를 팀에 돌렸다고 합니다.

오류 메시지도 바꿨습니다. 문제가 생겼다는 사실만 알리던 메시지에 이제는 고치는 방법이나 읽어야 할 문서를 적어 둡니다.

둘째, 사용 규칙을 두는 대신 시험을 늘렸습니다. 진행자가 꺼낸 사내 설문에 따르면, 코드의 80%를 코딩 에이전트로 쓰는 엔지니어 비율이 6개월 만에 10%에서 60%로 올랐습니다.18:02 어떻게 된 일이냐는 물음에 코플스톤은 이렇게 답했습니다.

대신 AI가 쓴 코드로 옮겨 가면서 시험의 양과 시험 도구가 크게 늘었고 그래서 결과물이 괜찮은지 확인할 수 있었다고 했습니다. 지금은 엔지니어링 노력의 상당 부분이 기능을 만드는 일보다 사람들이 실제로 만드는 경우를 시험하는 데 들어간다고도 덧붙였습니다.32:03

셋째, 대표가 직접 써 보고 막혀 봅니다. 코플스톤은 다음 변화에 대비하는 방법으로 자기 제품을 직접 쓰는 일을 가장 먼저 꼽았습니다. 그는 통화하듯 에이전트에게 말로 수정을 시키고 일부러 코드를 보지 않습니다. 개발을 모르는 사람처럼 써 봐야 1년 뒤 그런 사용자가 막히지 않을지 알 수 있다는 이유입니다.41:13

「정책 없음」이 성립한 조건부터 봐야 합니다

이 대담을 읽고 「우리도 AI 정책을 없애자」로 가면 곤란합니다. 노바폴드가 보기에 코플스톤의 답 아래에는 대담에서 말하지 않은 전제가 두 가지 깔려 있습니다. Supabase의 선택은 그 회사의 사람과 도구, 일하는 방식이 함께 만든 결과라서 한 조각만 떼어 오면 같은 효과를 기대하기 어렵습니다.

하나는 시험을 쓸 줄 아는 사람들이 이미 있었다는 점입니다. Supabase는 개발자 도구를 만드는 회사이고 설문에 나온 주인공도 엔지니어입니다. 결과를 확인하는 습관과 도구가 원래 일의 일부였기 때문에, 규칙을 비워 둬도 확인까지 비지는 않았다고 해석할 수 있습니다.

다른 하나는 데이터입니다. 정책이 없다는 답은 사내에서 어떤 도구를 쓰느냐에 관한 이야기였고, 고객 정보처럼 AI에 넣으면 안 되는 것이 무엇인지는 대담에서 다뤄지지 않았습니다. 고객 정보와 거래처 계약을 매일 다루는 조직이라면 이 부분은 따로 정해야 합니다.

보완할 점도 있습니다. 시험이라는 말은 개발자에게는 익숙하지만 영업, 구매, 인사 같은 현업에서는 무엇을 시험하느냐부터 막힙니다. 비개발 업무에서 시험에 해당하는 것은 정답이 알려진 과거 사례 묶음, 그리고 결과를 누가 어떤 기준으로 볼지에 대한 약속입니다. 이 두 가지가 없으면 현업 전문가가 만든 도구는 만든 사람의 감에만 기대게 됩니다.

지표도 다시 볼 필요가 있습니다. 대담에 나온 숫자는 코드 대부분을 에이전트로 쓰는 엔지니어의 비율, 곧 도입률이었습니다. 국내 조직이 이 숫자만 따라 재면 함정에 빠집니다. 도입률은 얼마나 썼는지를 보여 줄 뿐 결과가 믿을 만했는지는 말해 주지 않습니다. 확인을 통과한 비율이나 확인 과정에서 걸러 낸 오류 건수를 함께 봐야 허용 범위를 넓힐 근거가 생깁니다.

국내 조직에 옮길 때 가장 먼저 걸리는 곳은 승인 구조입니다. 많은 회사가 도구 단위로 사용을 허가하고, 새 도구는 보안 검토를 거쳐 목록에 올라야 쓸 수 있습니다. 이 방식에는 직원이 직접 만든 작은 프로그램이 들어갈 칸이 없습니다. 만든 것을 어디에 두는지, 고장 나면 누가 고치는지, 만든 사람이 부서를 옮기면 누가 이어받는지가 정해져 있지 않으면 쓸 만한 도구도 개인 노트북 안에서 끝납니다.

책임의 무게도 걸림돌입니다. 국내 조직에서는 AI가 낸 결과가 틀렸을 때 그 책임이 도구를 만든 개인에게 고스란히 돌아가는 일이 많습니다. 그러면 현업 담당자는 만들 줄 알아도 만들지 않습니다. 정해진 확인을 거친 결과라면 책임을 조직이 함께 진다는 약속이 있어야, 대담이 말한 「설득할 필요가 없어진」 사람들이 실제로 움직입니다.

가상의 예를 하나 들겠습니다. 한 제조사의 구매 담당자가 AI로 견적 비교 도구를 만들었다고 해 봅시다. 금지 목록부터 정하는 회사라면 이 도구는 승인을 기다리다 잊히거나, 아니면 몰래 쓰입니다.

확인 수단부터 정하는 회사라면 질문이 달라집니다. 지난 분기에 사람이 실제로 비교한 견적 30건을 넣어 같은 결론이 나오는지 보고, 결론이 다른 건은 이유를 적어 두며, 거래처 단가처럼 민감한 값은 정해 둔 환경에서만 다루게 합니다. 이 과정을 거친 도구는 팀 전체가 써도 되는 범위로 올라갑니다.

이 예시에서 눈여겨볼 것은 30건이라는 숫자보다, 확인 기준을 도구를 만든 사람 혼자가 아니라 팀이 함께 정했다는 점입니다. 기준이 개인의 머릿속에만 있으면 새 도구가 나올 때마다 처음부터 다시 따져야 합니다. 팀이 한 번 정해 둔 기준은 다음 도구가 그대로 가져다 쓸 수 있습니다.

에이전트 쪽에서도 같은 질문이 돌아옵니다. 직원이 에이전트에게 업무를 맡기면 사내 문서와 시스템의 첫 독자는 사람이 아니라 에이전트가 됩니다. 사내 안내문이 사람만 알아듣게 쓰여 있으면 에이전트는 거기서 멈추고, 직원은 다시 손으로 일하게 됩니다. Supabase가 오류 메시지에 고칠 방법을 적은 것과 같은 손질이 사내 시스템에도 필요해지는 셈입니다.

경비 정산 규정이 「담당 부서에 문의」로 끝나 있다고 해 봅시다(가상 예시). 에이전트는 어느 부서에 무엇을 물어야 할지 모릅니다. 문의처와 필요한 서류, 자주 반려되는 사유를 한 문서에 적어 두기만 해도 에이전트가 끝까지 처리하는 업무가 늘어납니다.

대표가 직접 써 보고 막혀 본다는 대목은 국내 조직의 리더에게 옮겨 볼 만합니다. 이것은 원문이 아니라 노바폴드의 제안입니다. 임원이 AI 도입 현황을 보고받는 데서 그치지 않고 현업 담당자가 쓰는 도구로 자기 업무 하나를 직접 처리해 보는 방식입니다. 어디서 막히는지 직접 겪어 본 리더는 금지 목록보다 확인 수단에 예산을 쓰는 쪽을 택하기 쉽습니다.

교육의 목표도 달라져야 합니다. 국내 기업의 AI 교육은 대개 도구 사용법에서 멈춥니다. 코플스톤이 기대를 건 사람은 자기 분야에서 아직 풀리지 않은 문제를 정확히 아는 현업 전문가였습니다. 도구를 쓸 줄 아는 사람을 넘어, 자기 업무에 필요한 작은 프로그램을 만들고 확인을 받아 동료와 나누는 사람을 길러 내는 것이 다음 단계입니다.

남는 질문은 누가 만들고 누가 확인하느냐입니다

대담 끝 무렵 진행자는 지금을 이렇게 표현했습니다. 모델의 능력은 가파르게 오르는데, 무엇을 만들지 알고 어떻게 시킬지 아는 사람의 수는 거의 그대로라는 것입니다.42:11

만드는 능력이 누구에게나 열리면 조직 사이의 차이는 두 곳에서 벌어집니다. 업무를 아는 사람이 무엇을 만들지 정하는 일, 그리고 회사가 그 결과를 믿을 수 있게 확인하는 일입니다. 규칙을 늘리는 일은 문서 몇 장으로 끝나지만, 확인 수단을 갖추는 일은 업무마다 기준을 세워야 해서 시간이 걸립니다. 먼저 시작한 조직과 나중에 시작한 조직의 거리가 쉽게 좁혀지지 않는 이유입니다.

그렇다면 AI 사용 지침을 몇 쪽으로 쓸지 고민하기 전에 먼저 물어야 할 것이 있습니다. 우리 조직에서 아직 아무도 설득하지 못한 아이디어를 가진 현업 담당자는 누구이고, 그가 내일 무언가를 만들어 온다면 우리는 그것을 무엇으로 확인하겠습니까?