🤖 대형언어모델 시대의 질적 연구: 코딩을 GPT에게 맡겨도 될까?
요즘 ChatGPT 같은 대형 언어 모델(LLM)이 자연어를 무척 잘 다룬다는 소문, 많이 들어보셨죠? 논문 요약부터 창작, 번역까지 척척 해내는데… 그럼 한 가지 질문이 생깁니다.
“그럼 혹시 질적 연구에서 코드북 만들고 코딩하는 일도 GPT가 대신 해줄 수 있을까?”
이 질문에 아주 정교하고 현실적인 답을 제시한 논문이 나왔습니다. 바로 Zackary Okun Dunivin의 2025년 논문,
📄 “Scaling hermeneutics: a guide to qualitative coding with LLMs for reflexive content analysis” 입니다.
이 글에서는 이 논문을 토대로, LLM이 질적 코딩에 어떻게 활용될 수 있는지, 어떤 이론과 방법론에 기반하고 있는지, 그리고 어떤 점을 주의해야 하는지를 하나하나 살펴보려고 해요.
✨ 질적 코딩은 단순한 태깅이 아니다
질적 코딩(qualitative coding)은 많은 사람들이 생각하는 것처럼 단순히 텍스트에 라벨을 붙이는 작업이 아니에요. 사실은, 텍스트와 연구자 사이의 해석적 상호작용을 통해 개념을 구성하고, 의미를 조직하고, 이론을 발전시키는 창조적인 과정이에요.
이러한 코딩의 해석적 성격은 오랜 질적 연구 전통에서 강조되어 왔습니다. 예를 들어, **Strauss와 Corbin(1997)**은 코딩을 “이론 생성을 위한 체계적인 전략”으로 보았고, **Saldaña(2021)**는 코딩을 단순한 데이터 정리가 아니라 “분석과 해석의 출발점”이라고 강조했습니다. 특히 질적 코딩은 Grounded Theory의 핵심 도구로, 자료로부터 이론을 도출해내는 과정에서 매우 중요한 역할을 하죠 (Glaser & Strauss, 1967).
또한, **Gadamer(1975)**의 해석학적 전통에 따르면, 이해란 단순히 정보를 받아들이는 것이 아니라, 연구자의 선이해와 질문이 결합되어 생성되는 능동적인 과정이에요. 즉, 코딩은 의미를 ‘발견’하는 게 아니라, 연구자가 ‘형성’하는 거예요.
✅ 요약하면, 질적 코딩은 단순한 분류작업이 아니라, 연구자가 텍스트와 지속적으로 ‘대화’하며 사회적 맥락과 개념을 구성해가는 반복적이고 해석적인 학문적 실천이라는 점이에요.
🧠 LLM을 활용해도 ‘해석학적 깊이’를 유지할 수 있을까?
자, 그런데 요즘 들어 우리가 고민하게 되는 질문 하나가 있죠.
“GPT 같은 LLM을 질적 코딩에 활용하면, 이런 해석학적 깊이는 유지할 수 있을까?”
많은 사람들이 LLM이 자동화된 분류(classification)는 잘하지만, 정교한 해석적 작업에는 한계가 있다고 생각해요. 실제로도 **Malik(2020)**은 기존 머신러닝 모델들이 복잡한 사회적 의미나 맥락을 포착하는 데 구조적인 한계를 가지고 있다고 지적했습니다.
하지만 이 논문에서 제시하는 해법은 그저 ‘대체’가 아니라 보완입니다. GPT를 활용하되, 코드북(codebook)은 사람이 먼저 만들고, 그 코드북을 GPT가 이해할 수 있도록 다시 작성한 뒤, 모델이 코딩한 결과를 사람이 검토하고 수정하는 방식이에요.
이러한 방식은 **Nelson(2017)**의 ‘Computational Grounded Theory’ 접근과도 연결돼요. 그는 질적 전통에서 사용하는 반복적 정의-검토-수정의 사이클이 자동화된 환경에서도 동일하게 유지되어야 한다고 주장했죠. 이 논문은 바로 그 원칙을 LLM에 맞춰 구체화한 사례입니다.
뿐만 아니라, 이 과정에서 LLM을 훈련시키는 것이 아니라, 오히려 연구자가 자신의 해석적 직관을 명확히 언어화하고 구조화하면서, 연구의 이론적 기반이 더 정교해지는 효과도 있다고 저자는 강조해요.
✅ 즉, 이 논문의 관점은 GPT가 인간의 해석적 작업을 ‘대체’하는 것이 아니라, 연구자가 이미 만든 해석의 틀을 확장하고 반복 적용할 수 있도록 돕는 도구로 활용하자는 제안이에요.
🛠️ 코드북을 LLM이 이해할 수 있도록 재설계하기
자, GPT에게 코딩을 맡기기 전에 반드시 해야 하는 일이 있어요. 바로, 코드북(codebook)을 LLM에 맞게 다시 쓰는 작업입니다. 왜 그럴까요?
사람 연구자는 코드북을 읽을 때 그동안의 경험, 이론적 배경, 그리고 동료와의 토론 같은 **‘암묵적 맥락’**을 함께 활용해요. 그런데 GPT는 이 모든 걸 모르고, 글자 그대로의 설명만 보고 판단해야 하죠.
그래서 저자는 다음과 같은 과정을 통해 **“LLM 친화적인 코드북”**으로 코드 설명을 재작성했습니다.
🔄 코드 설명 수정의 실제 예시
예시 1: "Academic Repute" → "Out of the Mouth of Academics"
- 원래 이 코드는 Du Bois에 대해 학계 구성원이 그를 언급했을 때를 의미했는데요,
- GPT는 이 코드를 "Du Bois가 학자로서 얼마나 존경받았는지"로 오해했어요.
- 그래서 코드명을 아예 **“학자의 입을 통해 나온 말(Out of the Mouth of Academics)”**로 바꾸고,
- 설명도 “Du Bois에 대해 말하는 ‘사람’이 학자일 때”로 명확히 수정했습니다.
✅ LLM은 단어의 뉘앙스를 모호하게 해석하므로, 코드명을 직관적이고 구체적으로 바꾸는 것만으로도 성능이 크게 개선됩니다.
예시 2: "Activism" → "Advocacy"
- GPT는 Du Bois가 쓴 글 속에서 사회를 비판한 내용이 있어도 “행동(activism)”이라고 인식하지 않았어요.
- 그래서 연구자는 “social/political advocacy”로 코드를 바꾸고, “사회적 비판이나 담론”도 포함되도록 설명을 수정했습니다.
- 또한 “explicitly or implicitly referenced”라는 문구를 추가해, 문장에 드러나지 않아도 맥락을 통해 파악할 수 있는 경우까지 포함시켰어요.
📌 이 과정에서 얻은 교훈
- 모호한 표현은 GPT가 오독할 가능성이 큽니다.
인간은 괜찮다고 느끼는 코드 설명도, GPT에겐 애매하게 느껴져요. - '어디까지 포함되고, 어디서부터는 안 되는지'를 명확히 써줘야 해요.
특히 '언급은 되었지만 본질적인 건 아닌 경우'에 대한 판단 기준을 정리해줘야 해요. - 코드마다 GPT가 혼동할 수 있는 지점을 사전에 파악해서 보완하는 것이 핵심입니다.
🔁 이 과정은 단순히 ‘GPT 친화적’으로 바꾸는 걸 넘어서, 오히려 연구자 스스로가 자기 코드를 더 명확하게 정리할 수 있게 만들어주는 훈련이 되기도 해요.
💬 Chain-of-Thought: GPT도 ‘이유’를 설명하게 하라!
GPT에게 “이 문단에 어떤 코드를 적용할래?”라고 묻는 것만으로는 부족합니다. 이 논문에서 아주 중요한 전략이 하나 등장하는데요, 바로 Chain-of-Thought(연쇄적 사고) 방식의 프롬프트 디자인이에요.
🤔 Chain-of-Thought(CoT)란?
Chain-of-Thought는 GPT가 단순히 답만 내놓는 게 아니라, “왜 그 답을 골랐는지” 과정을 설명하게 하는 방식이에요.
이 논문에서는 이 방식을 다음과 같이 적용했어요:
이렇게 GPT에게 reasoning 과정을 요구하면 다음과 같은 효과가 생겨요:
✅ Chain-of-Thought의 장점
- 모델이 코드를 잘못 적용한 이유를 분석할 수 있어요.
- 어떤 코드를 왜 골랐는지 설명하게 하면, 그 설명에서 코드 설명 자체의 모호성을 발견할 수 있어요.
- 연구자는 이를 기반으로 코드북을 더 명확하게 수정할 수 있어요.
- GPT의 응답 품질이 실제로 좋아집니다.
- 이 논문에서는 CoT 프롬프트를 사용했을 때 Cohen's κ 수치가 평균 0.59 → 0.68로 향상되었어요.
- 특히 GPT-4의 경우, Chain-of-Thought를 적용하면 GPT-3.5보다 월등한 수준의 일치율을 보였습니다.
- 신뢰도 높은 자동 코딩이 가능해집니다.
- GPT가 스스로 판단 근거를 제시하고, 그것을 바탕으로 코드를 적용하므로,
- 연구자는 그 이유를 보고 오류 여부를 판단하거나, 신뢰도를 높일 수 있어요.
📋 실제 프롬프트 예시 (논문 Fig. 2 참조 요약)
이처럼 Chain-of-Thought는 GPT를 단순한 기계가 아니라, 마치 사람 연구자처럼 "왜 그렇게 판단했는지"를 묻고, 그 사고과정을 들여다볼 수 있게 만들어주는 훌륭한 전략이에요.
🧠 정리하자면...
- 코드북을 LLM이 이해하도록 수정하려면, 모든 설명을 ‘글자 그대로’ 이해할 수 있도록 바꿔야 합니다.
- 그 다음, GPT에게 단순히 “분류해줘”가 아니라 **“왜 그 코드를 적용했는지도 말해줘”**라고 프롬프트를 설정해야 해요.
- 이 두 단계를 함께 쓰면, GPT도 정확하게, 설명 가능하게, 신뢰할 수 있는 방식으로 질적 코딩을 도와줄 수 있습니다.
📊 주요 결과 정리
- GPT-4는 대부분 코드에서 인간 연구자 수준의 성과를 보였습니다. (Cohen’s κ > 0.6)
- 특히, Activist, Memorialization, Collective Synecdoche 코드에서는 0.75를 넘는 ‘탁월한 일치’.
- 반면 GPT-3.5는 평균 κ = 0.34로 GPT-4보다 성능이 크게 떨어짐.
- 전체 코드북을 한꺼번에 주는 것보다, 코드 하나하나 따로 주는 방식(Per-Code Prompting) 이 훨씬 성능이 좋았음.
- CoT 프롬프트(설명 요구)를 쓰면 성능이 더 좋아짐.
💡 이 논문이 주는 실용적 메시지
이 논문은 단순히 “GPT가 질적 코딩 잘함”이라고 말하지 않아요. 오히려 다음과 같은 실용적 팁을 줍니다:
- GPT는 도우미이지, 해석 주체가 아니다.
사람이 만든 코드북과 이론이 우선입니다. - 프롬프트 디자인이 전부다.
코드 설명을 어떻게 쓰느냐, 이유 설명을 요구하느냐가 성능을 좌우합니다. - GPT-4는 강력하지만, 지속적으로 검증해야 함.
같은 이름의 GPT-4라도 버전에 따라 성능이 달라질 수 있어요. - 오히려 질적 연구가 더 중요해졌다.
LLM을 쓰려면 코드북을 훨씬 명확하게 정리해야 하므로, 해석력과 이론적 감각은 더욱 요구됩니다.
🧵 마무리: 질적 연구와 LLM의 멋진 만남
이제는 단순히 "코딩을 자동화하자"는 시대가 아닙니다. “어떻게 하면 해석적 깊이를 유지하면서 LLM의 힘을 잘 활용할 수 있을까?” 이게 더 중요한 질문이 된 시대예요.
이 논문은 그 질문에 대해 매우 구체적이고 실용적인 가이드를 줍니다. 정리하자면,
GPT는 당신의 질적 연구를 대신해주진 않아요.
하지만 당신의 코드북이 충분히 정교하고, 해석적 감각이 살아있다면,
GPT는 ‘작은 조수’로서 방대한 텍스트 분석을 가능하게 해줄 수 있습니다.