티스토리 뷰

Sorry Architecture

Sorry Architecture

Quill. 2021. 10. 8. 12:29

너무 오래 전 있었던, 게으름으로 인하여 기록하지 못했던 이야기를 남겨본다. AWS RDS(Relational Database Service)가 베타 버전이었을 때였다. 당시 우리 팀에서 RDS에 대한 우려가 많았던 시절이었고, 그래서 AWS RDS 엔지니어가 직접 한국을 방문했다. 그래서 우리는데이터베이스 관련한 다양한 질문을 주고 받았다. 그 중에서 기억에 남는 일화를 가져와봤다. RDS 엔지니어를 만났을 때의 첫인상은 다음과 같았다. 젋어보였고 짙은 갈색 머리를 가진 백인이었다. 뽀얀 피부에 수염을 길렀고, 진한 검정색이 매력적인 씽크패드를 들고 왔다. 잘 차려입은 격식있는 모습은 아니었지만 단정하고 깔끔한 인상이었다. 사실 그의 모습이 중요한 것은 아니었지만, 너무 인상깊었기 때문에 언급하고 싶었다.

회의 주제는 ETL(Extract, Transform, Load)에 관한 것이었다. 한 쪽 데이터베이스에 있는 정보를 추출해서 다른 데이터베이스로 옮기는 작업이었다. 이러한 요구사항은 여러 가지 경우에 필요한데, 그 중 한가지는 주문 정보를 기록한 특정 데이터베이스의 내용을 분석용 데이터베이스에 옮기는 것이다. 전세계를 대상으로 사업을 하는 회사의 경우, 해외 거점에 있는 데이터베이스의 정보를 한국에 있는 데이터베이스로 옮길 필요가 있었고, 이 시간을 단축시키고 싶었다. 반대의 경우도 있었다. 상품을 관리하는 데이터베이스의 정보를 각 지역의 거점 데이터베이스에 복사하는 요구사항도 있었다. 역시 마찬가지로 이 경우에도 정보를 옮기는 시간을 줄이고 싶었다. 이 요구사항들은 RDS에 특화된 것은 아니었지만, 그 엔지니어는 마치 우리 팀인 것처럼 같이 고민해 주고 해결법을 제안해 주었다.

ETL을 수행할 때 원본 데이터베이스의 정보를 파일로 만들어서 추출하고 파일을 전달한 다음 대상 데이터 베이스에 기록하는 것이었다. 파일로 추출하고 파일만 전송하는 것이 네트워크 환경까지 고려한 현실적인, 지극히 정직한, 방법이었다. 그가 제안한 방법은 묘수가 아니었다. 그러나 묘수[각주:1]를 원했던 당시 우리 측 엔지니어는 '별 거 없네'라는 반응을 보였다. 그래서 다른 것은 더 없는 지 물었다. 그러자 RDS 엔지니어는 히든 카드를 꺼내 들었다. 그 것은 쏘리 아키텍처(Sorry Architecture)였다. 처음 들어보는 아키텍처 이름에 다들 호기심이 발동했다. 어떤 특징을 가지고 어떤 문제를 해결할 수 있을 지 그리고 도대체 쏘리 -'미안해요'- 라는 이름이 무엇을 의미하는 지 궁금했다.

RDS 엔지니어는 사뭇 진지한 표정으로 이렇게 말했다. 쏘리 아키텍처라는 것은 ‘어쩔 수 없는 경우에 미안하다고 말하는 설계방법론‘이라는 것이었다. 너무 도전적인 목표를 달성하기 위해 많은 시간과 노력을 들이지 말라는 설명이었다. 어떠 경우에는 비지니스로 간단하게 문제를 풀 수 있다는 것이다. 현재의 기술로 해결할 방법이 없어보이는 문제에 집착했을 때 비용 대비 효용이 떨어질 수 있는 데[각주:2], 이런 경우 비지니스 관점에서 고객에게 미안하다고 말하는 것이 훨씬 좋다는 의미였다. 현실에서 일어나는 비지니스 요건 중 70-80%는 시스템과 기술로 충분히 기대효과를 얻을 수 있지만, 그 부분을 넘어서는 경우에는 오히려 사람사이의 관계로 문제를 간단하게 풀 수 있다는 뜻이었다.

시대를 앞서가는 뛰어난 혁신 기술일 것이라고 기대했던 많은 참석자들에게서 실망한 표정을 읽을 수 있었다. 기술적 탁월함을 기대했던 사람들에게는 다소 김이 빠지는 내용이었겠지만, 쏘리 아키텍처라는 이름과 의미를 통하여 기술의 목적을 다시 생각해 볼 수 있는 좋은 기회가 되었다. 기술에만 한정해서 바라보던 좁은 시야가 비지니스와 사람으로 확장된 것이다. 기술 자체에 너무 집착하지 말고 그 시대의 비지니스에 필요한 만큼의 적정 기술을 잘 활용하는 것이 중요하다는 깨달음을 얻었다. 기술은 사람을 위한 도구가 되어야 한다. 역시, 사람이 우선이다.


  1. 묘수라고 쓰고 꼼수라고 읽을 것 [본문으로]
  2. 성공 확률도 매우 떨어지며, 결국 성공한다고 하더라도 많은 시간과 노력이 필요하다. 그에 비해 얻을 수 있는 혜택이나 그 적용 대상범위가 적다 [본문으로]

'Sorry Architecture' 카테고리의 다른 글

Sixth Man  (0) 2022.05.16
Poka-Yoke  (0) 2022.05.10
Runbook  (0) 2020.12.05
RBAC with AWS IAM  (0) 2020.02.16
Stress Test  (0) 2019.11.06
공지사항