데이터 분석 업무를 AI 에이전트에게 맡긴다고 하면 많은 사람이 먼저 이런 장면을 떠올린다. CSV 파일을 던져 주면 그래프를 만들고, 수치를 해석하고, 인사이트를 뽑아내는 모습 말이다. 하지만 실제 현장에서 분석이 흔들리는 지점은 해석의 화려함보다 훨씬 앞에 있다. 파일 인코딩이 뒤섞여 있고, 날짜 형식이 제각각이며, 매출 단위가 원인지 천 원인지도 불분명하고, 누락값을 0으로 봐야 할지 비어 있는 값으로 봐야 할지도 정해져 있지 않다. 이 상태에서 아무리 똑똑한 모델을 써도 결과는 들쑥날쑥해진다.
데이터 분석 Skill의 핵심은 그래서 의외로 소박하다. 먼저 데이터를 같은 방식으로 읽고, 같은 방식으로 정리하고, 같은 순서로 살펴보게 만드는 것이다. 분석 Skill은 천재적인 해석을 복제하는 도구가 아니라, 흔들리지 않는 분석 절차를 설치하는 장치에 가깝다. 사람이 바뀌어도, 파일이 조금 달라져도, 모델이 바뀌어도 최소한의 일관성을 유지하게 만드는 것. 바로 그 점에서 데이터 분석 업무는 Skill로 만들 가치가 크다.
데이터 분석 Skill이 필요한 이유
정형 데이터 분석은 겉으로 보기에는 자유로운 탐색 작업처럼 보이지만, 실제로는 반복되는 공정이 많다. 파일을 열고, 컬럼을 확인하고, 타입을 맞추고, 누락값을 점검하고, 이상치를 확인하고, 요약 통계를 만들고, 적절한 시각화를 고르고, 마지막으로 결과를 설명하는 흐름은 대체로 비슷하다. 문제는 이 흐름이 암묵지로 남아 있는 경우가 많다는 데 있다.
예를 들어 같은 매출 데이터를 두 분석가에게 주면 한 사람은 취소 거래를 제외하고, 다른 사람은 포함할 수 있다. 한 사람은 결측치를 0으로 채우고, 다른 사람은 해당 행을 삭제할 수 있다. 한 사람은 월별 합계를 보고, 다른 사람은 주별 평균을 볼 수 있다. 둘 다 나름의 이유는 있지만, 조직 관점에서는 결과가 재현되지 않는다. 같은 입력에 대해 같은 규칙이 적용되지 않기 때문이다.
그래서 분석 Skill은 이렇게 묻는다. "이 데이터는 어떤 순서로 점검해야 하는가?", "어떤 값은 무조건 경고해야 하는가?", "어떤 차트를 우선 선택해야 하는가?", "최종 보고서에는 어떤 문장을 반드시 넣어야 하는가?" 이 질문에 답하는 순간, 분석은 감각의 영역에서 운영 가능한 시스템의 영역으로 옮겨간다.
분석 Skill은 해석보다 절차를 먼저 고정한다
많은 팀이 데이터 분석 Skill을 만들 때 처음부터 고급 분석 기법을 넣으려 한다. 예측 모델, 군집 분석, 상관관계 탐지, 자동 인사이트 생성 같은 요소들이다. 물론 이런 기능도 중요하다. 하지만 기초 절차가 불안정하면 그 위에 쌓이는 모든 해석이 모래성처럼 흔들린다.
좋은 분석 Skill은 먼저 다음 네 가지를 고정한다.
데이터를 어떻게 읽을지
데이터를 어떻게 정제할지
데이터를 어떤 순서로 요약할지
결과를 어떤 형식으로 설명할지
이 네 가지가 정리되면, 그다음에야 통계 기법이나 시각화 자동화, 도메인별 분석 규칙을 얹을 수 있다. Skill 설계에서 중요한 것은 모델이 "생각을 잘하게 만드는 것"이 아니라, "헷갈리지 않게 일하게 만드는 것"이다.
CSV, Excel, 로그 파일의 공통 입력 전처리 절차
파일 형식은 달라도, 정형 데이터 분석의 첫 단계는 놀랄 만큼 비슷하다. CSV든 Excel이든 로그 파일이든 일단 같은 질문부터 던져야 한다. 이 파일은 정상적으로 읽혔는가? 컬럼 구조는 예상과 맞는가? 날짜와 숫자는 진짜 그 타입인가? 값의 범위는 상식적인가?
데이터 분석 Skill에서는 입력 전처리 절차를 먼저 공통 단계로 묶어 두는 것이 좋다. 예를 들면 다음과 같은 순서다.
파일 읽기: 인코딩, 시트 선택, 구분자, 헤더 존재 여부 확인
스키마 확인: 컬럼명, 컬럼 수, 데이터 타입, 필수 컬럼 존재 여부 확인
값 정리: 공백 제거, 중복 행 점검, 날짜 형식 통일, 숫자형 변환
기본 진단: 행 수, 기간 범위, 고유값 수, 누락 비율, 음수 여부 같은 기본 상태 점검
이 순서를 Skill에 명시해 두면 에이전트는 파일이 들어올 때마다 곧바로 해석으로 뛰어들지 않고 먼저 기반부터 점검한다. 이 차이가 매우 크다. 사람이 급할 때 가장 많이 건너뛰는 단계가 바로 전처리인데, Skill은 그 생략을 막아 준다.
CSV 분석에서는 특히 구분자와 인코딩 문제가 잦다. 쉼표로 나뉜 줄 알았는데 실제로는 세미콜론인 경우도 있고, 숫자 컬럼에 쉼표가 들어가 문자형으로 읽히는 경우도 많다. Excel은 더 교묘하다. 여러 시트 중 어느 시트가 기준인지 모호할 수 있고, 첫 행이 제목인지 데이터인지 헷갈리기 쉽다. 로그 파일은 시간 형식과 이벤트 단위가 일정하지 않아서 전처리 규칙 없이는 분석이 바로 무너진다.
그래서 Skill은 파일별 세부 규칙을 달리 두더라도, 공통적으로 "읽기 → 구조 확인 → 타입 정리 → 상태 점검"의 순서를 강제해야 한다. 이 공통 뼈대가 있어야 이후 분석 단계도 흔들리지 않는다.
입력 전처리에서 꼭 고정해야 할 질문들
전처리는 단순히 데이터를 깨끗하게 만드는 작업이 아니다. 무엇을 정상으로 볼 것인지 정의하는 과정이다. 그래서 Skill에는 전처리 단계에서 에이전트가 반드시 답해야 할 질문을 넣어 두는 편이 좋다.
예를 들어 이런 질문들이다.
분석 대상 기간은 무엇인가?
필수 컬럼은 모두 존재하는가?
숫자 컬럼에 문자, 통화 기호, 단위 표기가 섞여 있는가?
날짜 컬럼은 하나의 형식으로 통일 가능한가?
중복 행은 오류인가, 정상 이력인가?
비어 있는 값은 누락인가, 해당 없음인가, 0인가?
이 질문을 미리 정해 두면 에이전트는 데이터를 볼 때마다 즉흥적으로 판단하지 않는다. 그리고 바로 여기서 분석 품질의 일관성이 생긴다. 데이터 분석에서 가장 위험한 실수는 어려운 통계를 틀리는 것이 아니라, 단순한 전제 조건을 매번 다르게 적용하는 것이다.
이상치, 누락값, 단위 변환은 규칙으로 다뤄야 한다
분석 결과가 조직에서 신뢰받지 못하는 이유 중 하나는 예외를 처리하는 방식이 사람마다 다르기 때문이다. 누군가는 지나치게 큰 값을 제거하고, 누군가는 남겨 둔다. 누군가는 결측치를 평균으로 채우고, 누군가는 행 전체를 삭제한다. 누군가는 kg를 g로 바꾸고, 누군가는 원 단위를 천 원 단위로 표시한다. 분석가 입장에서는 사소해 보여도, 의사결정자 입장에서는 결과가 달라지는 중요한 문제다.
좋은 분석 Skill은 이상치, 누락값, 단위 변환을 감으로 처리하지 않게 만든다. 규칙이 명시되어 있어야 한다.
이상치를 다루는 기준
이상치는 단순히 큰 값이 아니다. 맥락에서 벗어난 값이다. 그래서 Skill에는 "무조건 삭제" 같은 지침보다, 이상치 후보를 식별하고 처리 방식을 구분하는 규칙이 필요하다.
예를 들면 이런 식이다.
물리적으로 불가능한 값은 오류 후보로 표시한다. 예: 음수 수량, 존재할 수 없는 날짜
극단적으로 큰 값은 자동 삭제하지 말고 원자료와 함께 검토 대상으로 남긴다
집계 리포트에서는 이상치 포함 결과와 제외 결과를 분리해 보여 줄 수 있다
도메인상 프로모션, 이벤트, 장애일처럼 설명 가능한 급변은 이상치가 아니라 사건으로 취급한다
중요한 점은 이상치를 없애는 기술보다, 이상치를 어떻게 취급했는지 기록하는 습관이다. 분석 Skill에는 "이상치 처리 내역을 로그에 남긴다"는 문장을 반드시 넣는 것이 좋다.
누락값을 다루는 기준
누락값은 생각보다 위험하다. 비어 있다는 사실 자체가 정보일 수 있기 때문이다. 고객 전화번호가 비어 있는 것은 단순 누락일 수 있지만, 해지 사유가 비어 있는 것은 아직 해지하지 않았다는 뜻일 수도 있다. 그러므로 Skill은 결측치를 일괄 처리하지 말고 의미별로 나누게 해야 한다.
실무에서 쓸 만한 기본 규칙은 다음과 같다.
식별자, 날짜, 금액처럼 핵심 컬럼의 결측치는 우선 경고한다
계산에 필요한 값이 비어 있으면 자동 보정 전에 사용자 승인 또는 규칙 확인 단계를 둔다
범주형 컬럼은 "미입력", "해당 없음", "알 수 없음"을 구분할 수 있으면 분리한다
결측치 대체를 했을 경우 대체 방식과 대상 행 수를 결과에 함께 남긴다
이 규칙이 없으면 에이전트는 보기 좋게 표를 채워 버릴 수 있다. 하지만 보기 좋은 표와 믿을 수 있는 표는 다르다.
단위 변환을 다루는 기준
단위 문제는 조용하지만 치명적이다. 원과 달러, 초와 분, kg와 g, 퍼센트와 비율값이 뒤섞이면 그래프는 그럴듯해 보여도 의미는 완전히 달라진다. 데이터 분석 Skill은 단위 변환을 후처리 장식으로 다루지 말고, 전처리 핵심 단계에 넣어야 한다.
단위 관련 규칙은 최소한 다음을 포함해야 한다.
원본 단위를 먼저 확인하고 변환 전 값을 보존할 것
변환 기준을 명시할 것. 예: 초를 분으로 변환, 0.12를 12%로 표시
서로 다른 단위가 한 컬럼에 섞여 있으면 자동 집계하지 말고 분리 검토할 것
최종 표와 차트의 단위 표기를 제목이나 축 이름에 반드시 넣을 것
단위가 빠진 차트는 숫자는 많아도 정보는 적다. 에이전트가 만든 리포트에서 가장 흔한 실수 중 하나가 바로 이 단위 생략이다.
분석 절차를 네 단계로 나누기
데이터 분석 Skill은 분석 과정을 하나의 덩어리로 쓰기보다 단계별로 분해해야 한다. 그래야 에이전트가 어디까지 했는지 추적할 수 있고, 오류가 났을 때도 어느 단계에서 흔들렸는지 찾기 쉽다. 가장 실용적인 구조는 탐색, 정제, 요약, 시각화의 네 단계다.
1단계: 탐색
탐색은 데이터를 처음 만나는 단계다. 이 단계의 목적은 인사이트를 내는 것이 아니라, 데이터의 성격을 파악하는 것이다. 몇 행인지, 어떤 컬럼이 있는지, 날짜 범위는 어디부터 어디까지인지, 어떤 값들이 많이 등장하는지, 이상해 보이는 패턴은 없는지 확인한다.
탐색 단계에서 Skill이 요구해야 할 기본 출력은 다음과 같다.
데이터셋 개요: 행 수, 열 수, 기간 범위
컬럼 요약: 컬럼명, 타입, 설명 가능한 경우 의미 추정
기초 분포: 숫자형의 최소값, 최대값, 평균, 중앙값
품질 경고: 결측치, 중복, 비정상 형식, 단위 혼합 가능성
이 단계에서는 섣부른 결론을 내리지 않도록 지침을 넣는 것이 중요하다. 예를 들어 "탐색 단계에서는 인과 해석을 하지 말고 상태 진단에 집중하라" 같은 문장이 유용하다. 데이터 분석 Skill이 자꾸 오버해서 해석하는 문제는 대부분 이 초반 단계에서 시작된다.
2단계: 정제
정제는 탐색에서 발견한 문제를 규칙에 따라 바로잡는 단계다. 공백을 제거하고, 날짜를 통일하고, 숫자형을 변환하고, 잘못된 레코드를 분리하고, 필요한 파생 변수를 만드는 작업이 여기에 들어간다.
중요한 점은 정제를 조용히 하지 않는 것이다. 사람이 분석할 때도 그렇지만, 에이전트는 특히 더 많은 일을 자동으로 해 버릴 수 있다. 그래서 Skill에는 "정제 작업은 모두 기록한다"는 원칙이 필요하다.
정제 단계의 기록 예시는 이렇다.
주문일 컬럼의 날짜 형식을 YYYY-MM-DD로 통일함
금액 컬럼에서 쉼표와 통화 기호를 제거한 후 숫자형으로 변환함
수량이 0보다 작은 12개 행을 오류 후보로 분리함
국가명이 서로 다른 표기로 입력된 값을 표준 표기로 통일함
이 로그가 있어야 이후 누가 분석을 다시 보더라도 결과가 어떻게 만들어졌는지 따라갈 수 있다. 재현 가능한 분석은 결국 재현 가능한 정제 기록에서 시작된다.
3단계: 요약
요약은 정제된 데이터를 바탕으로 질문에 답하는 단계다. 월별 매출 합계, 제품군별 평균 객단가, 고객군별 이탈률, 지역별 문의 건수처럼 의사결정에 필요한 집계가 여기서 만들어진다.
이 단계에서 Skill은 단순히 "요약하라"고 쓰면 안 된다. 무엇을 기준으로 자를지, 어떤 집계 함수를 우선 쓸지, 비교 기준은 무엇인지까지 정해 줘야 한다. 예를 들면 다음과 같다.
시간 축이 있으면 먼저 일, 주, 월 중 어떤 단위를 기본으로 볼지 정한다
금액 데이터는 합계와 평균을 함께 보되, 건수 차이가 큰 경우 중앙값도 검토한다
범주 비교에서는 상위 항목과 기타 항목을 구분해 지나치게 긴 표를 피한다
비율 지표는 분모가 충분히 큰지 확인한 뒤 해석한다
요약 단계에서 흔한 문제는 숫자를 모으기만 하고 맥락을 잃는 것이다. Skill은 단순 집계가 아니라 "질문에 답하기 위한 요약"이 되게 만들어야 한다. 그래서 가능하면 요약 단계 시작 부분에 "분석 질문"을 다시 적도록 하는 것도 좋다.
4단계: 시각화
시각화는 결과를 예쁘게 꾸미는 마지막 장식이 아니다. 비교와 변화, 분포와 관계를 더 빨리 읽게 만드는 분석의 일부다. 그러나 많은 에이전트가 차트를 만들 때 가장 그럴듯해 보이는 형태를 무작정 고른다. 그래서 데이터 분석 Skill에는 차트 선택 기준이 꼭 들어가야 한다.
차트는 멋보다 목적이 우선이다. 시간 흐름을 보여 주고 싶은지, 항목 간 크기를 비교하고 싶은지, 값의 분포를 보고 싶은지, 변수 간 관계를 보려는지에 따라 선택이 달라진다. 이 원칙을 Skill에 명문화해 두면 엉뚱한 시각화를 크게 줄일 수 있다.
차트와 표의 선택 기준
좋은 분석 Skill은 에이전트가 "아무 차트나" 만들지 못하게 한다. 다음처럼 선택 기준을 고정해 둘 수 있다.
시간에 따른 변화는 선 그래프를 우선 사용한다
적은 수의 범주 비교는 막대 그래프를 우선 사용한다
비중 비교는 범주 수가 적을 때만 원형 계열을 제한적으로 사용한다
분포 확인은 히스토그램이나 상자 그림을 사용한다
두 수치형 변수의 관계는 산점도를 사용한다
상세 수치를 정확히 읽어야 할 때는 차트보다 표를 우선한다
여기서 중요한 것은 "우선"이라는 표현이다. 무조건 한 종류만 쓰라는 뜻이 아니다. 다만 에이전트가 매번 제멋대로 고르지 않게 기본 선택지를 제공하는 것이다.
표를 사용할 때도 기준이 필요하다. 표는 정확하지만 길어지기 쉽고, 차트는 직관적이지만 수치를 숨긴다. 그래서 Skill에는 "핵심 비교는 차트로, 원자료 확인은 표로" 같은 원칙을 넣을 수 있다. 경영진 보고용이면 핵심 수치 몇 개만 담긴 요약 표가 맞고, 실무 검토용이면 상세 표가 필요할 수 있다. 독자에 따라 출력 형식을 다르게 하는 규칙까지 포함되면 Skill의 완성도가 높아진다.
설명 문구도 템플릿으로 고정할 수 있다
많은 사람이 분석은 숫자와 그래프의 일이라고 생각하지만, 실제로 결과물의 품질을 가르는 것은 설명 문장이다. 같은 그래프를 두고도 어떤 에이전트는 "증가했습니다"라고만 쓰고, 어떤 에이전트는 "3월 이후 증가세가 이어졌지만 6월에는 일시 하락이 있었고, 이는 프로모션 종료 시점과 겹칩니다"처럼 맥락 있게 설명한다.
이 차이를 줄이기 위해 설명 문구도 Skill에 템플릿으로 넣을 수 있다. 템플릿은 글을 기계적으로 만들기 위한 것이 아니라, 중요한 요소가 빠지지 않게 하기 위한 안전장치다.
예를 들어 차트 설명 템플릿은 이렇게 만들 수 있다.
무엇을 보여 주는지: "이 그래프는 [기간] 동안의 [지표] 변화를 보여 준다."
핵심 변화: "전체적으로 [증가/감소/유지] 추세를 보이며, 특히 [시점]에 [특징]이 나타난다."
해석 주의: "다만 [누락값/이상치/표본 수 제한] 때문에 해석에는 주의가 필요하다."
다음 질문: "추가 확인이 필요하다면 [세부 구간/세그먼트/원인 변수]를 함께 분석한다."
표 설명 템플릿도 유용하다.
"이 표는 [기준]별 [지표]를 요약한 것이다."
"상위 항목은 [결과]를 보였고, 하위 항목과의 격차는 [의미]를 시사한다."
"단, [분모 차이/결측치/기간 차이]가 있어 단순 비교는 제한적이다."
이런 템플릿은 에이전트가 말투를 통일하는 데도 도움이 된다. 더 중요한 것은 과장과 단정의 위험을 낮춘다는 점이다. 숫자를 해석할 때는 언제나 "보이는 사실"과 "가능한 해석"을 구분해야 한다.
분석 Skill에서 자주 쓰는 출력 구조
데이터 분석 결과물을 만들 때마다 형식이 달라지면 검토와 재사용이 어려워진다. 그래서 Skill은 결과 출력 틀까지 정해 주는 편이 좋다. 예를 들어 실무형 분석 Skill이라면 다음 순서를 기본 출력 구조로 삼을 수 있다.
분석 목적
사용한 데이터와 기간
전처리 및 정제 내역
핵심 요약 지표
주요 차트와 해석
한계와 주의사항
다음 액션 또는 추가 분석 제안
이 구조의 장점은 단순하다. 보는 사람 입장에서 "무엇을 했고, 무엇을 믿을 수 있고, 무엇을 다음에 해야 하는지"가 한 번에 드러난다. 분석 보고서는 숫자를 늘어놓는 문서가 아니라, 판단을 돕는 문서라는 점을 Skill이 계속 상기시켜야 한다.
검증 체크리스트가 없는 분석 Skill은 위험하다
분석 Skill을 설계할 때 가장 자주 빠지는 요소가 검증 단계다. 파일을 읽고, 정리하고, 그래프를 만들고, 그럴듯한 문장까지 붙이면 일은 끝난 것처럼 보인다. 하지만 진짜 실수는 그다음에 드러난다. 합계가 맞지 않거나, 필터 조건이 빠졌거나, 중복 행이 두 번 집계되었거나, 백분율 합이 100%를 넘는 경우다.
그래서 분석 Skill에는 마지막 검증 체크리스트가 반드시 들어가야 한다. 이 단계는 화려하지 않지만, 조직에서 신뢰를 만드는 핵심이다.
검증 체크리스트에는 보통 이런 항목이 들어간다.
분석 대상 행 수와 제외된 행 수가 기록되었는가
필수 컬럼 누락 여부를 확인했는가
집계 전후 총합이 상식적으로 일치하는가
비율 계산의 분모와 분자가 올바른가
날짜 범위와 필터 조건이 보고서에 명시되었는가
이상치, 결측치, 단위 변환 처리 내역이 남아 있는가
차트 제목, 축 이름, 단위 표기가 명확한가
해석 문장이 데이터가 보여 주는 범위를 넘어서 단정하고 있지 않은가
이 체크리스트는 가능하면 사람이 읽는 지침에만 두지 말고, 스크립트나 템플릿으로도 일부 자동화하는 것이 좋다. 예를 들어 총합 일치 여부, 결측치 비율, 날짜 범위, 중복 건수 같은 항목은 자동 검사에 맡기고, 해석 과장 여부나 비즈니스 맥락 적절성은 사람이 검토하도록 나누는 방식이 현실적이다.
재현 가능한 분석 로그를 남겨야 한다
데이터 분석 Skill의 완성도를 가르는 마지막 요소는 로그다. 같은 데이터를 다시 넣었을 때 비슷한 결과가 나오는가, 왜 어떤 행이 빠졌는가, 어떤 변환이 적용되었는가, 어떤 필터가 걸렸는가를 추적할 수 있어야 한다. 이 정보가 없으면 분석은 결과만 남고 과정은 사라진다.
좋은 로그는 개발자의 디버깅 기록처럼 남는다. 복잡한 문장이 아니라, 핵심 결정을 순서대로 적는 것이다. 예를 들면 이런 항목들이다.
입력 파일명과 생성 일시
사용한 시트 또는 테이블 이름
분석 기간과 필터 조건
적용한 정제 규칙
제외된 행 수와 이유
생성한 파생 변수 목록
사용한 집계 기준과 시각화 종류
최종 결과 파일 또는 리포트 경로
이 로그가 있으면 두 달 뒤에 같은 분석을 다시 해야 할 때도 훨씬 수월하다. 팀 리더 입장에서도 좋다. 결과가 틀렸을 때 사람을 탓하는 대신, 어느 규칙이 잘못 적용되었는지 확인할 수 있기 때문이다. Skill은 사람의 실수를 없애는 도구가 아니라, 실수를 찾고 고치기 쉽게 만드는 도구이기도 하다.
데이터 분석 Skill의 폴더 구성 예시
분석 Skill은 자연어 지침만으로도 시작할 수 있지만, 실무에 들어가면 스크립트와 참조 자료가 함께 있는 편이 훨씬 안정적이다. 예를 들어 다음처럼 구성할 수 있다.
SKILL.md: 분석 목적, 적용 대상, 절차, 검증 규칙, 출력 형식scripts/: CSV 정리, 날짜 변환, 결측치 점검, 요약 통계 생성 스크립트references/: 컬럼 정의서, 단위 표준표, 이상치 판단 기준표assets/: 보고서 템플릿, 차트 스타일 가이드, 표 샘플examples/: 정상 입력 예시, 오류 데이터 예시, 기대 출력 예시
이 구조의 장점은 분명하다. 에이전트는 긴 설명을 모두 기억하려 애쓸 필요 없이, 필요한 순간에 필요한 파일을 참조하면 된다. 특히 데이터 분석은 컬럼 의미와 단위 기준표가 중요한데, 이를 references/에 따로 두면 Skill 지침 본문을 지나치게 길게 만들지 않고도 정밀도를 높일 수 있다.
SKILL.md에는 무엇을 써야 하는가
데이터 분석 Skill의 SKILL.md는 단순 사용 설명서가 아니다. 분석가의 작업 습관을 구조로 번역한 문서다. 따라서 다음 요소를 포함하는 것이 좋다.
목적과 적용 범위
어떤 데이터에 쓰는 Skill인지 먼저 분명해야 한다. 예를 들어 "매출 CSV 분석", "앱 이벤트 로그 분석", "고객 응대 Excel 요약"처럼 범위를 좁혀야 한다. 범위가 넓으면 규칙이 모호해지고, 범위가 너무 좁으면 재사용성이 떨어진다.
입력 명세
지원 파일 형식, 필수 컬럼, 선택 컬럼, 날짜 형식, 단위 기준을 적는다. 이 부분이 애매하면 에이전트는 없는 컬럼을 상상하거나, 잘못된 타입으로 계산할 수 있다.
분석 절차
탐색, 정제, 요약, 시각화의 네 단계를 명시하고, 각 단계에서 반드시 수행할 작업을 적는다. 가능하면 "해야 한다" 수준으로 단정적으로 쓰는 편이 좋다.
예외 처리 규칙
필수 컬럼이 없을 때, 기간이 비정상적으로 짧을 때, 결측치 비율이 일정 수준을 넘을 때, 단위가 혼재할 때 어떻게 할지 적는다. 분석 Skill은 정상 데이터보다 이상한 데이터를 만났을 때 진가가 드러난다.
출력 형식
보고서 구조, 표 형식, 차트 제목 스타일, 설명 문구 톤을 정한다. 같은 분석도 출력 형식이 통일되면 조직 내 활용성이 크게 높아진다.
검증 및 로그 규칙
마지막 검토 항목과 남겨야 할 로그 항목을 반드시 넣는다. 이 부분이 있어야 Skill이 단순 자동화가 아니라 운영 가능한 시스템이 된다.
예시: 매출 데이터 분석 Skill의 절차 설계
조금 더 구체적으로 상상해 보자. 한 팀이 매주 매출 데이터를 받아 성과 보고를 만든다고 하자. 사람마다 파일 정리 방식도 다르고 강조하는 지표도 달라서 회의 때마다 숫자 기준을 다시 맞추고 있다. 이때 매출 분석 Skill은 다음처럼 설계할 수 있다.
먼저 입력은 date, order_id, product, region, revenue, quantity 같은 필수 컬럼을 가진 CSV 또는 Excel로 제한한다. 그다음 전처리 단계에서 날짜 형식을 통일하고, 금액은 숫자형으로 변환하고, 주문 ID 중복 여부를 확인한다. 취소 주문을 나타내는 값이 있으면 집계에서 제외하되, 제외 건수는 로그에 남긴다.
요약 단계에서는 주별 매출 합계, 제품별 매출 비중, 지역별 평균 주문 금액을 기본 지표로 만든다. 시각화 단계에서는 주별 추세는 선 그래프, 제품별 비교는 막대 그래프, 지역별 비중은 표 중심으로 제시한다. 마지막에는 "전주 대비 변화", "가장 큰 기여 제품", "추가 확인이 필요한 이상 패턴"을 세 문단으로 정리하게 한다.
이렇게 하면 에이전트는 단순히 그래프를 뽑는 도우미가 아니라, 팀의 주간 매출 분석 방식을 재현하는 실행 시스템이 된다.
로그 파일 분석 Skill은 왜 따로 생각해야 하는가
CSV와 Excel은 비교적 표 구조가 명확하지만, 로그 파일은 사건의 흐름을 다룬다. 그래서 로그 분석 Skill은 숫자를 합산하는 것보다 이벤트를 해석하는 절차가 중요하다. 예를 들어 서버 로그, 사용자 행동 로그, 에러 로그는 각각 기준 시간이 중요하고, 이벤트 순서와 세션 구성이 핵심일 수 있다.
로그 분석 Skill에는 특히 다음 규칙이 필요하다.
타임스탬프를 하나의 시간대로 통일할 것
중복 이벤트 여부를 정의할 것
세션 기준을 명시할 것
에러 코드와 정상 이벤트를 구분할 것
이상 급증은 장애, 배포, 캠페인 등 운영 사건과 함께 검토할 것
로그 분석에서 흔한 실수는 이벤트 수를 그대로 성과나 문제 규모로 해석하는 것이다. 하지만 같은 사용자가 여러 번 재시도했을 수도 있고, 시스템 자체가 중복 로그를 남겼을 수도 있다. 그래서 로그 분석 Skill은 집계 전에 사건 모델을 먼저 정하게 만들어야 한다.
데이터 분석 Skill에서 코드가 필요한 순간
모든 분석 Skill이 스크립트를 필요로 하는 것은 아니다. 하지만 다음 상황에서는 자연어 지침만으로 일관성을 유지하기 어렵다.
날짜, 통화, 단위를 반복적으로 변환해야 할 때
큰 파일에서 누락값, 이상치, 중복을 자동 점검해야 할 때
같은 요약 표와 차트를 여러 번 생성해야 할 때
로그 정규화처럼 형식 변환 규칙이 복잡할 때
검증 체크리스트 일부를 자동 실행하고 싶을 때
이때는 스크립트를 붙이는 것이 좋다. 다만 중요한 것은 코드가 분석을 대신하게 하는 것이 아니라, 분석의 기초 작업을 안정화하게 하는 것이다. 예를 들어 validate_schema.py, clean_dates.py, summarize_sales.py처럼 기능별로 나누면 에이전트도 어떤 스크립트를 언제 호출해야 하는지 판단하기 쉬워진다.
또한 입력과 출력 계약도 함께 적어 두어야 한다. 입력 파일 경로, 필요한 컬럼, 출력 파일 형식, 실패 시 메시지 형식이 명확해야 에이전트가 스크립트를 안전하게 사용할 수 있다. 분석 Skill에서 코드가 실패하는 이유는 대개 코드가 어려워서가 아니라, 계약이 모호해서다.
사람이 확인해야 하는 순간도 정해 두자
데이터 분석 자동화에서 가장 위험한 착각은 "이제 사람은 안 봐도 된다"는 생각이다. 실제로는 사람 확인이 꼭 필요한 순간이 있다. 예를 들어 다음과 같은 경우다.
필수 컬럼이 빠졌는데 자동 추정이 필요한 경우
누락값 보정 방식이 결과에 큰 영향을 주는 경우
이상치가 오류인지 실제 사건인지 구분이 어려운 경우
차트 해석이 사업 맥락과 강하게 연결되는 경우
외부 보고용 문서라서 표현 수위와 책임 소재가 중요한 경우
좋은 Skill은 사람을 제거하지 않는다. 오히려 사람의 판단이 필요한 지점을 더 분명히 표시한다. 자동화의 목적은 모든 결정을 대신하는 것이 아니라, 기계가 잘할 수 있는 반복 작업과 사람이 판단해야 하는 예외 작업을 분리하는 데 있다.
분석 Skill의 성공 기준
데이터 분석 Skill이 잘 만들어졌는지는 멋진 문장이나 화려한 차트로 판단하지 않는다. 다음과 같은 기준으로 보는 편이 정확하다.
첫째, 같은 입력에 대해 비슷한 결과가 나오는가. 둘째, 누락값과 이상치 처리 방식이 일관적인가. 셋째, 결과를 다시 따라갈 수 있는 로그가 남는가. 넷째, 표와 차트의 형식이 조직 표준에 맞는가. 다섯째, 사람이 마지막 검토를 할 때 "무엇을 했는지"를 빠르게 이해할 수 있는가.
이 기준을 충족한다면, 그 Skill은 단순히 분석 결과를 만드는 도구를 넘어 조직의 분석 방식 자체를 보존하는 자산이 된다.
데이터 분석 Skill은 조직의 분석 습관을 패키징한다
결국 데이터 분석 Skill이 하는 일은 하나다. 데이터를 읽는 습관, 정리하는 기준, 확인하는 순서, 설명하는 방식까지 한 번의 대화가 아니라 재사용 가능한 능력으로 바꾸는 것이다. 이것이 중요한 이유는 분석이 늘 숫자의 문제가 아니기 때문이다. 분석은 신뢰의 문제이고, 신뢰는 일관성에서 나온다.
에이전트가 똑똑하게 보이는 순간보다 더 중요한 순간이 있다. 매주 들어오는 지저분한 파일을 같은 규칙으로 정리하고, 같은 기준으로 점검하고, 같은 형식으로 보고해 주는 순간이다. 바로 그때 AI는 신기한 도구를 넘어, 실제로 일을 맡길 수 있는 시스템이 된다.
데이터 분석 Skill을 설계할 때는 먼저 질문해야 한다. "이 에이전트가 얼마나 깊이 해석할 수 있는가?"가 아니다. "이 에이전트가 매번 같은 순서로, 같은 기준으로, 같은 품질의 분석을 반복할 수 있는가?" 이 질문에 자신 있게 답할 수 있다면, 당신은 이미 분석 자동화를 시작한 것이 아니라 분석 운영체계를 만들기 시작한 것이다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.