알고리즘을 공부하면서 깨달은 점.zip

코딩테스트를 준비하기 위해 알고리즘을 꾸준히 풀어보면서 이런 생각을 하게 됐다.

- 이게 왜 개발자한테 필요할까?

- 이걸 실제 개발에서 사용할 수 있을까?

 

프론트엔드와 백엔드를 모두 경험해 봤지만, 실제 서비스 개발에서는 단순히 API 연결, UI 개발, DB 설계처럼 눈에 보이는 구현이 대부분이었다.

 

그런데 알고리즘 문제들을 풀다가 실제 서비스 설계나 성능 최적화에 동일하게 쓰일 수 있다는 사실을 깨달았다.

그리고 문제를 구조적으로 분석하는 사고방식을 키우는 것이 중요하단 점을 느꼈다.

 

이번 글에는 알고리즘을 공부하면서 실제 개발과 연결해 이해했던 내용을 정리해보고자 한다.

 

 

1. 성능과 속도를 결정하는 기반이다

동일한 기능이라도 어떤 알고리즘을 선택하느냐에 따라 성능은 극적으로 달라진다.

 

예를 들어 가장 대표적인 것이 길찾기 알고리즘이다.

 

길 찾기 문제에서 가장 기본적으로 사용되는 알고리즘은 다익스트라 알고리즘이다.

-> 각 노드를 방문할 때 현재까지의 최단 비용을 유지하면서 불필요한 탐색을 하지 않도록 설계된 알고리즘이기 때문이다.

 

반대로, 다익스트라를 모르는 상태에서 완전탐색으로 길찾기를 한다면 어떻게 될까를 고민해 봤다.

- 가능한 모든 경로를 전부 탐색

- 경로의 수는 그래프 크기가 조금만 커져도 기하급수적으로 증가

-> 즉, O(노드수 ^ 경로길이) 수준의 비현실적인 연산량이 된다.

 

 

또한, 데이터 규모가 작을 때는 성능 차리를 체감하기 어렵다.

 

팀 프로젝트를 진행할 때는 보통 1,000건, 10,000건 정도의 데이터를 다뤘다.

이 정도면 사실 O(n²)이라도 그냥 돌아가는 규모다. JOIN이 여러 개 있어도 눈에 띄게 느려지지 않는다.

-> 작은 규모에서는 비효율적인 알고리즘도 성능이 버텨준다.

 

그렇지만, 실제 기업들은 1억, 10억 건, 매일 수백만 건씩 쌓이는 데이터, .. 이런 규모가 디폴트값이다.

그렇기 때문에 작은 규모에서는 티가 안 나던 알고리즘 차이가 실제 서비스에서는 엄청난 성능 차이로 드러나게 된다.

 

첫 개발 프로젝트에서 DB 설계를 할 때 '기능 별로 테이블을 최대한 나누는 게 좋다'라고 생각했다. 그래서 유저 관련 테이블만 3개가 되었다.

그런데 개발을 진행하면서 보니 사실 하나로 묶을 수 있는 구조였고, 결과적으로 API 하나를 호출할 때마다 JOIN이 3~4개씩 발생했다.

작은 데이터에서는 문제가 없었지만, 만약 데이터가 1억, 10억 건이었다면?

- JOIN이 많아질수록 연산량이 곱셈처럼 증가

- 인덱스가 없으면 풀스캔 발생

- 잘못 나눈 테이블 = 성능 병목

-> 즉, 불필요하게 나눈 테이블은 JOIN 증가 & 성능 저하의 원인이 된다.

 

물론, JOIN이 많다고 무조건 안 좋은 것은 아니며 이는 엔티티를 잘못 설계해서 발행하는 JOIN이 문제인 것이다.

 

 

2. 비즈니스 요구사항을 구조적으로 해결할 수 있게 된다

실제 개발에서는 문제를 기술적으로 해결하기 위해서는 문제 자체를 구조화하는 사고방식이 필요하다.

 

대표적인 경험이 바로 오버레이 저장 기능에서 발생한 UI 프리징 이슈였다.

 

콘텐츠 저장 앱을 개발할 때, 오버레이 아이콘을 누르면 현재 보고 있던 웹사이트의 URL과 AI 요약 내용을 저장하는 기능을 구현했다.

그런데 버튼을 누르면 10초가 넘도록 흰 화면이 유지되는 UI 프리징 현상이 발생했다.

 

처음에는 '저장하는데 10초 정도 걸리는구나, 그냥 로딩 UI로 구현하면 되겠지'라고 생각했다.

그렇지만, 10초는 너무 길고 사용자가 바로 불편함을 느끼는 수준이었다.

 

그래서 다시 문제를 분석해 봤다. 알고 보니 메인 스레드에서 URL 저장, AI 요약 요청, DB 저장이 동시에 실행되는 구조였다.

이걸 해결하기 위해서 네트워크 요청을 비동기로 분리하고 작업을 순차 처리하는 작업 큐 구조로 재구성했다.

그 결과 오버레이 버튼을 누르자마자 다시 보고 있던 화면으로 돌아오는 수준으로 개선이 되었다.

 

이 과정을 다시 되돌아보면, 결국 문제를 분해하고 흐름을 정리하는 '알고리즘적 사고방식'이 적용된 것이다.

이처럼 알고리즘은 문제를 쪼개고 핵심 원인을 찾는 능력을 길러준다.

 

 

3. 대규모 서비스에서는 효율이 곧 비용이 된다

서비스 운영에서는 시간 복잡도와 공간 복잡도 = 실제 비용이다

 

- DB 검색 속도 => 서버 증설 여부 결정

- API 처리 속도 => 동시 접속 처리량 결정

 

100명, 1000명일 땐 괜찮더라도, 100만 명 이상이 접속한다면 비용이 수천만 원씩 차이가 날 수 있게 된다.

개발 프로젝트를 진행할 때는 보통 나 혼자 또는 팀원 몇 명이 테스트하기 때문에 '수십만 명이 동시에 사용하는 상황'을 고려하지 못했다.

하지만 기업은 항상 이 상황을 전제로 서비스를 만들어야 한다.

그렇기 때문에 효율이 낮은 코드는 곧 비용을 증가시키는 코드가 된다.

 

 

4. 데이터 구조를 이해해야 유지보수가 가능해진다

실제 서비스는 대부분 자료구조 위에 동작한다

 

- 브라우저 렌더링 => 큐/우선순위큐

- React Fiber => 트리 구조

- Redis => 해시, 셋

 

자주 사용하는 브라우저 뒤로 가기/앞으로 가기 기능을 예로 살펴볼 수 있다.

 

이 기능은 스택 2개로 구현된다.

- 웹사이트 방문할 때마다 현재 페이지를 backStack에 push

- 뒤로 가기를 누르면 backStack.pop() -> forwardStack.push()

- 앞으로 가기를 누르면 forwardStack.pop() -> backStack.push()

- 새로운 페이지 방문할 때 forwardStack 초기화 -> 앞으로가기 버튼 비활성화

 

-> 스택 기반 구조이기 때문에 페이지 수와 상관없이 뒤로 가기/앞으로 가기 작업 수행 시 걸리는 시간은 O(1)로 일정하다.

 

방문 기록이 10개든 10,000개든 뒤로 가기를 눌렀을 때 걸리는 시간은 동일하게 빠르다는 의미이며, 브라우저를 사용할 때 지연을 느끼지 않는 핵심 기반이다.

이것은 리스트(배열)를 사용해 순차적으로 검색하는 것보다 훨씬 좋은 성능을 제공한다.

 

 

마무리

 

알고리즘을 공부하면서 단순히 코테를 위한 기술이 아니라, 서비스를 이해하고 설계하고 최적화하는 사고방식이란 점을 느꼈다.