SQL 코딩테스트를 풀다 보면 로직이 완벽함에도 불구하고 결과가 아예 나오지 않는(Empty Set) 현상을 마주할 때가 있다. 특히 서브쿼리와 함께 NOT IN을 사용할 때 이 현상이 자주 발생하는데, 그 원인은 바로 데이터베이스의 3값 논리(Three-Valued

알고리즘 문제를 풀다가 SQL을 처음 접하면 가장 당황스러운 순간이 바로 "값을 직접 비교하고 대입하는 과정(할당, =)이 없다"는 점이다.C++, Python, Java와 같은 언어에서는 for문으로 배열을 순회하며 if-else로 값을 변수에 대입하는 절차적(Imp

코딩 테스트에서 빈번하게 등장하는 '데이터 집계'와 '정렬 조건 최적화' 문제를 다뤄보았습니다. 단순한 빈도수 계산을 넘어, 동일 빈도 시 등장 순서(우선순위)를 보장해야 하는 엣지 케이스를 해결하는 것이 핵심입니다.여러 개의 플레이리스트 배열이 주어질 때, 다음 규칙

SQL 문제 해결 회고프로그래머스 '조건에 맞는 개발자 찾기' 문제를 풀며, 일반적인 외래키(FK) 매핑이 아닌 비트 연산(Bitwise Operation)을 통한 조인 기법을 학습했다. 더 나아가, JOIN 연산 시 필연적으로 발생하는 '1:N 데이터 증식(뻥튀기)'

최적화 철학 회고SQL 문제를 풀면서, 무거운 그룹화(GROUP BY) 연산을 수행하기 전에 필터링(WHERE)을 먼저 걸어두는 것이 연산 속도 측면에서 압도적으로 이득일 것이라 판단했다. 이 생각은 데이터베이스 최적화 관점에서 100% 정답이었다. 하지만 놀라운 점은

SOP (Standard Operating Procedure) 수립 회고알고리즘 문제를 풀 때마다 플랫폼(백준 vs 프로그래머스)의 입출력 방식 차이로 코드가 꼬이는 것을 막기 위해, 나만의 범용 보일러플레이트(Boilerplate) 템플릿을 구축했습니다. 더 나아가,

SOP (Standard Operating Procedure) 수립 회고백준(BOJ)과 프로그래머스는 입출력 환경이 완전히 다릅니다. 백준은 날것의 문자열을 직접 파싱해야 하고, 프로그래머스는 정제된 매개변수를 던져줍니다. 이 두 플랫폼 사이에서 코드를 짤 때마다 헷갈

학습 철학 회고알고리즘 템플릿을 무작정 외우는 것을 경계하며, 뼈대 코드의 아주 사소한 '초기화 값' 하나까지 극한으로 의심해 보았습니다. "왜 뻔히 더할 첫 번째 값을 놔두고 0으로 시작해서 덧셈 연산을 한 번 낭비하는가?"에 대한 답을 치열하게 고민했고, 그 결과

학습 철학 회고단방향으로 이동하는 '애벌레' 투 포인터에 이어, 정렬된 배열에서 양끝에서 마주 보며 좁혀오는 '양끝 교차 투 포인터'의 뼈대를 세웠습니다. 특히 "왜 지나온 포인터를 다시 되돌려보지 않아도 모든 경우의 수를 보장하는가?"에 대한 수학적 의심을 품고, 탐

학습 철학 회고10만 개의 데이터가 주어졌을 때, 부분 연속 수열의 합을 구하려고 이중 for문($O(N^2)$)을 돌리면 100억 번의 연산이 발생하여 무조건 시간 초과가 납니다. 이때, 두 개의 포인터(손가락)를 사용하여 배열을 단 한 번만 스캔($O(N)$)하고

학습 철학 회고본격적인 알고리즘 딥 워크(CPU Overclocking)에 들어가기 전, 뇌를 예열(Cache Loading)하기 위해 가장 기본적이고 순수한 형태의 이분 탐색 뼈대를 백지에서 구현해 보았습니다. 어제 학습한 '파라메트릭 서치(Parametric Sea

학습 철학 회고단순히 주어진 배열에서 숫자를 찾는 것을 넘어, "적어도 M미터의 나무를 집에 가져가기 위해 절단기에 설정할 수 있는 높이의 최댓값"을 구하는 최적화 문제를 만났습니다. 이를 해결하기 위해 이분 탐색을 응용한 '파라메트릭 서치(Parametric Sear

학습 철학 회고이전에 '다익스트라 완벽 해부' 포스팅에서 정리했던 특정 문제에 종속되지 않은 '순수한 다익스트라 뼈대(Template)'를 꺼내어, 실제 코딩 테스트 환경(백준 1753번)의 요구사항에 맞춰 조립해 보는 실전 훈련을 진행했습니다. 머릿속의 추상화된 논리

학습 철학 회고그래프 알고리즘 중 최소 신장 트리(MST)를 구하는 크루스칼 알고리즘은 '그리디'와 '자료구조'의 완벽한 융합체입니다. 복잡한 2차원 간선 배열을 BFS로 힘들게 탐색하는 대신, 1차원 부모 배열을 활용한 '유니온 파인드(Union-Find)'의 우아한

학습 철학 회고그리디 알고리즘은 직관적으로 풀기 쉽다는 함정이 있습니다. "그냥 지금 제일 좋아 보이는 걸 고르면 되는 거 아니야?"라는 생각으로 접근하다가 수많은 반례(Edge Case)에 부딪혀 무너지곤 합니다. 이번에는 감각에 의존하는 코딩을 멈추고, '탐욕'이

학습 철학 회고다이나믹 프로그래밍(DP)은 번뜩이는 천재성을 요구하는 퍼즐이 아닙니다. 복잡하고 거대한 문제를 '완벽하게 똑같은 구조를 가진 아주 작은 문제'로 쪼개고, 그 작은 문제들의 정답을 메모장에 적어두었다가 재활용하는 철저한 메모의 기술입니다. 수학의 점화식을

학습 철학 회고단순히 배열에서 숫자를 빨리 찾는 기법으로만 이분 탐색을 외우면, 정작 코딩 테스트의 꽃인 '파라메트릭 서치(Parametric Search)' 응용 문제를 풀지 못합니다. 탐색 공간을 반으로 접어 나간다는 본질적 철학과, left와 right 포인터가

학습 철학 회고실전에서 itertools를 쓰면 한 줄에 끝날 문제라도, 그 이면에 숨겨진 '상태 공간 트리(State Space Tree)'의 작동 방식을 뼛속까지 이해해야 복잡한 제약 조건이 걸린 시뮬레이션 문제를 통제할 수 있습니다. 모든 가능한 경우의 수를 전부

학습 철학 회고단순히 미로를 찾고 단지에 번호를 붙이는 1차원적인 풀이를 넘어, '그래프를 남김없이 탐색한다'는 본질적 목표를 어떻게 코드로 추상화할 것인지 고민했습니다. 특정 조건에 휘둘리지 않는, DFS와 BFS의 가장 순수하고 일반화된 뼈대(Skeleton)를 세

학습 철학 회고 특정 문제의 꼬인 조건에 맞춰진 코드를 달달 외우는 것은 융통성을 잃게 만듭니다. 알고리즘의 본질을 '언어'로 먼저 이해하고, 그것을 순수한 템플릿으로 추상화한 뒤, 실전 문제의 요구사항에 맞춰 조립하는 '설계 주도형 사고(SOP)'를 다익스트라 알고리