코드를 찢다

AI Native 탭 개설

나죽못고나강뿐 — Sun, 19 Apr 2026 00:22:00 +0900

블로그 문 안 닫았습니다 ㅜㅜ

최근 바쁘기도 바빴지만, 대체 블로그 포스팅을 뭘 해야 하나 고민이 너무 많았다.

단순 정보를 조합해서 열거하는 건 AI 쓰면 될 일이고, 기술적 고민을 적자니 사내 보안에 걸릴까봐 벌벌 떨어야 하고.

애초에 AI 시대에 적을만한 기술적 고민을 적는다면 기술 유출범이나 다름 없지 않은가 싶었더니 진짜 쓸 게 없었다.

그래서 한동안 Review 탭에 뻘글을 적었는데, 이건 또 왜 조회수가 잘 나오는 건지 이해가 안 감.

최근 가장 몰두하고 있는 것이 AI Native에 대함인데, 막상 또 이걸 적으려니 인플루언서형 개발자가 되어가는 느낌이라 영 불쾌했다.

평가 기준이 모호해서 정말 뭐가 더 나아진 건지, 나아졌다고 착각하고 있는 건지 분간이 되질 않으니, 이런 내용들을 함부로 적고 싶지 않았다.

그래서 한동안 어떻게 엔지니어 관점에서 관련 경험들을 풀어나갈 수 있을 지 연구하는데 시간을 퍼부었던 것 같다.

그런 시간을 거친 덕분에 이제 나름 많은 의미있는 경험들을 축적하긴 했으나, 이걸 그대로 쓰기엔 또 보안 유출이 될 거 같아서 각색할 시간이 필요하긴 할 듯.

아무튼 거의 3주 가까이 포스팅을 못하고 있는데, 제 블로그 정상 운영 중입니다.

[대규모 시스템 설계] 8장. URL 단축키 설계

나죽못고나강뿐 — Sat, 4 Apr 2026 16:01:44 +0900

해당 내용은 "가상 면접 사례로 배우는 대규모 시스템 설계 기초"를 참조하여 작성하였습니다.

1. Introduction

Opening

내용도 쉽고 짧다.

심심풀이 삼아 읽어보기 좋은 파트.

Usecase

original URL을 단축 URL로 표현해야 하며, 단축 URL로 original URL로 갈 수 있어야 한다.
단축 URL 결과는 짧을 수록 좋다.
연산
- 쓰기 연산: 매일 1억 개의 단축 URL 생성
- 초당 쓰기 연산: 100 (million * writes/day) / 24 (hr/day) / 3,600 (sec/hr) = 1,157 (writes/sec)
- 읽기 연산: 초당 11,600 (reads/sec) (assume, 읽기 연산 : 쓰기 연산 = 10 : 1)
저장 공간
- URL 단축 서비스를 10년간 운영하면, 100 million * 365 days * 10 years = 365 billion 개 record를 보관해야 함
- 축약 전 URL 평균 길이는 100이라고 가정 (단, URL은 모두 영문)
- 10년 동안 필요한 저장 용량 = 365 billion * 100bytes = 36.5TB

10년이 지나면 저장된 단축 URL은 제거한다고 봐도 될 듯.

2. Draft Desgin

API Endpoint

RESTful API style로 설계한다는 전제로 시작.

URL compression endpoint
- 새 단축 URL을 생성할 때는 다음과 같은 요청을 보내야 한다.
  - Request URL: POST /api/v1/data/shorten
  - parameters: {longUrl: longURLstring}
  - return: compressed URL
URL redirection endpoint
- 단축 URL로 HTTP 요청이 오면 origianl URL로 보내주기 위한 endpoint
  - Request URL: /api/v2/shortUrl
  - return: original URL (redirection)

URL Redirection

redirect되면 Location header에 original URL을 담아서 301 http status response를 반환한다.

301 Permanently Moved
- 해당 URL에 대한 HTTP 요청의 처리 책임이 영구적으로 Location header의 URL로 이전되었음을 의미
- 영구적 이전이므로, 브라우저가 response를 caching
- 서버 부하를 줄이는데 용이
302 Found
- 요청이 일시적으로 다른 URL로 이전되었음을 의미
- Client의 request는 브라우저에 cache되지 않으므로, 언제나 compression URL server로 전달되어야 함.
- 트래픽 분석(e.g., 클릭 발생률, 발생 위치 추적)에 용이
URL redirection의 가장 직관적인 구현 방법은 hash table을 사용하는 것

URL Compression

단축 URL의 형태가 www.example.com/{hashValue} 같은 형태라면, 긴 URL을 hash value로 대응시킬 hash function f(x)를 찾아야 한다.

f(x)의 요구사항

입력으로 주어지는 긴 URL이 다른 값이면 해시 값도 달라야 한다. (그것이 해시함수니까..)
계산된 해시 값은 원래 입력으로 주어졌던 original URL로 복원될 수 있어야 한다.

3. Detailed Design

Data Model

id가 꼭 auto increment여야 할 이유는 없다.

초기 설계: 모든 값을 hash table(in-memory)에 저장하자
- 한계: 직관적이지만 36.5TB 데이터를 어떻게 올릴 거냐?
그냥 RDB에 때려넣자.

캐싱이 필요할까?

읽기 연산이 쓰기 연산보다 10배 높다는 것이 가정이므로, 캐싱을 하는 것을 고려해볼 수는 있을 것 같다.
그런데 굳이 필요할까?

단축 URL을 공유하는 경우는 웹 서핑을 하다 우연히 타고 들어온 경우보다는 특수한 목적을 가지고 있을 확률이 높다.
예를 들어 confluence에서 문서를 공유할 때도 단축 URL을 사용하는 것처럼, 누군가가 정보를 공유했고 그 정보가 필요한 사람들일 확률이 높다.
이미 목적이 뚜렷한 사람들이 방문할 페이지이므로 조회가 조금 느려도 사용자가 이탈할 일은 그다지 없을 것이고, 따라서 캐싱까지 해가며 읽기 성능을 높여주어야 할까 싶긴 하다.
단축 URL을 사용하는 목적에 따라 달라질 듯.

그리고 어차피 읽기 연산이면 Tx도 안 걸고 쿼리 날려버리면 그리 느리지도 않을 거고, index도 기껏 해봐야 shortURL에 걸려있을 텐데 진짜 필요 없을지도.

Hash Function

hash value length

딱히 특별한 내용은 없음.

hashValue는 총 62개의 문자들로 구성
- [0-9, a-z, A-Z]
365 billion의 고유값을 보장하기 위한 n(=minimum hash value length)
- 62^n ≥ 365 million
- n ≥ 7

이게 끝;;

hash collision resolution

문제는 hash function 중에 7글자 문자열로 줄이는 hash function이 있을까?

출력 길이
- CRC32 (Cyclic Redundancy Check 32): 32 bits
- MD5 (Message-Digest Algorithm 5): 128 bits
- SHA-1: 160 bits

보안에 민감한 정보는 아니니 어떤 hash function을 써도 무방하지만, 가장 짧은 CRC32 조차 8글자.
- hash 에서 앞의 7자리만 자르면? → hash collision 발생 우려
- 충돌이 해소될 때까지 longURL에 사전에 정한 문자열을 덧붙여서 rehash? → 될 때까지 DB 조회할 거임?
  - longURL을 DB에 저장할 때는 원본값을 넣어야 한다. 안 그러면 뒤의 값의 어디까지가 덧붙여진 값인지 알아내야 하는 번거로움이 존재함.
- Bloom Filter 쓰자. (in-memory에서 "값의 존재 여부"를 매우 빠르고 저렴하게 확인하는 방법. 있다고 답할 땐 있을 수도 없을 수도 있는데, 없다고 답할 때는 진짜 없음을 보장.)

base-62 conversion

왜 base64가 아니라 62?
- hashValue에 사용가능한 문자 개수를 62개로 정했으므로.
왜 사용함?
- 수의 표현 방식이 다른 두 시스템이 같은 수를 공유해야 하는 경우

진법 변환은 그냥 뭐 하면 되는 거니까 설명이 불필요.

문제는 longURL이 정수가 아니면 어떻게 할 건데?

base-62 변환은 정수 → 문자열 변환이므로, 입력이 문자열이면 먼저 정수로 만들어야 함.

그래서 base-62는 Unique ID Generator를 필요로 함.

아마 이런 flow가 되지 않을까?

longURL 입력
ID Generator로 unique integer ID 발급
base-62 conversion
따란~

URL Compression

귀찮아서 NotebookLM으로 정리했더니 난리가 났다. 영어로 만들어달라고 할 걸 ㅜ

어려운 내용은 아니니 패스

URL Redirection

난 위에서 굳이 cache 쓸 필요 없다고 했던 거 같은데, 책은 읽기를 더 자주하는 시스템이므로 cache를 도입해봤다고 한다.

그냥 cache 없이 해보고, 성능 평가 시 불만족스러우면 도입하는게 ㅎㅎ;;

트래픽이 예측되지 않은 상황에서 무작정 cache 도입하면 문제만 복잡해지는 경우를 너무 많이 봤다.

개발자는 원래 직업을 없애는 직군이었다

나죽못고나강뿐 — Sat, 21 Mar 2026 00:58:05 +0900

1. 개발자는 원래 직없을 없애는 직군이었다.

누군가의 밥벌이를 코드로 치환하는 것.

그것이 개발자가 지금껏 해온 일이다.

회계사가 밤을 새워 장부를 맞추던 시절이 있었다.

숫자 하나 틀리면 처음부터 다시, 연필과 계산기 사이에서 수천 줄의 거래 내역을 눈으로 훑던 시절.

ERP 시스템이 그 자리를 가져갔다.

은행 창구에 줄을 서서 통장에 도장을 찍던 시절이 있었다.

인터넷 뱅킹이 그 줄을 없앴다.

공장에서 사람이 육안으로 불량품을 골라내던 시절이 있었다.

자동화 검수 시스템이 그 눈을 대체했다.

그 뒤에는 항상 개발자가 있었다.

개발자는 이 과정을 "비효율의 제거", "자동화", "혁신"이라고 불렀다.

틀린 말은 아니다. 실제로 비효율적이었고, 실제로 자동화가 되었고, 실제로 혁신이었다.

다만 그 혁신의 이면에는 항상 누군가의 자리가 사라지고 있었다는 사실을, 개발자들은 크게 신경 쓰지 않았다.

아니, 신경 쓸 이유가 없었다.

그건 "시대의 흐름"이었고, 자신들은 그 흐름을 만드는 쪽에 서 있었으니까.

수십 년간 개발자는 안전했다.

자동화의 칼날은 항상 바깥을 향했다.

코드를 짤 수 있는 사람은 자동화를 당하는 쪽이 아니라 자동화를 시키는 쪽이었고, 그 기술적 장벽은 견고해 보였다.

프로그래밍은 아무나 하는 게 아니었다.

수년간의 학습이 필요했고, 논리적 사고력이 필요했고, 끊임없는 기술 갱신이 필요했다.

그 진입 장벽이 곧 개발자의 성벽이었다.

그래서 개발자는 편안했다.

남의 직업을 없애면서도.

2. 그리고 자기 차례가 왔다.

개발자는 본질적으로 "귀찮음"을 싫어하는 사람들이다.

반복적인 작업을 보면 참지 못한다.

같은 코드를 두 번 작성하는 것을 혐오한다.

수동으로 할 수 있는 일을 수동으로 하는 것을 견디지 못한다.

그래서 프레임워크를 만들고, 라이브러리를 만들고, 빌드 자동화를 만들고, CI/CD 파이프라인을 만들었다.

어쩌면 전부 "귀찮으니까"라는 동기에서 출발했을 수도 있겠다.

아이러니한 건, 그러면서도 기술 탐구 자체에는 한없이 비효율을 감수한다는 점이다.

새로운 언어가 나오면 밤을 새워 공부하고, 더 나은 아키텍처가 있다면 기존 코드를 전부 갈아엎는 것도 마다하지 않는다.

아직 확실하게 개념이 확립되지도 않은 트렌드로 뒤덮어버리고 이직해버리기도 하고, 여러모로 아이러니한 인간들이다.

비효율을 제거하기 위해 비효율을 감수하는 모순, 하지만 그 모순이야말로 기술을 전진시켜 온 동력이었다.

그리고 그 동력이 결국 자기 자신에게까지 도달했다.

생각해보면 당연하다.

개발자가 세상의 모든 비효율을 자동화하겠다는 집념을 가진 사람들이라면, 자기 업무의 비효율도 당연히 자동화 대상이 된다.

코드 리뷰? 자동화하자.

테스트 작성? 자동화하자.

버그 수정? 자동화하자.

그리고 이제는 "코드 작성? 그것도 자동화하자."

자신들이 그토록 좋아하던 "코드를 작성한다"는 행위마저도, 결국 "딸깍" 한 번으로 처리하고 싶어진 것이다.

남의 일을 딸깍으로 만들어왔던 사람들이, 자기 일도 딸깍으로 만들고 싶어하는 건 지극히 자연스러운 귀결이다.

이건 위기가 아니라, 예정된 수순이었다.

개발자라는 직군은 태생적으로 자기 자신을 포함한 모든 것을 자동화하도록 설계된 사람들이다.

지금 일어나고 있는 일은 배신이 아니라 완성에 가깝다.

3. "도메인을 이해하는 개발자는 살아남는다"는 말

요즘 가장 많이 들리는 말 중 하나다.

"코드만 잘 짜는 시대는 끝났다. 비즈니스를 이해하고, 도메인 지식을 갖춘 개발자만이 살아남을 것이다."

맞는 말이다. 코드를 작성하는 것은 개발자 업무의 일부에 불과하다.

요구사항을 분석하고, 문제를 정의하고, 아키텍처를 설계하고, 기술적 의사결정을 내리고, 이해관계자와 소통하는 것 등.

모든 것이 개발자의 일이었고, AI가 코드 생성을 대체한다 해서 이 역할들이 한순간에 사라지지는 않을 것이다.

문제는 이 주장이 "그러니까 개발자는 괜찮다"는 결론으로 이어질 때 발생한다.

한 발만 더 나가보자.

"문제를 정의하고 구조화하는 역량이 중요해진다."

동의한다.

그런데 그 역량이 가장 뛰어난 사람이 누구인가?

도메인을 가장 깊이 이해하는 사람은 개발자가 아니라, 그 도메인에서 수십 년을 일한 종사자들이다.

금융을 가장 잘 아는 건 금융인이고, 의료를 가장 잘 아는 건 의료인이고, 물류를 가장 잘 아는 건 물류 전문가다.

개발자가 필요했던 이유는 이들에게 프로그래밍 역량이 없었기 때문이지, 개발자가 도메인을 더 잘 이해해서가 아니었다.

개발자는 어디까지나 번역가였다.

인간의 의도와 기계의 언어 사이를 중개하는 사람.

한국어를 영어로 옮기는 번역가가 존재했던 이유는, 두 언어를 모두 구사하는 사람이 드물었기 때문이다.

번역이라는 행위 자체가 고귀했기 때문이 아니다.

번역의 수요가 있었고, 번역할 수 있는 사람이 적었기 때문에 직업이 된 것이다.

개발자도 마찬가지다.

"비즈니스 요구사항"이라는 인간의 언어를 "코드"라는 기계의 언어로 옮기는 사람.

그 중개가 필요했던 이유는 기계의 언어가 어려웠기 때문이다.

그런데 지금, 자연어로 말하면 코드가 나오는 시대가 오고 있다.

중개 비용이 0에 수렴하면, 중개인은 필요 없어진다.

즉 "도메인을 이해하는 개발자가 살아남는다"는 말의 진짜 의미는 개발자로서 살아남는 게 아니라, 도메인 전문가로서 살아남는 것이다.

"개발자"라는 타이틀이 남는 게 아니라, "문제를 정의하는 사람"이라는 역할이 남는 것이다.

그리고 그 역할은 굳이 개발자가 아니어도 수행할 수 있다.

누구나 인스턴트 식품처럼 프로그램을 만들어낼 수 있는 시대에서 "문제를 정의하고 구조화하는" 역량은 더없이 중요해질 것이다.

하지만 그 역량의 주인이 반드시 "개발자"여야 할 이유는 점점 희미해지고 있다.

4. 직업은 사라지지 않고, 변형될 뿐이라구요?

이 말을 처음 들었을 때는 나도 고개를 끄덕였다.

산업혁명 때 방직공이 사라졌지만 공장 노동자가 생겼고,

마차꾼이 사라졌지만 택시 기사가 생겼고,

타자수가 사라졌지만 비서직이 생겼다.

거시적으로 보면 직업의 총량은 줄지 않았고, 형태만 바뀌었다.

경제학 교과서가 가르치는 기술적 실업의 역사다.

은행 창구 직원이 줄었지만 금융 상담사가 생겼다.

전화 교환원이 사라졌지만 통신 엔지니어가 생겼다.

맞다. 틀린 말이 아니다.

그런데 은행 창구 직원이었던 그 사람은 어떻게 되었나?

30년간 창구에서 일하며 가정을 먹여 살리던 사람에게, "당신의 직업은 사라진 게 아닙니다, 변형된 겁니다"라고 말할 수 있는가?

"금융 상담사라는 새로운 직업이 생겼으니 괜찮습니다"라고?

그 사람이 금융 상담사가 될 수 있었나? UX 디자이너가 될 수 있었나?

후대의 사람들은 변형된 직업에 적응할 수 있다.

처음부터 그 직업을 목표로 교육받고, 준비하고, 진입하니까.

하지만 이미 구시대의 직업에 생계를 의탁하고 있던 사람에게 "변형"이라는 단어는 아무런 위안이 되지 않는다.

그건 그냥 해고다.

"직업은 사라지지 않는다, 변형될 뿐이다"는 말은 역사를 요약할 때는 유용하다.

하지만 그 역사의 한가운데 서 있는 사람에게는 폭력적이다.

50년 뒤의 경제학자가 "2020년대에 소프트웨어 개발자가 줄었지만 AI 오케스트레이터라는 직업이 생겼다"고 서술할 수 있을 것이다.

그 문장은 사실일 것이다.

그리고 그 문장은, 그 사이에 잘려나간 수만 명의 개발자에게는 아무런 의미가 없을 것이다.

교과서적 낙관을 해고 통보서 위에 올려놓지 말아야 한다.

거시적 관점이 틀렸다는 게 아니다.

역사가 그래왔듯이 장기적으로는 새로운 직업이 생기고, 경제는 적응하고, 인류는 전진한다.

하지만 그 "장기적"이라는 단어 속에는 한 세대의 고통이 뭉개져 있다.

방직공에서 공장 노동자로의 전환이 수십 년에 걸쳐 수백만 명의 빈곤과 고통 속에서 이루어졌다는 사실을, "변형"이라는 단어는 너무 깔끔하게 포장한다.

나도 얼마 전까지 같은 말을 했다.

"직업이 사라지는 게 아니라 바뀌는 거야."

얼마나 세상 모르는 소리였는지 이제야 조금 알 것 같다.

5. 그런데도

AI가 거품이라고 태평하게 말하는 사람들이 있다.

"지금 AI가 과대평가되어 있어", "결국 닷컴 버블처럼 꺼질 거야", "아직 개발자 대체하기엔 한참 멀었어."

틀릴 수도 있다. 진짜 거품일 수도 있다.

하지만 그 태평함의 근거가 분석이 아니라 안도라는 게 문제다.

현실을 직시한 뒤에 내린 판단이 아니라, 직시하기 싫어서 내린 결론이라는 게 문제다.

AI의 기술 트렌드를 쫓기 급급한 사람들이 있다.

새로운 모델이 나오면 벤치마크를 비교하고, 새로운 프레임워크가 나오면 튜토리얼을 돌리고, 새로운 논문이 나오면 요약본을 공유한다.

기술을 공부하는 것 자체는 나쁘지 않다.

하지만 "이 기술이 내 존재에 어떤 의미인가"를 묻지 않고 기술만 축적하는 것은, 무기가 자기에게 겨누어지는 줄 모르고 무기를 닦는 것과 다르지 않다.

특정 기술에 자신의 정체성을 묶어버리는 사람들이 있다.

"나는 자바 개발자입니다." "나는 리액트 전문가입니다." "나는 스프링 엔지니어입니다."

기술은 도구인데, 도구에 이름을 걸어버리면 도구가 필요 없어질 때 자기 자신도 같이 필요 없어진다.

목수가 "나는 망치 전문가입니다"라고 말하지 않는 것처럼, 개발자도 특정 기술이 아니라 해결하는 문제로 자신을 정의해야 하는데 그걸 못하는 사람들이 여전히 너무 많다.

이 세 부류는 방향이 다르다.

하나는 변화를 부정하고, 하나는 변화의 의미를 생각하지 않고, 하나는 변화 자체를 거부한다.

하지만 본질은 같다.

자기가 서 있는 자리를 직시하지 않는다는 것.

환멸이라고까지 말하면 과할지 모르겠다.

하지만 "코딩을 좋아한다"고 말하면서 정작 코딩이라는 행위의 의미가 바뀌고 있다는 사실에는 눈을 감는 사람들에 대한 답답함을 느낀다.

나도 코딩이 좋았다.

하지만 돌이켜보면 코딩 자체가 좋았던 건 아닌 것 같다.

남들이 못하는 걸 내가 할 수 있다는 우월감이 좋았던 것이다.

코드를 작성한다는 행위가 주는 "나는 특별하다"는 감각.

그게 코딩에 대한 애정의 실체였다면 AI가 누구에게나 그 능력을 나눠주는 순간, 그 "애정"은 증발할 것이다.

진짜 코딩을 사랑한 게 아니라, 코딩이 만들어준 위치를 사랑한 것이었으니까.

6. 아무도 괜찮지 않다.

어쩌면 AI에 또 한계가 찾아올 수도 있다.

지금의 대규모 언어 모델이 천장에 부딪히고, "생각보다 별거 아니었네"라는 반응과 함께 다시 AI 겨울이 올 수도 있다.

그러면 개발자는 다시 잠깐동안 숨을 돌릴 수 있을 지도 모르겠다.

어쩌면 AI는 직업을 없애는 게 아니라, 엑셀이 그랬던 것처럼 기대치를 올리는 도구가 될 수도 있다.

엑셀이 등장했을 때 사무직 노동자의 업무량은 줄지 않았다.

"이 정도는 당연히 처리해야지"라는 기준선만 올라갔을 뿐이다.

AI도 그렇게 될 수 있다.

개발자가 사라지는 게 아니라, "혼자서 열 명 몫을 해야 하는 개발자"가 표준이 되는 미래가 열릴 수도 있을 것이다.

아니지, 그 때는 10명의 몫이 1인분이 되는 건가.

그게 어쩌면 "직업이 사라지는 것"보다 더 잔인할 수도 있다.

직업은 남아 있는데, 사람의 가치가 희석되는 것이니까.

열 명이 하던 일을 한 명이 하게 되면, 아홉 명은 어디로 가는가?

남은 한 명은 열 배로 행복해지는가? 아니면 열 배로 지치는가?

확실한 건 하나뿐이다.

개발자는 원래 직업을 없애는 직군이었고, 그 칼날이 마침내 자기 자신에게 도달했다는 것.

이것이 완전한 소멸인지, 변형인지, 아니면 그저 과도기의 착각인지는 아직 모른다.

다만 이것만큼은 말할 수 있다.

"괜찮을 거야"라는 말은, 적어도 지금은, 아무에게도 도움이 되지 않는다.

이 글은 저와 AI의 대화에서 시작되었고, AI가 모든 내용을 구조화하고 집필했음을 밝힙니다.

여기서부턴 직접 쓴 글.

전 딱히 AI가 개발자의 자리를 대체하는 것에 부정적인 입장이 아닌 사람입니다.

원래 제가 만들려던 세상을 진짜로 만들어버린 인간들이 존재했을 뿐이라, 선수를 빼앗겼다? 정도의 느낌.

최근 다양한 직군의 사람들과 대화하고, 같은 개발자끼리도 많은 대화를 나누다보니 생각이 복잡해졌습니다.

그래서 LLM한테 구조화해보라고 시켰더니 굉장히 염세주의적인 글이 탄생했네요.

제 평소 페르소나를 반영했다는데, 대체 저의 어떤 면을 메모리에 적재해둔 건지 모르겠습니다.

그리고 본문에서는 현실에 안주하거나, 트렌드를 좇는 이들에게 답답함을 느낀다고 적혀있지만, 저는 저런 표현을 쓴 적이 없는데 좀 억울하네요. (번역가란 표현도 제가 먼저 쓰지 않았는데;;)

최근 블로그 포스팅을 "딸깍"해보고 싶어져서 이런저런 시도를 해보는 중입니다.

기술적인 내용은 아직 업로드하기 처참한 수준이라 어렵고, 이번 글도 솔직히 별로 마음에 안 드는데 최근 포스팅을 거의 못해서 그냥 올렸습니다.

디프만 18기 서버 파트 합격 후기

나죽못고나강뿐 — Sat, 7 Mar 2026 16:41:03 +0900

Introduction

왜 붙은 거지.

서류부터 면접까지 아무것도 제대로 된 준비를 하지 못했다.

못한 건지, 안 한 건지를 고민을 해봤는데 못했다고 보는 것이 맞다고 판단했다.

디프만의 선발 과정을 얕본 건 아니었다.

이건 어디까지나 양자 택일 문제였다.

어떤 활동을 하던, 나에게 최우선 순위는 커리어여야만 한다.

문제는 최근 상당히 까다로운 태스크를 할당받아서 업무를 하고 있었기에, 이 업무를 끝내지도 못한 상태에서 외부 활동을 하겠다는 나의 선택에 많은 고민을 했었다.

단순히 의욕만 앞선 행위라면, 회사나 동아리 양쪽에 모두 피해를 주는 이기적인 행동이라 생각했었다.

그래서 무엇에 더 집중을 할 지 선택의 기로에 놓였었다.

동아리 활동 전에 업무에 모든 시간을 투자한다면 서류나 면접 준비에 소홀해질 것이고, 선발 과정에 시간을 쏟으면 그만큼 업무가 늘어져서 합격을 해도 문제가 될 것이었다.

하지만 이건 답이 정해진 문제였다.

당연히 업무를 최우선으로 해야한다.

그 외에도 7개나 벌려놓은 스터디들을 하나씩 정리하고, 활동 전에 최대한 많은 이들에게 포폴 첨삭을 해주고, 동아리 활동에 지장을 주지 않도록 공부도 미리 다 끝내놔야만 했다.

그렇게 되면 서류 작성은 하루, 면접 준비는 기껏해야 30분밖에 할애하지 못한다는 계산이 섰다.

고작 이 정도 준비밖에 안 했으면서 붙을 거라는 뻔뻔한 기대는 하지 않았고, 당연히 도중에 떨어질 거라 예상했는데 어찌저찌 붙었다. (물론 마인드 만큼은 언제나 월클이었다. '날 떨어트리면 너희 손해임.')

이번 기수 개발자 최고 경쟁률이 8.1:1 정도로 이전 기수들보다 확연히 저조해졌던데, 그게 아니었다면 반드시 떨어졌을 것이라 본다.

Why Depromeet?

굳이 디프만이어야 하는 이유는 없었지만, 디프만이 아닐 이유도 없었다.

본래 외부 커뮤니티를 찾은 이유는 다음과 같았다.

커뮤니티
- 하나의 집단에만 소속되면 필연적으로 우물 안 개구리가 되어 간다. 난 그 기분이 끔찍하게도 싫었다. (집단 구성원들의 실력과는 무관한 이야기)
- 그렇다고 회사 타이틀이 더 이상 내게 신뢰를 주지 못한다고 느꼈기에, 굳이 관련 종사자 커뮤니티를 고집하지는 않았다. 중요한 건 당신이 회사원이냐, 개발자냐가 중요한 영역이니까. 좋은 회사를 다닌다고 그 사람이 좋은 개발자라는 것을 증명하지는 않는다.
- 회사나 학교를 다니면서 외부 활동을 병행한다는 건, 목표가 무엇이든(설령 취업, 이직이 목표일지언정) 발전을 위한 욕심이 있다는 것의 반증이라 생각했다. 실력은 논외 사항.
프로덕트
- 학생 때 남은 유일한 미련은 모든 프로젝트가 결국 실패로 끝났다는 것.
- 자사 서비스에 아무리 애정을 가진다고 해도, 결국 이건 내 것이 될 수 없다는 현실.
- 그렇다면 '나는 여전히 로컬 호스트조차 벗어나지 못한 반쪽짜리 개발자가 아닌가?'라는 고민.
- AI 덕에 혼자서 제품을 만들 수 있는 시대가 오긴 했으나, 나의 고질적인 문제는 혼자 프로젝트를 하면 자꾸 딴 길로 샌다는 점이 치명적이었다. (지도에 위치 찍다가 삼각측량 공식을 음미하고 있는 게 말이 되나) 나의 연구욕이 뻗어나가는 걸 방지해줄 가이드레일이 필요했다.

원래는 특수 대학원에서 석사 학위를 준비하려고 했으나, 돈이 어지간히도 많이 깨진다는 불편한 사실...과 더불어 아직은 연구보다는 프로덕트에 좀 더 관심이 많다는 변변찮은 이유로 외부 동아리를 택했다.

조건은 단순했다.

실무 경험이 있는 현직자가 적당히 포함(프로젝트가 과하게 학술적으로 빠지는 것을 방지 목적)되었으면 좋겠고, 어느정도 체계적인 선발 절차가 있길 바랐다.

이 조건으로 탐색했을 때 가장 처음에 발견한 게 디프만이었다는 게 전부였다.

하지 않을 이유가 없으면 한다.

다른 외부 동아리도 많긴 하던데, 굳이 더 알아볼 필요는 없다고 판단했다.

디프만 공식 깃헙 페이지에서 11기부터 18기까지 한 명도 빠짐없이 전직군의 프로필을 훑어보고 만족했기에, 굳이 여기서 선택지를 더 늘려 집중력을 흐리고 싶지 않았다.

Resume

다른 블로그들 훑어 보니까 서류 문항 정도는 공개해도 되는 거 같아서 맘 편하게 썼다.

디프만에 지원하게 된 동기와 이번 기수 활동을 통해 이루고 싶은 구체적인 목표를 작성해 주세요. 그 목표가 본인과 디프만 팀의 성장에 어떻게 기여할 수 있을지 서술해 주세요. (500자)
디프만은 약 4개월간 몰입도 높은 팀 프로젝트를 진행합니다. 현재 본업(직장/학업)을 포함하여 병행 중이거나 계획 중인 활동(타 스터디, 사이드 프로젝트, 자격증 등)을 모두 나열하고, 디프만 활동에 우선순위를 두고 참여할 수 있는 구체적인 시간 관리 계획을 작성해 주세요. (500자)
팀 프로젝트나 협업 진행 중 예상치 못한 어려움(팀원 이탈, 일정 지연, 기술적 난관, 의견 대립 등)에 직면했지만, 끝까지 책임을 다해 완주했던 경험을 작성해 주세요. 당시 상황을 어떻게 판단했으며, 문제를 해결하기 위해 어떤 노력을 했는지 구체적으로 서술해 주세요. (500자)
주어진 역할의 범위를 넘어, 팀의 문제를 내 일처럼 여기고 주도적으로 해결했거나 품질을 높였던 경험이 있다면 작성해 주세요. 왜 그런 행동을 했으며, 그 결과 팀이나 프로젝트에 어떤 변화가 있었는지 작성해 주세요. (700자)
완벽한 계획보다는 빠른 실행과 시도(실험)를 통해 더 나은 결과를 만들었던 경험을 작성해 주세요. 초기 계획이 틀어졌거나 피드백을 받았을 때 어떻게 대처했고, 개선 과정에서 무엇을 배웠는지 서술해 주세요. (700자)
서버 개발자로서 협업 과정에서 중요하게 여기는 역량이나 원칙이 있다면 무엇인가요? 그렇게 생각하게 된 구체적인 상황이나 사례가 있으면 함께 설명해주세요. (최대 700자)
프로젝트를 하면서 가장 기억에 남는 기술적 어려움 혹은 시스템 장애 경험 중 하나를 선택해서, 그 상황을 어떻게 진단하고 해결했는지 설명해주세요. 원인 파악 과정과 문제 해결 절차에서 본인이 한 역할을 중심으로 작성해 주세요.(최대 1,000자)
자소서 or 포트폴리오

(요샌 동아리나 해커톤 질문 문항이 회사 지원 서류의 질문 문항보다 많은 것 같다. 정신이 살짝 아득해질 뻔.)

내가 면접관의 입장이라면 '나'와 같은 지원자 유형의 장점과 리스크는 무엇일까.

실력이나 열정 측면에 있어서는 회사 타이틀과 블로그라는 증거가 존재하기에 큰 문제가 되지 않을 것이라 생각했다.

(학생이었다면 실력을 입증하기 위한 고민도 많이 필요했었을 텐데, 지금은 사용할 수 있는 전략 폭이 넓어졌다는 것을 새삼 느꼈다.)

다만 열정이 너무 과하다는 점과 경력이나 고집을 앞세워 팀을 찍어누를 것이 우려스러울 것이라 분석했다.

나도 일정 관리도 못 하면서 열정만으로 일을 벌리는 무능한 사람, 더 이상 인풋은 하지 않고 아웃풋만 하는 사람을 싫어하긴 하나, 이런 요소들은 당췌 증명하기가 까다롭다.

그래서 1~6번 문항 전체를 문제 해결 역량보다 커뮤니케이션 역량과 일정 관리 능력, 책임감과 유연성에 초점을 맞춰 작성했고, 기술적인 부분은 7번 문항과 추가로 제출하는 포트폴리오에 올인했다.

이 과정에서 어떠한 꾸밈이나 과장도 섞지 않았다.

그들이 판단하기에 내가 디프만과 맞지 않은 성향이라면 마땅히 걸러내주기를 바랐고, 그것이 서로에게 이득이 되는 방향이라고 믿었다.

그리고 자기 PR을 주장이나 감정 호소로 하는 것을 좋지 않게 보기에, 최대한 실증적인 증거와 구체적 계획을 제시하려고 노력은 했다.

문제는 오래된 포트폴리오까지 하루만에 전부 갱신하려니 시간이 너무 빠듯해서 첨삭은 못하고 그냥 제출했었다.

면접 전에 다시 한 번씩 훑어봤는데, 이상한 내용도 적어놓은 걸 뒤늦게 발견해서 '아, 망했네'라고 생각했을 정도였으니 말이 더 필요없지 않을까.

아직도 서류 왜 붙었는지 모르겠다.

Interview

진짜 하나도 준비하지 않고 당당하게 들어갔다.

처음에 적은 것처럼 모든 걸 마무리해두지 않으면 붙어도 의미가 없었기에, 모든 일을 쳐내느라 가장 바빴던 한 주였다.

심지어 면접도 가장 첫 날 오후 2시에 잡혔었는데, 오후 1시까지 영어 회화 스터디하다 오는 전사의 심장.

물론 이렇게까지 배짱을 부리게 된 나름의 3가지 이유가 있긴 했다.

제출한 자소서랑 블로그 기반으로 질문이 많이 나온다는 정보를 이미 확인했었다.
- 자소서에 적은 내용들은 취준할 때 질릴만큼 봤던 내용들이기도 하고, 평소에도 워낙 많은 회고를 하니까 굳이 특별하게 더 준비할 게 없었다.
- 만약 블로그 기반으로 질문을 했는데 답변을 못한다? 있어서는 안 될 일이다. 그런 불상사가 발생하면 합불이 중요한 사안이 아니다. 스스로의 해이해진 기강을 바로 세워야 하는 문제다.
커피챗 분위기라고 많은 후기에 적혀있기도 하고, 설마 경력으로 지원했는데 CS를 물어볼까 싶어서 패스했다.
- 설령 CS 질문이 나왔어도 답을 못했다면 문제다.
클로드한테 디프만 정보 조사해서 면접관 페르소나 확립시킨 후에, 내 자소서와 블로그 기반으로 예상 질문을 리스트 업을 시켜봤었다. 100개 질문 정도를 빠르게 스캔해봤는데, 딱히 답변에 걸리는 부분이 없어서 문제 없다고 판단했다.

이런 마인드로 면접 당일 구글밋에 접속했고, 나랑 같은 현직자와 함께 다대다 면접을 봤다.

(이전 후기들 보면 다른 직군들이랑 면접을 보기도 하고, 재직자랑 학생도 섞여있는 경우가 있었다고 하는데, 적어도 내가 할 때는 잘 분리를 해서 면접이 진행된 것 같아 좋았다.)

그런데 같이 면접보시는 분이 준비를 많이 해오신 것 같아서 살짝 당황했다.

'이 정도로 준비를 해왔어야 했나?', '내가 너무 안일했나?' 뭐 이런 잡생각이 들다가, 주사위는 이미 던져졌는데 무슨 의미가 있나 싶어서 평정심을 잃지는 않았다.

평정심을 잃지는 않았는데 답변은 망했다. ㅋㅋ

면접 직전 이번 기수 운영진 구성을 확인했을 때 가장 취약한 쪽은 iOS 쪽이었고, 그렇다면 분명 iOS 유관 경험이 있는 내게 구미가 당길 수밖에 없다고 생각했다.

그리고 예상한 그대로의 질문이 들어오긴 했으나, 답변 직전에 생각의 변화가 생기는 바람에 횡설수설했다.

서버 파트 관련 질문도 몇 개 받긴 했었는데, 지금 생각해봐도 매끄러운 답변은 아니었다.

'이번엔 진짜 망했네'라는 생각이 지배적이었다.

그래서 면접 다음 주 목요일 점심 시간 쯤에 최종 결과 메일을 받았을 때, 별 기대도 안 하고 열었는데 합격했다고 적혀있길래 잘못 읽은 줄 알았다.

이건 진짜 어떻게 붙은 거지.

Conclusion

뭔가 dramatic한 변화가 있을 거라고는 기대를 하지 않는다.

회사나 동아리나 부트캠프 모두 결국 잘 하던 사람이 잘하고, 열심히 하던 사람이 열심히 한다는 걸 이제는 안다.

특이한 케이스가 드물게 있긴 하나, 매우 드물기 때문에 특이하다고 취급하는 것이기도 하고.

그리고 활동을 열심히 하면 할 수록 마찰도 분명히 발생할 테고, 또다시 내 인격적인 미성숙함을 되돌아보게 될 수도 있을 것이며, 실패 경험을 한 번 더 누적하는 결과가 될 수도 있을 것이다.

그래도 도전한 만큼 후회없는 활동을 할 것이다.

뭐가 됐건 현재에 안주하는 것보다 최악은 없지 않을까.

[요즘 개발자를 위한 시스템 설계 수업] 1부 1~3장

나죽못고나강뿐 — Sun, 22 Feb 2026 18:09:18 +0900

설 연휴 기간 동안 하루도 쉰 적이 없는데 불구하고, 너무 바빠서 블로그 포스팅을 할 겨를이 없었다.

시작하기 앞서, 이건 별로 추천하고 싶은 책은 아니다.

번역이 이상한 부분도 있고, 내용 자체가 틀린 점도 있으며, 설명이 상당히 불친절하다.

챕터 순서 배치도 뭔가 이상하게 짜여 있어서 이해를 방해한다는 느낌까지 받았다.

대규모 시스템 설계 책은 구체적인 usecase를 던져주고 필요한 때에 적절히 지식을 던져주는데, 이 책은 "일단 먹어. 그리고 그걸 먹은 이유는 나중에 설명해줄게"라는 식으로 전개가 되어 혼란을 준다.

그 와중에 내용이 워낙 어려우니 쉽게 설명하려고 얕은 부분만 적어놨는데, 필요한 내용까지도 덜어내는 덕에 책만으로는 절대 이해할 수 없는 상황을 만들어 놨다.

(Practical Byzantine Fault Tolerance에 대한 설명은 몽땅 덜어내놓고 직후에 뜬금없이 FLP impossibility 내용이 나오던데, 논문을 읽어보니 전자의 기본 전제가 후자와 연관된 것이었다. 그런데 책에서 이런 관계성을 건너 뛰는 경우가 너무 많고, 하더라도 논문을 제대로 읽은 게 맞나 싶을 정도로 오류도 많아서 당혹스러웠다.)

이미 어느 정도 흐름을 이해한 사람들이야 적당히 필요한 부분만 섭취하고 넘기겠지만, 첫 시스템 설계 수업을 이 책으로 공부한다고 하면 말리고 싶다.

난 왜 했냐고? 회사에서 이걸로 스터디를 하니까.

하여간 이런 이유들로 인해 책과 다르거나, 없는 이야기도 많이 다룰 것.

1. 시스템 설계의 기본

시스템 설계의 정의

넓은 의미에서 시스템 설계를 정의하는 wikipedia와 달리, 책에서는 software 관점에서 선을 긋고 운영 및 기능 관점으로 실용적으로 정의를 해두었다.

그래서 데이터 관리, 트랜잭션 처리, 최종 사용자를 위한 서비스 제공 등이 소프트웨어 시스템에 속한다라고 명시하고 있다.

그래서 "시스템을 설계한다"란, 요구 사항 달성을 위해 시스템 아키텍처, 구성 요소, 인터페이스와 같은 여러 특성을 정의해나가는 과정이라고 설명하는 것.

시스템 구성은 가장 대표적으로 처리 주체로 나눌 수 있다.

흔히 아는 서버 한 대로 돌아가는 중앙 집중형 시스템과 물리적으로 분산되어 있는 서버 클러스터로 운영하는 분산 시스템이다.

Centralized System
- 모든 처리와 데이터가 단일 중앙 노드에 집중
Distributed System
- 지리적으로 다른 위치와 네트워크에 걸쳐서 여러 노드가 통신하며 협력
  - 과거에는 단순히 개별 컴퓨터가 물리적으로 분산된 컴퓨터 네트워크만을 의미했었다.
  - 최근에는 개념이 확장되어 "협력"이라는 단어가 중요해졌다. wiki 정의에서도 "The components of a distributed system communicate and coordinate their actions by passing messages to one another in order to achieve a common goal."이라고 정의한다.
  - 다만 분산 시스템에 대한 단일 정의가 없어서, 일반적으로 두 가지 공통 속성을 포함해야 한다.
    - 여러 개의 자율적인 컴퓨팅 개체가 존재하고, 각각은 자체 로컬 메모리를 갖는다.
    - 개체들은 메시지 전달을 통해 서로 통신한다.
- 다양한 통신 프로토콜로 소통
  - e.g., RPC(Remote Procedure Call), message passing, publish/subscribe model 등

중앙 집중형 시스템을 모놀리식, 분산 시스템의 유형 중 하나를 MSA로 불러도 되는지에 대해서는 의문이 남는다.

개인적인 견해로는 중앙 집중 vs. 분산형은 단순히 "어디서 실행하냐"를 논하고, "코드를 어떻게 패키징 하느냐"를 논하는 게 모놀리식 vs. MSA의 가장 큰 차이라고 보는데, 그렇다고 MSA가 단순 배포 관점만 고려하지도 않기 때문에 엄밀하게 구분이 어렵다.

모놀리식 구조의 코드 베이스라도 지리적으로 분리된 여러 인프라에 분산하는 게 불가능한 것도 아니다.

하지만 우리가 단순히 infra topology 나누었다고 분산 시스템이라고 부르지도 않는다.

Decentralized Computing이라 보는 게 맞을까 싶었는데, 단순 monolithic replica는 wiki 정의(= Decentralized computing is the allocation of resources, both hardware and software, to each individual workstation, or office location. (...) A collection of decentralized computers systems are components of a larger computer network, held together by local stations of equal importance and capability.)와 그리 딱 맞아 떨어지지도 않는다. (자율적이고 대등한 노드로서 독립적 의사 결정을 하기보다는, 중앙 인프라에 종속된 동일한 복제본일 뿐인 것 같다고 여겼기 때문)

애초에 단일한 정의가 없는 분산 시스템이나 MSA 같은 용어의 관계성을 억지로 이어 붙이려고 하다보니 이런 문제가 발생하는 듯.

통일 좀 해주면 안 될까??

하여간 시스템 설계는 일반적으로 위 순서를 따른다고 한다.

물론 이론적인 내용이고, 실제로 일해보면 이상한 순서로 굴러가는 과정도 많긴 하다.

특히 대부분 회사는 사용할 수 있는 infra가 고정되어 있다보니, infra를 중심으로 설계를 하게 되는 경우도 많음.

시스템 설계의 다양한 유형

요구사항을 분석했으면, 요구사항에 맞는 시스템을 설계해야 한다.

어차피 이건 다 아는 내용이니까 정리할 가치도 못 느끼겠다.

오히려 요구사항에서 무엇을 봐야하는지를 책에서 다뤄줬으면 좋았을 거 같은데.

우리가 소프트웨어를 만드는 이유는 한정된 자원으로 문제를 해결하여 결과를 창출하기 위함이다.

나를 포함한 많은 엔지니어가 "문제를 해결"하는 것에만 너무 많은 관심을 기울이는 나머지, "한정된 자원"과 "결과 창출"의 중요성을 쉽게 망각한다고 느낀다.

그래서 결과를 해결하지 못하는 솔루션을 내오거나, 온갖 상황을 고려하다가 필요 이상의 스펙을 설계하는 경우가 많다.

세상에 똑똑한 사람들 많은 건 여실히 느끼는데, 볼 때마다 '그래서...왜 이렇게까지...?'라는 의문을 가진 적이 많다.

요구사항 분석이라는 단계를 누락했기 때문이 아닐까.

설명 안 함. 패스.

업계에서 시스템 설계가 갖는 중요성

책에서 "시스템 설계를 하면 명확한 이해와 협업의 시너지 효과, 설계 검토 및 피드백 가능성, 높은 확장성, 성능, 유지 보수성, 그리고 비용 효율성이 있기 때문에 중요하다"고 한다.

논리적으로 틀린 설명이다.

시스템 설계를 할 때 높은 확장성과 성능, 유지 보수성, 비용 효율성이 있을 수는 있겠으나, 시스템 설계 자체가 이를 보장하는 것은 아니다. (설계는 좋은 시스템의 필요 조건일 수는 있지만, 충분 조건이 아니다.)

즉, 시스템 설계의 지향점이자 고려 사항이자 기회 측면에서 설명한 후에 설계 산출물로 커뮤니케이션과 리뷰의 기반이 된다고 설명을 하는게 더 적절했을 것이다.

2. 분산 시스템의 속성

책 읽을 때 가장 어이가 없었던 챕터.

핵심 단어들을 열거하는 식으로 진행을 하는데, 일부 내용은 설명을 포기한 수준이다.

일관성, 가용성, 파티션 허용성은 CAP 이론 설명 빌드업이고, 나머지는 CAP 이론의 한계를 확장한 이론들을 설명하기 위함이거나, 분산 시스템을 논할 때 고민하는 다른 factor들이라고 보면 된다.

호텔 객실 예약 시스템으로 살펴보는 분산 시스템 예시

DB를 분산 클러스터링으로 구성했다고 하자.

이런 상황에서 client로부터 "예약(=쓰기 작업)"과 "빈 방 조회(=읽기 작업)"를 어떻게 처리할 수 있을까.

서버가 매번 모든 DB에 쓰기를 요청할 수도 있고, master에만 쓰기 요청을 하면 비동기로 slave에 동기화를 할 수도 있을 것이며, 서버가 모든 DB에 요청을 보내지만 threshold개(threshold < N)만큼 성공 응답이 돌아오면 성공으로 간주할 수도 있을 것이다.

읽기 작업도 마찬가지다.

문제는 모든 DB에 쓰기 요청을 하고 성공 응답을 받겠다고 한다면 Consistency는 높아지지만 Latency도 함께 높아져서 사용자가 불편함을 겪을 수도 있고, 일부만 쓰기 요청을 하면 Consistency가 떨어져서 사용자가 stale data를 보게 될 수도 있다.

Latency도 낮추고 Consistency도 높일 수 있으면 정말 좋겠지만, 이후 배울 CAP thorem에 의하면 이 둘을 동시에 충족하는 것은 불가능하다.

그러니, 우리는 policy 선택을 위해 많은 것들을 고려해야 한다.

이번 챕터는 이를 고려하기 전에 다양한 용어들을 정의한다.

Consistency

시간 축에서 어느 한 시점을 고정했을 때, 모든 사용자는 그 시점에서 같은 데이터를 바라볼 수 있는가?

DB Transaction ACID 속성에서 consistency가 단순히 "하나의 유효한 상태에서 다른 유효한 상태로 전이시켜야 한다"는 규칙이라면, distributed system에서 consistency는 "모든 노드가 동일한 시점에 동일한 데이터를 보는 것"을 의미하므로 완전히 다른 개념이다.

CAP에서 Consistency는 Linearizability에 대한 이야기다. (Linearizability: A Correctness Condition for Concurrent Object(1990))

쉽게 말해 "복제본이 여러 개 있어도, 마치 하나만 있는 것처럼 동작하느냐", 즉 동시성 환경에서 "올바르다"는 것이 무엇인지를 정의하는 기준이다.

가장 잘 알려진 Quorum Consensus Protocol의 기준에 따르면, 합의체가 의사를 진행하고 의결하는데 필요한 최소 구성원 출석수를 쓰기/읽기 각각 분리하여 계산한 후에 R+ W 관계에 따라 일관성 모델을 정의한다.

(책에서 R + W ≤ N을 최종 일관성 모델이라고 지칭하던데 명백히 틀린 내용이다. 약한 일관성이라고 부르는 것이 맞고, 여기에 추가적인 메커니즘이 도입되어야 최종 일관성 모델이 된다.)

책에서 2PC, SAGA 패턴은 다루지 않는다.

그냥 예전에 (전혀 관련도 없는) 트랜잭셔널 메시징 전략 구상할 때 알아본 게 생각나서 적었다.

일관성 모델에 대한 내용도 대규모 시스템 설계 공부할 때 정리해둔 게 있으므로 패스.

Availability

어려운 개념은 아닌데, 기존에 알고 있던 Availability의 정의와는 차이가 있다.

보통 Application의 Availability는 SLA(Service Level Aggrement)같은 방법으로 측정을 한다.

예를 들어, 정상적인 요청의 99.9%가 1s 이내에 성공적인 응답을 반환해야 한다는 명세가 있다.

그런데 CAP에서 A를 측정하는 metric에는 latency가 고려되지 않는다.

즉, 응답에 10s가 소요되어도 아무튼 응답만 하면 Availability를 충족한다고 본다.

만약 서로 다른 데이터 센터 사이에 network partition이 발생해서 동기화가 되지 않음에도 availability를 보장하기 위해 stale data 응답을 반환하는 것을 허용한다면, 이는 non-linearizable하므로 consistency의 정의에 부합하는 행위가 된다.

Partition Tolerance

CAP의 "2 of 3" 선택을 강요하게 만드는 본질적인 문제.

우리는 매우 좁은 영역이 아닌 이상, netwrok partition을 피할 방법이 없다.

Latency

다 아는 개념이므로 패스.

Durability & Fault Tolerance & Reliability

책에서 제일 열받는 부분.

내구성, 장애 허용성, 신뢰성의 구분을 명확히 해주지 않는다.

내구성은 "시스템이 죽든 말든, 저장된 데이터만 날아가지 않으면 돼"라고 주장하며 데이터 관점만 고려하고,

장애 허용성은 "노드 하나 죽어도 서비스가 중단만 안 하면 돼"라고 하며 장애 발생 순간에만 중점을 둔다.

반면, 신뢰성은 시간 축 위의 종합적인 품질이다.

따라서 내구성이 떨어지면 신뢰성도 떨어지고, 장애 허용성이 떨어져도 신뢰성은 떨어진다.

심지어 내구성과 장애 허용성이 높아도 신뢰성은 떨어질 수 있다.

예를 들어, 카카오 데이터 센터 화재 당시에 IDC를 이중화 해둔 평행 세계가 존재한다고 가정해보자.

덕분에 내구성과 장애 허용성 모두를 충족했을지라도, 트래픽이 한 곳으로 몰리면서 지연 시간이 높아졌다면 신뢰성은 여전히 떨어졌을 수 있다.

Scalability

이것도 이미 대규모 시스템 설계 공부할 때 다룸.

3. 분산 시스템의 이론과 데이터 구조

CAP theorem

개인적으로 저 벤다이어그램도 구시대 산물이니 지워버려야 한다고 생각한다.

대중적으로 가장 잘 알려진 CAP 속성은 "2 of 3".

"3개 중 2개만 선택할 수 있다"는 표현이 오해를 불러일으킬 여지가 많다는 건 Brewer가 직접 인정했고, CAP Twelve Years Later: How the “Rules” Have Changed(2012)에서 직접 정정했다.

(여기는 책에서 정의한 게 오히려 더 나은 측면이 있다.)

CAP 이론을 이해하려면, 왜 Distributed System에서 많고 많은 요소 중 CAP를 최우선으로 고려하는지 알 필요가 있다.

아래 그림에서 X 표시를 node에 해놨는데, edge에 X 표시를 하는 게 더 적절했다. partition이 node 장애를 의미하지는 않기 때문. 옛날에 그렸던 걸 그대로 가져와버려서 수정하기도 어려움.

본래 Distributed System이 등장한 초기 목적은 Availability가 가장 큰 비중을 차지했을 것이라 생각한다.

서버를 제 아무리 고성능 HW로 scale-up을 해도 IDC가 테러라도 당하면 무용지물이었을테니.

그렇게 막상 분리하려고 보니 Consistency 문제가 생겼다.

사실 이상적인 환경에서는 Availability와 Consistency를 모두 충족시킬 수 있다.

CA system을 선택하더라도 애초에 network partition이 발생하지 않으니 P는 고려할 이유가 없어진다.

node1에 기록된 데이터는 언제나 n2, n3에 자동으로 복제될 테니까. (CAP에선 latency를 고려하지 않음을 기억하자.)

그런데 Network Partition 문제를 피할 수가 없다는 현실적인 문제가 이를 어렵게 만든다.

예를 들어, node1에 write를 하고 node3에서 read를 하고 있었는데 network partition이 발생했다고 치자.

여전히 node1에 쓰고, node3에서 읽는 것은 가능하나 stale data를 읽게 될 가능성이 농후하다.

그러니 CAP 이론은 우리는 둘 중 하나를 선택해야 한다고 이야기를 한다.

node3가 가진 데이터로만 응답한다 = consistency 포기
지금은 응답할 수 없다고 거부한다 = avilability 포기

그런데 node1과 node3 사이에 network partition이 발생했을 뿐, 여전히 application은 모든 node와 통신이 가능하다면 어떨까?

application이 node3만 읽지 않고, 다른 nodes도 read를 해서 consensus를 한다면?

그렇다면 여전히 system은 linearizable하다고 볼 수 있어야 하지 않을까?

파티션의 정의
- 노드는 살아있지만, 특정 노드 사이의 네트워크가 끊겨 메시지가 지연/손실되는 상황
- node1-node3 간 링크가 끊어졌다면 서로의 상태를 동기화할 수 없다.
애플리케이션이 모든 노드와 통신 가능하다는 조건
- node1과 node3 링크는 끊겨 있음에도 양쪽이 독립적으로 write/read를 할 수 있는 구조라면, 선형성을 보장하기 위해 어느 한쪽(또는 일부 연산)은 차단해야만 한다.
node3만 읽지 않고 다른 node도 읽어서 consensus를 수행한다면?
- partition이 발생한 쪽에서 quorum을 이루지 못하면 write를 거부하고, read도 linearizability를 보장하도록 만들고, 언제나 application이 그런 경로로만 읽고 쓰게 만든다면 맞는 말이다. 이렇게 하면 partition이 발생해도 linearizability를 보장할 수 있다.
- 그러나 이 경우는 CAP의 정의(= 모든 살아있는 노드가 정상적인 요청을 처리해야 한다)와 달리 partition의 소수 쪽 요청을 실패시키거나 차단하므로, CAP-availability를 포기했다고 봐야 한다.

이게 당췌 무슨 소린지 이해가 안 간다면 정상이다.

이런 너무 엄격한 CAP 정의 때문에 실무적 판단과 동떨어져 있다고 비판하는 경우도 많다.

하여간 CAP는 "2 of 3"보다는 가중치의 문제로 봐야 한다.

가용성은 0~100%의 연속값이고, 일관성도 여러 수준이 있으며, 파티션조차 시스템 내에 파티션이 존재하는지에 대한 의견 불일치까지 고려해야 한다.

PACELC 정리

PACELC가 뭔가 싶을 수 있는데, 위에 나오는 핵심 용어 앞글자만 모두 따서 붙이는 것.

CAP 이론의 한계는 partition이 발생하지 않았을 때(ELSE)를 고려하지 않는다.

그래서 PACELC는 정상 상태에서 latency와 consistency를 고려하도록 알고리즘을 확장시켰다.

참고로 여기서 책이 급발진을 한다.

왜 이랬을까 고민을 해봤는데, latency와 consistency를 동시에 만족할 수 없는 이유를 우리의 뇌로 보여주고 싶었던 것 같다.

consistency를 포기할 수 없다면 공부 시간을 늘려서 latency를 희생하고, latency가 너무 길어져서 부담이 되면 consistency를 포기하라는 훌륭한 교훈을 몸소 체감하게 해준다.

이해하지 말라.

스탠포드 대학 학생들도 이해하는데 1년 가까이 걸렸다는 괴담이 존재한다. 농담이 아니라, 그 다음에 나올 Raft 합의 알고리즘이 그런 이유로 탄생했다.

The Part-Time Parliament(1998)

참고로 책에 나온 설명으로 절대 이해할 수가 없으므로, 차라리 wiki 문서 읽는 게 훨씬 낫다.

In Search of an Understandable Consensus Algorithm(2014)

제목부터 "Understandable" ㅋㅋ.

내가 한 가지 간과한 것이 있었다면, 어쨌든 이거 쓴 인간도 스탠포트 대학 다니는 사람이란 것이었다.

이해가 안 간다는 얘기다.

Paxos는 단일 값에 대한 합의를 기본으로 놓고, 이를 여러 개 조합해서 로그를 만드는데, 이 기본 단위인 single-decree Paxos 자체가 두 단계(prepare/accept)로 나뉘어져 있으면서, 각 단계가 독립적으로는 직관적 설명이 어려웠다고 한다. (e.g., "왜 prepare 단계에서 promise를 받아야 하는가?"에 대한 답은 accept 단계와 함께 봐야만 이해가 되는 구조)

그 와중에 실제 시스템 만들려면 multi-Paxos가 필요한데, Lamport 원 논문에서 multi-Paxos는 스케치 수준으로 끝나는 덕에 춘추 전국 시대를 열어젖혀버렸다는 후문이 있다.

그래서 Raft는 "강한 리더가 있다"는 전제를 먼저 깔고, 리더는 어떻게 선출하고, 리더가 어떻게 로그를 복제하고, 이 과정에서 안전성은 어떻게 보장되는가로 문제를 쪼개버렸다.

이론적 일반성은 포기했지만, 몇 가지 전제를 더 확고히 깔아버리면서 경우의 수를 줄였다고 봐야한달까.

물론 나도 심심해서 논문 조금 훑어보다가 머리 아파서 닫아버렸다.

AI가 정리해줬는데도 이해가 안 감.

The Byzantine Generals Problem

The Byzantine Generals Problem(1982)

재밌는 시나리오. 옛날 논문들은 낭만이 있다.

Paxos, Raft 때와 달리 node 자체를 신뢰할 수 없는 경우까지 고려한다.

다만, 위 논문의 방법은 속도가 너무 느려서 실제로 적용하기엔 무리가 있다.

Practical Byzantine Fault Tolerance(1999)

그래서 나온 게 실용적인 비잔티움 장애 허용 알고리즘.

이것도 설명하려면 포스트 하나를 통채로 할애해야 하므로 패스.

솔직히 내가 이해한 것 같지도 않음.

아, 참고로 바로 밑에 나올 FLP 불가능성 정리가 background로 쓰였음을 확인하자.

난 이 내용이 갑자기 왜 나오나 했다.

FLP Impossible

Impossibility of distributed consensus with one faulty process(1985)

쉽게 말해, "모든 node가 언제나 동일한 state에서 동일한 input에 대해 동일한 상태 전이 혹은 output을 내놓는 환경 + 완전 비동기 시스템 환경 + 하나 이상의 프로세스가 장애가 발생할 수 있는 환경"에서 safety와 liveness를 동시에 만족할 수 없다는 이야기.

safety: replicated state machines가 linerizability를 만족하는 것. 동일한 input에 모든 nodes가 동일한 결과에 도달.
liveness: 최종적으로 output을 내야 함.

핵심은 셋 중 하나를 포기해야만 느린 프로세스와 죽은 프로세스를 구분할 수 있기 때문.

Fully Asynchronous System → 동기화된 클럭이 없으므로 구분 불가
하나 이상의 결함 프로세스 → 하나라도 예고 없이 영구히 멈출 수 있다면, 비동기 + 결정론적 알고리즘이 해결할 수 없음.
결정론적 알고리즘 → 느린 것과 죽은 것을 구분할 방도가 없는데, 영원히 기다리면 죽은 노드로 인한 liveness 위배, 무시하면 뒤늦게 도착한 메시지 때문에 safety 위배 가능

말이 좀 이상한데, "하나 이상의 결함 프로세스"를 포기한다는 의미는 하나도 결함이 없는 환경을 만족시키라는 의미.

보통은 결정론적 알고리즘을 확률적 합의 알고리즘으로 바꾸는 것을 선택한다고 알고 있고, raft도 그 중 한 예라고 알고 있음.

Consisten Hashing

[대규모 시스템 설계] 5장. 안정(일관성 있는) 해시 설계

1. 수평적 규모 확장에서 고려할 점 수평적 규모 확장 (Horizontal Scaling, Scale-Out)수평적 규모 확장성을 달성하기 위해서는 요청 또는 데이터를 서버에 균등하게 나눌 수 있어야 한다.클라이언

jaeseo0519.tistory.com

Bloom Filter

네가 찾는 데이터가 있을 수도 있고 없을 수도 있지만, 없는 것 만큼은 확실히 보장하는 녀석.

Count-Min Sketch

What’s Hot and What’s Not: Tracking Most Frequent Items Dynamically(2005)

데이터 스트림에서 각 요소가 몇 개 존재하는 지 추정하는 자료 구조.

이거랑 이후에 나올 HyperLogLog는 AI한테 사이트 하나 만들어달라고 하고, 직접 만져보는 게 이해가 빠름.

서로 다른 독립적인 hash function 별로 행을 분리하고

input을 hashing한 값을 각 열에 할당.

조회할 때도 같은 hash function을 사용하므로 각 행에 대해 같은 열을 참조할 것이고, 그 중 최소값을 반환하는 자료 구조.

HyperLogLog

HyperLogLog: the analysis of a near-optimal cardinality estimation algorithm(2007)

고유 원소 개수(cardinality)를 근사적으로 추정하는 자료 구조.

이건 이해하려면 수학적인 내용을 좀 알아야 하는데, 별로 궁금하지 않아서 대충 알아보기만 했다.

HyperLogLog는 고유 원소 개수 정도만 알 수 있고, "A라는 정보가 몇 개 있다"나 "고유 원소 중에 A가 있다"같은 질문에 대한 답은 불가능함.

애초에 책에서 갑자기 이걸 왜 언급하는지도 이해가 안 간다.

Strategy

나죽못고나강뿐 — Sun, 8 Feb 2026 19:46:37 +0900

1. Introduction

Dissonance

블로그에 공부, 프로젝트, 취업, 삶을 대하는 태도와 관련한 전략들을 공유해왔고 최근에는 자소서 첨삭까지 해주고는 있지만, 할 때마다 뿌듯함이나 보람이 아니라 자괴감이 쌓여간다.

개인의 신념 문제는 밑에서 다룰 것이지만, 가장 큰 괴리는 '조언이 이렇게 가벼워도 되는 건가'라는 질문을 스스로에게 끝없이 할 수밖에 없다는 구조에 있다.

"행위의 동기가 올바랐고, 결과가 좋았으니 고민하지 않아도 된다"는 타인의 격려는 딱히 도움이 되지는 않았다.

세상 모든 사람들을 속일 수 있을 지언정, 나는 그 행위의 동기가 올바르지 않았고, 좋은 결과가 나온 건 내 덕분이 아닌 그들의 역량 덕분이었다는 사실을 스스로에게 속일 수 없기 때문이다.

단순 자기 만족과 커리어를 위해 뒤처진 이들을 돕는 것이 아닌 이상, 나는 현실과 책무를 직시해야만 한다.

내 블로그 포스팅의 20%에 등장하는 단어인 "전략"은 그만큼 인생에 있어 큰 비중을 차지한다.

그리고 그 전략이란, 언제나 나의 상태와 가용 자원 등을 객관적으로 분석하는 절차를 밟아야 한다.

따라서 타인을 위한 전략을 설계할 때도 같은 절차를 따라야 하지만, 그러기 위해서는 그들이 살아온 삶과 가치관, 재정 형편과 같은 현재 상태를 모두 검토해야만 한다.

이건 불가능한 일이다.

그러니 진정 상대만을 위한 전략을 세워줄 수는 없기에, 통계치를 기반으로 분석한 데이터를 들이밀 수밖에 없다.

실로 가벼운 조언이 아닐 수 없다.

때문에 나는 나의 위선적인 행위에 매사 역겨움을 느낀다.

Purpose

금일 영어 회화 스터디에서 다음과 같은 주제로 이야기를 나누었다.

"If you were to become a writer, what kind of book would you want to write?"

다양한 직종의 사람들이 있었고 대부분 연령대가 40대를 넘어서는 분들이 많으셨기에, 모두 자신들의 삶의 스토리와 노하우들을 담는 책을 적고 싶어하셨다.

그리고 다들 사회초년생과 학생들에게 도움을 주고 싶다는 숭고한 목적을 가지고 있었다.

세상에는 이미 자신들의 성공 혹은 실패, 그리고 삶의 지혜를 담은 수많은 훌륭한 책들이 나와있었기에, 나는 조금 다른 책을 집필하고 싶었다.

"I want to write a book that really reflects my own philosophy. There are already many great books based on personal experiences, but in my experience, directly applying someone else's life lessons to my own often leads to failure. So I want to write about how to build your own strategy for your own life."

하지만 굳이 책을 집필할 때까지 일을 미룰 이유가 없다.

나는 지금 오늘 내뱉고 온 말을 실현하기 위해서, 자신만의 전략을 세우는 방법에 대해 이야기하려고 한다.

2. Strategy

Failure

뒤늦게 정신차리고 공부를 시작하려던 중학교 3학년 때, 공부의 왕도라는 EBS 프로그램을 보고 그들의 방법을 그대로 따라했었다.

어릴 때부터 책을 많이 읽었기 때문인지 국어와 영어를 1등급으로 만드는 건 그다지 어려운 일이 아니었지만, 내 인생의 가장 높은 벽은 수학이었다.

수포자가 실은 "수학이 포기한 자"의 줄임말이 아닐까 싶을 정도로 아무리 노력해도 등급이 오를 생각을 하지 않았고, 끝내 나의 재수 도전은 처참하게 망해버렸었다.

이후로 공부는 내 길이 아닌 것 같아 반쯤 포기하고 1년 동안 신나게 놀았었는데, 나중에서야 이 사실을 받아들이는 것이 어지간히도 분하고 수치스러워서 취한 자기방어적 행동이었다는 것을 알게 되었다.

아무튼 전역 이후, 취미로 시작한 프로그래밍에 완전히 매료되어버렸고, 이번에는 온갖 변명을 들이밀며 포기할 바엔 죽겠다는 일념으로 임했기에 방법을 찾아내야만 했다.

다른 이들이 성장을 위해 공부할 때, 나는 내 마지막 남은 자존심과 목숨을 걸고 공부를 했다.

하지만 지금까지 해왔던 것처럼 무식하게 노력만 해서는 망한다. 아니, 죽는다.

그러니 어떻게 공부를 할 지 전략을 세워야만 했다.

그것이 내 인생에서 처음으로 전략에 대해 깊게 생각한 때였다.

Process

전략은 크게 3단계의 절차를 거쳐 세워진다.

목표
내가 가진 자원과 현재 상태, 한계점 파악 및 정보 수집
목표로 도달하기 위한 구체적인 경로 탐색 및 계획 수립

초기에는 위 프로세스를 절차적으로 수행하려고 해도 오차가 클테니, 반복 사이클을 돌리거나 병행해야 한다.

자세한 세부 사항은 밑에서 섹션 별로 나누어 설명한다.

이 과정은 어지간히도 단순하고 쉬워보이지만 그렇지만은 않다.

목표는 명확해야 하고, 스스로를 잔인할 정도로 객관적으로 분석해야 하며, 단 하나의 성취를 위해 온갖 실패의 쓴맛을 맛봐야만 한다.

이 모든 삼박자가 갖춰지더라도 운이 따라주지 않으면 망하는 경우가 빈번하고, 나의 현재 상태와 목표 사이의 간극이 클 수록 형용할 수 없는 절망감과 좌절감이 필수적으로 따라온다.

그럼에도 해내야만 한다.

스스로 세운 삶의 의미와 목표마저 부정하면서 살아야 할 이유가 없지 않은가.

3. Goal

Clarity

목표는 명확해야 한다.

가능하다면 KPI를 설정하는 것만큼이나 수치적으로 표현 가능할 수록 좋다.

내가 가장 싫어하는 목표가 행복이나, 커리어의 정점인 이유가 이 때문이다.

행복의 알고리즘에서 작성했듯, 행복이라는 추상적인 개념은 목표가 될 수 없다.

경쟁을 해서 금메달이라도 수여해주는 것이 아닌 이상 커리어의 정점이라는 목표도 마찬가지다.

특히나 추상적인 목표는 위기의 순간에 타협이 될 여지가 다분하다.

자조적인 태도로 "사실 이게 원래 목표였어"라는 변명을 내뱉는 꼴을 더이상 보고 싶지 않다.

제때 포기하는 것도 능력이라는 것을 알지만, 어디까지나 자신의 모든 것을 걸고 부딪혀본 이들만 내뱉어도 되는 말이다.

구체적인 목표를 세워야 한다.

모호한 목표를 달성하기 위한 플랜을 세우는 것은 무모한 행위다.

Scale

너무 큰 목표를 세우지 말라는 사람도 있고, 큰 목표를 세워야 한다는 사람도 있는데, 둘 다 필요하다.

큰 목표를 달성하기 위한 작은 목표들을 단계적으로 설정해야만 객관적인 측정과 심리적 안정을 취할 수 있다.

즉, 거시적(macro)인 목표를 달성하기 위한 작은(micro) 목표들을 세우라는 이야기다.

예를 들어, 미국에 있는 대학원에서 연구를 하고 싶다고 해보자.

그럼 미국 비자를 발급받기 위한 조건을 파악하여 목표를 세우고, 나는 실무 경험 없이 대학원에 가는 것을 꺼렸기에, 관련 업계 취업을 먼저 목표로 삼았다.

이후 취업을 하기 위해서 목표로 하는 회사를 선택하고, 그 회사를 입사하기 위한 자격 조건을 채우기 위한 공부 목표를 세움으로써 더 작고 단기적인 목표들로 나눌 수도 있다.

큰 목표는 원동력으로써 존재해야만 하지만 계획을 세우기 어렵다.

하지만 이를 여러 작은 목표들로 계속 나누다보면 구체적인 계획을 수립할 수 있게 되면서 성취감도 챙길 수 있다.

4. State

가장 쓰기가 조심스러운 파트다.
철학과 사상에 대한 주제를 글에 담을 때마다 조심스러울 수밖에 없다.
나는 N명의 사람이 있으면 N개의 철학이 존재하길 바라는데, 소신이 뚜렷하지 않은 이들은 내 말에 너무 쉽게 영향을 받는다.
"개똥철학"이라고 치부해도 좋으니 매우 경계해서 읽었으면 좋겠다.

Fact vs. Truth

올바른 전략을 세우기 위해서는 내 상태를 객관적으로 평가해야 하고, 이를 위해서 티끌 하나의 거짓조차 용납치 않고 사실과 진실을 봐야한다.

그런데 이 둘을 구분하지 못하는 사람들이 제법 많아서 (적기 싫은데) 적었다.

사실(fact)과 진실(truth)은 다르다.

누군가 나의 실책을 뒤에서 험담했다고 하자.

사실은 그 사람이 나를 험담했다는 것과 알고 보니 그 사람이 지적한 나의 실책이 아무런 문제가 없다는 것까지다.

그 사람이 나를 싫어한다거나, 나에게 피해를 입히기 위해 의도했다는 것은 사실 정보를 기반으로 추측한 결과일 뿐이다.

AI 때문에 취업이 안 된다고 결론을 짓는 것도 구분지어 생각해야 한다.

AI가 취업 시장에 영향을 준 것, 앞으로 더 강력해질 것이라는 것, 그로 인해 취준 패러다임이 크게 바뀌고 있다는 것, 그리고 당신이 취업을 하지 못했다는 것은 사실이다.

그러나 단순히 그것만으로 당신이 취업이 안 된다고 분석한 것은 정보 수집이 부족했거나, 그냥 그렇게 믿고 싶기 때문일 수도 있다.

내 경우에는 나처럼 살면 불행해질 것이라 많은 이들이 단정했었지만, 그렇게 말하는 이들 중 나처럼 살아본 이가 단 한 명도 없다는 사실을 파악했었기에, 진실은 다수의 의견과는 관련이 없다는 것을 알 수 있었다.

또한 경력 없이 대학원 혹은 창업을 계획하기도 했었으나, 이는 취업이 어려워 현실 도피성 거짓임을 스스로 인정하고, 다시 원래금 계획대로 되돌린 적도 있었다.

사실은 현상이고, 진실은 오로지 내면에서 솟아오르는 자신만의 것이다.

선과 악, 도덕, 법, 이데올로기, 구호, 프로파간다와 같은 외적인 요소 따위가 당신의 진실이 될 수 없다.

이 둘을 명확하게 구분지어 봐야한다.

왜곡되고 편협한 사고가 당신의 시야를 가리는 걸 방치하지 말라.

도덕과 법이 진실은 아니지만, 질서를 유지하기 위해선 반드시 존재해야만 한다.

질서가 존재하기에 내가 길 한복판에서 봉변을 당할 확률이 줄어들었다.
위법 행위를 처벌해야 하는 이유는 거짓이나 악이기 때문이 아니라, 룰을 위반하여 질서를 무너트리려 하기 때문이다.

또한 불확실성으로 넘치는 세상에 예측 가능한 가이드 라인을 설정하는데 도움을 준다.
예를 들어, 선이나 도덕을 최고 가치로 두는 팀원에게 동기를 부여하는데, 굳이 "그건 진실이 아니야"같은 사회성 떨어지는 면모를 보일 이유는 없다.
이런 유형 대다수는 믿음을 존중해주는 것만으로도 최선을 다할 것이다. (호구 취급하라는 말이 아니다.)

멋대로 사회적 합의를 깨부수지 말고 플랜을 이행하는데 있어 도구로 잘 사용해라.

Experience

나는 실존적 위기가 찾아올 정도로 내면의 모든 사실과 진실을 재정립하는데 시간을 썼었다.

이를 고민한 본래 목적은 다른 계기 때문이었지만, 덕분에 나의 메타인지는 월등하게 향상되어 있던 시기였다.

코딩을 접한 시기도 마침 이 맘 때 쯤이었다.

내가 좋아하면서도 잘 하는 일을 찾기 위해 온갖 일을 다 벌려놨던 시기였고, 반 년 내에 바디 프로필을 찍겠다는 구체적인 계획이 있을 정도로 운동에도 진심이었던 때였다.

하지만 예상보다 일찍 최선을 다해보고 싶은 일을 찾았고, 내가 가진 자원과 역량을 따져봤을 때 둘을 병행하는 건 과욕이었다.

그렇기에 운동은 장기적인 목표 달성을 위한 건강 관리 차원 행위로써 중요도를 하향시켰고 바디 프로필은 깔끔하게 포기했다.

덕분에 더 많은 시간을 프로그래밍 공부에 매진할 수 있었다.

당시 나의 강점이라고는 열정 하나 뿐이었다.

단순히 치기어린 감정이 아니라, 고3 생활과 재수 경험을 떠올려보면 이는 내 강점이라 부를 수 있다고 판단했다.

하지만 당시에 나는 열심히 했다기 보다는 열심히 하는 것처럼 보이는 것에 더 중점을 두었었기에, 같은 실수를 번복하지 않기 위한 대책이 필요했다.

내가 채워야 할 지식이 무엇이며, 그 지식을 지정한 날짜까지 습득하기 위해 필요한 시간, 심지어 지식을 습득했다는 기준까지도 재정의했다.

초기에는 시간과 체력을 빼앗기는 알바를 하지 않고 얼굴에 철판을 깔고 부모님께 도움을 청했다.

대신 소비는 최대한으로 줄였고, 조금 시간이 흐른 뒤에는 장학금, 부트캠프, 외주로 돈을 충당했다.

그 외 모든 시간은 오로지 공부 뿐이었고, 압도적인 공부량 덕분에 남들보다 빠른 속도로 성장하며 많은 이들에게 칭찬을 받았으나, 같은 시간을 쏟았다면 남들은 나보다 더 나은 성과를 냈을 것이라는 통계만이 중요했다.

이는 나의 공부 효율이 떨어진다는 것을 의미했고, 그 효율을 더 끌어올리기 위해서 타인의 공부 전략을 흡수하고, 내 공부 패턴의 비효율적인 측면을 분석해서 뜯어 고쳤었다.

이렇게 1년 정도 살면, 슬슬 내가 정한 삶의 의미를 부정하는 이들과 인정해주는 이들이 많아진다.

하지만 전부 필요없다.

타인이 나를 부정한다고 가치가 훼손되는 것도 아니며, 나를 긍정한다고 가치가 향상되는 것도 아니다.

자신의 내면의 진실을 최우선으로 두라.

진실이 타락하지는 않았는지 끊임없이 사실 정보를 모아 갱신하고, 편협하게 해석하거나 수집하지는 않았는지 재검토를 해라.

타인이 멋대로 재단하는 나의 모습은 아무리 좋은 말이라도 걸러낼 줄 알아야 한다.

(다만 이를 통해 유추 가능한 상대방의 나에 대한 우호도는 향후 전략에 사용할 수 있다.)

Contradiction

나는 사람이 태생적으로 타인의 진실을 알지 못한다고 여긴다.

상대가 만들어 낸 언행이란 사실 정보로 목적을 유추할 뿐이며, 상대 스스로도 진실이 무엇인지 알지 못하는 경우도 많기 때문이다.

그래서 인간은 영원히 서로를 온전히 이해할 수 없다는 흉폭한 진리를 받아들였다.

또한, 세상에 단 하나의 진실만이 존재한다면 좋겠지만 그렇지 않은 경우가 더 많았고, 최악의 경우는 대립하는 경우도 잦다.

그리고 이러한 모순된 진실을 외면한 채 끌어안고 나아가기만 하면, 그 괴리에 스스로 잠식되어 낙오될 우려가 있다.

예를 들어서 "선의는 선의로 남아야 한다"는 나의 말과 실제 나의 행위가 일치하기에 대다수가 내게 칭찬과 감사를 표하는 것이겠지만, 이것이 모두 내게 진실임에도 불구하고 또 다른 진실과의 괴리가 내 기분을 역하게 만든다.

제 아무리 그럴 듯하게 포장해도 근본적으로 직업을 없애는 개발자가 타인의 취직을 돕기 위한 행동과 경쟁 시대에서 승리하기 위해 타인을 좌절시키는 주제에 함께 성장하기 위한 나의 노력과 신념은 서로 모순된다.

이러한 인지부조화를 다스리지 못하면 번아웃이 올 것이고, 애매하게 유지하면 위선, 혹은 사기꾼이 된다.

또 다른 진실로 불편한 괴리를 덮어버릴 수도 있겠으나, 훗날 그것이 진실이 아니었다는 것을 다시금 자각하게 되면 더 큰 혼란에 빠질 수도 있다.

나도 여기에 대한 답은 아직 모르겠다.

그저 계속 고뇌할 뿐이다.

이게 전략과 무슨 의미가 있는지 의문이 들 수 있겠지만, 목표까지 세워가면서 나아가는 경우는 소소한 경우보다 거창한 경우가 더 많다고 생각했기 때문이다.

그리고 필히 한정된 자원과 기회를 놓고 경쟁하다보면 이러한 괴리가 스멀스멀 기어올라오는데, 많은 이들이 이쯤에서 번아웃이 찾아와 내려놓고 행복을 찾으러 떠난다는 말을 하곤 했었다.

그들에게 그 판단은 올바랐을 수도 있지만, 지금의 나에게 있어서는 다른 목표가 생겨 경로를 벗어난 것 외에는 낙오일 뿐이다. (그들이 틀렸다는 게 아닌 주관적인 생각일 뿐이다. 같은 인간으로서 그들이 진정 원하던 이상에 도달하길 바란다.)

난 나의 낙오를 행복이라는 추상적인 명분 하에 위안하고 싶지는 않았다.

그건 거짓으로 내 눈을 속이는 행위일 뿐이다.

Foundation

'나'라는 사람은 자신의 상태를 객관적으로 파악할 수 없는 존재이면서, 그 누구보다 객관적으로 파악할 수 있는 모순적인 존재다.

사실 당신이 굳게 믿는 진실 마저도 살다보면 어느 순간 거짓이 될 수도 있다.

하지만 사실은 바뀌지 않는다.

당신의 내면이 제 아무리 요동친다고 한들 사실은 그 자체로써 존재한다.

때때로 그러한 사실 정보들이 혼란을 잠재워줄 새로운 진실을 바로 세우는데 도움이 되기도 한다.

그래서 둘은 상호 보완 관계에 가깝다.

잘만 사용한다면 진실은 사실을 왜곡시키지 않도록 일조하고, 사실은 진실을 세우는데 기여한다.

또한 진실이 원동력이라면, 사실은 전략을 수립하는데 객관적인 지표로 사용 가능하다.

부족한 정보를 토대로 올바른 전략을 세울 수는 없다.

하지만 외부 세계부터 자신의 내면 세계까지 전체를 훑어보고, 조직을 이끌어야 한다면 예산과 팀원들의 역량과 성향과 같은 부분까지 최대한 세세하게 파악해두면 전략을 세우는데 도움이 된다.

5. Plan

Invariant

꼼수나 행운, 의리와 정과 같은 변칙적인 요소를 계획에 반영하는 것은 전략이라기 보다는 도박에 가깝다.

남들보다 쉽고 빠르게 성장할 수 있는 방법을 내게 알려달라고 해도, 나도 그런 방법따위 알지 못한다.

그게 가능했다면 애초에 그게 당신의 역량 중 하나였을 것이다.

나는 그게 안 되니까 "나보다 2년 앞선 이를 1년 내로 따라잡기 위해, 1년 간 그 사람보다 3배의 노력을 한다"는 압도적인 노력의 총량을 쏟아부었다.

내가 상대를 도왔으니 상대도 마땅히 나를 도울 것이란 기대도 하지 않는 것이 좋다.

사람의 행동과 감정만큼이나 예측 불가능한 것이 없다.

상대가 나에게 무언가를 제공했다면, (좋은 것이든, 나쁜 것이든)그것의 10배로 되갚아서 학습을 시키는 것은 가능할 것이다.

설령 배신을 당하더라도, 그 배신을 예상하지 못했던 자신의 경험 미숙을 탓하는 편이 이롭다.

그 사람이 나를 왜 배신했는지 영원히 알 수 없는 진실을 찾을 시간에 플랜부터 수정해라.

때때로 승부수를 띄워야 하는 경우가 존재하기는 하지만, 그로 인한 리스크 또한 충분히 계산을 해라.

그게 감당이 안 된다면 확률이 더 높아지는 밑작업을 해두는 것도 한 가지 방법이 될 것이다.

계획에 변수는 최대한 덜어내야 한다.

Path

구체적인 목표를 세우고 원동력과 정보들을 충분히 수집했다고 끝나질 않는다.

마이크 타이슨이 말하지 않았는가, "누구나 그럴싸한 계획은 있다. 쳐맞기 전까지는"이라고.

사실 정보가 충분하지 않았거나,

사실이 아닌 데이터가 섞여있었거나,

팀원이 갑자기 이탈하거나,

내가 갑자기 교통사고를 당했거나,

역량을 과신했거나,

의지가 꺾이거나,

누군가의 희생이 필요한 판단이거나.

온 세상이 나를 방해하려 달려드는 기분이 들 정도로 부조리 투성이에 뭇매를 맞기 일쑤다.

이건 경험이 미숙할 수록 어찌 대응할 방도가 없다. 실패할 수밖에.

하지만 타인의 성공담보다 실패담이 더 가치를 발휘하는 부분이기도 하며, 실패는 성공의 어머니라는 말이 유효하게 먹히는 곳이기도 하다.

남들이 깔아놓은 판에 굳이 순순히 응해야 할 이유도 없다.

천재랑 나, 아니 AI와 내가 태생적으로 불합리한 순수 학습 역량으로 대결을 할 이유가 없다.

그럴 땐 판을 뒤집거나, 회피하거나, 아니면 그들의 등에 올라타는 것도 한 가지 방법이 될 수 있다.

예를 들어, 근래 많은 이들이 AI를 경쟁 상대로 여기는 경향이 있는데, 적어도 코드 생산량에 있어 인간은 AI의 경쟁 상대조차 되지 않는다.

그러나 만약 인식의 관점을 옮겨서 AI의 등에 올라탄다면 어떠한가.

일머리는 좋지만 개발에 다소 시간이 걸리던 이들은 AI의 서포트에 힘을 입어 자신의 역량을 극대화할 기회가 되었다.

비단 개발자에 국한된 이야기가 아니다.

나의 지인 중에는 AI로 자동화 프로세스를 구축하고 업무 효율을 증대시킨 이들도 존재한다.

단순히 AI라는 존재에 떨기만 하면 아무런 계획도 세울 수 없거나, 잘못된 정보 기반의 계획을 세우게 되니 주의해야 한다.

목표로 도달하는 경로에는 다양하고 예측 불허한 위험들이 도사리고 있지만,

그 경로를 지나가본 이들의 조언을 경청하거나,

아니면 다른 경로를 간다는 선택지 등 다양한 의사 결정을 내릴 수 있다.

혹은 승부수를 띄워보거나.

6. Conclusion

.

이렇게 살면 소시오패스, 혹은 AI보다 더 AI같은 인간이라는 말이 줄기차게 뒤따라온다.

그런데 내가 진짜 소시오패스였다면, 누구에게도 도움이 되지 않을 거라 생각하는 포스팅에 7시간을 투자하진 않았을 것이다.

적당히 눈을 가리고 선행에 대한 보수를 받고, 쓸 데 없는 정에 연연하느라 실패하는 경험을 만들지도 않고, 뉴스에서 들려오는 흉악 범죄에 분노하느라 감정 소모를 하지도 말았어야 했다.

결정적인 순간에 나의 유약함이 일을 그르치는 것을 몇 번이고 봤음에도, 나는 끝내 이것을 버리지를 못한다.

하지만 매사 그런 일에 휘둘리기에는 나에게 주어진 책임을 등한시 할 수 없다.

그렇기에 전략이 필요하고, 주위 환경 뿐만 아니라 자기 자신마저 통제해줄 수 있는 완고한 프로세스를 세우는 것이다.

전략이 부조리한 삶을 살아가는데 있어 의미가 되어주지는 못하겠지만, 적어도 지금 당장 내가 가야하는 길이 무엇인지는 밝혀줄 것이다.

[AI Engineering] 9장. Inference Optimization

나죽못고나강뿐 — Fri, 6 Feb 2026 21:20:08 +0900

PPT 만든다고 11pm에 퇴근하는 나 ㅋ

서빙 효율성 판단 척도
- 비용
- 처리량
- 지연시간
단순 GPU 연산 능력으로 평가하는 건 무리가 있음.
비효율적으로 돌아가는데 단순히 열심히 계산하다고 MFU 높고, Bandwidth 문제인데 GPU 활용도가 떨어진다고 측정될 수 있음. -> 그래서 MBU 개념이 등장함
목표는 처리량 높이고 지연시간 낮추기. 그런데 어떻게?

추론의 2단계
- Prefill: 사전 계산
- Decoding: 자기회귀 방식으로 token을 순차적 생성
decoding 단계와 다르게 prefill은 병렬 처리가 가능하고, 그렇게 해야 효율적
- 덕분에 둘의 병목 원인이 다름.
여기서 우리는 크게 세 가지 부분으로 나누어 추론 효율성과 성능을 높일 아이디어를 찾을 수 있음
- prefill: 메모리 잘 써서 연산량 줄이기
- model: 모델을 압축시키거나 파라미터 양자화해서 줄이기
- decoding: 연산량은 얼마 안 되는데 bandwidth가 병목이니까 이 문제를 해결해보자

CPU Bound, I/O Bound를 알고 있다면 무슨 의미인지 금방 알 듯.

매번 동일한 토큰 선형 변환 낭비 -> 캐싱을 하자

근데 캐시가 너무 비효율적임 (KV cache mem 계산)
- KV cache size 계산
  - KV 캐시는 키, 값 캐시 각각 2개 저장하므로 2 곱함.
  - 모델이 사용하는 데이터 타입 크기에 맞게 곱함
  - self attention 결과는 attention layer 수만큼 생기므로 layer 수 곱함
  - token embedding을 표현하는 dimension만큼 또 곱함
  - 메모리 미리 확보하기 위해 최대 sequence 길이 곱함
  - 배치 크기 커질수록 저장하는 데이터 많아지니까 배치 크기도 곱함
- KV Cache 공간을 미리 계산해서 memory 할당해줬더니 batch 크기 늘릴 공간이 부족해짐
  - e.g. LLama 2 13B 모델은 40 layers, 5,120 dimension인데, 32 batch size, 2,048 sequence length, 2 bytes per value로 단순 계산하면, 2 * 32 * 2,048 * 40 * 5,120 * 2 = 54GB

multi-head attention
- Attention is All you need에서 여러 head에 attention 연산을 수행했었음.
- Q, K 사이 다양한 측면 관련성 반영 가능하고 성능은 높였으나, KV cache에 더 많은 메모리가 필요하고 로드하는데 memory bound.
multi-query attention
- 모든 head가 단일 K, V 공유
- Q만 head 독립적
- K, V projection param이 1/h로 감소
grouped-query attention
- head를 g개 그룹으로 나누고, 그룹 내에서 K, V 공유
- MQA와 MHA 사이의 중간 지점
- g=1이면 MQA, g=h면 MHA와 동일

OS의 virtual memory 개념과 유사함.

모델 자체의 용량 줄여서 HW 요구 사항을 줄이자
- FP16, BF16, ...
- W4A16(Weight 4bits and Activation 16bits) 같은 것도 쓴다
- 양자화 수행 시점
  - PTQ
    - bits-and-bytes: QLoRA 저자가 썼던 논문
    - GPTQ: 양자화할 때 모델도 업데이트 하자
    - AWQ: 양자화할 파라미터를 선별하자
    - GGUF: CPU에서도 양자화가 된다면?
  - QAT

PTQ는 vision 했을 때 빼놓고는 잘 안 쓸 듯. LLM 스케일이 압도적으로 커서 함부로 양자화하면 성능이 어떻게 떨어질지 알 수 없다.

작은 모델을 똑똑하게 만들자
Knowledge Distillation (이미 앞에서 배웠으므로 패스)
- 지식을 더 작은 모델로 이전
희소성(Sparsification)
- 희소 행렬은 많은 요소가 0인 행렬로, 전체 밀도 행렬보다 공간을 덜 차지하는 압축된 형태로 표현
- 가장 흔하게 신경망 구성 요소를 선택적으로 제거(pruning)하는 방식 사용

batch 없을 때 문제점
- GPU는 테라플롭, 심지어 페타플롭 범위 연산 속도를 자랑함.
- 그런데 model parameter 로드하느라 memory bandwidth bound 걸려서 툭하면 포화상태 도달
naive batching = static batching
- 힘들게 모델 파라미터 로드했는데, 굳이 요청 하나만 처리할거냐? 그냥 한 번에 많이 받아서 처리해버리자.
- 그런데 실제 환경에서 요청 언제 들어올 줄 알고 한 번에 처리할 거냐. N개 쌓일 때까지 기다릴 거임??
- 그리고 token sequence 차이가 많이 날 수록 짧은 질문한 애들은 손해 + GPU도 놀고 있음.

dynamic batching
- 조금 기다려서 최대한 많은 요청을 한 번에 처리하자
continuous batching
- Continuous Batching = Ragged Batching + Dynamic Scheduling + Chunked Prefill
  - Ragged Batching: 패딩 없이 여러 시퀀스를 처리할 수 있게 함
  - Dynamic Scheduling: 완료된 시퀀스를 즉시 새 시퀀스로 교체
  - Chunked Prefill: 긴 프롬프트를 메모리 제약에 맞게 분할

Decoding할 때 memory bandwidth 병목 좀 제거하자
kernel fusion
- 반복적 수행하는 연산(e.g. 메모리 로드/저장)은 하나로 묶어서 오버헤드 줄이자.
- flash attention이 대표적인 예시
- MS에서 21년에 공개한 deep fusion이란 것도 있음

tiling으로 NxN 행렬을 BLOCK로 나눠 SRAM에 저장
kernel fusion으로 쪼갠 block 연산들을 하나의 kernel로 합침
기존에도 행렬 곱셈이긴 한데, HBM 왔다갔다하는 게 병목점 -> SRAM만 쓰자
AI 개발자가 할 수 있는 영역은 아님
- CUDA: NVIDIA GPU 프로그래밍하기 위한 platform/language
- CUDA 개발자가 NVIDIA LIB 수준에서 attention 전체를 하나로 합친 커스텀 CUDA kernel을 추가해줘야 함.
softmax 연산을 분할하는 트릭을 보는 게 묘미.

GPU는 행렬 곱셈 연산은 빠른데, 비행렬 곱셈 연산은 16배 정도 느림.
비행렬 곱셈이 빈번하게 발생하는 곳이 flash attention에서 softmax 분할하다가 생겼는데, 정규화를 마지막에 한 번만 수행하는 것으로 횟수 자체를 줄여버림.
역전파를 위한 상태 저장도 m, l이 아니라, L만 계산해서 저장해두면 됨.

batch size가 작거나, 어텐션 헤드 수가 작아서 충분한 수의 thread block을 모으지 못하면, GPU의 SM을 충분히 활용하기 어려움
그러니 입력 시퀀스로도 병렬화를 추가해버리자.

사실 이게 효과가 있는 게 맞나 의심스러워서 안 찾아보다가, 여기저기서 언급되길래 호다닥 추가한 내용. (나도 잘 몰라..)

[LLM 실전 AI 애플리케이션 개발] 5장 그림 5.13 텐서 병렬화 이미지 오류 수정

나죽못고나강뿐 — Sat, 31 Jan 2026 16:03:53 +0900

책을 읽다가 self-attention 열 병렬화의 그림이 이상한 것을 발견

GPU 0: Q₁ ⊗ K₁ᵀ → Softmax → Dropout → ⊗ V₁ → Y₁

GPU 1: Q₂ ⊗ V₂ → Softmax → Dropout → ⊗ K₂ᵀ → Y₂

GPU1에서 Q₂ ⊗ V₂를 먼저 계산하고 나중에 K₂ᵀ를 곱함.

Self-Attention 표준 공식인 Attention(Q, K, V) = Softmax(Q · Kᵀ / √d) · V와 다르고, 위 방식대로 계산하면 수학적으로 완전히 다른 연산으로 보는 게 타당함.

https://huggingface.co/docs/transformers/v4.15.0/parallelism#tensor-parallelism

아니나 다를까 K2와 V2의 위치가 바뀌어 있더라..

중간중간 트랩이 있는 걸 주의하면서 읽어야 할 듯.

[AI Engineering] 8장. Dataset Engineering

나죽못고나강뿐 — Wed, 28 Jan 2026 21:11:26 +0900

내용이 거의 고이즈미 신지로 화법.
"1 더하기 1은 2다. 왜냐면 그것이 수학이기에." (끄덕)
그만큼 당연한 말을 늘어놓고 있음.

Data Curation
- curation
  - 원래 미술관에서 기획자들이 우수한 작품을 뽑아 전시하는 행위
  - 다른 사람이 만들어놓은 콘텐츠를 목적에 따라 분류하고 배포하는 일 (양질의 콘텐츠만을 취합·선별·조합·분류해 특별한 의미를 부여하고 가치를 재창출하는 행위)
- Data with COT
- Data with Tool use
- Data with Conversation
  - Single Turn
  - Multi Turn
Data Quality
- There's many factors for data quality
  - Relevant -> 이커머스는 얘가 중요한 듯
  - Aligned with task requirements -> 개발할 땐 이거 아닌가 ㅋㅋ
  - Consistent -> 제조업에서 가장 중요한 듯
  - Correctly formatted
  - Sufficiently unique
  - Compliant
- What's the most important factor for data quality in LLM?
  - 답이 없는 문제.
  - Aligned with task requirements 아닐까? LLM이 결국 input이 있을 때 output이 있는데, 요새는 코딩이나 수학같은 것들을 tuning함. 그러기 위해선 LLM이 얼마나 복잡성을 담고 있는가가 중요하다고 생각.
- What's the most important factor for data quality in ML?
Data Coverage
- A model's training data should cover the range of problems you expect it to solve
- Training language models to follow instructions with human feedback(2022)
Data Quantity
- There're 3 factors deciding how much data you need
  - Fine-tuning technique
    - Less total tokens: LoRA
    - Much total tokens: Full Fine-Tuning
  - Task complexity: More complex task -> More data you need
    - 경험 상 얘가 제일 중요함. complexity만 잘 되어있으면 LoRA를 하든 Full Fine-Tuning을 하든 잘 되더라. 근데 이거 안 되어 있으면 뭘 해도 안 됨.
  - Base model's performance: Smarter base model -> Less data you need
    - 당연한 얘기 아님???
Data Acquisition and Annotation
- The goal of data acquisition is to produce a sufficiently large dataset with the quality and diversity you need
- Pipeline
  - Raw data archiving
  - Preprocessing with LLM
    - 어떤 경우에 해야 할까?
- What Database?
  - text면 뭘 쓸까? -> 당연히 RDB는 안 씀. mongoDB 같은 NoSQL이나 FileStorage 쓸 듯? -> "내가 원하던 답이 다 나왔다!" ㅋㅋㅋ
  - Ontology 요새 많이 씀 -> 근데 이거 관리 너무 어렵지 않냐? -> 맞음. relationship을 사전에 모두 정의해야 함. Graph DB의 장점이 확장성인데, relationship을 사전에 다 준비한다는 게 모순임. 그래서 이 relation을 어떻게 잘 정의하냐가 숙제임.
  - Graph DB vs. Graph RAG
    - Q. 그냥 retreiver를 Graph DB로 두면 Graph RAG임??
    - A. 얘는 골 때리는 게 Embedding 할 때는 vector DB가 필요했는데, Graph RAG는 LLM을 필요로 함. LLM이 scheme를 보고 가장 적절한 driver를 연결해서 응답을 뿌림. (판단의 주체가 LLM) -> 세부 파라미터 튜닝하는 옵션이 없어서 일관성이 떨어짐. -> 일관성을 유지하려면 relationship을 잘 정의해야 하는데, 그러면 graph DB의 장점이 떨어짐. 진퇴양난에 빠졌다.
Model Distillation
- Large models require very very large resource usage
- Distillate knowledge from teacher model (large) to student model (small)
  - 작은 모델이 큰 모델처럼 생각을 하게 만듦. (서빙이 쉬운 작은 모델을 만들려는 시도.)
  - 가장 유명한 게 deepseek. (metrics 보면 정신이 나간 수준)
    - Deepseek Knowledge Distillation
    - SOTA performance in parameter scale
  - 그럼 large model의 환각 현상을 잡는 것이 중요할 듯.
  - 지식의 확장보다는 small model의 performance를 끌어올릴 때 쓰는 것. (large model을 넘기 어려움.)
- 근데 Distillation할 때 썼던 testset 이외의 다른 입력에 들어왔을 때도 비슷한 성능을 발휘할 수 있나? -> 맞음. 근데 이건 distillation 구상의 문제로 봐야 함.
- 애초에 Distillation의 목적이 specific task의 일을 처리하게 하려고 했는데, large model은 과하니까 small model 쓰려는 거 아닌가? 그렇다면 앞선 질문은 당연한 현상 아님? -> "질문 수준에 감동했다" (ㅋㅋㅋㅋ). 그럼에도 너무 특정 작업에만 몰두하는 경향이 있어서 주의할 필요가 있긴 함.
Data Augmentation and Synthesis
- AI generate training data for weak model
- Science, Math related topic: Froniter Models
- Non-English data: Language specific model
  - Upstage Solar가 한국어에서 대표적인 예시
- NVIDIA NeMo
- 문제점: synthesis가 편향적일 수 있음. 가장 대표적 예시가 deepseek. 중국어가 자꾸 나오거나, 중국 친화적인 답변이 나올 수 있음.
Deduplicate Data
- Active Learning
  - Find representive data for Dataset
- AI learns mapping between variable variance and output variance

[AI Engineering] 7. Finetuning

나죽못고나강뿐 — Thu, 22 Jan 2026 11:39:09 +0900

스터디원 어록.

"영어 원문 자료가 있음에도 번역기 딸깍하면서 원문으로 읽지 않는 건 공부할 자세가 되어있지 않은 것이다."

Transfer Learning
- 학습시키고 싶은데 데이터 적으니까, 방대한 데이터셋이 있는 기존의 모델에 pre-training 시키고, 적은 양의 데이터셋으로 학습시켜야 하는 나만의 model을 post-training 시키는 것
- 원래 image 쪽에서만 주로 사용했었는데, Scaling Instruction-Finetuned Language Models(2022)에서 NLP(Natural Language Processing)에도 잘 되는 것을 보임 -> NLP 필수 교양서 수준
position encoding 왜 함?
- ~~K-NN~~(수정: RNN)에서 Transformer Architecture로 넘어오면서 attention 하면 위치 정보 사라짐.
  - "나는 사과를 먹는다" -> 입력 받는 행렬이 5차원이면? -> 벡터화 시켜서 넣었더니 위치 정보가 다 날아감.
- 그래서 sin, cos 파를 썼는데, 긴 context를 넣으면 한 주기를 넘어버려서 문제가 됨. (e.g. 최대 1,000 tokens로 했는데 1,500 tokens 들어오면? 주기를 늘릴 거임?)
- RoPE (Rotary Positioning Embedding)는 더하지 않고, position m에 해당하는 각도만큼 vector를 회전시킴. -> 행렬 곱셈(선형 변환)이 일어남. -> 위치 정보 손실 최소화
  - Rm * Rm' : 길이 확장 해야 했던 걸 각도만 쪼개면 됨. (interpolation)
LongLoRA (Shifted Sparse Attention)
Flash Attention
- "finetuning 파튼데 이걸 왜 들고 왔냐. 들어나 보자." (ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ)
- O(N^2)을 줄여주지는 않는데, 그냥 bandwidth 늘려서 한 번에 가져와서 융합(fusion)
  - 이런 것도 솔루션이라고 봐도 되는 건가? HW 비싼 거 써서 성능 높인다는 아이디어를 누가 못 내냐. -> 생각보다 안 비쌈. 요새 많이 쓴다.
  - 소비자용은 별 의미 없고, 기업용 끌고 와야 속도 체감될 것. -> "9장에서 재서님이 더 깊게 파주시길 기대합니다." (제가요?)
- 연산량은 동일한데 메모리 사용량을 줄여줌.
finetuning 왜 함?
- AI 쓰면서 불편한 점. 지식(fact)이 부족하거나, 행동(act)이 멍청. -> fact는 RAG로 보완 가능하니 act를 고쳐라.
- 근데 prompt 먼저 체크하고, degration risk, RAG로 fact 주입하고, 도메인 특화 지식 넣어주면 대부분 해결될 수도 있음.
  - A survey of techniques for maximizing LLM Performance 3:29 부터 나오는 그림 참고
- 범용 모델이 너무 좋으면, 니가 백날 finetuning한 모델을 쉽게 뛰어넘을 수도 있다. -> 대부분 few-shot learning으로 해결됨.
- 근데 또 요새 RAG도 잘 안 씀. 너무 long long long long context가 되니까 agent를 쓰자는 방향으로 가는 추세.
Memory Bottleneck
- 왜 역전파는 더 많은 메모리가 필요한가?
  - 추론에는 생각보다 별로 안 씀.
  - gradients, weight, optimizer states, activations 등의 정보를 들고 있어야 함.
  - Adam(Optimizer)의 경우 momentum, variznce 두 개 상태 필요.
- 요즘 LLM들은 모두 Adam 쓰는데, weights + gradients + optimizer states + activations 하면 거의 기존 memory의 4배가 필요. 13M Model이면 거의 78GB 이상.
Floating Point Formats
- FP32, FP16, BF16, TF32
- 정확도 좀 줄이면, 메모리 사용률 줄이고 성능 높일 수 있지 않냐. -> Quantization을 꿈꿀 수 있지 않을까.
PTQ, QAT 중 QAT를 더 많이 씀.
- 양자화 고려한다 = edge device에서 하겠다.
- PTQ 문제점은 정밀도 줄어서 성능이 너무 떨어짐.
- 그래서 QAT를 좀 더 많이 쓰는 추세. (성능 감소가 원본 모델의 98% 정도, 근데 mem 사용량은 엄청 줄어듦.) -> 근데 양자화했다가 복호화했다가 하느라 속도는 좀 느릴 수도.
PEFT (Parameter Efficient Fine-Tuning)
- transformer에 adapter를 하나씩 더 끼운 것.
soft prompt -> 대학원에서 이쪽은 잘 안 쓴다고 패스함. ㅋㅋ
LoRA(Low-Rank Adaptation)
- LORA: LOW-RANK ADAPTATION OF LARGE LANGUAGE MODELS(2021)
- PEFT면 사실상 다 LoRA 쓴다고 봐도 무방.
- 아까 multihead 뒤에 adapter를 붙였는데, 이제 옆에 붙일 거임. (병렬 처리) -> pretrained weight는 건들지 않고 adapter의 weight만 건들 거임. -> adapter는 attention 지나고 나서 학습, attention 연산을 할 때 그 값 자체를 바꾸(문장이 들어오면 Q, K, V로 projection을 직접 만듦)는 게 가장 큰 차이라고 생각.
- value, output이 제일 중요함. -> 뭘 finetuning해야 할 지 모르겠다? value, output tuning 해라~
요새는 학습할 때 Iteration 횟수를 많이 봐야하지 않을까. epoch로 보게 되면 large data를 너무 많이 되지 않을까
Direct Preference Optimization: Your Language Model is Secretly a Reward Model(2023)
- (그냥 요새 finetuning 안 하는 방향으로 많이 가더라, ranking할 때도 PPO말고 DPO 많이 쓰는 거 같더라. 이런 말 하려고 공유했는데 DPO 논문도 반드시 읽어야 할 논문 중 하나라고 열광함.)