저장한 Instagram 코딩·기술 포스트 다시 읽기: 알고리즘에서 백엔드·AI까지

이 글은 로그인된 개인 Instagram 저장 목록을 2026년 7월 23일에 검토해 만든 독립적인 학습 노트입니다. 원본 이미지·영상·캡처·캡션을 복제하지 않았고, 대표 포스트는 맥락 확인용 직접 링크로만 남겼습니다. 모든 설명과 도식은 새로 작성했으며 기술 주장은 공식 문서와 다시 대조했습니다. 링크는 Instagram 로그인이나 원 게시자의 공개 상태에 따라 나중에 열리지 않을 수 있습니다.

먼저 결론: 저장 버튼은 지식의 끝이 아니라 큐의 시작이다

짧은 기술 영상은 새로운 용어를 발견하고 코드의 움직임을 직관적으로 보는 데 유용하다. 하지만 저장 목록이 길어질수록 “언젠가 다시 볼 자료”는 검색하기 어려운 무제한 큐가 된다. 더 큰 문제는 30초 설명이 조건, 실패 경로, 운영 비용을 생략하기 쉽다는 점이다.

이번 정리의 목적은 모든 저장물을 요약하는 것이 아니다. 다시 쓸 만한 아이디어만 다음 네 칸으로 바꾸는 것이다.

1. 패턴: 어떤 문제 모양을 알아보기 위한 자료인가?
2. 불변조건: 정답이 되려면 끝까지 무엇이 참이어야 하는가?
3. 경계: 숏폼에서 생략된 전제와 실패 조건은 무엇인가?
4. 다음 행동: 구현, 벤치마크, 추가 조사 중 무엇을 할 것인가?

이 기준으로 보면 저장 목록은 북마크 창고가 아니라 알고리즘 → 애플리케이션 → 분산 시스템 → AI 호출로 이어지는 재방문 가능한 학습 지도다.

어떻게 379개를 118개 후보로 줄였나

로그인 세션에서 저장 목록에 표시된 379개 항목을 확인했다. 제목, 화면에 보이는 설명과 계정·주제 단서를 기준으로 coding, algorithm, graph, database, API, Kafka, Redis, distributed, security, AI 같은 기술 키워드 후보 118개를 추렸다. 이 숫자는 게시물 품질 점수나 통계 표본이 아니라, 당시 저장 목록을 사람이 다시 읽기 위한 탐색 단계다.

그다음 후보를 하나씩 검토하며 다음 항목은 제외했다.

• 코딩 화면이 있어도 실제 학습 포인트가 없는 밈·동기부여 영상
• 같은 개념을 거의 같은 방식으로 반복한 저장물
• 제품 홍보만 있고 재현 조건이나 실패 설명이 없는 항목
• “항상 더 빠르다”, “완벽히 한 번만 처리된다”처럼 조건 없는 과장
• 기술과 무관한 취미·일상·패션·음식 콘텐츠
• 이미 별도 글로 완성한 Big-O 중복 세 편

따라서 118은 발행할 글 수가 아니다. 아래 글은 그 후보에서 서로 연결되는 개념 묶음만 남긴 큐레이션이다. 원문을 대체하려는 요약도 아니며, 직접 링크는 아이디어가 시작된 위치를 추적하기 위한 provenance다.

보드는 각 주제를 “입력 → 상태 변화 → 경계 검사 → 결과”라는 같은 시간축에 놓는다. 재생을 멈추고 한 행씩 읽으면 알고리즘의 자료구조 선택과 백엔드의 압력 제어, AI 호출의 비용 제어가 사실 같은 질문을 반복한다는 점이 보인다. 무엇을 저장하고, 누가 다음 단계를 소유하며, 실패했을 때 어디서 멈출 것인가?

1. 알고리즘: 코드를 외우지 말고 상태를 그린다

괄호 검증과 DFS는 “나중에 돌아갈 상태”를 저장한다

괄호 검증 포스트의 핵심은 괄호 문자가 아니라 LIFO 불변조건이다. 여는 괄호를 스택에 넣고 닫는 괄호가 올 때 맨 위와 짝을 맞춘다. 중간에 짝이 맞지 않거나 끝에 스택이 남으면 실패다. 정답 조건을 “모든 문자를 읽었다”가 아니라 모든 prefix에서 닫힘이 열림을 추월하지 않고, 마지막에 미해결 열림이 없다로 쓰면 구현과 테스트가 함께 선명해진다.

DFS 포스트도 같은 자료구조 감각을 쓴다. 재귀 호출 스택이나 명시적 스택은 “이웃을 다 본 뒤 돌아갈 위치”를 기억한다. 그래프에서는 visited 집합이 없으면 cycle을 따라 끝없이 반복할 수 있다. 인접 리스트 기준 시간복잡도 O(V+E)는 각 정점과 간선을 제한된 횟수로 볼 때의 결과이지, 모든 재귀 코드가 저절로 선형이 된다는 뜻은 아니다.

Two Sum은 답보다 비용 모델을 비교하는 연습이다

Two Sum 포스트는 세 선택지를 비교하기 좋다.

“O(n)이 정답”이 아니라 입력 크기, 메모리 제한, 정렬 여부, 원 인덱스 요구가 선택을 결정한다. 숏폼을 오래 남는 지식으로 바꾸려면 코드 대신 이 비교표를 기억하는 편이 낫다.

행렬은 좌표계와 경계를 분리해서 읽는다

in-place 전치는 정사각 행렬에서 대각선을 기준으로 (i, j)와 (j, i)를 한 번만 바꾸는 문제다. 직사각 행렬은 같은 모양의 배열 안에서 단순 swap만으로 전치할 수 없으므로 “in place”라는 말에 입력 형상 조건이 붙는다.

나선 순회는 top, right, bottom, left 네 경계를 줄이는 상태 기계로 보면 쉽다. 행이나 열이 하나만 남았을 때 중복 방문하지 않도록 각 방향을 돌기 전 경계를 다시 검사해야 한다. 전치와 나선은 둘 다 행렬 문제지만, 하나는 좌표 변환, 다른 하나는 유효 영역 축소다.

최단 경로는 “더 영리한 알고리즘”보다 전제를 먼저 고른다

양방향 Dijkstra와 A* 포스트를 한 줄 순위표로 읽으면 위험하다.

• Dijkstra는 간선 가중치가 음수가 아닐 때, 현재까지 거리가 가장 작은 frontier를 확정한다.
• 양방향 탐색은 출발점과 목표점이 모두 알려져 있고 두 방향을 효율적으로 탐색할 수 있을 때 탐색 공간을 줄일 가능성이 있다. 종료 조건과 두 frontier의 결합 비용을 정확히 구현해야 한다.
• A*는 g(n)+h(n)을 사용한다. h가 실제 남은 비용을 과대평가하지 않는 admissible heuristic이면 최적성을 보존할 수 있지만, 나쁜 heuristic은 Dijkstra와 비슷해지거나 잘못된 종료 조건과 결합해 오답을 만들 수 있다.

즉 “A*가 항상 가장 빠르다”가 아니라 가중치 제약, 목표의 존재, heuristic 품질, 메모리 한도를 먼저 적어야 한다.

재귀에서 DP로, 정렬 이름에서 선택 기준으로

재귀·메모이제이션·tabulation 비교와 두 번째 Fibonacci 예시는 같은 recurrence라도 평가 전략이 비용을 바꾼다는 사례다. 순진한 Fibonacci 재귀는 같은 부분 문제를 반복한다. 메모이제이션은 top-down 호출 구조를 유지하며 결과를 저장하고, tabulation은 의존 순서를 정해 bottom-up으로 채운다. 둘 다 O(n)까지 줄일 수 있지만, tabulation은 필요한 마지막 두 값만 보존하면 공간도 O(1)로 줄일 수 있다.

정렬 변형 1과 정렬 변형 2는 알고리즘 이름을 늘리는 대신 다음 질문으로 남겼다.

• 안정 정렬이 필요한가?
• 최악 시간 상한이 중요한가, 평균 처리량이 중요한가?
• 입력이 거의 정렬됐는가, 키 범위가 제한됐는가?
• 추가 메모리와 외부 저장소 I/O를 얼마나 쓸 수 있는가?

비교 정렬의 이름만 외우는 것보다 데이터 분포와 운영 제약을 먼저 재는 편이 실전적이다.

2. 백엔드: 구성요소보다 경계와 압력을 설계한다

N+1을 eager loading 하나로 끝내지 않는다

N+1 포스트 1과 N+1 포스트 2가 가리키는 증상은 목록 한 번 뒤에 항목마다 추가 쿼리가 붙는 것이다. eager loading, join, batch loader가 왕복 횟수를 줄일 수 있지만 무조건 큰 join을 만드는 것도 답은 아니다. 행 곱셈, 중복 전송, pagination 왜곡, 사용하지 않는 열까지 함께 측정해야 한다.

connection pooling 포스트는 이 문제의 다음 경계를 보여준다. 풀은 무한 연결 생성 비용을 줄이는 캐시가 아니라 데이터베이스에 들어갈 동시 작업 수를 제한하는 admission control이다. PostgreSQL 공식 문서는 max_connections를 늘리면 shared memory를 포함한 자원 할당도 커진다고 설명한다. 따라서 풀 크기는 인스턴스 수를 곱한 전체 연결 예산, 쿼리 지연, timeout, 대기열 길이와 함께 정해야 한다. 풀이 가득 찼다면 더 많은 요청을 밀어 넣기보다 backpressure와 빠른 실패가 필요하다.

pub-sub, 작업 큐, consumer group, DLQ는 소유권이 다르다

pub-sub 대 queue에서 가장 중요한 질문은 “메시지를 몇 명이 보나?”보다 **완료 책임을 누가 가지나?**다.

• pub-sub은 같은 사건을 여러 독립 구독자가 각자 관찰하는 fan-out에 적합하다.
• 작업 큐는 보통 한 작업을 한 worker가 소유해 완료하도록 분배한다.
• Kafka consumer group은 topic partition을 group 안 소비자에게 배정한다. 순서는 전체 topic이 아니라 partition 안에서 보장된다.
• DLQ 포스트의 dead-letter queue는 실패를 없애는 장소가 아니라 자동 재시도가 더는 안전하지 않은 메시지를 격리해 조사·수정·재처리하는 운영 경계다.

재시도에는 횟수 상한, backoff와 jitter, 오류 분류, idempotency key가 필요하다. 영구적인 schema 오류를 무한 재시도하면 poison message 하나가 처리량을 소진한다. DLQ를 만들고 아무도 보지 않는 것도 유실과 다르지 않으므로 유입률, 체류 시간, replay 결과에 소유자와 알람을 둔다.

cache, rate limit, circuit breaker는 서로 대신할 수 없다

Redis 캐시 포스트는 cache-aside로 읽는 것이 안전하다. 애플리케이션이 먼저 cache를 보고 miss면 원본 DB를 읽어 TTL과 함께 채우며, 쓰기 뒤에는 key를 무효화한다. 캐시는 원본이 아니고 TTL은 정합성 보장이 아니라 stale window의 상한이다. hot key 만료 시 stampede가 생길 수 있으므로 single-flight, TTL jitter, 조기 refresh도 검토한다.

rate limiting은 과도한 호출을 예산 안으로 제한하고, circuit breaker는 이미 실패 중인 downstream에 계속 부하를 보내지 않도록 회로를 연다. cache는 반복 읽기 비용을 줄이고, rate limiter는 입구를 제어하며, circuit breaker는 실패 전파를 끊는다. 세 개를 “성능 기능” 하나로 묶으면 관측 지표와 실패 대응이 흐려진다.

sharding, replication, leader election은 확장 기능이 아니라 데이터 권한 계약이다

sharding은 key space의 소유권을 나눈다. 좋은 shard key는 분포뿐 아니라 함께 조회할 데이터, 재샤딩 비용, hot tenant를 고려한다. replication은 같은 데이터를 여러 곳에 복사하지만 복제 지연, 읽기 일관성, write acknowledgement 정책을 새로 만든다.

leader election은 “리더 한 명을 고르는 알고리즘”에서 끝나지 않는다. 오래된 리더가 다시 쓰지 못하도록 term/epoch나 fencing token이 필요하다. PostgreSQL failover 문서도 이전 primary가 자신이 더는 primary가 아님을 알게 하는 장치가 없으면 두 노드가 모두 primary라고 믿어 데이터 손실을 일으킬 수 있다고 경고한다.

DB deadlock 포스트는 단일 DB 안에서도 권한 순서가 중요하다는 축소판이다. PostgreSQL은 deadlock을 감지해 한 transaction을 중단하지만 어느 쪽이 중단될지 의존해서는 안 된다. 여러 객체의 lock을 일관된 순서로 획득하고, 중단된 transaction은 side effect가 안전한 범위에서 재시도해야 한다.

3. 짧은 주장에 붙여야 할 교정표

이 표의 공통점은 기술 A와 B를 승자 결정전으로 보지 않는 것이다. API 스타일, 데이터 모델, 전달 보장, 보안 토큰은 서로 다른 층에 있으며 한 선택이 다른 층의 책임을 지워주지 않는다.

4. AI와 창작 기술: 구현 큐와 관찰 큐를 분리한다

AI rate limit·token budget 포스트는 보드의 마지막 행처럼 수명주기로 남겼다.

1. 요청 전에 입력 크기와 최대 출력 token 예산을 계산한다.
2. 긴 공통 prefix가 있다면 prompt cache hit 조건을 맞추고 실제 cached_tokens를 본다.
3. concurrency와 request/token rate를 함께 제한한다.
4. timeout, 취소, 비용, model·prompt version을 trace에 기록한다.
5. 429나 일시 오류만 제한된 횟수로 exponential backoff + jitter 재시도한다. 실패 요청도 rate budget을 쓸 수 있으므로 무한 재시도하지 않는다.

나머지는 당장 사실로 채택하기보다 watchlist로 분리했다.

• GraphRAG 포스트: graph construction 비용이 multi-hop retrieval 품질을 실제로 올리는지, 단순 hybrid retrieval과 같은 평가셋에서 비교한다.
• FAISS를 경매 탐색에 쓴 포스트: approximate nearest-neighbor recall, index build/update 비용, business constraint를 별도 측정한다. 벡터 유사도가 최종 ranking rule을 대신한다고 가정하지 않는다.
• 수식을 소리로 바꾸는 창작 포스트: mapping 규칙, 시간축, normalization을 공개해야 같은 수식이 같은 소리로 재현되는지 확인할 수 있다.
• Ghidra 포스트: 합법적으로 소유하거나 분석 권한이 있는 binary에 한해 호출 그래프, 문자열, decompiler 가설을 학습한다. decompiled C를 원본 source로 오인하지 않는다.

watchlist의 승격 조건은 “흥미롭다”가 아니라 작은 재현 실험, 비교 기준, 실패 사례가 생겼는가다.

5. 다시 볼 때의 실행 순서

이렇게 정리하면 “저장한 것을 다 봐야 한다”는 부담이 사라진다. 저장물은 완독 목록이 아니라 질문을 발견하는 inbox이고, 이 글은 그중 재사용 가능한 질문만 공식 근거와 실행 조건을 붙여 보관한 archive다.

대표 Instagram 원문 인덱스

링크는 아이디어 provenance를 위한 것이며 원본 표현을 복제하지 않는다.

• 알고리즘: stack, DFS, Two Sum, transpose, spiral matrix, Dijkstra·A*, Fibonacci 1, Fibonacci 2, sorting 1, sorting 2
• 백엔드: N+1 1, N+1 2, pooling, pub-sub·queue, DLQ, Redis cache, rate limit, circuit breaker, Kafka consumer groups
• 분산·보안: sharding, replication, leader election, deadlock, GraphQL·REST, SQL·NoSQL, exactly-once, TLS, cookies·JWT
• AI·창작: prompt caching, token budget·rate limit, GraphRAG, FAISS, equations to sound, Ghidra

교정에 사용한 공식 1차 출처

• IETF, RFC 8446: TLS 1.3
• IETF, RFC 6265: HTTP State Management Mechanism
• IETF, RFC 7519: JSON Web Token
• GraphQL Foundation, Thinking in Graphs 및 Serving over HTTP
• Apache Kafka, Design: message delivery semantics and transactions
• PostgreSQL, Connections and max_connections, Deadlocks, Replication, Failover
• Redis, Cache-aside
• OpenAI, Prompt caching 및 Rate limits

마지막 원칙

소셜 피드는 발견을 잘하고 공식 문서는 경계를 잘 설명한다. 둘 중 하나만으로는 부족하다. 저장한 포스트에서 질문을 얻되, 설계 결론은 불변조건·실패 경로·측정값·1차 문서로 다시 세운다. 그래야 링크가 사라져도 학습 결과는 남고, 다음에 같은 문제를 만났을 때 실제로 꺼내 쓸 수 있다.