조금 전, Excel의 폼 안에 있던 AI가 한정판이 아니라 눈을 가린 평범한 Claude였다는 이야기를 썼습니다.

그 기사의 마무리에서 다음과 같이 예고했습니다. "다음에는 대화가 이어지는 것을 전제로 폼을 다시 만들겠습니다. 그릇이 내용물을 따라잡게 되면 다시 쓰겠습니다."

따라잡았습니다. 바로 이것입니다.

Excel 시트 위에 이런 창이 뜹니다. 이름은 "Excel 콤보(Excelコンボ)". 왼쪽 하단의 [AI] 옆에 놓인 sonnet 콤보가 이 이름의 유래입니다.

먼저 고백하자면, 이 기사는 한 번 완성된 후에 폐기될 뻔했습니다. 도구를 만드는 과정에서 근본적인 오류가 발견되었기 때문입니다. 오류는 같은 날 안에 수정되었고, 기사는 이렇게 부활했습니다. 그 전말까지 포함하여 작성하겠습니다.

• Excel의 폼 안에 AI를 살게 하고, 콤보로 모델을 선택하며 작업하는 도구를 만들었습니다. 이름은 Excel 콤보입니다. - 완성된 날, 이름을 붙인 것은 제가 아니라 AI였습니다. "AI 작업창". 임시 이름으로는 충분히 제 역할을 했습니다.
• 사용감에 대한 지적은 거의 전부 이쪽(사용자)에서 나왔습니다. 탭을 3개로 나누기, 글자를 굵게 하기, 중간 경과 보여주기──모두 제가 사용하며 불편함을 말하면 AI가 구현했습니다.
• 다음 날, 이름을 "Excel 콤보"로 변경했습니다. 그리고 기사를 다 써 내려갔을 때, 이 도구가 자작 MCP 서버를 전제로 했다는 사실이 밝혀집니다. 일반인이 가질 수 없는 것을 토대로 하고 있었습니다. 기사는 폐기될 위기였습니다. - 전제를 역으로 바꾸어 다시 만들었습니다. AI에게 도구를 건네주는 것을 그만두고, 폼의 VBA 자체가 AI의 수족이 됩니다. 재료도, 중간 경과도, 위험한 조작에 대한 승인도 전부 폼 안에서 완결됩니다. - AI는 "다시 만들면 느려질 것"이라고 예상했고, 저는 "안에 들어있으니까 빨라질 것"이라고 판단했습니다. 이전 버전에서 31초급이었던 응답이 20초 만에 돌아옵니다. 맞춘 것은 저였습니다.

먼저, 다시 만든 후의 완성형을 쓰겠습니다.

Excel에서 버튼을 누르면 폼이 열리고, 지시란에 일본어로 적고 Ctrl+Enter를 누르면 백그라운드에서 Claude Code가 작동합니다. "이 시트를 사용하고 있는 매크로를 특정해줘", "이 표의 집계 매크로를 만들어줘"와 같은 지시입니다.

AI에게는 도구를 일절 주지 않습니다. 대신 약속을 하나 전달합니다. 재료가 필요하다면, 답변에 주문서를 써라.

AI가 "이 시트의 값을 줘", "모든 매크로 코드에서 이 글자를 검색해"라고 정해진 서식으로 답변하면, 폼의 VBA가 그것을 읽어 들여 열려 있는 북(Book)에서 실제로 가져온 뒤 AI에게 전달하여 다음 내용을 묻습니다. 이 왕복을 답이 나올 때까지 반복합니다. 주문할 수 있는 재료는 시트의 값, 수식, 매크로 본문, 코드 횡단 검색, 현재 선택 중인 셀, 도형과 매크로의 연결 등 총 16종류를 준비했습니다.

코드 수정도 통합니다. 단, 시트에 대한 쓰기, 매크로 치환, 매크로 실행은 실행 직전에 폼이 확인 창을 띄우며, 제가 "예"를 누를 때까지 움직이지 않습니다. 매크로 치환은 치환 전의 코드를 백업한 뒤 적용합니다.

읽는 것은 AI의 판단으로, 쓰는 것은 인간의 승인으로. 지난 기사에서 "선을 긋는다면 읽기/쓰기가 아니라, 되돌릴 수 있음/없음이다"라고 썼던 선이 이번에는 폼 안에 구현되어 있습니다.

여기까지가 완성형입니다. 여기서부터는 이 형태에 도달하기까지의 이야기──첫 번째 버전은 이렇지 않았습니다.

도구가 처음 작동하던 날, 저는 이름을 붙이지 않았습니다. 이름을 붙일 필요를 느끼지 못했다기보다, 애초에 이름이 필요한 물건이라고 생각하지 않았습니다.

그런데 AI 쪽에서 먼저 이름을 붙여왔습니다. "AI 작업창". 매크로 목록 메뉴에도 그 이름으로 나열되었고, 타이틀 바에도 그렇게 표시되었습니다.

이것에는 조금 놀랐습니다. 부탁하지 않았기 때문입니다. 만든 직후에 "어라", "아까 그 폼"이라고 지칭하면 대화가 끊길까 봐 임시로라도 정해두었다──이유를 물으니 그랬지만, 부탁받지 않은 명명(Naming)을 스스로 한다는 것은 저에게 있어 신선한 광경이었습니다.

그리고 생각해보면, 이것을 못 하면 곤란합니다. 프로그래밍은 실질적으로 명명의 연속입니다. 변수를 하나 둘 때마다, Sub를 하나 추가할 때마다 이름이 필요합니다. 만약 AI가 "여기에 변수를 놓겠습니다만, 이름은 무엇으로 할까요?"라고 일일이 물어온다면 한 줄도 나아가지 못할 것입니다. 일단 정해서 달려가고 나중에 수정한다. 이것이 가능한지 여부는 도구로서 사용할 수 있는지의 갈림길입니다.

게다가 이름을 붙이려면 "이것은 무엇인가"를 먼저 결정해야 합니다. 명명은 설계 그 자체입니다. 이름이 떠오르지 않을 때는 대개 만들고 있는 본인조차 무엇을 만들고 있는지 모르고 있는 상태입니다.

그런 까닭에, 이 시점에서는 「AI 작업창」만으로도 만족하고 있었습니다. 불만이 있었다 하더라도, 비교할 대상이 없었으니까요.

갓 만든 폼은 정답 표시란이 하나뿐이었습니다. 지시를 내리면 그 아래로 정답이 쌓여갑니다. 실행 중인 로그도 같은 칸에 흐릅니다.

직접 써보니 보기 불편했습니다. 지금 나온 정답을 읽고 싶은데, 위에는 이전 정답들이 쌓여 있고 그 사이에 실행 로그가 끼어 있습니다. 어디서부터 읽어야 할지 알 수 없었습니다.

그래서 주문을 넣었습니다. 지금의 대화만 보여주고, 나머지는 전부 다른 곳으로.

구현은 MultiPage, 즉 탭(Tab)입니다. 3개로 나누었습니다.

대화: 지금의 한 차례 왕복만. 다음 지시를 내리면 교체됨 -
이력: 지금까지의 전부 -
경과: 실행 중인 로그

이것이 정답이었습니다. 읽을 때는 대화 탭만 보면 됩니다. 이전 대화를 찾고 싶으면 이력으로 갑니다. 같은 정보를, 놓는 장소로 나누었을 뿐입니다.

덤으로 하나 더 주문했습니다. 정답이 표시되면 표시 위치를 맨 처음으로 되돌릴 것. 긴 정답이 돌아왔을 때, 마지막 부분이 보이는 상태로 멈춰 있으면, 읽기 전에 매번 스크롤을 올려야 하는 번거로움이 생깁니다. 코드로 작성하면 단 한 줄입니다.

이렇게 써두면, 이런 종류의 지적은 제가 직접 사용해 보지 않으면 나오지 않습니다. 작동 여부는 AI가 판정할 수 있지만, 읽기 편한지 여부는 읽는 인간만이 알 수 있습니다. AI가 만든 것은 기능이고, 제가 결정한 것은 사용감(Usability)입니다.

다음은 대기 시간에 대한 이야기입니다.

첫 번째 버전의 실측 결과, 한 차례 왕복에 30초에서 40초가 걸리고 있었습니다. 게다가 가벼워야 할 작은 모델일수록 도구 사용법이 서툴러서 더 많이 읽어 들여야 하는 바람에 더 느리다는 결론이 나왔습니다. 몰아붙여도 별로 빨라지지 않는다는 것을 알게 되었기에, 속도를 높이는 것은 포기하고 다른 일을 했습니다. 경과를 보여주기로 한 것입니다.

실행을 시작하면 자동으로 경과 탭으로 전환되며, AI가 지금 무엇을 하고 있는지가 한 줄씩 흐릅니다. 「매크로 목록 취득」, 「〇〇의 본문 읽기」——읽고 있는 대상이 보입니다. 그리고 정답이 나오면 자동으로 대화 탭으로 돌아옵니다.

이것으로 체감이 달라졌습니다. 처리 시간은 1초도 빨라지지 않았습니다. 그럼에도 「기다리고 있다라는 느낌」이 사라져서, 시간이 신경 쓰이지 않게 되었습니다.

침묵을 없애는 것이 속도를 높이는 것보다 효과적이었다. 이 발견 자체는 지금 버전에도 그대로 살아있습니다.

다만——이 경과 표시를 처음에 어떻게 구현했는지가 나중에 폐기하게 되는 계기가 됩니다. 복선으로서 여기에 남겨둡니다.

외관에 대한 이야기도 하나.

저는 나이 때문인지 눈이 피로해서 가는 글씨를 읽지 못합니다. 그래서 글자를 크게 해달라고 주문했습니다.

처음 올라온 것이 14포인트였습니다. 보자마자 거절했습니다. 너무 크고, 너무 굵었습니다. 13으로 낮추고, 여전히 신경 쓰여서 12로 낮추었고, 거기서 안착했습니다.

결국 어떻게 되었냐면, 효과가 있었던 것은 서체와 굵기였지, 크기가 아니었습니다.

• 서체를 BIZ UDP 고딕으로 변경 (UD=읽기 편함을 목적으로 만들어진 서체입니다)
• 입력란·콤보·레이블을 굵게(Bold) 설정
• 크기는 12포인트. 기존과 동일

크기를 1포인트도 키우지 않고도 읽기 편해졌습니다. 「글자를 크게」라고 말했던 제가 원했던 것은 크기가 아니라, 선명한 글자였던 셈입니다. 버튼만 굵게 하면 투박해 보이므로 표준 굵기로 하고, 실행 로그의 경과 탭만은 자릿수를 맞추고 싶어서 고정폭(Monospace)으로 설정했습니다.

다음 날, 다른 곳에서 이름에 관한 이야기가 다시 돌아왔습니다.

계기는 전혀 다른 이야기였습니다. Excel에서 Google Apps Script를 하나 거쳐 외부 API를 호출하는 구조가 통과되었고, 그 경위를 기사로 써서 올린 바로 다음 날의 잡담이었습니다.

중계 경로가 하나 생겼다는 것은, 폼의 콤보(Combo)에 나열할 목적지를 얼마든지 추가할 수 있다는 뜻이기도 합니다.

거기서 깨달았습니다. 이것은 Cursor나 Antigravity에서 모델을 선택하는 것과 같은 일을 하고 있다는 것을.

그리고 어딘가 어색한 점도 깨달았습니다. 「Excel 폼 안에서 AI 모델을 선택하며 작업할 수 있는 것」이라고 매번 그렇게 설명하고 있었다는 사실입니다. 「AI 작업창」이라는 이름이 있는데도 그 이름으로는 아무것도 전달되지 않기에, 결국은 설명하고 있었습니다.

이름을 다시 지었습니다. **Excel 콤보(Excel Combo)**입니다.

이중으로 효과가 있다고 생각합니다. UI 부품으로서는 놓여 있는 것이 콤보박스(Combobox) 하나입니다. 그리고 그 내용은 VBA로부터 여러 경로를 거쳐 AI로 연결되는 연계 기술(Combo)──기술 측면에서의 콤보이기도 합니다. 누르는 곳은 한 곳이지만, 뒤에서는 여러 곳이 연결되어 있습니다.

이름을 바꾸는 작업 자체는 허무할 정도였습니다. 수정한 곳은 메뉴에 나타나는 실행용 Sub 명, 폼의 타이틀 바(Title bar), 실행 전 확인 화면의 타이틀 이렇게 세 곳뿐이었습니다. 비포(Before)와 애프터(After)를 나란히 놓아보겠습니다. 차이는 타이틀 바의 단어 하나뿐이며, 그 외에는 단 1픽셀도 움직이지 않았습니다.

개명이란 결국 이 정도의 일입니다. 그럼에도 불구하고, 부르기 쉬운 정도는 완전히 달라졌습니다.

덤으로 알게 된 사실이 하나 있습니다. 'Excel 콤보'라는 이름의 내용──콤보로 모델을 선택하는 메커니즘──은, 이름을 바꾸기 전부터 들어있었습니다. 'AI 작업창'은 내용에 대한 설명일 뿐이었고, 'Excel 콤보'는 사용하는 손놀림에서 유래한 것이었습니다. 이름만이 나중에 내용에 따라잡은 셈입니다.

여기까지 쓰고, 기사는 일단 완성되었습니다.

다 써 내려간 초안을 앞에 두고, 나는 공개를 멈췄습니다.

계기는 복선으로 적어두었던 경과 표시였습니다. 저 'AI가 지금 무엇을 하고 있는지'를 보여주는 한 줄 한 줄은, 사실 AI 측이 아니라, 내가 직접 만든 MCP 서버──AI가 Excel을 만지게 하기 위한 도구──가 출력하고 있었습니다. 즉, 그 서버가 없는 환경에서는 경과가 단 한 줄도 나오지 않습니다.

그뿐이라면 단순한 트릭(Trick) 이야기일 것입니다. 하지만 파고들수록 이야기는 더 깊어졌습니다. AI가 스스로 워크북(Workbook)을 읽으러 가는 것도 자작 서버의 도구이며, 위험한 조작 앞에서 멈추는 승인 절차도 같은 서버 안에 있었습니다. 이 도구의 세 기둥은 모두 폼(Form) 외부의, 세상에서 오직 내 책상에만 존재하는 서버에 세워져 있었던 것입니다. 서버가 없는 환경에서 폼을 열면, 빈 껍데기와 침묵만이 남습니다.

나는 AI에게 말했습니다. "MCP 서버 같은 건 보통 사람들은 가질 수 없어. 그런 전제로 만드는 도구라고."

돌이켜보면, 이 연재의 도구들은 줄곧 '가지고 있지 않은 사람'을 기준으로 만들어 왔습니다. 복사해서 붙여넣기만 해도 작동하는 버튼. API 키를 대신 처리하기 위한 GAS(Google Apps Script) 중계. 이 도구만 유독 가장 혜택받은 환경──내 책상──을 기본값(Default)으로 하여 설계되어 있었습니다.

만든 사람의 환경을 표준으로 삼은 도구는, 만든 사람의 책상 위에서만 도구가 된다.

기사는 선을 긋는 문장 하나를 추가한다고 해서 구원받을 수 있는 것이 아니었습니다. 도구의 설계가 우선입니다. 폐기(Discard).

전제를 뒤집겠습니다. MCP 서버가 없는 상태에서도 모든 것이 성립하게 하고, 있는 사람은 그 위에 올라타기만 하면 되도록. 역방향이 아니라.

열쇠가 된 것은 너무나 당연해서 보이지 않았던 사실입니다. VBA는 Excel 안에서 움직이고 있다. 열려 있는 워크북과 가장 가까운 곳에 있는 것은 외부의 상주 서버가 아니라, 폼 자체의 VBA입니다. AI의 '손'이 필요하다면, 외부에서 특주품을 가져올 필요 없이 처음부터 그곳에 있습니다.

그래서 설계는 다음과 같이 바뀌었습니다.

• AI에게 도구를 주지 않는다. 대신 "재료가 필요하면 주문서를 써라"라는 약속만 전달한다.
• AI의 주문서(이 시트의 값, 모든 매크로에서 이 글자를 검색 등)를 VBA가 읽어 들여, 실제로 가져온 뒤 전달하고 다음 지시를 기다린다.
• 중간 경과는 주문을 한 건 처리할 때마다 VBA가 자신의 경과 탭에 한 줄씩 기록한다.
  실행 주체가 자신이기 때문에 트릭이 필요 없다 - 되돌릴 수 없는 조작은 실행 주체가 VBA이므로, 실행 전에 VBA가 일반적인 확인 화면을 띄운다.

외부에 두었을 때는 환경 변수니 파일 연동이니 하는 트릭의 연속이었던 세 기둥이, 안으로 옮기니 전부 폼의 일상적인 기능이 되었습니다. 승인 화면을 띄울 수 없다는 헤드리스(Headless) AI의 문제도, 애초에 AI에게 실행을 맡기지 않으므로 소멸했습니다.

이 재설계에 대해 AI 측은 "속도가 떨어질 것"이라고 예측했습니다. 외부 서버를 경유하면 AI가 1초에 몇 번이고 도구를 두드릴 수 있지만, 주문서 방식은 왕복 한 번마다 CLI(Command Line Interface)의 기동 비용을 지불해야 하기 때문입니다. 거의 두 배는 느려질 것이라는 전망이었습니다.

나의 판단은 반대였습니다. 안에 있으니까, 빨라질 수밖에 없다.

실측 결과입니다. 재설계 전후의 두 버전은 동일한 질문인 "이 시트를 사용하고 있는 매크로를 특정해줘"로 측정했습니다. MCP 서버 버전의 수치만은 전날의 실측치이며, 질문은 다른 것입니다 (동일한 조건으로는 다시 측정할 수 없으므로, 참고용으로 나열합니다).

처음 69초는 예상대로 패배였습니다. 원인은 AI가 "어떤 매크로가 이 시트를 사용하는지" 조사할 수단이 없어, 매크로 본문을 하나씩 가져오는 낚시 작업을 6번이나 반복했기 때문입니다. 여기서 "모든 매크로 코드를 횡단 검색하라"는 주문을 한 종류 추가했더니, 낚시 6회가 검색 1회로 바뀌며 2회 왕복 20초가 걸렸습니다. 조건이 동일하지 않다는 점은 고려해야 하지만, 전날 MCP 버전의 실측치마저 밑도는 결과였습니다.

AI의 예측이 빗나간 이유를 생각해보면 이렇습니다. 외부 서버 방식에서는 AI가 도구를 한 번 호출할 때마다 「생각하기 → 호출하기 → 결과를 보고 다시 생각하기」를 반복하고 있었습니다. 도구 호출 한 번은 빠를지 몰라도, 생각하는 횟수만큼 시간을 지불하고 있었던 것입니다. 내부의 VBA는 통합 문서의 모든 매크로를 한 번에 훑어서 결과를 한 접시에 모아 내놓을 수 있습니다. AI는 그 접시를 보고 단 한 번만 생각하면 됩니다.

속도의 정체는 도구의 속도가 아니라, AI에게 생각하게 만드는 횟수였습니다. 그리고 횟수를 줄일 수 있는 것은, 한꺼번에 가져올 수 있는 자, 즉 내부에 거주하는 자뿐입니다. "내부에 있으니 당연한 결과겠지" —— AI에게 말한 대로의 결과가 나왔습니다.

게다가, 내부에 있는 자만이 가질 수 있는 주문서도 만들 수 있었습니다. "지금 화면에서 선택하고 있는 셀". 이것은 외부 서버에서는 원리적으로 보이지 않습니다. 내가 셀을 선택하고 "여기를 봐"라고 말할 수 있는 것 —— 현장에 있는 자의 특권입니다.

이 이틀간의 과정과 한 번의 반려를 통해 보면, 하나의 선이 그어집니다.

AI가 만들 수 있는 것은 기능이며, 전제와 사용감은 인간이 결정한다.

탭을 3개로 나누는 것도, 글자를 굵게 만드는 것도, 동작 자체로는 아무것도 변하지 않습니다. 그것을 요구할 수 있는 것은 사용하고 있는 인간뿐이었습니다. 이름도 마찬가지입니다. AI는 임시 이름표를 붙일 수 있습니다. 오히려 붙여주지 않으면 곤란할 정도입니다. 다만, 진짜 이름표를 새기는 것은 사용하는 쪽의 일입니다.

그리고 이번에 그 선이 한 단계 더 깊게 통과했습니다. "이 도구는 누구의 책상 위에서 돌아가야 하는가"라는 전제조차 AI로부터는 나오지 않았습니다. AI는 자신의 눈앞에 있는 환경 —— 도구가 전부 갖춰진, 가장 축복받은 책상 —— 을 의심 없이 토대로 삼아 능숙하게 조립해 버립니다. 올바르게 만들어진 잘못된 물건만큼 지적받기 전까지 알아채기 어려운 것도 없습니다.

그럼에도 불구하고, 임시 이름표가 있었기에 다시 붙일 수 있었던 것과 마찬가지로, 일단 형태가 갖춰져 있었기에 전제부터 뒤집는 재작업을 하루 만에 끝낼 수 있었다고도 할 수 있습니다. AI가 단정적으로 달려나가고, 인간이 전제를 바로잡는다. 이 분담은 아마 앞으로도 변하지 않을 것입니다.

관례에 따라 분류합니다.

사실: 폼을 2026년 8월 1일에 만들고, 8월 2일에 「AI 작업창」에서 「Excel 콤보」로 개명한 것. 같은 날, 내용이 자체 제작 MCP 서버를 전제로 한다는 점이 지적되어 기사를 반려한 것. 같은 날 내에 주문서 방식으로 재작업하여, MCP 서버 및 허가 인수에 대한 의존성을 완전히 폐지한 것. 실측치가 재작업 직후 69초(6회 왕복) · 코드 검색 추가 후 20초(2회 왕복)인 것(동일한 질문에 대한 당일 실측치. 공개 전에 재확인하겠습니다). MCP 버전의 31초는 전날의 실측치이며 질문이 다르다는 점(본문에도 명시했습니다). 주문할 수 있는 재료는 16종이며, 시트 쓰기 · 매크로 교체 · 매크로 실행의 3가지는 실행 전 승인제라는 것. 폰트를 BIZ UDP 고딕 12포인트 굵게로 통일하고, 14포인트를 기각하여 12포인트로 결정한 것.

견해: MCP 버전과 주문서 방식의 속도 차이에 대한 설명(생각하는 횟수의 차이. AI의 내부 처리를 측정한 것은 아닙니다). "침묵을 없애는 것이 속도를 높이는 것보다 효과적이었다"는 것은 저 개인의 체감입니다. "올바르게 만들어진 잘못된 물건일수록 알아채기 어렵다"는 해석 그 자체입니다.

• 이 폼이 들어있는 통합 문서는 미공개 상태입니다. 실행하려면 Claude Code CLI의 설정과 로그인이 필요합니다. MCP 서버는 필요 없게 되었지만, CLI는 여전히 필요합니다. 누구의 Excel에서도 바로 돌아가는 것은 아닙니다.
• 실측치는 자택 PC · 특정 질문 1개에 대한 비교입니다. 질문의 종류나 통합 문서의 크기에 따라 달라집니다.
• 주문서는 읽기 계열 16종을 준비했지만, 실전에서 통과시킨 것은 아직 몇 종류뿐입니다. 승인제인 3가지(쓰기 · 매크로 교체 · 매크로 실행)는 한 번도 통과시키지 않았습니다.
• AI가 주문서 형식을 어기면 재료가 전달되지 않아 추측으로 답합니다. 약속 사항은 프롬프트로 길들이고 있을 뿐이므로, 이 사고는 일정 수 발생한다는 전제하에 움직입니다.
• 왕복은 최대 7회로 제한하며, 매크로 교체의 백업은 메모리 유지로만 수행합니다(폼을 닫을 때까지).
• "Excel 콤보"의 콤보는 현재 Claude의 4개 모델입니다. 회사를 넘나들며 선택할 수 있게 되어야 비로소 이름값(Combo)을 하게 됩니다. 목적지를 늘리는 배관(GAS 중계)은 마련해 두었으므로, 그 부분은 다음 숙제입니다.

이틀간의 과정과 한 번의 반려로 알게 된 것을 한 줄로 요약하면 다음과 같습니다.

만든 것에는 이름이 필요하다. 그리고 이름도 전제도, 만든 쪽에서는 나오지 않는다.

AI는 요청하지 않아도 이름표를 붙이고, 요청하지 않아도 조립합니다. 빠르고 능숙하며 대개 옳습니다. 다만 그 이름표가 적절한지, 그 토대가 누구의 책상 위에도 있는지는 사용하는 인간이 말하기 전까지는 알 수 없는 채로 남습니다. 나는 이름표를 바꿔 달고 토대를 다시 만들게 했습니다. 두 가지 모두 AI는 지시를 받은 후에는 빨랐습니다.

지금 Excel 안에는 Claude가 4개 나열된 콤보(Combo)가 자리 잡고 있습니다. 외부의 특주(Custom) 서버는 이제 필요 없습니다. 폼(Form)과 VBA, 그리고 CLI뿐입니다. 도구는, 배포할 수 있는 형태가 되었을 때 비로소 도구입니다.

다음에는 이 콤보에 다른 회사의 모델을 하나 추가하겠습니다. 그때는 이름이 먼저 정의되어 있으므로 조금 더 수월할 것이라고 생각합니다.

이 기사의 내용을 영상으로도 제작했습니다.