AI가 코드 취약점을 찾는 시대, 외주 검수는 뭘 바꿔야 할까요

📰 2026년 7월 30일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.

외주로 받은 코드의 보안, 어떻게 확인하고 계세요? 대부분은 “개발사를 믿는다”에서 멈춰요. 확인할 방법이 마땅치 않았거든요. 그런데 지난주 오픈AI가 코드 취약점을 찾아 고치는 도구를 오픈소스로 풀면서, 이 질문의 답이 조금 달라졌어요.

---

1. 오픈AI가 공개한 건 정확히 무엇일까요

Codex Security CLI라는 명령줄 도구예요. 저장소를 훑어서 보안 취약점을 찾고, 진짜 문제인지 확인한 뒤, 수정안까지 제안해요. 라이선스는 아파치 2.0이라 상업적으로 써도 되고 사내에서 고쳐 써도 돼요.

원래는 사내 코드명 Aardvark로 불리던 실험이었어요. 2026년 3월에 ChatGPT 기업용 요금제 고객을 대상으로 리서치 프리뷰를 열었고, 이번에 소스를 공개하면서 누구나 쓸 수 있게 됐어요. 오픈AI 발표에 따르면 4월까지 3,000건이 넘는 중대 취약점을 고치는 데 쓰였다고 해요.

기능만 놓고 보면 이런 것들이 돼요.

• 저장소 여러 개를 한 번에 스캔
• 실행 결과를 회차별로 비교
• 수정이 실제로 먹혔는지 재검증
• CI/CD 파이프라인에 점검 단계로 끼워 넣기

2. 왜 지금 발주자에게 의미가 있을까요

그동안 코드 보안 점검은 비용 때문에 생략되는 항목이었어요. 상용 정적 분석 도구는 라이선스가 비쌌고, 외부 보안 진단은 별도 계약이라 중소 규모 프로젝트에서는 견적서에서 제일 먼저 지워졌어요.

오픈소스 도구가 나오면 그 계산이 바뀌어요. 스캔 자체에 드는 돈이 사실상 없어지니까, “할지 말지”가 아니라 “언제 몇 번 할지”가 협의 대상이 돼요. 발주자 입장에서는 요구할 근거가 생긴 셈이에요.

실제로 이런 요구는 이제 무리한 게 아니에요. “납품 전에 저장소 스캔 결과를 문서로 주세요”는 개발사가 몇 시간이면 만들 수 있는 산출물이거든요.

3. 그래도 찾는 일과 고치는 일은 달라요

여기서 오해가 자주 생겨요. 도구가 취약점을 찾아준다는 말은 목록을 만들어준다는 뜻이지, 안전해진다는 뜻이 아니에요.

스캔 결과에는 실제 위험과 오탐이 섞여 나와요. 어떤 항목은 우리 서비스 구조에서는 도달할 수 없는 경로라 무시해도 되고, 어떤 항목은 등급이 낮게 나왔지만 우리 데이터 성격상 심각해요. 이걸 가르는 건 서비스를 아는 사람이에요.

재미있는 사실도 하나 있어요. 2025년 8월에 Codex CLI 자체에서 명령어 주입 취약점이 발견돼 제보를 받고 수정한 적이 있어요. 보안 도구도 코드라서 점검 대상이라는 이야기예요. 도구를 붙였다는 사실만으로 안심하기 어려운 이유가 여기 있어요.

4. 외주 계약에서 바뀌어야 할 세 가지

도구가 흔해진 만큼 계약서에 적을 말도 달라져야 해요. 저희가 실제 프로젝트에서 쓰는 기준은 세 가지예요.

항목	예전 표현	지금 권하는 표현
점검 여부	”보안에 유의하여 개발한다"	"납품 전 저장소 정적 점검을 수행하고 결과 목록을 제출한다”
조치 기준	(없음)	“중대 등급은 검수 전 조치, 나머지는 미조치 사유를 문서로 남긴다”
재검증	(없음)	“하자보수 기간 내 동일 점검을 1회 이상 재수행한다”

핵심은 도구 이름을 지정하지 않는 거예요. 도구는 반년마다 바뀌지만 산출물 형식은 오래 쓰여요. 무엇을 어떤 형태로 받을지만 적어두면 개발사가 어떤 도구를 쓰든 검수가 가능해요.

이 부분은 개발 외주 검수 절차와 기준 체크리스트에서 더 자세히 다뤘어요.

5. 도구를 붙일 때 실제로 드는 비용

오픈소스라고 해서 공짜로 끝나지는 않아요. 이런 도구는 대부분 모델 호출로 동작해서, 저장소 크기와 실행 빈도만큼 API 사용료가 붙어요.

여기서 ai 모델링 최적화 비용이라는 말이 나오는데, 실무에서는 훨씬 단순한 이야기예요. 매 커밋마다 전체 저장소를 훑으면 요금이 빠르게 올라가니까, 변경된 부분만 보게 하거나 실행 주기를 하루 한 번으로 줄이는 식으로 조정해요. 이 조정만 해도 비용 차이가 몇 배로 벌어져요.

발주 단계에서는 누가 이 요금을 내는지를 정해두는 게 좋아요. 개발사 계정으로 돌리면 계약이 끝나는 순간 점검도 멈춰요. 서버·인프라 항목과 함께 다루는 게 편해서, 개발 외주 서버·인프라 비용 정리를 참고하셔도 좋아요.

6. 운영해보면 알게 되는 것

저희는 자체 SaaS 4종을 직접 운영해요. 그러면서 확실해진 게 하나 있어요. 취약점은 만드는 동안보다 운영하는 동안 더 많이 생겨요.

코드는 그대로인데 쓰던 라이브러리에서 문제가 발견되기도 하고, 서버 운영체제가 올라가면서 설정이 어긋나기도 해요. 기능을 하나 붙였을 뿐인데 외부에 열린 경로가 늘어나는 경우도 있고요. 납품 시점에 깨끗했다는 사실이 반년 뒤를 보장하지 않아요.

그래서 저희는 검수 항목보다 점검 주기를 더 중요하게 봐요. 오픈 전에 한 번 하고 끝내는 점검과, 분기마다 같은 기준으로 다시 돌려보는 점검은 결과가 완전히 달라져요. 자동화 도구가 싸질수록 이 차이를 만들기 쉬워졌다는 게 이번 소식의 진짜 의미라고 생각해요.

7. 발주 전에 정해두면 좋은 네 가지

복잡하게 갈 필요는 없어요. 네 가지만 정하고 시작하셔도 충분해요.

1. 점검 시점 — 납품 전 1회, 하자보수 기간 내 1회를 기본으로 잡아요.
2. 산출물 형식 — 발견 항목, 등급, 조치 여부, 미조치 사유가 들어간 문서로 받아요.
3. 계정 소유 — 점검 도구와 API 계정은 발주사 명의로 만들어요.
4. 판단 주체 — 어떤 항목을 고치고 어떤 항목을 넘길지 최종 판단은 발주사가 해요.

네 번째가 특히 중요해요. 개발사가 알아서 판단하면 나중에 “왜 이건 안 고쳤나요”라는 질문에 답할 근거가 남지 않아요.

AI 도구를 어디부터 붙일지 정하는 단계라면 AI 도입 비용 구조와 시작점도 함께 보시면 그림이 잡혀요.

8. 자주 묻는 질문

ai 자체 도입과 외주 개발 중 어떤 선택이 맞나요?

보안 점검 도구처럼 도입 범위가 좁고 결과가 바로 확인되는 영역은 자체 도입이 빨라요. 저장소에 붙여 한 번 돌려보면 며칠 안에 판단이 서거든요. 반대로 기존 시스템 데이터와 엮이거나 여러 부서가 함께 쓰는 기능은 함께 개발하는 쪽이 안전해요. 기준은 회사 규모가 아니라 연동 범위예요.

AI 도구가 취약점을 잡아주면 보안 점검 비용을 줄일 수 있나요?

스캔 비용은 줄어요. 다만 줄어드는 건 찾는 비용이지 고치는 비용이 아니에요. 도구가 올린 항목을 읽고 판단하고 수정 뒤 다시 검증하는 일은 사람 몫이에요. 예산을 깎기보다 점검 횟수를 늘리는 데 쓰시는 편이 효과가 분명해요.

이미 납품받은 프로젝트에도 적용할 수 있나요?

가능해요. 소스코드를 넘겨받았다면 지금이라도 저장소에 돌려볼 수 있어요. 다만 조치는 다른 문제예요. 유지보수 계약이 없으면 수정 작업이 신규 견적으로 잡히니까, 점검부터 하고 결과를 근거로 범위를 협의하는 순서가 현실적이에요.

9. 마무리

도구가 싸지면 기준이 올라가요. 예전에는 요구하기 어려웠던 보안 점검이 이제는 견적서 한 줄로 정리되는 항목이 됐어요. 발주하는 쪽에서 먼저 물어보시면 개발사도 준비하고 들어와요.

코드 보안을 어디까지 요구해야 할지, 지금 진행 중인 프로젝트에 무엇부터 적용할지 정리가 필요하시면 운영까지 해본 개발사와 편하게 이야기 나눠보세요 →

저희는 10년 넘게 50개 이상의 프로젝트를 진행하면서 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 만드는 단계보다 운영 단계에서 무엇이 문제가 되는지 겪어봤기 때문에, 검수 기준을 짤 때 실제로 쓰이는 항목만 골라드릴 수 있어요.

---

관련 글

• 개발 외주 검수, 어떻게 해야 분쟁이 줄어들까요
• 개발 견적서, 어떤 항목이 빠지면 나중에 돈이 더 들까요
• 외주 계약서, 어떤 조항이 빠지면 나중에 문제될까요