Molayo

© 2026 Molayo

Qiita헤드라인2026. 05. 30. 15:28

업무 개발에서 AI를 사용하기 전에 정리해야 할 체크 관점

요약

업무 개발 시 AI를 안전하고 효율적으로 활용하기 위한 체크리스트를 제안합니다. 보안, 라이선스, 비용 및 코드의 신뢰성 문제를 리스크 수준에 따라 관리하는 현실적인 접근법을 다룹니다.

핵심 포인트

  • 모든 항목을 기계적으로 확인하기보다 리스크에 따라 확인 수준을 조절할 것
  • 고객 정보, API 키, 비공개 사양서 등 민감 정보 입력 시 익명화 필수
  • AI 출력물은 반드시 동작 원리와 부작용을 스스로 설명할 수 있어야 함
  • 도구별 데이터 취급 방식과 사내 보안 규정을 사전에 확인

업무 개발에서 AI를 사용하는 장면이 늘어나고 있습니다.

코드의 초안을 만든다.

에러의 원인을 조사한다.

설계안을 정리한다.

문서를 요약한다.

테스트 관점을 도출한다.

이러한 용도에서 AI는 상당히 편리합니다.

한편, 업무 개발에서 사용하는 경우에는 개인 학습이나 개인 개발과는 다른 주의점이 있습니다.

  • 출력된 코드가 반드시 옳다고 할 수 없음
  • 그럴듯한 잘못된 정보(Hallucination, 할루시네이션)가 섞일 수 있음
  • 잘 모르는 분야일수록 틀린 것을 알아차리기 어려움
  • 기밀 정보나 계약상의 제약이 있음
  • 클라우드 환경에서는 시행착오가 그대로 비용으로 이어질 수 있음
  • 리뷰할 사람이 없으면 타당성 판단이 어려움

이 기사에서는 업무 개발에서 AI를 사용하기 전에 정리해 두고 싶은 체크 관점을 정리합니다.

먼저 전제를 적어 두겠습니다.

본 기사의 내용은 AI를 사용할 때마다 모든 항목을 기계적으로 확인하기 위한 것이 아닙니다.

실제 업무 개발에서 모든 AI 출력에 대해 매번,

  • 공식 문서 확인
  • 보안 확인
  • 라이선스 확인
  • OSS(Open Source Software)와의 유사성 확인
  • 비용 영향 확인

을 전부 수행하는 것은 현실적이지 않습니다.

중요한 것은, 모든 것을 매번 확인하는 것이 아니라 리스크에 따라 확인 수준을 바꾸는 것입니다.

따라서 이 기사에서는 체크 관점을 다음 세 가지로 나눕니다.

  • 기본적으로 매번 의식하고 싶은 것
  • 구현 내용에 따라 확인하고 싶은 것
  • 팀·회사로서 정해 두어야 할 것

AI를 안전하게 사용하려면 '전부 체크한다'보다, 어떤 장면에서 어디까지 확인할지를 정해 두는 것이 더 현실적이라고 생각합니다.

먼저 확인하고 싶은 것은 AI에 입력하는 정보입니다.

업무 개발에서는 다음과 같은 정보를 그대로 입력하지 않는 것이 안전합니다.

  • 고객명
  • 계약 정보
  • API 키
  • 액세스 토큰
  • 비밀번호
  • 개인 정보
  • 비공개 사양서
  • 사내 한정 자료
  • 미공개 장애 정보
  • 마스킹하지 않은 운영 환경의 로그 전문

AI 도구에 따라 입력 데이터의 취급 방식은 다릅니다.

또한, 같은 서비스 이름이라도 개인 계약·법인 계약·API 이용·조직 설정에 따라 취급이 달라질 수 있습니다.

따라서 우선 다음을 확인합니다.

  • 해당 AI 도구를 업무에서 사용해도 되는가
  • 입력해도 되는 정보의 범위는 어디까지인가
  • 소스 코드를 입력해도 되는가
  • 로그를 입력해도 되는가
  • 고객 정보나 안건 정보를 익명화해야 하는가

망설여지는 경우에는 구체적인 이름을 숨기거나 구조만 추상화하여 상담하는 것이 안전합니다.

NG 예시:
주식회사 〇〇를 위한 △△ 시스템에서 다음과 같은 운영 로그가 나오고 있습니다.
OK 예시:
...

예를 들어, 에러 조사를 위해 운영 로그를 그대로 붙여넣은 결과, 이메일 주소나 내부 URL, 고객 식별자가 섞여 있었다는 일은 일어나기 쉽습니다.

로그는 언뜻 단순한 문자열로 보일지라도, 실제로는 개인 정보나 기밀 정보를 포함하고 있을 수 있습니다.

'그대로 외부에 보내도 문제없는 정보인가'로 판단하면 이해하기 쉽습니다. 망설여진다면 입력하지 않는 것이 기본입니다.

AI가 내놓은 코드나 설계안은 편리하지만, 그대로 업무 결과물로 만들기에는 위험이 있습니다.

최소한 다음 사항은 확인하고 싶습니다.

  • 어떤 일을 하는 코드인지 설명할 수 있는가
  • 기존 설계와 모순되지 않는가
  • 에러 발생 시의 동작을 이해하고 있는가
  • 부작용(Side Effect)이 어디에 있는지 파악하고 있는가
  • 삭제·갱신·과금·권한 변경 등의 영향이 없는가

특히 자신이 잘 모르는 분야에서는 주의가 필요합니다.

AI의 답변은 단정적인 말투로 돌아올 때가 있습니다.

하지만 단정적이라고 해서 반드시 옳다는 뜻은 아닙니다.

'잘 모르겠지만 돌아간다'는 상태로 업무 코드에 넣는 것이 아니라, 적어도 자신이 리뷰에서 설명할 수 있는 상태로 만들어 두어야 합니다.

인증 관련 코드를 AI에게 생성하게 했더니, 로그인 자체는 되었지만 인가(Authorization) 체크가 빠져 있어서 권한이 없는 사용자도 조작할 수 있게 되었다는 일은 충분히 있을 수 있습니다.

'돌아가는 것'과 '요건을 충족하는 것'은 별개입니다.

리뷰에서 구두로 설명할 수 없는 코드는 그대로 넣지 않는 것이 안전합니다.

AI가 내놓은 코드는 실행을 전제로 확인합니다.

최소한 다음 사항은 확인하고 싶습니다.

  • 빌드(Build)가 통과하는가
  • Lint가 통과하는가
  • 타입 에러가 없는가
  • 기존 테스트가 실패하지 않는가
  • 추가한 처리의 동작 확인을 했는가
  • 이상계(Abnormal case)도 확인했는가

AI에게 물어보는 것으로 끝내는 것이 아니라, 실제로 동작시켜 확인합니다.

특히 버전 차이에 의한 에러에는 주의가 필요합니다.

AI가 오래된 API나 오래된 라이브러리 사양을 전제로 답변하는 경우도 있습니다.

그 경우, 코드는 그럴싸해 보여도 현재 환경에서는 동작하지 않을 수 있습니다.

빌드(Build)·테스트(Test)·동작 확인을 거치지 않은 것은 샘플로 취급하는 것이 무난합니다.

AI에게 수정을 요청하면 예상보다 넓은 범위가 변경될 수 있습니다.

특히 에디터 연동형 AI 도구에서는 여러 파일을 한꺼번에 변경하기도 합니다.

확인해야 할 관점은 다음과 같습니다.

  • 변경된 파일을 파악하고 있는가
  • 불필요한 변경이 포함되지 않았는가
  • 기존 사양을 깨뜨리지 않았는가
  • 주석이나 명명 규칙(Naming)이 기존 방침과 일치하는가
  • 생성된 코드가 과도하게 복잡해지지 않았는가

AI에게 맡기는 범위가 넓을수록 차이점 리뷰(Diff Review)는 중요해집니다.

차이점을 완전히 추적할 수 없는 변경은 그대로 반영하지 않는 것이 안전합니다.

여기서부터는 매번 수행하는 것이 아니라, 구현 내용에 따라 확인하고 싶은 관점입니다.

라이브러리, 클라우드 서비스, 프레임워크에 관한 내용은 필요에 따라 공식 문서(Official Documentation)에서 확인합니다.

특히 확인해야 할 사항은 다음과 같습니다.

  • API 명칭
  • 옵션 명칭
  • 권장되지 않는 방식(Deprecated)이 아닌지 여부
  • 버전 차이
  • 요금과 관련된 사양
  • 보안 설정
  • 권한 설정
  • 제한 사항

AI는 오래된 정보나 다른 버전의 정보를 섞어서 답변할 때가 있습니다.

예를 들어 AWS, Next.js, React, Android, Matter 등 사양의 변화나 전제 조건이 중요한 영역에서는 공식 문서 확인의 우선순위가 높습니다.

API 명칭·설정값·제한 사항이 얽힌 이야기는 공식 문서를 한 번 확인하는 것을 추천합니다.

다음과 같은 처리에서는 보안 관점을 더욱 강력하게 확인해야 합니다.

  • 인증 (Authentication)
  • 인가 (Authorization)
  • 세션 관리 (Session Management)
  • API 공개
  • CORS (Cross-Origin Resource Sharing)
  • 파일 업로드
  • 서명된 URL (Signed URL)
  • SQL
  • 외부 API 연동
  • 로그 출력
  • 권한 설정
  • 클라우드 리소스 생성

AI가 내놓은 코드는 언뜻 동작할 것처럼 보여도 보안 요구사항까지 충족하고 있다고 단정할 수 없습니다.

예를 들어, 다음과 같은 코드는 주의가 필요합니다.

  • 인가 체크가 없음
  • 관리자 권한을 너무 넓게 부여함
  • CORS를 *로 설정함
  • 비밀 정보를 로그로 출력함
  • SQL 인젝션(SQL Injection) 대책이 없음
  • S3 버킷을 공개함
  • IAM 권한이 너무 넓음

'동작하는 것'과 '안전하게 동작하는 것'은 별개입니다.

인증·인가·권한·공개 설정과 관련된 변경은 가능하다면 유식자(Expert)의 리뷰를 거치고, 어려운 경우라도 공식 문서나 기존 구현과의 대조를 더욱 철저히 하는 것이 좋습니다.

AWS와 같은 클라우드 환경에서는 AI에게 물어보며 시도하는 것 자체가 요금으로 이어질 수 있습니다.

특히 주의해야 할 사항은 다음과 같습니다.

  • NAT Gateway: 존재하는 것만으로도 시간당 과금이 발생하기 쉬우며, 통신량에도 주의가 필요함
  • RDS: DB 인스턴스, 스토리지, 백업, 멀티 AZ 구성 등에 따라 요금이 발생함
  • OpenSearch: 검색 기반으로서 강력하지만, 노드 구성이나 스토리지에 따라 요금이 커지기 쉬움
  • ElastiCache: Redis 등을 상시 기동하므로, 검증 용도로 정말 필요한지 확인하고 싶음
  • CloudWatch Logs: 로그 양이나 보관 기간에 따라 요금이 증가함. 과도한 로그 출력에 주의
  • 데이터 전송량: 이미지·동영상·대용량 로그 등을 다룰 경우 통신량에 따른 요금이 발생함
  • 스토리지: S3, EBS, 백업, 로그, 오래된 파일이 계속 남아 있으면 계속 늘어남
  • 빈번하게 실행되는 Lambda: 이벤트 설정이나 재시도(Retry) 설정에 따라 예상보다 많이 실행될 수 있음
  • 정기적으로 실행되는 EventBridge: 실행 간격이 짧으면 호출되는 Lambda나 API의 횟수도 늘어남
  • AI/API 계열의 종량제 서비스: 토큰 양, 이미지 생성 횟수, 재시도, 배치 처리 건수에 따라 요금이 늘어나기 쉬움

AI가 "이 구성으로 만들 수 있습니다"라고 답변하더라도, 그것이 저비용임을 보장하지는 않습니다.

검증용이라면 다음 사항을 확인해 두어야 합니다.

  • 무료 티어(Free Tier) 또는 저비용 범위 내에 들어오는가
  • 필요 없어진 후 삭제할 수 있는가
  • 삭제를 누락하기 쉬운 리소스는 없는가
  • 로그가 계속 늘어나지는 않는가
  • 알람(Alert)이나 예산(Budgets)을 설정해 두었는가

특히 인프라 구성을 AI에게 맡길 경우에는 요금 영향을 더욱 강력하게 확인하는 것이 좋습니다.

"일단 만들어 보자"는 식으로 과금될 수 있는 구성인지는 미리 확인해 두는 것이 안전합니다.

AI가 내놓은 코드에 대해 OSS(Open Source Software)와의 유사성 확인을 매번 전부 수행하는 것은 현실적으로 불가능합니다.

단, 다음과 같은 경우에는 주의하는 것이 좋습니다.

  • 긴 코드를 일괄 생성했을 때
  • 특징적인 알고리즘이 포함되어 있을 때
  • 어딘가의 구현 예시와 닮았을 때
  • 라이브러리 내부 구현에 가까울 때
  • 라이선스 제약이 강한 영역과 관련될 때
  • 그대로 제품의 핵심 기능으로 넣을 때

현실적으로는 리스크가 높은 부분을 중점적으로 확인하는 형태가 될 것이라고 생각합니다.

확인 방법의 예시입니다.

  • 코드 중의 특징적인 함수명이나 주석으로 검색하기
  • AI에게 출처나 참고 원천을 확인하기
  • 공식 샘플 유래인지 확인하기
  • Copilot 등의 공개 코드 일치 검출 기능 이용하기
  • 필요에 따라 사내 규칙에 따르기

일반적인 CRUD 처리, 유효성 검사 (Validation), UI 처리 등 흔히 있는 정형화된 코드까지 매번 엄격하게 조사하는 것은 현장 운용 측면에서 너무 무거울 가능성이 있습니다.

중요한 것은, 리스크가 높은 코드를 식별하는 것입니다.

이 부분은 기술적 판단만으로 종결짓지 않는 것도 중요합니다.

계약 조건이나 고객과의 약정, 사내 규칙에 따라 법무나 보안 담당자에게 확인이 필요할 수 있습니다.

제품의 핵심·차별화 요소·긴 생성 코드는 한 단계 더 신중하게 다루는 것이 안심됩니다.

AI는 설계안을 내놓는 것도 잘합니다.

하지만 업무 시스템의 설계에서는 코드만으로는 판단할 수 없는 정보가 있습니다.

  • 팀의 스킬
  • 운용 체제
  • 기존 시스템과의 정합성
  • 예산
  • 보안 요구사항 (Security Requirements)
  • 유지보수 기간
  • 장애 발생 시의 대응
  • 고객과의 계약 조건

AI는 이러한 전제를 모르는 상태에서 일반론으로서 답변합니다.

따라서 설계 판단을 AI만으로 확정하는 것은 위험합니다.

AI는 선택지를 제시하는 역할로 사용하고, 최종 판단은 인간 측에서 수행해야 합니다.

요건·운용·책임 분계와 관련된 이야기는 AI 안을 그대로 채택하지 않는 것이 좋습니다.

먼저, 업무에서 사용해도 좋은 AI 도구를 결정해 두어야 합니다.

  • ChatGPT
  • GitHub Copilot
  • Claude
  • Gemini
  • Cursor
  • 사내 AI 채팅
  • Microsoft 365 Copilot

등, AI 도구에는 여러 가지가 있습니다.

단, 도구마다 데이터 취급 방식, 계약 조건, 관리 기능이 다릅니다.

사용하는 AI의 계약 형태, 소스 코드를 입력해도 되는지 여부 등은 개인의 판단에 맡기기에는 리스크가 있습니다.

팀 또는 회사 차원에서 입력 가능한 정보를 분류해 두면 운용하기 쉬워집니다.

예:

정보AI 입력
공개 문서OK
...

포인트는 현장 멤버가 망설이지 않을 정도의 입도(Granularity)로 만드는 것입니다.

"기밀 정보는 넣지 않는다"라고만 하면 사람에 따라 판단이 갈릴 가능성이 있습니다.

AI가 내놓은 코드라도 업무 코드에 넣는 시점에서 그 코드에는 책임이 발생합니다.

결정해 두어야 할 사항은 다음과 같습니다.

  • AI 생성 코드를 누가 리뷰할 것인가
  • 어느 수준까지 리뷰를 필수로 할 것인가
  • AI 이용 여부를 PR (Pull Request)에 기재할 것인가
  • AI 생성 부분을 명기할 것인가
  • 버그가 발생했을 경우의 책임 범위를 어떻게 생각할 것인가

AI를 사용했는지 여부와 관계없이, 최종적으로는 인간이 리뷰하고 이해하며 유지보수해야 합니다.

모든 AI 이용을 엄격하게 리뷰하는 것은 부담이 큽니다.

따라서 리뷰 필수 조건을 정하는 것이 현실적입니다.

예:

  • 인증·인가 (Authentication/Authorization)와 관련됨
  • 개인정보를 다룸
  • 과금·결제와 관련됨
  • DB 업데이트를 수행함
  • 클라우드 리소스를 생성함
  • IAM 권한을 변경함
  • 외부 공개 API를 추가함
  • 보안 설정을 변경함
  • 대량 데이터 처리를 수행함
  • 생성된 코드가 길거나 이해할 수 없음

이와 같이 조건을 정해 두면 "AI를 사용했으니 전부 위험하다"가 아니라, "리스크가 높은 변경을 중점적으로 본다"는 운용이 가능해집니다.

개인적으로는 다음과 같은 운용이 현실적이라고 생각합니다.

예:

  • 작은 UI 수정
  • 주석 정리
  • 테스트 데이터 생성
  • README 초안 작성
  • 간단한 타입 정의 (Type Definition)
  • 일반적인 유효성 검사 (Validation)

확인 내용:

  • 차이점 (Diff) 확인
  • 빌드 확인
  • 동작 확인
  • 기존 규칙과의 정합성 확인

예:

  • API 처리
  • DB 액세스
  • 상태 관리 (State Management)
  • 에러 핸들링 (Error Handling)
  • 라이브러리 도입
  • 비동기 처리
  • 외부 서비스 연동

확인 내용:

  • 공식 문서 확인
  • 테스트 추가
  • 이상 계통 (Abnormal Case) 확인
  • 리뷰 요청
  • 기존 설계와의 정합성 확인

예:

  • 인증·인가
  • 권한 설정
  • 개인정보
  • 결제
  • 운영 데이터 업데이트
  • 인프라 구축
  • 클라우드 비용에 영향을 주는 구성
  • 보안 설정
  • 라이선스 영향이 있는 코드

확인 내용:

  • 전문가 리뷰 (Expert Review)
  • 공식 문서 (Official Documentation) 확인
  • 보안 (Security) 관점의 확인
  • 비용 (Cost) 확인
  • 라이선스 (License) 확인
  • 롤백 (Rollback) 절차 확인

업무 개발에서는 AI에게 모든 것을 맡기기보다, 전제 조건과 제약 사항을 명시하는 것이 더 안전합니다.

다음 조건으로 구현안을 제시해 주세요.
- TypeScript로 구현
- any는 사용하지 말 것
...

다음 사항에 대해 조사하고 싶습니다.
- 공식 문서를 우선적으로 확인하고 싶음
- 버전 차이가 있다면 주의점을 제시할 것
...

다음 코드에 대해 리뷰 관점을 도출해 주세요.
- 보안 (Security)
- 유지보수성 (Maintainability)
...

AI에게도 단순히 "무엇을 해주길 바라는지"뿐만 아니라, "어떤 전제하에", "어느 부분에 주의하여" 결과물을 내놓아야 하는지를 작성하는 것이 사용하기 좋은 답변을 얻는 데 유리합니다.

개인적으로 위험하다고 생각하는 것은, AI가 있다면 잘 모르는 분야라도 그대로 진행할 수 있다고 생각하게 되는 점입니다.

실제로는 그 반대입니다. 잘 모르는 분야일수록 AI의 출력을 무비판적으로 수용하기 쉽습니다.

  • 보안 설계 (Security Design)
  • 인증 및 인가 (Authentication/Authorization)
  • 클라우드 구성 (Cloud Configuration)
  • 계약이나 라이선스가 얽힌 판단
  • 장애 대응의 원인 파악 (Troubleshooting)

이러한 영역은 그럴듯한 설명이 돌아오더라도, 그 정답 여부를 판단하기가 매우 어렵습니다.

AI는 전문가의 대체재가 아니라, 전문가의 작업을 빠르게 만드는 도구로서 사용하는 것이 안전하다고 생각합니다.

업무 개발에서 AI를 사용하는 데 있어 중요한 것은 AI를 금지하는 것이 아니라, 어디까지 맡기고 어디서부터 인간이 책임을 질 것인지를 명확히 하는 것입니다.

망설여질 때마다 매번 제로 베이스에서 판단하는 것이 아니라, 리스크에 따른 확인 관점을 팀 단위로 공유해 두면, AI는 편리한 지름길이 아니라 **관리 가능한 개발 지원 도구 (Development Support Tool)**로서 사용하기 쉬워집니다.

최소한 다음 세 가지를 정리해 두면 운영하기 수월합니다.

  • 매번 확인하고 싶은 것
  • 구현 내용에 따라 확인하고 싶은 것
  • 팀 또는 회사 차원에서 정해두고 싶은 것

AI는 편리하지만, 책임까지 대신 져주지는 않습니다.

그렇기에 사용 방법의 전제를 결정한 뒤에 사용하는 것이 중요하다고 생각합니다.

OpenAI Business data privacy, security, and compliance

https://openai.com/business-data/ -
OpenAI Help: How your data is used to improve model performance

https://help.openai.com/en/articles/5722486-how-your-data-is-used-to-improve-model-performance -
GitHub Copilot Best practices

https://docs.github.com/en/copilot/get-started/best-practices -
GitHub Copilot code referencing

https://docs.github.com/en/copilot/concepts/completions/code-referencing -
GitHub Copilot policies

OWASP Top 10 for LLMs and GenAI Apps

AI 자동 생성 콘텐츠

본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
1

댓글

0