2 데이터 탐정 되어보자
이전 장에서 우리는 놀라운 사실을 발견했다. AI의 추측과 달리 박봉식(Pabodie) 엔지니어가 가장 많은 측정을 수행했고, 더욱 흥미롭게도 일부 측정 기록에서 person 필드가 누락되어 있었다. 특히 752번 방문에서 이상한 패턴을 발견했다.
1930년대 탐사대에게 정말 무슨 일이 일어났을까? 단순한 기록 실수일까, 아니면 더 큰 비밀이 숨어 있는 것일까?
이 미스터리를 해결하려면 지금까지 배운 SELECT만으로는 부족하다. 데이터를 정렬(ORDER BY)하고 필터링(WHERE)하는 새로운 도구가 필요하다. 마치 탐정이 단서들을 시간 순으로 정리하고, 의심스러운 증거들만 골라내는 것처럼 말이다.
2.1 752번 방문의 진실
탐정의 첫 번째 원칙: 사건을 시간 순으로 정리하라. 이상한 752번 방문이 언제 일어났는지, 그 전후로 무슨 일이 있었는지 파악해보자. SQL의 ORDER BY를 사용해서 측정 시점별로 데이터를 정렬할 수 있다:
SELECT * FROM Survey ORDER BY taken;| taken | person | quant | reading |
|---|---|---|---|
| 619 | dyer | rad | 9.82 |
| 619 | dyer | sal | 0.13 |
| 622 | dyer | rad | 7.8 |
| 622 | dyer | sal | 0.09 |
| 734 | pb | rad | 8.41 |
| 734 | lake | sal | 0.05 |
| 734 | pb | temp | -21.5 |
| 735 | pb | rad | 7.22 |
| 735 | - | sal | 0.06 |
| 735 | - | temp | -26.0 |
| 751 | pb | rad | 4.35 |
| 751 | pb | temp | -18.5 |
| 751 | lake | sal | 0.1 |
| 752 | lake | rad | 2.19 |
| 752 | lake | sal | 0.09 |
| 752 | lake | temp | -16.0 |
| 752 | roe | sal | 41.6 |
| 837 | lake | rad | 1.46 |
| 837 | lake | sal | 0.21 |
| 837 | roe | sal | 22.5 |
| 844 | roe | rad | 11.25 |
흥미로운 패턴이 보이기 시작한다! 측정 시점별로 정렬하니 각 방문에서 누가 어떤 측정을 했는지 명확해진다. 그런데 752번 방문을 보면… Lake는 모든 측정을 기록했지만, Roerich의 염도 측정값이 41.6으로 비정상적으로 높다.
ORDER BY는 기본적으로 오름차순(ASC)으로 정렬한다. 만약 가장 최근 측정부터 보고 싶다면 DESC를 사용할 수 있다:
SELECT * FROM Survey ORDER BY taken DESC;이제 752번 방문의 수상한 점을 더 자세히 파헤쳐보자.
2.1.1 의심스러운 측정 날짜
탐정의 두 번째 원칙: 중복된 증거는 의심스럽다. 우리가 발견한 문제 중 하나는 752번 방문의 날짜가 -null-로 기록되어 있다는 것이다. 다른 방문들의 날짜 패턴을 확인해보자:
SELECT dated FROM Visited;| dated |
|---|
| 1927-02-08 |
| 1927-02-10 |
| 1930-01-07 |
| 1930-01-12 |
| 1930-02-26 |
| 1932-01-14 |
| 1932-03-22 |
이상하다! 같은 날짜에 여러 번 방문한 기록들이 보인다. 하지만 중복된 날짜보다 더 이상한 것은 빈 날짜 필드다. DISTINCT 키워드를 사용해서 실제로 며칠에 걸쳐 탐사가 이루어졌는지 확인해보자:
SELECT DISTINCT dated FROM Visited;| dated |
|---|
| 1927-02-08 |
| 1927-02-10 |
| 1930-01-07 |
| 1930-01-12 |
| 1930-02-26 |
| 1932-01-14 |
| 1932-03-22 |
7개의 서로 다른 측정 일자가 있었지만, 여전히 누락된 날짜가 하나 있다. 이것이 바로 752번 방문이다. 왜 이 방문만 날짜가 기록되지 않았을까?
탐정의 두 번째 원칙: 중복을 제거하여 고유한 증거 조합을 찾아라. 여러 칼럼을 동시에 중복 제거하면 흥미로운 패턴을 발견할 수 있다:
-- 각 방문에서 실제로 측정에 참여한 고유한 인원 조합
SELECT DISTINCT taken, person FROM Survey WHERE person IS NOT NULL;| taken | person |
|---|---|
| 619 | dyer |
| 622 | dyer |
| 734 | pb |
| 734 | lake |
| 735 | pb |
| 751 | pb |
| 751 | lake |
| 752 | lake |
| 752 | roe |
| 837 | lake |
| 837 | roe |
| 844 | roe |
이제 명확해진다! 752번 방문에서만 Lake와 Roerich가 함께 측정했다. 다른 방문들을 보면 대부분 한 명이 주도하거나, 두 명이 함께해도 서로 다른 측정을 담당했다. 하지만 752번에서는 둘 다 염도를 측정했는데 값이 극명하게 다르다 (Lake: 0.09, Roerich: 41.6).
비정상적인 측정값이 나올 때 다른 측정자가 검증 측정을 하는 것은 과학적 관례다. 하지만 두 값의 차이가 너무 극단적이어서 장비 오작동이나 특별한 지질학적 현상을 의심하게 된다.
2.1.2 용의자를 찾아서
탐정의 세 번째 원칙: 특정 조건에 맞는 증거만 골라내라. 이제 SQL의 WHERE를 사용해서 의심스러운 데이터들을 하나씩 추적해보자. 먼저 문제의 752번 방문에 대한 모든 정보를 수집해보자:
SELECT * FROM Survey WHERE taken = 752;| taken | person | quant | reading |
|---|---|---|---|
| 752 | lake | rad | 2.19 |
| 752 | lake | sal | 0.09 |
| 752 | lake | temp | -16.0 |
| 752 | roe | sal | 41.6 |
드디어 752번 방문의 전체 모습이 드러났다! Lake는 방사능, 염도, 온도를 모두 측정했고 정상적인 값들을 기록했다. 하지만 Roerich는 오직 염도만 측정했는데 그 값이 41.6이다. 정상적인 염도 값(0.05~0.21)과 비교하면 거의 200배나 높은 수치다!
여기서 중요한 점: WHERE 절에서 문자열은 작은따옴표로, 숫자는 그대로 작성한다.
2.1.3 비정상 측정값 패턴
이상한 일은 계속된다. 비정상적으로 높은 측정값들을 찾아보자:
SELECT * FROM Survey WHERE reading > 20.0;| taken | person | quant | reading |
|---|---|---|---|
| 752 | roe | sal | 41.6 |
| 837 | roe | sal | 22.5 |
충격적인 사실이 드러났다! 비정상적으로 높은 염도 측정값이 2개 있는데, 둘 다 Roerich가 측정한 것이다. 우연의 일치일까?
SQL은 다양한 비교 연산자를 제공한다: >, <, >=, <=, =, !=
2.1.4 복합 조건으로 범인 추적
이제 여러 조건을 조합해서 더 정교한 수사를 해보자. Roerich가 측정한 모든 염도값을 확인해보자:
SELECT * FROM Survey WHERE person = 'roe' AND quant = 'sal';| taken | person | quant | reading |
|---|---|---|---|
| 752 | roe | sal | 41.6 |
| 837 | roe | sal | 22.5 |
모든 증거가 한 방향을 가리킨다! Roerich가 측정한 염도값은 모두 비정상적으로 높다.
2.1.5 수사 기법 고도화
탐정이 증거를 여러 기준으로 정리하듯, SQL에서도 여러 칼럼을 기준으로 정렬할 수 있다. 각 방문에서 누가 주도적으로 측정을 했는지 패턴을 찾아보자:
-- 방문별로 먼저 정렬하고, 같은 방문 내에서는 측정자별로 정렬
SELECT taken, person, quant, reading FROM Survey
ORDER BY taken ASC, person DESC;| taken | person | quant | reading |
|---|---|---|---|
| 619 | dyer | rad | 9.82 |
| 619 | dyer | sal | 0.13 |
| 622 | dyer | rad | 7.8 |
| 622 | dyer | sal | 0.09 |
| 734 | pb | rad | 8.41 |
| 734 | pb | temp | -21.5 |
| 734 | lake | sal | 0.05 |
| 735 | pb | rad | 7.22 |
| 735 | sal | 0.06 | |
| 735 | temp | -26.0 | |
| 751 | pb | rad | 4.35 |
| 751 | pb | temp | -18.5 |
| 751 | lake | sal | 0.1 |
| 752 | roe | sal | 41.6 |
| 752 | lake | rad | 2.19 |
| 752 | lake | sal | 0.09 |
| 752 | lake | temp | -16.0 |
| 837 | roe | sal | 22.5 |
| 837 | lake | rad | 1.46 |
| 837 | lake | sal | 0.21 |
| 844 | roe | rad | 11.25 |
흥미로운 패턴이 보인다! 각 방문에서 알파벳 순으로 정렬된 측정자 순서를 통해 752번 방문의 특이점이 더욱 명확해진다. Roerich(roe)가 맨 위에 나타나는 것은 알파벳 순서 때문이지만, 그의 측정이 단 한 개만 있다는 것이 더욱 의심스럽다.
여러분도 다음 쿼리를 실행해보면 각 측정자가 어떤 전문 분야를 가지고 있는지 발견할 수 있다:
-- 측정 종류별, 측정자별로 정렬해서 전문 분야 파악
SELECT quant, person, COUNT(*) as 측정횟수
FROM Survey WHERE person IS NOT NULL
GROUP BY quant, person
ORDER BY quant, person;정렬 순서의 비밀
SQL에서 정렬은 생각보다 섬세한 작업이다. 기본적으로 ORDER BY는 오름차순(ASC)으로 정렬하기 때문에 별도로 명시하지 않아도 된다. 알파벳은 A부터 Z까지, 숫자는 작은 값부터 큰 값까지 차례대로 나열된다. 반대로 내림차순으로 정렬하고 싶다면 반드시 DESC를 명시해야 한다.
특히 주의할 점은 NULL 값의 정렬 순서다. 대부분의 데이터베이스에서 NULL 값은 오름차순 정렬 시 가장 마지막에, 내림차순 정렬 시 가장 처음에 위치한다. 이는 735번 방문에서 측정자 정보가 누락된 기록들이 왜 특정 위치에 나타나는지 설명해준다. 데이터베이스는 ’알 수 없는 값’을 일관된 규칙에 따라 배치하여 예측 가능한 결과를 제공한다.
-- 최신 측정부터 보기 (내림차순)
SELECT * FROM Survey ORDER BY taken DESC;
-- 측정값이 높은 순서대로 보기
SELECT * FROM Survey WHERE quant = 'sal' ORDER BY reading DESC;여러 조건을 결합할 때는 AND, OR, NOT 연산자를 사용할 수 있다:
-- 정상적인 염도값만 찾기
SELECT * FROM Survey WHERE quant = 'sal' AND reading < 1.0;조건이 복잡해질 때는 괄호를 사용해야 한다. AND가 OR보다 우선순위가 높기 때문이다:
-- 올바른 쿼리
SELECT * FROM Survey WHERE (person = 'lake' OR person = 'dyer') AND quant = 'sal';
-- 잘못된 쿼리 (의도와 다른 결과)
SELECT * FROM Survey WHERE person = 'lake' OR person = 'dyer' AND quant = 'sal';SQL은 NOT연산자도 제공한다:
SELECT * FROM Survey WHERE NOT reading > 1.0;| taken | person | quant | reading |
|---|---|---|---|
| 619 | dyer | sal | 0.13 |
| 622 | dyer | sal | 0.09 |
| 734 | lake | sal | 0.05 |
| 734 | pb | temp | -21.5 |
| 735 | - | sal | 0.06 |
| 735 | - | temp | -26.0 |
| 751 | pb | temp | -18.5 |
| 751 | lake | sal | 0.1 |
| 752 | lake | sal | 0.09 |
| 752 | roe | temp | -16.0 |
| 837 | lake | sal | 0.21 |
2.1.6 증거의 흔적
탐정의 네 번째 원칙: 부분적인 단서도 놓치지 말라. 실제 수사에서 완전한 증거는 드물다. 탐정들은 종종 불완전한 정보로도 범인을 추적해야 한다. SQL도 마찬가지다. LIKE 연산자를 사용하면 부분적인 패턴만으로도 원하는 데이터를 찾을 수 있다.
예를 들어, 우리는 “oe”라는 글자가 들어간 과학자가 의심스럽다는 단서를 얻었다. 정확한 이름을 모르더라도 이 패턴으로 찾을 수 있다:
SELECT * FROM Person WHERE family LIKE '%oe%';| personal | family |
|---|---|
| Valentina | Roerich |
바로 Roerich! 우리의 주요 용의자다.
또 다른 중요한 패턴을 발견할 수 있다. DR로 시작하는 모든 측정 지점들을 조사해보자:
SELECT * FROM Site WHERE name LIKE 'DR%';| name | lat | long |
|---|---|---|
| DR-1 | -49.85 | -128.57 |
| DR-3 | -47.15 | -126.72 |
흥미롭게도 DR-1과 DR-3만이 존재한다. 그렇다면 DR-2는 어디에 있을까? 이것 또한 미스터리의 한 부분일 수 있다.
2.2 미래의 탐정 도구
1930년 2월 26일, 남극의 매서운 바람이 몰아치는 DR-3 지점. Dyer 교수는 꽁꽁 언 손가락으로 연필을 쥐고 측정 노트에 숫자를 하나씩 적어내려갔다. 종이가 바람에 날아가지 않도록 돌멩이로 꾹 눌러두고, 장갑을 벗었다 끼었다 하며 한 글자 한 글자 꼼꼼히 기록했다. 752번 방문에서 벌어진 Roerich의 이상한 측정값을 두고 동료들과 몇 시간째 토론을 벌이고 있었다. “이 수치가 정말 맞는 걸까? 장비 오류일까, 아니면 뭔가 특별한 일이 벌어진 걸까?”
90년이 지난 2025년. 우리는 키보드 몇 번만 두드리면 ChatGPT가 즉시 답을 제시하는 시대에 살고 있다. 1930년대 탐사대가 며칠 밤을 고민했던 문제를 몇 초 만에 분석해달라고 AI에게 요청할 수 있다. 하지만 과연 AI의 답을 그대로 믿을 수 있을까?
바로 이 지점에서 흥미로운 실험을 해보자. ChatGPT라는 AI 탐정과 SQL이라는 데이터 탐정 사이의 추리 대결 말이다. 같은 미스터리를 두고 어떤 도구가 더 정확한 해답을 제시할까? 과연 AI는 우리보다 더 나은 추리를 할 수 있을까? 실제 증거(데이터)와 AI의 추측을 직접 비교해보자.
2.2.1 시나리오 1: 탐사대 이동 패턴 분석
첫 번째 대결 라운드. 탐사대의 이동 패턴에 대한 수수께끼다. 탐사대가 가장 자주 방문한 지역은 어디였을까? 그리고 그 이유는 무엇일까?
ChatGPT 프롬프트: “1930년대 남극 탐사대 데이터를 보고, 탐사대가 가장 자주 방문한 지역과 측정 패턴을 분석해줘.”
ChatGPT 응답: “탐사대는 아마도 기지 근처인 DR-1을 가장 자주 방문했을 것이고, 날씨가 좋은 날에 집중적으로 측정했을 것입니다.”
ChatGPT의 추론은 매우 합리적이다. 탐사 경험이 있다면 누구나 이렇게 생각할 것이다. 기지에서 가까운 곳을 자주 방문하고, 날씨가 좋을 때 집중적으로 측정하는 것이 일반적인 탐사 패턴이기 때문이다. 하지만 1930년대 남극 탐사는 과연 일반적이었을까?
이제 AI의 추측을 실제 데이터로 검증해보자. SQL 탐정의 출전이다.
SQL로 검증해보기:
-- 실제 사이트별 방문 횟수
SELECT site, COUNT(*) as 방문횟수
FROM Visited
WHERE site IS NOT NULL
GROUP BY site
ORDER BY 방문횟수 DESC;| site | 방문횟수 |
|---|---|
| DR-3 | 4 |
| DR-1 | 3 |
| MSK-4 | 1 |
결과: 이번 라운드는 SQL의 승리! ChatGPT의 추측과는 정반대였다. 실제로는 DR-3가 4회로 가장 자주 방문되었고, ChatGPT가 예측한 DR-1은 3회로 두 번째였다. 더욱 흥미로운 것은 MSK-4는 단 1회만 방문되었다는 점이다.
이는 ChatGPT의 “기지 근처를 자주 방문할 것”이라는 상식적 추론이 틀렸음을 보여준다. 실제로는 DR-3라는 특정 지역에 탐사대가 집중했던 것 같다. 왜 DR-3가 그렇게 중요했을까? 그리고 MSK-4는 왜 단 한 번만 방문했을까?
2.2.2 시나리오 2: 위험한 측정 상황 분석
두 번째 라운드는 좀 더 복잡한 질문이다. 남극이라는 지구상에서 가장 혹독한 환경에서 과학자들이 마주했던 위험 상황을 추적하는 것이다.
ChatGPT 프롬프트: “남극에서 가장 위험했던 측정 상황을 찾아줘. 극한 상황에서 측정된 데이터는?”
ChatGPT 응답: “가장 위험한 상황은 아마도 폭설이나 강풍이 있던 날일 것입니다. 온도가 -30도 이하일 때의 측정이 가장 위험했을 것입니다.”
이번에도 ChatGPT의 추론은 그럴듯하다. 남극의 위험 요소들 - 폭설, 강풍, 극한 저온 - 을 모두 고려한 종합적인 판단이다. -30도라는 구체적인 수치까지 제시한 것도 설득력 있어 보인다. 하지만 과연 1930년대 탐사대가 그런 극한 상황에서도 측정을 감행했을까?
SQL로 검증해보기:
-- 극한 온도에서의 측정
SELECT taken, person, reading as 온도
FROM Survey
WHERE quant = 'temp'
ORDER BY reading ASC;| taken | person | 온도 |
|---|---|---|
| 735 | - | -26.0 |
| 734 | pb | -21.5 |
| 751 | pb | -18.5 |
| 752 | roe | -16.0 |
결과: 이번 라운드는 SQL의 승리! ChatGPT가 추측한 -30도는 존재하지 않았다. 실제로 가장 추웠던 날은 -26도였다. 하지만 여기서 더욱 흥미로운 발견이 있다. 가장 위험했던 그 날, -26도의 극한 추위 속에서 측정을 감행한 용감한 과학자의 이름이… 기록되지 않았다는 점이다.
왜 가장 극한 상황의 기록에서 측정자의 이름이 빠져있을까? 너무 위험해서 기록할 여유가 없었던 걸까, 아니면 다른 이유가 있는 걸까? 이 또한 우리가 풀어야 할 미스터리 중 하나다.
2.2.3 시나리오 3: 전문성 분석
세 번째 라운드는 가장 철학적인 질문이다. 과연 무엇이 과학자의 전문성을 말해주는가? 이는 데이터 분석의 근본적인 질문이기도 하다.
ChatGPT 프롬프트: “가장 전문성 있는 탐사대원을 찾아줘. 누가 가장 신뢰할 만한 과학자인가?”
ChatGPT 응답: “가장 많은 측정을 한 사람이 가장 경험이 많고 전문적일 것입니다. 아마도 팀 리더였던 사람이겠죠.”
이번에도 ChatGPT는 상식적인 접근을 했다. ’많이 일한 사람 = 전문가’라는 일반적인 통념을 적용한 것이다. 실제로 많은 조직에서 경험과 업무량을 전문성의 지표로 사용한다. 하지만 과학 연구에서도 이 공식이 성립할까?
SQL로 검증해보기:
-- 측정 횟수별 순위
SELECT person, COUNT(*) as 측정횟수
FROM Survey
WHERE person IS NOT NULL AND person != '-'
GROUP BY person
ORDER BY 측정횟수 DESC;| person | 측정횟수 |
|---|---|
| lake | 7 |
| pb | 5 |
| dyer | 4 |
| roe | 3 |
결과: 흥미롭게도 실제로는 lake(Anderson Lake)가 7회로 가장 많은 측정을 수행했다. ChatGPT가 예상한 “팀 리더가 가장 많이”라는 가설은 부분적으로 맞았다. dyer(William Dyer) 교수가 리더였다면 4회로 중간 정도에 위치한다. 하지만 정말로 “많이 측정 = 전문성”일까?
여기서 더욱 흥미로운 패턴이 드러난다. 앞서 우리가 발견한 사실을 떠올려보자. Lake는 7회로 가장 많이 측정했고, 특히 DR-3 지역에 집착했다. 반면 Roerich는 단 3회만 측정했지만, 그의 측정값들은 모두 비정상적이었다. 41.6과 22.5라는 극단적인 염도값 말이다.
어쩌면 Lake는 많은 측정을 통해 무언가를 찾고 있었던 것 같다. 특히 DR-3에서 말이다. 반면 Roerich는 다른 사람들이 측정하기 어려운 특별한 상황이나 지역을 담당했기 때문에 적게 측정했을 수도 있다. 측정 횟수만으로는 전문성을 판단하기 어렵다는 뜻이다.
2.2.4 AI vs SQL: 승부의 결과는?
세 라운드의 대결이 끝났다. 이제 결과를 정리해보자.
| 분석 항목 | ChatGPT | SQL | 승자 |
|---|---|---|---|
| 속도 | 30초 | 3초 | SQL ✅ |
| 정확도 | 33% (1/3 정답) | 100% | SQL ✅ |
| 근거 제시 | 추측 기반 | 데이터 기반 | SQL ✅ |
| 가설 생성 | 우수 | 불가능 | ChatGPT ✅ |
| 패턴 발견 | 직관적 | 체계적 | SQL ✅ |
표면적으로 보면 SQL의 압도적 승리인 것 같다. 속도도 빠르고, 정확하고, 명확한 근거도 제시한다. 그렇다면 이제 AI는 필요 없는 걸까?
그런데 잠깐. ChatGPT가 제시한 가설들을 다시 살펴보자. 놀랍게도 3번의 시나리오에서 2번이나 틀렸지만, 그 가설들 자체가 우리에게 중요한 질문들을 던져주었다. “DR-1을 가장 자주 방문했을 것”이라는 추측은 틀렸지만, 덕분에 우리는 DR-3에 대한 탐사대의 특별한 관심을 발견했다. “-30도에서 측정했을까?”라는 ChatGPT의 추측도 틀렸지만, 덕분에 우리는 실제로 -26도라는 극한 상황에서 측정자 이름이 누락된 미스터리를 발견했다. “팀 리더가 가장 많이 측정했을 것”이라는 가설은 부분적으로 맞았지만, 덕분에 우리는 측정 횟수와 전문성의 관계에 대해 더 깊이 생각하게 되었다.
실제 데이터 분석 현장에서는 이렇게 활용한다. 마치 1930년대 탐사대의 팀워크처럼 말이다.
1단계: ChatGPT로 가설 생성 “이 데이터에서 어떤 패턴을 발견할 수 있을까? 어떤 가설을 세워볼까?” AI는 상상력이 풍부한 조수 역할을 한다. 인간이 놓칠 수 있는 관점들을 제시하고, 분석의 방향을 잡아준다.
2단계: SQL로 정확한 검증 “과연 이 가설이 맞을까? 실제 데이터는 뭐라고 말하는가?” SQL은 냉철한 판사 역할을 한다. 감정이나 편견 없이 오직 데이터로만 판단한다.
3단계: 결과 해석과 다음 단계 설정 틀린 가설도 가치가 있다. 왜 틀렸는지 생각하다 보면 새로운 발견이 기다리고 있다. ChatGPT의 “틀린” 추측이 우리를 752번 방문의 진짜 미스터리로 이끌었던 것처럼.
최고의 탐정팀: 1930년대 탐사대가 서로의 전문성을 믿고 협력했듯이, 현대의 데이터 탐정도 AI의 창의성과 SQL의 정확성을 모두 활용할 때 최상의 결과를 얻을 수 있다.
2.3 Lake 미스터리
데이터 분석 과정에서 흥미로운 패턴이 발견되었다. Lake가 특별히 DR-3 지역과 염도 측정에 집착했다는 것이다.
2.3.1 Lake의 DR-3 염도 측정 패턴
탐정처럼 단계별로 수사해보자. 먼저 DR-3 사이트의 방문 기록을 확인한다:
-- 1단계: DR-3 방문 기록 확인
SELECT * FROM Visited WHERE site = 'DR-3';| id | site | dated |
|---|---|---|
| 734 | DR-3 | 1930-01-07 |
| 735 | DR-3 | 1930-01-12 |
| 751 | DR-3 | 1930-02-26 |
| 752 | DR-3 |
이제 Lake가 이 방문들(734, 751, 752번) 중 어떤 측정을 했는지 확인한다:
-- 2단계: Lake의 해당 측정 기록 찾기
SELECT * FROM Survey
WHERE person = 'lake'
AND taken IN (734, 751, 752)
ORDER BY taken;| taken | person | quant | reading |
|---|---|---|---|
| 734 | lake | sal | 0.05 |
| 751 | lake | sal | 0.1 |
| 752 | lake | rad | 2.19 |
| 752 | lake | sal | 0.09 |
| 752 | lake | temp | -16.0 |
2.3.2 비정상 염도값 진실
가장 놀라운 발견은 Roerich의 비정상적인 염도값이었다:
-- 비정상적인 염도값 조사
SELECT taken, person, reading,
CASE
WHEN reading > 10 THEN '매우 위험'
WHEN reading > 1 THEN '위험'
ELSE '정상'
END as 위험도
FROM Survey
WHERE quant = 'sal' AND reading > 1.0
ORDER BY reading DESC;| taken | person | reading | 위험도 |
|---|---|---|---|
| 752 | roe | 41.6 | 매우 위험 |
| 837 | roe | 22.5 | 매우 위험 |
2.3.3 미스터리 실마리를 모으다
모든 증거들을 차례로 정리해보니 놀라운 패턴이 드러났다:
- Lake는 DR-3에 집착했다 - 7번의 측정 중 7번 모두 DR-3에서
- Roerich 염도값이 비정상적이다 - 41.6과 22.5 (정상: 0.0-1.0)
- 752번 방문이 핵심이다 - 이 날 Lake와 Roerich가 함께 측정했지만 날짜가 누락됨
752번 방문의 진실을 최종 확인해보자:
-- 752번 방문의 모든 측정 조사
SELECT taken, person, quant, reading
FROM Survey
WHERE taken = 752
ORDER BY person, quant;| taken | person | quant | reading |
|---|---|---|---|
| 752 | lake | rad | 2.19 |
| 752 | lake | sal | 0.09 |
| 752 | lake | temp | -16.0 |
| 752 | roe | sal | 41.6 |
탐정의 최종 추리: 1930년 2월 26일, Lake와 Roerich가 함께 DR-3을 방문했다. Lake는 완벽하게 정상적인 세 가지 측정(방사능 2.19, 염도 0.09, 온도 -16.0)을 기록했다. 하지만 Roerich는 41.6이라는 터무니없는 염도값을 측정했다.
이 사건이 Lake로 하여금 DR-3 지역을 집요하게 재조사하게 만든 출발점이었을 것이다. 무엇이 Roerich의 측정 장비를 고장내었을까? 아니면… 다른 이유가 있었을까?
💭 생각해볼 점
1930년 Dyer 교수가 손으로 기록하며 며칠 밤을 고민했던 문제들을, 우리는 몇 분 안에 풀어냈다. ORDER BY로 시간순 단서를 정리하고, WHERE로 용의자를 추적하며, 복합 조건으로 범인의 흔적을 찾았다. 심지어 AI와 SQL이라는 두 탐정이 서로 경쟁하며 더 정확한 추리를 해냈다.
하지만 정말로 우리가 1930년대 탐사대보다 나은 탐정일까?
Lake가 DR-3에 집착한 이유, Roerich의 비정상적인 염도값들, 그리고 사라진 752번 방문의 날짜… 이 모든 단서들이 하나의 큰 그림을 그리고 있다. 90년 전 과학자들이 놓쳤던 연결고리를, 현대의 도구로 마침내 찾아낼 수 있을까?
탐정으로서의 당신의 추리는 무엇인가? 1930년대 남극에서 정말 무슨 일이 일어났을까? 다음 장에서는 여러 테이블을 연결하는 JOIN이라는 강력한 도구를 사용해 이 미스터리의 마지막 퍼즐을 맞춰볼 것이다…