AI 도구에서 말하는 아티팩트의 의미

etc · 8월 29일 · 31 min read

요즘 codex 같은 AI를 사용하다보면 아티팩트라는 단어가 자주 등장합니다.
코드를 수정할 때도, 문서나 이미지를 만들 때도, 빌드 결과를 확인할 때도 같은 단어가 쓰인다.
낯선 전문 용어처럼 보이지만 핵심은 의외로 단순하다.

이 글에서는 AI 작업의 아티팩트를 특정 과정에서 만들어지거나 그 과정의 증거로 남아, 이후 검토·전달할 수 있는 결과물로 이해한다.

아티팩트의 기본 의미

artifact의 원래 뜻은 사람이 만든 물건이나 흔적에 가깝다.
소프트웨어 작업에서는 의미가 조금 더 구체적이다.
작업 중에 생성되고, 정보를 담아 저장·검토·전달할 수 있는 산출물을 아티팩트라고 부른다.

NIST CSRC 용어집에는 문맥에 따른 여러 정의가 있다.
그중 시스템 엔지니어링 문맥에서는 아티팩트를 정보를 담고 전달하기 위해 프로젝트에서 만들고 사용하는 작업 산출물로 설명하며, 모델과 소스 코드를 예로 든다.
이 정의를 넓게 적용하면 계획서와 분석 보고서도 포함할 수 있고, GitHub Actions 문서에서는 로그·테스트 결과·스크린샷도 대표 아티팩트로 다룬다.
최종 납품물만을 가리키는 말이 아니라는 점이 중요하다.
초안이나 로그, 스크린샷처럼 작업의 흔적과 근거로 남는 파일도 아티팩트가 될 수 있다.

아티팩트 = 작업 과정이 남긴, 다시 확인할 수 있는 결과물

문맥에 따른 의미 차이

아티팩트가 어렵게 느껴지는 이유는 분야마다 가리키는 범위가 다르기 때문이다.

문맥	주로 가리키는 것	대표 예시
AI 에이전트	대화를 통해 생성하거나 수정한 결과물	코드, 문서, 스프레드시트, 이미지, HTML 파일
CI/CD	워크플로가 실행되며 만든 파일	빌드 번들, 바이너리, 테스트 보고서, 로그
소프트웨어 공급망	불변 데이터 객체와 그 출처 정보	파일, Git 커밋, 직렬화된 디렉터리, 컨테이너 이미지
영상·음향	기술 처리 과정에서 생긴 원하지 않는 왜곡	압축 블로킹, 스캔 얼룩, 음원 왜곡

AI 에이전트

주로 가리키는 것: 대화를 통해 생성하거나 수정한 결과물
대표 예시: 코드, 문서, 스프레드시트, 이미지, HTML 파일

CI/CD

주로 가리키는 것: 워크플로가 실행되며 만든 파일
대표 예시: 빌드 번들, 바이너리, 테스트 보고서, 로그

소프트웨어 공급망

주로 가리키는 것: 불변 데이터 객체와 그 출처 정보
대표 예시: 파일, Git 커밋, 직렬화된 디렉터리, 컨테이너 이미지

영상·음향

주로 가리키는 것: 기술 처리 과정에서 생긴 원하지 않는 왜곡
대표 예시: 압축 블로킹, 스캔 얼룩, 음원 왜곡

따라서 단어만 보고 의미를 고정하면 안 된다.
어떤 과정에서 무엇이 남았는지를 함께 봐야 한다.

AI 도구에서의 아티팩트

대화형 AI의 답변은 흔히 대화창 안의 텍스트로 제공된다.
Codex 같은 도구는 여기에 더해 파일을 만들고, 실제 프로젝트를 수정하고, 실행 결과를 보여준다.
이때 대화의 설명과 구분되는 구체적인 결과물을 아티팩트라고 부르는 경우가 많다.
다만 제품마다 이 용어를 쓰는 범위가 다르므로, 이 글에서는 대화와 구분해 검토할 수 있는 파일과 결과물을 중심으로 설명한다.

OpenAI 공식 문서에 따르면 ChatGPT 데스크톱 앱은 생성된 문서, 프레젠테이션, 스프레드시트, PDF를 대화 옆에서 미리 보여준다.
HTML 미리보기가 지원되는 환경에서는 렌더링 화면과 소스를 전환해 볼 수 있다.
반면 Codex CLI는 작업 디렉터리의 파일을 만들고 편집할 수 있지만 시각적 미리보기나 주석 인터페이스는 없다.
따라서 출력 경로와 실행한 검증을 보고하도록 요청하는 편이 좋다.
즉 AI 문맥의 아티팩트는 새로 생긴 완전히 별개의 개념이 아니다.
기존 소프트웨어 용어를 가져와 대화가 실제 작업물로 바뀐 부분을 가리키는 데 쓰는 것에 가깝다.

대화 응답과 아티팩트의 차이

대화 응답은 주로 무엇을 했는지 설명한다.
아티팩트는 실제로 열어 검토하고, 저장하거나 다음 작업에 넘길 수 있는 대상이다.
이 구분은 실무를 위한 기준이지 고정된 경계는 아니다.
아티팩트가 반드시 편집 가능해야 하는 것은 아니며, 대화 안의 보고서나 코드도 독립된 검토 결과로 다뤄지면 아티팩트가 될 수 있다.

예를 들어 AI가 “README.md를 수정했습니다”라고 말한 문장은 대화 응답이다.
실제로 바뀐 README.md는 작업의 주요 아티팩트고, 저장된 diff나 리뷰 기록은 검증 근거 아티팩트가 될 수 있다.
대화창의 코드 블록도 단순한 예시라면 설명의 일부일 수 있다.
반면 독립된 파일로 저장되고 미리보기나 다운로드 대상이 됐다면 아티팩트에 가깝다.
확장자보다 해당 결과물이 어떻게 다뤄지는지가 기준이 된다.

Codex 작업의 대표 예시

요청	주요 아티팩트	검증 근거
README 수정	수정된 `README.md`	diff, 링크 검사
웹 화면 제작	컴포넌트, CSS, HTML	빌드 결과, 브라우저 미리보기·스크린샷
데이터 분석	CSV, 스프레드시트, 차트	원본 데이터, 수식 검사
이미지 제작	PNG, JPG	크기·형식 확인, 시각 검토
프로젝트 빌드	`out`, `dist`, 실행 파일	빌드 로그, 테스트 보고서

README 수정

주요 아티팩트: 수정된 README.md
검증 근거: diff, 링크 검사

웹 화면 제작

주요 아티팩트: 컴포넌트, CSS, HTML
검증 근거: 빌드 결과, 브라우저 미리보기·스크린샷

데이터 분석

주요 아티팩트: CSV, 스프레드시트, 차트
검증 근거: 원본 데이터, 수식 검사

이미지 제작

주요 아티팩트: PNG, JPG
검증 근거: 크기·형식 확인, 시각 검토

프로젝트 빌드

주요 아티팩트: out, dist, 실행 파일
검증 근거: 빌드 로그, 테스트 보고서

주요 아티팩트와 검증 근거는 구분해서 봐야 한다.
테스트 로그와 스크린샷도 넓은 의미에서는 아티팩트이지만, 사용자가 원한 결과물과 그 결과를 뒷받침하는 근거는 역할이 다르다.

소스와 아티팩트의 관계

한 번의 AI 작업만 놓고 보면 소스를 입력물로, 이번 작업이 새로 만들거나 수정한 결과를 아티팩트로 구분하면 이해하기 쉽다.
하지만 이 구분은 파일의 고정된 속성이 아니라 작업 문맥에서의 역할이다.

원본 README.md는 AI에게 제공한 소스다.
수정 작업이 끝난 뒤의 같은 README.md는 이번 작업의 아티팩트다.
그 파일을 다음 작업에 다시 입력으로 주면 소스가 된다.
SLSA에서는 Git 커밋처럼 사람이 직접 작성하거나 검토한 불변 소스 객체도 아티팩트의 한 종류로 다룬다.
중요한 것은 파일에 영원한 이름표를 붙이는 것이 아니라 현재 과정에서 무슨 역할을 하는지 파악하는 일이다.

빌드 아티팩트와 AI 아티팩트의 차이

빌드 아티팩트는 보통 컴파일, 번들링, 패키징 과정의 출력을 가리킨다.
JavaScript 프로젝트의 dist 디렉터리, Java의 JAR, 컨테이너 이미지가 대표적이다.

GitHub Actions가 말하는 워크플로 아티팩트는 이보다 범위가 넓다.
공식 문서는 이를 워크플로 실행 중에 만들어진 파일이나 파일 묶음으로 정의한다.
빌드 바이너리만이 아니라 로그, 테스트 결과, 실패 정보와 스크린샷, 코드 커버리지도 대표 예시로 든다.
업로드하면 작업이 끝난 뒤에도 저장하거나 같은 워크플로의 다른 작업으로 전달할 수 있다는 점이 핵심이다.

AI 아티팩트는 범위가 더 넓다.
빌드를 거치지 않은 Markdown 문서나 이미지, 차트, 프로토타입도 포함할 수 있다.
두 용례의 공통점은 “과정에서 만들어져 확인과 재사용의 대상이 된 결과물”이라는 점이다.

생성과 완료의 구분

아티팩트가 존재한다는 사실은 작업이 검증되거나 배포됐다는 뜻이 아니다.
파일을 만드는 단계와 실제로 쓸 수 있는 상태를 확인하는 단계는 다르다.

생성됨 ≠ 검증됨 ≠ 커밋됨 ≠ 배포됨

코드 파일이 생겼어도 테스트는 실패할 수 있다.
빌드 아티팩트가 있어도 Git에 커밋되지 않았을 수 있다.
커밋이 원격 저장소에 올라가도 운영 배포는 실패했을 수 있다.
이 상태를 하나로 묶어 “완료”라고 표현하면 AI 작업을 과신하기 쉽다.

아티팩트 확인 기준

AI가 아티팩트를 만들었다고 할 때는 다음 순서로 확인한다.

실제 파일 경로나 다운로드 링크를 확인한다.
파일을 열어 내용과 렌더링 상태를 직접 본다.
코드라면 diff와 테스트, 문서라면 레이아웃, 데이터라면 수식과 출처를 검증한다.
임시 초안과 최종 버전을 구분하고 가장 최신 결과인지 확인한다.
커밋, 푸시, 배포 여부를 각각 따로 확인한다.
비밀 키, 개인정보, 내부 경로가 결과물에 포함되지 않았는지 점검한다.

출력 경로와 검증 결과를 함께 요청하는 습관만 들여도 대화와 실제 작업물을 헷갈리는 일이 줄어든다.

결함을 뜻하는 아티팩트

이미지나 음향 문맥에서는 아티팩트가 기술 처리 과정에서 생긴 부산물이나 인위적인 특징을 뜻하며, 보통은 원하지 않는 왜곡으로 나타난다.
압축 이미지의 네모난 블록, 스캔 이미지의 반점, 과포화된 오디오의 왜곡이 예다.
AI 이미지의 어색한 손가락이나 무너진 문자 같은 오류도 시각적 아티팩트라고 부르기도 한다.

따라서 “AI 아티팩트”라는 표현을 보면 먼저 문맥을 확인해야 한다.
파일이나 미리보기를 말한다면 결과물이고, 화질과 음질을 말한다면 왜곡일 가능성이 높다.