API 활용과 자동화

이번 주 읽기: 상담사도 API를 알아야 할까?

API(Application Programming Interface, 두 프로그램이 서로 대화하는 약속된 규칙)라는 말을 처음 들으면 어렵게 느껴진다. 비유로 설명해보자. 레스토랑에 가면 고객이 직접 주방에 들어가 요리하지 않는다. 메뉴판(API 문서)을 보고 주문(요청)을 하면, 웨이터(API)가 주방(서버)에 전달하고 음식(응답)을 가져다준다. API는 바로 이 “웨이터” 역할이다 — 한쪽이 “이거 해줘”라고 요청하면, 다른 쪽에서 “여기 결과야”라고 돌려주는 약속이다.

또 다른 비유를 들어보자. TV 리모컨도 일종의 API다. 리모컨의 버튼(요청)을 누르면, TV(서버)가 채널을 바꾸거나 볼륨을 조절한다(응답). 리모컨을 쓸 때 TV 내부의 전자 회로가 어떻게 작동하는지 알 필요가 없다. 버튼만 누르면 된다. API도 마찬가지다. 내부 작동 원리를 몰라도, 정해진 형식으로 요청을 보내면 원하는 결과를 받을 수 있다.

그런데 상담사가 왜 이걸 알아야 할까? Gainer(2025)는 코딩을 직접 할 필요는 없지만, API가 뭘 하는지, 내담자(상담을 받는 사람) 데이터가 어디로 가는지, 어떤 보안 위험이 있는지를 이해하는 “API 리터러시(API literacy, API가 뭔지 개념적으로 이해하는 능력)”가 필수라고 말한다. 예를 들어보자. 내가 만든 상담 앱에서 내담자가 “나는 죽고 싶다”라고 입력하면, 그 텍스트가 미국에 있는 AI 서버로 전송된다. 이 과정을 모르면 개인정보 보호도, 윤리적 판단도 할 수 없다.

레스토랑 비유로 돌아가자. 손님(우리 앱)이 주문(내담자 메시지)을 하면, 웨이터(API)가 그 주문서를 들고 주방(AI 서버)으로 간다. 문제는 이 주방이 다른 나라에 있다는 거다. 주문서에 적힌 내용(내담자의 민감한 심리 정보)이 국경을 넘어간다. 그 주방에서 주문서를 복사해두진 않는지, 다른 손님에게 보여주진 않는지를 확인하는 게 “API 리터러시”의 핵심이다.

무스타파 술레이만

기술을 이해하지 못하면 기술에 의해 지배당한다. AI 시대에 모든 전문가에게 필요한 건 코딩 능력이 아니라, 기술이 무엇을 하고 무엇을 할 수 없는지 판단하는 능력이다.

— Suleyman (2023)

AI API 호출의 네 가지 핵심 요소

AI API를 호출(call, AI에게 요청을 보내는 것)할 때 필요한 것은 딱 네 가지다. 첫째, 엔드포인트(endpoint, API 서버의 주소)다. “이 주소로 요청을 보내세요”라는 URL(인터넷 주소)이다. 예를 들어 OpenAI라면 api.openai.com/v1/chat/completions 같은 형태다. Anthropic(Claude를 만든 회사)이라면 api.anthropic.com/v1/messages다. 회사마다 주소가 다르다.

둘째, 인증(authentication, 본인 확인)이다. API Key라는 일종의 비밀번호를 함께 보내야 한다. 이게 없으면 서버가 “너 누구야?” 하면서 거부한다. API Key는 집 열쇠와 같다. 잃어버리면 남이 내 집(계정)에 들어와서 비용을 발생시킬 수 있다. 그래서 API Key는 절대로 코드에 직접 적으면 안 되고, 환경 변수(environment variable)라는 안전한 보관함에 넣어둬야 한다.

셋째, 요청 본문(request body, 실제로 보내는 내용물)이다. 어떤 AI 모델을 쓸 건지, 시스템 프롬프트(AI에게 주는 역할 지시)는 뭔지, 사용자 메시지는 뭔지를 JSON(데이터를 정리하는 형식, 쉽게 말해 “이름표 붙인 정보 묶음”) 형태로 담아 보낸다. JSON은 이렇게 생겼다 — 중괄호 안에 “이름: 값” 쌍을 나열한 것이다. 택배 송장에 보내는 사람, 받는 사람, 내용물을 적듯이, JSON에도 모델명, 시스템 프롬프트, 사용자 메시지를 적는다.

넷째, 응답(response, 서버가 돌려주는 결과)이다. AI가 생성한 텍스트, 사용한 토큰(token, 글자 단위) 수, 모델 정보 등이 담겨 돌아온다. 응답도 JSON 형식이다. 우리가 필요한 부분(AI가 생성한 텍스트)을 골라서 화면에 보여주면 된다.

여기서 꼭 기억할 두 가지 설정이 있다. temperature(온도)는 AI의 “창의성 다이얼”이다. 0에 가까우면 매번 비슷한 답을 하고(분석 작업에 적합), 1에 가까우면 매번 다른 답을 한다(대화 생성에 적합). max_tokens는 응답 길이 제한이다. 상담 축어록 분석처럼 정확성이 필요한 작업에는 temperature 0.0~0.3이 적합하다. 공감적 대화처럼 자연스러움이 필요한 작업에는 0.7~1.0이 적합하다.

안드레이 카르파시

temperature는 AI의 '성격'을 조절하는 다이얼이다. 낮으면 신중하고 예측 가능하며, 높으면 창의적이고 예측 불가능하다. 목적에 맞는 설정이 결과의 품질을 결정한다.

— Karpathy (2023)

축어록 자동 분석: AI가 상담 대화를 읽는다

축어록(verbatim transcript, 상담 대화를 한 마디도 빠짐없이 글로 옮긴 것)은 상담사 수련의 핵심 도구다. 내가 상담할 때 어떤 말을 했는지 되돌아볼 수 있다. 문제는, 50분 상담의 축어록을 꼼꼼히 읽으며 분석하는 데 수 시간이 걸린다는 것이다. A4 용지로 15~20페이지에 달하는 텍스트를 한 줄 한 줄 읽으면서 “여기서 내가 공감을 잘 했나?” “이 지점에서 다른 개입을 했으면 어땠을까?”를 분석하는 작업이다. AI가 이 시간을 크게 줄여줄 수 있다.

Goldberg 등(2020)은 AI에게 축어록을 읽게 한 뒤, 상담사의 공감 수준과 치료적 동맹(therapeutic alliance, 상담사와 내담자가 “같은 팀”이라는 느낌)의 정도를 자동으로 평가하게 했다. AI의 평가와 인간 전문가의 평가를 비교하니, 상관계수(두 값이 얼마나 같이 움직이는지를 나타내는 숫자) 0.72로 꽤 높았다. 0.72라는 건, AI와 인간 전문가가 같은 축어록을 보고 약 72% 정도 일치하는 평가를 내렸다는 뜻이다. 완벽하지는 않지만, “대략적인 방향은 맞게 짚는다” 수준이다.

Flemotomos 등(2022)은 CBT(인지행동치료, 생각의 패턴을 바꿔 감정을 개선하는 상담 방법) 회기의 품질을 AI로 평가했는데, “상담사가 무엇을 했는가”(기법 사용 여부)는 잘 감지했지만, “어떻게 했는가”(공감의 깊이, 진정성)는 정확도가 낮았다. AI는 구체적 행동은 잘 잡지만, 미묘한 관계적 요소는 아직 한계가 있다. 상담사가 “그게 많이 힘드셨겠네요”라고 말했다는 사실은 AI가 감지하지만, 그 말이 진심에서 우러나온 것인지, 기계적으로 한 것인지는 구분하지 못한다.

유발 노아 하라리

AI는 우리보다 우리를 더 잘 알게 될 수 있다. 하지만 '아는 것'과 '이해하는 것'은 다르다. 데이터 분석은 패턴을 보여주지만, 그 패턴 뒤의 의미를 해석하는 것은 인간의 고유한 영역이다.

— Harari (2018)

Gainer(2025)는 이렇게 정리한다 — 축어록 자동 분석은 상담사의 귀를 대체하는 게 아니다. 50분 동안의 방대한 대화에서 상담사가 놓칠 수 있는 패턴을 발견해서 “여기 다시 들어보세요”라고 제안하는 “보조 청취자”의 역할이다. 수퍼바이저에게 축어록을 보여주기 전에 AI의 분석을 먼저 보면, “아, 이 부분에서 내가 너무 서둘렀구나”라는 자기 성찰의 출발점을 얻을 수 있다.

API 비용과 현실적 고려

AI API는 토큰(token) 단위로 과금된다. 1 토큰은 영어 약 4글자, 한국어 약 1~2글자다. 50분 상담 축어록은 한국어 기준 약 5,000~8,000자이고, 분석 프롬프트와 응답까지 합치면 회당 약 100~150원 정도가 든다. 월 20회기를 진행하면 월 2,500~4,000원 수준이다. 커피 한 잔 값으로 20회기분의 자동 분석을 돌릴 수 있다는 뜻이다.

비용보다 더 중요한 건 보안이다. 상담 축어록에는 내담자의 이름, 직장명 같은 개인 정보와 민감한 심리 정보가 들어 있다. 이 데이터가 API를 통해 미국의 AI 서버로 전송된다. 한국의 개인정보보호법과 정신건강복지법을 고려하면, 이 과정에서 세 가지 보안 조치가 필요하다.

첫째, 비식별화(de-identification)다. 이름, 날짜, 장소 같은 식별 정보를 제거한 뒤 API에 보낸다. “김민수”를 “내담자 A”로, “서울대학교”를 “대학 B”로 치환하는 것이다. 둘째, 전송 암호화다. HTTPS 프로토콜을 사용하면 데이터가 이동 중에 암호화된다. 셋째, 데이터 보존 정책 확인이다. OpenAI와 Anthropic 모두 API로 받은 데이터를 AI 훈련에 사용하지 않겠다고 밝히고 있지만, 가장 확실한 방법은 자체 서버에서 오픈소스 모델을 돌리는 것(온프레미스, on-premise)이다.

온프레미스가 뭘까? 외부 서버(클라우드) 대신 우리 기관의 컴퓨터에서 직접 AI 모델을 실행하는 것이다. 비유하면, 남의 주방(클라우드)에서 요리하는 게 아니라 우리 집 주방(자체 서버)에서 직접 요리하는 것이다. 재료(데이터)가 밖으로 나가지 않으니 보안이 훨씬 강하다. 다만 자체 서버를 구축하고 유지하는 비용이 들고, 클라우드 API보다 성능이 낮을 수 있다는 단점이 있다.

조지프 와이젠바움

컴퓨터가 특정 영역에서 인간의 판단을 대체해서는 안 된다. 특히 상담처럼 진정한 이해가 필요한 영역에서는. 기계의 분석은 참고 자료이지, 최종 답이 아니다.

— Weizenbaum (1976)

다음 강의에서는 실제 API 호출 코드를 직접 작성해보고, 축어록의 정서 분석, 주제 추출, 회기 요약 보고서 생성을 실습한다. 기술적으로 어렵게 느껴질 수 있지만, Replit Agent의 도움을 받으면 코딩 경험이 없어도 충분히 따라올 수 있다.

API 호출, 실제로 어떻게 생겼을까?

AI API 호출은 세 단계다. 먼저 요청(request)을 만든다 — 어디로 보낼지(URL), 내가 누구인지(API Key), 뭘 해달라는지(메시지). 다음으로 서버에 보내고 응답을 기다린다. 마지막으로 응답에서 필요한 부분을 꺼낸다. Replit에서 OpenAI SDK를 설치하면, chat.completions.create()이라는 한 줄로 이 모든 과정을 처리할 수 있다.

이 세 단계를 편지 보내기에 비유해보자. 첫째, 편지를 쓴다(요청 만들기). 봉투에 받는 사람 주소(URL)를 적고, 보내는 사람 확인 도장(API Key)을 찍고, 편지지에 내용(메시지)을 적는다. 둘째, 우체통에 넣고 답장을 기다린다(서버에 전송). 셋째, 답장이 오면 봉투를 열고 필요한 내용을 읽는다(응답 파싱). 프로그래밍에서 “파싱(parsing)”이란 데이터에서 필요한 부분을 골라 꺼내는 작업이다.

여기서 핵심은 시스템 프롬프트(system prompt)다. AI에게 “너는 누구이고, 뭘 해야 하고, 뭘 하면 안 되는지”를 미리 알려주는 지시문이다. 상담 도구라면 이런 식이다 — “당신은 상담 회기 축어록을 분석하는 전문 분석가입니다. 각 발화의 감정을 분류하고, 핵심 주제를 추출하세요. 절대로 진단적 판단을 내리지 마세요. 개인 식별 정보를 출력에 포함하지 마세요.” 시스템 프롬프트가 명확할수록 AI의 출력도 정확해진다.

시스템 프롬프트를 잘 쓰는 건 상담에서 적절한 질문을 던지는 것과 비슷하다. 상담사가 “요즘 어때요?”라고 막연하게 물으면 내담자도 막연하게 답한다. “지난주에 이야기했던 직장 갈등, 이번 주에 어떻게 됐나요?”라고 구체적으로 물으면 구체적인 답이 온다. AI에게도 마찬가지다. “이 텍스트를 분석해줘”보다 “이 상담 축어록에서 내담자의 핵심 감정 3가지를 추출하고, 각각의 강도를 1-5로 평가해줘”가 훨씬 좋은 결과를 낸다.

안드레이 카르파시

프롬프트 엔지니어링은 새로운 프로그래밍이다. 코드 한 줄 한 줄이 컴퓨터에 명령을 내리듯, 프롬프트 한 문장 한 문장이 AI에게 명령을 내린다. 명확할수록 결과가 좋다.

— Karpathy (2023)

구조화된 출력: AI 답을 바로 쓸 수 있게 하기

AI에게 “이 축어록을 분석해줘”라고만 하면, AI는 자유로운 형태의 글을 써온다. 이건 사람이 읽기엔 좋지만, 프로그래밍에서 자동으로 처리하기엔 불편하다. 그래서 AI에게 “JSON 형태로 출력해줘” 라고 지시한다. JSON(JavaScript Object Notation)은 데이터를 정리하는 국제 표준 형식이다.

왜 JSON이 중요할까? 비유하면 이렇다. 누군가에게 “오늘 뭐 했어?”라고 물으면, “아침에 일어나서 밥 먹고, 학교 가서 수업 듣고, 친구 만나서 카페 갔어”라고 자유롭게 답한다. 이건 대화에서는 자연스럽지만, 이 답을 자동으로 분류하려면 어렵다. 반면 “오전: 식사+등교, 오후: 수업, 저녁: 친구+카페”처럼 구조화하면, 컴퓨터가 “오후 활동은 수업”이라고 바로 뽑아낼 수 있다. JSON은 이런 구조화를 해주는 형식이다.

축어록 정서 분석: 감정을 숫자로 바꾸기

실무에서 축어록을 준비하는 가장 빠른 방법은 AI 전사 도구를 쓰는 것이다.meeting.tobl.ai는 상담 중 실시간으로 대화를 전사하고, 화자를 자동 구분하며, 전사가 끝나면 AI 분석까지 제공한다. 전사 결과를 비식별화 처리한 뒤 분석 API에 보내면, 실시간 전사 → 비식별화 → 정서 분석 → 보고서 생성까지 하나의 파이프라인이 완성된다.

정서 분석(sentiment analysis)이란, 상담 대화의 각 발화에 감정 레이블을 붙이고 강도를 수치화하는 것이다. “이번 주 정말 힘들었어요” → 부정, 강도 4. “남자친구랑 좋은 대화를 나눴어요” → 긍정, 강도 3. 이런 식이다. 왜 감정을 숫자로 바꿀까? 숫자로 바꾸면 패턴을 볼 수 있기 때문이다. 50분 동안 부정 감정이 언제 올라가고, 상담사의 어떤 개입 후에 내려가는지를 추적할 수 있다.

AI API에 프롬프트를 이렇게 보낸다 — “다음 상담 축어록의 각 발화에 대해 (1) 화자, (2) 정서(긍정/부정/중립/혼합), (3) 강도(1-5), (4) 핵심 감정 단어를 JSON 배열로 출력하라.” JSON이란, 컴퓨터가 읽기 쉬운 구조화된 형식이다. 이렇게 하면 AI의 답을 그대로 프로그래밍에 활용해서 그래프로 시각화할 수 있다. 프로그래밍을 모르더라도 Replit Agent가 시각화 코드를 자동으로 만들어준다.

“혼합(mixed)” 감정 카테고리가 중요하다. 상담에서 내담자의 감정은 순수하게 긍정이거나 부정인 경우가 드물다. “엄마가 보고 싶은데, 만나면 또 싸울 것 같아요”는 그리움(긍정)과 불안(부정)이 섞인 혼합 감정이다. AI에게 “긍정/부정” 두 가지만 분류하라고 하면 이런 미묘함을 놓친다. “혼합” 카테고리를 추가하면 상담의 현실에 더 가까운 분석이 나온다.

이 분석의 활용은 두 갈래다. 첫째, 한 회기 안에서 내담자의 감정이 어떻게 흘러갔는지를 본다. 50분 동안 어떤 주제에서 감정이 올라갔고, 상담사의 어떤 개입 후에 누그러졌는지를 추적한다. 둘째,여러 회기에 걸쳐 부정적 감정의 비율이 줄고 긍정적 감정이 느는 추세를 본다. 이건 치료가 진전되고 있다는 하나의 지표가 된다.

칼 로저스

감정은 상담 과정의 핵심 나침반이다. 내담자가 무엇을 느끼는지를 정확히 파악하는 것이 모든 치료적 개입의 출발점이다.

— Rogers (1961)

주제 추출과 회기 요약: 50분을 3분으로 압축하기

주제 추출(topic extraction)은 축어록에서 반복적으로 나오는 핵심 주제를 자동으로 뽑아내는 것이다. “이 축어록의 핵심 주제 3~5개를 추출하고, 각 주제의 빈도와 감정적 맥락을 설명하라”는 프롬프트를 보내면 된다. 예를 들어 AI가 “1. 직장 상사와의 갈등 (빈도 높음, 부정 감정), 2. 자기 효능감 저하 (빈도 중간, 부정 감정), 3. 여자친구와의 관계 (빈도 낮음, 혼합 감정)”이라고 추출했다고 하자. 이걸 여러 회기에 걸쳐 추적하면, “직장 갈등” 주제가 줄어들고 “자기 수용” 주제가 새로 등장하는 흐름을 볼 수 있다.

회기 요약 보고서는 축어록 분석의 최종 결과물이다. (1) 회기 요약 2~3문장, (2) 내담자 주요 감정, (3) 핵심 주제, (4) 상담사 개입 전략, (5) 다음 회기 제안. 프롬프트에 이 형식을 명시하면, 매번 같은 구조의 보고서가 나와서 회기 간 비교가 쉽다. 5번째 항목인 “다음 회기 제안”은 특히 주의가 필요하다. AI의 제안은 참고 자료일 뿐, 상담사가 직접 판단해야 한다.

Gainer(2025)는 이런 자동 보고서가 상담사의 기록 시간을 60~70% 줄여준다고 추정하면서도, “AI 보고서를 그대로 쓰는 건 임상적 판단을 AI에 맡기는 것”이라 경고한다. 올바른 사용법은 이렇다 — AI가 초안을 만들면, 상담사가 읽으면서 “이건 맞다, 이건 다르다, 이건 빠졌다”를 수정한다. 특히 Assessment(임상적 판단) 부분은 반드시 상담사가 직접 작성하거나 AI 초안을 꼼꼼히 검토해야 한다.

조지프 와이젠바움

컴퓨터가 특정 영역에서 인간의 판단을 대체해서는 안 된다. 특히 상담처럼 진정한 이해가 필요한 영역에서는. 기계의 분석은 참고 자료이지, 최종 답이 아니다.

— Weizenbaum (1976)

API 비용과 데이터 보안

AI API는 토큰(token) 단위로 과금된다. 1 토큰은 영어 약 4글자, 한국어 약 1~2글자다. 50분 상담 축어록은 한국어 기준 약 5,000~8,000자이고, 분석 프롬프트와 응답까지 합치면 회당 약 100~150원 정도가 든다. 월 20회기를 진행하면 월 2,500~4,000원 수준이다. 커피 한 잔 값으로 20회기분의 자동 분석을 돌릴 수 있다. 다만 모델에 따라 가격 차이가 크다. GPT-4 급 고성능 모델은 GPT-3.5 급보다 10~30배 비싸다. 축어록 분석은 정확성이 중요하므로 고성능 모델이 적합하지만, 비용을 고려하면 먼저 저렴한 모델로 테스트해보고 결과가 부족할 때만 상위 모델을 쓰는 전략이 현명하다.

더 중요한 건 보안이다. 상담 축어록에는 내담자의 이름, 직장명 같은 개인 정보와 민감한 심리 정보가 들어 있다. 이게 미국 서버로 전송된다. 대책은 세 가지다. 첫째, 비식별화 — 이름, 날짜, 장소 같은 식별 정보를 제거한 뒤 API에 보낸다. 둘째, 전송 암호화 — HTTPS로 데이터가 이동 중에 암호화된다. 셋째, 데이터 보존 정책 확인 — OpenAI와 Anthropic 모두 API로 받은 데이터를 AI 훈련에 사용하지 않겠다고 밝히고 있지만, 가장 확실한 방법은 자체 서버에서 오픈소스 모델을 돌리는 것(온프레미스)이다.

비식별화를 좀 더 구체적으로 살펴보자. 단순히 이름만 바꾸면 될까? 그렇지 않다. “강남에 있는 그 대학교”라는 표현만으로도 누구인지 추론할 수 있다. 나이, 직업, 가족 구성, 거주 지역을 조합하면 개인 식별이 가능한 경우가 많다. 완전한 비식별화는 이런 “간접 식별자(quasi-identifier)”까지 제거하거나 일반화하는 것이다. “강남에 있는 대학교”를 “서울 소재 대학교”로, “28세”를 “20대 후반”으로 바꾸는 식이다.

실습에서 축어록을 API에 보내기 전에, 반드시 비식별화 과정을 거쳐야 한다. 가상 데이터를 쓰면 이 문제가 없지만, 실제 상담 데이터를 쓸 때는 비식별화가 법적 의무다. AI에게 “다음 텍스트에서 모든 개인 식별 정보를 제거해줘”라고 먼저 요청하고, 그 결과를 사람이 확인한 뒤에 분석 API로 보내는 2단계 절차를 권장한다.

유발 노아 하라리

데이터는 21세기의 가장 가치 있는 자산이다. 그리고 인간의 심리 데이터는 모든 데이터 중 가장 민감하다. 이 데이터를 누가 소유하고, 어떻게 사용하느냐가 개인의 자유를 결정한다.

— Harari, Nexus (2024)

정리하면, API는 상담사에게 AI의 분석 능력을 연결해주는 다리다. 이 다리를 안전하게 건너려면 세 가지를 기억해야 한다. 시스템 프롬프트를 명확하게 쓰고, 출력 형식을 구조화하고, 데이터 보안을 확보한다. 다음 실습에서 이 세 가지를 직접 손으로 해볼 것이다.

축어록 분석 파이프라인 만들기

이번 실습에서는 AI API를 연동해서 상담 축어록을 자동으로 분석하는 도구를 만든다. 파이프라인(데이터가 처리되는 흐름)은 세 단계다. 첫째, 축어록을 입력하는 화면. 둘째, AI API로 정서 분석·주제 추출·회기 요약을 돌리는 백엔드(서버 쪽 코드). 셋째, 결과를 보기 좋게 보여주는 시각화 화면. Replit Agent에게 “OpenAI API를 사용한 축어록 분석 도구를 만들어줘”라고 지시하면 기본 구조를 생성해준다.

파이프라인이란 말이 어렵게 느껴질 수 있다. 공장의 컨베이어 벨트를 떠올려보자. 원재료(축어록)가 들어가면, 첫 번째 공정(정서 분석)을 거치고, 두 번째 공정(주제 추출)을 거치고, 세 번째 공정(회기 요약)을 거쳐서 최종 제품(분석 보고서)이 나온다. 각 공정은 독립적이지만, 순서대로 연결되어 있다. 이번 실습에서는 이 컨베이어 벨트를 직접 만들어보는 것이다.

먼저 가상 축어록을 만든다. 실무에서는 meeting.tobl.ai 같은 실시간 AI 전사 서비스로 상담 대화를 바로 텍스트로 변환하지만, 이번 실습에서는 직접 가상 데이터를 작성한다. 상담사와 내담자의 대화 20턴(한 번 말하는 것이 1턴)을 작성한다. 주제는 “취업 스트레스와 가족 갈등”으로 잡고, 내담자의 감정이 초반 불안 → 중반 분노 → 후반 수용으로 변하는 흐름을 반영한다. 이 흐름을 미리 정해놓으면, 나중에 AI 분석 결과가 맞는지 비교할 수 있다. “정답”을 알고 있는 데이터로 테스트하는 것이다. 이걸 “골드 스탠다드(gold standard, 정답이 알려진 기준 데이터)” 라고 부른다.

안드레이 카르파시

좋은 AI 시스템을 만들려면 좋은 테스트 데이터가 먼저다. 정답을 아는 데이터로 테스트해야, AI가 맞게 작동하는지 검증할 수 있다.

— Karpathy (2024)

프롬프트 엔지니어링: 정확한 결과를 뽑는 기술

AI에게 막연하게 “이거 분석해줘”라고 하면 막연한 답이 온다. 정확한 결과를 얻으려면 프롬프트를 정밀하게 설계해야 한다. 네 가지를 명시한다. 첫째, 역할 — “당신은 상담심리 전문가로서 축어록을 분석합니다.” 둘째, 분류 기준 — 정서 레이블(긍정/부정/중립/혼합)과 강도 척도(1-5)를 정확히 정의한다. 셋째,출력 형식 — 원하는 JSON 형태를 예시와 함께 보여준다. 넷째, 제약 조건 — “개인 식별 정보를 출력에 넣지 마세요”, “진단을 내리지 마세요” 같은 안전 규칙.

이 네 가지 중 “출력 형식 예시”가 가장 효과적이다. AI에게 “JSON으로 출력해줘”라고만 하면, AI마다 다른 구조의 JSON을 만든다. 하지만 구체적인 예시를 보여주면 — “이런 형태로 출력해줘: [{화자: 내담자, 정서: 부정, 강도: 4, 핵심감정: 불안}]” — AI가 그 형태를 정확하게 따른다. 이걸 “퓨샷 프롬프팅(few-shot prompting, 예시를 보여주며 가르치는 방법)”이라고 부른다.

앨리슨 다시

AI 도구의 품질은 결국 프롬프트의 품질이 결정한다. 상담사가 내담자에게 올바른 질문을 해야 좋은 답을 얻듯, AI에게도 올바른 지시를 해야 정확한 분석을 얻는다.

— Darcy (2021)

Gainer(2025)는 프롬프트에 “상담적 민감성”을 반영하라고 조언한다. 예를 들어, 그냥 “부정적 감정”으로 뭉뚱그리지 말고, “슬픔” “분노” “불안” “수치심” 등 구체적 감정 어휘를 분류 체계에 넣으면 분석 결과가 상담에 바로 쓸 수 있을 만큼 정교해진다. 한국어 감정 어휘의 미묘한 차이도 반영하자. “서운하다” “섭섭하다” “야속하다”는 영어로는 모두 “disappointed”에 가깝지만, 한국어에서는 각각 다른 관계적 맥락을 담고 있다.

API Key 보안: 비밀번호를 코드에 적지 마세요

API Key는 절대로 소스 코드에 직접 쓰면 안 된다. GitHub 같은 공개 저장소에 올라가면 수 분 안에 자동 봇이 스캔해서 무단 사용이 생긴다. 실제로 GitHub에 API Key를 실수로 올린 개발자가 하룻밤 사이에 수십만 원의 청구서를 받은 사례가 있다. 봇이 자동으로 Key를 찾아서 AI API를 대량 호출한 것이다.

Replit에서는 Secrets(환경 변수) 기능을 쓴다. 왼쪽 사이드바의 자물쇠 아이콘 → 키 이름(OPENAI_API_KEY)과 값을 등록 → 코드에서process.env.OPENAI_API_KEY로 접근. API 호출은 반드시 서버(백엔드)에서만 하고, 브라우저(프론트엔드)에서는 Key에 접근할 수 없도록 분리해야 한다. 프론트엔드에 Key를 넣으면, 브라우저의 “개발자 도구”에서 누구나 Key를 볼 수 있기 때문이다.

API Key 외에도 보안에서 신경 쓸 부분이 있다. API 호출 시 사용량 제한 (rate limiting)을 설정해야 한다. 누군가 우리 앱을 악용해서 대량의 API 호출을 보내면, 비용이 폭증할 수 있다. OpenAI 대시보드에서 월간 사용 한도를 설정하면 이런 상황을 방지할 수 있다. 학생 프로젝트에서는 월 5달러 정도로 한도를 걸어놓으면 실수로 과금되는 걸 막을 수 있다.

제이콥 닐슨

보안은 사용자가 신경 쓰지 않아도 시스템이 알아서 지켜주는 것이어야 한다. 좋은 보안은 투명하되 견고하다.

— Nielsen (2020)