[실전 서버리스 15] KV·DO·Queues·Workflows 언제 뭘 쓰나

서버리스 생태계에는 데이터베이스와 스토리지 말고도 여러 도구가 있다. 빠른 읽기용 저장소 KV, 상태를 들고 있는 두러블 오브젝트, 작업 대기열 큐, 장기 실행 워크플로 같은 것들이다. 이름만 봐선 뭐가 뭔지 헷갈린다. 이번 편은 이 도구들을 언제 무엇에 쓰는지, 선택의 기준을 정리한다.

서버리스를 쓰다 보면 이 도구들을 만나는데, 각자 잘하는 게 달라서 상황에 맞게 골라야 한다. 잘못 고르면 안 맞는 도구로 억지로 문제를 푸는 셈이 된다.

1. KV, 빠른 글로벌 읽기

KV는 키와 값을 저장하는 아주 단순한 저장소다. 키를 주면 값을 빠르게 돌려준다. 특징은 전 세계 어디서나 매우 빠르게 읽힌다는 것이다. 대신 쓰기는 즉시 반영되지 않고 잠깐의 지연이 있을 수 있다. 읽기에 최적화되고 쓰기는 느슨한 저장소다.

그래서 KV는 자주 읽고 드물게 쓰며 즉시 일관성이 필요 없는 데이터에 맞는다. 예를 들어 설정값, API 키 같은 것들이다. 이런 건 한 번 정하면 자주 안 바뀌고 여기저기서 계속 읽으니 KV가 적합하다. 세션 정보 같은 것도 후보다.

다만 KV에는 쓰기 횟수 제한과 쓰기 지연이 있어서, 자주 바뀌고 즉시 반영이 중요한 데이터엔 안 맞는다. 나는 이 지연 때문에 KV를 쓰려다 접고, 데이터베이스 읽기를 캐시하는 방식으로 갔다. KV가 좋은 경우가 분명 있지만, 내 상황에는 안 맞았다. 도구의 특성을 알고 내 상황과 맞춰봐야 한다.

KV의 쓰기 지연이라는 특성을 모르고 쓰면 낭패를 본다. 값을 바꿨는데 바로 반영이 안 돼 혼란스러울 수 있기 때문이다. 그래서 KV는 자주 안 바뀌고 즉시 일관성이 필요 없는 데이터에만 쓴다. 설정값이나 API 키처럼 한 번 정하면 오래 가는 것들이다. 나는 이 지연 때문에 KV를 접고 데이터베이스 캐시로 갔다.

한 가지 더, 이 도구들은 서로 조합해 쓸 수도 있다. 큐로 넘긴 작업이 워크플로로 처리되거나, 두러블 오브젝트가 큐와 함께 쓰이는 식이다. 각 도구가 독립적이라 필요에 따라 엮을 수 있다. 다만 조합이 복잡해질수록 관리도 어려워지니, 필요한 최소한만 조합하는 게 좋다.

이 도구들의 이름이 처음엔 비슷비슷해 헷갈리지만, 각자 해결하는 문제가 다르다는 걸 알면 정리가 된다. 저장이냐 상태냐 비동기냐 장기 작업이냐, 이 질문에 답하면 어느 도구인지가 보인다. 문제의 성격을 먼저 파악하고 거기에 맞는 도구를 고르는 순서가 옳다.

2. Durable Objects, 상태를 든 워커

두러블 오브젝트는 상태를 계속 들고 있는 특별한 워커다. 일반 워커는 요청마다 새로 시작하고 끝나지만, 두러블 오브젝트는 상태를 유지한다. 그리고 여러 요청이 이 하나의 오브젝트를 거치게 해서, 순서를 엄격히 보장할 수 있다.

이게 필요한 경우가 있다. 예를 들어 실시간 협업이나 채팅방처럼, 여러 사람의 동작이 한 곳에서 순서대로 처리돼야 하는 상황이다. 또는 사용자별로 상태를 계속 들고 있어야 하는 경우다. 일반 워커로는 상태를 유지하기 어려운데, 두러블 오브젝트가 이걸 해준다.

다만 두러블 오브젝트는 대체로 유료 기능이고, 개념도 조금 복잡하다. 그래서 정말 상태 유지와 엄격한 순서가 필요한 경우가 아니면 굳이 쓸 이유가 없다. 나는 커뮤니티에 이런 실시간 상태 요구가 크지 않아서 두러블 오브젝트는 쓰지 않았다. 필요 없는 도구를 억지로 쓸 필요는 없다.

두러블 오브젝트는 강력하지만 필요할 때만 쓰는 도구다. 상태 유지와 엄격한 순서가 정말 필요한, 실시간 협업이나 채팅방 같은 경우에 빛난다. 하지만 대체로 유료이고 개념도 복잡해서, 그런 요구가 없으면 굳이 쓸 이유가 없다. 나는 커뮤니티에 이런 실시간 상태 요구가 커서 두러블 오브젝트를 안 썼다.

3. Queues, 비동기 작업 대기열

큐는 앞서 고아 파일 정리에서 잠깐 나온 작업 대기열이다. 당장 처리하기 어렵거나 무거운 작업을 큐에 담아두고, 뒤에서 별도로 처리한다. 사용자 요청은 빠르게 끝내고, 무거운 일은 큐로 넘겨 나중에 처리하는 것이다.

큐가 유용한 경우는 많다. 이미지 압축이나 썸네일 생성 같은 무거운 후처리, 대량의 알림 발송, 외부 서비스 호출처럼 시간이 걸리는 작업들이다. 이런 걸 사용자 요청 안에서 처리하면 응답이 느려지지만, 큐로 넘기면 사용자는 빠른 응답을 받고 무거운 일은 뒤에서 진행된다.

큐는 작업이 확실히 처리되도록 보장한다. 큐에 넣은 작업은 최소 한 번은 처리되고, 실패하면 다시 시도된다. 그래서 반드시 처리돼야 하는 작업을 안전하게 뒤로 미룰 수 있다. 큐는 별도 편에서 더 자세히 다룰 만큼 서버리스에서 중요한 도구다.

큐는 이 도구들 중 가장 자주 쓰게 된다. 무거운 작업을 뒤로 미루는 이 패턴이 거의 모든 서비스에 유용하기 때문이다. 이미지 후처리, 알림 발송, 외부 연동처럼 시간 걸리는 걸 큐로 넘기면 사용자 응답이 빨라진다. 그래서 큐는 별도 편에서 따로 다룰 만큼 서버리스에서 중요한 도구다.

또 하나, 큐가 작업을 묶어 처리하는 기능이 효율에 도움이 된다. 알림 여러 개를 하나씩 보내는 것보다 모아서 한 번에 보내는 게 효율적일 때가 있다. 큐가 작업을 얼마나 모아 언제 처리할지를 조절할 수 있어서, 이 묶음 처리로 자원을 아낄 수 있다. 개별 처리와 묶음 처리를 상황에 맞게 고른다.

4. Workflows, 장기 실행 다단계 작업

워크플로는 여러 단계로 이뤄진 긴 작업을 안정적으로 처리하는 도구다. 예를 들어 여러 단계를 거치고, 중간에 기다리기도 하고, 실패하면 재시도하는 복잡한 작업이다. 이런 걸 일반 워커로 하면 중간에 끊기거나 상태를 잃기 쉬운데, 워크플로는 각 단계의 상태를 저장하며 안정적으로 진행한다.

워크플로의 강점은 내구성이다. 중간에 문제가 생겨도 마지막 성공한 단계부터 이어서 재개할 수 있다. 긴 작업을 처음부터 다시 하지 않아도 되는 것이다. 여러 단계를 거치는 결제 처리나 복잡한 데이터 파이프라인 같은 데 적합하다. 최근에는 이 워크플로가 더 유연하게 발전하고 있다.

다만 워크플로는 복잡한 장기 작업을 위한 것이라, 단순한 사이트에는 과할 수 있다. 대부분의 커뮤니티 기능은 큐 정도로 충분하다. 워크플로는 정말 여러 단계와 재시도, 상태 유지가 필요한 복잡한 작업을 만났을 때 꺼내는 카드다. 도구의 무게를 문제의 무게에 맞추는 게 중요하다.

워크플로는 복잡한 장기 작업을 위한 것이라 단순한 사이트엔 과할 수 있다. 여러 단계와 재시도, 상태 유지가 필요한 결제나 복잡한 파이프라인 같은 데 적합하다. 대부분의 커뮤니티 기능은 큐 정도로 충분하다. 도구의 무게를 문제의 무게에 맞추는 게 중요하다. 과한 도구는 오히려 관리를 복잡하게 한다.

5. 선택의 기준

이 도구들의 선택 기준을 정리하면 이렇다. 자주 읽고 드물게 쓰는 데이터는 KV, 상태 유지와 엄격한 순서가 필요하면 두러블 오브젝트, 무거운 작업을 뒤로 미루려면 큐, 복잡한 다단계 장기 작업은 워크플로다. 각자 잘하는 영역이 뚜렷하다.

중요한 건 필요 없는 도구를 억지로 쓰지 않는 것이다. 이 도구들이 있다고 다 써야 하는 게 아니다. 내 사이트가 실제로 필요로 하는 것만 골라 쓰면 된다. 나는 데이터베이스와 스토리지, 그리고 큐 정도로 커뮤니티를 굴렸다. 두러블 오브젝트나 워크플로는 필요가 없어 안 썼다. 단순하게 유지하는 게 관리에 유리하다.

정리하면 서버리스 생태계에는 KV, 두러블 오브젝트, 큐, 워크플로 같은 도구들이 있고, 각자 잘하는 영역이 뚜렷하니 필요에 맞게 골라 쓰되 억지로 다 쓸 필요는 없다. 다음 편에서는 이 중 실제로 가장 많이 쓰는 큐를 더 파고들어, 무거운 작업을 뒤로 미루는 비동기 처리를 실전으로 다룬다.

선택의 기준을 정리하면 각 도구가 잘하는 영역이 뚜렷하다. 자주 읽는 건 KV, 상태와 순서는 두러블 오브젝트, 뒤로 미룰 작업은 큐, 복잡한 장기 작업은 워크플로다. 중요한 건 필요 없는 걸 억지로 안 쓰는 것이다. 나는 데이터베이스, 스토리지, 큐 정도로 커뮤니티를 굴렸다. 단순함이 관리에 유리하다.

덧붙이면, 이 도구들을 처음부터 다 알 필요는 없다. 사이트를 만들며 필요가 생길 때 그때 해당 도구를 익히면 된다. 나도 큐는 무거운 작업을 만나고서, 크론은 정기 작업이 필요해지고서 익혔다. 도구는 문제가 생겼을 때 배우는 게 가장 잘 이해된다. 미리 다 공부하려 들기보다 필요에 따라 하나씩 익히는 게 현실적이다.

다음 편에서는 이 중 실제로 가장 많이 쓰는 큐를 더 깊이 파고든다. 무거운 작업을 사용자 요청에서 떼어내 뒤에서 처리하는 비동기 처리를, 실전 관점에서 자세히 다룬다.