Rebuilding ERP UX: Brennan이 Claude Code·Codex로 NetSuite 앱을 하루 최대 5건 만드는 법

Brennan Industries는 AI 에이전트를 앱을 만드는 데만 쓰고 완성된 앱은 SuiteScript 코드로 NetSuite 안에서 돌립니다. 그래서 반복 업무가 돌 때마다 토큰이 나가지 않고 건당 1주 넘던 맞춤 화면을 하루 최대 5건 만듭니다. 따라 하려면 NetSuite를 깊이 아는 빌더 한 명과, 목업 승인부터 배포까지 하루 안에 도는 짧은 루프가 필요합니다.

요약

diginomica의 Phil Wainewright는 2026년 11월 2일, NetSuite 연례 행사 SuiteWorld에서 유압 부품 제조사 Brennan Industries의 CIO Ryan King을 만나 이야기를 전했습니다. King은 Anthropic의 Claude Code와 OpenAI의 Codex(코딩 에이전트), 최근에는 NetSuite Next까지 써서 현업 동료가 요청한 앱을 직접 만듭니다. 방식은 정해져 있습니다. 동료와 마주 앉아 요건을 듣고 에이전트와 1시간이 안 되는 약 45분 동안 목업을 만듭니다. 동료가 보고 고칠 곳을 말하면 반영하고 승인이 나면 에이전트가 앱을 SuiteScript(NetSuite 안에서 도는 JavaScript 기반 맞춤 개발 언어)로 생성해 바로 NetSuite에 올립니다.

결과는 속도입니다. 예전에는 한 건에 1주 이상 걸리고 여러 사람이 회의를 거듭해야 했습니다. 지금은 하루에 최대 5건을 끝냅니다. 예전에는 King이 비용이 크다, 개발자가 필요하다며 요청을 돌려보냈고 많은 요청이 그렇게 사라졌습니다. 지금은 요청받은 것을 그대로 만들어 줍니다. 비용 쪽 논리도 분명합니다. 앱을 AI 플랫폼 위에서 채팅으로 계속 돌리면 토큰이 타지만 NetSuite 프로그램으로 만들어 두면 반복 업무가 자동으로 돌아갑니다. ERP에 AI를 쓰기엔 너무 비싸다는 말에 King은 “You’re not using AI right.”라고 답합니다. 아래에서는 이 방식을 네 가지 장치로 나눠 보고 실제로 돌릴 때 필요한 기술·현업 디테일을 덧붙입니다.

핵심 메커니즘

Build-time Agent: 에이전트는 만들 때만, 실행은 NetSuite가

에이전트를 앱의 실행 엔진이 아니라 개발 도구로만 쓰는 구조입니다. 입력은 현업 요건과 승인된 목업이고 에이전트가 이를 SuiteScript 코드로 바꿉니다. 출력은 NetSuite 안에서 스스로 도는 프로그램입니다. 토큰은 만드는 동안에만 쓰고 앱이 매일 실행될 때는 쓰지 않습니다. King은 NetSuite 환경이 자신이 통제하고 유지할 수 있는 곳이라 이 방식을 택했다고 설명합니다. 같은 작업이 반복되는 업무에 맞고 매번 판단이 달라지는 비정형 질의에는 맞지 않습니다. 가상 예시를 들면, 매일 아침 납기 지연 주문을 뽑아 담당자에게 알리는 일은 채팅으로 매번 물을 필요 없이 예약 스크립트 하나로 끝납니다.

Mockup Loop: 45분 목업으로 요건을 확정하는 짧은 순환

요건 문서를 길게 쓰는 대신 화면부터 보여 주고 고치는 방식입니다. King이 동료와 요건을 정리하면 에이전트와 약 45분 만에 목업이 나옵니다. 동료는 목업을 보고 바꿀 곳을 말하고 King이 고친 뒤 승인을 받습니다. 승인 뒤에는 에이전트가 SuiteScript로 앱을 만들어 NetSuite에 올립니다. 예전에는 같은 일에 여러 사람과 여러 차례 회의가 필요했습니다. 화면 단위로 끝나는 작은 업무 앱에 맞고 여러 부서의 결재 흐름이 얽힌 큰 프로세스 변경에는 이 루프만으로 부족합니다.

Task-shaped UI: 필요한 필드만 보여 주고 ERP는 뒤로 숨기는 화면

King이 그리는 ERP 화면은 사용자가 그 일에 필요한 것만 보는 화면입니다. 회사가 자기 업무를 들여다본 뒤 Claude, ChatGPT, NetSuite 내장 AI에 특정 필드가 있는 양식을 만들어 달라고 합니다. 사용자는 그 양식 말고는 아무것도 보지 않고 ERP 처리는 뒤에서 일어납니다. 사용자가 데이터를 넣으면 AI가 그 데이터에 관해 질문을 던집니다. King은 Brennan이 전체 환경을 처음부터 다시 짓고 있다고 말합니다. 화면을 오가며 입력하기 번거로워 기록이 빠지던 업무에 특히 효과가 큽니다.

Expert-guided Agent: NetSuite를 아는 사람이 단계별로 이끈다

King은 이 방식이 마법이 아니라고 못 박습니다. 에이전트는 도구이고 프로세스와 데이터를 단계별로 알려 줄 사람이 필요합니다. 빌더는 NetSuite를 깊이 알아야 하고 에이전트가 던지는 질문에 빠르게 답해야 합니다. 입력은 빌더의 업무·데이터 지식이고 에이전트는 그 지시를 코드로 옮기며 출력은 실제 레코드와 필드에 맞게 붙은 앱입니다. ERP 구조를 아는 사람이 없는 조직이라면 에이전트를 들이기 전에 그 역할부터 세워야 합니다.

통념과 다른 주장

저자가 든 사례

사례 1. 영업 통화 기록 화면

상황	한 일	결과	연결
고객이 전화로 부품을 묻고 영업은 가격과 납기를 안내. 화면 전환이 번거로워 누구와 무슨 얘기를 했는지 남기지 않았고 남는 기록은 주문뿐	King이 Claude로 화면 하나를 만듦. 평소처럼 가격·납기를 조회하는 동안 NetSuite CRM에 통화 내용이 뒤에서 채워짐	오후 한나절에 완성. 수백 건의 통화 이력이 처음으로 쌓이고 후속 조치가 가능해짐. 기간 기준은 원문에서 밝히지 않음	Task-shaped UI, Build-time Agent

사례 2. 돌려보내던 요청을 받아 주게 된 IT

상황	한 일	결과	연결
현업 요청마다 비용이 크다, 개발자나 NetSuite 지원이 필요하다는 이유로 많은 건이 폐기됨	요건 수집, 약 45분 목업, 리뷰·승인, SuiteScript 생성의 루프로 바꿈	건당 1주 이상 걸리던 일을 하루 최대 5건 처리. 요청받은 것을 그대로 만들어 줌	Mockup Loop, Expert-guided Agent

기술 디테일: 같은 루프를 직접 만든다면

아래 필드명, 설정값, 숫자는 원문에 없는 가상 예시입니다. 기사가 밝힌 방식을 실제로 돌릴 때 필요한 것을 정리했습니다.

Build-time Agent를 돌리려면 에이전트가 읽을 작업 폴더부터 만듭니다. 폴더에는 SuiteCloud Development Framework(SDF, NetSuite 맞춤 개발을 파일로 관리하는 도구) 프로젝트, 쓰는 레코드와 필드 ID 목록, 코딩 규칙 파일을 둡니다. 규칙 파일에는 SuiteScript 2.1만 쓸 것, 레코드를 고칠 때는 지정된 필드만 건드릴 것, 스크립트 하나가 쓰는 governance 단위(NetSuite가 스크립트마다 거는 실행 한도)를 넘지 않게 나눠 처리할 것을 적습니다. 에이전트는 Claude Code든 Codex든 같은 폴더와 규칙 파일을 읽게 해, 도구를 바꿔도 결과물 형식이 같게 합니다. 배포는 반드시 샌드박스 계정에 먼저 하고 운영 반영은 사람이 승인한 뒤 SDF로 올립니다.

Mockup Loop의 요건을 구조화하려면 동료와 나눈 대화를 바로 코드로 넘기지 말고 앱 명세 JSON 한 장으로 먼저 정리합니다. 목업은 이 명세로 만들고 승인도 이 명세 버전에 겁니다. 승인 뒤 코드 생성은 같은 명세로 하므로, 목업과 실제 앱이 어긋나지 않습니다.

{
  "app_id": "sales-call-log",
  "spec_version": 3,
  "requester": "영업팀장",
  "approved_by": "영업팀장",
  "approved_at": "2026-11-05T15:20:00+09:00",
  "screen": "Suitelet",
  "fields": [
    {"label": "고객", "record": "customer", "mode": "lookup"},
    {"label": "문의 품목", "record": "item", "mode": "lookup"},
    {"label": "안내 가격", "source": "price_level", "mode": "readonly"},
    {"label": "안내 납기", "source": "availability", "mode": "readonly"},
    {"label": "통화 메모", "mode": "text"}
  ],
  "writes": [{"record": "phonecall", "link": "customer"}],
  "runs_without_llm": true
}

Task-shaped UI를 만들려면 화면은 Suitelet(NetSuite 안에 띄우는 맞춤 페이지)이나 기존 양식에 붙는 Client Script로 만들고 사용자가 이미 하던 동작에 기록을 얹습니다. 영업 통화 화면이라면 고객과 품목을 고르는 순간 가격·납기 조회와 통화 레코드 초안 생성이 함께 일어나고 저장 버튼 하나로 CRM에 남습니다. 입력 중 AI가 질문을 던지는 기능을 붙일 때만 LLM을 호출하고 그 호출은 사용자가 요청할 때로 한정해 토큰이 매 조회마다 나가지 않게 합니다. 호출은 temperature 0, 출력은 {"question", "field", "reason"} 세 필드로 고정하고 사용자당 하루 호출 상한(예: 20회)을 둡니다. 응답이 형식에 맞지 않으면 질문 없이 저장만 진행합니다.

Expert-guided Agent의 품질을 지키려면 빌더가 에이전트에게 주는 지시를 단계로 쪼갭니다. 레코드 구조 확인, 화면 목업, 저장 로직, 오류 처리 순서로 한 번에 한 단계씩 요청하고 단계마다 샌드박스에서 실제 레코드 3~5건으로 저장 결과를 확인합니다. 생성된 코드는 Git에 명세 버전과 함께 커밋해, 어느 승인본에서 나온 코드인지 추적할 수 있게 합니다.

실패하는 경우	대응 (가상 예시)
승인한 목업과 배포된 앱의 필드가 다름	목업과 코드를 같은 명세 버전으로 생성, 배포 전 필드 목록 자동 비교
스크립트가 대량 레코드에서 실행 한도에 걸림	예약 스크립트나 Map/Reduce로 나눠 처리, 샌드박스에서 실제 규모로 시험
에이전트가 존재하지 않는 필드 ID를 씀	필드 ID 목록 파일만 쓰게 규칙화, 배포 전 SDF 검증 실행
앱이 늘어 누가 무엇을 만들었는지 모름	앱 목록에 요청자·승인자·명세 버전·배포일 기록
빌더 한 명에게 지식이 몰림	규칙 파일과 명세를 저장소에 남겨 다른 빌더가 이어받게 함

현업 실행 디테일: 누가, 언제, 무엇을

Brennan처럼 IT가 현업 요청을 하루 단위로 받아 주려면 역할부터 나눕니다. 아래 표와 일정, 기준은 모두 가상 예시입니다.

역할	맡는 일 (가상 예시)
ERP 빌더(NetSuite에 밝은 IT 1명)	요건 듣기, 에이전트로 목업·코드 생성, 샌드박스 시험, 배포
요청 부서 담당자	업무 설명, 목업 리뷰, 수정 요청, 승인
요청 부서장	우선순위 결정, 데이터를 바꾸는 앱 승인
CIO	앱 목록 관리, 운영 반영 기준과 토큰 예산 결정

시작 전 준비물은 NetSuite 샌드박스 계정, SDF 프로젝트가 담긴 저장소, 쓰는 레코드·필드 ID 목록, 요청 접수 양식, 그리고 현업이 지금 화면을 오가며 손으로 옮겨 적는 업무 목록입니다. 이 목록이 첫 후보가 됩니다.

기간	할 일	산출물
1주	화면 전환이 잦은 업무 5개 수집, 규칙 파일과 필드 ID 목록 작성	후보 목록, 작업 폴더
2주	1건을 골라 요건 대화, 목업, 승인, 샌드박스 배포까지 한 바퀴	첫 앱, 소요 시간 기록
3주	나머지 후보를 하루 1~2건씩 처리, 운영 반영	앱 3~5개, 앱 목록
4주	사용률과 기록 누락 변화 확인, 확대 여부 판정	판정 보고서

확인 질문은 이렇게 준비합니다. 이 업무에서 지금 몇 개의 화면을 오갑니까? 입력하다 빠뜨리는 기록은 무엇이고 그 기록이 있으면 누가 무엇을 하게 됩니까? 이 앱이 레코드를 새로 만들거나 바꿉니까, 조회만 합니까? 승인은 누가 하고 고칠 일이 생기면 누구에게 말합니까?

진행 판정 기준은 세 가지로 시작합니다. 요건 대화부터 운영 반영까지 1영업일 안에 끝난 건이 70% 이상, 대상 사용자 가운데 매주 앱을 쓰는 사람이 80% 이상, 앱 도입 전에 빠지던 기록이 매주 실제로 쌓이는지입니다. 데이터를 잘못 쓴 사고가 한 건이라도 나면 그 앱은 샌드박스로 되돌리고 원인을 고친 뒤 다시 반영합니다.

AX 적용 제언. 국내 제조·유통 기업에서 이 사례를 옮길 때 첫 대상은 큰 프로세스 개편이 아니라, 현업이 ERP 화면을 오가다 기록을 빠뜨리는 작은 업무입니다. 영업 통화, 견적 문의, 출고 문의처럼 매일 반복되고 남는 기록이 주문뿐인 업무가 좋습니다. 빌더는 외부 개발자보다 ERP 구조를 이미 아는 사내 IT 담당자가 맞고 에이전트 비용은 앱을 만드는 시간에만 들도록 실행은 ERP 안 코드로 둡니다. 운영 반영 전 샌드박스 시험, 명세 버전, 앱 목록 세 가지를 처음부터 갖추면 앱이 수십 개로 늘어도 관리할 수 있습니다.

원문 사례

항목	내용
원문	diginomica, Phil Wainewright, 2026.11.2, SuiteWorld 현장 인터뷰
인물	Ryan King, Brennan Industries CIO
회사	유압 부품 제조사, NetSuite 고객
도구	Anthropic Claude Code, OpenAI Codex, 최근 NetSuite Next
실행 방식	에이전트가 앱을 SuiteScript로 생성, NetSuite에서 실행. 채팅으로 계속 돌리지 않아 토큰 비용을 피함
속도	목업 약 45분(1시간 미만), 하루 최대 5건. 예전에는 건당 1주 이상
절차	요건 수집, 목업, 동료 리뷰·수정, 승인, SuiteScript 생성·배포
사례	영업 통화 기록 화면. 오후 한나절에 제작, 가격·납기 조회 중 CRM에 기록, 수백 건 통화 이력 확보
화면 방향	필요한 필드만 보이는 양식, ERP 처리는 뒤에서, 입력 시 AI가 질문. 전체 환경을 처음부터 다시 짓는 중
조건	깊은 ERP 지식 필요, 에이전트는 도구이며 단계별 지시와 빠른 답이 필요
고지	Oracle이 diginomica의 premier partner이며 저자의 SuiteWorld 출장비를 부담

핵심 개념

SuiteWorld

Oracle NetSuite의 고객 행사입니다. 이번 인터뷰가 열린 자리입니다.

NetSuite Next

기사에서는 King이 Claude Code·Codex에 더해 최근 쓰기 시작한 NetSuite 쪽 도구로만 나옵니다.

Claude Code / Codex

자연어 지시를 받아 코드를 쓰고 고치는 코딩 에이전트입니다. 각각 Anthropic과 OpenAI가 만듭니다.

token

LLM이 글을 읽고 쓸 때 세는 단위입니다. 호출할 때마다 쓴 만큼 비용이 붙습니다.

CRM

고객과 나눈 연락, 영업 기회, 후속 조치를 기록하는 시스템입니다. 이 사례에서는 NetSuite CRM에 통화 기록이 쌓입니다.

sandbox

운영 데이터와 분리된 시험용 NetSuite 계정입니다. 새 스크립트를 먼저 올려 확인하는 곳입니다.

내 메모

TODO: 내 생각 추가

원문은 diginomica의 「SuiteWorld 26 - Brennan Industries is re-building its ERP user experience in Claude and Codex, without burning tokens」(Phil Wainewright, 2026.11.2 게재)입니다. 요약, 핵심 메커니즘의 기사 내용, 통념과 다른 주장, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 핵심 메커니즘의 작은 예시, 기술·현업 실행 디테일(SDF, Suitelet, 샌드박스 절차 포함), JSON 예시, 실패 대응 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 기사 전문은 원문 페이지에서 볼 수 있습니다.