개발자와 회의하다 보면 이 네 단어가 한 문장에 다 나오는 순간이 옵니다. 구조, 아키텍처, 자료구조, 알고리즘.
검색해 보면 더 막막해지죠. 트리가 나오고 빅오 표기법이 나오고 시간복잡도가 나옵니다. 알고 싶었던 건 "그래서 이게 서로 뭐가 다른데?" 였는데요.
이 글에서는 네 단어를 층으로 나눠서 정리합니다. 코드는 한 줄도 안 나옵니다. 다 읽으면 개발자에게 뭘 물어야 하는지까지 잡히실 거예요.
가장 흔한 오해가 이겁니다. 넷을 나란히 놓고 어느 게 더 중요한지 비교하려는 것.
넷은 같은 줄에 있지 않습니다. 집을 짓는 일에 비유해서, 무엇인지와 집으로 치면 어디쯤인지, 잘못됐을 때 뭐가 문제인지를 나란히 적었습니다.
아키텍처 : 시스템 전체 짜임새 / 건물 설계도 / 나중에 못 고칩니다
자료구조 : 데이터를 담는 그릇 / 방 안 수납 방식 / 찾는 데 오래 걸립니다
알고리즘 : 일을 처리하는 순서 / 청소하는 순서 / 같은 일에 시간이 더 듭니다
스트럭처 : 그냥 '구조' / 맥락에 따라 다름 / 말이 헷갈립니다
아래로 갈수록 작고 위로 갈수록 되돌리기 어렵습니다. 이 순서가 핵심이에요.
그럼 아래쪽부터 하나씩 보겠습니다. 작은 것부터 봐야 위가 이해되거든요.
자료구조는 데이터를 담아두는 방식입니다. 이름이 딱딱해서 어려워 보이지만, 여러분이 이미 매일 쓰는 것들이에요.
배열 : 번호가 붙은 사물함이 한 줄로 있는 겁니다. 37번을 달라고 하면 바로 꺼내줍니다. 대신 중간에 하나 끼워 넣으려면 뒤쪽을 다 밀어야 하죠.
연결리스트 : 첫 번째 쪽지에 두 번째 쪽지 위치가 적혀 있는 보물찾기입니다. 중간에 끼워 넣기는 쉬운데, 37번째를 보려면 36번 지나가야 합니다.
스택 : 접시 쌓기예요. 마지막에 올린 걸 먼저 꺼냅니다. Ctrl+Z 되돌리기가 이겁니다. 방금 한 일이 먼저 취소되는 이유죠.
큐 : 줄 서기입니다. 먼저 온 사람이 먼저 나갑니다. 프린터 대기열, 콜센터 대기 순서가 다 이 모양이에요.
해시 : 이름을 넣으면 사물함 번호가 튀어나오는 계산기입니다. 연락처에서 이름 두 글자 치면 바로 뜨는 게 이 덕분이고요.
트리 : 폴더입니다. 폴더 안에 폴더가 있고 그 안에 파일이 있는 그 모양이 트리예요.
여기서 알아두실 건 하나입니다. 자료구조를 잘못 고르면 기능은 되는데 느려집니다.
데이터 10개일 때는 어떻게 담아도 티가 안 납니다. 10만 개가 되면 갈립니다. 서비스를 만들고 몇 달 뒤에 "왜 갑자기 느려졌지?" 하는 일의 상당수가 여기서 나옵니다.
알고리즘은 문제를 푸는 순서입니다. 요리 레시피와 같아요. 재료가 같아도 순서를 바꾸면 시간이 달라지죠.
제일 유명한 예가 이분탐색입니다. 두꺼운 사전에서 '알고리즘'을 찾을 때 첫 장부터 넘기는 사람은 없어요. 가운데를 펼치고, 뒤쪽이면 다시 그 뒤쪽의 가운데를 펼칩니다.
숫자로 보면 차이가 선명합니다. 100만 개 데이터에서 하나를 찾을 때,
앞에서부터 하나씩 보면 최악의 경우 100만 번 봐야 합니다.
반씩 접어가면 스무 번이면 끝납니다. 2를 스무 번 곱하면 약 104만이니까요.
100만 번과 스무 번. 코드 길이는 비슷한데 결과가 이만큼 벌어집니다.
지도 앱에서 최단 경로를 찾는 것도 알고리즘이에요. 모든 경로를 다 계산하는 게 아니라, 가까운 곳부터 차례로 확정해 나가면서 답이 정해진 지점은 다시 계산하지 않습니다. 그래서 지하철 노선 전체를 놓고도 결과가 1초 안에 나옵니다.
여기까지가 작은 층입니다. 이제 위로 올라가겠습니다.
아키텍처는 시스템 전체를 어떻게 나누고 잇는지에 대한 결정입니다.
서비스를 하나의 큰 프로그램으로 만들 것인가, 기능별로 쪼개서 서로 통신하게 할 것인가
데이터는 어디에 저장하고, 사진과 영상은 따로 둘 것인가
주문과 결제는 한 몸으로 붙일 것인가, 떼어놓을 것인가
아키텍처가 자료구조나 알고리즘과 결정적으로 다른 점은 고치는 비용입니다.
알고리즘이 느리면 그 함수만 다시 쓰면 됩니다. 자료구조가 잘못됐으면 그 부분을 바꾸고 주변을 손보면 되고요. 아키텍처가 잘못됐으면 대개 다 뜯어야 합니다. 벽지를 바꾸는 일과 벽을 옮기는 일의 차이죠.
그래서 아키텍처 이야기는 늘 "나중에 사람이 100배 늘면 어떻게 될까"로 시작합니다. 지금 안 정해두면 나중에는 정할 수가 없어서요.
이 단어만 성격이 다릅니다. 나머지 셋은 가리키는 게 정해져 있는데, 스트럭처(structure)는 영어로 그냥 '구조'거든요.
그래서 개발 현장에서 이 말은 최소 세 가지로 쓰입니다.
데이터 스트럭처를 줄여서 자료구조를 뜻하는 경우
폴더와 파일이 어떻게 나뉘어 있는지, 코드 구조를 뜻하는 경우
화면이나 문서의 구성을 뜻하는 경우
즉 이 단어를 들었을 때는 뜻을 외우려 하지 말고 "어느 쪽 구조를 말씀하시는 거예요?" 하고 물으시면 됩니다. 개발자끼리도 이건 되묻습니다.
여기가 이 글을 쓴 이유입니다. 용어를 알아서 좋은 게 아니라, 질문이 달라지면 답이 달라져서 좋은 거예요.
"느려요"라고 말하면 개발자는 어디를 봐야 할지 모릅니다. 대신 이렇게 물어보세요.
"이 목록이 1만 개가 되면 지금처럼 빠를까요?" → 자료구조 이야기가 나옵니다.
"지금 오래 걸리는 게 특정 화면인가요, 전체인가요?" → 알고리즘인지 구조인지 갈립니다.
"이건 이 화면만 고치면 되는 일인가요, 전체를 손봐야 하는 일인가요?" → 아키텍처 문제인지 알 수 있어요.
마지막 질문이 특히 값어치가 있습니다. 일정과 견적이 몇 배로 벌어지는 갈림길이 여기라서요. 같은 "수정해주세요"인데 하나는 반나절, 하나는 두 달인 이유가 이 층 차이입니다.
Q. 비전공자도 알고리즘을 공부해야 할까요?
A. 코딩 테스트를 볼 생각이 없으시면 안 해도 됩니다. 다만 위의 층 구분만 알아두면 개발자와 대화가 훨씬 짧아집니다. 그게 이 글의 목표예요.
Q. 자료구조와 데이터베이스는 같은 건가요?
A. 다릅니다. 자료구조는 프로그램이 돌아가는 동안 메모리에 데이터를 담는 방식이고, 데이터베이스는 그걸 저장해서 계속 남겨두는 곳입니다. 다만 데이터베이스 안에서도 빨리 찾기 위해 트리 같은 자료구조를 씁니다.
Q. AI가 코드를 써주는 시대에도 이게 중요한가요?
A. 오히려 물어볼 줄 아는 쪽이 유리해졌습니다. AI는 시키면 돌아가는 코드를 잘 만들지만, 데이터가 100배 늘었을 때를 알아서 고민해주지는 않습니다. "1만 개가 되면 어떻게 되나요"를 물어야 그때 답이 나옵니다.
아키텍처는 설계도, 자료구조는 수납, 알고리즘은 순서입니다.
위로 갈수록 고치는 비용이 큽니다.
스트럭처는 그냥 구조라는 말이니 되물으면 됩니다.
저도 처음엔 이 네 단어를 난이도 순서로 이해했습니다. 층이라는 걸 알고 나서야 남의 말이 들리기 시작했어요. 딱 여기까지만 알아도 회의에서 고개만 끄덕이는 일은 없어집니다.
아직 댓글이 없습니다.