왜 사람들은 “F*** LeetCode”라고 말할까: 난이도, 공정성, 실제 가치 — 그리고 더 나은 방법
Source: Dev.to
왜 이렇게 많은 똑똑한 엔지니어들이 이렇게 느낄까?
불만은 단순한 배출이 아니라, 준비 루프와 면접 평가가 맞지 않을 때 나타나는 패턴이다.
- 지표 불일치 – 당신은 해결한 개수와 연속 streak 로 진행 상황을 추적하지만, 면접관은 명료성, 적응력, 시간 압박 속에서의 엣지‑케이스 처리를 중시한다. 두 가지가 갈라지면 몇 주간의 고생이 물에 떠다니는 느낌이 된다.
- 기억 감퇴 – 화요일에 문제를 풀고 금요일에 잊어버리는 것은 성격 결함이 아니라, 구조화된 노트와 간격 복습 없이 뇌가 작동하는 방식이다.
- 면접의 사회적 특성 – 제약을 설명하고, 트레이드‑오프를 정당화하며, 실수를 인정하고, 대화를 이끌어야 한다. 혼자서만 연습하면 그 근육을 키우지 못한다.
- 컨텍스트‑스위치 과부하 – 프롬프트를 복사‑붙여넣고, 로그를 뒤섞고, 탭을 오가면 작업 기억이 소모돼 필요한 세부 사항이 사라진다.
- 잘못된 자기 의심 – 신뢰성 있는 시스템을 배포하면서 억지 DP 트위스트에 걸리면 “내가 이거에 맞지 않는다”는 생각이 들지만, 실제 격차는 고통을 유지하면서 피드백을 늘려주는 준비 루프에 있다.
인지된 난이도: 간단한 공식
Difficulty = Novelty Load + Time Pressure + Feedback Delay
| 구성 요소 | 의미 |
|---|---|
| Novelty Load | 익숙한 패턴이 새로운 트위스트(예: 카운팅 제약에 숨겨진 슬라이딩‑윈도우) 뒤에 숨겨져 있다. |
| Time Pressure | 시계가 작업 기억을 압축한다; 지름길이 막다른 길이 된다. |
| Feedback Delay | 빠른 확인이 없으면 스스로 의심하거나 과도하게 설계하게 된다. |
새로움을 줄이고(패턴을 힌트로 제공), 시계를 제어하며(부드러운 타임박스), 피드백 루프를 단축하면(초기에 적대적 테스트 생성) 같은 문제를 대략 두 배는 쉽게 느낄 수 있다—문제를 낮추는 것이 아니라.
알고리즘 라운드의 공정성 및 유용성
| 기준 | 질문 |
|---|---|
| 내용 타당성 | 과제가 실제 업무에서 사용하는 기술(불변식, 복잡도 감각, 엣지‑케이스 위생)을 샘플링하고 있는가? |
| 구성 요소 커버리지 | 추론과 커뮤니케이션을 평가하고 있는가—아니면 스트레스 하에서의 기억력만을 보는가? |
| 신뢰도 | 두 명의 평가자가 동일한 수행을 비슷하게 점수화할 수 있는가(구조화된 루브릭, 기준 예시)? |
| 불리한 영향 | 시험‑전략 트릭을 진정한 엔지니어링 판단보다 우대하고 있지는 않은가? |
| 게임 가능성 vs. 투명성 | 준비는 도움이 되지만, 유일한 길이 수개월간의 기계적 패턴 암기가 되어서는 안 된다. |
잘 설계된 알고리즘 라운드는 휴대 가능한 신호를 만든다: 상태를 깔끔히 표현하고, 불변식을 유지하며, 제약 하에서 트레이드‑오프를 고민하는 능력. 이는 실제 업무에서 레이트‑리미터, 스케줄러, 스트림 윈도우, 의존성 그래프, 제한된 캐시 등으로 나타난다. 반대로 형편없이 설계되면 퀴즈, 함정, “500개의 미디엄을 외워라”는 소규모 산업이 된다.
흔한 패턴군의 실제 가치
| 패턴군 | 전형적인 프로덕션 활용 |
|---|---|
| 해시맵 / 집합 | 중복 제거, 조인, 멤버십 검사, 캐시 키, 멱등성 |
| 슬라이딩 윈도우 / 두 포인터 | 스트림 분석, 롤링 레이트 리밋, 윈도우 집계 |
| 힙 & 인터벌 스윕 | 우선순위 스케줄링, Top‑K 쿼리, 방/슬롯 할당, 압축 패스 |
| 그래프 (BFS/DFS) | 의존성 해결, 서비스 네트워크 최단 경로, 권한/ACL 탐색, 워크플로 오케스트레이션 |
| 답 공간에 대한 이진 탐색 | 임계값 튜닝(SLO 예산, 백오프), 최소 가능한 용량 탐색 |
| 동적 프로그래밍 | 최적화, 가격 책정, 컴파일러/분석, 추천 엔진, 상태 + 전이 + 순서가 중요한 모든 도메인 |
예를 들어 “편집 거리”를 업무에서 직접 구현하지 않더라도, 상태 정의, 불변식 유지, 엣지 조기 테스트라는 사고 방식이 “개발 환경에서는 동작한다”와 “프로덕션에서 살아남는다”를 구분한다.
더 나은 학습 시스템 – FAITH 루프
고통(학습이 일어나는 곳)을 유지하면서 낭비되는 마찰을 줄이는 5단계 일일 루틴. 하루 60–90분을 투자한다.
F — 패밀리 찾기
패턴군을 식별하고 전략 수준 힌트를 얻는다(코드 없음).
예시: “증가/감소 윈도우?”, “레벨별 BFS?”, “답 공간에 대한 이진 탐색?”
A — 불변식 명시
코드를 쓰기 전에 핵심 불변식을 서술한다.
예시: “윈도우는 고유 문자만 포함”, “힙은 현재 k 후보를 보관”, “dp[i] = …까지의 최적”
I — 제한된 타이머 아래 구현
- 15분: 문제 프레이밍 / 첫 번째 시도.
- 막히면 하나의 구조 힌트(스캐폴드, 전체 문법 아님)를 사용.
- 총 45–50분; 이후 학습 모드로 전환.
T — 깨뜨리며 테스트
3–5개의 적대적 입력(중복, 빈값, 극단, 편향)을 생성하고 배치 실행, 첫 실패를 고치고 왜 실패했는지 기록한다.
H — 학습 정리
2분 동안 마이크로 노트를 작성한다:
Problem:
Approach:
Invariant:
Failure mode + fix:
노트를 10분 정도 식힌 뒤 검토한다.
주 1회 30분 모의(미디엄 1개, 쉬운 1개)를 추가한다. 목표는 “이기”가 아니라 약점(명료성, 속도, 엣지 처리)을 드러내고 다음 주 계획에 반영하는 것이다.
AI를 효과적으로 활용하기
좋은 활용법
- 점진적 힌트 – 전략 → 구조 → 체크포인트 질문; 코드 제공은 “사후 분석 모드”일 때만.
- 엣지 압박 – 까다로운 입력을 생성해 한 번에 실행, 버그를 조기에 발견.
- 시각화 – 텍스트가 실패할 때 30초 정도 콜스택이나 포인터 타임라인을 그려 보기.
- 리콜 – 마이크로 노트를 자동 생성하고 재노출 일정 잡아 오늘의 노력이 다음 주까지 살아남게 함.
- 성능 연습 – 피드백(명료성, 접근법, 정확성)과 점수 분해가 포함된 모의 면접.
나쁜 활용법
- 연습 중 코드 직접 요청.
- 실행·테스트·시각화 없이 끝나는 끝없는 대화.
- 너무 길어 절대 다시 읽지 않을 노트.
원칙: AI에게 피드백을 저렴하게 만들게 하라, 생각 자체를 선택 사항으로 만들지는 마라.
샘플 주간 리듬 (FAITH 중심)
| 요일 | 포커스 | 작업 |
|---|---|---|
| 월 | 배열 / 문자열 | 전략 힌트만 2문제; 배치 엣지 테스트; 포인터 시각화; 마이크로 노트 |
| 화 | 해시맵 + 슬라이딩 윈도우 | 2문제 – 불변식을 소리 내어 말하기 |
| 수 | 연결 리스트 + 단조 스택 | 2문제 – 포인터/스택 스냅샷; 실패 1개 로그 |
| 목 | 힙 & 인터벌 | 2문제 – 스윕 라인 + 최소 힙; 경계 공유 엣지 테스트 |
| 금 | 그래프 | 2문제 – 방문 의미를 가진 BFS 레벨; 큐 경계 시각화 |
| 토 | 답 공간에 대한 이진 탐색 | 2문제 – P(mid) 정의; 진리표; 오프‑바이‑원 방어 |
| 일 | 가벼운 DP | 2문제 – 상태/전이/순서 문장; 2D 테이블 채우기 다이어그램 |
| 매일 | 빠른 설명 | 고무오리 혹은 AI에게 90초 동안 “문제와 접근법 설명” |
매일 FAITH 루프를 고수하고, AI를 피드백 스캐폴드로 활용하면 “F*** LeetCode” 좌절을 지속 가능하고 고효율적인 학습 습관으로 바꿀 수 있다.