지난주 DeepSeek가 저에게 정규표현식 (Regex) 작성을 거부했습니다. "못 하겠다"가 아니라, 여기서 정규표현식을 쓰는 것은 좋지 않은 아이디어라고 정중하게 설명하며 루프 (Loop)를 제안했습니다. 그때 저는 제가 지난 1년 동안 모델들을 "눈대중"으로 비교해 왔다는 사실을 깨달았습니다. 하나가 버벅거리면 프롬프트 (Prompt)를 옆 탭에 복사해서 붙여넣고, 보고 나서 근거 없는 결론을 내리곤 했죠. 이제 지쳤습니다. 그래서 작은 정직한 측정을 실시했습니다. 제 업무 일상에서 흔히 발생하는 세 가지 전형적인 과제를, 말 그대로 완전히 동일한 프롬프트로 세 모델에게 던졌습니다.

설정에 대해 한 문단만 말씀드리자면, 이후에 흐름을 깨지 않기 위함입니다. "한쪽 탭은 VPN이 끊기고, 다른 쪽은 세션이 만료되는" 변수를 제거하고 싶었기에, 애그리게이터 (Aggregator)를 통해 하나의 창에서 모두 실행했습니다. 링크는 아래에 있겠지만 여기서는 중요하지 않습니다. 중요한 것은 하나입니다. 입력창 바로 위에서 모델을 전환할 수 있어, 세 참가자 모두 서비스 간 복사 붙여넣기 없이 동일한 텍스트를 받았다는 점입니다. 참가자: GPT (플래그십, GPT-5급), Claude, DeepSeek.

과제 1. 정규표현식 (Regex): 따옴표를 깨뜨리지 않고 CSV 문자열 분할하기

프롬프트: "CSV 문자열을 쉼표 기준으로 나누되, 큰따옴표 안에 있는 쉼표는 구분자로 간주하지 않는 JS 정규표현식을 작성해줘."

전형적인 함정: 단순한 split(',')은 "Иванов, Иван" 필드를 반으로 쪼개버립니다.

GPT는 즉시 룩어헤드 (Lookahead)를 사용한 버전을 내놓았습니다:

const parts = row.split(/,(?=(?:[^" ]*"[^" ]*")*[^" ]*$)/);

작동합니다. 다만, 필드 내부에 이스케이프된 따옴표 ""가 포함된 제 테스트 케이스에서는 작동하지 않았습니다. 하지만 저는 그런 것을 요청하지 않았으므로, 통과 처리합니다.

Claude는 동일한 정규표현식을 주었지만 주의사항을 덧붙였습니다: 모든 쉼표에서 룩어헤드 (Lookahead)가 문자열의 끝까지 훑어야 하므로, 긴 문자열에서는 시간 복잡도가 제곱으로 늘어날 수 있으니 프로덕션 (Production) 환경에서는 csv-parse를 사용하라는 것이었습니다. 까다롭지만 유익한 조언입니다. 저도 예전에 정확히 이런 구조 때문에 타임아웃 (Timeout)을 겪은 적이 있습니다.

DeepSeek는 이 모든 일의 시작이었던 바로 그 거절을 했습니다. 정규표현식을 작성하는 대신, "우리는 현재 따옴표 안에 있다"라는 플래그 (Flag)를 사용하는 루프 (Loop)를 제안했습니다. 그게 더 신뢰할 수 있다는 논리였습니다. 형식적으로는 이것이 더 정직할 수 있지만, 과제는 "정규표현식을 작성하라"였고, 그는 명확한 재요청이 있은 후에야 그것을 내놓았습니다.

라운드 결과: GPT와 Claude가 동점이며, 경고를 준 Claude가 0.5점 앞섭니다.

과제 2. 리팩토링 (Refactoring): 중첩된 if 문이 있는 할인 함수

모든 모델에게 오래된 프로젝트에서 약간 익명화한 코드 조각을 입력으로 주었습니다:

function getDiscount(user, sum) {
  if (user) {
    if (user.isPremium) {
...

Claude가 가장 좋은 결과를 보여주었습니다: 조기 반환 (early returns), 평탄한 구조 (flat structure), 그리고 동작이 비트 단위로 일치했습니다. 저는 채팅창에서 직접 두 가지 버전을 8개의 케이스로 실행해 보았습니다:

function getDiscount(user, sum) {
  if (!user) return 0;
  if (user.isPremium) return sum > 10000 ? 0.15 : 0.1;
...

GPT도 비슷하게 작성했지만, 동시에 로직을 "개선"해 버렸습니다: 임계값(thresholds)을 상수로 추출하면서, 슬그머니 > 10000을 >= 10000으로 바꾸어 놓았습니다. 사소한 차이 같지만, 경계값에서는 돈의 액수가 달라집니다. 테스트에서 잡아내긴 했지만, 찜찜함이 남았습니다.

DeepSeek는 조심스럽게 작동했습니다: 할 수 있는 것보다 덜 단순화했지만, 아무것도 망가뜨리지 않았고 구조를 변경한 부분에 주석을 남겼습니다.

결과는 명확합니다: Claude가 1위, DeepSeek가 2위, GPT는 독단적인 수정 때문에 감점입니다.

과제 3. SQL: 3개월 연속 주문을 한 고객 찾기

프롬프트: "PostgreSQL. orders(user_id, created_at, amount) 테이블. 최소 3개월 연속으로 주문이 있었던 사용자를 찾아라."

이것은 Gaps-and-Islands 문제이며, 여기서 결과가 뒤집혔습니다.

DeepSeek가 첫 번째 시도만에 가장 깔끔한 버전을 내놓았습니다:

WITH months AS (
  SELECT DISTINCT user_id, date_trunc('month', created_at) AS m
  FROM orders
...

Claude는 LAG 함수와 플래그의 누적 합계를 사용하여 해결했습니다. 정확하긴 하지만, 코드가 열 줄 정도 더 길고 불필요한 CTE (Common Table Expression)가 포함되었습니다.

GPT는 첫 번째 버전에서 월(month) 번호를 숫자로 비교하다가, 예상대로 12월에서 1월로 넘어가는 구간에서 걸려 넘어졌습니다. "연도 경계는 어떻게 되나요?"라는 힌트를 준 후 한 번의 반복(iteration) 만에 수정했지만, 두 번째 찜찜함이 남았습니다.

약 200개의 주문이 포함된 생성된 데이터셋으로 모두 검증했습니다. 이 역시 채팅창을 벗어나지 않고, 모델에게 직접 테스트 데이터를 만들고 쿼리를 실행하도록 요청하여 진행했습니다.

이번 라운드의 점수는 간단합니다: DeepSeek가 갑작스럽게 1위를 차지했습니다.

최종 결과 표

이번 테스트를 통해 얻은 교훈

가장 중요한 결론은 모델 자체에 대한 것이 아닙니다. 모델들은 대략적으로 비슷한 수준이며, 각자 고유의 성격(GPT는 주도적이고, Claude는 꼼꼼하며, DeepSeek는 실용적임)을 가지고 있습니다. 그리고 새로운 모델이 출시되고 몇 달이 지나면 순위는 분명히 바뀔 것입니다.

프로세스에 대한 결론: 모델을 비교하는 것은 오직 동일한 프롬프트(Prompt)를 사용할 때만 의미가 있으며, 모델 전환이 "탭을 열고, 다시 로그인하고, VPN을 켜는" 과정이 아니라 단 두 번의 클릭만으로 가능할 때만 유효합니다. 약속했던 설정 링크는 다음과 같습니다. 저는 모든 테스트를 Veruna에서 진행했습니다. 제가 필요했던 기능은 딱 두 가지였습니다. 입력창 위의 모델 전환 스위치와, 답변을 눈으로 확인하는 대신 테스트로 검증할 수 있도록 채팅 내에서 코드를 실행하는 기능입니다.

여러분의 작업으로 직접 측정을 해보고 싶다면, 러시아용 AI Awesome 리스트를 참고하세요. 이곳에서 러시아에서 사용 가능한 모델과 서비스를 수집하고 있으며, 추가 사항에 대한 PR(Pull Request)은 언제나 환영합니다.

댓글로 질문 하나 드릴게요: DeepSeek가 특히 SQL 작업에서 예상치 못하게 승리한 분이 또 계신가요, 아니면 제가 운 좋게 문제를 잘 고른 걸까요?