【AWS Amplify 노하우 시리즈】 6. Amplify DataStore 는 무작정 쓰는거 아닙니다~!

Amplify 시리즈 여섯번째 글입니다! 이번 글에서는 비교적 최근에 출시된 Amplify DataStore 에 대해 간단히 소개하고, 다른 여느 기술과 마찬가지로 Amplify DataStore 도 만능은 아니라는 점을 위주로 한 내용을 다뤄보겠습니다.
2020.07.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

안녕하세요!ㅎㅎ Classmethod 컨설팅부 소속 김태우입니다.

Amplify 시리즈 여섯번째 글입니다! 이번 글에서는 비교적 최근에 출시된 Amplify DataStore 에 대해 간단히 소개하고, 다른 여느 기술과 마찬가지로 Amplify DataStore 도 만능은 아니라는 점을 위주로 한 내용을 다뤄보겠습니다.

그럼 시작하겠습니다! :)

Amplify DataStore 란?

2019년 12월에 발표된 Amplify DataStore 는 출시 직후, 화려한 기능 소개와 함께 그 편리함으로 인해 많은 주목을 받았습니다.

Introducing the Amplify DataStore, a persistent storage engine that synchronizes data between apps and the cloud

AWSKRUG 에서도 올해 초에 Community Day Seoul 이라는 행사를 통해 IDEASAM 의 박태성님께서 Amplify DataStore 에 대해 간단히 소개해주셨습니다.

Amplify Datastore 의 공식 도큐먼트는 아래 페이지를 참조해주세요.

또한, AWS 에서 올해 5월에 Amplify DataStore 를 사용한 레퍼런스 아키텍쳐를 공개하였으므로 아래 글과 Github 리포지토리도 참조해주세요.

위의 내용들을 직접 캐치업하기에는 너무나 바쁘신 분들을 위해 간략히 요약해서 기능을 정리해드리면,

  1. AppSync 의 오프라인 싱크 기능을 손쉽게 사용할 수 있도록 하여, 오프라인 상태에서도 앱을 사용할 수 있게하고 온라인이 되었을때 내부적으로 자동으로 데이터 싱크를 맞춰준다.

  2. GraphQL 을 몰라도 Amplify 를 활용할 수 있도록, save() / delete() / query() / observe() / clear() 등의 ORM 과 비슷한 느낌으로 사용할 수 있게 해준다.

정도로 요약될 수 있을 것 같습니다.

위 그림은 AWS 에서 설명하는 Amplify DataStore 의 내부 구조인데요, Storage Engine 레이어에서 로컬 스토리지와 리모트 스토리지 (AppSync) 에 적절하게 데이터를 연동시켜주는 마법을 부려준다고 합니다.

const post = await DataStore.save(
  new Post({
    title: "My Post with comments",
    rating: 10,
    status: PostStatus.ACTIVE
  })
);

await DataStore.save(
  new Comment({
    content: "Loving Amplify DataStore!",
    postID: post.id
  })
);

const comments = (await DataStore.query(Comment)).filter(c => c.postID === "123");

const post = await DataStore.query(Post, "123");
const comments = (await DataStore.query(Comment)).filter(c => c.postID === post.id);

const toDelete = await DataStore.query(Post, "123");
DataStore.delete(toDelete);

데이터를 조작할 때에도 GraphQL 에 대한 개념이 전혀 없이도 손쉽게 사용할 수 있는 코드를 확인하실 수 있습니다.

이 좋은걸 왜 안 써?!

혁명적인 수준의 편리함을 자랑하는 Amplify DataStore 이지만, 결론부터 말씀드리면 제 생각에는 아직까지는 Amplify DataStore 의 쓰임새는 그리 넓지 않을 것 같습니다. 아마도 Amplify DataStore 를 처음 접하시고 개발 경력이 비교적 짧은 (저와같은) 분들은 바로 실제 프로젝트에 써보고싶은 마음이 굴뚝같을 것 같습니다. 당연히 사이드 프로젝트에 Amplify DateStore 를 적용해보는 것은 매우 훌륭하다고 생각하지만, 프로덕션 에 적용을 위해 검토하시는 분들은 아래의 제약사항들을 꼭 먼저 읽어보시는 것을 권장합니다.

1. 쿼리에 제약이 많다

Amplify DataStore 의 쓰임새가 많지 않을것 같다고 판단한 그 첫번째 이유로, 쿼리에 제약이 많다는 점을 꼽고 싶습니다. 사실 이건 Amplify DataStore 의 문제라기보다는 DynamoDB 를 데이터소스로 활용하고 있기때문인데요, DynamoDB 를 데이터소스로 활용할 때 어떠한 제약들이 있는가에 관해서는 아래의 블로그를 참조해주세요.

그럼 Elasticsearch 를 데이터소스로 쓰면 되지 않느냐라고 생각하실 수 있는데요, @searchable 디렉티브 페이지의 처음 Note 로 아래의 사항이 적혀있습니다.

Note: @searchable is not compatible with DataStore but you can use it with the API category.

Amplify 공식 도큐먼트 @searchable 설명

네.. DataStore 는 @searchable 디렉티브를 지원하지 않습니다. 이말은 즉슨, Elasticsearch 를 지원하지 않는다는 의미가 됩니다. 기껏 편하게 개발하려고 Amplify DataStore 를 선택했는데, 제생각엔 대다수의 애플리케이션의 경우 DynamoDB 에서 제공하는 수준의 쿼리만으로는 턱없이 부족하기때문에, DynamoDB Streams 와 Elasticsearch 의 데이터 동기화 및 인덱싱을 직접해줘야하며, Elasticsearch 로 요청하는 커넥션 및 쿼리 관련 코드도 직접 작성해야합니다.

그럴바에는 차라리 Amplify API 만을 사용하는 편이 훨씬 편하겠죠. Amplify DataStore 를 검토하시는 분들이라면 반드시 고려해야하는 제약사항이라고 생각합니다.

2. Amplify API 보다 정보를 구하기 더 어렵다

이건 많은 분들이 쉽게 공감할 수 있는 사항일 거라 생각하는데요, Amplify DataStore 는 작년 12월에 출시된 굉장히 최신 기능이다보니 아직 제대로된 노하우는 커녕, 어떤 이슈가 있는지에 대한 정보 조차도 찾기가 어렵습니다. Amplify API 의 경우, 이제 어느정도 Github Issues 에 활발히 논의되었던 토론들을 보며 선인들의 지혜와 노하우를 비교적 쉽게 습득할 수가 있는데요, Amplify DataStore 는 Amplify API 보다도 더 사례가 부족하고 개발시에 막히는 부분들에 대해 같이 "한국어" 로 이야기 해볼 상대를 찾는것도 쉽지 않아보입니다.

참고로, Amplify Discord #datastore-discussion 채널 에서 "영어" 로 Amplify DataStore 에 대한 토론은 활발하게 진행되고 있습니다 :D

3. 커스텀하기 어렵다

마지막으로, Amplify DataStore 의 정보를 구하기 어렵다는 점에서 기인한 내용인 커스텀하기가 어렵다는 점을 꼽고 싶습니다. Amplify DataStore 는 Amplify API 와 비교했을 때 더욱 추상화된 수준의 라이브러리를 제공하기 때문에 직접 커스텀하기가 더 까다롭고 어렵습니다. Amplify API 를 직접 커스텀하는 것도 그리 편안한 작업은 아니지만 Amplify DataStore 의 경우 Amplify 공식문서에 모든 제약사항과 이슈들이 다 기재되어 있지도 않을뿐더러 그 정보를 아는 사람들은 AWS Amplify 개발팀의 내부 인력들밖에 없으므로 Github Issues 등을 통해 공식 문서에 표기되어 있지 않은 이슈가 발생할 때마다 직접 모든 사항들에 대해 물어보지 않으면 안됩니다.

개발을 하면서 특정 라이브러리에 의존하게 된다고 하더라도 어느정도의 커스터마이징은 필수적으로 해야하는 경우가 대부분이라 생각됩니다. Amplify DataStore 의 경우에도 직접 resolver 를 커스터마이징한다거나, 싱크엔진이나 스토리지 엔진을 커스터마이징한다거나 Amplify API 와 Amplify DataStore 를 같이 사용하고 싶다거나 하는 등의 수많은 커스터마이징 요구사항들에 대해 미리 파악해두지 않으면 각각의 상황들이 닥칠때마다 많은 시간을 허비하게 됩니다. 이런 점에서 봤을 때 커스터마이징하기 어렵다는 점은 사전에 반드시 알아둬야할 제약사항이라고 생각합니다.

Amplify DataStore 에 대한 개인적인 생각

위와 같은 큼직큼직한 제약사항들이 있음에도 불구하고 저는 Amplify DataStore 가 앞으로의 개발방법에 대한 가이드를 제시하고 있다고 믿고 있습니다. 점점 더 복잡하고 많은 기능들을 당연하게 생각하는 사용자들의 기대치에 제대로 부응한 앱을 효과적으로 빨리 만들어내기 위해서는, Amplify 의 오프라인 기능 서포트와 ORM 방식의 개발방법론이 사실상 베스트에 가깝지 않나하고 개인적으로는 조심스럽게 생각하고 있습니다. 초기 스타트업이 빠르게 MVP 를 만들어내는데 Amplify 는 이미 매우 효과적인 도구라고 생각하지만, Amplify DataStore 는 이를 더욱 효과적으로 사용할 수 있는 미래를 보여주고 있다고 생각합니다.

그래서 아직은 좀 더 지켜볼 단계이지만 머지 않아 Amplify DataStore 가 널리 사용되는 날이 올 것 같다고 생각합니다!

마치며

이번 글에서는 Amplify DataStore 에 대한 간단한 소개, 현시점에서의 제약사항, 그리고 Amplify DataStore 에 대한 저의 개인적인 의견을 적어보았습니다. Amplify DataStore 가 하루빨리 더 많은 기능을 지원해서 널리 쓰일 수 있었으면 좋겠습니다!

이상, 컨설팅부의 김태우였습니다! :D