(younjin.jeong@gmail.com, 정윤진) 

Pivotal 에 입사한지도 이제 두어달 뒤면 일년이 된다. 참 세월이 빠르다 싶기도 하고, 그동안 무엇을 내가 잘했나 잘못했나 하고 뒤돌아 보니 다양한 감상이 생긴다. 아마존 웹 서비스 같은 회사를 왜 그만 두셨어요 하는 분들부터, 피보탈로 옮겼다 하니 역시 라고 말해주는 분들까지 정말로 다양한 피드백이 있었다. 사실 이러한 외부 피드백 보다 스스로 돌이켜 보았을때, 그리고 다른 회사들에서 동일한 시간을 보냈을때 라고 가정했을때 지난 일년동안 했던일, 또는 배웠던 일이 가치가 있었는가 하고 묻는다면 "당연하다" 라고 하고 싶다. 뭐 여러가지 이유가 있겠지만, 그런 이야기는 나중에 소주를 사주는 분들께 따로 들려드리기로 하고... (응?) 

어쨌든 지난 일년간 배운걸 가지고 어디다가 정리를 좀 해보고 싶은데, 이게 기술적으로 너무 단편적인 것들이 많아서 하나씩 올리면 전체를 보기가 힘든것 같다는 생각이 들었다. 그래서 아, 이 전체 일에 대한 플로우를 써 보면 어떨까 하는 생각, 그리고 그것이 소프트웨어 개발자 분들이나 프로덕트 매니징을 하시는 분들께 도움이 되겠다 싶어 이런 서두부터 살짝 긴 장문의 블로그 포스팅을 시작한다. 주제는 제목과 같다. 자, 이제 그럼 본격 시작해 볼까나. 

1. 가장 자주 목격하는 문제. 

대부분의 사업장, 특히 개발이 필요한 사업장에서 다양한 역할을 가진 분들을 만나면, 생각보다 서로 굉장히 다른 의견을 어필하는 것을 목격하곤 한다. 사실 내가 기본적으로 이해하고 있는 "회사"라는 조직은 큰 틀에서 사업부나 경영진에서 어떤 사업을 기획하면, 그것을 개발한 후에 운영의 단계를 가진다고 본다. 그래서 이를테면 이런저런 앱을 만들고 싶어용 하는 요구사항을 개발팀이 받아서 아 그건 이렇게 저렇게 구현해야해 하고 코드를 만들면 운영팀에서 어머 업데이트가 생겼네 하고 개발된 코드를 서비스한다. 최근 여기에 한꼭지 더 들어가는 것이 이제 분석 정도인데, 서비스를 돌려보니 이렇더라 하고 다시 사업부에 이런 내용을 던지면 그 이후의 사이클은 반복된다. 

http://www.supplychain247.com/article/want_to_innovate_your_supply_chain_break_the_rules

당연한 말이겠지만, 이걸 누가 얼마나 더 저렴하게 많이 하는가에 따라 그 기업의 경쟁력이 달라진다고 생각한다. 그리고 기업의 규모가 더 클 수록, 조직에 사람이 더 많을 수록, 그리고 의사 결정 단계가 많을 수록 이 속도는 느려진다. 보통 회사들은 같은 일을 하는 사람들끼리 부서로 묶고, 일을 부서에서 부서로 넘긴다. 기획부서에서 개발부서로 넘기는데, 만약 기획안 중에 개발이 불가능하거나 현재로서는 없는 기술이라고 하는 극단적 상황이 있다고 하자. 그러면 개발팀은 그것을 다시 기획 부서로 돌려보내고, 기획 부서는 그것이 왜 잘못되었거나 개발이 불가능한지 팀간 미팅을 잡는다. 그렇게 미팅을 하고 나면 그 내용을 기획팀에서 공유하고 다시 유사한 기획이 발생하지 않도록 검토 수정한 후에 다시 개발팀으로 보낸다. 그럼에도 불구하고 무언가 지속적인 문제가 발생하거나 한다면 개발팀과 기획팀의 각 장들, 그리고 부서장들간의 추가적인 미팅이 필요하게 된다. 그리고 이런 동작은 비단 기획과 개발 사이의 문제가 아니라 개발과 운영, 운영과 기획, 개발과 분석 등 동일한 서비스를 위한 이해관계에 있는 팀들 모두가 서로 복잡하게 얽힌다. 

이것은 서비스가 시장에 준비되는 속도를 느리게하고 이미 런칭한 서비스라도 고객의 요구를 반영하는 시간이 오래걸리도록 하는 문제이다. 그리고 많은 조직들은 이렇게 말한다. "우리 여태까지 그렇게 하고 있었는데요."

http://customerthink.com/weve-always-done-it-this-way/

이런 문제는 비단 큰 회사의 문제만은 아니다. 시장에서 주목을 받는 스타트업 역시 투자를 받고, 성장하는 과정에서 동일한 문제를 겪게 된다. 보통 처음 사업을 기획하고 서비스를 만들때는 사람이 적다. 두명에서 다섯명, 그렇게 시작한 스타트업은 빠른 의사결정과 개발속도를 가지고 서비스를 시작한다. 주목을 받기 시작하면 서비스에 요구되는 기능이 많아지고 관리할 대상도 많아진다. 더 많은 개발자를 충원하게 되고, 더 많은 운영자를 충원하는 과정에서 처음과 같은 멤버 보다는 기존의 개발 시장에서 일하던 사람들이 조직에 수혈된다. 또는 수혈받은 자금력을 사용해 경쟁관계에 있는 유사 서비스 회사를 인수하거나 하는 과정에서 조직은 순식간에 성장한다. 하지만, 서비스 개선 속도는 오히려 서너명 있을때 보다도 느린것 같다는 말이 나온다. 

이러한 조직과 프로세스의 문제는 곳곳에서 발견된다. 그리고 곳곳에서 해결되지 않는다. 해결되지 않는 가장 궁극적인 이유는, 다양한 경험을 보유한 것으로 보이는 사람들이 결국 모아 두고 보면 다 유사한, 즉 "오래된" 개발 문화에 익숙해져 있고, "오래된" 조직 구성 방법에 의존하고 있으며, "오래된" 조직 및 서비스 노하우를 그대로 사용하기 때문인 경우가 많다. 그리고 이런 이야기를 꺼내면 그래서 너네는 얼마나 잘하는데 라거나 한국에 그런 조직 있으면 나와보라고 하거나 하는 등 거부의 성향을 보인다. 당연하다. 변화가 반가운 사람들은 변화를 많이 겪은 사람들 뿐이다. 그리고 이런 사람들은 많지 않다. 

2. 그럼 어떻게  

https://blog.pivotal.io/labs/labs/design-critique-pivotal-labs

옆사람이 기획을 할 줄 알고 내가 개발을 할 줄 알고 내 오른쪽의 친구는 운영을 한다. 그리고 내 뒤에는 디자이너가 앉아있고, 이렇게 구성된 우리 팀의 주된 일은 로그인 서비스 개발이다. 기본적으로 API 로 다른 서비스와 연동하며, 관리의 편의를 위해 별도의 어드민 페이지가 있다. 업무의 수행, 전달, 확인은 모두 이슈 트래킹 도구를 통해 진행되며 별도의 보고를 위해 파워포인트나 엑셀을 만들지는 않는다. 우리 팀장님은 매주 월요일에 팀장 미팅에 다녀오면 이번주에 해야 할 일들을 이슈 트래커에 차곡차곡 정리한다. 정리가 끝나면 최대 1시간 정도의 팀 미팅을 한다. 이때 우리 팀 끼리만 미팅을 하는 것이 아니라 다른 팀 팀장 또는 서비스 매니징을 담당하는 쪽에서 함께 미팅에 참석한다. 그리고 전체 서비스의 방향과 새로 이슈트래커에 정리된 일들이 어떤 고객의 어떤 요청에 의해 발생한 일들인지 설명한다. 각 일들 별로 어떤 형태가 되어야 제대로 되는 것인지 완료 되었을때의 동작이나 디자인을 명시한다. 그리고 그런 일들의 기술 난이도와 우선 순위에 따라 분류한다. 한시간 정도 이런 미팅을 하고 나면 이번주에 해야할 일들의 윤곽이 잡힌다. 

http://www.stthomas.edu/news/silicon-valley-close/

아침에 출근하면 우리팀 말고도 전체 팀이 모인다. 한층에 모여서, 15분 정도 되는 간편한 미팅을 한다. 보통 스텐드-업 이라고 불리는 이 미팅은, 글로벌에 있는 우리 회사의 모든 팀들이 함께 들어온다. 그리고 누가 오늘 새로 입사했는지, 어제 무슨 큰일이 있었는지, 서비스에 크리티컬하거나 무지하게 궁금한 질문이 있는지 정도의 이야기를 나눈다. 마이크는 한번에 한사람에게 돌아가며, 10분에서 15분을 절대 넘지 않는다. 그렇게 아침 미팅을 하고 나면 다시 10-20분 정도의 팀 미팅을 한다. 이 미팅에서는 1. 팀과 관련된 주요 사건  2. 어제 해결이 안된일  3. 해결이 안된 일이 있다면 왜인지  4. 오늘 해결해야 할 일과 그래서 누구랑 같이 앉아서 일하면 좋은지  를 결정한다. 이 아침에 일어나는 두개의 미팅은 절대 앉아서 하지 않는다. 하나는 넓고 탁 트인 공간에서, 다른 하나는 팀 자리에 와서 작은 화이트 보드 앞에서 한다. 

https://www.glassdoor.com/Photos/Pivotal-Office-Photos-IMG455504.htm

둘이 함께 자리에 앉으면, 어떤 일을 해결 할지 이슈 트래킹 도구에서 선택한다. 선택의 요령은 일단 리스트상 윗쪽에 위치한 일이 프로덕트 매니저가 지정한 우선순위가 높은 일이다. 그리고 일을 해결하기 위한 조건을 살펴보고, 필요한 기술 스택에 대해 옆사람과 이야기 한 후 구현을 시작한다. 오늘 우리 로그인 서비스에 요구된 추가 기능은 트위터와의 Oauth2 연동이다. 기존의 인증 매커니즘에 추가적인 인증 소스를 더하는 것이다. 이 일의 해결을 위해 나는 오늘 로그인에 관련된 데이터 소스에 대한 정보를 다 알고 있는 친구와 짝을 지어 앉았다. 우리는 함께 앉아, Spring Boot 를 사용하여 만들어진 기존의 Facebook 연동과 Google, Amazon 인증 연동 방법을 간단히 살펴보고 Twitter 구현을 시작한다. 기본적으로는 내가 코딩을 하고, 옆에 앉은 친구는 내가 작성하는 코드를 보며 내가 중간에 틀리거나, 내가 구현하는 로직보다 더 좋은 알고리즘이 있다면 조언을 해 준다. 사용할 데이터베이스의 스키마 지정이나 테스트 코드의 추가에도 도움을 준다. 그렇게 새로운 기능을 하는 코드가 작성이 완료되면, 개발 환경에서 간단히 테스트 한다. 테스트에 별 문제가 없어 보이면, 코드 저장소에 업로드 한다. 업로드 된 commit 에는 나와 내 오늘 짝의 이니셜이 기입된다. 업로드 된 코드는 자동으로 회사에서 사용하는 테스트 도구로 전달된다. 그리고 이 테스트 도구는 보안성 검사, 취약성 검사, 서비스에 추가되어도 문제가 없는지 등의 의존성 검사등을 모두 자동으로 수행한다. 그리고 이 테스트 결과가 모두 녹색이라면, 테스트 시스템은 우리가 작성한 코드를 '스테이징'이라고 부르는 환경에 자동으로 배포한다. 

https://github.com/cloudfoundry-community/bosh-init-concourse

이렇게 스테이징 환경에 배포된 코드는 트위터와 로그인 연동이 적용된 상태로 동작한다. 그리고 이슈 트래커에는 특정 기능이 어떤 커밋 로그로 배포 되었는지 나타나며, 프로덕트 매니저는 이렇게 배포된 기능이 정상 동작하는지 바로 스테이징 환경에 접근하여 확인한다. 확인 뒤에 기능이 제대로 동작하며 문제가 없다면 Accept 를, 문제가 있거나 원래 의도와 다르다면 Decline 을 누른다. Accept 를 누르면, 이 커밋된 코드는 다음번 릴리즈에 배포되기 위해 추가 된다. 나와 내 동료는 Accept 가 된 것을 확인하고 잠깐 쉬기 위해 회사에 마련된 탁구대에서 3세트로 한게임 치거나, 비치된 스낵바나 냉장고에서 음료와 스낵을 가져다가 먹으며 이야기를 나눈다. 무엇을 하건간 약 5분에서 15분 정도의 휴식이 끝나고 나면, 다시 자리에 앉아 다른 일을 꺼내어 함께 시작한다.

http://www.wired.com/2013/11/pivotal-one/

코드 리뷰와 같은 과정은 없다. QA팀이 별도로 존재하지 않는다. 구현이 어려운 기능을 놓고 혼자 끙끙 앓고 있지 않는다. 애초에 대부분의 일을 30분 ~ 수시간 단위의 일로 쪼개는 것이 관건이고, 이것이 각각의 스토리로 관리가 된다. 그리고 일이 어렵건 쉽건 항상 함께 코드를 작성한다. 옆사람이 앉아서 세미콜론이 빠졌는지, 콤마가 빠졌는지, 더 좋은 라이브러리가 있는지 함께 앉아 조언해 준다. 그리고 이런 진행할, 진행중, 진행된 일들은 다른 팀의 누가 와서 보더라도 30분 정도만 투자하면 무슨 일이 어떻게 벌어지고 있는지, 이 팀의 개발 속도가 지금 어떤 상황인지 매우 손쉽게 알 수 있다. 즉, 투명하다. 

이런 팀들이 글로벌하게 존재한다. 나와 같은 로그인을 담당하는 팀이 저기 프라하랑 베이징에 두개가 더 있다. 우리는 같은 이슈 트래커를 공유하고, 그래서 우리 회사의 로그인 서비스는 쉬지 않고 개선된다. 퇴근할때 끄는 서버는 없다. 퇴근할때는 데스크탑만 꺼질 뿐이다. 여기서 일하면 보수도 좋다. 그리고 입사할때 인터뷰 자체가 그날 하루의 일정을 다른 엔지니어와 함께 하는 것이다. 내가 이력서에 기입한 내용에 대해 전화로 간단한 확인이 끝나면, 사무실로 면접을 보러 아침에 온다. 그러면 같이 스탠드업을 하고, 팀 미팅을 하고, 그리고 다른 피보탈 직원과 함께 이슈 트래커의 스토리를 해결한다. 그렇게 하루를 보내고 나면, 피보탈의 직원은 해당 면접자에 대한 피드백과 그가 작성한 코드를 기반으로 채용 여부를 결정한다. 당연히 입사한 사람들은 거의 즉시 일에 투입이 될 수 있고, 또 그런 직원들이 만약 다른 회사의 비전 또는 다른 스타트업에서 일을 하려고 할때 그는 이 회사의 경력이 매우 도움이 된다. 다른 회사들은 이 회사에서 일했던 기술자가 자신들의 회사에서도 일을 잘 할 수 있을것이라고 생각한다. 마치 아마존이나 넷플릭스에서 개발을 했던 사람이 그 회사에서 겪은 경험을 살려 새로운 비지니스를 도움 받았던 경험이 많기 때문에, 바로 그렇기 때문에 시장이 안다. 그래서 좋은 사람이 몰린다. 

3. 그래서 어쩌라고 

우리는 종종 불만 섞인 이야기를 많이 하거나, 듣고는 한다. 이래서 우리나라 소프트웨어 기술이 발전이 없다거나, 또 저거 삽질하고 있다거나, 뭔가 잘못된 일에 돈이 사용되고 있다거나 하는 주변의 수많은 이야기들. 그리고 그런 이야기들은 모두 각자 나름대로의 "한국 사람이라면" 이해할 만한 사연이 있다. 그런데, 만약 조직이 변화한다면 어떨까. 내가 하던 일의 방법이 바뀌고, 내가 어제까지는 그냥 내 자리에 앉아 혼자 일해도 되었는데 내일 부터는 다른 사람과 함께 앉아서 일해야 한다면 어떨까. 나의 능력이 과연 이런식으로 일을 하기에 적합할까. 그렇다, 바로 변화에 대한 공포가 조직을 지배하는 경우가 매우 많다. 

사업의 의사 결정권을 가진 사람들이 만약, 어떤 식으로든 조직의 개발 속도가 아마존 닷컴이 11초에 한번 업데이트 되는 속도를 당신네의 회사에서도 사용할 수 있다면 어떻게 하겠는가 라는 질문에 부정적으로 답변하는 사람은 없을 것이다. 이 로직이 가지는 장점이 전달 되면, 나머지는 비용과 시간의 문제일 뿐이다. 그리고 그래서 그렇게 했던 회사들이 어디가 있냐고 묻게 된다. 구글이 그랬고, 페이스북이 그랬고, 트위터가 그랬고, 이베이가 그랬고, 페이팔이 그랬고, 벤츠가 그렇고, 아우디가 그러며, 비엠더블유가 그렇고, 지이가 그런데, 폭스바겐과 포드도 그러고 있고, 컴캐스트도 그렇고, 비자, 제이피모건체이스, 휴매나, 올스테이트 기타 등등 산업도 다양하다. 왜냐! 소프트웨어가 필요하지 않은 산업은 없기 때문이다. 그리고, 그래서, 그렇기 때문에 이 관련 직군에 있다면 다가올 미래의 다양한 기회를 위해 준비를 해야 할 것이다. 사업가들은 이미 알고 있다. 규제와 제제, 자국 산업 보호, 이런것들도 사실 FTA의 영향에 따라 다양한 임팩트가 있을 것이다. 미국 물건 한국에 못파는게 규제때문이라고 하면 그 미국 기업도 미국도 가만히 있지는 않겠지. 

즉, 때는 온다. 따라서 두려워 피하지 말고 준비해야 한다. 그래야 그때 가면 경쟁력을 가질 수 있고, 이것은 준비된 사람과 아닌 사람을 가를 것이다. 

2012년에 아마존 웹 서비스 한번 살펴보라고 권고를 많이 하고 다녔더랬다. 2014년까지도 흥 관심 없어 하셨던 분들이 많다. 2015년에 회사가 전사적으로 아마존 웹 서비스를 사용하기로 했다. 그리고 그 분은... 

소개된 모든것이, 그리고 일하는 방식이, 문화가 정답은 아닐것이다. 다만, 현재 가지고 있는 많은 문제 중 하나는 개발 관련된 조직과 문화에 대한 to-be 가 좋은 모델이 별로 없다는 것이다. 구글이? 페이스북이? 그리고 그들이 자신들의 서비스를 잘 만들도록 구축한 문화를 다른 회사에 전달해 줄리가 없잖은가. 

http://enterpriseitadoption.com/

4. 위에서 설명한 내용들은 아래의 도구들에 기반하고 있다. 

http://pivotal.io/labs - 당연히도 피보탈 랩의 이야기니까. 

http://www.pivotaltracker.com  -  오픈소스 프로젝트는 무료로 사용할 수 있다. 

http://www.cloudfoundry.org   - 오픈소스는 그냥 가져다가 사용할 수 있으나, 운용 및 관리가 쉽지 않을 것이다. - 상용으로 Pivotal Cloud Foundry 가 있다. 호스팅 회사라면 한번 노려봄직 하다.  

http://www.concourse.ci - Docker 기반의 CI/CD 도구. 랩탑에 간단하게 vagrant 로 구성해서 사용할 수 있다. 

https://network.pivotal.io/products/pcfdev  -  랩탑이 맥북 프로에 메모리 만땅 정도 되면, Cloud Foundry 를 로컬에 설치해서 가지고 놀아볼 수 있다. CF의 구조 이해나 동작 방식, 또는 개발에 기여하고 싶다면 사용을 강추한다. vagrant 로 동작한다. 

http://github.com  -  오픈소스 프로젝트에는 이제 거의 당연하다고 해야. 사용법 정도는 기억하고, pull request 를 통해 기여를 하는것도 해 보자. 모든 프로젝트에 코드만 기여하는 것은 아니다. 번역이나 문서등을 한글화 하는 방법도 있으므로 시간이 되면 참여하는 경험을 쌓는 것도 보람진 경험이다. 

http://aws.amazon.com  -  위에 설명된 거의 대부분의 내용과 서비스, 그리고 개발은 이 위에서 돌아간다. 즉, 모르면 안되는 거다. 

http://azure.microsoft.com - AWS와 함께 알아두면 도움이 될 것이라고 생각한다. 

http://12factor.net   -  애플리케이션 개발 방법에 대한 일종의 가이드라인이다. 

http://spring.io   -   Spring 하시는 분들이라면 Spring Cloud 

엔지니어링 블로그들 

http://engineering.netflix.com 

http://engineering.pivotal.io 

http://nerds.airbnb.com 

http://engineering.instagram.com 

http://engineering.facebook.com 

http://www.wired.com/2013/11/pivotal-one/

소프트웨어 공장장

(younjin.jeong@gmail.com, 정윤진)