솔직히 고백하겠습니다. 저는 기술 스택을 선택할 때, 그리고 서버 아키텍처를 설계할 때 일종의 강박을 가지고 있었습니다. "무조건 실시간이어야 해", "무조건 최신 기술을 써야 해", "가장 빠르고 강력한 옵션이 최고야".
주니어 시절엔 이것이 열정인 줄 알았습니다. 하지만 CTO가 되어 비즈니스와 기술의 접점에서 비용과 효율을 계산하다 보니, 뼈저리게 느낍니다. 그것은 열정이 아니라 '불안'이었습니다. 우리가 시스템을 과잉 설계(Over-engineering)하는 이유는, 적정 수준이 어디인지 확신할 수 없기 때문입니다. 그래서 일단 가장 비싸고 자주 실행되는 옵션을 선택해버리곤 하죠.
최근 흥미로운 의학 논문 하나를 읽었습니다. 우리 개발자들이 시스템 리소스를 다루는 태도에 시사하는 바가 커서 공유해 봅니다. 바로 '아스피린 복용 주기'에 관한 연구입니다.
매일 도는 크론잡(Cronjob), 정말 필요할까?
보통 심혈관 질환 예방을 위해 저용량 아스피린을 '매일' 복용하라고 권장받습니다. 그런데 이 연구(Feldman et al., 2001)에서는 재미있는 실험을 했습니다. 건강한 성인을 대상으로 아스피린 투여 간격을 달리해본 것이죠.
결과는 놀라웠습니다. 3일마다 325mg을 복용하는 그룹과, 매일 81mg을 꼬박꼬박 복용하는 그룹의 혈청 트롬복산(혈소판 응집 유도 물질) 억제율이 거의 동일했습니다. 심지어 3일마다 81mg만 먹어도 꽤 준수한 억제 효과(74%)를 보였습니다.
이 결과를 보며 문득 우리 시스템의 배치(Batch) 작업들이 떠올랐습니다.
우리는 불안감 때문에 데이터 동기화나 리포트 생성 작업을 매일, 혹은 매시간 돌리도록 설정하곤 합니다. AWS Lambda나 CloudWatch Events를 설정할 때, rate(1 day) 혹은 rate(1 hour)가 기본값이 되어버린 지 오래입니다. 하지만 그 데이터가 정말 실시간으로, 혹은 매일 갱신되어야만 비즈니스 가치를 갖는 걸까요?
'3일 간격'이 주는 기술적 교훈
연구진은 "3일 간격 투여는 독성을 줄이면서도 동일한 효능을 보일 가능성이 있다"고 말합니다. 개발 용어로 번역하자면 "리소스를 1/3로 줄이면서도(Cost Down), 동일한 SLA(Service Level Agreement)를 달성할 수 있다"는 뜻입니다.
실제로 제가 과거 운영하던 추천 시스템이 딱 그랬습니다. 사용자의 취향을 분석해 추천 목록을 갱신하는 작업을 매일 새벽 3시에 수행했습니다. 트래픽이 늘어나자 이 작업은 새벽 내내 DB CPU를 100% 가까이 점유했고, 결국 아침 출근 시간대까지 지연되어 장애를 일으키곤 했습니다.
팀원들과 모여 근본적인 질문을 던졌습니다. "사용자의 취향이 과연 하루 만에 그렇게 급격하게 변하는가?"
데이터를 분석해보니 유의미한 취향 변화는 주 단위, 혹은 특정 이벤트 발생 시점에만 일어났습니다. 우리는 과감하게 전체 유저 대상 배치를 '3일 1회'로 변경하고, 실시간성이 필요한 액티브 유저만 별도의 트리거로 처리하는 하이브리드 방식을 도입했습니다. 결과적으로 컴퓨팅 비용은 60% 절감되었고, 새벽 장애 알람은 사라졌습니다. 아스피린을 매일 먹지 않아도 효과가 유지되듯, 배치 작업도 숨 쉴 틈이 필요했던 겁니다.
우리의 아키텍처에도 '적정 용량'이 필요합니다
물론 모든 시스템을 느슨하게 만들자는 이야기는 아닙니다. 주식 거래나 이상 탐지(Fraud Detection)처럼 밀리세컨드(ms) 단위가 중요한 영역도 분명 존재합니다. 하지만 대부분의 비즈니스 로직은 우리가 생각하는 것만큼 급박하지 않습니다.
막막할 때는 다음 세 가지 질문을 던져보세요.
- 변화율(Rate of Change): 데이터가 변하는 속도보다 더 자주 갱신하고 있진 않은가?
- 비즈니스 임팩트: 이 작업이 3일 뒤에 실행된다면 정말 회사가 망하는가?
- 부작용(Side Effect): 과도한 실행이 오히려 DB 락(Lock)이나 리소스 고갈 같은 '독성'을 만들고 있진 않은가?
우리는 때때로 '성실함'의 함정에 빠집니다. 매일 커밋하고, 매일 배포하고, 매일 데이터를 갱신하는 것이 미덕이라 여깁니다. 하지만 엔지니어링의 본질은 무조건적인 실행이 아니라, 최소한의 자원으로 최대한의 효율을 내는 최적점을 찾는 데 있습니다.
매일 아침 습관적으로 확인하는 대시보드나 로그 알람이 있다면, 한번 의심해 보시길 바랍니다. 혹시 우리는 필요 이상의 아스피린을 시스템에 쏟아붓고 있는 건 아닐까요?
내일은 출근해서 팀원들과 cron 설정 파일이나 스케줄러 목록을 한번 훑어봐야겠습니다. 불필요하게 성실한 녀석들이 꽤 숨어 있을 것 같거든요.
