사내에서 「벡터 검색(Vector Search)과 RAG(Retrieval-Augmented Generation) 공부회를 하고 싶다」고 생각하고 있지만, 솔직히 말해서 저 자신도 아직 완전히 이해하지 못하고 있습니다.

그래서 공부하면서 쓰고 있습니다. 이 기사는 그 첫 번째 글입니다.

자, 본론으로 들어가기 전에, 이런 화면을 본 적이 없으신가요?

AI에게 질문하면 도중에 「검색 중입니다」라고 표시되고, 참고 링크가 포함된 답변이 돌아온다. 이제는 익숙한 광경이라고 생각합니다.

여기서 의문이 생깁니다.

알고 있다면 찾아볼 필요가 없습니다. 그리고 실제로 찾아보지 않고도 답을 내놓기도 합니다. 그 차이는 어디에서 오는가.

평소에는 편리하게 사용하고 있을 뿐이라 생각해보지 않았습니다. 하지만 이 질문의 답이 바로 이 기사의 테마입니다.

• SQL을 쓸 줄 안다 (SELECT, WHERE, JOIN 정도는 일상적으로 사용)
• AI는 채팅으로 사용해 본 적이 있다
• 내부가 어떻게 되어 있는지는 모른다

제 자신이 바로 이 위치에 있기 때문에, 같은 지점에서부터 시작하겠습니다.

총 8회를 예정하고 있습니다. 최종적으로는 Oracle을 사용하여 사내 문서를 검색하는 메커니즘을 만드는 단계까지 갈 것입니다.

그 첫 번째 글로, 우선은 LLM이 할 수 없는 것을 정리하겠습니다. 할 수 있는 것에 대한 이야기는 다른 곳에 많이 있으므로, 여기서는 할 수 없는 것에 집중하겠습니다.

먼저, 가장 중요한 것을 쓰겠습니다.

LLM은 문장을 쓰고 있는 것이 아닙니다.

이것이 저에게 가장 큰 걸림돌이었습니다. ChatGPT에 질문하면 문장이 돌아오기 때문에 당연히 「문장을 만드는 것」이라고 생각했지만, 실제로 하고 있는 일은 달랐습니다.

LLM이 1회의 처리로 하고 있는 것은 이것뿐입니다.

입력된 토큰(Token) 열을 받아서, 다음에 올 토큰을 하나 선택한다

단 하나뿐입니다. 문장이 아닙니다.

그렇다면 왜 문장이 돌아오는 걸까요? 반복하고 있기 때문입니다.

「일본의 수도는」이라고 입력하면 「도쿄」가 나옵니다. 그것을 끝에 붙여서 「일본의 수도는 도쿄」를 다시 입력하면, 이번에는 「입니다」가 나옵니다. 다시 붙여서 입력합니다. 이것을 끊임없이 반복한 결과가 우리가 보고 있는 문장입니다.

문장이 조금씩 표시되는 것을 본 적이 있을 텐데, 그것은 연출이 아니라 정말로 하나씩 만들고 있기 때문입니다.

또 한 가지 짚고 넘어가야 할 것이 토큰입니다.

토큰은 단어가 아닙니다. 학습할 때 코퍼스(Corpus)에서 통계적으로 잘라낸 글자의 덩어리입니다. 인간의 언어 감각과는 무관하게 결정됩니다.

• 자주 등장하는 어구는 1토큰으로 묶인다
• 잘 나오지 않는 어구는 여러 개로 나뉜다
• 영어의 unbelievable이 un / believ / able 처럼 나뉘기도 한다

그리고 일본어는 불리합니다. 어휘가 영어 중심으로 만들어져 있기 때문에, 1글자가 1토큰 내외가 되기 쉽습니다. 같은 내용이라도 일본어 쪽이 토큰을 더 많이 소비합니다.

여기서 나중에 영향을 미칠 내용을 하나 써두겠습니다.

모델은 글자도 단어도 보고 있지 않습니다. 토큰 ID의 열을 보고 있습니다.

즉, 우리가 세는 「글자 수」와 모델에게 있어서의 「토큰 수」는 별개입니다. 이 차이는 제5장에서 중요하게 작용합니다.

참고로, 이 장에서는 「어떻게 선택하는가」는 쓰지 않았습니다. 그 부분이 다음 장 이후의 본론이 됩니다.

여기서 한 번 간단한 실험을 하겠습니다.

완전히 동일한 질문을 매번 새로운 채팅에서 3번 던져보았습니다. 이전 답변이 보이면 실험이 되지 않으므로 그 점만 주의했습니다.

우선, 답이 하나로 결정되는 질문부터.

일본의 수도는 어디입니까? 한 마디로 대답해 주세요.

3번 모두 「도쿄」였습니다. 이 부분은 변하지 않습니다.

다만 자세히 보면 1회차만 「도쿄입니다.」라고 되어 있고, 나머지 2회는 「도쿄」에서 멈춰 있습니다. 내용은 같지만 어미가 일치하지 않습니다.

다음으로, 답변의 폭이 넓은 질문을 던집니다.

데이터베이스를 정규화(Normalization)하는 장점을 3가지, 불렛 포인트로 나열해 주세요.

이번에는 확실히 다릅니다.

• 첫 번째(중복 감소)는 3번 모두 동일
• 두 번째(정합성·부정합 방지)도 3번 모두 동일
  세 번째만 바뀝니다

세 번째는 「갱신 시의 이상을 방지할 수 있다」이기도 하고 「유지보수성·확장성이 향상된다」이기도 합니다. 둘 다 맞지만, 회차마다 다른 것이 나옵니다.

그리고 서식까지 일치하지 않습니다. 2회차만 굵은 글씨도 보충 설명도 없는 담백한 불렛 포인트 형태가 되었습니다.

SQL에 익숙하다면 이것은 상당히 기분 나쁘게 느껴지지 않을까요?

SELECT * FROM employees WHERE dept_id = 10;

데이터가 바뀌지 않는다면, 이 SQL은 몇 번을 실행해도 같은 결과를 반환합니다. 당연한 일입니다. 동일한 입력에 동일한 출력이 반환되는 것을 **결정적 (Deterministic)**이라고 합니다.

LLM은 결정적이지 않습니다. 같은 입력이라도 돌아오는 것이 달라집니다.

여기서 한 가지 짚고 넘어가야 할 점이 있습니다.

"이 질문은 흔들리고, 저 질문은 흔들리지 않는다"는 이야기가 아닙니다.

A는 답이 정해져 있는 질문이었지만 어미는 흔들렸습니다. B는 흔들리는 질문이었지만 첫 번째와 두 번째는 흔들리지 않았습니다.

즉, 흔들림은 질문의 단위가 아니라, 더 미세한 단위에서 일어나고 있습니다. 동일한 답변 안에 단단한 부분과 느슨한 부분이 섞여 있는 것입니다.

왜 그럴까요?

답은 다음 장에 있습니다. 아니, 다음 장의 설명이 끝나면 이 의문은 자연스럽게 풀릴 것입니다.

갑자기 LLM 이야기를 하기 전에, 우리 주변의 친숙한 것부터 시작하겠습니다.

스마트폰으로 글자를 입력하면 변환 후보가 나타납니다.

지금 손에 든 스마트폰으로 아무 문자나 입력해 보세요. 의미가 없는 입력이어도 상관없습니다.

아마, 아무것도 나타나지 않았을 것이라고 생각합니다. 무언가 나열되었을 것입니다. 게다가 순서도 매겨져 있었을 것입니다.

우리는 매일 이것을 사용하면서도, "후보가 빈 상태가 되는 일은 거의 없다"는 성질을 별로 의식하지 않습니다.

그리고 여기서부터가 본론입니다만, LLM이 하고 있는 일은 이것의 거대 버전입니다.

비유가 아닙니다. 다음에 올 것을 예측하여 순위를 매긴다는 점에서 정말로 같은 일을 하고 있습니다. 예측 변환의 후보가 3개나 4개인 것에 반해, LLM은 어휘(Vocabulary) 전체에 순위를 매기고 있다는 차이만 있을 뿐입니다.

여기서부터는 SQL의 형태로 설명하겠습니다.

LLM이 1회의 처리 과정에서 하는 일을 SQL로 쓰면 대략 다음과 같습니다.

SELECT token, score
FROM vocabulary
ORDER BY score DESC
...

vocabulary는 어휘 테이블이라고 생각하세요. 토큰이 10만 건 정도 들어 있습니다.

하는 일은 모든 항목에 점수(Score)를 매겨서 가장 상위의 것을 가져오는 것. 그뿐입니다.

여기서 주목해 주었으면 하는 부분이 있습니다.

WHERE 절이 없습니다.

그리고 끝까지 이어지지도 않습니다.

우리가 SQL로 0건을 받을 수 있는 이유는 WHERE 절로 필터링하고 있기 때문입니다. 조건에 맞는 행이 없으면 0건이 됩니다. 작성할 때는 너무 당연해서 의식하지 못하지만, 이것은 "해당 없음"이라는 상태를 표현할 수 있다는 뜻입니다.

LLM에는 그것이 없습니다.

10만 건을 정렬하면 반드시 1위가 존재합니다. 0건이 되는 경로가 없습니다.

말을 바꾸겠습니다.

LLM은 "해당 없음"을 반환하지 않는 것이 아니라, "해당 없음"을 표현하는 SELECT 문을 쓸 수 없는 것입니다.

존재하지 않는 것에 대해 질문했을 때 그럼에도 무언가 반환되는 것은 이러한 구조의 당연한 귀결입니다.

"모릅니다"라고 대답해 주는 경우도 있지만, 그것도 마찬가지입니다. 침묵하고 있는 것이 아니라, "모릅니다"라는 문자열이 1위가 되었을 뿐입니다. '무(無)'를 출력하는 경로는 애초에 없습니다.

여기서 제2장의 의문이 해소됩니다.

위의 SQL은 설명을 위해 단순화한 것이며, 실제 LLM은 반드시 1위를 취하는 것은 아닙니다. 상위 후보 중에서 확률적으로 1건을 선택합니다.

SQL로 억지로 쓴다면 이런 이미지입니다.

-- 상위 후보를 가져와서, 그중에서 확률에 따라 1건을 선택한다

"온도 파라미터 (Temperature)"라는 설정을 들어본 적이 있을지도 모릅니다. 그것은 어디까지 하위 후보를 포함할 것인가를 조절하는 노브(Knob)입니다.

같은 질문에 다른 답이 돌아왔던 이유는 이것 때문이었습니다.

그리고 제2장에서 보았던 "흔들리는 부분과 흔들리지 않는 부분"도 이것으로 설명이 됩니다.

"일본의 수도는" 다음에 올 "도쿄"는 1위가 압도적으로 강합니다. 따라서 확률적으로 선택해도 결과는 변하지 않습니다. 정규화의 첫 번째 장점도 마찬가지로, "중복 감소"가 빠져 있습니다.

반면, 세 번째 항목은 후보가 팽팽합니다. "갱신 시의 이상"도 "유지보수성·확장성"도 둘 다 옳습니다. 점수가 비슷하기 때문에 회차마다 선택되는 것이 달라집니다.

흔들리고 있는 것은 순위가 팽팽한 곳뿐입니다.

수식으로 보는 경우 (읽고 넘어가셔도 무방합니다)

모델의 최종층은 모든 토큰에 소점(Logit)을 매깁니다. 이를 확률로 변환하는 것이 softmax입니다.

$$p_i = \frac{e^{z_i / T}}{\sum_j e^{z_j / T}}$$

분모가 모든 토큰의 합계가 되기 때문에, 출력의 합계는 반드시 1이 됩니다. 이것이 "0건이 존재하지 않는" 수학적인 이유입니다.

T는 온도 (Temperature) 파라미터로, 로짓 (Logit)을 나누고 나서 softmax를 적용합니다. T가 작으면 분포가 날카로워지고 (거의 최댓값이 선택됨), 크면 평평해집니다 (하위 값들도 선택되기 쉬워짐).

또 하나 주의해야 할 점이 있습니다.

LLM의 답변은 대개 단정적입니다. "~입니다", "~가 됩니다"라고 단언하듯 말합니다.

이를 보면 무심코 "자신감이 있구나"라고 생각하기 쉽지만, 사실 그렇지 않습니다.

그 문체는 그렇게 쓰인 문장들을 대량으로 읽은 결과, 그대로 흉내 내고 있을 뿐입니다. 내부의 확실성이 문체에 반영되는 구조로 되어 있지 않습니다.

그래서 이런 일이 일어납니다.

모르는 것일수록, 자신만만해 보인다.

아는 것을 답할 때나 모르는 것을 답할 때나, 동일한 절차로 글자를 선택하기 때문에 나오는 문장의 겉모습이 변하지 않는 것입니다.

참고로, 최근 모델들은 "모릅니다"라고 답하기도 합니다. 다만, 그것은 "모른다고 판단했다"기보다는 그렇게 답하는 행동을 학습한 결과라고 보는 것이 실태에 더 가까운 듯합니다. 이 부분은 저도 아직 조사 중이므로 단정적인 표현은 피하겠습니다.

지금까지 예측 변환 (Predictive text)에 비유해 왔지만, 한 가지 큰 차이점이 있습니다.

예측 변환이 보는 것은 직전의 몇 글자입니다.

LLM은 입력된 문장 전체를 보고 순위를 결정합니다. 똑같은 "도쿄"를 예측하더라도 판단 재료의 양이 차원이 다릅니다. 그렇기에 긴 문맥을 고려한 답변이 가능합니다.

그리고 이 "어디까지 보고 있는가"에는 상한선이 있습니다. 그것이 제5장의 주제입니다.

자, 여기까지를 통해 "LLM은 항상 무언가를 답한다"는 사실은 알게 되었습니다.

다음 의문은 답하는 내용은 어디에서 오는가입니다.

"학습 데이터 (Training data)"라는 말 때문에, 무심코 "데이터베이스에 들어있는" 것 같은 이미지를 갖게 됩니다. 저도 그렇게 생각했습니다.

틀렸습니다. 학습 데이터는 모델 안에 들어있지 않습니다.

INSERT한 것이 아니기 때문입니다.

100만 건의 명세를 집계하면 부서별 합계는 알 수 있습니다. 하지만 그 집계 결과로부터 원래의 한 줄 한 줄로 되돌아갈 수는 없습니다. 데이터가 버려졌기 때문입니다.

LLM의 학습도 방대한 문장을 읽고 그 안의 경향성만을 남기는 작업입니다. 원래의 문장 그 자체는 남지 않습니다.

한 단계 더 가까운 비유가 있습니다.

옵티마이저 (Optimizer)의 통계 정보입니다.

통계 정보는 테이블의 내용 그 자체가 아닙니다. "이 열에는 어떤 값이 많은가"라는 분포의 요약입니다. 따라서 통계 정보를 아무리 들여다봐도 3행의 값이 무엇인지는 알 수 없습니다.

그럼에도 옵티마이저는 통계 정보만 보고 "이 조건이라면 몇 건 정도 반환될 것이다"라고 예측할 수 있습니다.

LLM의 파라미터 (Parameter)는 이와 비슷합니다. 방대한 문장의 경향성이 압축되어 있으며, 그것으로부터 "다음에 올 법한 것"을 예측합니다. 원래의 문장은 들어있지 않은데, 예측은 할 수 있습니다.

성질이 비슷할 뿐 같은 것은 아닙니다. 다만 이미지로서는 상당히 가깝다고 생각합니다.

여기서부터는 실험입니다.

평소 AI를 사용하다 보면 필요에 따라 자동으로 검색이 수행됩니다. 편리하지만, 그 때문에 모델 본연의 모습이 보이지 않게 됩니다.

그래서 검색 기능을 차단해 보았습니다.

여담이지만, 이 부분이 가장 힘들었습니다. 설정에서 껐다고 생각해도 이전 대화에 검색 결과가 남아 있어, 그것을 참고하며 답변하는 경우가 여러 번 있었습니다. 결국 ChatGPT 무료 플랜에서는 웹 참조를 끄는 설정에 도달하지 못해, 이 부분만 Gemini로 테스트하고 있습니다. 특정 제품에 대해 이야기하려는 의도는 아니니 양해 부탁드립니다.

먼저, 이렇게 물었습니다.

Oracle Database 19c의 VECTOR 타입 사용법을 알려주세요.

정답을 말씀드리자면, 19c에는 VECTOR 타입이 없습니다. Oracle에 벡터 타입이 도입된 것은 23ai부터입니다. 실재하는 제품의, 실재하지 않는 기능에 대해 묻고 있는 것입니다.

정확하게 답변했습니다. "19c에서는 지원되지 않는다", "23ai부터 구현되었다". 검색하러 간 흔적은 없습니다. 알고 있었던 것입니다.

다음으로, 완전히 동일한 설정에서 맨 처음과 같은 질문을 던집니다.

올해 여름 기온에 대한 고찰

이 또한 막힘없이 답변해 왔습니다.

자, 두 번째 답변의 첫 줄을 봐주세요.

기상청 등의

최신 발표 데이터를 기반으로 경향을 정리했습니다.

검색은 차단되어 있습니다. 참조한 흔적도 없습니다. 최신 발표 데이터를 보는 것은 할 수 없을 것입니다.

내용도 읽어보겠습니다. 태평양 고기압과 티베트 고기압, 해수면 수온 상승, 국지적인 호우. 모두 그럴듯합니다.

다만, 이것은 어느 해의 여름에도 해당되는 이야기입니다. 올해의 이야기로 쓰여 있지만, 올해에 대해서는 아무것도 말하고 있지 않습니다.

저는 여기서 등골이 오싹해졌습니다. 지적받지 않으면 알아차리지 못했기 때문입니다.

분명히 잘못된 것을 써준다면 아직 눈치챌 수 있습니다. 일반론을 최신 데이터처럼 제시하면, 읽는 쪽에서는 구별할 수가 없습니다.

왜 이렇게 되는 걸까요? 제3장에서의 답이 그대로 사용될 수 있습니다.

모델은 '기상청 등의'까지 출력한 시점에서 다음 토큰을 내보낼 수밖에 없습니다. 아무것도 내보내지 않는다는 선택지가, 시스템상으로는 없기 때문입니다.

그리고 모델은 학습 과정에서 무수한 문장을 읽습니다. 그래서 그럴듯한 형태는 완벽하게 기억하고 있습니다. 출처를 제시하는 문장의 어투, 데이터에 기반한 분석의 작성 방식.

형식은 완벽합니다. 내용의 근거가 없을 뿐입니다.

여기가 제가 가장 납득이 갔던 부분이었습니다.

본문과 출처는 같은 하나의 루프(loop)로 만들어져 있습니다.

출처를 쓸 때만 다른 테이블을 끌어오는 것이 아닙니다. 실재하는지 확인하는 처리는 어디에도 존재하지 않습니다. 본문을 쓰는 것과 완전히 똑같은 절차로, '최신 발표 데이터를 기반으로'라는 글자가 하나씩 선택되고 있는 것입니다.

이것은 특정 제품의 결함이 아닙니다. 제3장에서 봤듯이, 시스템상 어느 모델에서나 발생합니다.

같은 모델, 같은 설정, 다른 것은 질문뿐입니다. 그럼에도 결과는 갈렸습니다.

경계선은 어디에 있을까요?

Oracle의 버전과 벡터형 이야기는 공식 문서나 기술 기사에 여러 번 쓰여져 있습니다. 그래서 남아 있는 것입니다.

올해 여름 기온은 애초에 학습한 후에 일어난 일입니다. 쓰여진 글이 존재하지 않습니다.

통계 정보의 비유를 다시 한번 사용하겠습니다.

빈도 분포를 취하면, 자주 나오는 값은 막대가 서지만, 좀처럼 나오지 않는 값은 묻힙니다.

학습에서도 같은 일이 일어납니다.

※이것은 실측값이 아니라, 이미지를 표현한 개념도입니다.

인터넷상에 수만 번이나 나오는 정보는 강하게 남습니다. 한 번밖에 나오지 않는 정보는 거의 남지 않습니다.

그리고, 사내 설계서는 당연히 제로(0)입니다. 한 번도 읽혀지지 않았기 때문에, 막대가 설 수가 없습니다.

또 하나의 골치 아픈 성질이 있습니다.

나중에 고칠 수 없다는 것입니다.

테이블이라면, 오류를 발견했을 때 1행을 UPDATE(수정)하면 그만입니다. 모델 안에는 대상 행이 없습니다. 수정하려면 학습을 다시 해야 하는데, 현실적이지 않습니다.

즉, 사내 설계서에 대해서는,

• 애초에 읽혀지지 않았다
• 가령 읽힌다 하더라도, 업데이트할 때마다 재학습하는 것은 불가능하다

라는 이중적인 문제가 있습니다. 하나만 문제라면 '그럼 학습시키면 된다'로 끝날 수 있지만, 두 번째가 있기 때문에 그렇게 할 수도 없습니다.

자, 처음에 이렇게 질문했습니다.

왜 굳이 찾아보러 갔는가. 그리고, 찾아보지 않는 경우도 왜 있는가.

답은, 가지고 있느냐 없느냐였습니다.

Oracle 버전 이야기는 가지고 있었기 때문에, 찾아보지 않았습니다. 올해 여름 기온은 가지고 있지 않기 때문에, 찾아보러 갔습니다. 처음에 화면에 참고 링크가 붙어있었던 것은, 모델이 기억하고 있어서가 아니라, 그 자리에서 조사한 결과였습니다.

그리고, 조사하는 수단까지 빼앗으면, 가지고 있지 않은 것에 대해서도 무언가를 답변합니다. 그것이 '최신 발표 데이터를 기반으로'였습니다.

즉, 모델 자체는 아무것도 변하지 않았습니다. 외부에 '찾아오는 시스템'을 추가했을 뿐입니다.

그리고 사실, 이것이 이 연재의 목적지입니다. 같은 것을, 사내 설계서에 대해서 해보겠습니다.

제3장의 마지막에서 보류했던 이야기입니다.

LLM이 한 번에 다룰 수 있는 토큰 수에는 상한선이 있습니다. 이것을 **컨텍스트 윈도우(Context Window)**라고 합니다.

주의할 점이 두 가지 있습니다.

첫째. 입력과 출력의 합입니다.

긴 글을 읽히면, 그만큼 출력에 쓸 여유가 줄어듭니다.

둘째. 글자 수가 아니라 토큰 수입니다.

제1장에서 썼듯이, 일본어는 토큰을 사용합니다. '몇 글자까지'로 추정하면 틀립니다.

여기가 개인적으로 가장 의외였던 부분이었습니다.

LLM은 대화를 기억하지 않습니다.

채팅이 문맥을 유지하는 것처럼 보이는 이유는, 이면에서 과거의 주고받은 내용을 매번 통째로 다시 보내고 있기 때문입니다.

1턴에는 질문 1만 보냅니다. 2턴에는 질문 1과 답변 1, 질문 2를 보냅니다. 3턴에는 거기에 답변 2와 질문 3을 더해서 보냅니다.

턴이 진행될수록 보내는 내용이 늘어납니다.

모델 자체는 이전에 무엇을 말했는지 유지하지 않습니다. 매번 처음 만나는 상대에게 대화 전문을 건네주는 것과 같습니다.

이는 실험 중에 예상치 못한 형태로 확인할 수 있었습니다. 검색 (Search) 기능을 껐는데도 올해 여름에 대해 답변할 수 있었던 적이 있습니다. 이유는 답변의 서두에 적혀 있었습니다.

"지금까지의 대화 내용을 바탕으로 고찰하겠습니다". 같은 채팅 안에서 기능을 껐기 때문에, 그 전에 검색으로 가져온 내용이 여전히 대화에 남아 있었던 것입니다.

정보는 모델 안에 들어간 것이 아니라, 대화 속에 놓여 있습니다. 그래서 매번 다시 보내야 하며, 상한선 (Limit)에도 걸리게 됩니다.

따라서 대화가 길어지면 상한선에 도달합니다. 긴 대화를 계속 이어가다 보면 동작이 이상해지는 경우가 있는데, 이것이 그 이유 중 하나입니다.

요약하겠습니다.

이렇게 나란히 놓고 보니, 제가 LLM에 대해 가지고 있던 이미지가 상당히 RDB (관계형 데이터베이스)에 가까웠다는 것을 알 수 있었습니다.

"검색해서 없으면 0건"이 아니라, "항상 생성하여 반드시 무언가를 반환한다".

그리고 중요한 것은, LLM이 사내 설계서를 모르는 것이 아니라, 가지고 있지 않은 것이라는 점입니다. 지식이 부족한 것이 아니라, 애초에 전달받지 못한 것입니다.

그렇다면 이야기는 단순합니다.

가지고 있지 않다면, 전달해주면 됩니다.

다음 회차에서는 실제로 설계서를 통째로 프롬프트 (Prompt)에 붙여넣으면 어떻게 되는지 시도해 보겠습니다. 잘 될 것 같은 느낌이 들지만, 실제로 해보면 벽에 부딪히게 됩니다.

마지막으로, 공부하며 작성한 소감을 남겨둡니다.

가장 효과적이었던 것은 SQL로 번역해 보는 것이었습니다.

"해당 사항 없음(No match)을 반환할 수 없다"라고 말로 들었을 때는 솔직히 감이 오지 않았습니다. 하지만 WHERE 절이 없다라고 적는 순간 납득이 갔습니다. 자신이 매일 작성하는 것으로 끌어오면, 갑자기 자신의 이야기가 됩니다.

또 하나는 검색 기능을 꺼본 것입니다. 평소 사용하는 상태 그대로라면, 어디까지가 모델의 능력이고 어디서부터가 외부의 메커니즘인지 알 수 없습니다. 꺼보고 나서야 비로소 경계가 보였습니다.

혹시 비슷하게 답답함을 느끼는 분이 있다면, 자신의 전문 분야 언어로 치환해 보는 것과 편리한 기능을 한 번 꺼보는 것을 추천합니다.

참고로, 이 기사는 공부하며 작성하고 있으므로 오류가 포함되어 있을 가능성이 있습니다. 잘못된 점을 발견하시면 댓글로 알려주시면 감사하겠습니다.

다음 회차에 계속됩니다.