less is more

안녕하세요. StyleShare에서 커머스 개발을 맡고 있는 강성용입니다. 늘 모든 개발자들이 그러하듯, 어딘가에 올라가는 글은 원래는 거창한 주제여야 한다는 강박에 열심히 글을 쓰다(혹은 그런 생각을 하다가), 벌써 입사 이후 10개월이 지났습니다.

이런 식이라면 아무도 영원히 글을 쓰지 못할 것입니다. 그래서 아주 간단한 글로 시작해볼까 합니다.

많은 분들이 CodeDeploy라는 말을 들어본 적 있을 것입니다. 써보신 분들도 계실 것이고, 안 써보신 분도 계실 것입니다. 그리고 도입을 고려하는 분도 계실 것입니다. 이 글이 그러한 배포 도구를 선택할 때 도움이 되기를 바랍니다.

CodeDeploy는 2014년 경에 등장했습니다. 당시에도 이미 ECS는 있었습니다. 그러나 ECS는 특정한 기술(Docker)을 강요한다는 단점 아닌 단점이 있었습니다.

그렇기 때문에 CodeDeploy는 Docker를 적용할 수 없는 특정 환경에서 작업을 해야 하는, 안 그래도 이미 가상화 된 Cloud 플랫폼 위에서 더 이상의 Virtualization Overhead를 쌓기 싫은, 그리고 Task와 Task Definition, Service, Revision 등을 구분한답시고 만들어진 항공기 대시보드만큼이나 복잡한 대시보드를 보기 싫은, 또 그런 와중에 revision의 versioning 은 UUID지만 task definition 의 versioning 은 incremental 한 형태의 나이브한 postfix를 강제하는 안일함에 화가 난, 아무튼 각종 이유로 ECS가 마음에 들지 않는 엔지니어들에게는 하나의 대안이었습니다.

특히나 Deployment에 있어서 당시는 Environmental Deployment와 Source code Deployment가 혼재되어 이를 구분하려는 몸부림이 존재했습니다. CodeDeploy는 그러한 아이디어에 기반해, 순수한 AWS의 환경 위에서 Source code Deploy와 Environmental Deploy를 내부적으로 확실히 구분하면서도 심리스하게 동작시킬 수 있다는, 즉 ECS처럼 어플리케이션 배포와 소스코드 배포를 implicit하게 넘어가지 않고도 그만큼의 기능성을 확보할 수 있다는 확신을 가지고 시작한 프로젝트로 보입니다(물론 저는 AWS 개발자가 아니니 진실은 알 수 없습니다).

예전에 이와 90%이상 일치하는 컨셉의 Beanstalk 라는 제품이 존재하긴 했습니다만 사람들은 늘 같은 꿈을 꾸고 다음에는 더 잘 할 수 있으리라고 스스로 생각하곤 합니다. 저는 이러한 태도를 존경합니다. 인간이 복어를 먹게 된 이유도 결국 같은 이유일 테니 말입니다(먹으면 죽는 음식을 파는 건 다른 문제입니다만).

CodeDeploy의 이러한 시도는 일부 성공을 거두었습니다. 그러나 상기한 이유들로 인해 기존의 배포 도구 시장을 뒤엎지는 못했습니다. 만약 그랬다면 Kubernetes와 EKS의 출현은 조금 후가 되었을지도 모르겠습니다.

현대의 인프라스트럭쳐 시장에는 Kubernetes가 Gamechanger로써 등장했고 얼리어답터들은 기다렸다는 듯 EKS로 옮겨가는 추세입니다. 그만큼 사람들은 기존의 배포 도구에 만족하지 못하고 있다는 뜻이기도 합니다.

이 글은 2019년에 CodeDeploy를 적용하려는 회사들을 위해 남기는 메모입니다. 이를 공유함으로써 추후 다른 개발자들의 기술 선택에 도움이 되길 바랍니다.

CodePipeline과 사용시 주의할 점

CodePipeline 은 AWS의 각종 인프라스트럭쳐들을 Lambda로 체이닝하여 invoke함으로써 Continuous Deployement 라는 목적을 달성하기 위한 도구입니다. 보통 하나의 pipeline 은 AWS Codecommit/Github - Codebuild/Jenkins - Manual Approval - Codedeploy/EKS/ECS 등의 형태로 구성되곤 합니다.

이 도구가 하는 행위가 Continuous Integration 과 무슨 차이가 있는지는 어렴풋이 감이 오는 분도 계실 것이고 왜 있는지 모르겠다는 분도 계실 것입니다. 일단은 양쪽의 생각이 모두 맞습니다. 전자는 차치하고, 왜 있는지 모르겠다는 의견이 타당하냐면 CodePipeline의 완성도가 그리 높지 않기 때문입니다. 예를 들어 컨셉만 보자면 CodePipeline은 같은 리포지토리에 대해 Multi branch deployment 같은 걸 지원해야 할 것 같지만 안타깝게도 그런 기능을 지원하지는 않습니다. 만약 이를 달성하려면 Terraform 등을 병용하여 내부적으로 인프라를 별도로 관리해야 합니다.

아, 죄송합니다. 제가 방금 너무 있어 보이게 이야기했습니다. 정정하겠습니다. 일일히 브랜치마다 Pipeline을 손으로 만들어야 한다는 이야기입니다. 결국 특정 IaC solution 등을 통해서 사용하는 것이 아닌 이상 일반적으로 production과 staging용도로 사용하는 어플리케이션 두 개 정도 띄우는 게 일반적인 패턴이 됩니다.

단점을 먼저 열거했으나 CodePipeline가 가지는 장점은 상당히 큽니다. 아시다시피 Lambda의 컨셉은 매우 단순합니다. 일종의 function이죠. argument를 받아서 execute하고 필요할 경우 return을 하기도 합니다. 그리고 여기에 더해서, 하나의 pipeline은 동일한 scope안에서 순차적으로 이루어집니다. 일종의 sequential programmable flow-chart block이라고 보시면 됩니다.

이러한 컨셉을 AWS의 각종 서비스와 결부시키면 꽤 쓸 만한 서비스가 됩니다. 수백개의 서비스가 범람하는 마이크로-서비스-아키텍쳐 시대에 코드/빌드/배포를 일괄적으로 하나의 화면에서 관리할 수 있게 되는 것입니다. 심지어 이미 있는 것들을 활용할 수 있기 때문에 구성 비용이 크지도 않습니다.

물론 이것은 여러분이 AWS장애가 나면 자사의 서비스가 중단되는 시대에 태어났기 때문이기도 합니다. 마냥 기뻐할 일은 아닙니다.

CodePipeline과 함께 사용할 때, CodeDeploy가 전달받는 Build Artifacts의 확장자명은 .zip이 아닙니다

진짜 배포 파일의 Location

CodePipeline을 통해 invoke된 프로젝트가 Codebuild에서 넘겨주는 Build Artifacts는 Build step이 끝나고 S3에 업로드될 때 H4VB3Iu 같은 7글자의 Alphanumeric 한 이름을 갖습니다.

그리고 다음 step으로(CodeDeploy로) s3://bucket-name/application/H4VB3Iu.zip 이라는 이름을 넘겨주는 척 하지만 사실 그것은 Display name이 그럴 뿐이고 실제 Location은 s3://bucket-name/application/H4VB3Iu을 넘겨줍니다.

그래야 CodeDeploy 입장에서는 H4VB3Iu라는 파일이 zip으로 압축되어 있다는 사실을 알 수 있으면서도 실제 파일 이름은 H4VB3Iu일 수 있으니까요. 이는 CodePipeline으로 호출되는 CodeDeploy가 가진 암묵적인 약속으로 보입니다.

네, 동작이 조금 이상합니다.

물론 동작이 이상한 것과는 별개로 얼핏 보기에 사용하는 데에는 무리가 없어 보입니다. 어차피 머신이 flow를 컨트롤 하는 이상 이런 metadata는 인간에게 참고용일 뿐이니까요.

무슨 일이 일어나지만 않는다면 말입니다. 여기서 무슨 일이란 시간이 한참 지난 뒤의 롤백 등의 각종 이유를 든 CodePipeline을 통하지 않은, CodeDeploy 단일 실행을 통한 배포를 의미합니다. 그리고 그런 일은 자주 일어납니다.

재밌게도 CodeDeploy는 이 때 s3://bucket-name/application/H4VB3Iu라는 이름이 아닌s3://bucket-name/application/H4VB3Iu.zip라는 이름의 Build Artifact를 자동완성합니다(심지어, zip이라는 확장자를 제거하면 자동완성이 되지도 않습니다). 왜냐면 이전 배포 이력에 그렇게 남아있기 때문입니다.

그리고 이걸 믿고 배포했다간 어플리케이션이 뜨지 않고 배포가 실패하는 모습을 보실 수 있습니다. 심지어 이 경우 나는 에러는 File not found가 아닌 Access denied 에러이기 때문에 여러분은 절대 원인을 쉽게 발견할 수 없습니다. 아마 S3의 bucket의 policy부터 점검하기 시작하겠지요.

그리고 여러분은 진짜 원인을 찾느라 매우 추상화된 Sandbox 환경 여기저기를 한참을 들쑤신 뒤 원인을 발견하고는 허탈한 표정으로 커피를 들고 하늘만 하염없이 바라볼 것입니다.

하지만 괜찮습니다. 제가 여러분의 2시간을 구했습니다. 저에게 감사하셔도 좋아요.

Blue/Green 옵션 사용 시 주의할 점

Blue/Green이란 일부 인스턴스를 Warming up 시켜놓고 LB에 연결된 Blue 그룹과 Green 그룹을 Gracefully 서로 교체하는 옵션입니다. 이 동작이 실제로 Graceful한지는 둘째 치고서라도, 다들 ELB 혹은 ALB를 운용해 보았다면 이러한 식의 버전 배포가 익숙할 것입니다. 저도 이러한 작업을 Python script 로 만들어 배포 도구를 만든 적이 있습니다.

문제는 CodeDeploy의 책임과 역할이 이 Blue/Green Deployment에 있어서 과도하게 확장되었다는 사실에 있습니다. 왜냐면 필연적으로 Blue 그룹과 Green 그룹이 출현함에 따라 CodeDeploy가 그동안 전통적으로 수행했던 Source code deployment 뿐만이 아닌 Environmental deployment까지 그 책임이 미치기 시작했기 때문입니다.

본래의 CodeDeploy는 원래 특정한 인스턴스에 리비전만 다른 애플리케이션을 내부에 실행중인 agent가 서비스와 커뮤니케이션하며 버전을 교체하는 방식이었습니다(이를 in-place deployment라고 합니다). 그렇지만 Blue/Green 방식의 배포를 위해서는 어쩔 수 없이 Instance를 런칭하고, 제거하고 하는 등의 한 단계 위의 작업이 필요합니다. 그리고, CodeDeploy는 아마도 초기 설계 과정에서 앞으로 이러한 부분을 다룰 것이라 예상하지 못한 것으로 보입니다.

왜냐면 Blue/Green에는 이러한 가정을 바탕으로 한 것으로 보이는 수많은 문제들이 있기 때문입니다. 아래는 만약 여러분이 CodeDeploy를 Blue/Green Deploy로 사용한다면 필히 고려해야 할 점을 정리해봤습니다.

Blue/Green을 통해 런칭된 AutoScalingGroup에는 Target Group이 Implicit 하게 붙어 있습니다

여기엔 아마도 AWS의 private API 를 이용한 Trick 이 존재하는 것으로 보입니다. Blue/Green Deployment 를 통해 배포된 ASG의 Target Group은 빈칸이지만, 사실은 실제로 여기에 CodeDeploy에서 지정한 Target Group이 붙어 있습니다. 이유는 잘 모르겠습니다.

그러니까 단적으로 말하자면, "아, 없나보다. 다른 값을 내 마음대로 수정하고 저장해도 되겠지." 하고 저장하는 순간 Target Group이 분리되며 서비스는 장애를 일으키게 됩니다.

만약 CodeDeploy 배포로 만들어진 ASG를 손으로 수정해야 할 경우, 이 사실을 항상 염두에 두셔야 합니다. Target Group을 잊지 마십시오.

CodeDeploy ARN에 Blue/Green을 위한 별도 policy 를 적용해줘야 합니다

CodeDeploy의 기본 IAM 권한에는 Blue/Green 에 필요한 권한이 없습니다. 더욱 안타까운 점은 이에 대해 명시적으로 작성한 문서도 없다는 사실입니다. 다만 검색을 통해 누군가의 블로그 글을 찾을 수 있으며 이는 올해 2월에 밝혀진 버그입니다. 그리고 아직까지 수정되고 있지 않습니다.

어쩔 수 없습니다. 스스로 해결해야 합니다.

(참조 : https://h2ik.co/2019/02/28/aws-codedeploy-blue-green/)

"The IAM role does not give you permission to perform operations in the following AWS service: AmazonAutoScaling. Contact your AWS administrator if you need help. If you are an AWS administrator, you can grant permissions to your users or groups by creating IAM policies."

만약 여러분이 위와 같은 에러메시지를 보면 아래 Policy를 여러분이 사용하는 CodeDeploy Role에 별도로 추가해주시면 됩니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "iam:PassRole", "ec2:CreateTags", "ec2:RunInstances" ], "Resource": "*" } ] }

AutoScaling Group의 LifeCycle Hook이 중복되었는지 확인해야 합니다

이 버그는 Blue/Green 배포시 원래는 In-place로 배포했던 ASG를 복사하여 CodeDeploy를 통한 최초 시도 시에 발생합니다. Scheduled action이나 Cloudwatch alarm 등에 걸린 action에 의해 AutoScaling operation이 실행되면, 두 개의 LifeCycle Hook이(In-place 에서 쓰던 LifeCycle Hook과 Blue/Green 에서 새로 설정한 LifeCycle Hook) 서로 같은 인스턴스에 존재하게 되면서, 하나의 인스턴스에 두 가지 버전이 동시에 배포되는 비극이 일어납니다.

당연히 새 Instance에는 제대로 된 배포가 진행되지 않습니다. 그 인스턴스는 Create 된 직후 PendingWait 상태에서 Health check에 실패하여 Terminate 됩니다. 그러면 또 다시 ASG의 Desired capacity에 의해 다시 Instance가 런칭되고... 이런 상황이 무한하게 반복됩니다.

해결책은 간단합니다. Blue/Green 배포시 기존의 In-place에 있던 LifeCycle Hook을 삭제해줍시다.

Rollback을 하고 나면 AutoScaling Group의 LifeCycle Hook이 훼손됩니다

이 버그는 조금 치명적입니다. 여러분의 Deployment가 별 일 없이 끝났다면 이 문제를 밟지는 않겠지만, 아시다시피 현대의 웹 애플리케이션은 Buggy한 프로덕션을 롤백하는 일이 잦습니다. 이 버그는 만약 Blue/Green 배포가 끝난 버전에 대해 Rollback 할 경우 무조건 발생합니다.

상식적으로 Rollback이 실행 된 경우 LifeCycle Hook은 Blue version(롤백된 기존의 버전)에 다시 걸려 있어야 하고, Green version(새로 배포되었다 취소된 버전)에는 걸려있지 않아야 합니다. 그러나 롤백된 Blue Version 에는 응당 걸려있어야 할 LifeCycle Hook 이 없습니다.

이 LifeCycle Hook의 부재로, 현재 배포된 EC2 인스턴스를 제외한, 새로 런칭되는 인스턴스들에는 CodeDeploy의 automatic deployment 가 작동하지 않으며 애플리케이션의 아무 버전도 배포되지 않은 비어있는 인스턴스가 올라가게 됩니다. 그 결과 그런 깡통 인스턴스만 계속 떴다 죽었다를 반복하며 전반적인 장애내구성을 약화시키기 시작하고, 혹시라도 ASG의 Termination policy가 OldInstance 등으로 걸려있다면 여러분의 ASG는 순식간에 깡통 인스턴스로 가득찰 지도 모릅니다.

이 버그의 가장 큰 문제는, 이 상태를 문제가 생기기 전에 눈치채기가 쉽지 않다는 점입니다. 왜냐 하면, 이 문제는 평소에 잠재적으로만 존재하다가, Scheduled action 이나 Autoscaling Policy 등에 의해 Instance가 늘어났을 경우에만 가시화되기 때문입니다.

맺으며

이상으로 CodeDeploy를 production에 적용할 때 발생할 수 있는 주의점들에 대해 알아보았습니다. 생각보다 fragile한 프로덕트에 실망하신 분도 계실 것이고, 이 정도의 deployment system 을 만드는 데에 드는 비용에 비해서는 생각보다 낮은 trade-off 라고 생각하신 분도 계실 것입니다.

그러나 이래저래 따져도 가장 좋은 것은 위에서 언급한 주의사항들(이라고 쓰고 버그라고 읽는)을 더 이상 고려하지 않아도 되는 것입니다. 어쩌면 이 글을 통해 최근 EKS가 왜 주목받고 있는지를 실감하셨을 수도 있겠습니다.

여러 가지 사정으로 2017년에 PHP를 하게 됐다. 개인적인 감상으로는 뭐라고 할까, 삶은 언제나 우리에게 화두를 던진다. 그것도 하필이면 쉽지 않은 일들에 대해서. 그나마 다행히, 이 지옥의 밑바닥에도 빛은 있었다. 아직 좌절하지 말자. 2017년에도 여러 가지 사정으로 아직 PHP를 하는 사람들이 있을 것이다. 앞으로도 바꿀 수 없을지도 모르는 상황에서. 2017년에도 PHP를 한다는 것은 수라의 길이다. 파이오니어들은 이미 증발했고 시장 점유율은 꾸준히 감소하고 있다. 우리는 수라의 길을 가야 한다. 그러므로 지금부터 나는 수라의 길에 대해 적어보고자 한다.

PHP Version

5.6을 쓰자.

그렇게까지는 못하더라도 무조건 5.3 이상을 쓰자. 지금은 2017년이다. 내가 마지막으로 PHP를 했을 때도(대략 7년 전이다) 5.3이 있었다. 5.2와 5.3의 갭은 매우 크다. 고작 한 마이너 버전 체인지라고 믿을 수 없을 정도의 문법적 차이가 있다. 내 기억에도 5.3부터는 그나마 개발이 쉬워졌다. 매우 많은 부분 비어있던 PHP의 메타프로그래밍과 객체 지향 기반 프로그래밍 언어로써의 정체성을 좀 더 낫게 만들었다. 그리고, 그렇기 때문에 상식적인 패키지들은 아직 5.3을 지원하고 있다.

이 말은 5.3 이후로 PHP5가 그닥 나아지지 않았다는 의미이기도 하지만, 5.2에서 5.3로의 과감한 버전업그레이드가 그나마 PHP5의 명줄을 붙잡고 있을 수 있게 한다는 의미이다. 또한, 여러분의 PHP 프로그래머로써의 인생은 아직 희망이 있다는 의미이기도 하다.

PHP5.2 to 5.3 이라는 문서에 보면 친절하게 deprecated 된 함수 목록과 removed된 extension 들에 대한 목록을 적어놨다. New feature를 적용하는 것은 아직 바라지도 않으니 두 가지를 읽고 충분히 테스트 해 본 다음 기술 담당자에게 과감하게 건의하자. 거절하면 여러분에게는 좋은 퇴직 핑계가 생기는 셈이다.

Why 5.6

우리는 2017년의 개발자다. 2017년의 개발자는 현대적인 도구들을 사용해야 한다. 근데 (너무나 당연하지만) 모든 (그나마) 현대적인 라이브러리들과 패키지들은 5.3 이상을 쓸 것을 권하고 있다(정확히는 5.6이다).

Composer (사실 이걸 쓰기 위해서다!)

Sentry

Bugsnag (얜 심지어 5.5 이상을 쓸 것을 권장한다)

CodeIgnitor (얘도 그렇다)

더 가볼까?

Laravel 내가 봤던 가장 sane 한 PHP MVC 프레임워크고, 그렇기 때문에 PHP7 이상을 쓸 것을 권하고 있다

WordPress 심지어 워드프레스조차도 최신버전에선 php5.6 미만을 포기했다

Pthreads 자, 이 쯤 되면 우리가 어떤 길을 걷고 있는지 알 것이다. 우리는 7.2 이전에는 제대로 된 thread조차 쓸 수 없다.

더 필요한가? 더 필요하다면 당신은 설득이 이미 불가능한 레벨이라고 생각한다. 뒤로 가서 악플이나 달자.

Coding convention

PSR-1

PSR-2

Python 에도 PEP8이 있듯 PHP에도 PSR-1과 PSR-2란 게 있다. 요약하자면 PHP에도 기본적인 상식의 시대가 왔다. PSR-1은 단순하고, PSR-2는 PSR-1을 상속받으며 철학과 세칙을 강화했다. PSR-1은 "여러분 잘 때는 꼭 이를 닦도록 하세요" 수준이고 PSR-2는 "상식인으로써 이를 올바르게 닦는 법"에 가깝다. 아직 개인적으로 생각하기에 "충치는 입 속에 곰팡이를 막기 위해 만들어진 것이므로 이를 닦는 행위가 의미하는 것은 구강내 생태계를 일정하게 유지하기 위함이다" 수준의 고민은 없다(앞으로 코딩 컨벤션 문서가 3개 정도 더 나오게 되면 가능할지도 모르겠다).

PSR-1을 적용하는 건 쉽다. 이게 문제라고 한다면 PHP이전에 그 동안 자신이 얼마나 힘든 삶을 헤쳐왔는지에 대해 고민하고 새로운 것에 도전해야 한다는 문제의식을 가지는 것이 좋다. 세상에는 프로그래머 말고도 많은 가치 있는 일들이 있다는 사실을 상기하자. 그리고, PSR-2쯤 되면 MUST, MUST NOT, SHOULD 등의 표현을 잘 구분해서 써야 하는데 이 표현들의 구분은 RFC2119 에 명시돼 있다. 문제는 기존의 PHP개발자들이 이해하기에는 이 규칙이 너무 많다는 것이다(개인적으로는 SHOULD고 나발이고 다 적용하는 게 좋다고 생각은 한다. 생각은...)

PHP Code sniffer

우리들 PHP 개발자는 언제나 동료를 걱정한다. 그렇기 때문에 동료에게 PSR-2 문서를 던져주고 알아서 공부하라는 무책임한 짓은 하지 않는다. 대신 우리는 동료들에게 최소한의 규칙을 강제한다. PHP Code sniffer는 그런 역할을 한다. 책임자를 꼬셔서(안되면 무릎이라도 꿇자) php를 최소한 5.4로 올린 다음 꼭 composer 로 설치하자.

PHP Code sniffer는 phpcbf 라는 "자동 문법 교정" 바이너리가 있다. 왠만한 문법적 "잘못"은 다 교정해준다. YODA condition 같은 거나 120자 제한 같은 것은 잡기만 하고 교정은 못하긴 하는데, 어쨌든 그게 중요한 게 아니다. 조금이라도 더 나아진다는 것이 중요하다. 반드시 동료의 커밋 훅에 phpcbf와 phpcs를 통과하지 않으면 커밋이 취소되는 스크립트를 집어넣도록 하자. 설득을 하는 게 제일 좋지만 만약에 이뤄지지 않을 경우 협박을 해도 좋고, 속여도 좋으며, 그래도 들어가지 않는다면 CI에서라도 테스트를 실패하게 만들자. 팀장들은 높은 확률로 여러분의 편일 것이다. 만약 그러지 않는 팀장을 만났다면 팀장과 술을 한번 마시도록 하자. 당신에게 찬성하지 않더라도 CI 계정 비밀번호 정도는 알아낼 수 있을 것이다. 코드가 계속 실패한다고 당신에게 왜 이러냐고 물으면 "PHP버전이 업그레이드 됐나본데요?" 하고 시치미를 떼자.

글을 잘 쓰는 방법은 뭘까. 나도 잘 모르겠다. 그냥 좋은 글은 로또 맞듯 찾아온다. 어느 날 저녁을 먹고 집에 들어가기 전에, 너무 글이 쓰고 싶었다. 그것도 미련과 애틋함과 질척함과 애잔함이 뚝뚝 묻어나오는 글을 쓰고 싶었다. 아는 형이 운영하는 곳에 가서 술을 시키고 (당시엔 아직 바에서 흡연이 되던 시절이라) 담배를 물고 구석에 쳐박혀 30분 만에 엽편 하나를 썼다. 별로 다듬지도 않았다. 그리고 그 글은 썩 마음에 들었다. 지금 봐도 썩 마음에 든다. 그게 내가 기억하는 좋은 글을 쓰는 방법이다.

그럼 좋은 글을 쓰기 위해서는 술이 필요한가? 담배가 필요한가? 아니면 뭐가 필요했던 걸까. 로또를 맞기 위해선 뭘 해야 할까? 잘 모르겠다. 당시에는 글을 하루종일 쓰던 나날이었다. 술을 마실 때도, 담배를 피울 때도, 학교에서 심심할 때도 쓰고, 집에 가서 심심할 때도 쓰고. 그냥 숨쉬듯 글을 썼다. 어차피 나의 날 선 감정들은 아무도 들어주지 않을 테니까. 대신 글에 녹여냈다. 마치 독을 토해내듯.

그래. 글을 쓸 때는 항상 힘들고 우울했었다. 그럴 때가 아니면 쓸 수가 없었다. 배출할 거리가 없으니까. 결국에 목적은 단 하나였던 것 같다. 나는 나를 위해서 쓰지, 남을 위해서 쓰지 않는다. 내가 스스로 글을 잘 쓴다고 생각하는 이유는 그 때문이 아니었을지. 내 글은 언제나 나 정도는 위로할 수 있었다.

시간이 지날 수록 많은 일을 끌어안게 되는 것보다 가지고 있는 일들을 덜어내는 것이 훨씬 중요한 전략이라는 것을 배운다.

인간의 가능성은 무한하다는 말을 전적으로 신뢰하지는 않지만, 보통 인간은 왠만한 것은 다 할 수 있다. 글을 쓸 수도 있고 일을 할 수도 있고 게임과 술로 탕진할 수도 있고 커피에 대해 공부할 수도 있으며 아무튼 기타 등등 스스로 떠올릴 수 있는 일을 다 할 수 있다. 누구나 그렇다.

다만 "그러지 않겠습니다"하고 말하는 것은 힘든 선택이다. 가능성을 열어놓는 것에 대해 다들 긍정적으로 생각하곤 한다. 그러나 종종 "가능성을 열어놓는다"는 행위에서 사실 그만큼의 기회가 거기서 소비되고 있다는 점을 망각하곤 한다.

우버는 결국 한국에서 본격적인 리무진 사업을 하는 것을 포기한 것으로 보인다. 합법과 불법의 경계를 아슬아슬하게 넘나드는 그런 서비스가 구조에 개혁을 꾀할 수 있기 위해서는 (웃기지만) 민심을 흔들어놔야 했다. 다른 수송서비스들에 비해 가격, 친절, 사용성에 있어 모두 월등하고 탁월한 서비스를 제공했어야 했다. 그런데 고작 우버가 제공할 수 있었던 것은 몇 달 간의 우버X 프리라이딩 뿐이었다. 그것도 한 번 잡으려면 20분씩 걸리는. 개인적으로는 편하게 썼고, 유료화된 이후에도 썼지만, 남들에게 대놓고 추천할 수는 없었다. 물론 우버의 본거지인 SF에서는 상황이 좀 다른 것으로 알고 있긴 하다.

한편으로는 핀테크라는 단어가 한국을 또 (지겹게도) 강타하고 있다. 핀테크들의 가장 큰 장해물은 금산분리법이다. 나는 이 법을 개인적으로 좋아하고, 안 그래도 고부가가치 시장을 몇몇 대기업이 전부 장악하고 있는 마당에 안정적인 금융까지 손에 쥐게 되면 답이 없다고 생각하는 편이라 왠만하면 규제를 해제하지 않는 쪽을 원하고 있지만, 핀테크 회사들은 자신들의 성장을 위해 이 규제를 풀어야 한다고 주장한다. 이들 역시 합법과 불법의 미묘한 경계를 걷는 이들이다. 적어도 그들은 우버보다는 똑똑한 전략을 선택하고 있는 모양이지만 여전히 실패할 것 같다.

우버도 핀테크업체도, 위험한 선택을 했지만 결국 아직까지 아무것도 바꾸지 못했다. 왜냐면 아무도 모르기 때문이다. 개인적으로 뱅카를 즐겨 쓰긴 하지만 그건 내가 가진 직군과 소속된 집단 문화의 독자적인 성질 때문이지 집단 밖을 벗어나서는 딱 한번 써봤을 뿐이다. 우버는 지금 누구에게 추천하라고 하면 할 수가 없고.

왜인지 저 둘을 생각하다 보니 오늘 비로소 근래에 일어났던 사건에 대한 생각이 정리되었다. 둘 다 합법과 불법의 경계를 아슬아슬하게 넘나드는 것들이었기 때문일까. 법과 기존 아성에 도전하는 그런 시도들이 의미가 없다고 생각하지는 않는다. 우리가 정한 도덕/윤리와 법은 사실 지극히 주관적이며 또한 시류의 극히 흔한 사고방식을 따라가는 것으로써 나라와 문화마다 크고 작게 틀린 점이 있으며 심지어 그 적용에 있어서도 관점 차이가 존재하니까.

저는 짧게는 3년, 길게는 8년 스타트업-벤처에서 일을 했습니다. 야간개발팀이라는 개발팀을 기억하시려나 모르겠습니다마는, 그게 저의 첫 스타트업이고 벤처였죠. 지금은 스포카라는 회사에서 일하고 있습니다. 스포카에서 저는 제가 만난 최고의 파트너들과 일하고 있고, 당당하게 다들 대단한 사람들이라고 추천할 수 있습니다.

신뢰.

저는 그 사람들을 신뢰하고, 그 사람들이 내가 가진 스톡옵션을 더욱 커다란 자산으로 만들어줄 수 있을 거라고 생각합니다. 이 신뢰의 문제는 엄청난 겁니다. 당신이 나를 곤경에 빠트리지 않으리라는 확신이 있다면, 엄청나게 많은 불필요한 잡음들이 문제가 되지 않습니다. 당신이 만약 내 친한 친구고, 내 책상에다가 커다란 장난질을 쳐 놔도, 그게 날 웃기기 위한 장난이라는 확신이 있다면 별 문제가 되지 않듯 말입니다.

우리가 잡음 없이 일을 하려면 상호 신뢰가 전제됩니다. 스타트업은 도박입니다. 시간을 스톡옵션으로 치환해 베팅하는 도박이죠(물론 그렇지 않은 분들도 계십니다만). 매년 살아남는 스타트업은 극소수고, 그 중에서도 성공하는 스타트업은 살아남은 스타트업 대상으로 계산해봐도 극소수입니다. 어쩌면 수지 맞는 장사가 아닐 수도 있습니다.

그럼 왜 우리는 수지 맞지 않는 장사인 스타트업을 하고 있을까요?

개인에게는 여러가지 이유가 있을 것입니다. 대기업보다 나은 복지와 연봉일 수도 있고, 좋은 팀원들에 그 이유가 있을 수도 있고, 집에서 가까워서, 그냥 대기업을 못 들어가서 잠시 거쳐간다는 생각으로 있을 수도 있고, 다른 기업 문화가 안 맞아서, 월급으로 버는 돈보다 많은 돈을 벌기 위해서 등등.

수많은 목적이 있을 거고 개인의 이유는 각기 다를 것입니다마는, 그래도 전반적으로 저는 어떤 한 가지 이유를 꼽고 싶습니다.

얼마 전에 일 잘할 수록 따돌림당하는 한국 직장인들이라는 글을 보게 되었습니다. 저는 이게 제 개인적인 행운 때문인지, 아니면 다른 어떠한 이유 때문인지 모르겠지만 한번도 일을 잘 해서 돋보인다는 이유로 왕따를 당하는 사람이 있는 회사를 다닌 적이 없습니다.

다른 이야기를 해 보겠습니다. 스타트업의 핵심은 성장입니다. 정확히는 회사 가치의 성장이죠. 스티브 잡스는 애플을 스타트업으로 규정하였습니다. 애플은 그 커다란 덩치에도 매년 놀라운 성장률을 보이고 있고, 성장을 위해 많은 투자를 하고 있기 때문입니다. 즉 애플의 목표는 성장이지 기득권 유지가 아닌 것입니다. 일반 중소기업 혹은 대기업과 스타트업의 핵심적인 차이는 바로 그 성장에 대한 목표의식에 있습니다(많은 사람들이 스타트업의 핵심을 열정 혹은 Entrepreneurship 이라고 하지만, 저는 그렇게 생각하고 있지 않습니다. 그렇게 말하는 건 매우 쉽지만, 올바른 답은 아닙니다).

그래서인지 스타트업을 지배하는 커다란 문화가 있습니다. 회사를 성장시킬 수 있는 사람이 최고입니다. 스타트업의 제1원칙은 성장이고, 그것을 위해 모든 것을 내려놓아야 합니다. 적어도 스타트업을 다니는 당신은 그렇지 않을지라도 당신이 다니는 회사의 창업자는 그럴 것입니다(만약 그렇지 않은 회사에 다니고 있다면 더 좋은 곳을 알아보는 것을 추천합니다).

한 번 생각해 봅시다. 당신이 매우 싫어하는 A라는 사람이 있습니다. 어떤 정치적인 신념 때문에 대립한다고 해 봅시다. 당신과 사사건건 부딪히지만, 그가 기여한 프로덕트는 계속해서 당신의 스톡옵션을 몇배씩 뻥튀기해주고 있습니다. 이 경우 당신이 그를 밀어내기 위해 무언가를 한다면 당신은 자신의 미래자산 가치를 스스로 깎아낼 뿐만 아니라 당신 동료들의 자산도 같이 쓰레기통에 던지는 겁니다.

성장을 위해 달려가야 하는 사람들에게 다른 사람을 질시하고 경계하여 배척한다는 것이 가당키나 한 것일까요? 물론 그럼에도 불구하고 그런 행동을 할 수 있습니다. 인간이니까요. 당신은 때때로 유혹에 빠질 겁니다. 당신의 동료들도 당신을 배척하고자 하는 유혹에 빠질지도 모릅니다.

대기업에서 남을 밀어낸다고 자신에게 돌아오는 디메리트는 크지 않습니다. 오히려 자신의 가치를 상승시켜 연봉을 높게 받을 수 있는 계기가 됩니다. 그건 어쩌면 오히려 옳은, 영리한 행동입니다.

그러나 스타트업은 그런 행동을 막기 위한 장치로 스톡옵션을 제공합니다. 당신이 스톡옵션 계약서에 사인하는 순간 당신은 이 성장을 위한 긴 여정에 합의하는 것입니다. 그리고 다른 사람도 이런 '성장'에 합의하리라는 생각을 가지게 되죠. 이 생각은 신뢰로 이어집니다. 그리고 그것은 스타트업을 지탱하는 핵심 가치입니다. 스타트업의 좋은 문화라는 점들은, 이러한 구조적 신뢰에서 나오는 것이라고 저는 확신합니다.

저는, 이게 바로 스타트업과 기존 기업의 가장 큰 차이점이라고 봅니다.

저는 상호 신뢰를 좋아합니다. 저는 믿을 수 있는 사람들과 일하고 있고, 같이 일하는 사람들을 언제나 믿고 싶습니다. 그리고 이 생각은 저에게 수많은 잡음들을 무시하게 합니다. 업무 시간에 늦어도, 졸고 있어도, 지나갈 때마다 잡담을 하고 있어도, 나에게 화를 내고 마음에 들지 않는 행동을 해도 저는 그 동료를 신뢰하고, 당연히 자신의 스톡옵션을 높이기 위해 열심히 일할 거라고 생각하게 합니다(그리고 그 사람을 좋아하게 되죠). 스타트업이란 정말 길고 긴 여정이고, 언제나 하루종일 전투 태세일 수는 없으니까요. 오히려 돈을 벌어다주는 사람들에게 이 정도 이해는 당연한 것 아닐까요?

그리고, 성장과 스톡옵션에 합의하지 않는 사람이라도, 당신이 스타트업을 선택한 그 어떤 이유를 가지게 된 데에는 스톡옵션으로 엮인 절대적인 신뢰가 선행함을 알아야 합니다. 당신은 스톡옵션에 사인하지 않았지만, 사실 그 이유에 사인한 것이니까요. 그리고 그 이유는 신뢰가 보호해주고 있는 것이기 때문입니다.

p.s

저는 서로 신뢰로 엮인 스타트업에서 일하고 있습니다. 그리고 제가 다니는 스타트업은 매우 훌륭한 기업문화를 지니고 있습니다. 이런 보도 자료를 얼마나 신뢰할 수 있을지는 잘 모르겠지만, 스무 살 때부터 계속 어떤 조직에 속해 일해온 제가 느낀 회사 중 가장 좋은 회사에 다니고 있습니다. 하루 하루가 전쟁터인 스타트업에서 어깨를 나란히 할 수 있는 동료들과 일하고 있다는 사실은, 제가 느끼는 저희 회사의 가장 큰 장점입니다.

생산성을 높이려면 야근하지 마라

너무 많이 일하지 마라. 1926년 포드 자동차 회사 설립자인 헨리 포드는 실험에서 재미있는 결과를 얻었습니다: 근로 시간을 하루 10시간에서 8시간으로, 주 당 6일에서 5일로 줄였더니 생산성이 높아졌다.

일주일을 통틀어 10%정도의 오버워킹은 괜찮을 지도 모른다. 하지만 그 이상은 안된다.

야근을 하게 되는 과정에 대해 생각해 보자.

커다란 일이 불가능한 시간 안에 주어진다.

야근을 한다

(신의 은총에 의해, 혹은 우주의 의지에 의해, 아니면 운명의 장난에 의해, 혹은 그에 준하는 기적에 의해) 어떻게든 시간 안에 일을 맞춘다

칭찬을 받는다.

축하한다. 당신은 이제 큰일났다(X됐다).

이제 당신의 상사와 당신의 동료와 당신 자신이 생각하는 당신의 업무처리능력은 야근을 해서 일을 해낸 것만큼 늘어났다. 당신은 이제 앞으로 1에 주어진 양만큼의 일을 계속 하게 될 것이다. 야근의 함정에 빠진 것이다.

당신은 당신을 그동안 지탱해왔던 취미를 포기해야 한다.

더 나가면, 당신은 점점 더 잠을 못 자게 된다.

잠을 못 자니, 당신의 업무처리능력은 점점 더 떨어진다

일을 못 하니, 당신의 자존감은 점점 더 하락한다

당신의 일에 대한 열정 또한 점점 더 내려간다

당신은 당신을 불행하게 하는 일로 인해 어느 순간 이직, 휴직, 퇴사를 알아볼 것이다(Burnout).

이는 당신과 당신의 동료, 당신의 회사에게도 불행이다. 당신은 야근을 하면 안 된다.

작년 12월쯤에 페이스북에 쓴 글이다. 이 글을 슬슬 다시 가져올 때가 되지 않았나 싶다.

결국 이러니저러니 해도 워크라이프 밸런스는 개인이 맞추어야 한다.

아침에 일어나 지각을 하면 우버나 카카오 택시를 타고 회사를 간다. 지갑을 두고 나오는 바람에 점심값을 대신 결제해준 사람에게 뱅크월렛카카오로 점심값을 보낸다. 단골 카페에 들어가 커피를 테이크아웃하며 도도포인트로 적립을 한 뒤 사무실로 돌아온다. 좋아하는 아티스트의 신곡이 나오면 아이튠즈 뮤직 스토어에서 다운로드받는다. 문득 샤오미 체중계가 사고 싶어져 쿠차에서 최저가를 검색한다. 한창 일하다가 입지 않는 겨울옷을 빨아야겠다는 생각을 하고 크린바스켓을 불러 세탁 수거일을 정한다. 돌아온 집은 덤앤더머스에서 제공하는 덤덤우렁각시가 깨끗하게 치워주었다. 그러고 보니 이번 주말은 이케아가 세일을 한다. 아는 사람과 같이 쇼핑을 가기로 했다. 다들 차가 없었기에 쏘카에서 차를 빌리기로 했다. 돌아오는 길에는 코스트코에 들러 식료품을 샀다. 조금 있으면 계약 만료일이 다가오기 때문에 직방으로 집을 알아보았다. 당장은 마음에 드는 집이 보이지 않지만 천천히 찾다보면 나올 것이다. 예쁜 집들을 보다보니 왠지 모르게 며칠 예쁜 집에서 살고 싶다는 생각이 들어 에어비앤비로 숙소를 찾으며 여름 휴가를 계획했다.

위에 열거한 서비스는 덤덤우렁각시를 제외하고는 내가 한번 이상 써본 서비스들이고, 만족했으며, 다음에도 이용할 의향이 있는 서비스들이다.

이미 20대의 소비 패턴과 더불어 라이프스타일 커머스는 이전과는 전혀 다른 양상으로 변화하였고 경쟁자들보다 훨씬 더 똑똑한 기업들이 전통적인 영역을 대체하였다.

다른 사람들에게 일처럼 보이는 것이 당신에게는 일이 아니라면 그것이 당신의 적성이다. 예를들어 나를 포함해 많은 프로그래머들이 (투덜대면서도) 사실은 디버깅을 좋아한다. 어떤 사람들은 디버깅을 스스로 찾아하는데 그게 사실 자원해서 할만큼 그렇게 즐거운 성격의 일은 아니다. 그렇지만 어떤 사람들은 여드름 짜내며 희열을 느끼는것처럼 디버깅을 좋아한다. 그런데 프로그래밍에 디버깅이 얼마나 중요한 역할을 하는지를 따져보면 프로그래밍을 좋아하려면 디버깅 역시 좋아해야만 한다.

일처럼 느껴지지 않는 것들

적절한 비유인지는 모르겠으나, 요즘 결국 히어로 액션으로 귀결되는 헐리웃 블록버스터들이 칠리 소스 잔뜩 끼얹은 타코나 부리또 따위의 멕시칸 푸드를 떠올리게 한다면 버드맨은 그와는 달리 미식에 갓 눈을 뜬 자들이 접할 만한 파인다이닝을 연상케 한다. 그것도 자기 주장이 강한 요리사의. 쉐프는 식사 내내 메뉴를 어떤 식으로 먹어야 하는 지 강요하고, 그 사이사이에서 분명 독특한 해석과 세련된 기술에 대한 놀라움과 반가움이 없는 것은 아니지만, 결정적으로 전체적인 식사의 흐름은 불편하고, 더부룩하며, 맥락을 파악하기 힘들다.

최근 유통 구조가 뭔가 신기하게 변했다. 오프라인과 온라인을 통틀어 판매되는 모든 상품에는 할인률이 붙어있는 게 당연하고 그렇지 않은 경우 "아, 이 상품은 아직 살 때가 아니구나" 하는 인식을 먼저 준다. 말인즉슨, 사람들 사이에서 정가라는 개념이 희박해지고 있다.

일단 회사는 터무니없는 가격의 소비자가를 책정한 뒤, 선심 쓰듯 무지막지한 할인율을 제공해 소비자 단가를 맞춘다. 이러한 가격 책정의 가장 큰 장점은 따로 마케팅을 하지 않아도 가격 책정만으로 할인 프로모션/마케팅이 가능하다는 것이다. 그렇기에 회사 입장에서는 가격 뻥튀기/할인율 뻥튀기는 기본적으로 해야 하는 것이 되었다-너의 지갑을 오늘도 흔들고 있는 스팀을 보라!

규제의 시작은 이러한 현실에 대한 인식에서 시작한다.

회사는 무지막지한 기본 가격을 형성하고 무지막지한 할인율로 결국 최종 제공 가격에 대한 소비자의 커먼 센스를 흐트려놓는 시도를 한다. 거기에 넘어가면 운이 좋은 경우 소비자는 "적당한 가격의 소비"를 하게 되고, 대부분의 경우 과소비를 하게 된다.

사실 프로모션이라는 게 다 그런 거 아닌가. 당신들 모두 퇴근길에 아버지가 싱글벙글하면서 "이 앞에서 싸게 팔더라구" 하면서 이상한 노점 물품을 사오면 분노한 어머니가 아버지의 등짝을 후려치는 장면을 한번쯤 본 기억이 있을 터이다. 필요 없는 물건을 사게 하는 것은 전부 다 사기이다.

그래도, 여기까지는 괜찮다. 왜냐면, 대부분의 상품은 일회성 지출이라, 한번 데였다 싶으면 다시 안 사면 그만이기 때문에.

그러나 통신사 이야기가 되면 달라진다. 현재 통신은, 그 중에서도 무선 통신은 내 생각에 이 나라에서 생필품이 되었다. 심지어 국가조차도 그에 대해 인식하고 있다. 그 증거로 기초수급가정과 차상위계층 가정에는 국가에서 통신금을 보조하기까지 한다. 우리는 인터넷이 생존을 위해 꼭 필요한 시대에 살고 있는 것이다.

그래서 국가로써는 통신사에 손을 댈 수 밖에 없었다. 모두가 무식하던 시절, 이 나라에서는 '몰아주기'가 유행하고 있었다. 중간 과정은 생략하고 결국 그 몰아주기로 세 개의 거인 통신사가 탄생했다. 그리고 뒤이어 이들은 망 중립성을 훼손하며 직접 단말기 유통과 그 부가 산업들에 참여하게 된다.

누구인지는 몰라도, 누군가가 이러한 유통 구조와 이러한 국내 통신사의 구도는 위협적이라고 생각한 게 분명하다. 현재 통신사는 고객과 단말기 제조사 사이에서 유통과 가격 책정을 마음대로 할 수 있는 위치에 있다. 이 구조를 허물기 위한 여러 시도가 있었다. MVNO 강제, 요금제 규제, 보조금 규제, 그리고…

이런 상황에서 단통법은 더 이상 거대 통신사가 유통망과 가격 형성을 멋대로 휘두를 수 없도록 그들에게서 최소한 단말기 가격에 대한 주도권을 뺏어 소비자에게 다시 던져주겠다는 의지의 표명이라고 해석된다. 그래서 나는 모 의원이 했던 "단통법이 소비자 혜택(보조금) 주려고 만드는 법"이 아니라는 말을 이해한다. 단통법은 소비자에게 정가를 돌려주기 위한 법이다. 소비자보다는 시장 자체에 중점을 둔 법이라는 이야기다.

혹시 아는지 모르겠지만 단통법 시행이 슬슬 2개월째를 맞아가는 지금 KT에서 순액요금제가 나왔다.이 순액요금제란, 그동안 "2년 약정"이니 "3년 약정"이니 하며 강제해 왔던 소비자 이탈을 막는 장치를 스스로 포기한 요금제다. 즉, 계약기간 내 임의 탈퇴에 대한 패널티를 부여하지 않는 제도다. 아직 KT만 나왔고 SKT와 LGT에는 존재하지 않는다. 하지만 아마 두 회사도 나오게 될 것이다. 항상 그런 식이었다.

제도로 인해 시장은 또 다시 변화하고 있다. 규제가 성공할지, 아니면 결국 또 다시 기형적인 구조가 만들어질지는 모르겠다.