미국에 오면 개발자 천국일 것 같으시죠?
연봉 많이 주고, 자율 출퇴근하고, 수평적인 문화. 틀린 말은 아닙니다.
하지만 그 자유 뒤에는 아주 살벌한 책임이 따릅니다. 특히 인프라를 건드리는 SRE(Site Reliability Engineering) 팀이라면 더더욱 그렇습니다.
제가 AWS EC2 팀에 있을 때나 지금 넷플릭스에 있으면서, 수많은 천재들이 하루아침에 책상을 빼는 걸 봤습니다.
그들이 무능해서 잘렸을까요? 아닙니다.
대부분은 '지나친 열정' 때문이었습니다.
특히 "회사의 클라우드 비용을 획기적으로 줄여보겠다"며 섣부른 자동화 스크립트를 돌리다 사고를 친 경우가 태반입니다.
오늘 소개할 도구는 정확히 그 반대 지점에 있습니다.
최근 해커뉴스(Hacker News)에서 화제가 된 CleanCloud입니다.
이 도구의 캐치프레이즈는 아주 도발적입니다.
"무엇도 삭제할 수 없는 클라우드 정리 도구"
보통의 엔지니어들은 AWS Nuke 같은 강력한 도구를 좋아합니다.
명령어 한 줄이면 안 쓰는 리소스를 싹 밀어버리고, 비용 그래프가 뚝 떨어지는 쾌감을 주니까요.
하지만 저는 후배들에게 늘 말합니다.
"프로덕션 환경에서 삭제(Delete) 권한이 있는 자동화 스크립트는 시한폭탄이다."
사람은 실수를 합니다. 그리고 기계는 그 실수를 빛의 속도로 실행합니다.
개발 환경(Dev)인 줄 알고 날렸는데 프로덕션(Prod) DB였던 사례, 아마 판교에서도 숱하게 들으셨을 겁니다.
CleanCloud가 매력적인 이유는 바로 그 무력함에 있습니다.
이 툴은 기본적으로 읽기 전용(Read-only)입니다.
AWS IAM이나 Azure RBAC에서 Describe나 List 권한만 요구합니다.
아무리 버그가 있어도, 아무리 오작동을 해도, 여러분의 인프라를 털끝 하나 건드릴 수 없습니다.
pip install cleancloud로 설치하고 실행하면, 그저 리포트만 던져줍니다.
제가 주목한 기능은 '신뢰도 점수(Confidence Score)'와 '우리가 확인하지 않은 것(What we didn't check)' 명시 기능입니다.
보통의 툴들은 "이거 안 쓰네요? 지우세요"라고 띡 던져줍니다.
하지만 CleanCloud는 다릅니다.
"이 EBS 볼륨은 6일간 EC2에 붙어있지 않았습니다. (신뢰도: Medium)"
그리고 덧붙입니다.
"단, 우리는 이게 재해 복구(DR)용인지, 수동 작업용 데이터인지는 확인하지 않았습니다."
이게 진짜 엔지니어링입니다.
기계가 판단할 수 있는 영역과, 인간의 맥락(Context)이 필요한 영역을 명확히 구분하는 것.
SRE로서 가장 두려운 건 '블랙박스'입니다.
왜 지워야 하는지, 근거가 무엇인지 모른 채 "삭제 권장"만 뜨는 툴은 새벽 3시에 저를 깨우는 주범이 됩니다.
이 도구는 RCA(Root Cause Analysis) 관점에서도 훌륭합니다.
결과가 결정론적(Deterministic)입니다.
같은 환경에서 돌리면 항상 같은 결과가 나옵니다.
JSON이나 CSV로 떨어지는 로그는 나중에 감사(Audit) 자료로 쓰기에도 완벽합니다.
물론 성격 급한 스타트업 CTO님들은 싫어하실 수도 있습니다.
"알아서 싹 지워주는 원클릭 솔루션 없어?" 라고 물으시겠죠.
그럼 저는 조용히 이력서를 업데이트하라고 조언해 드립니다.
속도보다 중요한 건 가용성(Availability)이고, 그보다 중요한 건 내 밥줄의 안전입니다.
비용 좀 아끼겠다고 프로덕션 날려먹고 사유서 쓰느니, 차라리 한 달에 몇십 달러 더 내고 두 다리 뻗고 자는 게 남는 장사입니다.
CleanCloud는 오픈소스고 MIT 라이선스입니다.
지금 당장 여러분의 팀에서 돌려보세요.
단, "이거 돌리면 비용 얼마나 줄어?"라는 상사의 질문에는 이렇게 대답하십시오.
"비용은 모르겠지만, 적어도 팀장님이 자다 깰 일은 확실히 줄여줍니다."
자동화는 인간을 대체하는 게 아니라, 인간의 판단을 돕는 도구여야 합니다.
삭제 버튼은, 언제나 땀 흘리는 사람의 손으로 직접 눌러야 합니다.
그게 우리가 시스템과 공존하며 오래 살아남는 법입니다.
