나는 LLM을 지식을 대신 외워주는 도구보다, 내 사고 모델을 빠르게 만들고 검증하는 대화형 튜터로 활용한다.

1. 개념을 먼저 구조화한다

새로운 분야를 배울 때 세부 구현부터 들어가기보다, 먼저 전체 구조와 핵심 개념 사이의 관계를 잡는다.

예를 들어 백엔드 대규모 시스템을 공부할 때도 특정 DB나 프레임워크의 사용법보다 먼저 다음과 같은 구조를 만든다.

• 데이터는 어떻게 저장되는가
• 어떻게 빠르게 읽는가
• 동시에 수정되면 어떻게 되는가
• 장애가 나면 어떻게 복구하는가
• 한 DB로 감당할 수 없으면 어떻게 확장하는가

이 과정에서 LLM에게 개념을 계층화하고 연결해서 설명하도록 요구한다.

목표는 용어를 많이 아는 것이 아니라, 이후 새로운 기술을 보더라도 어디에 위치하는지 판단할 수 있는 정신적 지도(Mental Model)를 만드는 것이다.

2. 설명을 그대로 받아들이지 않고 내 언어로 다시 표현한다

설명을 들은 뒤에는 반드시 내가 이해한 내용을 다시 표현한다.

예를 들어 원자성을 다음처럼 이해했다.

SELECT와 UPDATE가 분리되어 있으면 그 사이가 시간 구간이기 때문에 다른 변경이 끼어들 수 있다.
이를 하나의 원자적 연산으로 만들면 중간에 개입할 수 없는 하나의 점처럼 취급할 수 있다.

이런 식으로 기술 용어를 그대로 암기하기보다 내가 이해할 수 있는 모델로 변환한다.

LLM의 역할은 여기서 답을 다시 설명하는 것이 아니라,

• 내 비유가 어디까지 맞는지
• 어디서부터 틀어지는지
• 어떤 용어와 구분해야 하는지

를 검증하는 것이다.

3. 비슷한 개념의 경계를 집요하게 확인한다

개념을 배울 때 가장 중요하게 보는 것은 정의 자체보다 서로 비슷한 개념의 경계다.

예:

• Transaction vs Lock
• Atomicity vs Serializability
• MVCC vs Lock
• Non-repeatable Read vs Phantom Read
• Optimistic Lock vs Pessimistic Lock

두 개념을 각각 설명하는 것보다,

“둘이 뭐가 다른데?”

를 반복해서 묻는다.

이 방식은 개념을 독립된 단어가 아니라 차이와 관계의 네트워크로 기억하게 만든다.

예를 들어 다음처럼 압축한다.

• Transaction → 여러 작업의 논리적 경계
• Atomic SQL → read/write 사이 경합 구간 제거
• MVCC → 읽는 세계를 분리
• Lock → 쓰는 순서를 조정
• Isolation → 서로의 변경을 어디까지 볼지 결정

이런 압축된 구분이 만들어질 때 개념이 실제로 이해됐다고 판단한다.

4. 개념을 바로 문제에 적용한다

설명을 충분히 들은 뒤에는 다시 설명을 요청하기보다 문제를 요청한다.

특히 다음 형태를 선호한다.

“이 코드 안전한가?”

예:

SELECT stock;

if stock > 0:
    UPDATE stock;

또는

UPDATE products
SET stock = stock - 1
WHERE stock > 0;

처럼 실제 코드를 두고 판단한다.

이를 통해 단순히 개념을 기억하는지보다,

• Race Condition을 발견하는가
• Atomic SQL로 바꿀 수 있는가
• Lock이 필요한가
• affected rows를 확인해야 하는가
• Deadlock 가능성이 있는가

를 확인한다.

즉 학습을 설명 → 적용 → 피드백 사이클로 만든다.

5. 틀린 부분을 전체 실패로 보지 않고 정확한 미끄러짐 지점을 찾는다

문제를 틀렸을 때는 “이 개념을 모른다”고 결론 내리지 않는다.

대신 어디서 사고가 미끄러졌는지를 찾는다.

예를 들어 다음 문제에서:

UPDATE products
SET stock = stock - 1
WHERE stock > 0;

INSERT INTO orders (...);

Transaction 안에 있으므로 안전하다고 판단했지만 실제 문제는 Transaction 이해가 아니었다.

핵심 누락은:

UPDATE 0 rows도 SQL 관점에서는 정상 실행이다.

라는 점이었다.

그래서 실패를 다음처럼 더 작은 학습 단위로 분해했다.

동시성 개념 부족 ❌
affected rows를 비즈니스 결과로 해석하는 감각 부족 ✅

이렇게 하면 이미 이해한 부분을 다시 처음부터 공부하지 않고, 정확히 부족한 부분만 보강할 수 있다.

6. 작은 오류에서 일반화 가능한 패턴을 뽑는다

한 문제를 고친 뒤에는 그 문제 하나로 끝내지 않는다.

예를 들어 affected rows를 놓친 경험에서 다음 패턴을 추출했다.

SQL 실행 성공 ≠ 비즈니스 성공

그리고 이를 다시 다음 설계 패턴으로 일반화한다.

조건부 Mutation + affected rows 확인

예:

UPDATE coupons
SET claimed = true
WHERE id = ?
AND claimed = false;

• affected rows = 1 → 내가 상태 변경에 성공
• affected rows = 0 → 이미 다른 요청이 선점

즉 한 번의 오답을 재사용 가능한 설계 원칙으로 변환한다.

7. 학습 중간에 스스로 새로운 인사이트를 만든다

LLM이 모든 결론을 알려주게 하지 않는다.

개념들이 연결되기 시작하면 내가 먼저 추론한다.

예:

단일 사용자의 상태에 대한 요청 경합은 충돌 빈도가 낮다면 낙관락으로 많이 해결할 수 있겠다.

이런 가설을 만든 뒤 LLM에게 검증을 요청한다.

그러면 LLM은 단순히 맞다/틀리다가 아니라 조건을 붙인다.

예:

• 낮은 write contention → Optimistic Lock
• 중복 요청 자체가 문제 → Idempotency / UNIQUE
• 한정된 자원 경쟁 → Atomic Update / Pessimistic Lock

이 과정에서 처음의 직관이 보다 일반적인 판단 기준으로 정교화된다.

즉 학습은:

설명을 받아들이는 과정

이 아니라

설명 → 내 추론 → 검증 → 수정

과정이다.

8. 세부 기술보다 판단 기준을 남긴다

최종적으로 기억하려는 것은 API나 문법이 아니라 판단 질문이다.

예를 들어 DB 동시성 문제를 볼 때 다음 질문을 자동으로 떠올리는 것을 목표로 한다.

1. 두 요청이 동시에 들어오면 어떻게 되는가?
2. read와 write 사이에 다른 요청이 들어올 수 있는가?
3. SQL 하나로 원자화할 수 있는가?
4. affected rows를 성공 여부로 확인해야 하는가?
5. 같은 row에 write contention이 발생하는가?
6. 낙관락과 비관락 중 어느 쪽의 비용이 더 작은가?
7. 중복 요청이라면 idempotency가 필요한가?
8. lock 순서 때문에 deadlock이 생길 수 있는가?

이런 질문 세트가 만들어지면 다른 DB나 다른 언어를 쓰더라도 동일한 사고방식을 적용할 수 있다.

전체 학습 루프

나의 LLM 학습 방식은 다음 루프로 요약할 수 있다.

새로운 분야
    ↓
전체 구조 파악
    ↓
핵심 개념 설명
    ↓
내 언어로 다시 모델링
    ↓
비슷한 개념 간 차이 확인
    ↓
실전 문제로 공격
    ↓
내가 직접 답변
    ↓
LLM이 오개념/미끄러짐 지점 판별
    ↓
틀린 이유를 작은 단위로 분해
    ↓
일반화 가능한 원칙 추출
    ↓
새로운 상황에 다시 적용

이 방식의 핵심은 LLM에게 생각을 맡기지 않는 것이다.

LLM은 다음 역할을 담당한다.

• 지식 구조화
• 설명
• 문제 생성
• 반례 제공
• 사고 검증
• 오개념 탐지

반대로 다음은 내가 직접 한다.

• 개념을 내 언어로 재구성
• 문제에 대한 판단
• 해결 방법 추론
• 여러 개념 연결
• 일반화된 원칙 도출

따라서 LLM은 답안지가 아니라 고속 피드백 루프를 제공하는 사고 파트너에 가깝다.

핵심 원칙

가장 압축하면 다음 네 문장으로 정리할 수 있다.

정의를 외우기보다 작동 모델을 만든다.

설명을 들은 뒤 반드시 내 언어로 다시 설명한다.

이해 여부는 문제를 풀어 검증한다.

틀린 문제에서는 정답보다 내가 어디서 미끄러졌는지를 찾는다.