알고리즘 공부, 실무에서 진짜 쓰이나?

개발자 현직자 솔직 경험담

알고리즘 공부,
실무에서 진짜 쓰이나?

3년 동안 실무 코드를 짜면서 직접 답을 찾아봤다

Frontend Developer 2026년 6월 약 13분 읽기

취준생 때 가장 많이 들었던 논쟁

알고리즘 공부가 필요한지 아닌지에 대한 논쟁은 개발자 커뮤니티에서 가장 오래된 주제 중 하나다. "실무에서 BFS 쓸 일이 없다"는 파와 "알고리즘을 모르면 코드를 제대로 못 짠다"는 파가 팽팽하다. 취준생 때 나는 이 논쟁을 보면서 "그래서 어쩌라고"라는 생각이 들었다. 어차피 코딩테스트가 있으니 해야 했고, 해도 되는지 안 되는지는 나중에 알 수 있을 테니까.

그리고 지금, 프론트엔드 개발자로 3년이 조금 넘게 일하면서 — 스타트업 2년, 프리랜서 1년 — 그 질문에 대한 나만의 답이 생겼다. "쓰인다, 근데 생각한 것과 다른 방식으로"가 그 답이다. 이 글은 그 "다른 방식"이 뭔지에 대한 이야기다.

알고리즘 공부

📌 이 글의 전제

Next.js, TypeScript, React 기반 프론트엔드 개발 관점이다. 백엔드나 알고리즘 집약적인 도메인(게임, 데이터 파이프라인 등)은 다를 수 있다. 같은 개발자라도 도메인에 따라 체감이 완전히 다를 수 있으므로 참고해서 읽어주시길.

먼저 솔직하게 — 코딩테스트 수준의 알고리즘은 거의 안 썼다

백준 골드 수준의 DP 문제를 실무에서 만난 적은 없다. 다익스트라를 직접 구현한 적도 없고, 세그먼트 트리가 필요했던 적도 없다. Next.js로 컴포넌트 만들고, API 연결하고, 상태 관리하는 일을 하면서 그 수준의 알고리즘을 꺼낼 일이 거의 없었다.

이걸 솔직하게 인정하고 시작해야 한다. "알고리즘 공부가 실무에서 도움이 됐다"고 말하는 사람들 중 상당수는 무의식적으로 과장하거나, 알고리즘의 범위를 넓게 잡아서 말하는 경우가 많다고 생각한다. 어디서나 "결국 다 연결된다"는 말은 사실이기도 하고 면피이기도 하다.

LeetCode Hard를 실무에서 구현할 일은 없었다. 그런데 알고리즘 공부가 쓸모없었냐고 묻는다면 — 그것도 아니었다. 쓸모의 모양이 달랐다.

그런데 이런 순간들이 있었다

01

실무 사례 1

중첩 카테고리 메뉴 렌더링 — 트리 순회

쇼핑몰 프로젝트에서 카테고리 메뉴를 만들었다. 대분류 → 중분류 → 소분류, 깊이가 최대 4단계였다. API에서 flat 배열로 데이터가 왔고, 이걸 중첩 구조로 변환해서 렌더링해야 했다.

처음엔 그냥 중첩 for문으로 짰다. 동작은 했지만 카테고리 수가 늘어날수록 느려지는 게 느껴졌다. 알고리즘 공부하면서 익혔던 트리 구조와 재귀를 떠올렸다. parentId를 기준으로 Map을 먼저 만들고, 거기서 트리를 구성하는 방식으로 O(n)으로 바꿨다. 그 차이가 카테고리 300개짜리 메뉴에서 체감됐다.

✅ flat 배열 → 트리 구조 변환 — O(n²) vs O(n)

// ❌ 처음에 짠 방식 — O(n²), 카테고리 많아지면 느려짐 function buildTreeSlow(items: Category[], parentId = null) { return items .filter(item => item.parentId === parentId) .map(item => ({ ...item, children: buildTreeSlow(items, item.id) // 매번 전체 순회 })) } // ✅ Map 기반으로 개선 — O(n), 알고리즘 공부의 직접 적용 function buildTreeFast(items: Category[]) { const map = new Map(items.map(i => [i.id, { ...i, children: [] }])) const roots: CategoryNode[] = [] for (const item of map.values()) { if (item.parentId === null) { roots.push(item) } else { map.get(item.parentId)?.children.push(item) } } return roots }

02

실무 사례 2

검색 자동완성 디바운스 + 캐시 — 해시맵

검색 자동완성 기능을 만들면서 같은 키워드를 두 번 검색하면 API를 다시 부르지 않도록 캐싱을 구현했다. 간단한 Map 기반 캐시였는데, 캐시 크기 제한을 걸면서 LRU(Least Recently Used) 정책을 적용해야 했다.

LRU는 코딩테스트에서 꽤 자주 나오는 유형이다. 그걸 알고 있었기 때문에 Map과 연결 리스트 구조를 떠올릴 수 있었고, 직접 구현하지는 않았지만 어떤 자료구조가 이 문제에 적합한지 바로 떠올렸다. 모르는 사람은 그냥 배열로 짜고 O(n)으로 남겼을 것이다.

03

실무 사례 3

무한 스크롤 중복 데이터 제거 — Set

무한 스크롤 페이지네이션에서 API 응답 타이밍 이슈로 같은 아이템이 두 번 오는 경우가 있었다. 페이지가 바뀌는 타이밍에 race condition이 생기면서 중복이 들어왔다.

Set으로 id를 추적해서 중복을 제거하는 걸 5분 만에 짰다. 알고리즘 공부하면서 Set과 Map의 시간복잡도 차이를 익혔기 때문에 배열의 includes() 대신 Set을 선택하는 게 자연스러웠다. 아이템 수가 늘어날수록 이 차이가 성능에 영향을 준다는 걸 알고 있었으니까.

04

실무 사례 4

의존성 그래프 정렬 — 위상 정렬 발상

사이드 프로젝트에서 여러 단계의 설문 폼을 만들었다. 각 단계가 특정 이전 단계의 답변에 의존해서 순서가 있었고, 사용자가 임의로 단계를 건너뛰거나 되돌아갈 수 있었다. 어떤 단계가 완료됐을 때 어떤 단계가 잠금 해제되는지 계산해야 했다.

이건 정확히 위상 정렬 문제였다. 코딩테스트에서 봤던 "선수 강의 완료 후 다음 강의 수강 가능" 유형과 같은 구조였다. 알고리즘 공부를 안 했다면 이 문제를 어떻게 풀었을지 모르겠다. 아마 복잡한 중첩 조건문으로 짰을 거고, 케이스가 늘어날수록 버그가 터졌을 거다.

직접 구현한 게 아니라 '발상'이 쓰였다

위 네 가지 사례의 공통점이 있다. 알고리즘을 교과서 그대로 구현한 게 아니었다. 알고리즘을 공부하면서 익힌 "이런 상황엔 이런 구조가 맞다"는 발상이 실무 문제에 적용됐다.

트리 순회를 달달 외운 게 쓰인 게 아니라, "이건 트리 문제구나"를 인식하는 감각이 쓰였다. LRU를 구현한 코드가 실무에 들어간 게 아니라, "이 상황에서 어떤 자료구조가 맞는지"를 떠올리는 배경지식이 쓰였다.

알고리즘이 실무에서 쓰인다는 건, 코드를 그대로 가져다 쓴다는 게 아니다. 문제를 보는 방식이 달라진다는 것이다.

알고리즘 공부의 실무 기여도 — 솔직한 평가

알고리즘 유형별 실무 활용 빈도 (프론트엔드 기준)

자료구조 (Map, Set, 배열)

 

매우 높음

재귀 / 트리 순회

 

높음

시간복잡도 감각

 

높음

정렬 알고리즘 이해

 

보통

BFS / DFS

 

가끔

DP (동적 프로그래밍)

 

드묾

고급 그래프 알고리즘

 

거의 없음

알고리즘 / 개념	실무 활용	활용 방식
Map, Set, 해시 기반 탐색	매우 높음	중복 제거, 캐싱, 빠른 조회
시간복잡도 O(n), O(log n) 감각	높음	코드 리뷰, 성능 최적화 판단
재귀 / 트리 구조	높음	메뉴 렌더링, 댓글 구조, 폴더 트리
정렬 알고리즘 이해	보통	sort() 안정성, 커스텀 정렬 구현
BFS / DFS 발상	가끔	의존성 탐색, 폼 단계 관계 파악
동적 프로그래밍	드묾	메모이제이션 개념 정도
골드 이상 난이도 알고리즘	거의 없음	프론트엔드에서 직접 구현 경험 없음

알고리즘 공부가 남긴 진짜 유산

🧩

문제를 추상화하는 능력

실무 문제를 "이건 그래프 문제다", "이건 슬라이딩 윈도우 느낌이다"라고 패턴으로 인식하는 능력. 이게 생기면 해결 방향이 빨리 보인다.

⏱️

시간복잡도 감각

코드 리뷰에서 "이 부분 O(n²)인데 데이터 많아지면 느려져요"라고 말할 수 있는 것. 알고리즘 안 배웠으면 이런 시각 자체가 없었을 것이다.

📦

자료구조 선택 기준

배열 대신 Set, 객체 대신 Map을 언제 써야 하는지 이유를 알고 선택하는 것. "그냥 되니까"와 "이래서 이게 맞으니까"는 코드 품질이 다르다.

🔍

엣지 케이스 발견 습관

알고리즘 문제에서 항상 엣지 케이스를 고려하는 훈련이 됐다. 빈 배열, null, 최댓값 — 실무 코드를 짤 때도 이게 자동으로 작동한다.

💬

기술 면접 공통 언어

알고리즘 공부를 한 사람들끼리는 "이건 O(n log n)이고, 이 부분이 병목이에요"가 통한다. 팀에서 기술 토론할 때 공통 언어가 생기는 것의 가치는 생각보다 크다.

🧠

논리적 사고 훈련

알고리즘을 풀면서 단계별로 논리를 전개하는 훈련이 된다. 이게 버그를 추적하거나 복잡한 로직을 설계할 때 그대로 나온다.

그렇다면 얼마나, 어디까지 공부해야 하나

취준 중이라면 코딩테스트는 피할 수 없다. 하지만 현직자 입장에서 "실무를 위해 알고리즘을 더 깊게 파야 하나"는 질문을 자주 받는다. 솔직하게 답하면 — 프론트엔드 기준으로 골드 이상의 문제를 꾸준히 풀 필요는 없다. 그 시간에 프로젝트를 하거나 공식 문서를 더 읽는 게 실무에 더 직접적으로 도움이 된다.

그렇지만 기본기는 흔들리면 안 된다. 자료구조의 시간복잡도, 재귀의 동작 방식, 정렬의 안정성 — 이 수준은 현직자도 언제든 꺼낼 수 있어야 한다고 생각한다.

Silver 프론트엔드 취업 최소 목표

Gold 대부분 기업 코테 커버

Platinum+ 네카라쿠배 수준 필요

기본기 현직 중에도 유지 필요

💡 현직자 기준 알고리즘 유지 방법

주 1~2회 실버~골드 문제 하나씩 푸는 것으로 충분하다. "녹슬지 않는" 수준을 유지하는 게 목표다. 알고리즘 풀이보다 코드 리뷰, 공식 문서, 프로젝트에 더 많은 시간을 쓰는 게 현직자 성장에는 맞다.

결론 — "쓰인다"는 맞는 말이지만, 기대와 다르다

알고리즘 공부가 실무에서 쓰이냐는 질문에 대한 내 답은 "그렇다, 하지만 코딩테스트처럼 쓰이지 않는다"이다. 실무에서 DFS를 교과서대로 구현하는 일은 거의 없다. 그런데 "이 문제가 DFS 구조로 생각하면 풀린다"는 발상이 떠오르는 사람과 아닌 사람의 코드는 다르다.

알고리즘 공부의 진짜 가치는 코드가 아니라 사고방식이다. 문제를 구조로 보는 눈, 시간복잡도를 떠올리는 습관, 자료구조를 선택하는 기준 — 이게 남는다. 그리고 이게 3년 동안 내 코드를 조금씩 다르게 만들어왔다고 생각한다.

취준생이라면 코딩테스트를 위해 당연히 해야 한다. 현직자라면 기본기가 녹슬지 않을 정도로 유지하면 충분하다. "알고리즘이 실무에서 전혀 안 쓰인다"는 말은 틀렸고, "알고리즘만 잘하면 좋은 개발자다"는 말도 틀렸다. 그 사이 어딘가에 답이 있다.

✅ 알고리즘 공부에 대한 현직자의 최종 입장

기초 자료구조와 시간복잡도는 현직 중에도 알고 있어야 한다. 코딩테스트 수준 이상의 고난도 알고리즘은 도메인에 따라 다르지만, 프론트엔드 기준으로는 기본기 위에 프레임워크·아키텍처 이해가 더 중요하다. 알고리즘을 공부하되, 그게 전부가 되면 안 된다.

---

3년 전 새벽에 백준 문제를 붙잡고 있던 내가 이 글을 읽는다면 뭘 느낄까 생각해봤다. "괜히 한 게 아니었구나"라고 할 것 같다. 그리고 동시에 "근데 포트폴리오 프로젝트를 진작에 더 깊게 만들었어야 했다"고도 할 것 같다. 두 가지가 다 맞다.

💬 알고리즘 공부, 실무에서 어떻게 느끼셨나요?

취준 중에 알고리즘을 공부하면서 느낀 것, 혹은 현직에서 실제로 알고리즘이 쓰였던 경험이 있다면 댓글로 나눠주세요. 백엔드, 프론트엔드, 데이터 분야별로 체감이 많이 다를 것 같아 다양한 경험이 궁금합니다.