Serverless 방식이 추구하는 성과는 충분히 설득력이 있다. 유지보수와 변경관리를 쉽게 만들고, 운영 환경에서의 자원 관리를 효율성을 높인다. 이 성과를 취하기 위해서는 변화를 수용해야 한다.
경험에 비추어 봤을 때, 팀 단위로 움직이고 있는 프로젝트에서는 변화의 정도에 비례하여 저항이 발생한다.
Serverless 방식이 제공하는 구조적인 장점을 온전히 취하면서, 프로젝트에 환경에 맞게 최적화 하는 일은 기존에 동작하고 있는 업무 프로세스의 성숙도가 높을수록 큰 저항이 발생할 가능성이 높다.
이 글은 개별 엔지니어의 생산성을 넘어서 프로젝트 혹은 팀의 생산성과 성과에 대해 고민하고 있는 소프트웨어 엔지니어들과 나누고 싶은 이야기이다.
코드 작성에 사용하는 툴이나 프로그래밍 언어, 혹은 새로운 개발 프레임워크의 도입은 Serverless 방식을 온전히 적용하는 것에 비하면 단순한 변화라 할 정도다.
이 포스트에서 경험을 바탕으로 다음의 주제에 대해서 생각을 나눠 보고자 한다:
- 왜 Serverless 방식을 선택해야 할까?
- 바꿔야 하는 것들
- 주어진 비즈니스 환경에서 성공에 기여하기 위한 소프트웨어 개발 전략과 기술적인 구현 사례
왜 Serverless 방식을 선택해야 할까?
왜 해야 하는지 따라서 어떻게 할 것인가가 결정된다.
소프트웨어 업계에서 'No Silver Bullet'1은 널리 알려진 명제이다. 특정 관점에서 우월할 수 있는 어떤 선택도 다른 관점과 상충(trade-off) 되는 경우는 매우 흔하다.
무엇보다도 소프트웨어 시스템은 순수 창작물이 아니라 비즈니스를 지원하고 혁신하기 위해 사용되기 때문에 비즈니스 환경 변화에 따라 적응해야 하는 것은 필연적이다.
이러한 특성에 비추어 Serverless 방식의 도입의 이유는 단순하고 직관적이다. 비즈니스 환경의 움직임을 자동차와 비교하면 이 생태계는 항상 accelerator-pedal을 힘껏 밟고 있다.
단순히 특정 방향으로 움직이고 있는것이 아니라 항상 가속을 하고 있는 것이다. 역사적으로 이 위태로워 보이는 질주를 지속하는 방법은 감속 장치((brake))를 발전시키는 것이 아니라, 더 단단한 섀시(chassis)와 스테빌라이저(stabilizer)를 보완하면서 동시에 더 빠른 가속 장치를 추가하는 것이다. Serverless 방식은 새로운 가속 장치이다.
산업 현장에서는 소프트웨어 시스템을 활용해서 비즈니스 기회를 확장하고 실행을 가속화 하고있다. 소프트웨어 제품의 구현과 유지보수도 이러한 속도에 발을 맞춰야 한다. 이 변화는 이미 정립된 기술 분야의 연속적인 발전으로는 설명하기 힘들다. 이 변화의 속도는 구조적인 진화에서 비롯된 것이다.
소프트웨어를 기초로 인터넷을 통해 연결된 디지털 세계는 비즈니스의 한 관점에서 보면 일종의 실험실이다. 위험(risk)를 효과적으로 관리 하면서 구상하고 있는 비즈니스를 실증하고 동작시켜볼 수 있는 기회다. 시장 경쟁 구도 속에서 이 실험을 얼마나 효율적으로 실행하고 효과를 극대화 하느냐 하는 것이 비즈니스의 경쟁력에 영향을 미친다. 개별 실험들은 시스템화 되면서 체계적으로 조직되어 개별 실험의 생명 주기는 더 빨라지고, 데이터로 확인된 기회들은 비즈니스 가치로 변환된다. 소프트웨어 개발, 즉 구현 관점에서는 실질적으로 동작하여 사용자에게 전달될 수 있는 소프트웨어 제품들이 이러한 프로세스에 맞춰 공급돼야 한다. 빨리 만들어서 사용자에게 공개 해야 하는 것이다.
일정 수준 이상 품질의 소프트웨어를 개발하는 역량은 개별 엔지니어의 역량과 밀접한 관련성이 있을 수 있다. 하지만 프로젝트의 규모가 일정 수준 이상 커지면 개인의 역량으로는 제어할 수 없는 위험 요소들이 생긴다. 그 중 한가지가 제품을 배포하고 변경을 관리하는 부분이다. 소프트웨어의 본질적인 속성에 의해 소프트웨어는 지속적으로 변경된다. 이 속성은 비즈니스 환경의 변화를 수용할 수 있는 기초가 되기도 한다. 문제는 이 변경이 동작하고 있는 제품과 지원하고 있는 비즈니스 성과에 영향을 미치는 위험 요소라는 것이다. 개발 과정에서 발견되지 못한 프로그램 오류나 기대하지 않은 부작용(side effects)과 같은 현상을 개별 엔지니어의 역량 만으로 통제 하는 것은 불가능한 일이다.
바꿔야 하는 것들
운영 환경(코드가 최종적으로 동작하는 환경)에서 개발하기
코드를 작성한 개발자가 확인해야 하는 것은 이 코드가 실제 사용자의 요청을 제대로 처리할 수 있는가 하는 것이다. 소프트웨어가 놀라울 정도로 잘 작동하기 때문에 사람들은 종종 실체적 복잡성과 위험에 대해 잘 생각하지 않는 듯 하다. 개발 환경에서 실행한 빌드의 결과와 배포 과정에서 실행한 빌드의 결과는 정말 같을까? 개발 환경의 느슨한 보안 정책으로 인해 잘 동작하던 외부 API연동은 운영 환경에서도 당연히 문제 없이 동작할까? 프로그램이 참조하고 있는 특정 환경 변수의 값은 내 컴퓨터의 메모장에만 존재하는 것은 아닐까? 컨테이너 기술의 보급은 큰 의미가 있는 진보이다. 작성된 코드가 최종적으로 사용자에 의해 사용될 수 있도록 만들기 위한 모든 단계에서 위험성을 제어할 수 있는 기반을 마련했다.
Serverless 방식을 고려 한다면 운영 환경은 일반적으로 클라우드 서비스가 제공한다. 클라우드 서비스에서 동작하는 개발 환경이 필요하고, 상당히 잦은 주기로 로컬 개발 환경의 작업물이 동기화 되고 테스트 케이스의 실행 결과를 확인할 수 있어야 한다. 여기에 더해서 Serverless 어플리케이션의 주요 전략 중 하나가 상태 관리의 책임을 분리하는 stateless라는 것을 생각 해 본다면, 상태를 관리하는 어떤 컴포넌트와의 연동이 필요할 것이다. 우리의 경험을 통해서 제안하고자 하는 방법은 클라우드 환경에 개별 소프트웨어 엔지니어를 위한 개발 환경을 제공하는 것이다. github에서 제공하는 Codespaces와 AWS의 CodeCatalyst와 같은 서비스가 좋은 대 안이다. 우리 팀은 개발과 운영 환경으로 사용하고 있는 AWS와 더 쉬운 통합을 위해 CodeCatalyst를 선택했다.
주어진 비즈니스 환경에서 성공에 기여하기 위한 소프트웨어 개발 전략과 기술적인 구현 사례
Poc(Proof of concept) 수행의 목적은 '만들어보는 것'이 아니라, 본격적인 비즈니스 모델의 실현에 진입하기 전에 비즈니스 모델의 가설을 데이터를 통해 검증하는 것이다. 동작하는 시스템을 통해 이해당사자 또는 불특정 사용자에게 아이디어를 노출시켜 피드백을 수집하고 분석하는 일이다. 이 과정은 빠르고 효율적이어야 한다. 또 한번 강조하고 싶은 것은 구현하는 것 자체가 목적이 아니라 아이디어에 대한 데이터를 확보하는 것이 진짜 목적이라는 것이다.
이러한 작업의 반복은 생각보다 유쾌하지 않다. 단순한 기능이 아니라 단 하나라도 비즈니스 시나리오를 실행할 수 있어야 한다. 유의미한 데이터를 확보하기 위해서는 시장에서의 비교 우위를 주장할 수 있 을 정도는 아니더라도 일반 사용자들이 일정 시간 머물면서 써볼 수 있을 정도는 돼야 한다. 트래픽이 어느정도 발생해야 데이터에 대한 해석이 가치가 있게 되는 경우들도 있기에 특정 목적의 마케팅이나 홍보 같은 활동을 진행할 수 있도록 시스템이 지속적으로 운영돼야 한다. 아직 비즈니스 모델 전체가 작동하지 않는 상황에서 아주 작은 자원들 일지라도 비용은 무시할 수 없다.
이미 알려진 많은 성공 사례에서 민첩하게 비즈니스를 서포트하는 시스템을 어떻게 개발하면 좋은지에 대해서 이야기하고 있지만, 잘 생각해 보면 그런 이야기들은 성공했기 때문에 성립되는 논리 인 경우가 많다. 현실은 아이디어를 아무리 잘 구현해서 치열한 논의 끝에 결정한 우리 브랜드의 도메인에 연결시켜 공개해도 아무일도 일어나지 않는다는 것이다. 팀 내부의 여러 가설을 증명하기 위해 테스트용 트래픽을 발생시키는 또 다른 개발을 하거나, 계속 쏟아져 나오는 여러 개발 및 운영 도구들을 찾아보면서 어떻게 적용시켜야 할지를 고민하면서 스크립트를 작성해야 한다.
그래서 필요한 것은 시간이다. 필요한 구현체를 더 빨리 만들어내고, 또 필요한 무언가를 해야 할 시간 동안 발생하는 비용을 줄이면 무언가를 할 수 있는 시간이 생긴다.
이 문제에 대한 해결 방법 중 하나는 사용량 기반 과금 정책 서비스를 최대한 활용하는 것이었고, 바로 Serverless 방식의 체택이다. 그리고 Microservice 설계 방식을 활용한 재사용이다. 서버를 계속 실행 상태로 유지할 수 없는 환경에서는 소스코드 레포지토리에서 다시 해당 부분을 복사하거나 패키지를 불러와서 코드 레벨에서 재사용이 이루어진다. 하지만 Serverless 방식을 통해 배포된 기능 들은 개발 작업 중이거나 배포된 상황에 상관없이 요청하고 응답을 처리하는 방식으로 이미 구현된 기능들을 재사용한다.
AWS Private Certificate Authority > Private certificate authorities
Mode: General-purpose | Type: Root
CSR
algorithm: RSA 2048