자동화는 잘 도는데, 설명할 사람이 없습니다
지난달 누군가 만든 Slack 리포트 봇이 오늘도 정상적으로 메시지를 보냅니다. 그런데 만든 사람은 다른 팀으로 옮겼고, Google Sheets와 Slack에 어떤 권한으로 접속하는지, API 키가 코드에 들어 있는지 묻자 아무도 확답하지 못합니다.
AI 코딩 도구 덕분에 작은 사내 앱과 스크립트는 빨리 만들 수 있게 됐지만, 소유자·자격증명·권한·실행 기록을 설명하는 일까지 저절로 해결되지는 않습니다. Tines는 AI로 만든 소프트웨어가 IT와 보안의 가시성 밖에서 시스템과 데이터에 연결되는 현상을 ‘와일드 코드(Wild Code)’라고 부릅니다. 다만 공인 보안 분류가 아니라 Tines가 제시한 제품·시장 프레임입니다.
여기서 가져갈 핵심은 자동화를 막는 방법이 아닙니다. 코드가 비밀값을 직접 들고 외부 시스템을 호출하던 구조를 커넥터, 격리된 실행, 비공개 초안과 라이브 권한으로 나누는 방법입니다.
위험은 AI보다 ‘경계 없는 연결’에서 커집니다
먼저 확인할 것은 AI가 작성한 코드의 비율이 아니라 그 코드가 가진 연결 권한입니다. IBM이 2026년 1~4월 33개 지역과 19개 산업의 IT·기술·AI 의사결정 담당 고위 임원 2,000명을 조사한 결과, 77%는 AI 도입 속도가 현재 거버넌스 역량을 앞선다고 답했고 70%는 현업의 기술 배포 속도를 IT가 추적하지 못한다고 답했습니다. 특정 회사의 미승인 자동화 비율은 아니지만, 중앙에서 설명하기 어려운 도구가 늘어나는 운영 문제를 보여주는 인식 조사입니다.
자격증명을 코드와 함께 다루는 습관은 공개 저장소에도 흔적을 남겼습니다. GitGuardian은 2025년 공개 GitHub의 MCP 관련 설정 파일에서 고유 시크릿 24,008개를 발견했고, 그중 2,117개는 검사 시점에 유효했다고 보고했습니다. 모든 사내 자동화의 노출률로 일반화할 수는 없지만, 설정 파일도 소스코드와 같은 유출 경로가 될 수 있다는 경고로는 충분합니다.
생성된 코드 자체도 검토 대상입니다. Veracode는 100개가 넘는 LLM에 Java·JavaScript·C#·Python으로 구성된 단일 함수 완성 과제 80개를 수행시키고 SAST로 검사했습니다. 그 결과 전체 모델·과제 조합의 45%에서 알려진 보안 결함이 탐지됐습니다. 실제 애플리케이션 전체의 45%가 취약하다는 뜻은 아니지만, 작은 함수도 배포 전에 정적 분석과 권한 검토를 건너뛰면 안 된다는 근거입니다.
Tines 3B가 옮기는 것은 자격증명과 실행 경계입니다
Tines 3B의 실용적인 차이는 비밀값을 워크플로 로직 밖으로 빼는 데 있습니다. API 키와 OAuth 토큰 같은 자격증명은 개별 단계가 아니라 커넥터에 저장되고, 요청 URL이 커넥터에 설정된 패턴과 일치할 때 외부 요청에 붙습니다. 공식 설명상 비밀값은 프록시를 거쳐 런타임에 주입되므로 빌더와 AI, 생성 코드에 직접 노출되지 않습니다.
연결 가능한 서비스를 Tines가 미리 정한 목록으로만 제한하는 구조는 아닙니다. 커스텀 API 키·OAuth·원격 MCP·데이터베이스 커넥터도 만들 수 있습니다. 따라서 안전성은 제품 이름보다 누가 커넥터를 만들 수 있는지, URL 패턴과 토큰 권한을 얼마나 좁혔는지에 달려 있습니다.
| 통제 지점 | 경계가 흐린 자동화 | 3B에서 확인할 설정 |
|---|---|---|
| 자격증명 | 코드·설정 파일·채팅에 직접 입력 | 커넥터에 저장하고 목적지 URL 패턴 지정 |
| 실행 | 한 프로세스에서 여러 작업을 연속 실행 | 단계마다 별도 샌드박스와 네트워크 환경에서 실행 |
| 변경 | 수정 즉시 예약·웹훅이 작동 | 비공개 초안에서 수동 시험한 뒤 라이브 반영 |
| 추적 | 만든 사람의 기억과 개인 로그에 의존 | 3B가 관리하는 워크플로의 모니터링·감사·버전 관리 |
격리와 프록시가 최소 권한을 대신하지는 않습니다. URL 패턴을 넓게 잡거나 관리자급 토큰을 넣으면 잘못된 호출의 영향도 커집니다. 또한 공식 자료에서 확인되는 모니터링 범위는 3B가 관리하는 워크플로입니다. 플랫폼 밖에서 이미 실행 중인 개인 스크립트와 앱까지 자동 발견한다고 단정할 근거는 없습니다.
설치 없이, 외부 전송 없는 초안부터 만드세요
첫 실행의 성공 기준은 Slack 메시지를 실제로 보내는 것이 아닙니다. 샘플 자동화 정보를 넣었을 때 소유자 누락, 코드에 둔 자격증명, 검토일 누락을 구조화된 결과로 찾고, 외부 시스템에는 아무 변화도 일으키지 않는 것입니다.
Explore 무료판은 현재 무제한 사용자·공간·커넥터, 라이브 워크플로 3개와 일회성 50달러 AI 사용량을 제공합니다. 관리형 Claude·OpenAI 공급자도 기본 설정돼 별도의 공급자 API 키 없이 시작할 수 있습니다. 가격과 제공 조건은 바뀔 수 있습니다.
- Tines 3B 무료 시작 경로에서 Explore 테넌트를 만들고 로그인합니다. 첫 시험에는 실제 API 키나 운영 데이터를 준비하지 마세요.
- General 공간이나 개인 공간을 열고 ‘What do you want to do?’ 입력창을 찾습니다. 새 요청의 결과는 비공개 First draft에 생성됩니다.
- 아래 요청을 입력합니다.
외부 API를 호출하지 않는 수동 실행 워크플로를 만들어 주세요. 첫 단계에서 다음 샘플 JSON을 출력하세요: {"name":"weekly-report-bot","owner":"","purpose":"Slack 주간 리포트","systems":["Slack","Google Sheets"],"credential_location":"source_code","last_reviewed":""}. 다음 단계는 owner, credential_location, last_reviewed를 검사해 누락되거나 위험한 항목을 JSON 배열로 stdout에 출력해야 합니다. 외부 요청, 메시지 전송, 파일 저장, 운영 데이터 변경은 하지 마세요.
이 JSON과 판정 항목은 제품 성능을 평가하는 수치가 아니라, 부작용 없는 첫 실행을 위한 예시입니다. - 아직 Run을 누르지 말고 생성된 모든 단계와 연결을 먼저 펼쳐봅니다. HTTP·API 호출, Slack이나 이메일 전송, 파일 저장, 운영 데이터 변경 단계가 없는지 확인하세요. 요청과 다른 단계가 생겼다면 채팅으로 삭제하도록 수정하고 전체 흐름을 다시 검토합니다. 초안도 수동으로 실행하면 외부 시스템을 호출할 수 있습니다.
- 부작용이 없는 단계만 남았을 때 시작 단계에서 Run을 누릅니다. Run은 선택한 단계와 연결된 후속 단계를 함께 실행합니다. Solo run은 선택한 단계 하나만 실행하므로 최종 점검 결과까지 확인하는 이번 시험에는 맞지 않습니다.
- 실행 상태와 마지막 단계의 stdout을 확인합니다. 상태가 Success이고, 마지막 stdout에 owner 누락,
source_code자격증명 위치, last_reviewed 누락을 나타내는 구조화된 결과가 나오면 성공입니다. stdout은 해당 단계의 결과이며 다음 단계가 있다면 그 단계의 stdin으로 전달됩니다. - 결과를 확인한 뒤에도 First draft로 둡니다. 예약·웹 요청·이메일 트리거는 라이브 버전에서 자동 작동하므로 이번에는 Push live를 누르지 않습니다.
입력창에서 모델을 사용할 수 없다면 테넌트 종류와 권한부터 확인하세요. Explore에는 관리형 공급자가 기본 제공되지만, 유료 테넌트는 자체 AI 공급자 설정이 필요할 수 있습니다. 조직 정책 때문에 가입할 수 없거나 필요한 공간 권한이 없다면 임의의 개인 계정으로 운영 데이터를 옮기지 말고 관리자에게 승인된 시험 공간을 요청하세요.
실제 API를 붙일 때는 URL과 권한을 함께 좁히세요
샘플 점검이 끝난 뒤에만 외부 연결을 추가하세요. 커넥터 생성 권한이 있는 사용자가 Connectors에서 테스트용 최소 권한 자격증명을 등록하고, 실제 호출할 호스트와 경로에 맞춰 URL 패턴을 좁게 지정합니다. 그다음 읽기 전용이거나 부작용이 없는 테스트 URL과 HTTP 메서드를 설정해 연결을 검사하세요. 테스트에 성공하면 상태가 Active로 표시됩니다.
테스트 URL과 메서드를 비워두면 연결 검사를 건너뛰어 Untested로 남을 수 있습니다. Untested는 자격증명이 실제로 작동한다는 뜻이 아닙니다. 안전한 테스트 엔드포인트가 없다면 운영 데이터로 바로 확인하지 말고 별도 테스트 환경부터 마련하세요.
초안이 기대한 데이터만 읽고 썼을 때 비로소 라이브 반영을 검토합니다. 공식 문서상 Push live 과정에는 단계 테스트를 포함한 사전 점검이 있지만, 점검에 실패해도 사용자가 게시를 계속할 수 있습니다. 사전 점검은 경고 장치이지 절대적인 배포 차단선은 아닙니다.
기존 자동화를 옮기기 전에는 네 칸부터 채우세요.
- 소유자: 장애와 권한 변경에 답할 사람
- 목적: 어떤 입력을 받아 어디에 사용하는지
- 자격증명: 저장 위치, 권한 범위, 교체일
- 실행 경계: 외부 전송, 데이터 변경, 자동 트리거 여부
한 칸이라도 모르면 바로 라이브로 옮기지 말고 샘플 데이터 초안에서 동작을 다시 설명하게 만드세요. ‘와일드 코드’를 줄이는 첫 행동은 새 제품 구매가 아니라 지금 돌아가는 자동화를 설명 가능한 상태로 바꾸는 일입니다.
