비개발 직군에 AI 가드레일 배포할 때 주의할 5가지

AI 도입 이후 우리가 일하는 방식도, 만들어 내는 것들도 많이 달라졌는데요. 이제는 비개발 직군도 직접 Git 저장소를 만들고, 웹페이지를 배포하고, 데이터를 가공합니다. 외부 서비스와 AI 에이전트를 연결하고, AI가 제안한 명령어를 실행하는 일도 더 이상 개발자만의 업무가 아닙니다.

할 수 있는 일이 늘어나는 만큼 새로운 판단도 필요합니다. 이 저장소를 개인 계정에 만들어도 되는가? AI가 만든 페이지를 바로 외부에 공개해도 되는가? 업무 파일이 섞인 폴더에서 에이전트를 실행해도 되는가?

기존의 계정 관리, 문서 공유, 개인정보 처리 기준만으로는 이런 질문에 충분히 답하기 어렵습니다. 그래서 이제는 AI가 어디까지 보고, 무엇과 연결되고, 어디까지 실행할 수 있는지에 대한 기준이 필요합니다.

저는 PO로서 AI 활용 범위가 비개발 직군까지 넓어지는 과정을 지켜봤습니다. 이 글은 그 과정에서 기존 업무 기준만으로는 다루기 어려웠던 판단의 공백을 정리하고, 조직의 환경에 맞는 ‘AI 업무 가드레일’을 설계한 경험에 관한 이야기입니다. 비개발 직군의 AI 활용을 지원하면서 어떤 기준을 새롭게 살펴야 할지 고민하고 있다면, 이 과정과 기준이 각자의 환경에 맞는 가드레일을 정리하는 데 참고가 되면 좋겠습니다.

아래에서는 가드레일을 만들고 배포하며 챙긴 다섯 가지를 차례로 정리합니다.

미리 요점만 콕 집어보면?

• AI 활용이 늘면 파일 접근, 외부 서비스 연결, 자동 실행, 산출물 공개에 관한 새로운 업무 기준이 필요합니다.
• 가드레일은 접근 범위·연결 범위·실행 범위를 중심으로 정리하고, 금지 항목에는 이유와 대안을 붙여야 합니다.
• 문서 배포 이후의 적용 과정도 설계해야 합니다. Skill과 확인 절차는 기준을 실제 업무에 연결하는 방법이 될 수 있습니다.

AI로 넓어진 업무 범위, 다양해진 산출물

기존에도 개인 계정 사용을 금지하거나 공개 범위를 제한하는 등 가이드는 있었습니다. AI를 도입한 뒤에도 기존 규칙은 유효합니다. 다만 넓어진 업무 범위에 맞는 가이드가 새로 필요해졌습니다.

웹페이지 만들기로 예를 들어볼까요? 이전에는 페이지를 외부에 공개하려면 개발이나 인프라 담당자를 거쳐야 했습니다. 그래서 배포 규칙이나 접근 권한이 뚜렷하게 정해져 있었습니다. 지금은 AI에 페이지를 만들어 달라고 한 뒤, 같은 대화에서 배포까지 요청할 수 있습니다.

하지만 인프라나 접근 권한에 대한 개념이 제대로 정립되지 않은 채 AI에 이끌려 가다 보면 어떻게 될까요? 내부에서 잠깐 확인하려던 페이지에 검색 노출과 SEO 설정까지 더해져, 예상보다 넓게 발견될 수도 있습니다.

산출물 역시 다양해졌는데요. 비개발 직군이 다루는 산출물이라고 하면 엑셀, PPT, PDF 정도였는데, 이제는 Skill, 웹페이지, 프로그램 등으로 확장되었습니다.

특히 웹페이지나 프로그램은 작업하다 보면 코드 관리 플랫폼인 깃허브(GitHub)를 자연스럽게 사용하게 됩니다. 하지만 규칙이 정해져 있지 않다면 코드와 산출물이 개인 계정에 흩어질 수 있습니다. 그러면 조직은 결과물이 어디에 있고 누가 관리하는지 파악하기 어려워집니다.

이뿐만 아니라 에이전트가 등장하면서 사람의 통제 아래 진행되던 업무에서도 AI가 더 깊은 권한을 요청하게 됐습니다. 실제로 접근할 수 있는 데이터의 양도 극적으로 늘었습니다.

사내에서 AI를 활용해 기존보다 폭넓은 유형의 산출물이 생기면서, 그에 맞는 업무 기준도 함께 마련해야 했습니다.

1. AI 항목을 덧붙이지 말고 하는 일 기준으로 나누기

처음에는 기존 가이드에 AI 관련 주의사항을 추가하면 충분할 것 같았습니다. 하지만 Git, 호스팅, 파일 접근, 권한 승인처럼 성격이 다른 문제를 한데 묶으면 항목만 늘어납니다. 그래서 구성원이 실제로 하는 일을 기준으로, 무엇을 확인해야 하는지 세 가지로 나눴습니다.

1) 접근 범위: AI는 무엇까지 볼 수 있는가

비개발 직군에게는 에이전트형 AI를 실행할 때 어디까지를 작업 공간으로 허용할지 정하는 일 자체가 익숙하지 않은 경우가 있었습니다. 실제로 가장 많은 파일이 모여 있는 상위 폴더나 다운로드 폴더를 그대로 접근 범위로 두고 AI를 실행하는 경우도 있었습니다. 그 폴더에는 업무 중 내려받은 계약서나 고객 데이터가 함께 들어 있기도 했습니다.

채팅만 이용할 때는 내가 어떤 정보를 입력하고 있는지 비교적 명확하게 알 수 있습니다. 하지만 활용 범위가 터미널과 에이전트형 AI로 확장되면, 사용자가 직접 첨부하지 않은 파일도 작업 과정에서 읽힐 수 있습니다. 이때부터는 요청 내용뿐 아니라 실행 위치와 접근 가능한 파일 범위까지 함께 확인해야 합니다.

같은 작업 영역에 고객 데이터, 계약서, 인증정보가 있다면 ‘민감정보를 AI에 입력하지 않는다’는 원칙만으로는 충분하지 않습니다. 그래서 다음 기준을 함께 정리했습니다.

• 작업 영역을 프로젝트 단위로 분리합니다.
• 필요하지 않은 고객 데이터와 계약서는 작업 영역에서 분리합니다.
• API 키·토큰·인증 파일에 불필요하게 접근하지 못하도록 설정합니다.

특히 자격증명은 서비스에 직접 접근할 수 있는 수단이기 때문에 별도로 관리해야 합니다. 코드나 대화에 직접 넣지 않고 조직에서 승인한 방식을 사용해야 합니다. ‘읽지 말라’는 지침만으로 실제 접근 제한이 보장된다고 보기는 어렵습니다.

2) 연결 범위: AI는 무엇과 연결되어 있는가

도구에 AI를 연결할 때는 결국 내가 가진 계정 권한을 AI도 함께 사용하게 됩니다. 실제로 컨플루언스(Confluence)를 연결한 뒤 쓰기 권한까지 허용하자, AI가 다른 사람이 작성한 페이지나 기존 양식을 수정·삭제하는 일이 생기기도 했습니다. 사용자 입장에서는 내 계정으로 하는 작업이지만, 그 계정이 조직 내에서 가진 권한 범위만큼 AI의 행동 범위도 넓어지는 셈입니다.

이후로는 단순히 연결 여부만 보는 것이 아니라, 내 계정이 가진 권한이 무엇인지, 그중 어디까지 AI에 맡길 것인지를 먼저 확인하도록 기준을 정했습니다. 이때는 다음 질문을 공통적으로 확인했습니다.

• 누가 제공하는가?
• 어떤 파일과 서비스에 접근하는가?
• 읽기만 하는가, 수정과 삭제도 가능한가?
• 외부로 데이터를 전송하는가?
• 실행 전에 사람의 확인을 거치는가?

특히 외부 콘텐츠 접근, 쓰기 권한, 자동 승인이 함께 있는 경우에는 그 조합을 살펴야 합니다. 외부에서 읽은 내용이 이후 행동에 영향을 주고, 사람의 확인 없이 데이터 변경으로 이어질 수 있기 때문입니다.

조회만 필요한 업무라면 쓰기 권한이 필요한지부터 확인해야 합니다. 사용자가 권한의 의미를 이해하기 어렵다면, 조직에서 검토한 연결 방식과 허용 범위를 안내할 필요가 있습니다.

3) 실행 범위: AI에 어디까지 맡길 것인가

AI와 작업 흐름을 따라가며 새 Git 저장소를 만들거나 push까지 진행하는 경우도 있었습니다. 사용자는 단순히 결과물을 저장한다고 생각했지만, 실제로는 새로운 저장소 생성과 외부 반영까지 함께 이뤄질 수 있었습니다.

이후로는 저장소 생성, push, 배포처럼 조직 자산이나 외부 환경에 영향을 주는 행동은 사람이 한 번 더 확인하도록 기준을 두었습니다.

AI가 초안을 제안하는 것과 실제 행동을 수행하는 것은 다릅니다. 그래서 AI가 할 수 있는 일과 자동으로 맡겨도 되는 일은 별도로 정해야 합니다. 파일 삭제, Git push, 외부 데이터 전송, 데이터베이스 수정, 배포 등이 주요 확인 대상입니다.

모든 행동에 승인을 요구할 필요는 없습니다. 영향 범위와 되돌릴 수 있는지 여부를 기준으로 구분해야 합니다. 분리된 폴더에서 초안을 수정하는 일과 운영 데이터를 변경하는 일을 같은 방식으로 다뤄서는 안 됩니다.

확인 절차도 구체적이어야 합니다. ‘계속 진행할까요?’라는 질문만으로는 부족합니다. 무엇을 어디에 실행하며 어떤 데이터가 바뀌는지 사용자가 판단할 수 있어야 합니다.

2. AI가 만든 결과물도 관리 대상으로 정하기

AI로 만든 페이지를 빠르게 공유하기 위해 각자 익숙한 외부 호스팅 서비스를 사용하거나, 개인 기준으로 Git 저장소를 만드는 경우도 있었는데요. 실제로 버셀(Vercel)에 임의로 페이지를 올리거나 저장소가 여러 계정에 흩어지면서, 결과물이 어디에 있고 누가 관리하는지 한눈에 파악하기 어려워졌습니다.

결과물이 조직의 관리 범위를 벗어나지 않도록, 작업이 끝난 뒤에는 산출물의 공개 범위와 관리 주체를 확인해야 합니다.

프로토타입이라도 실데이터가 들어 있거나 운영 시스템에 연결되어 있다면 운영 서비스와 같은 수준으로 관리해야 합니다. 공유 전에 개인정보와 인증정보의 노출, 내부 시스템 연결, 공개 대상과 접근 제한을 살펴야 합니다.

Git 저장소도 비공개 여부만 확인해서는 부족합니다. 개인 계정에만 남아 있다면 담당자가 바뀌었을 때 인수인계나 권한 회수가 어려울 수 있습니다. 조직이 계속 접근하고 관리할 수 있는 구조인지 확인해야 합니다.

AI 활용 지원과 디지털 자산 관리는 함께 설계해야 합니다. 구성원이 결과물을 빠르게 만들 수 있도록 지원했다면 저장 위치와 관리 주체도 안내해야 합니다.

3. ‘하지 마세요’ 뒤에는 이유와 대안 붙이기

결국 비개발 직군이 AI를 쓰는 이유는 해결하려는 문제가 있기 때문입니다. 조사한 자료를 다른 사람과 공유하거나, 반복해서 처리하던 데이터를 빠르게 정리하거나, 간단한 시스템을 만들어 업무에 활용하려는 식입니다.

그래서 위험하다는 이유로 특정 방법을 쓰지 말라고만 하는 것은 해결책이 될 수 없습니다. 원래의 업무 목적이 사라지는 것이 아니기 때문입니다. 외부 호스팅을 막으면 다른 공유 방법이 필요하고, 실제 데이터를 사용하지 말라고 하면 테스트할 수 있는 데이터가 필요합니다.

그래서 금지·주의 행동 → 이유 → 가능한 대안의 순서로 정리했습니다.

예를 들어 승인되지 않은 외부 호스팅에 업무 페이지를 바로 공개하지 않도록 안내한다고 해 보죠. 이때는 공개 대상과 접근 권한을 통제하기 어렵다는 이유를 함께 설명하고, 내부 공유 방식이나 승인된 외부 배포 경로를 제시합니다.

실데이터를 AI에 입력하지 않도록 안내할 때도 마찬가지입니다. 데이터를 처리하거나 기능을 검증하려는 목적은 그대로 남기 때문에, 비식별 데이터나 목데이터를 사용할 수 있도록 대안을 함께 안내했습니다.

아직 정해진 대안이 없다면 누구에게 무엇을 확인받아야 하는지라도 명시해야 합니다. ‘담당자에게 문의’라고만 적기보다 공개 목적과 포함 데이터처럼 판단에 필요한 정보를 함께 안내하는 편이 좋습니다.

구성원에게 기준을 따르라고 요구하려면, 그 기준 안에서 일을 계속할 수 있는 방법도 함께 제공해야 합니다.

4. 문서 대신 작업 중에 만나게 하기: Skill

가이드를 잘 정리해도 구성원이 작업할 때마다 문서를 열어 관련 항목을 찾을 것이라고 기대하기는 어렵습니다. AI와 대화하면서 빠르게 작업하는 중에는 더 그렇습니다.

그래서 가드레일을 내부 프로덕트처럼 바라봤습니다. 문서를 배포했다는 사실보다, 구성원이 내용을 확인하고 실제 작업에 적용하는 단계까지 이어지는지가 중요했습니다.

빠르게 움직이는 스타트업에서 모든 상황을 담당자가 일일이 확인하기는 어렵습니다. 필요한 순간에 기준을 발견하고, 적은 부담으로 활용할 수 있는 방법이 필요했습니다.

그래서 AI 업무와 직접 연결되는 내용을 Skill 형태로 다시 만들었습니다. 반복되는 상황별로 확인할 기준과 대안을 정리하고, 사용자가 특정 행동을 요청하면 AI가 관련 기준을 먼저 참조하도록 구성했습니다.

다음은 실제 업무 사례를 바탕으로 재구성한 예시입니다.

사용자: “이 페이지 외부에서도 볼 수 있게 해줘.”

AI: “공유 대상과 포함된 데이터를 먼저 확인해야 합니다. 내부 공유가 목적이라면 승인된 내부 방식을 사용할 수 있습니다. 외부 공개가 필요하다면 공개 가능한 데이터인지 확인하고 승인된 배포 경로로 진행해야 합니다.”

사용자가 문서를 찾느라 작업을 멈추는 대신, 이미 진행 중인 대화에서 기준을 확인하도록 한 것입니다. API 키 사용이나 외부 도구 설치에도 같은 구조를 적용할 수 있습니다.

물론 Skill이 실제 권한 제한을 대신하지는 않습니다. 지침을 참조하게 하는 것과 실행을 기술적으로 막는 것은 다릅니다. 영향이 큰 행동에는 권한 제한과 사람의 확인 절차를 함께 남겨야 합니다.

5. 배포한 뒤 적용 과정까지 설계하기

‘읽어주세요’라는 공지만으로는 가이드를 실제로 확인했는지, 필요한 설정까지 바꿨는지 알기 어렵습니다. 그래서 배포 과정 역시 다음 행동으로 이어지도록 나눴습니다.

가이드 배포 → 핵심 기준 확인 → 실행 항목 체크 → Skill 안내 → 팀 단위 확인

문서는 전체 기준을 설명하고, 체크 항목은 당장 해야 할 행동을 알려줍니다. Skill은 실제 작업 중 필요한 순간에 관련 기준을 다시 확인하도록 돕습니다. 하나의 방식에 기대기보다 각 단계의 목적에 맞는 방법을 조합했습니다.

그 결과 전 구성원이 가이드 확인을 마쳤고, Skill 역시 실제 업무에 적용했습니다. 물론 확인을 완료했다는 사실이 실제 준수까지 보장하지는 않습니다. 이후에는 사용 과정에서 반복해서 나오는 질문과 예외를 살피고, 기준이 현실과 맞지 않는 부분을 계속 보완해야 합니다.

“이런 게 생기니까 차라리 더 낫다.”

특히 기억에 남은 피드백입니다. 기준이 없는 상태에서 매번 ‘이건 해도 되는지’를 판단하는 데 부담을 느낀 사람이 저만이 아니었던 거죠. 그 점이 흥미로우면서도 보람 있었습니다.

하지 말아야 할 행동, 한 번 더 확인해야 할 지점, 그리고 가능한 대안이 정리되니 오히려 할 수 있는 범위를 판단하기 쉬워졌습니다. 모든 경우의 수를 규칙으로 정의하지 않아도, 몇 가지 경계가 명확하면 그 안에서는 훨씬 편하게 움직일 수 있었던 것입니다.

PO로서도 의미 있는 피드백이었습니다. 가드레일의 역할은 규칙을 늘리는 것이 아니라, 구성원이 업무 중 반복해야 하는 판단을 줄이는 데 있다는 것을 실제 적용 과정에서 확인할 수 있었기 때문입니다.

우리 조직에서는 무엇부터 체크하면 될까?

처음부터 긴 문서를 만들 필요는 없습니다. 현재 업무 환경에서 자주 판단이 필요한 지점을 살펴보고, 반복해서 등장하는 상황부터 기준을 정리해볼 수 있습니다.

가드레일 역시 한 번 만들고 배포한다고 끝나지는 않습니다. 실제 업무에 적용하면 반복되는 질문이 생기고, 이해하기 어려운 문장이나 현실적으로 쓰기 어려운 대안도 드러납니다.

이런 부분은 다시 고치고, 필요한 내용은 Skill처럼 업무 중 바로 참고할 수 있는 형태로 바꿀 수 있습니다. 새로운 도구와 권한이 추가되면 기준도 함께 다시 살펴야 합니다.

이번 과정에서 가장 중요하게 본 것은 규칙의 양이 아니었습니다. 구성원이 매번 같은 판단을 반복하지 않도록 하면서도, 새로운 시도까지 막지는 않는 것. 그 균형을 어떻게 설계하느냐가 더 중요했습니다.

업무 환경을 살펴 기준을 만들고, 실제 흐름에 적용하고, 다시 개선하는 과정이 쌓여야 새로운 도구도 조직의 일하는 방식 안에 자연스럽게 자리 잡을 수 있습니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.