오종인

시간이 많이 지났지만 저희 회사 개발 팀빌딩 관련해서 신기해하고 궁금해하는 분들이 몇분 계셨었습니다. 개발자가 씨가 말랐다는 채용 시장에서 서버 개발자를 3명이나 확보하고 Android, iOS, Front-End Web 개발자까지 총 6명(저 포함)의 개발팀을 구성했다는 것이 많이 신기하셨던 듯 싶습니다.

당시에는 팀 빌딩이 제 능력이라고 농담 삼아서 이야기 했지만 개발자 구인에 어려움이 있는 저와 비슷한 처지에 있는 분들께 도움이 되실까 해서 아침 영어학원 빼먹고 회사에 조금 일찍 출근해서 제가 요즘 겪는 경험을 두서없이 풀어볼까 합니다.

잘나가는 회사들이야 굳이 높은 연봉이 아니더라도 회사 브랜드 또는 근무하는 연옌급 개발자만으로도 개발자들이 앞다퉈서 지원하니 서류 전형이니 코딩 테스트니 하는 채용 절차에서부터 ‘구글은 어떤 사람을 채용하는가‘같은 고차원적인 채용 철학 도입을 위해서 고민하고 때로는 이런저런 조건들을 까다롭게 검토하면서 조직에 딱맞는 동료를 찾지만,

우리 회사 같이 돈도 없고 알려지지 않은 듣보잡은 어디서 개발자 구하기가 하늘의 별따기라 회사 개발팀 셋업 시기에 일찌감치 SI 출신 개발자를 채용했습니다.

예전에 회사에서 SI 출신 개발자와 계약직으로 일한 적이 있었는데, 일을 너무 잘해서 정규직으로 채용했더니 막상 정규직으로 채용한 이후에는 업무 스타일 차이로 인해서 너무 고생했던 기억이 있던터라 피하고 싶었던 상황이었습니다.

돌이켜보면, SI 개발자와 계약직으로 업무를 진행할때는 계약에 명시된 명확한 업무를 할당하고 혹시나 엉뚱한 결과물이 나오지 않을까 꼼꼼하게 점검하기 때문에 대부분 결과물에 만족을 했었는데, 정규직으로 채용한 이후에는 미션만 주고 알아서 스스로 업무를 진행하도록 했더니 스스로 스트레스를 많이 받기도 했고 이런 저런 업무 스타일 차이로 충돌이 잦았었던 것 같습니다.

이러한 경험으로 인해서 이왕이면 서비스를 경험해본 개발자 또는 자기 주도적으로 업무를 수행할 수 있는 개발자 또는 영혼에 기스가 없어서 해맑은 개발자면 좋겠다는 생각을 했는데, 막상 현실은 “Java 2명이요~” 였습니다. (진짜로 Java 개발자 2명이 가장 처음에 합류했….)

결과론적으로 서비스 초기에 합류한 개발자들이 너무 일을 잘해줘서 서비스 안정화를 비롯해서 외주 개발로 인해서 확장이 불가능했던 구조적인 문제에도 불구하고 사업적 확장을 위해서 땜질하는 등 지난 몇개월동안 참 많은 변화가 있었습니다.

요즘에 와서 느끼는 것인데 ‘만약 SI 출신 개발자가 아니었다면 지금 상황을 만들 수 있었을까?’라는 질문을 해보면 결과론적으로 쉽지 않았겠다라는 생각을 합니다.

서버 개발자 면접(?)시에 회사 사업에 대한 브리핑과 개발 진행 상태 등 합류하더라도 전체적으로 쉽지 않은 상황임을 공유했는데, 서버 개발자 입장에서는 워낙 많이 겪어본 일이라 다시는 겪고 싶지 않은 상황이기도 했지만 어떻게 해결해야 하는지 누구보다 많이 경험해보기도 했던 일이기도 했던 것 같았습니다.

그렇다고 SI 출신 개발자와 일하는 것이 절대 녹록한 상황은 아니었습니다.

처음 면접시에 앞으로는 SI 처럼 일하면 안되고 소위 말하는 ‘정신개조’가 필요하다고 수차례 강조했고 본인도 수긍했지만 일하는 과정에서 불쑥불쑥 튀어나오는 트라우마로 인한 스트레스는 너무 많은 사람들을 힘들게 했습니다.

서비스에서 사업적 판단에 의해서 계획이 자주 바뀌고, 개발 측면에서 Rework이 잦아지고 일정도 빠듯한데 이 모든 상황이 스트레스로 작용하는 듯 했습니다.

물론 이 상황이 스트레스인 점은 분명하지만 장기적으로 지속 사용 가능한 설계를 하고 일정에 맞춰서 차근차근 완성이 되고 최초 약속한 내용에서 조금이라도 변화가 생기면 이슈가 되어서 일정 협상이나 개발 공수 협상을 하던 것이 몸에 배어 있고 일정을 지키지 못했을때 ‘갑’으로부터 받는 불이익이 두려워서 어떻게든지 무조건 맞춰야 하는 강박관념 비슷한 면이 종종 표출되기도 합니다.

그럼에도 불구하고 요즘 같이 개발자를 구하기 어려운 시기에는 SI 업계가 개발자를 수급할 수 있는 마지막 블루오션이 아닐까 생각하고 있습니다. (SI 업계에서 개발자를 빼와서 개발자 씨를 마르게 해야 돈만 주면 쉽게 구할 수 있는게 개발자라는 업계 마인드를 바꾸고 SI 개발자들에 대한 처우가 좋아지는 부수적인 효과도..)

개발자를 채용해야 하는 스타트업은 카카오, 라인, 네이버 같이 공룡들이 지배하는 채용하는 시장에 들어가지 마시고, SI 업계에서 옥석을 가려서 동료를 찾으시면 좋지 않을까 생각합니다.

주말과 새벽을 불태웠던 장애가 사라지고 조직이 안정화되니 자연스레 회사의 방향이 수비에서 공격으로 전환되었습니다. 게다가 올해 상반기 중에 달성하고자 했던 내부 목표를 작년 말에 일찌감치 달성하고 나니 가뜩이나 맨땅에서 시작해서 할 일이 많은 스타트업 개발조직에게는 추가로 할 일들이 재앙 수준으로 다가 왔습니다.

공격을 위한 개발을 진행해야 하는데 운영 업무로 인해서 개발 리소스가 분산되면서 일정이 계속 지연되는 문제가 있어서 회사 내부에 운영 업무를 당분간 안하겠다고 극단적인 선언을 했음에도 어쩔 수 없이 해야 하는 운영 업무가 지속적으로 발생하고 자동화가 덜 된 백오피스로 인해서 일부를 수작업으로 진행하다 보니 사소한 데이터 추출 조차도 개발 공수 투입이 불가피한 상황이 지속되고 있습니다.

지금까지 다녔던 회사에서는 이런 상황을 맞닥뜨리면 외주 인력을 추가로 투입하거나 불가피한 상황을 공론화해서 사업 쪽이 기다리게 하거나 운영 업무를 기존 관리 조직으로 이관하거나 다른 대안을 경영진이 결정하도록 보고 하고 기다리거나 하는 수동적인 대응이 중간 관리자로서 할 수 있는 차선이었습니다.

어쩌면 지금까지 다녔던 회사에서는 수익이나 생존에 대한 걱정이 개발 조직에는 절박하지 않았기 때문에 고객사와의 계약 지연이나 매출이나 사업적인 부분을 개발에 반영하지 않았던 것 같습니다.

하지만 스타트업에서는 투자받은 금액으로 조직이 장기간 생존하기에는 한계가 있다는 것이 명확하기 때문에 스스로 돈을 벌어서 생존을 해야 하는 절박함이 가장 먼저 다가 왔습니다.

안정(?)적인 회사를 떠나서 지금 회사에 합류하기로 결정할 때, 지분도 없고 스톡옵션도 없고 오히려 연봉을 대폭 삭감하면서도 기대에 부풀어 있었던 것은 다녔던 회사들에서 이런 저런 한계에 부딪히면서 느낀 좌절을 극복하고 내가 꿈꾸는 회사를 만들어보고 싶었기 때문입니다.

‘기업의 목표는 이윤창출과 주주가치 극대화’라는 문구는 제가 이런 저런 회사를 다니면서 경영진에게 들었던 말 중에서 가장 싫어하는 말 중의 하나입니다. 저 문구로 인해서 회사에서 사람의 가치가 평가 절하되고 모든 편법과 불법이 합리화되는 것을 많이 봐왔기 때문이었습니다.

그런데, 막상 스타트업에 합류하고 가장 많이 하는 말은 ‘돈벌자‘입니다. 얼마 전에는 저 스스로도 놀랐는데, 개발자와 논쟁을 하면서 ‘당장 돈을 벌 수 있으면 사소한 불법 요소는 감안하지 말자. 돈 못벌어서 망한 뒤에 우리는 비록 망했지만 법을 지키고 우아하게 사업했다라고 말하면 참으로 자랑스럽겠다’라는 말을 제가 하고 있었다는 것이었습니다. 다행히도 나중에 불법적인 정책이 아니라고 확인이 되었지만 제가 변했다는 것을 느끼는 계기가 되었습니다.

또한, 저로 인해서 개발 과정에서 아름다운(?) 아키텍쳐가 자주 무시되고, 말도 안되는 일정에 말도 안되는 방법으로 사업을 위한 땜빵 개발이 이루어지고 있는 것이 현실이기도 합니다.

십수년간 개발을 해온 개발을 잘 안다고 생각하던 사람이 최소 6개월에서 1년 정도 개발해야 하는 서비스 개인화와 타케팅 푸시를 반나절만에 개발하도록 하고, 땜빵으로 1차 개발된 상태에서 살을 붙여서 재활용하도록 요구하다가 서버 개발자로부터 원성을 듣기도 했습니다.

꿈꿔왔던 회사를 만들기 위해서 당장 배고픔을 해결해야 하는 스타트업의 개발 조직 책임자는 개발의 원칙을 무시하는 변절자가 되었습니다.

입사 후 근무 기간을 만으로 석달 채우는데 몇일 안남았네요.. 나름 고난의 행군(?)을 했더니 참 긴 시간을 보낸 것 같은데 말이죠. 요즘 왜 글쓰는게 뜸하냐는 주변 지인들의 의견이 있어서 송년회 끝나고 집에 들어와 짬을 내서 글을 써봅니다.

이제는 새삼스러운 일이 아니라 페북에 글을 따로 올리지 않아서 그렇지 여전히 장애가 발생하고 있습니다. 다만, 예전과 달리 저 혼자가 아니기도 하고 그 동안의 경험 덕분에 개발자들이 빠르게 원인을 찾아서 대응을 하고 있습니다. 또한, 몰려드는 운영 이슈에 정신을 못차리고 있는 점도 있고, 여기저기 파트너사를 찾아다니면서 기술 협의도 하고, 새로운 개발 이슈를 어떻게 대응해야 하나 고민도 하고, 제 개인 업무인 Android application 개발도 하면서 정신 없이 하루 하루를 보내고 있습니다.

특히, 외주업체로부터 운영 주도권을 내부 개발팀으로 받아온 뒤로 사업부서에서 요청하는 운영 관련 업무가 기다렸다는 듯이 폭주하고 있습니다. 고객 문의사항 및 요청사항에 대한 개발 이슈 대응도 해야 하고 파트너사에서 요청하는 자료도 만들어야 하고 이런 저런 운영 업무가 끊임 없이 생기고 있지만, ‘독고다이 고립된 개발 조직’이 아닌 사업과 협업하는 아름다운 모습을 가진 개발 조직을 지향했기 때문에 운영 업무를 최대한 신속하고 친절하게 대응을 해왔는데 줄어들기는 커녕 자동화를 위한 투자에 더 많은 시간을 빼앗기면서 개선의 기미가 전혀 보이지 않고 있습니다.

예전 kth에서 근무할 때 당시 부사장님 이셨던 박태웅대표님께서 저에게 처음으로 주신 질책성 문구가 ‘항상 급한 것이 중요한 것을 잡아 먹는다’였습니다. 4년이 지난 지금도 항상 잊지 않고 되뇌이고 있고 저 질문에 스스로 답을 찾기 위해서 정말 많은 생각을 해왔습니다. 특히, 요즘 같이 정신 없이 하루 하루를 보내고 있을때 내가 급한 것 때문에 중요한 것을 놓치고 있지는 않는지 항상 반문하고 있었습니다.

돌이켜보니 친절하게 최우선으로 대응하던 운영 이슈는 항상 급한 업무 였습니다. 하지만, 급한 업무에 밀려서 하지 못했던 파트너사와 연동과 수익을 내기 위한 추가 기능 개발은 당연히 중요한 업무였습니다. 이런 고민 끝에 지난 주말에 제가 내린 결론은, 지금까지 개발 조직에서 했던 행동은 급한 일에 치여서 중요한 업무를 하지 못했다는 것입니다.

그래서 이번 주 부터는 개발팀에 몇가지 지침을 공유 했습니다.

• 지금까지 진행되던 모든 업무를 무조건 중단한다.
• ‘하면 좋은 일’은 하지 않고 ‘해야만 하는 일’을 한다.
• 운영 업무와 개발 업무는 오전/오후로 물리적 시간을 나누고 해당 시간에는 해당 업무만 한다.

일단 부족한 리소스로 과도한 업무를 진행해야 하는 현실에 제가 선택할 수 있는 궁여지책이었습니다. 일단 궁여지책으로 얼마간 운영을 더 해보겠지만 의문이 들었던 것은 기존 조직에서도 항상 인력대비 업무가 과다했고 인력을 충원해도 업무가 훨씬 더 증가 했었지만 지금과는 느낌이 많이 달랐다는 것이었습니다. 기존 안정된 조직 대비 절박함이 생긴 이유도 있었겠지만 보통의 조직에 비해서 스타트업은 무엇이 다른지 고민하다보니 제 나름대로 내린 결론이 ‘MVP 이후 성공을 대비하는 방법에 대한 Lesson Learned에 대해서 아무도 이야기 해주지 않았다’는 것을 깨닳았습니다.

보통 스타트업을 이야기 할 때 MVP에 대해서 이야기를 하지만, MVP는 실패 비용을 줄이기 위한 도구이지 막상 MVP로 성공했을 때 이후에 대한 어떠한 대책이나 방어 도구에 대해서 알려주지 않았습니다.

MVP를 만드는 과정에서 쌓이는 기술부채를 해결하기 위해서 또는 성공적인 서비스 지표에 따른 연쇄적인 사업적 확장 요구에 맞추기 위해서 무작정 인력을 늘릴 수도 없는 노릇이고(아직 사업적 성공으로 이어진 것이 아니기 때문에 비용적으로도 무리인 점도…) 개발 인력 부족으로 제휴 연동이나 추가 기능을 일정에 맞추지 못할 경우 서비스 초기 지표적 성공이 사업적 성공으로 이어지지 못할 수 있다는 두려움이 생겼습니다.

소위 ‘물 들어 올 때 노 젓는다’는 말이 있듯이 서비스 초기 지표적 성공에 따른 사업적 기회를 부족한 자금이나 인력 문제에도 불구하고 수익으로 연결해야 하는 것이 현재 제가 풀어야 하는 숙제입니다. 만약 제가 이 과정을 성공적으로 넘어선다면 할말이 참 많아지겠다는 생각이 들었습니다. 어쩌면 약장수가 될 수도.. ㅎㅎ

한동안 정말 조용하게 무난하게 시간을 보냈습니다.

그 동안 전화 오면 장애가 발생한 것일까 싶어서 심쿵하고, 단순한 슬랙 채팅 노티도 장애 노티일까 싶어서 열어보는 순간까지 조마조마 했고, 장애 현황 파악 및 긴급 조치를 위해서 주말에도 항상 노트북을 휴대하고 다녔었습니다.

Database에서 누락된 index 생성하고, AWS RDS에서 지원하는 slow query log 확인하고, API 서버 DB connection pool 정리하고, … 외주 업체가 무책임하게 심어놓은 지뢰 찾아서 하나씩 해결하다보니 어느덧 솥뚜껑보고 놀라는 일은 없어졌습니다.

그러던 중 방심한 것은 아닌데 무지에 의해서 어제와 오늘 연달아서 장애가 발생했습니다. 오랜만에 발생하는 장애였고 장애 발생 유형이 기존에 경험했던 것과 완전히 달라서 멘붕과 함께 에너지를 엄청나게 소모하는 바람에 진이 빠져서 그로기 상태를 겪었습니다.

서비스 초기에 서버 구성을 API와 DB로 단순하게 분리했었는데, 운영하다보니 분리해야 하는 서버 구성요소들이 하나둘씩 보이기 시작했습니다. 사업적으로 중요한 서버가 별로 중요하지도 않은 기능으로 인해서 전체 서비스 장애로 이어지는 현상을 몇번 겪었고, 안정적인 서비스 운영을 위해 서버 구성 변경과 기능 패치가 필요했습니다. 비록, 아직 발생하지 않았지만 언제 터질지 모를 시한폭탄이 돌고 있다는 생각이 드니 서버 구성 변경을 무한정 늦출 수가 없어서 서버 패치 일정을 잡았습니다

D-day였던 그제 밤 11시에 각자 집에서 슬랙으로 이야기 하면서 서버 분리 작업과 서비스 패치 작업을 순차적으로 진행하고, 하나씩 기본 기능 테스트해가면서 나름 순탄한 패치를 끝냈고 그래도 혹시나 하는 마음에 매장 영업 시간에 맞춰서 일부는 재택 근무로, 일부는 사무실에서 대기를 했습니다.

오전 10시에 매장 영업을 시작하고 별문제가 없는 듯 하다가 11시경부터 여기저기서 장애 현상이 보고되기 시작했습니다. 전체 장애는 아닌데 일부 매장에서 포인트 적립과 사용이 안된다는 클레임이 접수되기 시작했고 원인 분석을 위해서 로그 파일을 열어 본 순간 모두가 멘붕이 되었습니다. 막내 개발자가 로그 파일 크기를 줄인다고 API 호출 기록만 남기고 나머지 로그가 모두 출력되지 않도록 작업을 해 놓은 것이었습니다.

어찌 어찌 어렵게 장애 원인은 찾았는데 해결책을 못찾았고 장애 시간이 길어지니 rollback하자는 의견이 나오기 시작했는데, 서버 구성을 바꾼터라 기존 서버 구성으로 완전 복구는 몇시간이 더 소요될 것이고 바뀐 서버 구성에 예전 서비스 모듈을 올리면 어떤 오동작을 하게 될지 몰라서 선뜻 판단을 못내리고 있었습니다. 모두를 제 판단만 기다리는데 아무런 정보가 없는 상태에서 현재 문제를 해결할지 rollback 해야 할지 결정하는 것은 의사결정이라기 보다는 찍기에 가까운 무모함 그 자체였습니다.

문제의 원인은 특정 API 호출이 DB에 write하는 동작에서 master DB로 access하지 않고 replica DB로 write operation을 시도하니 Exception이 발생하는 것이었는데, 소스 코드 상으로는 master DB를 access하도록 코딩되어 있었기 때문에 해결책을 도저히 찾을 수 없었습니다.

이 상황에서 더 이상 나빠질 것도 없겠다 싶어서 일부 멤버는 서비스를 rollback하는 작업을 하고 나머지 멤버는 기술 동냥을 위해서 짐을 싸서 초고수분께 찾아갔습니다. 다행히도 이동하는 와중에 rollback 이후에 서비스가 정상 동작해서 큰 산을 넘었다고 생각했습니다. 장애가 발생한 문제는 생각보다 복잡해서 당장 문제를 해결할 수 있는 골드키는 얻지 못했지만 수정해야 하는 방향에 대해서 조언을 얻어서 무엇인가 해볼 수 있는 것이 생기니 일단 심리적 안정감을 가질 수 있었습니다.

오랜만에 생각지도 못했던 유형의 장애를 만나니, 서비스 무중단 패치와 staged roll-out을 하는 방법이 필요하다 싶어서 아침에 출근해서 이런 저런 이야기를 나누던 중에 여러가지 아이디어가 나와서 하나씩 적용해서 하다보면 밤새지 않아도 패치할 수 있고 장애가 발생해도 바로 복구할 수 있는 역량이 생길 것 같습니다.

여기까지는 괜찮았는데 막내 개발자가 테스트 한다고 로컬 버전을 업로드한 서버가 staging 서버가 아니고 상용 서버였다는 사실을 이실직고 하면서 평화로웠던 아침이 전쟁터로 변했습니다. 매장에서 적립/사용되는 포인트가 상용 서버가 아닌 테스트 서버에 쌓이는 상황에서 불가피하게 서비스를 중단시킬 수 밖에 없었고 어제 장애 여파도 있어서 대외적으로 대응해야 하는 입장에서 이래저래 참 난처할 수 밖에 없었습니다.

일단 급한 불을 끄고 테스트 서버에 쌓인 거래 내역을 상용 서버로 옮기는 작업까지 마무리하면서 오랜만에 쫄깃한 장애 대응을 마무리 했습니다.

Lesson Learned

• 단위테스트를 잘해도 빼먹은 테스트가 있으면 거기서 꼭 펑크가 난다. 빼먹은 테스트가 있는지 꼭 확인하자.
• 부하 테스트를 안하면 비주기 문제가 상용 서비스에서 발생한다. 부하 테스트 하는 방법을 꼭 찾아 놓자.
• 서비스 운영 경험이 없는 개발자에게는 사소한 경험이라도 알려줘야 로그에 대한 개념을 잡는다.
• 아무리 작은 수정사항이라도 double check하는 방안을 찾아야 한다.
• 비록, git을 쓰고 있지만 최종 산출물에 대한 버전 관리가 안되면 소스 빌드부터 다시 해야 하기 때문에 장애 대응이 늦을 수 밖에 없다. 서버 로컬 storage에 날짜별로 산출물을 남겨 놔야 빠른 rollback이 가능하다.
• 무중단 패치와 Staged roll-out은 아무리 바쁘더라도 먼저 도입했어야 했다. (비록 초반에는 몰라서 못했지만 장애를 겪기 전에 심각성을 예상했다면 충분히 방안을 찾을 수 있었을 것이라는 생각)
• 궁하니 통하고, 아무도 알려주지 않는 서비스 운영의 노하우는 몸으로 배울 수 밖에 없다.

회사 입사 후 각종 도구 도입과 시스템 구축 과정을 간단히 쓴다는게 길어져서 2부로 나뉘게 되었습니다. 오늘은 지난번에 못다한 이야기를 마저 해보려고 합니다.

Confluence는 묻지도 따지지도 않고 당연히 먼저 도입하고 구성원들 적응 과정도 순탄해서 별 문제가 없는데, JIRA는 항상 큰 고민을 합니다. 가격도 만만치 않고 구성원들이 이슈 트래킹이라는 업무 방식에 익숙하지 않은 것이 일반적이었기 때문입니다.

쉬운 이슈 트래킹으로 Trello를 많이 쓰는데, 작은 규모에서 도입 초기에는 별 문제가 없다가 인원이 많아지거나 오랜 시간 사용하면 이슈가 누적되어서 보드 유지보수가 안되는 치명적인 문제가 항상 발생했었던 것 같습니다. 결국 몇몇이 책임지고 보드 이슈를 관리하고 트래킹하지 않으면 깨진 유리창의 법칙에 의해서 Trello를 안쓰게 되는 수순으로 진행되었기 때문에 제대로 된 이슈 트래킹으로 JIRA를 쓰거나 또는 이슈 트래킹 프로세스를 도입하지 않거나 하는 고민을 하게 되었습니다.

입사 초기에는 기존 구성원들이 익숙한 방식대로 이메일과 대면 의사 소통에 의해서 업무를 진행 했었는데, 한달 반쯤 이후에 서버 개발자 2명, iOS 개발자 1명이 동시에 입사하면서 내부 개발팀에 대한 막연한 기대가 증폭되고 각 분야별로 업무 요청이 쇄도해서 업무 관리의 필요성이 대두되어 무모하다고 생각했지만 그냥 JIRA를 도입해서 밀어붙였습니다.

• 개발팀 요청은 무조건 JIRA로 진행하고 업무 충돌이 발생하는 경우에는 개발팀은 각 업무에 대한 예상 공수만 산출하고 경영진이 우선순위 의사결정을 한다.
• JIRA에서 진행 중이 아닌 이슈는 실제로 진행하고 있지 않은 것이니 업무상 반드시 필요하다면 다른 업무를 빼고 진행할 수 있도록 경영진 합의를 받아라.
• 그럼에도 불구하고 기존 업무에 추가해서 진행해야 하는 사항이라면 외주 인력 투입에 대한 비용 품의를 받으면 개발팀이 외주 인력을 투입해서 일시적으로 Capa를 늘리겠다.

어쩌면 공무원스럽고 어쩌면 스타트업에 맞지 않는 정책이라는 느낌이 있었지만 업무에 사람을 맞추게 되면 개발팀이 100명이어도 부족한 상황이라 사람에 업무를 맞춰야 한다는 판단을 했습니다.

4주째 JIRA로 업무를 진행 중인데 개발팀이 투명하게 업무를 진행하고, 진행 중인 업무에 대해서는 매일 스크럼을 통해서 또는 실시간으로 JIRA 이슈에 진행 상황 comment를 추가하니 전사 스크럼이 아니더라도 공유가 이루어져서 다행히도 별 무리 없이 진행되고 있습니다.

어렵게 JIRA를 도입한 이후에는 DVCS connector를 통해서 ticket 기반 git smart commit 기능을 사용할 수가 있어서 Release Note에 JIRA 이슈 리스트만 넣어도 code history까지 같이 파악이 가능하니 개발 입장에서 많은 잇점이 생기는 것 같습니다.

bitbucket은 atlassian 정책에 따라서 사용자별 과금 체계이고, github은 repository별 과금 체계인데 저희는 bitbucket과 github를 동시에 사용하고 있습니다. github organization account는 JIRA DVCS connector 연결을 지원하지 않는 문제도 있지만 상황에 따라서 추가되는 외주 인력으로 인해서 불필요한 bitbucket 비용을 지불하는 것이 부담이 되는 것도 있고 내부 코드를 외주에 모두 공개하는 것이 적절하지 않다고 생각했던 것도 있습니다.

외주 인력이 작업하는 repository는 github에 생성해서 해당 인원에 대해서 권한을 주고 외주 인력이 commit하는 code는 bitbucket으로 merge하는 작업을 진행합니다. 외주 프로젝트는 제한적이기 때문에 github 최소 과금 모델로 진행해도 추가 비용 부담 없이 인원수를 무제한 추가할 수 있습니다.

그리고, 현재 저희 회사 개발팀이 4명이기 때문에 5명까지 무료인 bitbucket를 사용하는 경우 무제한 repository를 무료로 사용할 수 있어서 간단한 sample project나 test project도 부담 없이 생성할 수 있는 장점도 있습니다.

Jenkins나 redmine, ldap, .. 은 오늘도 얘기를 못꺼냈네요.. 별거 없기는 한데 다음에 다시 쓰도록 하겠습니다.

kth에서 Confluence를 처음 접한 후에 회사 입사 후 처음 하는 일이 Confluence도입이 되었습니다. 이전 직장인 인포뱅크에서도 그랬고 지금 회사에서도 마찬가지 였습니다. kth에서 전사 조직이 Confluence를 이용해서 정보를 공유할 때 어떤 느낌인지 너무 강렬하게 느꼈기 때문에 그 느낌을 전파하고 싶었습니다. Confluence 없이 일을 하려고 하면 구석기시대로 돌아가서 일하는 느낌이라 답답해서 도저히 참을 수가 없을 정도입니다.

Confluence 도입 후에는 한동안 특별한 활동 없이 조직을 관찰하고 구성원들이 어떻게 일하는지 지켜봤습니다. 혹시나 경영진이 돈들여서 도입을 했으니 Confluence 사용을 강요하고 압박하거나 감시의 도구로 사용할까봐 각별히 주의를 기울였는데 다행히도 합리적인 분들이라 그런 일은 발생하지 않았고 한참을 저 혼자서 열심히 사용했습니다.

지금부터는 약간 소름돋는 경험을 몇가지 하게 됩니다. ‘절대로’ 꾸미거나 과장한 것은 아니니 혹시라도 오해가 없으셨으면 좋겠습니다.

Confluence 도입 후 빈둥 대다가 심심해서 서버에 모니터링 도구인 Whatap을 설치합니다. 24시간 동안의 서버 모니터링 데이터 저장은 무료이고 Database는 유료인데 대당 5만원이라 비싸서 그냥 EC2 서버에만 설치를 했습니다. AWS 모니터링 도구가 좋기는 하지만 Memory 사용량이나 Disk 사용량에 대한 모니터링 지표가 없어서 불편한데 Whatap은 간단하지만 딱 필요한 모니터링만 해주니 쓸만한 것 같습니다.

Whatap 설치 후 얼마 있다가 Disk 사용량 경고 이메일을 받았는데, 외주 개발사에서 서비스 로그를 Debug mode로 설정하다보니 별로 하는 일 없이 Disk에 로그가 하루치만 저장하는데도 90%를 넘게 사용하는 문제를 찾을 수 있었습니다. 만약 Whatap을 설치 하지 않았다면 제가 만나는 첫 장애가 Disk full로 인해서 발생한 것이 었을 겁니다.

그 뒤에는 제가 페북에 따로 글을 올렸던 것처럼 회의실에서 놀고 있는 64bit OS도 구동이 안되는 저사양 PC와 14인치 모니터 2대로 나름 상황실 분위기를 만들었던 것이고, 설치 후 불과 몇십분 지나지 않아서 첫 장애를 맞이 했었습니다. 장애 상황에서 모니터링 PC로 인해서 어떤 문제로 인해서 장애가 발생했는지를 바로 눈으로 확인할 수 있었습니다.

이런 일련의 상황이 이어지니 사장님이 ‘너 뭔가 알고 있었지!’라는 말을 농담반 진담반으로 여러번 하시는데 저도 약간 당황스러웠었습니다.

업무 시간이나 사무실에서 누군가 모니터를 지켜보는 상황이 아닌 주말이나 야간의 경우에는 장애가 발생하고 매장으로부터 전화가 폭주해야 장애 대처가 가능했고 그나마도 사후 대응이고 즉각적인 대처가 어려운 점이 있어서 뭔가 대책이 필요했었습니다.

처음에는 AWS 알림 메일과 IFTTT를 연결해서 slack으로 연동을 했는데, 메일 도착이 지연되거나 메일이 도착해도 Polling하는 시간이 있어서 최소 5분, 최대 수십분 정도 알림이 지연되는 현상이 발생해서 사실상 쓸모가 없었습니다.

AWS와 Slack을 연결하는 방법을 찾다보니 AWS의 lamda function을 이용한 방법이 많이 나오는데 설정이 쉽지 않아서 다른 방법을 찾다가 Heroku를 사용해서 쉽게 설정이 가능한 amazon-cloudwatch-to-slack을 발견했습니다. 소스 clone 받아서 heroku에 올린 후에 처음 셋업 과정은 조금 헤멨는데 상상했던 것보다 복잡하거나 어렵지 않았고 Webhook을 사용하기 때문에 반응성 또한 좋았습니다.

요즘은 카페에 가거나 식당에 가서 AWS 알림이 Slack으로 뜨면 약속이나 한 듯이 모두 폰을 꺼내서 알림 내용을 보고 이야기 하거나 누군가가 주변으로 전파해서 신속하게 장애에 대응을 하고 있습니다. 어제도 새벽 2시에 서버가 미친듯이 장애 알람을 보내는 바람에 뜬눈으로 밤을 지새기는 했지만 오전에 매장 영업 전까지 대응이 가능해서 무난한 하루를 보낼 수 있었습니다. 만약 알림이 없었다면 매장 영업 시간이 아니기 때문에 아무도 몰랐을 것이고, 아침부터 장애 대응에 힘든 하루를 보내고 장애를 해결하고 나면 여기저기 불려다니면서 사과하고 변명하는데 한참을 보내야 했었을 겁니다.

회사에서 사용하는 도구와 도입하는 과정을 간단히 쓰려고 했는데, 말이 너무 길어져서 JIRA 도입과정이나 github/bitbucket/redmine/LDAP/jenkins 등의 도구에 대해서는 다음번에 추가로 쓰도록 하겠습니다.

장장 한시간여에 걸쳐서 쓴 글을 페북이 날려먹어서 요점만 다시 씁니다. 썼던 글 다시 쓰는게 정말 짜증 나는 일이군요. (어쩐지 글이 술술 써지더라니..)

부푼 꿈을 안고 스타트업에 합류한지 이제 두달이 되어 갑니다.

그 동안 다닌 회사는 직무별로 전문 조직이 있어서 어설프게 아는 지식으로도 일하는데 부족함이 없었고 그게 제 역량인 줄 알고 정말 겁없이 스타트업에 합류했습니다. 막상 스타트업에 합류해서 일하다보니 서당개로 주워들은 지식의 파편들은 쓸모가 없었습니다. 정말 중요한 것은 ‘경험’이라는 것을 체감하고 있습니다. 장애 대응이나 서버 구성 및 DB 설계 등등 어느 것 하나 책으로 배울 수 있는 것들은 없었습니다. 하나씩 문제를 만나면서 주변 지인 분들로부터 구걸과 동냥을 해가면서 하나씩 배우고 있는 중입니다.

그리고, 스타트업에 대한 또다른 환상은 절박함과 절실함으로 가득찬 최정예 멤버들로 구성되어 있을 것이라고 상상했던 것이었습니다.

여타 작은 회사들이 그렇듯이 언제 망할지 모르는 듣보잡 회사가 ‘스타트업’이라고 포장한다고 사람들이 알아서 찾아올리가 없었는데 그 단순한 현실을 직시하지 못했던 것 같습니다. 결과적으로 스타트업에도 소위 명분을 중요시 하는 가오파가 있고, 편하게 월급만 받고 다니면 되는 사람이 있는가 하면 회사의 성공 여부와 상관없이 나름대로 하고 싶은 것을 할 수 있는 기회로 여기는 사람도 있었습니다.

그러고보니, 제가 예전에 다녔던 회사에서도 이유는 다르지만 절박함과 절실함을 가진 사람이 일부 있었습니다. 물론 그 동기가 스타트업과는 다르겠지만 그때 저는 회사원이었고 무난하게 회사 출근해서 대형 사고치지 않으면 월급이 나오니 해보고 싶은 일을 할 수 있는 기회로 여겼었습니다.

‘스타트업의 회사원’이라는 존재를 인식하기 전까지는 같이 달려주지 않거나 사사건건 발목을 잡는 행태로 인해서 때로는 분노했고 때로는 너무 힘들어서 그만둘까도 고민했었습니다.

결국 스타트업은 절박함과 절실함을 가진 사람들이 모인 로켓이 아니라, 언제 망할지 모르는 위험한 사업을 하는 듣보잡 작은 회사라는 현실을 인식하는데 2개월이 걸린 것입니다.

쉽게 금방 성공할 것 같았습니다.

• Business model은 흠잡을데 없었고
• Cash flow 계획도 완벽했으며
• 회원 유입과 앱 다운로드 등의 외형적인 수치도 순조로웠고
• 찾아다니지 않아도 사업을 같이 하자고 찾아오는 사람들이 부쩍 늘었습니다.

그런데, 어느 정도 예상은 했지만 성공이라는게 저한테 순순히 찾아올리가 없었습니다.

입사 초기부터 계속 문제가 되어왔던 외주 업체의 횡포를 막지 못하니 사업적으로 위기가 닥쳐도 헤쳐나가는게 몇곱절 더 힘든 것 같습니다.

지금까지 회사들의 경우에는 상부에서 문제의 심각성을 인지하도록 문제가 악화되기를 기다렸다가 대안을 제시하거나, 해결하기 어려운 구조적인 문제의 경우에는 회피하는 방법을 주로 사용했었습니다만 회사의 기반이 취약한 스타트업에서는 문제가 악화되는 경우 회사가 문닫아야 하는 상황이 될 수도 있어서 기존의 처신이 맞지 않다는 생각을 했습니다. 지금까지 겪어보지 못했던 상황과 그럼에도 불구하고 어떻게든 일이 진행되도록 대응을 해야 하는 점은 쉽지 않은 도전이 되고 있습니다.

또한, 사업의 위기가 닥쳤을때 생존을 위해서라면 비용을 절감하고 허리띠를 졸라매서 버티기 모드로 가야 하는 것이 맞겠지만, 서비스 초기 성장세에 아무것도 하지 못하면 앞으로 더 고전할 것이라는 판단하에 과감하게 비용을 올인하는 베팅을 했습니다.

사업과 영업을 담당하는 사람들은 매출을 발생시킬 수 있는 아이템을 계속 발굴해오는데, 개발에서 연동 개발을 비롯한 일정과 서비스 품질을 담보하지 못하니 계약이 차일피일 미루어지는 상황에서 더이상 시간을 끄는 것은 문제가 있다는 판단하에 마지막 남은 투자금으로 다른 외주 개발 업체를 섭외했습니다.

어쩌면 다음달에 또는 내년초에 월급이 나오지 않을지도 모르겠습니다. 계획대로라면 지금 서비스로 연말까지 어느 정도 안정적인 매출을 확보하고 운영 자금이 확보된 이후에 내년 초에 내부 개발팀을 셋업하고 사업 확장을 하는 시나리오였습니다만, 예상하지 못했던 서비스 지표의 폭발적인 성장으로 인해서 내부 개발팀 셋업 일정을 앞당겼고 계획된 비용 지출을 넘어서는 상황이 지속되고 있습니다.

회사 운영비 확보를 위해서 마련해둔 또다른 사업 아이템은 예상치 못했던 돌발변수로 인해서 한달이 될지 두달이 될지 아니면 영원히 좌초할지 모르는 짙은 안개속으로 빠져들었습니다. 당연히 될 것이라고 믿었던 cash flow에서 틀어지니 충격의 강도가 장난이 아닙니다.

지금까지 제가 회사를 다니면서 월급걱정하고 회사 cash flow를 고민해본적이 없었는데 새로운 경험으로 인해서 불안감과 함께 웬지 모를 짜릿함이 공존하고 있습니다.

이게 스타트업인 것 같습니다.

서비스 오픈하고 보름만에 두번의 장애를 겪고나니 요즘 멘탈 상태가 말이 아닙니다. 저 뿐 아니라 회사 전체가 서비스 초반에 가파른 가입자 상승세에 취해 있다가 요즘은 가입자나 외형적인 성장 수치에 대해서 아무도 이야기 하지 않습니다.

초기 상승세에도 불구하고 다이소에서는 회원수를 더 많이 늘리기 위해서 가맹점들에게 회원 가입 실적을 평가에 반영하고 인센티브를 지급하겠다는 정책을 발표했는데, 가맹점들이 실적 경쟁을 하다보니 사용자가 자발적으로 앱을 설치해서 가입하는 방식이 아니라 매장마다 가입 신청서 양식을 자체적으로 만들어서 직원들이 가입을 유도하는 방식으로 진행되고 있습니다. 매장을 방문하는 고객들에게 가입신청서를 나눠주고 영업시간 끝난 후에 직원들이 수작업으로 회원 정보를 입력하는 예상치 못한 방향으로 흘러가고 있습니다.

초기 단계에서 Android앱으로만 서비스하기 때문에 iOS 사용자나 스마트폰 사용에 취약한 계층도 회원으로 유입시키기 위해서 Mobile web page를 통해서 가입할 수 있는 우회 채널을 열어 놓은 것이 화근이 되었습니다.

다이소 매장 입장에서야 앱으로 가입하나 Web으로 가입하나 회원이 증가하는 측면에서는 차이가 없지만 Web으로 가입한 회원들은 포인트를 적립하기 위해서 핸드폰 번호를 직원에게 불러주거나 서명 패드에서 번호로 입력하는 과정을 거쳐야 하기 때문에 고객당 결제시간이 길어져서 궁극적으로 매장 비용 증가로 이어질 수 있는 부분이 간과되고 있습니다.

저희 회사 입장에서는 앱을 설치하는 사용자 수가 늘어야 CRM 서비스나 광고 BM을 적용할 수 있는데 앱으로 설치 가능한 사용자들도 직원들 권유에 의해서 Web으로 가입이 처리되고 있어서 가입된 회원을 대상으로 앱을 설치하도록 유도해야 하는 또다른 숙제를 떠안게 되었습니다.

빈번한 장애에 사업이 예상하지 못하는 방향으로 흘러가니 스타트업이 쉬운 일이 아니라는 것을 요즘 절실히 깨닳고 있습니다. 다행히도 주변에서 도와주시는 분들이 많아서 장애 원인 분석하고 대책을 수립하고 있는데 이 또한 쉬운 일이 아니라 스스로 무능함을 체감하고 있습니다.

가입자와 사용자를 모으는 데는 가시적인 성과를 보이고 있지만 사업적인 성과로 연결시키기 위해서는 서비스의 안정성과 빠른 개발이 필수적인데 외주 개발의 문제가 운영에서 적나라하게 드러나고 있습니다.

입사 후 외주 업체에게 완전히 넘어가 있는 개발 주도권을 가지고 오기 위해서 정말 많은 노력을 했습니다만 현재 외주로 개발하는 업체가 사장님과 사업이사와 함께 3년 넘게 같이 일한 사이라 신뢰가 두터웠기 때문에 설득이 쉽지 않았습니다. 어쩔 수 없이 1차 개발이 완료되고 연말까지 2차 추가 개발 계약을 기존 업체와 계속 하는 것으로 한발 물러서서 내년부터 업체를 바꿔서 운영하는 것으로 타협을 했습니다.

그런데, 이 타협이 회사를 어려운 상황으로 몰아가게 될지는 상상도 못했습니다.

서비스 장애가 발생해서 서버 재부팅을 해야 하는 상황에서도 외주 개발 업체에서는 책임 회피를 위해서 원인을 규명해야 한다며 30분 가까이 서비스 장애가 난 상태로 방치하고, 장애의 원인이 된 DB 부하 분산을 위해서 튜닝과 최적화 작업을 해야 하는데 명백한 결함에도 추가 계약 없이는 작업을 못하겠다고 버티는 등 여기저기서 사업을 발목잡는 작은 사건들이 발생하고 있습니다.

만약 제가 입사후 강하게 밀어붙여서 업체를 미리 바꿨다면 장애의 영향이 작았을 것이고 기능개발 보다는 서비스 안정성 위주로 개발 외주를 진행했을 것이기 때문에 추가적인 장애도 줄이고 사업적인 어려움이 덜했을 것이라는 자위를 스스로 합니다.

다만, 개발을 총괄하는 사람이 입사하자 마자 별 문제 없는 기존 업체를 자기가 아는 업체로 바꾼다는 사실만 가지고 뒷탈이 있을 수 있는 여지가 충분히 있었고 저 스스로도 업체를 바꿔야 할만큼 심각한 상황으로 인지하지 못하고 있었던 것도 있습니다.

그리고 지금까지 다녔던 회사에서는 ‘책임’이라고 해봐야 허울뿐인 구실이고, 제 개인의 판단이 조직의 시스템에 의해서 위험을 줄여주도록 동작했을 것이고 설사 실제 위험 요인이 발생했다고 하더라도 조직의 시스템에 의해서 어렵겠지만 결과론적으로 복구가 가능했을 것입니다.

하지만 스타트업에서는 제 개인의 결정이 회사의 존폐를 가를 수 있는 위험성을 가질 수 있고 각기 다른 분야에서 최소의 인원만 존재하다보니 서로 보완해줄 수 있는 여력을 가지고 있지 못한 것도 과감한 결단을 두렵게 하는 환경입니다.

입사한지 이제 갓 한달이 지났는데 사업의 롤러코스터를 타며 심장이 쫄깃함을 느끼고 있습니다. 가능한 즐겨보려고 합니다.

지난번 장애 이후에 덜컥 겁이 나서 AWS instance를 2단계나 Scale up 했더니 서비스가 안정적으로 돌아가고 있습니다. (물어보시는 분들이 몇 분 계셔서.. ㅎㅎ)

몇몇분들께서 메신저로 개인적인 도움을 주셨는데 제가 잘 모르는 것도 있고 개발 주도권이 외부 업체에 있다보니 제가 이래라 저래라 할 수 있는 처지가 아니라서 당장 조치를 취하지는 못하고 알려주신 내용들 잘 적어놓고 있습니다. 서버 개발자 입사하면 이것 저것 물어보면서 공부 좀 하도록 하겠습니다.

이번주는 개발실에 세팅되어 있던 모니터링 장비를 구성원 전체가 볼 수 있도록 위치를 옮겨서 세팅했습니다. 회의실에서 빔프로젝터 쏘는데 사용되었던 장비라 사양이 낮고 모니터도 작아서 오페라 볼때 사용하는 망원경이라도 구매해야 할 정도로 화면에 있는 글자들은 잘 안보이지만 중요한 그래프 확대해서 전체적인 추이만 관찰하고 세밀하게 관찰할 필요가 있을때 모니터링 장비 근처에서 확인하거나 개인 모니터에 띄워서 특이사항이 있는지 확인하고 있습니다.

이제 서비스 장애에 대한 두려움에서 점차 벗어나게 되니, 본업인 팀빌딩을 위해서 짬날때마다 같이 일했으면 하는 개발자 분들을 위주로 만나고 있습니다.

오늘은 복이 저절로 굴러들어와서 전 직장에서 개발을 참 잘하는 친구가 안부차 연락을 하길래 ‘이게 웬 떡이냐’며 식사도 하고 차도 같이 마셨습니다.

제가 회사에 대해서 이런 저런 수다를 좀 떨었더니 전직장 구성원들에게 자극을 주기 위해서 ‘100만 다운로드’ 달성하면 제 이야기를 하겠다고 하더군요. ‘100만 다운로드 금방이고 오픈한지 몇일만에 20만 다운로드 달성과 라이프스타일 카테고리 1위도 놀라운 실적이니 맘놓고 자극을 줘도 된다’고 이야기 해줬습니다.

동료들에게 자극을 주기 위해서 사석에서 제 이야기를 인용 할거라고 생각했는데 예상외로 회사에 복귀하자 마자 내부 직원 전용 페북 그룹에 글을 올렸더군요. 제 깔때기 같지만 요즘 저를 비추는 거울 같은 글이라 염치 불구하고 내용 제보 받아 올립니다.

처음에는 포인트 사업하는 회사라 했습니다.
그래서 "에구 고생하겠다."란 생각이 들었습니다.
거기다가 연봉도 깍여 들어간다고 하니, 사실 마음이 편하지 않았습니다.

그리고 몇 주 후, 판교에 볼 일 있어 들렸다며 잠깐 얼굴을 보았습니다.
그 때야 자기 회사 사장이 다이소와 함께 포인트 사업을 할꺼라고 얘기해 주었습니다.

포인트 사업 하나만 놓구 보면 정말 가망 없습니다.
포인트 + 다이소 = 흥미
신기한 것 입니다.

별거 아닌 다들 하고 있는 레드오션이 갑자기 블루오션이 되는 것 입니다.
그러면서 사업에 재능 없는 저도 갑자기 재미있는 그림이 그려지는 것 입니다.
헐~ 하면서요.

오늘 서울 갈 일이 있어 어찌 사는지 궁금하기도 하고 잠시 들렸다 오는 길 입니다.
앱 오픈한지 몇 일 되지 않는데 벌써 20만 다운로드랍니다.
라이프스타일 앱 중 현재 1위! ㅋㅌㅋㅌ
올해 목표가 100만 다운로드! ㅋㅌㅋㅌ

"앞으로 이렇게 이렇게 되어갈꺼야!"라고 말해주는데 그 이야기는 안들어오구, 밝은 긴장감만 느껴졌습니다.
밝은 긴장감, 기대와 희망에 부푼 모습입니다.

퇴사 할 때, 자기가 하고 싶었던 것은 처음부터 참여하여 좋은 서비스를 만들어 나가는 것이라고 했습니다.
지금 하고 싶었던 것을 해나가고 있어서 제가 다 기분이 좋습니다.

농담삼아 앞으로 만나려면 비서한테 전화하라고 했었는데,
아직은 다행히 제 연락을 받아줘서 다행입니다.
곧, 연락하면 예쁜 목소리의 비서가 "안 계십니다. 들어오시면 연락왔었다. 얘기 드리겠습니다."란 통화를 하게 되길 빌겠습니다.

여튼, 최근에 깨진 편견 중 하나, 사업 아이템만 중요한 게 아니고, 그것을 구현하는 것만 중요한게 아니다. 
어떤 그림을 그리고 그것을 현실화 시켜 나가느냐도 중요하다.
마치, 별거 아닐 것 같은 포인트 사업이 다이소를 만나 다른 시너지가 나는 것처럼...
오부장님이 언능 비서를 통해서 저를 피해 다니시는 날이 곧 오길 빌겠습니다.

대박! 기원! 화이팅!