S3 Files와 변화하는 S3의 미래

2026년 4월 7일 • 6004단어

사진 제공: Ossewa

경력을 쌓다 보면 누구나 한 번쯤은 대용량 데이터를 한 곳에서 다른 곳으로 옮기는 답답한 작업을 경험하게 됩니다. 아직 경험하지 못했다면, 아마 충분히 큰 규모의 데이터를 다뤄본 적이 없었을 가능성이 높아요.

Andy Warfield에게 이런 깨달음이 생긴 건 UBC(브리티시컬럼비아 대학교)에서였습니다. 유전체 연구자들과 함께 일할 때, 그들이 생산하는 엄청난 양의 시퀀싱 데이터를 목적지로 옮기는 데만 어마어마한 시간을 소비하는 모습을 목격했거든요. 데이터를 계속 왔다갔다 복사하고, 여러 개의 불일치하는 사본을 관리하는 악순환이 반복되고 있었습니다.

이 문제는 실험실의 과학자부터 머신러닝 모델을 학습시키는 엔지니어까지, 모든 산업 분야의 개발자들을 괴롭혀 왔습니다. 그리고 이야말로 우리가 고객을 위해 풀어야 할 문제죠.

이 글에서 Andy는 자신의 팀이 만든 솔루션인 S3 Files에 대해 얘기합니다. 시행착오 끝에 얻은 귀중한 교훈, 몇 가지 재미있는 순간들, 그리고 새로운 데이터 타입에 이름을 붙이려다가 좌절했던 이야기까지 담겨 있습니다. 꼭 읽어볼 만한 글이에요.

Part 1: 변화하는 S3의 면면

먼저, 식물학 이야기

해바라기가 인간보다 훨씬 더 난잡하다는 사실, 알고 계셨나요? 십여 년 전, Amazon에 입사하기 직전, 저는 두 번째 스타트업을 정리하고 다시 UBC로 돌아가 강의를 시작했습니다. 연구 경험이 별로 없던 분야를 배워보고 싶었는데, 그게 바로 유전체학이었어요. 특히 컴퓨터 시스템과 생물학자들의 유전체 연구 방식이 만나는 지점에 관심이 생겼습니다.

그렇게 해서 만난 사람이 UBC의 식물학 교수 Loren Rieseberg였습니다. 그는 해바라기 DNA를 연구하는데, 가뭄이나 염분이 많은 토양처럼 혹독한 환경에서도 살아갈 수 있는 특성을 유전체 분석을 통해 이해하려고 했거든요.

Loren 연구실이 일하기 좋았던 이유 중 하나가 바로 그 "난잡함" 농담이었어요. 설명을 들어보니 흥미로웠습니다. 인간의 DNA는 약 30억 개의 염기쌍을 가지고 있고, 인간 두 명은 유전체 수준에서 99.9% 동일합니다. 우리의 DNA는 놀랍도록 유사하다는 거죠.

하지만 해바라기는 꽃이고 일부일처제가 아니거든요. 그래서 더 큰 유전체(약 36억 개의 염기쌍)를 가지고 있을 뿐만 아니라, 개체 간 유전적 변이도 10배 이상 많습니다.

당시 제 지도 학생이던 JS Legare가 이 프로젝트에 함께하기로 했고, Loren의 연구실에서 박사후 연구원으로 일하면서 이런 작업들을 클라우드로 옮길 방법을 모색했습니다.

클라우드로의 이동

유전체 분석은 일부 연구자들이 "버스트 병렬"(burst parallel) 컴퓨팅이라고 부르는 작업입니다. DNA 분석은 대규모 병렬 처리로 가능한데, 이런 분석은 비교적 짧은 기간에 실행되거든요. 그래서 연구실의 로컬 하드웨어는 좋은 선택이 아니었습니다. 필요할 때 충분한 컴퓨팅 파워가 없었고, 작업이 없을 때는 기계들이 유휴 상태로 남아있었으니까요.

우리의 생각은 간단했습니다. S3와 서버리스 컴퓨팅을 이용해서 수만 개에서 수십만 개의 작업을 병렬로 실행하는 방식이었어요. 그러면 연구자들이 복잡한 분석을 매우 빠르게 실행할 수 있고, 작업이 끝나면 0으로 스케일 다운할 수 있으니까요.

생물학자들은 Linux에서 일했고, GATK4(유전체 분석 툴킷)라는 분석 프레임워크를 사용했습니다. Apache Spark과의 통합도 지원했어요. 모든 데이터는 공유 NFS 파일러에 저장되어 있었습니다.

JS는 클라우드 전환을 위해 "bunnies"(역시 난잡함 농담)라고 이름 붙인 시스템을 만들었습니다. 분석을 컨테이너로 패키징해서 S3 위에서 실행하는 방식이었는데, 속도, 재현성, 병렬화를 통한 성능 면에서 정말 큰 승리였습니다.

그런데 가장 눈에 띄는 교훈이 하나 있었어요. 바로 저장소 계층에서의 마찰이었습니다.

저장소의 마찰

S3는 병렬성, 비용, 내구성 측면에서는 훌륭했습니다. 하지만 유전체 연구자들이 사용하는 모든 도구는 로컬 Linux 파일시스템을 기대하고 있었어요.

결국 연구자들은 계속 데이터를 왔다갔다 복사해야 했고, 때로는 일치하지 않는 여러 복사본을 관리해야 했습니다. 이 저장소 마찰—한쪽에는 S3, 다른 쪽에는 파일시스템, 그 사이에는 수동 복사 파이프라인—은 이후 여러 번 목격했습니다.

미디어와 엔터테인먼트 분야에서도, 머신러닝 사전학습에서도, 실리콘 설계에서도, 과학 컴퓨팅에서도요. 서로 다른 도구들이 서로 다른 방식으로 데이터에 접근하도록 만들어져 있거든요. 그리고 우리 데이터 앞에 있는 API가 일하기 어렵게 만드는 마찰 요소가 되어버리는 상황은 정말 답답합니다.

에이전트가 데이터 마찰을 증폭시킨다

요즘 에이전트 도구가 소프트웨어 개발을 어떻게 바꾸고 있는지, 우리 모두 알고 있습니다. 아직도 조금은 놀라고 있기도 하고요. (심지어 Werner도 말이죠.)

에이전트는 코드를 작성하는 데 정말 능숙하고, 그 능력이 빠르게 향상되고 있어서 우리 모두 "이게 도대체 뭘 의미하는 건가"를 계속 생각하고 있습니다.

하지만 분명한 사실이 하나 있습니다. 에이전트 기반 개발이 애플리케이션을 만드는 비용을 근본적으로 바꿔놨다는 거예요. 달러로 센 비용도 있고, 시간 비용도 있고, 특히 작동하는 코드를 작성하는 데 필요한 기술 수준의 비용도 있습니다. 바로 이 마지막 부분이 앞으로 정말 중요해질 것 같습니다.