요약(TL;DR): 우리 회사의 근태 관리 SaaS(Software as a Service) 갱신 통지서가 도착했습니다: 300명 대상, 인당 월 200엔, 연간 720,000엔. 금액은 수용 가능한 수준이었습니다. 문제는 비용이 아니라 적합성(fit)이었습니다. 두 가지 요구사항(실제 출장 비용 정산, 네트워크 기반 사무실 출근 판정)이 표준 SaaS 사양을 벗어났기 때문입니다. 저는 AI를 코딩 리소스로 활용하여 Google Apps Script (GAS)로 몇 시간 만에 시스템을 재구축했습니다. 저는 이러한 인간의 역할을 "AI Director"라고 부릅니다. 비용 측면을 넘어, 민첩성(요구사항 발생 당일 시스템 반영), 데이터 소유권(Lock-in 방지), 그리고 새로운 개발 흐름 — 즉, 작동하는 샘플을 구축한 다음, 프로덕션 단계로 끌어올리기 위해 SIer(System Integrator)에게 인계하는 방식 — 을 얻었습니다. 추가적인 생각으로는 프로그래머의 지식이 여전히 가치 있는 영역(전문 분야, AI 이후의 품질 검토)에 대해 다룹니다. 골드러시 비유를 들어 설명하겠습니다.

제1장: 요구사항 — 왜 SaaS가 더 이상 맞지 않았는가
범용 SaaS는 많은 기업이 공유하는 비즈니스 프로세스를 중심으로 설계됩니다. 이는 타당한 설계 철학입니다. 하지만 회사 고유의 로직을 보유한 조직의 경우, 회사의 비즈니스가 SaaS가 제공하는 기능과 일치하지 않을 수 있습니다. 우리의 경우 두 가지 요구사항이 표준 사양을 벗어났습니다:

1. 실제 비용 대비 출장비 정산: 정기권 경로 및 일일 경로 판정에 관한 특정 규칙. SaaS의 기본 집계 기능으로는 이를 처리할 수 없었습니다.
2. 네트워크 기반 출근 판정: 기업 네트워크를 통해 출근 기록이 남았는지 여부에 따라 "재택 vs 사무실 출근"을 결정하고자 했습니다. 위치 기반 판정은 충분히 정밀하지 않았습니다.

범용 SaaS로 이를 해결하는 두 가지 방법이 있습니다: 커스텀 개발 옵션에 비용을 지불하거나, CSV 내보내기 + 사후 처리(post-processing)라는 임시방편을 사용하는 것입니다. 전자는 비용을 부풀립니다. 후자는 일종의 역(inverse) 벤더 락인(vendor lock-in)을 발생시킵니다. 즉, 귀사의 운영 프로세스가 오직 귀사만이 이해할 수 있는 수동 워크플로우에 갇히게 됩니다.

결정은 간단했습니다. AI를 외부 코딩 리소스로 고용하고, 우리의 요구사항에 맞게 GAS로 시스템을 재구축하는 것이었습니다. 구현 시작부터 운영 검증까지 단 몇 시간이 걸렸습니다. AI가 코드를 작성했습니다.

사람들은 요구사항과 사양 조정을 담당했습니다. 이 글에서 저는 인간의 역할을 "AI Director"라고 부르겠습니다.

제2장: 물리적 제약 돌파하기 (Ver.1에서 Ver.4까지)

개발 과정에서 위치 획득 방식이 네 번 바뀌었습니다. 각 변경은 발견된 제약 사항이었으며, 이를 우회하기 위한 설계 결정이었습니다.

Ver.1: HTML5 Geolocation
스마트폰의 GPS는 합리적인 정밀도를 제공합니다. 하지만 출퇴근 기록(punch)은 주로 PC에서 발생하는데, PC에서 Geolocation은 Wi-Fi 삼각 측량이나 IP 기반 추정 방식으로 대체됩니다. 오차 범위는 킬로미터 단위였습니다. 사무실 내부에 있는지 판단하기에는 정밀도가 부족했습니다. 기각되었습니다.

Ver.2: IP 기반 추정 (IP-Based Estimation)
많은 SaaS 제품이 사용하는 대체 방식을 모방했습니다. 외부 API를 호출하여 클라이언트 IP로부터 지리적 위치를 추정하고, 이를 주소 문자열로 변환하는 방식입니다. 여기서도 오차는 컸습니다. 통신사 라우팅(Carrier routing)으로 인해 많은 경우 "집"이 "도쿄역 근처"로 나타납니다. 실행 불가능합니다.

Ver.3: Google Maps 역지오코딩 (GAS 내장)
GAS에는 Maps 서비스가 포함되어 있습니다. Maps.newGeocoder().reverseGeocode(lat, lng)를 사용하면 비용 부담 없이 역지오코딩 (Reverse Geocoding)을 수행할 수 있습니다. 이를 통해 위도/경도(lat/lng)를 주소로 변환하기 위한 외부 API 키의 필요성을 제거했습니다. 정밀도 문제는 여전히 남아 있었지만, 비용 측면에서는 SaaS보다 확실한 우위를 점했습니다.

Ver.4: 출석 증명을 위한 마스터 매칭 (Master Matching)
최종 솔루션은 위치 정밀도를 높이는 것이 아니었습니다. 판단의 축 자체를 바꾸는 것이었습니다. 기업 네트워크를 통해 기록이 들어오면, 글로벌 IP는 회사 라우터의 고정 IP가 됩니다. 이 IP를 기업 사이트 주소 마스터와 대조합니다. 일치하면 "사무실 내"임이 확인됩니다. 이렇게 되면 위치 정밀도는 문제의 핵심에서 벗어나 무의미해집니다. 이는 결정론적인 IP-마스터 조회(deterministic IP-master lookup)로 귀결되므로, 구조적으로 오류가 발생하지 않습니다. 출석 판단이라는 목적 하나만 놓고 본다면, IP 매칭이 Geolocation보다 요구사항에 더 정확하게 부합합니다.

제3장: 시스템의 기능
최종 형태는 다음과 같습니다:
원터치 기록 (One-tap punch): 브라우저에서 버튼 하나로 출근/퇴근이 기록됩니다.

동적 위치 기록 (Dynamic location recording): IP 마스터가 "사무실 내(in-office)"임을 확인하거나, 그렇지 않을 경우 역지오코딩 (Reverse Geocoding)을 통해 주소 문자열을 기록합니다. 자동 월간 집계 (Automated monthly aggregation): 기업 사이트 마스터 매칭을 통해 계산된 개인별 출근 일수. 데이터 소유권 (Data ownership): 기록 데이터는 자체 Google Spreadsheet에 축적됩니다. 별도의 내보내기 (export) 작업이 필요 없습니다. SaaS를 해지한 후에도 데이터는 남아 있습니다. 마지막 포인트는 벤더 종속 (vendor lock-in) 방지에 매우 중요합니다. SaaS를 사용할 경우, 해지는 일반적으로 과거 데이터에 대한 접근 권한을 잃거나 CSV 덤프 (CSV dumps)에 국한되는 것을 의미합니다. 내부 개발은 데이터 구조 자체를 우리의 통제 하에 둡니다.

4장: AI의 비대칭적 레버리지 (AI's Asymmetric Leverage)
대부분의 AI 코딩 지원 관련 기사들은 생산성을 "프로그래머가 N배 더 빨라진다"라고 정의합니다. 이는 수직축(vertical-axis) 관점의 이야기입니다. 동일한 역할 내에서 처리량 (throughput)이 증가하는 것입니다. 더 빠른 타이핑, 더 빠른 코드 리뷰, 더 빠른 리팩토링 (refactoring)과 같은 것들입니다. 여기서 일어난 일은 다른 방향의 레버리지였습니다. 도메인 지식 (domain knowledge)을 가진 사람이 AI를 사용하면, 기존에 "비즈니스 측 → 엔지니어 외주 → 구현 → 검토" 과정을 거쳐야 했던 비즈니스 시스템을 중간 단계를 건너뛰고 직접 구축할 수 있습니다.

두 번째 형태의 레버리지는 시장 관점에서 비대칭적입니다. 프로그래머의 생산성 향상은 프로그래머 간의 경쟁을 가속화합니다. 반면 도메인 전문가의 AI 활용은 전문 직종의 경계를 완전히 가로지릅니다. 수직축을 따른 가속화 대 경계를 넘나드는 것. 이것들은 서로 다른 유형의 레버리지입니다. AI Director는 후자를 구현합니다.

5장: 결과물로서의 샘플 활용 — 전문가 인계 (The Specialist Handoff)
모든 출근 요구 사항을 최소 한 명을 위해 작동하는 샘플 시스템으로 패키징합니다.

그 시점부터 로그인 관리, 변경 요청 승인 흐름 (change-request approval flow), 데이터베이스 관리 (database management) 및 기타 프로덕션급 (production-grade) 요소들을 직접 구축하는 데 시간을 보낼 수도 있습니다. 하지만 이 단계에서는 SIer (system integrator, 시스템 통합업체)에게 작업을 인계하는 것이 실행 가능한 옵션입니다. 비즈니스가 원하는 모든 사항이 캡처되어 있고, 작동하는 샘플과 GAS 코드를 보유하고 있기 때문입니다. 이는 요구사항 정의 (requirements definition), 기본 설계 (basic design)의 일부, 기능 설계 (functional design) 및 상세 설계 (detailed design)를 완료한 것과 맞먹는 수준입니다. 단순히 SIer에게 이를 모든 직원이 사용할 수 있는 시스템으로 만들어 달라고 요청한다면, 비용은 전통적인 외주 방식보다 현저히 낮을 것입니다. 나아가, 적절한 SIer가 사양서 (specifications) 및 시스템 설계 문서 (system-design documents)를 산출물로 포함하여 프로덕션 품질 (production-quality)의 시스템을 인도한다면, 남은 변경 사항은 규모 조정 (직원 수 변경) 및 예외 케이스 (rare-case) 반영뿐입니다. 사양서와 시스템 설계를 현재 환경 (current environment)으로서 AI에 다시 입력함으로써, 이러한 변경 사항들을 직접 처리할 수도 있습니다. 로직은 직접 구축하고, 전문가는 이를 프로덕션 품질로 끌어올리게 하며, 산출물은 본인이 소유하십시오. 현재의 AI는 무엇이든 할 수 있는 마법 같은 도구가 아니라, 여러분 자신의 사고를 확장하는 도구입니다. 여러분 자신의 한계가 곧 AI의 한계임을 인식하십시오. 30분 동안 문제가 해결되지 않는다면, 이를 미결 이슈 (open issue)로 목록화하십시오. 그런 다음 다른 사람들이 해결하게 하거나, 그들이 검토하고 나아갈 방향을 제안하게 하십시오. AI를 중간에 활용하여 이슈 수를 줄이는 일반적인 시스템 개발, 이것이 제가 보는 미래 시스템 개발의 트렌드입니다.

제6장: 결론
연간 720,000엔을 절약하는 것이 여기서의 주요 결과는 아닙니다. 핵심 결과는 비즈니스 요구사항이 바뀌는 즉시 시스템을 재작성할 수 있는 능력입니다. SaaS 벤더가 기능을 추가하기를 기다리는 대신, 요구사항을 작성하는 날 시스템이 그에 따라 움직입니다. 이러한 민첩성 (agility)은 비용 계산만으로는 온전히 담아낼 수 없습니다. AI 코딩 시대에 "코드를 작성할 수 있는 능력"의 시장 가치는 상대적으로 하락하고 있습니다.

상승하는 것은 무엇을 구축해야 하는지 정의하고, AI에게 올바르게 지시하며, 결과물을 검증하는 능력입니다. 이는 새로운 직업의 등장이라기보다, 이미 비즈니스 지식을 보유한 사람들이 AI를 구현 계층 (Implementation Layer)으로 활용함으로써 자신의 비즈니스 도메인을 하나의 시스템으로 재구조화할 수 있는 시대의 도래에 가깝습니다. 요구사항을 정의하고, AI가 구축하게 하며, 이를 운영에 통합하는 AI Director (AI 디렉터)로서 작동하는 능력은 오늘날의 비즈니스 환경에서 기본적인 생존 전략 중 하나로 자리 잡고 있습니다.

보너스: 프로그래머의 지식이 가치를 유지하는 곳

이 글은 AI Director의 관점에 치우쳐 있습니다. 프로그래머의 지식이 여전히 가치 있는 패턴들도 정리해 보겠습니다.

AI가 부족한 영역에서의 전문화: 실시간 제어 (Real-time control), 임베디드 시스템 (Embedded systems), 보안 (Security), 형식 검증 (Formal verification), 미션 크리티컬 (Mission-critical) 도메인 등입니다. 이러한 영역에서는 검증 없이 AI가 작성한 코드를 실행하는 것이 사회적으로 용납되지 않습니다. 전문가적 지식의 깊이와 견고함 (Robustness)을 요구하는 분야는 여전히 프로그래머의 영역으로 남아 있습니다. 이는 AI Director가 침범할 수 있는 영역이 아닙니다. 오히려 프로그래머가 순수하게 더 강력해지는 방향입니다.

전문가 지식의 별도 수익화: 별도로, 저는 AI에게 계약서 초안을 작성하게 한 뒤 변호사에게 최종 검토를 요청했습니다. 2~3개의 코멘트만으로 5,000엔에 완료되었습니다. 이것이 AI 시대에 전문가가 자리 잡는 방식 중 하나를 보여주는 예시입니다. AI가 초안을 작성하더라도, 전문가의 검토는 법적 책임, 환각 (Hallucination) 완화, 전문가적 판단이라는 가치를 유지합니다. 프로그래머에게도 동일한 구조가 적용됩니다. AI Director가 구축한 샘플은 이를 프로덕션 품질 (Production quality)로 끌어올리는 단계에서 SIer/프로그래머의 검토가 필요합니다. 역할은 "처음부터 코드를 작성하는 데 소비하는 시간"에서 "코드를 평가하고 프로덕션 품질로 끌어올리는 데 소비하는 시간"으로 전환됩니다. 생산이 쉬워진 시대에, 반드시 생산 측에 머물러 있을 필요는 없습니다. 품질을 높이거나 시스템을 구축하는 쪽으로 이동할 수 있습니다.

골드러시(gold-rush) 비유가 적절합니다. 금을 캐기 위해 곡괭이를 휘두르는 대신, 곡괭이를 파는 사람이 되거나 금을 제련하는 사람이 될 수 있습니다. 이제 AI는 역사적으로 프로그래머의 시간을 소비해 온 영역들을 다룹니다. 확보된 시간은 방법론(methodology)과 알고리즘(algorithms)에 대한 지식을 심화하는 방향으로 재전환될 수 있습니다. 생산은 AI가 처리하게 하십시오. 전문가로서 비평하는 쪽으로 이동하십시오. 이것이 프로그래머, 나아가 모든 전문가를 위한 모델 패턴이 될 수 있습니다.