Vibe Coding하는 비개발자는 개발자인가(3)
AI 에이전트는 비개발자에게 단순히 코드를 생성해주는 도구를 넘어, 업무를 실행 가능한 구조로 재정의하게 만드는 동반자다. 글쓴이는 로컬 HTML 도구를 공유 서비스로 확장하고, 스프레드시트·웹훅·환경변수·스킬·MCP 등을 활용하며 입력과 출력, 권한, 보안, 검증 조건을 자연스럽게 고민하게 되었다고 말한다. 결국 중요한 것은 코딩 능력 자체보다 자신의 업무를 AI가 수행할 수 있는 단위와 규칙으로 구조화하는 능력이다. ## 로컬 HTML에서 공유 데이터 도구로 - 초기 도구는 브라우저에서 실행하는 단일 HTML 파일이었다. - 서버와 데이터베이스가 필요 없고 혼자 사용하기에 충분했다. - 다른 사람과 공유하려면 배포 주소, 최신 버전 반영, 데이터 저장 문제가 생겼다. - 정적인 화면을 넘어 다음 요구사항이 발생했다. - 과거 입력값 조회 - 여러 사용자의 데이터 공유 - 상태 변경에 따른 화면 갱신 - 사용자별 조회·수정 권한 관리 - 잘못된 수정의 복구와 데이터 백업 - 정식 데이터베이스는 접근 권한 설계와 운영·보안 부담이 컸다. - 대신 구글 스프레드시트를 공유 데이터 저장소로 활용했다. - 기존 협업 UI와 권한 관리 기능을 이용할 수 있었다. - 수정 이력과 공유 기능도 이미 제공됐다. - Apps Script 코드를 직접 붙여넣는 방식에서 시작해, 이후 `clasp`를 이용한 Apps Script API 기반 배포·실행 방식으로 발전했다. - 핵심 변화는 코드를 많이 작성한 것이 아니라, 데이터 위치·공유 방식·권한·변경 이력을 설계하기 시작했다는 점이다. ## 웹훅 연동과 보안 습관 - AI 에이전트의 도움으로 업무 환경과 연결되는 웹훅 봇을 구현할 수 있게 되었다. - 웹훅 URL과 토큰을 다루면서 다음 보안 원칙을 익히게 됐다. - 비밀값을 코드나 프롬프트에 직접 입력하지 않기 - `.env` 파일에서 환경변수로 읽기 - `.gitignore`로 저장소에 비밀값이 올라가지 않도록 하기 - 로그에 토큰 등 민감정보를 출력하지 않기 - 실제 비밀값 대신 placeholder 사용하기 - 작은 자동화라도 외부 시스템과 연결되는 순간 실행 환경과 접근 권한, 비밀값 관리가 함께 고려되어야 한다. - 보안은 별도의 전문 작업이 아니라 AI에게 코드를 요청할 때마다 반복하는 작업 습관이 되었다. ## 손작업을 명세와 파이프라인으로 바꾸기 - 파일 복사·정리, 문서 변환, 영상 편집, 음성 추출, 요약 등 기존의 수작업도 AI 에이전트에게 맡기기 시작했다. - 사람이 직접 할 때는 감으로 처리하던 작업도 에이전트에게 맡기려면 구체적인 명세가 필요했다. - 대상 입력 파일 - 결과 파일명과 저장 위치 - 기존 파일 덮어쓰기 여부 - 실패 시 중단 조건 - 결과의 정상 여부를 판단하는 검증 기준 - 이 과정에서 반복 업무가 다음과 같은 업무 단위로 분해됐다. - 입력 - 처리 단계 - 출력 - 예외 상황 - 검증 조건 - 자동화의 핵심은 명령어를 아는 것이 아니라, 한 단계가 완료되었다고 판단할 기준과 입력·출력 형식을 정의하는 데 있다. ## 회의록 스킬과 반복 판단의 축적 - 매주 반복되는 회의록 작성 과정에서 일정한 수정 패턴이 발견됐다. - 글쓴이는 Codex와 Claude의 `skill`을 만들어 회의 유형별 규칙을 저장했다. - 회의록의 출력 형식 - 결정사항과 액션 아이템 추출 방식 - PMO 관점에서 확인할 신호 - AI가 독단적으로 결론 내리지 않고 사용자에게 질문해야 하는 경우 - 스킬은 단순한 프롬프트 모음이 아니라 반복되는 판단 기준과 업무 규칙을 저장하는 장치였다. - AI가 초안을 작성하면 최종본과 비교해 개선점을 찾고, 그 결과를 다시 스킬에 반영하는 순환 구조를 만들었다. - 내부 데이터를 정리하다가 대화 기록을 잃어버린 사례도 있었다. - 스킬 파일은 남았지만 대화에 포함된 맥락이 사라져 성능이 일시적으로 저하됐다. - 반복 업무에서는 규칙뿐 아니라 맥락과 사례를 보존하는 것도 중요하다는 점을 보여준다. ## MCP와 스킬을 이용한 GA 리포트 자동화 - 기존에는 구글 애널리틱스(GA) 데이터를 확인하고 여러 대시보드를 만들어 인사이트를 도출하는 과정이 번거로웠다. - GA MCP를 통해 API로 데이터를 가져오고, 스킬로 월간 리포트 형식을 유지했다. - 지난달과 이번 달의 차이를 비교해 변화가 의미 있는지 판단하는 방식으로 리포트가 개선됐다. - MCP는 데이터를 가져오는 통로이고, 스킬은 반복되는 리포트 구조를 유지하는 장치다. - 중요한 것은 단순히 숫자를 요약하는 것이 아니라 다음을 판단하는 것이다. - 어떤 변화가 발생했는가 - 그 변화가 설명할 가치가 있는가 - 추가 조사가 필요한 신호인가 - AI의 분석 결과에 사용자의 업무 맥락을 결합하면 이전에는 발견하기 어려웠던 변화를 준실시간으로 탐지할 수 있다. ## 개발의 경계가 넓어지는 방식 - 변화의 본질은 AI 도구의 개수가 늘어난 것이 아니라, 기존 업무를 다른 구조로 바라보게 된 데 있다. - AI가 만든 결과물 자체보다 AI가 수행할 수 있도록 업무를 설명하는 방식이 중요해졌다. - 앞으로 더 많은 사람이 다음 요소를 일상적으로 고민하게 될 것으로 전망한다. - 입력과 출력 - 권한과 보안 - 반복 작업과 파이프라인 - 완료 조건과 검증 방법 - 이는 모든 사람이 전통적인 개발자가 된다는 뜻은 아니다. - 다만 비개발자의 업무도 점차 쪼개지고, 자동화되고, 실행 가능한 형태로 재정의될 수 있다. AI 에이전트를 효과적으로 활용하려면 “무엇을 만들어 달라”보다 “입력은 무엇이고, 결과는 어떤 형식이어야 하며, 실패와 보안 문제를 어떻게 처리할지”를 구체적으로 정의하는 것이 좋다. 반복되는 수정과 판단을 스킬이나 문서로 축적하고, 민감정보와 작업 맥락을 안전하게 관리하는 습관을 함께 갖추는 것이 실용적인 출발점이다.
원문 읽기(새 탭에서 열림)