학생 100명의 실험에서 본 AI 사용 빈도와 결과물 품질

코드가 한 줄도 보이지 않는 화면 앞에 100명이 앉았어요

취리히의 한 실험실에서 학생 100명이 코드가 전혀 보이지 않는 화면 앞에 앉았어요. 왼쪽에는 채팅창, 오른쪽에는 만들어지는 앱의 미리보기, 그리고 15분짜리 타이머가 놓여 있었어요.

과제는 세 개였어요. 이미 돌아가는 앱을 직접 써본 뒤 똑같이 만들기, 거기에 기능 하나 더 붙이기, 그리고 무슨 용도인지 알 수 없게 라벨을 지운 앱을 복제하기. 참가자가 할 수 있는 건 프롬프트를 쓰는 것뿐이었어요. 모델이 코드를 뱉는 화면은 진행 중이라는 것만 알 수 있게 일부러 흐리게 처리해 뒀거든요.

참가자는 55스위스프랑을 받고 한 시간 45분짜리 세션에 들어왔어요. 컴퓨터공학 입문 과목을 이수했고 LLM으로 프로그래밍을 해본 적이 있는 사람만 뽑았어요. 완전한 초보도 아니고 현업 개발자도 아닌 층이에요.

ETH 취리히 연구진이 이 실험을 사전등록¹하고 돌린 이유는 단순해요. 코드를 아예 만지지 않고 소프트웨어를 만드는 방식이 빠르게 퍼지고 있는데(흔히 말하는 바이브 코딩이죠.), 그 방식에서 누가 잘하는지는 아무도 측정해 본 적이 없거든요.

결과는 3월에 공개됐고, 최근 링크드인에서 요약본이 돌기 시작했어요. 그 요약본이 논문에 없는 문장을 결론으로 만들어 놓았어요. 그리고 논문 안에 실제로 있는 숫자 하나는 통째로 빠졌어요.

---

링크드인이 ‘개발자 100명’이라고 부른 사람들

돌고 있는 요약본의 골자는 이래요. ETH가 개발자 100명을 상용급 환경에서 시험했고, 결과는 잔혹했고, 컴퓨터공학 지식이 압도적인 예측 변수였고, 결국 바이브 코딩은 코드를 쓰는 게 아니라 로직을 디버깅하는 일이라는 것.

원문과 맞춰보면 이렇게 갈려요.

요약본	논문
개발자 100명	ETH·취리히대 학생 100명. 평균 25세, 공학·기술 51명, 자연과학 20명, 인문사회 11명
상용급 환경	상용 도구를 참고해 연구진이 직접 만든 실험용 플랫폼. 코드를 아예 안 보여준다는 점에서 상용 도구와 다름
압도적 예측 변수	CS 성취2와 성과의 상관은 0.39. 글쓰기까지 넣은 모델의 설명력은 20.8%
잔혹한 결과	바이브 코딩 평균 점수는 1점 만점에 0.45. 전원이 고전했음
코드를 보고 로직을 디버깅하는 일	참가자는 코드를 볼 수 없었음. 저자들은 인과 주장을 명시적으로 거부하고 문제 분해 능력을 가설로만 제시

하나는 맞아요. 컴퓨터공학 성취가 글쓰기보다 고유 설명력을 두 배쯤 더 가져간 건 사실이에요. 글쓰기를 먼저 넣고 CS를 더하면 설명력이 12.5%포인트 오르고, 순서를 뒤집으면 5.9%포인트가 올라요.

다만 글쓰기와 성과의 관계는 다른 조건을 함께 고려하면 달라졌어요. 일반 인지능력³을 통제하자 글쓰기와 성과의 관계는 통계적 유의성을 잃었어요. 부분상관⁴ 0.186, p값 0.066이에요. 같은 조건에서 CS 성취와 성과의 관계는 통계적으로 유의했어요.

그리고 논문 본문이 아니라 탐색적 분석에 묻혀 있던 숫자가 하나 있어요.

참가자가 스스로 보고한 LLM 사용 빈도는 바이브 코딩 성과와 음의 상관을 보였어요. 상관계수 −0.258, p값 0.010이에요. 이게 무슨 뜻이냐? 자주 쓴다고 답한 사람일수록 더 못 만들었다는 뜻이에요. 글쓰기 점수와도 −0.282로 음의 상관이었고, CS 성취와는 0.001, 사실상 무상관이었어요.

어떤 지표가 과제 성적과 관련이 있었을까요

먼저 −0.258을 어떻게 읽어야 하는지부터 정리할게요. 저자들도 이 결과에 놀랐다고 적었고, 세 가지 설명을 나란히 놓았어요. LLM이 표현 능력을 떨어뜨렸을 수 있고, 원래 글을 잘 못 쓰는 사람이 LLM에 더 의존할 수 있고, 둘 다일 수도 있다는 거예요. 자기보고 척도이고, 표본은 학생 100명이고, 사전등록된 확증 가설이 아니라 사후 탐색이에요. 그러니까 이 숫자로 “AI를 많이 쓰면 바보가 된다”는 문장을 만들면 안 돼요. 요약본이 저지른 잘못을 반대 방향으로 반복하는 거니까요.

연구진이 조심스럽게 설계했다는 근거도 몇 개 있어요. 절반은 설문을 먼저 풀고 절반은 과제를 먼저 풀게 순서를 섞었는데, 두 집단의 성과 평균은 0.446과 0.448로 사실상 같았어요. 에세이를 먼저 쓴 게 프롬프트를 잘 쓰게 만든 건 아니라는 뜻이에요. 사전에 등록한 가설 하나는 아예 기각됐고요. 맥락이 지워진 과제일수록 글쓰기가 더 중요할 거라고 예상했는데, 실제로는 기능 추가 과제와 차이가 없었어요. 참고로 세 과제 중 성적이 가장 낮았던 게 그 탈맥락 과제였어요. 1점 만점에 0.34였거든요.

한 가지 단서를 더 붙여야 해요. 실험에 쓰인 모델은 2025년 5월 버전의 클로드 소네트 4였어요. 모델이 한 세대 바뀌면 프롬프트의 빈틈을 알아서 메워주는 정도가 달라지고, 그러면 글쓰기와 성과의 관계도 같이 흔들려요. 이 연구의 숫자는 특정 시점의 모델을 사용한 실험 결과예요.

이 결과를 보면 사용 빈도만으로 AI 활용 역량을 판단하기는 어려워요. 적어도 이번 학생 표본에서는 사용 빈도가 높은 사람이 더 좋은 결과물을 만들었다고 볼 수 없었어요.

이번 연구에서 과제 성적과 가장 높은 상관을 보인 지표는 참가자가 작성한 프롬프트의 품질이었어요.

참가자가 실제로 작성한 프롬프트의 품질이 성과와 0.479로 상관했어요. 이 논문 전체에서 가장 큰 계수예요. 에세이 채점 루브릭을 만든 어학센터 강사진이 프롬프트용 루브릭을 따로 설계했고, 다른 데이터를 전혀 못 본 전문가 한 명이 눈가림 상태로 채점했어요. 일관성, 과제에 맞는 복잡도, 지시의 명확성을 봤어요.

매개분석⁵ 결과는 더 명확해요. 글쓰기 능력에서 성과로 가는 경로의 약 52%를 프롬프트 품질이 매개했고, 프롬프트 품질을 모델에 넣자 글쓰기의 직접 효과는 유의성을 잃었어요. 이 분석에서는 글쓰기와 성과의 관계를 프롬프트 품질이 상당 부분 설명했어요. 다만 횡단면 연구의 매개분석만으로 인과관계나 유일한 작동 경로가 입증되는 것은 아니에요. “코딩을 잘한다 = 인공지능을 잘 쓴다.”도 아니고, “인공지능을 잘쓴다. = 글을 잘 쓴다.”도 아닌 거죠.

기계적으로도 교차 확인했어요. 프롬프트의 어휘 다양성을 자동으로 재는 지표 두 개를 계산했는데, 어휘가 다양한 프롬프트를 쓴 사람일수록 에세이 점수도 높았고 과제 성적도 높았어요. 사람이 눈으로 채점한 결과와 기계가 센 결과가 같은 방향을 가리켰다는 뜻이에요.

한 가지 더 있어요. CS 성취와 글쓰기 능력은 서로 상관이 없었어요. 0.126, p값 0.213이에요. 이번 표본에서는 두 점수 사이에 통계적으로 유의한 상관이 확인되지 않았어요. 한 사람이 두 능력을 함께 갖추거나 키울 수 없다는 뜻은 아니에요.

그런데 조직은 왜 하필 사용량을 세고 있을까요

여기서 원문이 끝나고 제 해석이 시작돼요.

지금 대부분의 조직이 AI 도입을 보고할 때 쓰는 숫자는 세 가지예요. 계정 수, 주간 활성 사용자, 토큰 소비량. 세 개의 공통점은 전부 사용 빈도의 변형이라는 거예요. 세기 쉽고, 콘솔에서 바로 나오고, 위로 올라가면 도입이 잘 되는 것처럼 보이거든요.

이 실험이 불편한 건 그 지표가 이번 표본에서 부호까지 반대였다는 점이에요. 물론 학생 100명의 15분짜리 실험실 과제를 기업 현장에 그대로 옮길 순 없어요. 다만 방향이 반대로 나온 지표를 근거로 예산과 인력 배치를 정하고 있다면, 최소한 우리 조직에서는 사용량과 산출물 품질이 어떤 관계인지 확인해 봐야 해요.

저는 사용량 지표가 계속 쓰이는 이유 중 하나가 관리하기 쉽기 때문이라고 봐요. 계정 수는 계약을 늘리면 바로 바뀌지만, 산출물 품질은 별도로 평가해야 해요. 그래서 도입 현황을 보고하는 숫자와 실제 성과를 평가하는 숫자를 함께 봐야 해요.

사용 현황과 결과물의 품질을 나눠 측정해 볼 수 있어요. 아래의 조직 적용 방안은 논문의 직접 검증 결과와 구분해야 해요.

지금 세는 것	이 연구가 시사하는 것
계정 수, 활성 사용자	조직 도입 현황 지표. 연구가 직접 측정한 것은 개인의 자기보고 LLM 사용 빈도이며 성과와의 상관은 −0.258
토큰 소비량	이 연구에서 직접 검증하지 않음. 조직의 산출물 품질과 별도로 비교할 항목
사용 시간	이 연구의 자기보고 사용 빈도와 구분해야 함
프롬프트 품질	성과와 0.479, 이 연구의 최대 계수
산출물 채점	저자들이 실제로 쓴 방식. 4점 척도 루브릭

프롬프트 품질을 재는 게 비현실적으로 들릴 수 있는데, 이 논문은 그 루브릭을 보조자료로 공개했어요. 일관성, 과제 복잡도 대비 적절성, 지시의 명확성 세 축이에요. 팀이 이미 쓰고 있는 코드 리뷰나 기획서 리뷰에 붙일 수 있는 수준이에요.

한국 조직에는 이 대비가 더 아프게 와요. 지난 206호에서 다뤘듯이 한국은 AI에 매달리는 시간 자체가 이미 다른 나라보다 길어요. 그 시간이 곧 역량이라고 가정해 온 셈인데, 이 연구는 그 가정에 최소한 물음표 하나를 붙여요. 사용 시간과 함께 실제로 작성한 프롬프트와 결과물의 품질도 살펴보자는 뜻이에요.

당장 해볼 수 있는 일은 크지 않아요. 지난 분기에 팀이 AI로 만든 산출물 열 개를 고르고, 그때 쓴 프롬프트를 함께 꺼내서 세 축으로 채점해 보면 돼요. 프롬프트 점수와 결과물 점수, 사용량이 어떤 관계인지 비교하는 출발점으로 삼을 수 있어요. 열 개의 사례만으로 조직 전체의 관계를 확정하기보다는, 평가 기준을 맞추고 표본을 늘려 확인하는 편이 좋아요.

오스왈드의 시선

저는 이 논문의 진짜 발견이 상관계수가 아니라 실험 설계에 있다고 봐요.

연구진은 프롬프트를 결과가 아니라 자료로 취급했어요. 100명이 남긴 프롬프트 전체를 하나의 단위로 놓고, 루브릭을 만들고, 눈가림 채점을 붙였어요. 대부분의 조직은 프롬프트를 그냥 흘려보내요. 로그에는 남지만 아무도 읽지 않고, 아무도 채점하지 않아요. 우리가 AI 역량을 못 재는 이유는 재는 도구가 없어서가 아니라 재야 할 대상을 자료로 보지 않아서예요.

프롬프트를 자료로 보기 시작하면 따라오는 게 하나 더 있어요. 잘 쓴 프롬프트가 팀 안에서 재사용되기 시작해요. 각자의 채팅창에만 두던 프롬프트도 평가하고 공유하면 팀에서 다시 쓸 이유가 생기거든요. 그래서 사실 프롬프트는 공유하고 개선하는 반복 작업을 해야 더 좋아진다는 의미 이고, 어디서나 통하는 소위 만능 프롬프트는 사실 없다는 결론에 도달하게 되어요.

두 번째로 눈에 걸린 건 CS 성취와 글쓰기 점수 사이에 유의한 상관이 확인되지 않았다는 대목이에요. 저는 이를 보고 두 능력을 따로 평가해 볼 필요가 있겠다고 생각했어요. 팀에서는 구조를 분해하는 사람과 의도를 문장으로 잘 설명하는 사람이 협업할 수도 있겠죠. 다만 팀 구성이 성과에 미치는 영향은 이 연구가 직접 검증한 내용은 아니에요.

마지막으로 이 글을 쓰게 만든 건 −0.258이 아니라 그 숫자가 요약본에서 사라졌다는 사실이에요. 남은 건 “그러니까 CS를 배워라”였어요. 원래 하고 싶던 말에 맞는 숫자만 살아남은 거죠. 논문 하나가 링크드인 카드 한 장이 되는 동안 설명력 20.8%는 “잔혹한 결과”가 됐고, 코드를 볼 수 없었던 실험은 “로직 디버깅”이 됐어요. 사실 이건 기존의 CS 전공자 및 재직자들에겐 매력적인 말이거든요. 링크드인에선 잘 팔리는 콘텐츠죠.

마치며

구독자님이 지금 어느 위치에 있느냐에 따라 이 연구에서 가져갈 게 달라요.

AI 도입을 보고해야 하는 자리라면, 다음 보고서에서 사용량 지표 하나를 산출물 채점 하나로 바꿔보는 게 출발점이에요. 계정 수는 예산 근거는 되지만 역량 근거는 안 돼요.

사람을 뽑거나 배치하는 자리라면, CS 지식과 글쓰기 능력을 각각 평가해 볼 수 있어요. 이번 표본에서 두 점수의 상관이 유의하지 않았다는 결과를 모든 사람에게 일반화하지는 않아야 해요.

직접 만드는 자리라면, 가장 실용적인 조언은 자기 프롬프트를 다시 읽어보는 거예요. 이 연구에서 성과를 가장 잘 예측한 건 도구를 얼마나 오래 썼느냐가 아니라 무엇을 어떻게 적었느냐였으니까요.

---

💬 팀에서 AI 도입 성과를 보고할 때 지금 어떤 숫자를 쓰고 계신가요. 그 숫자가 실제 산출물의 품질을 잘 설명한다고 느끼시는지 궁금해요.

📨 이번 분기 AI 도입 지표를 정하고 있는 동료가 있다면 이 글을 넘겨주세요. 계정 수를 세기 전에 한 번 보면 좋을 내용이에요.

---

참고자료 & 더 읽기

핵심 출처

• Sverrir Thorgeirsson, Theo B. Weidmann, Zhendong Su, “Computer Science Achievement and Writing Skills Predict Vibe Coding Proficiency”, arXiv, 2026년 3월 14일. CHI 2026 채택 논문. 이 글의 모든 수치가 여기서 나왔어요. 특히 9절 탐색적 분석은 요약본에 거의 인용되지 않으니 직접 보시길 권해요
• 사전등록 문서, AsPredicted. 어떤 가설이 사전에 등록됐고 어떤 결과가 사후 탐색인지 구분하려면 이 문서를 먼저 봐야 해요

배경 지식

• 논문이 사용한 CS 성취 측정 도구는 Parker 외가 개발한 SCS1의 12문항 축약본이에요. 특정 프로그래밍 언어를 전제하지 않고 의사코드로 출제되는 검사예요
• 바이브 코딩이라는 말 자체는 2025년 2월 안드레이 카파시가 붙였어요. 코드의 존재를 잊는다는 원래 정의를 이 논문이 그대로 채택했다는 점이 결과 해석에 중요해요

관련 지난 호

• 206호 「미국의 두 배, 한국이 AI에 매달린 시간」
• 223호 「생산성 92%는 성과일까요, 연기일까요」
• 99호 「모두가 개발을 할 수 있는 시대가 온다는 것은」

필자 안광섭 (오스왈드)은 세종대학교 겸임교수, INLEVEL9 전략 컨설턴트입니다. 경력, 연구, 저서와 최신 활동은 저자 소개에서 계속 갱신합니다. 최근 소식 · 2026년 8월: 2026 세종도서 교양부문 우수도서 선정.

📝 용어 설명

각주

1. 사전등록: 실험을 시작하기 전에 가설, 표본 크기, 분석 방법을 공개 저장소에 등록해 두는 절차예요. 결과를 보고 나서 가설을 바꾸는 걸 막는 장치라 등록된 확증 분석과 사후 탐색 분석을 구분해서 읽어야 해요. ↩

2. CS 성취: 이 연구에서는 SCS1이라는 검사의 12문항 축약본 점수를 뜻해요. 정의 지식, 코드 추적, 코드 완성 세 유형을 각각 네 문항씩 다뤄요. ↩

3. 일반 인지능력: ICAR16이라는 공개 검사로 측정했어요. 언어 추론, 행렬 추론, 문자열 규칙, 3차원 회전 네 유형 16문항으로 구성돼요. ↩

4. 부분상관: 제3의 변수 영향을 걷어낸 뒤 남는 두 변수 사이의 상관이에요. 여기서는 일반 인지능력을 걷어낸 뒤의 값이에요. ↩

5. 매개분석: A가 B에 영향을 줄 때 그 사이에 낀 변수가 얼마나 통로 역할을 하는지 추정하는 방법이에요. 여기서는 글쓰기와 성과 사이에 프롬프트 품질이 놓였어요. ↩