개발이나 서버 관련 내용을 조금만 보다 보면 “동기”, “비동기”라는 말을 자주 보게 된다. 처음에는 그냥 비슷한 개념처럼 느껴져서 크게 신경 쓰지 않았는데, 막상 실제 흐름을 이해하려고 보니까 이 차이가 생각보다 크다는 걸 알게 됐다. 나도 처음에는 “비동기가 더 빠른 거 아닌가?” 정도로만 생각했었는데, 상황에 따라 완전히 다르게 동작한다는 걸 경험하면서 개념이 확 잡히기 시작했다.
동기는 작업이 끝날 때까지 기다리는 방식이다
동기 방식은 말 그대로 순서를 지키면서 하나씩 처리하는 구조다. 어떤 작업을 요청하면, 그 작업이 끝날 때까지 다음 작업으로 넘어가지 않는다. 예를 들어 파일을 읽거나 서버에 요청을 보냈을 때, 결과가 올 때까지 계속 기다리는 방식이다.
이 방식의 장점은 단순하고 이해하기 쉽다는 점이다. 코드 흐름이 순차적으로 이어지기 때문에 디버깅도 비교적 쉽다. 나도 처음에는 동기 방식으로 코드를 작성할 때 훨씬 편하게 느껴졌다.
하지만 단점도 분명하다. 하나의 작업이 오래 걸리면 전체가 멈춰버린다. 실제로 서버 요청을 기다리는 동안 프로그램이 아무 것도 못 하고 멈춰 있는 상황을 경험한 적이 있는데, 그때 체감적으로 “아 이게 동기의 한계구나”라는 느낌이 들었다.
즉, 동기는 안정적이고 직관적이지만, 시간이 오래 걸리는 작업이 있을 때 전체 성능이 떨어질 수 있는 구조다.
비동기는 기다리지 않고 다음 작업을 먼저 처리한다
비동기 방식은 동기와 반대로, 작업을 요청한 뒤 결과를 기다리지 않고 바로 다음 작업을 진행한다. 예를 들어 서버에 요청을 보내고 나서 응답을 기다리는 동안, 다른 작업을 계속 수행할 수 있다.
이 개념을 처음 이해할 때는 조금 헷갈렸다. “기다리지 않으면 결과는 언제 받지?”라는 생각이 들었기 때문이다. 그런데 실제로는 콜백, Promise, async/await 같은 방식으로 나중에 결과를 받아 처리한다.
나도 처음에 비동기 코드를 봤을 때는 흐름이 꼬여 보이고 어렵게 느껴졌는데, 익숙해지고 나니까 오히려 더 효율적이라는 걸 느꼈다. 특히 네트워크 요청이나 파일 처리처럼 시간이 오래 걸리는 작업에서는 비동기가 훨씬 유리했다.
그래서 비동기는 동시에 여러 작업을 처리할 수 있게 해주고, 전체적인 응답성을 크게 개선해준다.
결국 차이는 ‘기다림’과 ‘효율’의 차이다
동기와 비동기의 핵심 차이는 결국 하나다. 기다리느냐, 아니면 다른 일을 하느냐다. 동기는 하나의 작업이 끝날 때까지 기다리는 대신 구조가 단순하고 안정적이다. 반면 비동기는 기다리지 않고 다른 작업을 처리할 수 있지만, 흐름이 복잡해질 수 있다.
실제로는 둘 중 하나만 사용하는 것이 아니라 상황에 따라 적절히 섞어서 사용하는 경우가 많다. 나도 간단한 로직에서는 동기를 쓰고, 시간이 오래 걸리는 작업에서는 비동기를 사용하는 식으로 점점 감이 잡히기 시작했다.
이걸 이해하고 나니까, 웹사이트가 느려지거나 빠르게 반응하는 이유도 조금씩 보이기 시작했다. 특히 버튼을 눌렀을 때 바로 반응하는 인터페이스 뒤에는 대부분 비동기 처리가 숨어 있다는 걸 알게 됐다.
한 줄로 정리하면 동기는 작업이 끝날 때까지 기다리는 방식이고, 비동기는 기다리지 않고 다른 작업을 먼저 처리하면서 효율을 높이는 방식이다.