왜개발·데이터 업무와 AI의 궁합
개발·데이터는 '이해와 밑작업'에 시간이 든다
남의 코드를 읽고, 테스트를 빠짐없이 짜고, SQL을 매번 고민하는 일은 손이 많이 가지만 창의적이진 않다. 이런 밑작업의 초안·설명을 AI에게 맡기면, 사람은 검토와 판단에 집중할 수 있다.
핵심개발·데이터는 초안·설명·나열을 AI에게, 실행·검증·최종 판단은 사람에게. AI가 만든 코드·SQL은 반드시 읽고 테스트한 뒤 돌린다.
| ❌ AI 없이 | ✅ AI와 함께 |
|---|---|
| 남이 짠 코드 해독에 시간 오래 | 동작을 쉬운 말로 즉시 설명 |
| 테스트 케이스 자주 빠뜨림 | 정상·경계값·예외까지 나열 |
| SQL을 매번 처음부터 고민 | 초안을 받아 뜻 확인 후 수정 |
활용개발·데이터 대표 4가지
이럴 때 이렇게 쓴다
| 업무 | AI에게 시키는 것 | 사람이 지킬 것 |
|---|---|---|
| 코드 설명 | 모르는 코드·함수 동작을 쉬운 말로 풀이 | 실행 전 직접 읽고 확인 |
| 테스트 케이스 | 정상·경계·예외 케이스를 빠짐없이 나열 | 실제 사양·요구와 대조 |
| SQL 초안 | 자연어 요구를 쿼리 초안으로 변환 | 운영DB 실행 전 검토·백업 |
| 로그 요약 | 대량 로그에서 에러 패턴·빈도 요약 | 원본 로그로 근거 재확인 |
실습직접 해보기 — SQL 초안
실습 ① 자연어 요구 → SQL 초안 + 설명
아래 상황을 두고 프롬프트 상자를 복사해 Claude(또는 ChatGPT)에 붙여 넣는다.
상황주문 테이블 orders(id, user_id, amount, created_at)가 있다. 최근 30일간 사용자별 총 구매액 상위 10명을 뽑아야 하는데, SQL을 자주 안 써서 매번 헷갈린다. 초안과 각 줄의 뜻, 실행 전 확인할 점까지 받고 싶다.
주문 테이블 orders(id, user_id, amount, created_at)에서 최근 30일간 사용자별 총 구매액 상위 10명을 뽑는 SQL을 작성해줘. - 표준 SQL 기준으로 초안을 먼저 보여주고 - 각 줄(각 절)이 무슨 뜻인지 한 줄씩 설명해줘 - 실행 전에 내가 확인해야 할 점도 알려줘 DB 방언(날짜 함수 등)에 따라 달라질 수 있는 부분은 표시해줘.
실습 결과이렇게 나온다
AI가 만든 SQL 초안
나 · 요청
(위 프롬프트 실행)
Claude · 초안
SELECT
user_id,
SUM(amount) AS total_amount
FROM orders
WHERE created_at >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY user_id
ORDER BY total_amount DESC
LIMIT 10;
각 절이 하는 일
- SELECT user_id, SUM(amount) — 사용자별로 구매액을 합산해 보여준다.
- FROM orders — 주문 테이블에서 가져온다.
- WHERE created_at >= ... — 최근 30일 주문만 남긴다(기준 날짜 이후).
- GROUP BY user_id — 같은 사용자의 주문을 하나로 묶어 합계를 낸다.
- ORDER BY total_amount DESC — 합계가 큰 순서로 정렬한다.
- LIMIT 10 — 상위 10명만 남긴다.
실행 전 확인
- 날짜 함수는 DB 방언 차이가 크다. MySQL이면 DATE_SUB(CURDATE(), INTERVAL 30 DAY), PostgreSQL이면 NOW() - INTERVAL '30 days' 식으로 바꿔야 할 수 있다.
- created_at에 인덱스가 있는지 확인한다. 없으면 데이터가 많을 때 느려진다.
- amount 컬럼 정의를 확인한다 — 환불·취소 금액이 음수/별도 컬럼인지에 따라 합계 의미가 달라진다.
Claude · 참고
이 쿼리는 운영 DB에서 바로 실행하지 마세요. 먼저 조회 전용 권한이나 사본에서 테스트하고, 쓰기 작업이 아니어도 백업·부하를 확인한 뒤 돌리는 것이 안전합니다.
관찰 포인트SQL 초안뿐 아니라 각 줄의 뜻과 DB 방언·인덱스·컬럼 정의까지 짚어 준다. 나는 우리 DB에 맞게 날짜 함수만 바꾸고 검토하면 된다.
실습한 번 더 — 테스트 케이스
실습 ② 함수 → 테스트 케이스 표
SQL 말고 자주 쓰는 게 테스트 케이스 나열이다. 함수 사양만 주면 정상·경계·예외로 나눠 준다.
아래 이메일 검증 함수의 테스트 케이스를 표로 만들어줘. [함수] 입력이 이메일 문자열이면 true, 아니면 false를 반환한다. - 정상 / 경계 / 예외 세 구분으로 나눠줘 - 각 행에 '구분 / 입력 예 / 기대 결과'를 적어줘 - 빠뜨리기 쉬운 경계·예외 케이스를 특히 신경 써줘
Claude
| 구분 | 입력 예 | 기대 결과 |
|---|---|---|
| 정상 | a@b.com | true |
| 정상 | user.name@company.co.kr | true |
| 경계 | a@b.c (최소 형태) | true |
| 예외 | ab.com (@ 없음) | false |
| 예외 | a@ (도메인 없음) | false |
| 예외 | a @b.com (공백 포함) | false |
| 예외 | "" (빈 문자열) | false |
핵심정상만 짜고 넘어가기 쉬운데 @ 없음·도메인 없음·공백·빈 문자열 같은 예외를 챙겨 준다. 실제 사양(허용 형식)에 맞게 가감해서 쓰면 된다.
미션내 업무로 바로
지금 다루는 코드·데이터로 해보기
오늘 만난 코드·SQL·로그 하나를 AI로 설명 → 검증
10분- 코드 설명 · 테스트 케이스 · SQL 초안 · 로그 요약 중 지금 필요한 하나를 고른다.
- 대상(함수/요구/로그 일부)을 주고 초안·설명을 요청한다. SQL이면 각 줄의 뜻도 같이 물어본다.
- 사내 소스·운영 데이터를 붙일 때는 기밀·개인정보를 익명화하거나 최소한만 넣는다.
- 결과를 직접 읽고 테스트한 뒤에만 사용한다 — 특히 SQL은 사본/조회 권한에서 먼저 돌린다.
예상 결과 — 무엇을 얻게 되나
남의 코드 이해, 테스트 케이스 나열, SQL 초안 같은 밑작업 시간이 크게 줄어든다. 다만 생성된 코드·SQL은 그대로 믿지 않는다 — 반드시 읽고 테스트한 뒤 실행하고, 운영 DB 작업은 사본·백업으로 먼저 확인한다. 자세한 기준은 검증 체크리스트 참고.
클로드코드 시작하기부서별 활용 · 개발·데이터