AI가 만든 결과물을 그대로 쓸 수 없는 이유 — 규칙이 사람 머릿속에만 있기 때문입니다

저희는 최근 UI 시안과 개발 전달용 규격 시트를 만드는 일을 AI에게 넘겼습니다. 사람이 하던 절차를 그대로 지시문으로 옮겨 반복 실행하게 하는 방식입니다.

결과보다 막힌 지점이 더 쓸모 있었습니다. 병목은 AI의 성능이 아니었습니다. 우리가 지켜 온 규칙을 문서로 갖고 있지 않았다는 것, 그래서 지시할 말이 없었다는 것이 진짜 문제였습니다.

그럴듯한 결과물과 그대로 쓸 수 있는 결과물

화면 이미지 자체는 금방 나옵니다. 문제는 그다음입니다. 개발자가 받아서 그대로 옮기지 못합니다. 요소 간격이 조금씩 다르고, 글자 크기가 어디서 나온 값인지 알 수 없고, 색이 기존 화면과 미묘하게 어긋납니다.

보기에 그럴듯한 것과 받아서 바로 작업할 수 있는 것은 다릅니다. 그래서 작업의 목적부터 다시 적었습니다. "예쁜 화면을 만든다"가 아니라 "디자이너와 개발자가 그대로 받아 쓸 수 있는 산출물을 만든다"로요. 이 한 줄을 바꾸자 필요한 규칙이 드러났습니다.

규격의 출처를 하나로 못 박았습니다

같은 화면의 규격이 여러 폴더에 흩어져 있었습니다. 해상도가 다른 구버전과 신버전이 함께 있고, 디자이너 원본과 실기기 기준본이 서로 조금씩 달랐습니다.

사람은 이걸 감으로 처리합니다. "저건 옛날 거예요"라고 아는 사람이 팀에 있으니까요. 하지만 그 지식은 어디에도 적혀 있지 않았습니다. AI는 당연히 모릅니다.

그래서 세 가지를 문서에 못 박았습니다.

1. 어느 파일이 규격의 원본인가 — 찾는 순서를 정합니다
2. 충돌하면 무엇을 우선하는가 — 해상도가 먼저, 그다음이 날짜입니다
3. 원본이 없으면 무엇을 기준으로 삼고, 그 사실을 어디에 적는가

여기서 짚을 것이 있습니다. 이건 AI 때문에 생긴 문제가 아닙니다. 원래 있던 문제이고, 신입이 들어왔다면 똑같이 겪었을 일입니다. AI에게 일을 시키는 과정이 그동안 미뤄 둔 정리를 강제한 셈입니다.

추정을 금지하고, 재게 만들었습니다

자동화에서 가장 위험한 실패는 틀린 결과가 아닙니다. 그럴듯한 결과입니다. 명백히 틀리면 바로 걸러지지만, 그럴듯하면 그대로 개발까지 넘어갑니다.

글자 크기가 대표적입니다. 이미지만 보고 "32포인트 정도"라고 자신 있게 답하기 쉽습니다. 사람도 그렇게 합니다. 그리고 종종 틀립니다.

그래서 규칙을 이렇게 바꿨습니다. 추정하지 말고, 후보 크기를 실제로 렌더해서 대조표를 만들고, 실측한 글자 상자와 같은 열끼리 비교해 확정할 것. 색과 간격도 마찬가지로 픽셀에서 직접 측정하게 했습니다. 검증 항목의 첫 줄은 "적은 수치가 전부 실측값인가, 기억과 추정은 금지"입니다.

AI에게 판단의 자유를 주는 대신, 근거를 대는 방법을 지정해 준 것입니다.

나중에 덜 고칠 형식으로 적게 했습니다

가장 값진 교훈은 여기서 나왔습니다.

처음에는 모든 좌표를 화면 왼쪽 끝 기준으로 적게 했습니다. 정확했습니다. 그런데 컨테이너 폭이 한 번 바뀌자 오른쪽에 붙어 있던 요소의 수치가 전부 무효가 됐습니다. 표를 통째로 다시 계산해야 했습니다.

그래서 규칙을 바꿨습니다. 가운데를 경계로, 가까운 쪽 끝에서 잰다. 왼쪽 절반의 요소는 왼쪽 끝을 0으로, 오른쪽 절반의 요소는 오른쪽 끝을 0으로 적습니다. 이렇게 하면 컨테이너 폭이 바뀌어도 수치가 그대로 유효합니다.

정확한 산출물과 오래 가는 산출물은 다릅니다. 두 값 모두 처음에는 똑같이 맞았지만, 변경이 한 번 들어오자 한쪽만 살아남았습니다. 어떤 형식으로 적을지 정하는 것은 여전히 사람의 몫입니다.

함정 목록은 지우지 않고 쌓습니다

작업하다 보면 특정한 함정을 반복해서 밟습니다. 특정 조건에서 이미지가 사라진다든가, 값이 미묘하게 어긋난다든가 하는 것들입니다.

사람끼리는 "아 그거 원래 그래요"로 넘어갑니다. 그리고 다음 사람이 또 밟습니다. 저희는 이걸 증상과 원인을 짝지은 표로 만들어 문서에 두고, 새로 밟을 때마다 한 줄씩 추가하도록 했습니다.

부수 효과가 있었습니다. 이 표가 사람에게도 좋은 인수인계 자료가 됐습니다. 암묵지를 문서로 꺼내는 일이었으니 당연한 결과이기도 합니다.

무엇이 남았는가

시간이 몇 퍼센트 줄었다는 식의 수치는 말씀드리지 않겠습니다. 저희가 측정한 값이 아니고, 작업 종류마다 편차도 큽니다. 대신 확실히 달라진 것을 적겠습니다.

구분	이전	이후
산출물 형식	담당자마다 다름	누가 만들어도 같은 형식
검토 대화	"이 값 맞나요?"	"이 규격 이탈을 승인할까요?"
규칙의 소재	경력자의 머릿속	문서와 체크리스트

검토의 성격이 바뀐 것이 가장 큰 변화입니다. 값이 맞는지 확인하는 일에서, 예외를 승인할지 결정하는 일로 옮겨 갔습니다. 사람의 시간이 수행에서 판단으로 이동한 것입니다.

UI에만 해당하는 이야기가 아닙니다

견적서, 주간보고, 검수 체크리스트, 계약서 검토 모두 같은 구조입니다. 자동화가 막히는 지점은 대개 모델 성능이 아니라 "우리 회사가 이걸 어떻게 하는지가 어디에도 적혀 있지 않다" 는 사실입니다.

그래서 AI 도입의 첫 작업은 도구를 고르는 일이 아닙니다. 반복이 심한 업무를 하나 골라, 그 일을 잘하는 사람이 실제로 어떤 순서와 기준으로 하는지 받아 적는 일입니다. 그 문서가 없으면 어떤 도구를 붙여도 결과물은 매번 달라집니다.

저희가 이 이야기를 하는 이유

에버스톤은 2013년 부산에서 시작해 13년째 교육 솔루션과 업무 시스템, 모바일 앱, VR/AR 콘텐츠, 자체 게임 IP를 만들어 왔습니다. 공공·교육기관 사업도 20건 넘게 수행했습니다.

위에 적은 내용은 자문한 결과가 아니라 저희 제작 공정에 먼저 적용해 본 기록입니다. 만든 것을 직접 운영하는 회사라 이런 문제를 자사 제품에서 먼저 겪었고, 고치는 과정도 저희 몫이었습니다.

진단만 받으면 대개 거기서 멈춥니다. 재설계안을 그린 뒤에는 만들어 줄 곳을 다시 찾아야 하고, 그 사이에서 원래 의도가 절반쯤 사라집니다. 저희는 규칙을 정리하는 일과 그것을 실제로 도는 도구로 만드는 일을 같은 자리에서 합니다. 그래서 만들 수 없는 것을 처음부터 제안하지 않습니다.