AI가 우리의 측정 도구를 앞질러 버린다면
GPT-6 Astra 출시 이후 다시 불붙은 AGI 논쟁 속에서, 개발자 Hemapriya Kanagala는 다른 질문을 던진다. 모델이 나아졌다는 걸 우리는 대체 무엇으로 확인하고 있나.
What Happens When AI Outgrows the Tests We Use to Measure It?
TL;DR GPT-6 Astra has started another familiar AI conversation. The model is more capable, Jensen...
개요 #
GPT-6 Astra가 나오자 익숙한 순서가 또 반복됐다. 모델 공개, 사용 후기, 벤치마크 점수, 비교, 그리고 큰 질문들. NVIDIA CEO 젠슨 황은 X에 **"AGI가 도래했다(AGI has arrived)"**는 글을 올려 OpenAI에 축하를 전했고, 타임라인은 곧바로 흥분과 불안 사이를 오갔다.
개발자 Hemapriya Kanagala는 이 흐름에서 조금 다른 지점을 짚는다. "AI가 훨씬 유능해졌다"는 말이 "개발자는 이제 필요 없다"거나 "컴퓨터공학은 끝났다"로 건너뛰는 속도가 너무 빠르다는 것이다. 그가 대신 꺼낸 질문은 이쪽이다.
모델이 좋아졌다는 걸, 우리는 대체 무엇으로 아는가?
보통은 벤치마크를 본다. 유용한 도구다. 다만 벤치마크에도 수명이 있고, 포화되기도 하고, 직접 재기 어려운 능력을 대리 지표로 대신하기도 한다. Astra의 시스템 카드 자체가 그 사례를 여럿 담고 있다.
숫자는 나왔다. 그런데 그 숫자가 말해주는 건 뭔가 #
벤치마크에는 편리한 구석이 있다. 모델 A가 82%, 모델 B가 88%라고 하면 어느 쪽이 더 나은지 답이 나온 것처럼 느껴진다. 공통된 시험이 있다는 것만으로도 비교의 출발점이 생기니까, 분명 가치가 있다.
잊기 쉬운 건 벤치마크가 측정 도구라는 점이다. 모델 능력에 대한 증거를 주긴 하지만, 그 자체가 능력은 아니다. 온도계는 온도를 알려주지만 온도계가 곧 온도는 아닌 것처럼.
모델이 좋아질수록 이 구분이 더 중요해진다. 한때 모델 간 차이를 선명하게 보여주던 시험이, 어느 시점부터는 웬만한 모델이 전부 만점 근처에 몰리는 시험이 되기도 한다. 숫자는 여전히 숫자지만, 예전만큼 많은 걸 말해주지는 않는다.
Photo by 모든 벤치마크에는 수명이 있다 #
Astra 시스템 카드에서 흥미로운 대목은 평가 방식의 변화를 꽤 솔직하게 다룬다는 점이다. 기존 평가 중 일부는 상당히 포화됐고, 일부는 은퇴를 검토 중이며, 더 이상 충분한 신호를 주지 못하는 평가를 대체할 새 평가가 들어오고 있다.
납득이 가는 이야기다. 상위 모델들이 97%, 98%, 98%를 받는 시험을 떠올려 보자. 인상적인 성적이긴 한데, 다들 천장에 붙어 있다면 그 1%포인트 차이에서 우리가 배울 게 얼마나 될까.
벤치마크가 나빠진 게 아니다. 우리가 궁금해하는 차이를 더는 드러내지 못하는 지점에 도달했을 뿐이다. 어떤 의미에서는 제 역할을 다한 셈이다. 모델들이 천장에서 멀리 있을 때 진전을 보여줬고, 이제 모델이 충분히 멀리 갔으니 구분할 다른 방법이 필요해진 것이다.
그래서 평가가 은퇴하거나 교체되는 장면을 저자는 실패로 읽지 않는다. 오히려 기술이 앞으로 나갔다는 신호에 가깝다.
모델이 움직였으니, 시험도 움직여야 한다.
92%, 무엇을 기준으로? #
벤치마크 점수를 볼 때 저자가 가장 좋아한다는 질문이다.
92%, 무엇을 기준으로?
쉬운 경우도 있다. 수학 문제는 정답이 정해져 있고, 프로그래밍 문제는 테스트로 확인할 수 있고, 사실 확인 질문은 신뢰할 만한 출처와 대조하면 된다.
복잡해지는 건 과학적 추론이나 생물학적 예측, 명확한 정답이 하나로 떨어지지 않는 긴 과제를 평가할 때다. 여기서 정답 기준(ground truth) 문제가 등장한다. 모델을 평가할 때 옳다고 놓고 비교하는 기준점 말이다. 문제에 따라 전문가 판단일 수도, 실험 데이터일 수도, 시뮬레이션일 수도 있다.
그리고 재고 싶은 능력을 직접 잴 수 없을 때는 **대리 지표(proxy)**를 쓴다. 측정 가능하면서, 재기 어려운 능력에 대해 뭔가 알려줄 거라 기대되는 무언가다.
Astra 시스템 카드에는 생물학 쪽 사례가 나온다. AAV 캡시드 패키징 예측 평가다. AAV는 아데노 연관 바이러스, 캡시드는 바이러스를 둘러싼 단백질 껍질을 말한다. 모델은 서로 다른 캡시드가 패키징에서 어떤 성능을 낼지 예측하고, 그 결과는 더 넓은 생물학적 설계 능력의 대리 지표로 쓰인다.
대리 지표를 쓰는 것 자체는 문제가 아니다. 직접 시험하려면 지나치게 어렵거나 비싼 영역에서는 현실적인 선택이다. 다만 **"모델이 이 예측을 더 잘하게 됐다"**와 **"모델이 이 예측이 대표하는 실제 능력에서 더 나아졌다"**는 같은 말이 아니다. 연결되어 있을 수는 있어도 동일하지는 않다.
시스템 카드는 생물학적 예측에 쓰이는 모델 BPNet과 관련한 문제도 언급한다. 원본 시스템의 예측에 오류나 가정이 섞여 있는데 그 예측을 시험의 기준으로 삼으면, 미래의 AI는 정작 우리가 궁금해하는 생물학 과제가 아니라 그 패턴을 재현하는 데 능숙해질 수 있다. 미묘하지만 중요한 측정 문제다.
점수도 진짜고 개선도 진짜인데, 그 개선이 무엇을 뜻하는지는 여전히 물음표로 남는다. 그래서 Astra가 미공개 실험 데이터와 웻랩 검증을 거친 증거로 새 생물학 평가를 꾸린 건 눈여겨볼 만하다. 웻랩 검증은 계산 예측에만 기대지 않고 실제 실험실에서 결과를 확인했다는 뜻이고, 그만큼 평가가 재려던 실제 현상에 가까워진다.
92%라는 숫자는 여전히 궁금하다. 다만 그 뒤에 뭐가 있는지도 같이 알고 싶을 뿐이다.
시험이 바뀌어서 숫자가 바뀌기도 한다 #
벤치마크 차트를 볼 때 놓치기 쉬운 또 하나. 시험 자체가 바뀔 수 있다.
점수는 저절로 생기지 않는다. 뒤에는 데이터셋이 있고, 모델에게 주는 지시문이 있고, 채점 방식이 있고, 점수 산정 방법이 있고, 때로는 특정 도구나 모델 설정이 있다. 이 중 하나만 바뀌어도 최종 숫자의 의미가 달라진다.
Astra 시스템 카드도 이 점을 직접 짚는다. 정책, 채점자, 데이터셋, 평가 항목을 비롯한 측정 세부사항이 시간에 따라 변하므로, 무엇이 바뀌었는지 확인하지 않은 채 예전 결과와 새 결과를 나란히 놓고 비교하면 곤란하다는 것이다.
그러니 이런 표를 볼 때는,
모델 A: 90% 모델 B: 95%
5%포인트 차이가 의미 있을 수도 있다. 다만 한쪽이 훨씬 낫다는 결론으로 가기 전에, 두 숫자가 같은 평가 환경에서 나온 건지 한 번 확인해 볼 만하다.
더 사소해 보이는 변수도 있다. 답변 길이다. 열린 형태의 평가에서는 답이 길수록 채점자가 찾는 여러 항목을 충족할 기회가 늘어난다. 사람에게는 짧은 답이 더 쓸모 있었을 상황에서도, 말을 많이 했다는 이유로 점수가 높아질 수 있다는 뜻이다. Astra 시스템 카드는 이 문제를 언급하며 일부 평가에 대해 길이를 보정한 점수를 함께 공개한다.
기술적 디테일처럼 들리지만, 점수가 실제로 무엇을 말하는지 이해하려 할 때 정확히 이런 것들이 걸린다. 숫자는 중요하다. 그 숫자에 도달한 방식도 마찬가지다.
답 하나로는 알 수 있는 게 줄어든다 #
AI를 쓰는 방식 자체도 달라지고 있다. 질문 하나 던지고 답을 기다리는 게 전부가 아니다. 여러 단계를 거치는 작업을 처리하고, 도구를 쓰고, 소프트웨어와 상호작용한다. 불완전한 지시를 받아 들고 일하다가 요구사항이 중간에 바뀌면 거기 맞춰 조정하기도 한다.
Astra 출시 자료도 이런 동작을 이야기한다. 모호함을 더 잘 다루고, 답에 따라 결과가 달라질 지점에서는 초점을 좁힌 질문을 던지고, 답을 기다리는 동안 다른 작업을 이어간다. 결정의 무게가 클 때는 추측하는 대신 사용자 입력을 기다린다.
이런 행동은 고립된 질문 하나로 포착하기 어렵다.
30분짜리 워크플로를 AI에게 맡긴다면, 답 하나를 맞혔는지보다 훨씬 많은 게 궁금하다. 내가 하려던 일을 제대로 이해했나. 중간중간 판단은 합리적이었나. 도중에 바뀐 요구사항을 감당했나. 뭔가 잘못됐을 때 복구할 수 있었나. 그래서 결과물은 실제로 동작하나.
Astra 시스템 카드에는 컴퓨터와 브라우저 작업, 모호한 지시, 복잡한 권한 설정이 얽힌 업무 환경 평가도 포함돼 있다. 요즘 우리가 AI를 쓰는 방식에 조금 더 가까운 그림이다.
개별 질문에는 탁월하면서 작업을 끝까지 끌고 가는 데는 헤매는 모델이 있다. 반대도 가능하다. 고립된 벤치마크에서는 평범해 보였는데 필요한 도구와 맥락을 주자 의외로 잘 해내는 시스템도 있다.
그래서 평가 질문도 서서히 바뀌는 중이다. **"모델이 답을 맞혔나"**만이 아니라 **"작업 전체를 얼마나 잘 끌고 갔나"**를 물어야 한다는 것. 그리고 이건 훨씬 재기 어렵다.
Photo by Pragyan Bezbaruah on Pexels
벤치마크를 볼 때 확인할 것들 #
새 모델이 나올 때마다 평가 방법론 전문가가 될 필요는 없다. 다만 점수를 해석하기 쉽게 만들어 주는 질문 몇 가지는 있다.
1. 실제로 무엇을 재고 있나 #
우리가 궁금한 능력을 직접 재고 있나, 아니면 대리 지표를 쓰고 있나.
2. 이 벤치마크는 아직 어려운가 #
강한 모델들이 이미 최고점 근처라면 포화됐을 가능성이 있다. 의미 있는 차이를 볼 여지가 별로 남지 않았다는 뜻이다.
3. 정답 기준은 어디서 왔나 #
무엇을 정답으로 놓고 있나. 고정된 답인가, 전문가 판단인가, 다른 모델인가, 시뮬레이션인가, 실제 증거인가.
4. 평가가 바뀌지는 않았나 #
데이터셋, 채점자, 점수 산정 방식, 프롬프트, 도구, 모델 설정이 바뀌었나. 작은 변화도 최종 숫자의 해석을 바꾼다.
5. 그 결과가 내 일에도 옮겨 오나 #
개발자라면 특히 유용한 질문이다. 일반 코딩 벤치마크에서 최고 성적을 낸 모델이 내 코드베이스, 내 팀, 내 워크플로에서도 최선이라는 보장은 없다.
여기서는 직접 만든 작은 평가가 의외로 쓸모 있다. 실제 업무에서 과제 20~30개를 뽑아 모델들에게 돌려 보고, 내게 중요한 항목을 본다. 코드가 동작했나. 요구사항을 이해했나. 변경을 어떻게 처리했나. 내가 얼마나 고쳐야 했나. 잘못됐을 때 복구했나. 얼마나 걸렸고 비용은 얼마였나.
큰 벤치마크 점수를 버리라는 말이 아니다. 전체적인 그림은 여전히 유용하다. 내 과제는 거기에 증거 한 조각을 더할 뿐인데, 때로는 그 조각이 가장 결정적이다.
그래서 개발자에게 이게 무슨 의미인가 #
여기서 벤치마크 이야기가 Astra 이후 자주 보이는 문장과 만난다. "AI가 개발자를 대체할 것이다."
질문이 나오는 이유는 이해가 간다. 모델이 코드를 쓰고, 코드베이스를 파악하고, 도구를 쓰고, 작업을 진행하면서 변경까지 감당한다면, 몇 년 뒤 소프트웨어 개발이 어떤 모습일지 궁금해지는 게 당연하다.
저자도 일이 바뀔 거라 본다. 어떤 건 훨씬 빨라지고, 어떤 작업에는 사람 손이 덜 들고, 도구가 좋아지면서 덜 중요해지는 기술도 생길 것이다. 동시에 더 중요해지는 기술도 있다.
코드 생산이 쉬워질수록 어려운 부분은 무엇을 만들어야 하고 어떻게 만들어야 하는가 쪽으로 옮겨 간다. 진짜 요구사항은 뭔가. 제약은 무엇인가. 시스템은 어떻게 설계해야 하나. 규모가 커져도 이 아키텍처가 버티나. 안전하고 신뢰할 만한가. AI가 만든 결과물은 어떻게 검증하나. 6개월 뒤 요구사항이 바뀌면 무슨 일이 생기나. 그래서 이게 사용자의 문제를 실제로 푸는가.
AI가 코드 수백 줄을 빠르게 뽑아낸다고 이 질문들이 사라지지는 않는다. 오히려 구현 후보를 여러 개 만들기 쉬워진 만큼 더 중요해지는 면도 있다. 선택지를 이해하고 상황에 맞는 걸 고르는 일은 여전히 누군가의 몫이다.
**"컴퓨터공학은 이제 필요 없다"**는 말이 저자에게 과하게 들리는 이유가 여기 있다. 컴퓨터과학과 소프트웨어 공학은 언제나 코드 작성 이상의 것이었다. 코드는 소프트웨어를 만드는 과정의 한 부분이지 전부가 아니다.
개발자에게 더 쓸모 있는 질문은 **"AI가 나를 대체할까"**가 아니라 **"AI가 일의 더 많은 부분을 가져갈 때, 나는 무엇을 더 잘해야 하나"**일지도 모른다.
헤드라인 하나를 결론으로 삼지 않아도 AI를 진지하게 볼 수 있다 #
저자는 AI를 둘러싼 우려를 가볍게 넘기지 않는다. 안전성, 오용, 보안, 신뢰성, 고용, 그리고 이 시스템에 얼마만큼의 자율성을 줄 것인가. 기술이 유능해질수록 진지하게 다뤄야 할 질문들이다.
다만 능력이 개선될 때마다 그것이 한 직업의 종말 예측으로 이어질 필요는 없다고 본다. AI가 코드를 쓸 수 있다는 사실에서, 그는 소프트웨어 개발을 바꾸고 있는 기술을 본다. 개발자가 끝났다는 게 유일한 결론이라고 생각하지 않는다.
점점 복잡해지는 AI 시스템도 마찬가지다. 사람이 필요한가 아닌가로 곧장 건너뛰는 대신, 어느 부분을 AI에게 맡길 수 있고 어디에 사람이 남아야 하며 어떤 감독이 합리적인지를 묻는 편이 낫다.
벤치마크 점수가 올라갈 때도 그 숫자 뒤를 보고 싶다. 무엇을 시험했나. 어떻게 시험했나. 이 벤치마크는 아직 유용한 신호를 주나. 그 개선이 사람들이 실제로 하는 일에서도 나타나나.
이렇게 보면 논의가 더 흥미로워진다. 모델이 해내는 것에 흥분하면서도 그 주장들에 질문을 던질 수 있다. 가장 극단적인 결말을 전제하지 않고도 위험을 진지하게 볼 수 있고, 새 헤드라인을 최종 답으로 여기지 않고도 진짜 진전을 알아볼 수 있다.
아직 모르는 게 많다. 그래도 괜찮다. 우리는 이 변화를 실시간으로 지켜보는 중이니까.
모델이 변한다면, 보는 방식도 변해야 한다 #
저자가 Astra를 보며 계속 돌아오는 지점이 이것이다. 모델은 유능해지는데 그 능력을 재는 일은 점점 복잡해진다. 벤치마크는 포화되고 대리 지표에는 한계가 있다. 정답 기준이 늘 단순한 것도 아니고, 평가 방법 역시 계속 진화해야 한다.
그렇다면 질문도 같이 진화할 필요가 있다.
"AI가 개발자를 대체할까" 대신 "개발의 어느 부분이 바뀌고 있고, 어떤 기술이 더 가치 있어지나."
"컴퓨터공학은 죽었나" 대신 "코드 생산이 훨씬 쉬워진 세계에서 컴퓨터과학은 어떤 모습인가."
"AGI가 왔나" 대신 "우리가 말하는 능력이 정확히 무엇이고, 그걸 어떻게 재고 있으며, 증거는 무엇인가."
앞으로도 더 강한 모델과 인상적인 데모, 그리고 아주 강한 의견들이 계속 나올 것이다. 어떤 예측은 맞을 테고, 어떤 예측은 너무 멀리 갈 테고, 어떤 일은 모두를 놀라게 할 것이다. 이렇게 빠르게 변하는 기술을 지켜본다는 건 원래 그런 일이다.
저자가 택한 태도는 호기심을 유지하고, 증거를 보고, 위험을 진지하게 다루고, 우리 일에서 실제로 무엇이 달라지는지에 주의를 기울이는 것이다.
벤치마크와 헤드라인과 예측을 다 지나고 나면, 물어볼 만한 질문은 결국 이것일지도 모른다.
"무엇이 바뀌었고, 우리는 그걸 어떻게 아는가. 그리고 그게 우리 일에 무슨 의미인가."
그다음은 이것이다.
"좋다. 지금 이 기술은 이만큼 할 수 있다. 그럼 우리는 무엇을 만들까."
참고 자료 #
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.