KOPIS 프롬프트 공유 - 수상작 데이터로 흥행 패턴 분석하기
KOPIS OpenAPI를 활용해 2022년 이후 연극·뮤지컬 수상작의 총티켓판매수를 추출한 작업의 단계별 프롬프트 가이드
수상작 데이터와 공연 통계를 연결하려면 4개 테이블을 조인해야 한다. 테이블 간 관계가 복잡해서 클로드가 혼자 파악하기 어려운 부분은 직접 설명해줬고, 오류가 발생하면 진단 스크립트를 먼저 돌려 원인을 확인한 뒤 수정을 요청했다. 그 흐름을 정리했다.
보라색은 직접 입력했던 프롬프트, 노란색은 참고할만한 팁을 정리하였습니다.
STEP 1. 목표 설정 + 데이터 가용성 확인
프롬프트 의도: 분석 주제를 정한 뒤, 원하는 데이터가 API에 실제로 존재하는지부터 확인한다. 나는 ‘수상작의 흥행 패턴’을 분석하고 싶었는데, ‘흥행’을 측정할 관객수·매출 데이터가 있는지 알 수 없었다. 주제를 먼저 잡고 데이터를 나중에 보는 것보다, 데이터를 먼저 보고 주제를 구체화하는 순서가 낫다고 판단해서 데이터 탐색부터 시작했다.
⌨️ KOPIS 수상작DB를 활용해서 수상작들의 흥행 패턴을 분석하고 싶어.
수상작 목록을 수집하고, 이 데이터에서 흥행 여부를 파악할 수 있는 지표가 뭐가 있는지 확인해줘.수집 기간은 2022년 이후, 대상 장르는 연극과 뮤지컬, 아동 공연은 제외야.
결과: KOPIS API에는 개별 공연의 관객수·매출을 직접 조회하는 API가 없다는 사실을 먼저 파악했다. 통계 API는 전체 장르 또는 시설 단위 집계만 제공한다. 대신 공연수익계산기에서 처럼, ‘공연시설별통계DB’를 통해 티켓 판매 수를 간접적으로 산출할 수 있을 것 같았다. 이 구조를 기반으로 4개 테이블 조인 설계로 방향을 잡았다.
💡 클로드에게 데이터 소스와 분석 목적을 먼저 알려주면, 가용한 데이터로 어떤 분석이 가능한지 스스로 탐색해준다. 어떤 데이터가 있는지 명확하지 않을 때 먼저 물어보는 것도 도움이 된다. 하지만 데이터의 세세한 내용까지 한 번에 파악하지는 못하기 때문에, 결국 사람의 이중검증이 필요하긴 하다.
STEP 2. 1차 추출 - 수상작 목록 + 공연상세 조인
프롬프트 의도: 수상작 목록 API(prfawad)에서 가져올 수 없는 제작사, 기획사, 티켓가격 등의 세부 정보를 공연상세 API(pblprfr)에서 보완한다. 두 테이블을 공연ID(mt20id)로 조인하는 스크립트를 요청했고, 어떤 컬럼이 필요한지 명확히 지정해서 불필요한 필드 수집을 막았다.
⌨️ 수상작DB의 전체 데이터를 추출하고, 공연ID(mt20id)를 기준으로 공연상세DB와 조인해줘.
공연상세DB에서는 다음 컬럼만 추출해:공연시설명(fcltynm), 제작사(entrpsnmP), 기획사(entrpsnmA), 주최(entrpsnmH), 주관(entrpsnmS), 티켓가격(pcseguidance), 오픈런, 내한, 아동, 대학로, 축제, 뮤지컬라이센스, 뮤지컬창작
결과: 첫 실행에서 수집 건수가 0건. 원인 파악을 위해 진단 스크립트를 따로 만들어 API 응답을 직접 확인했고, KOPIS API의 특이사항 2건을 발견했다.
발견된 KOPIS API 특이사항
- 수상작API의
shcate****(장르코드) 파라미터 미작동: 장르코드를 넣으면 결과가 0건으로 반환된다. 문서에는 지원된다고 나와 있지만 실제로는 작동하지 않음. → 전체 조회 후 응답의genrenm필드로 직접 필터링하는 방식으로 전환.- 수상실적 구분자가
태그: 복수의 수상 이력을 구분하는 필드(awards)의 구분자가 줄바꿈(
\n)이 아닌 HTML 태그
형태로 들어있다.
💡 오류가 발생했을 때, 오류 메시지를 그대로 복사해서 붙여넣거나 터미널 출력을 캡쳐해서 올리면 된다. 원인 분석 없이 상황만 전달해도 클로드가 진단 스크립트를 만들어 원인을 찾아준다.
STEP 3. 2차 추출 - 총티켓판매수 추가 (3개 테이블 추가 조인)
프롬프트 의도: 흥행 지표로 총티켓판매수를 추가하기 위해 공연시설상세DB와 공연시설별통계DB를 추가로 조인한다. 이 두 테이블 사이의 관계가 복잡해서, 클로드가 스스로 파악하기 어려운 조인 로직을 내가 직접 설명했다. 테이블 간 컬럼명이 같아도 의미가 다르거나, 값이 합성 형태로 저장된 경우가 있기 때문이다.
⌨️ 공연시설상세DB와 공연시설별통계DB를 추가로 조인해서 총티켓판매수를 구할거야. 아래 관계를 참고해:
[공연상세DB ↔ 공연시설상세DB]
- 공연상세DB의 공연시설명(fcltynm) = 공연시설상세DB의 fcltynm + ”(” + prfplcnm + ”)” 형태로 합쳐진 값이야.
[공연시설상세DB ↔ 공연시설별통계DB]
공연시설상세DB의 fcltynm → 통계DB 요청 시 shprfnmfct 파라미터로 사용
공연시설상세DB의 prfplcnm → 통계DB 응답의 prfnmplc 값으로 필터링
공연의 시작일~종료일 기간으로 조회하면 총티켓판매수(totnmrs)를 합산할 수 있어.
결과: 초기 실행에서 총티켓판매수가 전부 0건. 진단 스크립트로 API 응답을 직접 확인하니 공연장명 파싱 로직에 오류가 있었다.
발견된 KOPIS API 특이사항
공연상세DB의 fcltynm 합성 형태에 공백이 포함되어 있다:시설명 (공연장명)← 괄호 앞에 공백 있음. 처음에는 공백 없이 파싱을 시도해서 전체 매칭 실패.시설명부분을 제거한 나머지 문자열을 strip 처리한 뒤 괄호 안을 추출하는 방식으로 수정했다.
💡 API 문서에 없는 테이블 관계나 값의 합성 규칙은 클로드가 스스로 알 수 없다. 내가 직접 데이터를 확인하고 관계를 파악해서 설명해줘야 한다. 반대로, 내가 설명해주면 그 로직대로 코드를 짜준다. 나는 판단을 내리고 클로드는 실행하는.. 서로 분업을 해야 한다!
STEP 4. 조건 추가 수정
프롬프트 의도: 데이터를 실제로 보면서 빠진 조건들을 추가로 정의했다. ‘22년부터 현재까지’라는 기간 요건과, 동일 작품이라도 공연 시기·극장이 다르면 개별 집계해야 한다는 요건이 처음부터 명확하지 않아서 추가했다.
⌨️ 1. 수집 기간을 2024년으로 고정하지 말고, 2022년부터 지금까지로 변경해줘.
- 동일한 작품이어도 공연마다 극장이나 날짜가 다르기 때문에 좌석수와 총티켓판매수는 공연(mt20id) 단위로 따로따로 집계해야 해.
결과: END_YEAR를 datetime.now().year로 변경해 실행 시점 기준으로 자동 수집되도록 수정. 공연ID(mt20id) 기준의 기존 중복 제거 로직은 이미 공연 단위로 분리되어 있었기 때문에 2번 요건은 별도 수정 없이 확인만 했다.
STEP 5. 작업 마무리 - 다음 작업을 위한 기록
이번 데이터 추출 작업은, 추출 결과와 관계없이 활용하지 못할 것 같다는 판단이 들었다. 가장 크리티컬한 문제는 수상 시기 데이터가 없다는 것이었다. 시상식 명에 ‘제1회’와 같은 식으로 표기되어 있으나, 년도나 월일이 표시되어 있지 않아서, 수상 이후에 작품이 얼마나 더 성장했는지 파악하는 것이 기본적으로 불가능했다. 물론 수작업과 인간지능을 더한다면 가능하겠지만… 일단 여기까지 추출해보고 포기!
데이터를 사용하지는 않더라도 이번 작업에서 발견한 API 특이사항과 조인 로직을 다음 작업 전에 다시 확인할 수 있도록 문서화했다. 특히 KOPIS API처럼 문서와 실제 동작이 다른 경우가 많을 때는, 삽질했던 내용을 기록해두는 것이 다음 작업 속도를 크게 줄여준다.
기록하고 있는 내용은 두 종류
- 작업 노트: 이번 수상작 분석 작업의 현황, 남은 작업 체크리스트(혹시나 재작업 한다면 필요할)
- API 활용가이드: 테이블 구조, 조인 관계, 발견된 특이사항, 오류 이력 — KOPIS를 다시 쓸 때마다 업데이트
💡 작업이 끝날 때마다 ‘다음에 이 작업을 이어서 할 나’에게 편지를 쓴다는 느낌으로 기록하면 좋다. 특히 API 특이사항처럼 문서에는 안 나와 있는 내용은 꼭 기록하고 있다. 클로드와 다음 세션을 시작할 때 이 문서를 먼저 보여주면, 맥락 공유 시간을 크게 줄일 수 있다.
(참고) 4개 테이블 조인 구조
💡 전체 조인 흐름
수상작DB (prfawad)└─ [공연ID: mt20id]
공연상세DB (pblprfr/{mt20id})
└─ [공연시설ID: mt10id]
공연시설상세DB (prfplc/{mt10id})
└─ fcltynm(시설명), prfplcnm(공연장명)
공연시설별통계DB (prfstsPrfByFct)
→ shprfnmfct=fcltynm, prfnmplc 필터링 → totnmrs 합산
핵심 특이사항 요약
prfawad의 shcate 파라미터 미작동 → genrenm으로 직접 필터링
awards 구분자 =
태그 (줄바꿈 아님)
공연상세DB.fcltynm = 시설명 + ” (” + 공연장명 + ”)” (공백 포함)
공연시설별통계DB 기간 제한 31일 → 30일 단위 분할 후 합산
prfstsPrfByFct가 데이터 없을 때 빈 body 반환 → XML 파싱 전 빈 응답 체크 필요
Excel 출력 시트 구성
전체/연극/뮤지컬— 장르별 분리
수상횟수TOP50— 수상 많이 한 공연 상위 50개
티켓판매TOP50— 총티켓판매수 상위 50개
