Continue reading ‘쏘카를 떠나며’ »]]> 쏘카의 마지막 퇴근길, 박수받았다.

남기고 떠나는 것 같아 아쉬움이 있었다. 마지막 AAA 시간 역시 무기명으로 진행했는데, 50대의 꿈과 IT 환경의 문제점에 대한 질문을 받았다. 쓸 물건을 만들기 위한 개발, 제대로 쓰기 위한 노력이 필요하다는 개똥철학을 공유했다.

남은 짐을 가방에 한가득 넣고, 사무실을 나서니 박수를 치기 시작했다. 세상 무안해서 손사래를 쳤다. 조직으로 일하는 것을 완성하지 못했는데 그럼에도 박수 소리가 열심히 한 노력을 인정해주는 것 같아 좋았다.

2년 8개월 동안 내 Staff 역할을 해줬던 담당 친구가 준비해준 꽃 다발을 들고 퇴근했다. 내 꽃다발이지만 형수님 취향으로 준비했다고. 집에 도착 후 꽃다발 본 와이프가 싱글벙글거리며 꽃병에 옮긴다.

메세지 카드도 맘에 들었던지 냉장고 벽 잘 보이는 곳에 뒀다.

저녁 6시, 쏘카에 와서 구성원들과 함께 만들었던 자동화된 퇴사 프로세스가 실행됐다.

퇴사 완료.

정말 치열하게 고민하고 일했던 시간이었다. 제대로 일하는 조직을 만들 수 있을까 하는 고민과 걱정을 안고 시작한 쏘카 생활이었지만 “된다.”라는 확신을 얻을 수 있는 시간이었다. 미국의 방식과 한국의 문화를 조합이 구성원들이 공감해주면 충분히 가능하다라는 것도 확신했다. 물론 이걸 실행하는 리더십이 매우 중요한건 당연하고.

모든 구성원들이 고생했지만, 특히 나를 믿고 지금까지 따라와준 팀장, 그룹장들에게 감사하다. 당신들의 지지가 없었더라면 내가 꿈꾸는 다음 단계는 상상도 못했을 것이다.

좋은 경험과 성취를 가지고 이제 다음 스테이지로 간다.

Continue reading ‘리더십의 리더 – Lead와 Leader’ »]]> Lead와 Leader – 용어 차이와 역할 차이

요즘 리더(Leader)와 리드(Lead)를 많이 쓴다. 두 용어의 의미는 묘하게 비슷하면서도 다르다. 개발 리드(Tech Lead), 데브옵스 리드(DevOps Lead), QA 리드(Quality Assurance – 품질)와 같이 리드라는 단어는 앞에 접두어가 존재한다. 물론 리더도 같은 접두사를 쓰기도 하지만 “리더”라는 단어 자체로 더 많이 사용된다. 아마도 리드를 동사로, 리더를 명사로 생각하기에 쓰임과 느낌의 차이가 있는게 아닐까 싶다.

두 용어에 대해 신임 임명자분에게 질문해보면 “사람들을 이끈다” 라는 점을 공통점으로 이야기하지만 다름에 대해서는 잘 모르겠다는 반응이 보통이다. 두 단어의 차이에 대한 나의 정의를 가지고 있지만, 객관적 용어 정의를 먼저 알아보는 것이 좋겠다. 두 단어 모두 영어 단어기에 핸드폰에 설치된 ACE 영어사전에서 정의를 찾아봤는데 Lead 의 명사 정의가 납, 납으로 만든 추 등으로 나와 영 신통치 않았다. 리드에 기대했던 명사 설명을 영한 사전에서는 찾기 어려워 Webster 영영 사전을 찾아봤다.

• Lead – example, position at front, initiative, the act or privilege of playing first in a card game
• Leader – something that leads a primary or terminal shoot of a plant; a person who has commanding authority or influence.

영영 사전 정의를 한국인 관점에서 해석해보면 리드는 “행위의 중심 혹은 표상(혹은 표본)”이고, 리더는 “권위 혹은 지위를 갖는 사람”으로 해석한다. 그동안 생각해오던 정의에 부합하는 것 같다.

가지고 있는 정의를 좀 더 풀어보면 리드의 역할은 행위에 중심을 두고 있고, 리더는 역할에 중심을 둔다고 정의한다. 그리고 각 역할에 따른 책임을 진다. 리드는 주어진 일 혹은 업무를 함께하는 동료들과 실행해서 결과를 만드는 책임을 갖는다. 리더는 업무를 수행하는 사람들을 책임진다. 책임 완수를 위해 구성원들이 어느 시점에 어떤 일을 수행하고, 필요한 자원이 무엇인지 관리한다. 관리 관점에서 리더의 책임 범위는 리드의 책임 범위를 포괄하는 막중한 책임을 진다. 엔지니어링 용어를 빌어보면 리더는 프로세스(Process)고 리드는 쓰레드(Thread)에 상응한다고 보면 좀 더 빠른 이해가 될 지 모르겠다.

개인적인 경험을 빌어보면, 리더와 리드의 역할 범위를 스스로 명확하게 정의했던 때는 라이엇게임즈에 근무하던 때다. 회사의 목표에 맞춰 수행할 일을 리더가 확정하고, 업무를 주도할 리드를 선정한다. 리드는 수행할 업무에 필요한 사람과 시간이라는 자원을 산정하고, 리더는 자체적으로 자원 확보가 가능한지 혹은 추가 협의, 외부 도움 혹은 채용을 통해 문제를 해결할지 결정한다. 외국계 큰 기업이라도 언제나 충분한 자원이 있었던 적이 없었다. 그럼에도 리더와 리드의 유기적인 소통이 잘 동작하는 조직은 합리적인 의사 결정을 통해 회사가 원하는 결과를 만들어냈다

리더는 “방향”을 제시하고, 리드는 “일을 실행해서 완성”하는 역할을 수행한다. 리더는 어느 방향으로 조직이 나아갈지, 상위 리더와 합을 이루기 위한 방향이 무엇인지 정한다. 결정된 방향으로 나가기 위해 필요한 일이 정해지면, 일 성격에 부합하는 전문성을 갖춘 리드가 본인의 과제를 선택한다. 혹은 리더가 일을 부여할 수 있다. 전사 방향에 일관성있는 맞춤(Alignment)을 통해 리더의 의사 결정과, 구성원의 역량 수준에 따른 리드의 계획과 실행이 중요하다.

리더와 리드의 역할 구분은 조직의 규모에 따라 가변적이다. 그리고 조직도 혹은 조직체계에 따라 불리는 호칭도 다르다. 쏘카의 경우  리더는 그룹장으로 리드는 팀장으로 정의했다. 그룹장은 조직 책임자로써 방향을 정의하는 역할을 맡고, 팀장은 분배된 업무를 수행하고 결과에 대해 책임진다. 물론 각 팀은 전문성에 맞춘 목적 지향 팀을 지향한다. 리더로써 그룹장은 업무 진행에 필요한 인력, 시간, 외부 변수를 관리하는 것이 본인의 책임이라는 것을 강조했다. 쏘카보다 더 큰 규모의 조직이라면 팀과 파트로 나눌 수도 있다.

기업 혹은 조직의 성장에 따라 규모가 변한다. 우상향하는 조직이라면 상응하는 리더와 리드 체계를 고민해야 한다. 분명한 역할 정의없이 늘어난 인력 구조나 운영 시스템은 혼란만 가중시킬 뿐 조직이 원하는 결과 도출을 어렵게 만든다. 어떤 조직 체계라도 리더와 리드가 일을 수행하는 핵심 구성 요소다. 그리고 리더 산하에 리드가 일을 수행할 적절한 인력 규모(Man power)가 뒷받침 돼야한다. 일의 실행 관점에서 지속 가능한 조직의 인원수는 10명 미만이어야 한다. 최적 인원은 4~5명이라고 생각한다. 이 숫자를 넘어서면 리드가 업무 수행보다 사람 관리에 더 많은 시간을 쏟게 된다. 속칭 개발하고 싶다는 이야기가 나온다. 마찬가지로 리더 역시 함께 일을 수행할 리드 수는 효과성을 기준으로 4~5명의 최대라고 생각하고, 적절한 수는 2~3명이라고 판단한다. 이 숫자들을 놓고 보면 리더가 효과적으로 일할 수 있는 규모는 15명 수준이고 최대 40명을 넘기지 않는게 좋은 선택이다. 넘어서면 사람에 치이다 하루를 보내는 경험을 하게 된다.

구성원의 성장을 고려한다면 리드는(혹은 리드라는 타이틀은) 유동적인 것이 좋다고 생각한다. 일을 이끌고 완성한다는 경험은 한 조직에 속한 개인이 커리어(Career) 관점에서 경험해야 할 단계다. 지식 산업 시대에서 한 개인이 알 수 있는 지식의 범위는 한정되고, 이는 AI 시대 역시 마찬가지다. 타인과의 협업은 필수이고, 협업 과정에서 일을 리딩하는 경험은 커리어의 다음 단계를 위한 필수 요소다. 조직 방향에 맞는 일감은 언제든 존재하고 이를 제한적인 리드 풀(Pool)내에서 소화시키는 것은 조직의 수행 역량의 한계를 설정한다. 성장을 위해 도전하는 구성원들이 있다면, 도전 기회를 통해 성취를 이룰 수 있다면 구성원 개인뿐만 아니라 조직의 전체 수행 역량을 키울 수 있는 바탕이 된다. 물론 리드 역할에 도전하는 구성원의 자질에 대해 리더의 냉철한 평가 잣대와 함께 결과로써 자질 검증이 완료될 때까지 리더 역할이 유동적으로 운영될 수 있는 구성원의 수용성이 전제되어야 한다. 따라서 이 경우 리드는 임명직보다는 역할에 대한 호칭으로 자리매김할 수 있어야 한다.

다만 이것 역시 조직의 규모와 조직의 경직성에 따라 맞추어 판단될 부분이다. 소규모 조직은 강한 응집력을 바탕으로 빠른 결과를 만들수 있어야 한다. 잦은 리드 교체는 응집력의 구심점 정의를 모호하게 만든다. 경직된 조직의 경우 리드라는 타이틀을 구성원이 크게 인식할 수 있다. 이 경우 리드 교체는 개인에게 큰 상실감을 안길 수 있다. 경우에 따라 조직의 화합을 깨는 기폭제가 되기 때문에 더 큰 조직 문제를 일으킬 수 있다.

Continue reading ‘계획대로 흘러가지 않는 여행’ »]]> 싱가폴 날씨는 변화무쌍했다.

와이프 동반으로 몇일 싱가폴에 다녀왔다. 자주 갈 수 있는 곳이 아니다보니 되도록 예측 가능한 일정을 수립하고 여행하고 싶었다. 모시고 가는 분이 시간을 허투로 쓰는 걸 극혐하시는 스타일이시라… 맞춰드리기 어렵다. 하지만 일주일 전 날씨 확인하고 짠 여정을 전날 다시 확인하니 그나마 해가 난다던 하루마저 비 표시로 채워졌다는… 그나마 전망대 코스였는데, 이걸 어떻하나? 난감 그 자체였다.

급한 마음에 현지에 사는 친구에게 비를 대비한 옷차림을 물었더니 비가 오면 맞으면 되고, 강하게 내리면 쇼핑몰로 가면 된다는 기대와 다른 답이 돌아왔다. 실화냐? 좀 현실적인 답을 줄 것이지 진정성이 전혀 없어보였다.

현지에 도착해 여행하다보니 그 말이 어떤 의미인지 알게 됐다. 걷는 길 대부분이 지붕 통로여서 약한 비는 안젖고도 이동할 수 있었다. 정말 강한 비가 내리면 가게에서 커피 한잔하고 있으면 이내 잦아들었다. 물론 동선이 꼬이는 건 당연했고, 예정했던 일정대로 완벽히 흘러갈리 없었다. 하지만 새로운 곳을 찾아 떠났다는 것과 빡빡한 일정 사이의 예상 못한 쉼은 여행의 본질에 충실한 시간이었다고 생각한다.

쉬면서 잠깐 돌이켜보니 변화 무쌍한 환경에서 조직을 이끄는 리더가 대비됐다. 명확히 예측하고, 결과를 만들어내는 것에 책임지는 사람이 리더다. 구성원들의 목표 달성을 위해 필요한 환경을 구성하는 것 역시 리더의 몫이다. 하지만 예측대로 놔두지 않는 변수들이 사방에 널렸고, 고착화된 환경은 아무리 노력해도 바뀌지 않는다. 이 상황에서 리더가 해야 할 일은 적응하는 것이다. 이상적인 비즈니스와 조직을 추구하는 것은 당연하지만 언제나 예상 못한 변수와 변화가 다반사로 일어하는 것이 현실이다. 현실을 인정하고 수용해서 최선의 결과를 도출하기 위해 무엇을 해야할지 리더가 최종적으로 결정해야 한다.

“여행”이라는 본질을 추구하고, 변칙을 수용하면서 환경에 적응해 “여행”의 가치를 결과로 만들어내는 것이 리더의 역할이라고 생각을 다시금 했다. 물론 현지를 잘 아는 친구의 피드백을 수용하는 것 역시 당연히 필요하고.

덕분에 여행 잘 마치고 일상으로 복귀했다.

Continue reading ‘2022년을 마무리하고 다시 도전합니다.’ »]]>

숨가빴던 2022년이 해넘이만 남았습니다. 많은 것들이 새로운 한해였던 것 같습니다. 서비스 엔지니어링 본부가 만들어졌고, 많은 구성원분들이 새롭게 합류했습니다. 특히 갓 사회 생활을 시작한 주니어분들의 1인분을 찾아가는 고군분투는 말 그대로 스토리였습니다. 고생하셨고, 감사합니다.

올해는 버킷이라는 이름으로 도메인(Domain) 조직이 시작됐습니다. 작게는 2명으로 시작했던 조직들이 각자의 도메인의 업무들이 자율적으로 진행될만큼 모습을 갖췄습니다. 모두의 참여와 기여 덕분입니다. 내년에는 버킷의 개념이 SE본부를 넘어 쏘카 전사 레벨의 버킷으로 조직화됩니다. 각 사업 및 운영 도메인들에서 서비스를 제공하는 구현자로써의 팀의 역할에는 변함이 없습니다.

2023년 상반기는 시기적으로 우리, 쏘카의 구성원에게 중요한 시점입니다. “여행의 이동”을 완성하고 신사업 FMS를 통해 수익 기반의 성장이 가능함을 고객과 시장에 알려야 합니다. 더불어 2022년 본격적으로 시작한 MSA/EDA 전환을 가속화해야 합니다. 이 과정을 통해 기술로써 이동의 즐거움을 고객분들께 적시에 제공할 수 있어야 합니다.

기대되는 여정이긴 하지만, 한편으로는 걱정도 됩니다. 서비스 구현하는데 이미 많은 제약 사항들이 있고, 시장의 상황도 녹록치 않습니다. 그럼에도 올해를 거치며 빌드업(Build-up)된 각 팀의 역량을 믿습니다. 노련한 TL분들과 거침없이 1인분 이상을 해주고 계신 주니어 분들, 그리고 그 사이를 접착제로 이어붙혀주시는 선배 개발자분들이 있습니다. 우리의 역량과 투지가 새로운 성장 기회를 만들어줄 것이라 믿습니다. One SOCAR로 방향성을 맞추고, 원팀의 힘을 제대로 보여줄 수 있으리라 기대해봅니다.

2023년, 기술 기업 쏘카가 제공하는 고객 가치를 우리 구성원분들과 함께 만들어 갑시다.

Continue reading ‘쏘카 기술 면접 제대로 하고 있다.’ »]]> 지난 번에 반가운 이야기 두가지를 들었다. 두 이야기 모두 쏘카의 기술 1차 인터뷰에 대한 피드백이었다.

첫번째 이야기.

쏘카 기술 인터뷰 과정에서 진행하는 화이트보드 인터뷰가 너무 좋아 현재 재직중인 회사에 도입하셨다는 것이다. 쏘카에서 중니어 및 시니어 면접은 온라인 코딩 테스트(문제 풀이)를 하지 않는다. 대신 코드와 기술 구조를 정의할 수 있는 살펴보기 위해 화이트보드를 사용한다. 경험했던 구조를 설명을 위한 그림으로 그려낼 수 있는지, 설명할 수 있는지 살펴본다. 그리고 간단한 문제를 제시하고, 스스로 조건을 정의해서 자신이 가장 익숙한 코드로 풀어내길 요청한다. 면접관과 지원자 사이에 많은 인터랙션(서로 주고받기)는 필수다. 설명하고, 질문하고, 그림 그리고, 적는다. 토론 방식으로 진행한다.

면접관들은 토론 진행 과정을 통해, 지원자분의 기술적인 역량이 우리가 필요한 역량에 부합하는지 살핀다. 동료와의 협업과 주니어의 성장을 도와줄 수 있는지도 마찬가지로 중요한 포인트다. 이 과정을 면접관들이 꼼꼼히 기록한다. 이것이 다음 단계의 면접과 평가를 위한 기초가 된다.

화이트보드 코딩 테스트를 우리만 하는 건 아닐 것이다. 다만 우리의 방식은 면접관 분들의 많은 시간 투자가 필요하다. 면접 자체도 1시간 반에서 길게는 2시간까지 이어진다. 물론 지원자를 파악하기 위해 들어가는 사전 한 두시간은 필수다.

이 경험을 벤치마킹 해주셨다는것에 감사하다는 이야기를 꼭 전하고 싶다.

두번째 이야기.

지원자분이 1차 인터뷰에서 탈락했다. 1차 인터뷰 결과는 몇 페이지 분량으로 기록된다. 1차 기술 인터뷰 탈락자분께서 원하시면 피드백을 전달드린다. 지원자분이 우리 기대와 달랐던 부분이 어느 부분들이었는지, 발전을 위해 보완되면 좋을 부분들을 채용 담당자가 메일이나 전화로 연락드린다.

이 분께도 채용 담당자분이 정리된 자료를 바탕으로 전화로 지원자분께 탈락 결과를 말씀드렸다. 보통은 이렇게 절차가 마무리된다. 그런데 지원자분이 주니어로 다시 지원 의사를 밝혔다. 경력이 4년 이상인 분이 경력 포기나 다름없는 주니어 포지션으로 지원하다니?

면접 진행했던 분께 여쭤보니 2시간 정도 면접을 진행했고, 지원자의 역량을 파악하기 위해 많은 대화가 오갔다고 전해줬다. 과정이 지원자분께 성장할 수 있는 회사라는 경험을 준 것 같다. 바로 다음 차수의 주니어 온라인 코딩 테스트부터 진행하는 것으로 지원자분께 전달했다.

쏘카에 와서 아마 가장 먼저 손을 대고, 과정을 계속 살펴보는 부분이 면접 프로세스이다. 쏘카는 성장을 원하고, 또 해야한다. 이를 실현할려면 인재들이 필요하고, 쏘카의 성장과 어울릴 수 있는 사람인지를 평가할 수 있는 체계가 있어야 한다. 그렇기 때문에 우리의 인재상은 무엇인지 그 인재상에 도달하기 위해서 어떤 과정을 구성원들이 거치게 될지를 이야기한다.

오늘, 이 두가지 경험은 채용의 핵심에 있는 쏘카 서비스 개발 조직의 인터뷰 담당자들이 제대로 하고 있음을 증명한다. 감사하고 고마운 일이다. 개인의 성장을 통해 조직의 성장을 추구하는 일. 성장하는 쏘카는 현재는 이 방향성을 추구한다. 그리고 많은 분들의 노력 덕분에 우리는 현재 진행중이다.

추가로 이 채용 인터뷰 방식과 프로세스, 더욱 널리 퍼졌으면 좋겠다. 다른 회사에도 마찬가지로 정답이 될 수 있을지 없을지 모른다. 하지만 벤치마크 대상은 될 수 있지 않을까? 그럼 스스로에게 가장 적합한 방법을 찾을 수 있을테니. 이 과정을 통해 우리 나라에서도 제대로 된 채용 인터뷰가 정착되지 않을까? 기술쟁이로써의 첫걸음이 여기서부터 시작이라면 한국의 개발 문화가 쫌 제대로 동작하기 위한 첫걸음에 보탬이 될 수는 있을지도 모르겠다.

기분좋다!

Continue reading ‘라이엇: 6년 3개월의 기록’ »]]> 말그대로 파란만장했던 시간이었던 것 같다. 즐거웠던 기억도 정말 치열했던 기억도 다양하다.

좀 더 업데이트를 하겠지만, 그래도 그 시간의 추억을 기록해둬야 잊지 않을것 같아 남겨둔다.

2015년

배운것도 많았고, 좋은 사람도 만났던 네이버 시절을 마무리하고 7월, 라이엇에 입사했다. 글로벌 회사는 어떻게 일할까 싶은 기대를 안고 첫출근.

구글이나 마이크로소프트와 같은 글로벌 회사에 대한 환상이 있었던 것 같다. 약간의 실망? 걍 한국 회사네?

그럼에도 즐겁게 라이엇 생활을 시작했다. 입사 후 두달 채 안됐는데, 오리엔테이션 비슷한 교육이 본사에 있고 당근 다녀와야한다고 하네! 오!!!! 미국 출장을 가긴 가는구나~ 난생 처음 미국행 비행기에 올랐고, 함께 가는 친구들과 “우리가 언제 미국 본사에 와 보겠나?” 라는 생각으로 교육 후에 돌아볼 만한 명소들을 돌아봤던 것 같다. 사실 교육이기 때문에 뭐 그닥 업무라는 건… 본사 구경도 잘 하고 LA 구경도 잘 했다. 뭐 언제 또 출장을 오겠어.

10월에 월챔 웹 사이트를 급하게 만들어야 한다고 요청이 들어왔다. 글로벌 사이트가 있는데, 왜 이걸 다시 만들어야할까? 상황을 보니 만들어야 했다. 웃픈 현실이라고 해야할까?

처음으로 미국 친구들과 일을 시작했다. 처음에는 메일로, 그러다가 행아웃 채팅으로. 매우 재미있었던 건 영어로 말하는 사람이 제한적인 거. 다들 똑똑한 사람들이고 영어도 배울만큼 배웠는데 본인들 입으로 이야기하는게 아니라 다른 사람들 입을 빌려 이야기할까? 신박하달까? 직접 이야기하겠다고 말하고 본사 친구들이랑 작업을 했다. 시차라는거 정말 블러커다. 몇일 걸리지 않을거라고 생각했던 작업을 마무리하는데 한달이 걸렸다!!! 설마 여기와서 밤을 새겠어 했지만 시차때문에 몇일을 밤샜던 것 같다.

이후에 올스타 웹까지 만들어야 한다고 해서, 출장 다녀오겠다고 했다. (한국에서 작업하는거 힘드니 출장가는게 좋을거라고 꼬득인 친구… 얼굴 본지 오래됐네.) 무려 혼자! 혼자 뱅기타고 혼자 호텔에서 잠자면서 본사 친구들과 2주 동안 작업했다. 행아웃으로 이야기할 때 “싸가지없는 놈”을 실물로 봤고, 오해였다는 걸 알았다. 친절하고 착한 친구였다. 더불어서 서너명 eSports Web 담당하는 개발자 친구들과 PO를 사귀었다. 2~3주 이렇게 있다면 말 그대로 친구가 된다. 이때 사귄 호주에서 온 여전히 좋은 친구도 있다.

2016년

기술 부채 갚아나가기

급한 작업을 일단락 후 왜 이런 작업을 반복해왔는지 고민했다. 한국만의 특성이 과도하게 반영된 한국의 계정 체계가 만악의 근원이었다. 하지만 이걸 당장 고칠 수 있는 상황은 아니니 우선 인증 시스템부터 센트럴 시스템과 맞추자라는 생각했다. 여기서 발견한 또 다른 만악의 근원. “.co.kr” 도메인. 한국적이지만 시스템적인 통합에는 확실한 걸림돌이다. 형식이 아니라 내용과 진심이 전달되는게 정답이다. 이 정답을 향해 가자!

사실 문제가 이것뿐이겠나? 한국 시스템의 문제도 있었지만, 한국 요구 사항을 본사 시스템도 받아들이기에 아직 준비가 안됐다. 뭐 별수 있나? 또 비행기탔다. 새로운 친구들도 사귀고 두어번 관련 출장 이후에 한국에서도 미국쪽 인증 시스템을 사용할 수 있게 됐다. 과정에서 어떻게 하면 한국에서 운영하는 계정 시스템을 본사 시스템과 통합할지 생각하기 시작했다.

출장 후 돌아와보니 얼떨결에 팀장이 됐다. 개발만 할려고 왔던 건데…

핵과 욕설의 시대

2015년부터 커뮤니티에서 이슈가 되던 핵과 욕설이 본격적으로 무대로 올라왔다. 물론 그 전부터 문제를 인지했고, 해결 방안들을 내부적으로 계속 고민해왔다. 이정도면 대응이 가능하다고 한국 오피스 내부에서 계획을 수립하고 준비를 시작했다. 다만 글로벌 시스템들이 이미 있는데 “왜 그렇게까지 할 필요가 있냐?” 라는 본사 각 영역의 담당자들의 반대가 있었다. 아무리 글로벌 회사라고 하지만 플레이어들이 플레이하는 방식은 다르다. 어찌보면 그게 문화라고 지금도 생각한다. 하지만 글로벌 서비스를 통해 해결해야한다라는 취지의 반대가 크게 발목을 잡았다.

한국팀에서 서비스를 개발한다고 하더라도 센트럴 팀의 도움을 받아야 한다. 불행히도 도움받아야 할 서비스에 대한 오너십(Ownership)은 센트럴 팀들에 있었다. 대응 가능한 한국 서비스를 만들어가는 과정에서 이 컨텍스트(Context)를 이해시킬려고 안되는 영어로 정말 많이 노력했다. 하지만 오너십은 정말 큰 허들이었다. 한국 서비스를 접목시키기만 하는데 그 과정이 정말 치열(처절)했다. 많은 사람들의 노력으로 완벽하진 않지만 한국 시스템이 준비됐지만, 여전히 하나의 서비스를 거스르는 한국 시스템에 대한 반대는 남아있었다.

한국 리더십에서 이 문제를 풀려고 몇번이나 태평양을 왕복했지만, 결론은 앞으로 나아가지 못하고 공회전 상태였다. 결국 한국 리더십에서 결정했다. 물론 준비에 대한 확신이 있었지만 믿기지는 않는 결정이었다. 대단했다!! 한국 서비스 시스템들을 턴온했다. “일해라 라이엇!“의 핵심인 서비스들이 릴리즈됐다. 반응은 말 그대로 대박이었고, 롤을 접었던 플레이어들이 다시 돌아오기 시작했다.

2017년

치열함 이후의 평온함. 2017년은 평안했던 것 같다.

센트럴 개발팀 방문!

치고박고 겁나 싸우던 본사 개발팀이 한국으로 온단다. 엥? 사업팀이나 PO가 아니라 개발자들이 온다구?

사실 한국 오피스를 셋업된 이후에 본사 개발자들이 한국팀과의 협업을 위해서 방문한 첫번째 사례였다. 더구나 온전히 한국팀이 개발한 서비스에 대한 지식을 얻고, 협업을 목적으로 온다고 하니. 개인적으로 매우 신났다! 오기전에 한국팀에 궁금한 점과 한국팀에서 협업하고 싶은 부분들을 정리했다.

정말 회의에서 서로 욕하기 직전까지 갔던 친구들이 드디어 사무실에 등장했다. 역시나 얼굴보고 이야기해보니 달랐다. 문화가 다르면 접근하는 방법도 달라야 한다는 부분에 공감대가 생겼다.  비로소 그 친구들도 왜 우리가 이렇게까지 서비스 개발에 매달렸는지, 왜 한국 서비스가 글로벌 서비스보다 더 잘 동작하는지 이해했다. 그리고 2주간에 걸쳐서 한국 사무실에서 함께 작업을 했다. 물론 쏘주는 덤이었다. ㅎㅎㅎ

서로가 서로에게 쌓인 오해를 풀게됐고, 이 친구들 가운데 베프도 하나 생겼다. 나중에 출장갔더니 얻어먹었다고, 본인들 회식 자리에 데꾸가서 신박한 LA 음식 먹을 기회도 줬다는… (하지만 나에게는 역시 한식이…)

로열티, 숙원 사업을 시작하다.

한국의 비지니스를 담당하는 큰 축 가운데 하나가 PC방 사업이었다. 초기에 사업을 진행하기 위해 센트럴 팀이 이 시스템을 만들었는데… 비지니스는 한국에서 하는데 서비스 개발은 센트럴 팀에서 진행하다보니 많은 어려움이 있었다. 소통도 문제고, 시차도 문제고. 플레이어분들도 고통이고 업주분들도 고통이고 서비스를 운영하는 우리도 고통이었다. 이 고통을 센트럴 팀에 전달하는 것도 또 고통!!!

대차게 이 서비스를 한국팀에서 오너십을 가지고 재개발하겠다고 선언했다. 관련 팀들에게 이 프로젝트의 진행을 알렸다. 센트럴에서도 이 서비스에 대한 이해가 부족했고, 계속 문제가 발생됐던 영역이었기 때문에 반겼다. 계륵이라고 생각되던 서비스였기 때문인지 모르겠지만 순조롭게 한국팀의 오너십을 인정했고, 개발 팀을 셋업하고 2년이 넘는 긴 여정이 시작됐다.

2018년

새로운 준비의 시대가 도래했다.

LCK 그리고 앱!

LCK 리그의 격변이 시작되는 시점이었다. 종로에 경기장도 만들기로 했고, 자체 방송을 하는 것으로 결정됐다. 그리고 이걸 데이터 서비스의 형태로 만들어보자! 앱으로!!

전사 과제로 결정이 됐고, 앱을 개발할 수 있는 역량있는 개발자들도 뽑고… 9개월쯤의 긴 여정끝에 Ice Boxing하는 것으로 결론. 가장 결정적인 이유는 앱에 대한 전사(글로벌) 정책이었다. 앱이 한창 흥하던 시절이었고, 사내에서도 서비스 앱을 만들자는 것이 붐이었던… Awesome! 이라는 이야기를 많이 듣긴했지만. 무분별한 앱 개발에 대해 새로운 정책이 생겼다. 사실 우리만 앱을 개발할려는 건 아니었으니까. 이 정책을 비껴갈 수는 없었다. 라이어터니까.

이 프로젝트를 진행하면서 느낀 또다른 시사점은 오너십이었다. 본사와 매번 이 오너십때문에 치고박고 했는데, 정작 우리 스스로에게 요구되는 오너십에 대한 고민은 적었던 것 같다.

일을 하는데 오너십이라는 것으로 뭘까? 스스로 재미있는 일을 한다는 것과 결과를 만들어내기 위해 주도적으로 하고, 한 일에 대한 책임을 온전히 감당하겠다는 자세… 많은 생각이 들게 만들었다.

이 프로젝트는 중단했지만 이후 다른 프로젝트에 개발된 기술/경험들이 요모조모 사용됐으니까 만족한다.

롤 그 다음 게임

슬금슬금 롤 다음 게임에 대한 이야기가 나왔다. 한국에서도 본격적으로 멀티게임 시대를 위한 준비를 시작했다.

멀티게임 시대를 위한 첫번째 여정은 이를 감당할 수 있는 조직 만들기. 명목적으로만 존재하던 팟(Pod)이라는 조직을 구체화하고, 역할을 명시했다. 팟은 서비스 조직으로 서비스 중심으로 팟이 서비스 담당과 유지보수를 주도적으로 수행한다. 서비스가 없어지기 전까지는.

다음으로 필요한 것들은 적폐청산! 소위 기술 부채라 불리는 것들을 없애는 것이다. 운영이 급격하게 돌아가다보니 이 부분을 안고 갈 수밖에는 없었다. 하지만 새로운 게임이 출시됐을 때 이 부채들이 발목을 잡았다. 나아갈려면 먼저 이것들을 치워버려야했다. 청산해야할 적폐들이 어떤 것들이 있는지 파악했다. 쌓인 부채가 어마어마하기 때문에 한번에 이 부채들을 털어버릴 수는 없었다. 부채를 점진적으로 갑아나갈 방법과 그 사이에 이자를 어떻게 낼지등도 함께 고민해야했다.

신규 게임이 출시된 이후까지 이 기술 적폐 청산이 마무리되지는 않았다. 하지만 부채를 부채로 인식하고 갚아나갈려고 하는 노력을 시작했다는 것이 중요하다. 당장 할 수 없다고 안하면 결국에 부채가 이자 포함해서 어마어마한 눈덩이라가되어 굴러온다.

2019년

롤 다음 게임이 구체화되었다. 한국에서 여러 게임들을 운영한다고 했을 때 필요한 것들. 이것들을 정리하고 개발할거라고 선언하고.

정말 부지런히 태평양을 오고갔다. 소위 Game Agnostic Service 체계로 만들고, 특정 게임에 대한 의존성을 최대한 없애기 위해 노력했다. 여전히 가장 큰 어려움은 한국이라는 지역의 플레이어들과 운영의 특성을 함께 협업해야할 게임팀을 비롯한 플랫폼 영역의 팀들에게 이해시키고, 협조를 끌어내는 것이다. 부단히 노력했고, 로열티 서비스와 Anti-Addiction Service, 한국말로 하면 셧다운제? 를 기존 서비스들을 대체해서 여러 게임에 하나의 플랫폼으로 적용하도록 개발시켰다. 계정도 롤 기반 계정에서 라이엇 계정으로 한국 환경에서 운영되도록 만들고…

와중에 좌충우돌하는 다른 지역 팀도 좀 도와주고. ㅎㅎ 우리도 바빠 죽겠는데, 다른 지역을 도와주는게 실화냐고 욕도 좀 먹었다. 하지만 한국팀의 존재감을 다른 팀들에게 톡톡하게 보여줬고, 고맙다는 이야기도 들었다. 그럼 된거지.

버라이어티했던 것 같다.

그리고 롤 다음의 첫번째 PC 게임, “레전드 오브 룬테라” 서비스 준비를 마쳤다.

2020년

2019년 말에 코로나라고 하는 신박한 병이 발병하더니 전 지구를 휩쓰는 전염병이 되었다. 2월말에 이 와중을 뚫고 마지막 출장을 다녀왔다. 한국에서 본격적인 PC방 서비스를 제공할 “발로란트”의 운영 환경 준비를 위해.

모든 준비를 마치고 한국에서 이제 제대로 RiotGameS가 되었다. S의 무게감이 엄청 무거웠고, 정말 열심히 준비했던 것 같다.

• 1월 – 레젠드 오브 룬테라 베타 시작.
• 4월 – 발로란트 베타 시작. 레전드 오브 룬테라 정식 및 모바일 시작.
• 6월 – 발로란트 정식 서비스 및 PC방 서비스 시작.
• 7월 – 와일드리프트

이제 남은 기술 부채 해소에 전력을 기울여서 Seamless service environment를 만들어야 할 때다.

해야만 하는 일을 하는 시대를 끝냈다. 이제 우리가 할 수 있는 일들은 뭘까를 고민할 시점이다.

2021년

게임을 넘어서 다음 여정의 방향은 어딜까? 한국팀이 가지고 있는 서비스들의 역량을 강화하는 것이었다. 지속적인 서비스를 한국 플레이어들에게 제공하기 위해서는 반드시 필요하다. 한국은 사업과 개발이 정말 굉장한 시너지를 내고 있는 팀이었다. 이런 시너지가 계속 이어지게 하기 위해서는 “역량”이 필요하다고 판단했다.

우리가 개발한 서비스들은 한국 환경이라는 목적을 가지고 처음 개발이 시작되었지만, 이제는 다른 곳에서도 이걸 활용할 수 있는 여지도 생겼다.

명분, 기회, 가능성…

여러 단어들이 있을 수 있겠지만, 나의 여정은 여기까지.

10월의 마지막 근무일에 나의 라이엇 여정은 막을 내렸다.

이제 남은 사람들의 몫이다.

Continue reading ‘Hi~ there’ »]]> 새로운 시도라는 건 항상 두려움이다. 있던 틀 안에서의 나는 안전하다. 그 안전함을 벗어나 미지로 향하고 싸워야한다는 건 괴롭기도 하고 어떤 때는 정말 하기 싫다.

와중에 모든 일이 생각만큼 순조롭지도 않고, 별 생각하지도 않았던 곳에서 장애물이 튀어나마 마음도 괴롭고 몸도 괴롭게 한다. 요즘이 아마도 딱 이런 형국이다. 업무적으로도 개인적으로도.

아마도 살아오면서 성공보다는 좌절이 많았고, 그냥 주저앉아서 한걸음도 움직이기 싫은 적도 있었다. 마음대로 되지 않고, 하고 싶어도 할 수 없었다. 그럼에도 어떻게든 일어나 지친 걸음을 내딛었고, 정말 걷기 싫은 걸음을 내딛어 걸었다. 그래서 지금 여기에 있다.

Hi~ There.

어렵지만 그래도 가야겠지. 결론은? 글쎄 해피 엔딩일지 새드 엔딩일지 모른다. 그럼에도 다른 사람이 결론을 내주는 것보다는 성격상 내가 결론을 내는게 좋다. 부디 해피 엔딩이어야 하는데 말이다.

Continue reading ‘현실에서의 재택 근무’ »]]> 지난 3월 초에 재택 근무에 대해 간단히 글을 적었는데, 어느새 원격 근무를 5월 중반까지 해오고 있다. 회사 전체적으로는 2월말부터 원격 근무를 시작했으니 어느 덧 만 3개월을 다 채워가고 있다. 이 정도의 기간을 재택으로 지내다보니 얼추 이런 근무 형태도 할만하다는 생각이 든다. 업무만 봤을 때 해야할 일들이 거의 적절하게 진행되고 있는 느낌이긴 하니까.

재택 근무의 일상을 정리해보면.

출장을 못가다보니 본사쪽과 일은 지속적으로 챙겨야 한다. 슬랙으로 이야기가 잡다하게 길어질 것 같으면 아침에 콜을 잡지만, 그렇지 않은 경우에는 커뮤니케이션 하는 타이밍을 잘 잡아서 끊어지지 않게 해야한다. 말 그대로 이야기 줄기가 끊어지면 잊혀진다. 끊어진 걸 다시 이어 붙이려면 어렵기도 하고 투자해야할 시간도 많이든다.

그래서 아침 기상 시간은 재택 전과 비슷하게 6시 반이나 7시 사이를 유지한다. 전날 보내 둔 메시지에 대한 답글을 확인하고, 우리쪽 채널에 올라온 요청들이 있는지를 휴대폰으로 확인한다. 일상 다반사가 항상 바쁜 건 아니지만, 답을 얻어야 하거나 논쟁중인 사안이 있다면 후다닥 노트북 앞에 앉는다. 지금 내가 이야기를 던져야지 그 친구들이 답한다. 본사쪽은 오후 4시 근방이라 아직 일하고 있을 시간이다. 30분, 한시간 가량 본사 친구들과 이야기를 하고, 우리가 챙겨야 할 사항들이 있다면 관련 팀 채널에 내용을 전달한다.

출근 준비

8시 즈음에 시작하는 뉴스를 본다. 전에는 다음 뉴스에서 주로 새소식을 들었다면 재택 이후에는 YTN이다. 종종 쉬는 시간에도 가까이에 있는게 TV다 보니 정말 자주 보는 것 같다. 어제 발생한 코로나 이슈들을 중심으로 이야기를 듣는다. 참 세상 개념없는 인간들이 많다라는 걸 이번 사태를 겪으면서 다시금 확인한다. 국내, 국외 모두.

이쯤되서 와이프가 아침먹으라고 힘찬 소리를 들려주신다. 온라인 수업으로 등교해야만 하는 딸네미가 허우적 거린다. 처음 온라인으로 수업이 진행될 때만해도 짜증 대마왕이었다. 하지만 최근에는 동영상 스트리밍도 안정화된 것 같고, 한번 들은 수업을 다시 들어야하는 경우는 없어진 것 같다. (LG, MS 에저 화이팅!) 재택하면서 딸과 같이 밥먹는 시간이 많아졌다는 건 정말 좋다. 물론 전에도 아침은 매번 같이 먹긴 했지만 6시 반에 먹어야만 하는 아침밥이 딸에게 기분좋은 식사는 아니었을테니까. 온라인 수업 시간의 아침밥 먹는 시간은 8시에서 8시 반이다. 이정도만 되도 거의 짜증이 없었다. 전에는 왜 7시 반까지 등교하라고 한거지? 걍 9시까지 등교하라고 해도 충분할 것 같은데. 학교와서 책상에 코박고 잘께 뻔한 걸.

밥 든든하게 먹고 출근 준비한다. 양치하고 면도하고 샤워하고. 단장하고 근무복으로 갈아입는다. 이제 준비 완료!

완전 아재스럽다. 그렇다고 꽃중년도 아니니 걍 스킵. 을 보고 아이디어를 얻은 건 아니다. -_-;;; 하지만 넘 편하면 Naive해지는 건 어쩔 수 없이 부장님에게 동의. 전에도 이렇게 입었는데 걍 근무복이라고 생각하자. 사실 미팅하다보면 난닝구(메리야쓰???)부터 잠옷, 샤워 가운까지 다양하게 등장한다. ㅎㅎ; 일만 잘하면 되지, 복장은 편한 스타일대로 입는거지 뭐.

출근해서 업무 시작

회사에 출근했을 땐, 커피 머신에서 내려먹거나 바리스타분께 부탁드려 한잔 먹는게 습관이었는데, 그 습관 버리기 힘들다. 재택에서는 내가 바리스타.

이렇게 내린 커피는 전자렌지의 도움을 받아서 오후까지 먹는다. 물론 그 사이에 믹스도 두봉지쯤은 달달하게 타 먹지만. 막 내린 커피들고 이제 출근한다. 아드님께서 학교로 가버린 이후에는 아들 방이 내 근무처다. (탱큐~ 아들!) 좀만 제대로 된 공간이었다면 더 좋았을걸 하는 아쉬움도 있긴 하지만. 거실 한켠에서 쪼그려서 일하던 때보다는 한결 낫다. 9시 반에서 10시 사이에 자리에 앉아서 이제 본격적으로 근무를 시작한다.

오전 근무는 밤새 온 이메일들을 정리하고, 어제 퇴근 이후에 한국쪽에서 이야기된 내용들을 살펴보는 것으로 시작한다. 대부분 슬쩍 훝어보고 지나가지만, 간간히 참견해야할 내용들이 이메일로 온 경우가 있다. 필요한 것들에 대해서만 회신한다. 메일과 슬랙 훑어보는게 끝나면 이제 아침 데일리전에 해야할 코드 작업이나 할당 작업들을 한다. 데일리에서 공유할 내용들 대부분은 어제 해두긴 했지만 간간히 미진하거나 마무리 못한 꺼리가 있다. 아침 이 시간이 집중이 잘 되기 때문에 나름 일할만 하다. 마무리가 됐다면 Jira Ticket을 Done으로 marking한다.

데일리(Daily)

오전 근무의 하이라이트는 데일리(Daily)다. 에자일을 고집하는 분들이나 전문가들이 이야기하는 Daily는 아니다.Jira 보드 놓고 한일/할일 혹은 넋두리를 한다. 어찌보면 딱 아침 조회다!! ㅎㅎ

11시가 되면 5~7명쯤 개발팟 인원들이 행아웃에서 모인다. 가장 연장자 분이 BGM을 깔아놓으면 사람들이 모일동안 감상의 시간을 갖는다. 얼추 참석자들이 모이면 진행자가 순서대로 Jira 보드에서 담당자를 선택하면 업무 이야기를 공유한다. 오늘 할일이나 어제 겪었던/논의했던 이슈나 Blocker들에 대해 이야기한다. 진도를 많이 빼신 분은 Backlog에서 할만한 일이나 Sustaining꺼리를 물어본다. 동료가 봐줬으면 하는 걸 이야기하면 그걸 도와주거나 아님 팟 리드가 처리되어야 할 꺼리를 백로그에서 뽑는다. 두루두루 이야기하고, 마지막으로 팟 리드가 어떤 일들이 있으면 챙겼으면 좋겠다는 것으로 마무리한다.

형식을 보면 에자일식은 아니고 칸반 스타일인가? 오피스에서 모여서 이야기할 때는 15분안에 끝내는게 목표였고, 대부분 그 시간안에 마쳤던 것 같다. 하지만 온라인으로 진행하면서 전체 시간이 좀 오래 걸린다. 이건 꼭 데일리 뿐만 아니라 거의 모든 회의들이 오피스 미팅룸에서 모여서 하던 것보다는 전체적으로 길어졌다. 한번에 여러 사람이 한꺼번에 이야기할 수 없다는 제한이 있기 때문이기도 하고 같이 얼굴 맞대고 이야기할 기회가 없다보니 다들 한 두마디씩 더 하는 것 같다. ^^;

Work & Break in the afternoon

정리하고 데일리에서 나온 것들 가운데 바로 F/U해야할 꺼리를 봐주고 하다보면 12시다. 12시라고 꼭 밥 시간은 아니다. 하지만 2시간 정도 일했으니 쉬는 시간이 맞긴 하다. 닫혔던 방문 열고 거실로 나가서 가족들과 잠깐 이야기도 하고 새로 나온 코로나 확진자 수도 확인한다. 최근에는 거의 자리수가 한자리 수라서 다행이라는 생각이 든다. 하지만 백신과 확실한 치료제가 나오기 전까지는 끝나도 끝난게 아니라는거.

내가 때를 챙기지 않더라도 따님 덕분에 1시 되기 전에는 거의 점심을 먹는 편이다. 물론 삼시세끼를 다 챙기느라고 와이프 고생이 많다. 와중에 나는 미팅중, 딸은 온라인 수업중이라 와이프만 쥐죽은듯이 거실이나 침실에서 꼼짝도 못한다. 얼떨결에 갇힌 신세가 되버렸다. 원래 집에서 낮시간은 와이프의 공간과 시간이었는데, 난데없이 딸과 내가 이걸 빼앗아버렸으니…

점심 먹고, 커피 한잔 후 다시 문닫고 업무 복귀. 데일리를 빼고 하루에 보통 1~2개의 미팅이 있다. 한국팀과 미팅은 거의 한시간을 꼬박 채운다. 참석하는 사람도 좀 많은 편이고 사람당 두서너 마디 이야기가 돌고나면 훌쩍 1시간을 채우는게 다반사다. 미팅 끝나고, 메일이나 슬랙 메시지 보내다보면 두시간쯤이 훌쩍 간다. 거북 형상으로 목이 뻣뻣해질 때쯤이면 거의 3시 근방이다. 쉴때다.

오후에는 한두번쯤은 아파트 주위를 3~4번쯤 돈다. 3월부터 거의 빼먹질 않았다. 덕분에 시간이 이렇게 가고 자연이 이렇게 변해가는걸 눈으로 본다. 그 전에는 제대로 느끼지 못했던 새로움이다. 그러고보니 겨울의 끝자락에 이 생활을 시작해서 이제 여름으로 접어든다.

산보에서 복귀 후 다시 일을 시작한다. 대강 요 무렵이면 집안일의 갱킹이 들어온다. 5시나 6시 근방이면 쓰레기를 버리거나 분리 수거에 관련된 업무 요청이 들어온다. 잘 보여야 후환이 없기 때문에 정 급하지 않으면 바로 처리해야 한다. 그래도 이 시간 타임이 가장 일을 많이 하는 시간대다. 2~3시간 연속으로 몰입해서 일할 수 있는 시간이 많다. 최근 2~3주 사이에는 코딩 이외의 다른 행정 업무들이 많아서 이런 시간을 갖기가 어려웠는데, 대강 마무리해서 다시 코딩에 복귀하고 있다. 이렇게 중간에 쉬어버린 시간이 많으면 예열에도 시간이 오래 걸린다. -_-;;; (몸은 못 속이나?)

퇴근

6시 반이나 7시쯤되면 따님이 “퇴근했어?“고 물어본다. 상황따라 약간씩 잔업이 있긴 하지만 대부분은 그 시간 즈음이면 슬랙 채널에 “퇴근합니다.” 라고 이야기한다. 슬랙 알람은 7시가 지나면 자동으로 Off된다. 바꿀 수도 있지만 굳이 그러지않는다. 일단 해야만 하는 일들은 처리했고, 해야할 일들은 Calendar에 적어두거나 Ticket으로 정리해뒀다. 이제 정말 놓친 일들이나 내가 하고 싶은 것들을 한다.

오후 내내 놓친 뉴스를 좀 보기도 하고, 못읽은 책을 읽는다. 책을 읽는다고 이야기를 해봐야 하루에 한시간 남짓이 될까말까다.

와이프와 딸과 저녁먹고, 최근 재미있는 드라마나 예능 보면서 이야기를 나눈다. 이전에는 가족과 이야기하는 시간이 평균 30분 넘을까 말까였다면 재택 이후로는 적어도 1시간 이상이 되니까 고건 참 바람직하다. 특히 딸과의 대화 시간이 많이 늘어난 건 개인적으로 기쁜 일이다.

재택. 하다보니.

일하는데 있어서 몇가지 보이는 것들이 있긴하다. 일단 준비된 재택 근무를 하기 위해서는 필요한 것들이 많다. 그 가운데서 가장 큰 문제는 가족으로부터의 동의와 협조가 무엇보다도 필수적이라는 것이다. 집에서 일하는 것에 대한 가족의 인식과 협조가 없다면 재택은 불가능하다. 특히 현재의 재택 상황을 봤을 때 더욱 그렇다.

챙김이 필요한 육아를 본인이 병행해야하는 상황에서의 재택은 불가능하다. 차라리 휴가를 내는게 본인의 정신 건강을 위해서 낫다.

커뮤니케이션에서 진심이 보여야 한다. 그래서 온라인 화상 통화에서 얼굴은 가급적 보여줘라. 정장을 입고 있으라는 이야기가 아니다. 말 그대로 얼굴을 보여주라는 것. 대화에서 표정과 제스처는 생각 이외로 많은 것들을 전달한다. 이건 수화에서 왜 표정이 중요한 역할을 하는지와 어찌보면 같은 맥락일 것이다. 한국팀은 그래도 본사 친구들과 콜을 많이 해서 기본적으로 얼굴을 보여줄 것이라고 생각했는데 이외로 거의 보여주지 않는다. 보여주지 못한다면 못하는 그것 자체에 문제가 있다. 육아 관련 예외를 빼고 나머지는 이유가 안된다.

명확한 근무 시간을 명확히 하고 알려야 한다.  본인을 위해서도 협업하는 동료들을 위해서도. 종종 재택이라고 근무 시간을 본인들의 작의적으로 정해버리는 경우가 있다. 근무 시간을 정하는 이유는 협업을 위해서다. 당연히 한국 상황만 놓고 본다면 9시부터 6시 사이를 근무 시간으로 정한 이유는 그 시간이 보편적으로 연락 가능하고 협업이 가능한 시간임을 모두가 암묵적으로 동의하기 때문이다. 메신저 뒤에 숨어서 페이크치다 걸리면 쪽팔린다. 재택이라고 하더라도 근무 시간이 변경된 건 없다. 가능하면 지켜야 하고 못지키면 이야기해서 협업에 방해되지 않도록 알려야 한다.

부재는 알려라. 오피스 공간에서 근무를 선호하는 이유는 고개 돌리면 동료가 옆에 있고, 이야기할 수 있기 때문이다. 온라인으로 일을 하는 경우에도 마찬가지 환경이 되야 한다. 오피스에도 자리 비운다면 자리 비운다고 동료에게 이야기한다. 마찬가지로 행동하면 된다. 재택이라고 다르지 않다.

팀을 생각해야 한다. 재택은 공간적으로 팀을 배제한다. 혼자있는데 뭔, 팀… 때문에 더욱 더 개인화된다. 같은 공간에 팀이 모여있는 공기와 자신만의 공간에서 느끼는 공기는 당연히 틀리다. 팀이 팀으로 느껴지는 이유는 공간적인 이유가 크다. 하지만 재택은 이를 분리한다. 이런 거리감을 인위적으로 줄일 수 없다. 강제로 줄여봐야 파열음만 난다. 스스로 팀원이어야 한다. 자발적으로 팀의 상황을 이해하고 팀의 발전을 위해 기여해야 한다. 정해진 일만 하겠다면 재택과 맞지 않는다. 아니 되려 팀 플레이 자체가 맞지 않는거 아닐까도 싶다.

••••••

재택은 팀 플레이를 시험한다고 보여진다. 공간으로 분리된 상황에서 개인이 팀이라는 인위적인 공동체를 유지할 수 있을 것인가? 이 과정에 스스로 있기도 하고, 결과가 어떻게 나올지 기대된다. 본사에서도 실패했고, 때문에 공간을 중심으로 팀을 유지하는 것이 현재 정책이었다. 이제까지 나도 이에 동감했고, 크게 바뀌지 않았다.

하지만 기대 이외의 결과를 보고 싶다. 당장 재난 형국을 넘어서기 위해서도, 그리고 먼 미래를 위해서도 ^^;

Continue reading ‘원격 근무(Remote working) – 꿈과 현실의 차이’ »]]> 2020년은 파란만장하게 시작했다. 그리고 3월의 어느 시점을 관통하는 지금 개인을 넘어 전세계적으로 “코로나19 바이러스“로 혼란의 도가니 안에 있다.

바이러스의 습격은 한국 기업에게 원격 근무를 선택지로 강요하고 있다. 한 공간에 사람이 모이는 것 자체가 감염의 근거를 제공하기 때문에 업무를 이어가기 위한 어쩔 수 없는 선택이 되버렸다. 몇 일 전직원 휴가를 쓸 수 있겠지만, 그 기간은 몇 일을 못 넘긴다. 감당이 된다면 직원들이 사장님 “쵝오!!!” 를 외칠텐데 말이다.

나도 현재 원격 근무를 시전중이다. 불가항력적인 몇몇 부서를 제외하고는 오피스에 속한 모든 사람들이 원격 근무를 하고 있다. 다른 팀들과 비교했을 때 개발팀은 해외 팀들과 그동안 협업을 해왔고, 그 팀들은 어떤 식으로 원격 근무를 하는지를 봤었으니까… 협업할려고 본사갔더니 이 친구가 원격 근무하는 친구라서 삼실에 안나온다는… 뱅기타고 힘들게 날라왔는데, 정작 만나는게 행아웃(Hangout)이면, 거참…

Nomad?

개발자라면 한번 쯤 원격 근무를 생각해봤을 것이다. 태국의 어느 한 동네에서 호젓하게 자신만의 코딩 세계에 빠져서 일하다가 무더위에 지칠 무렵이면 바다가에서 수영으로 스트레스를 날려버리는. 그리고 늦은 석양을 바라보며 PR 날리고 함께 즐기는 친구들과 바에서 맥주 한잔? 걍 생각만 해도 멋있네.

Financial Case Study: Kim and Ryan Desmond, CodingNomads

하지만 실상은 이렇지 않을까? 서로 갈린 시차로 오해가 생긴 슬랙으로 인해 팀원들과 오해가 쌓인다. 문자의 한계를 벗어나 화상 회의로 진행할려 했으나 화질은 뚝뚝 끊어지고, 웅웅대서 뭔 소리를 하는지 하나도 알아들을 수 없다. 와중에 원격에서 참가한 사람들이 많다보니 서로 이야기할 순서를 못잡는다. 결국 눈치보다가 해야할 이야기를 못하고 마무리된다. 이미 해는 저물어가는데 느려터진 VPN 때문에 PR을 날릴 수가 없다. 이럴거면 때려치라는 매니저의 얼굴이 아른거린다.

Culture of society

각자가 일하는 방식이 있기 때문에 원격 근무는 호불호가 갈린다. 특히 사회 분위기와 관련이 깊달까? 미국처럼 개인 문화가 발달한 곳에서는 원격 근무가 잘 받아들여진다. 개인이 해야할 일을 잘 해내기만 하면 된다. 다른 사람 일은 신경쓸 필요없이 계획된 일들 가운데 자신이 하기로 한 일만 잘 하면 된다. 이런 분위기에서는 원격 근무가 되려 더 좋은 결과를 낼 수 있을 수도 있다. 같은 공간에서 팀으로 일할 때는 업무 외적으로 시간이 소모되는 경우가 크니까.

이에 반해 한국처럼 조직을 우선시하고, 계층적 조직 문화가 발달한 곳에서는 원격 근무가 힘들다. 보고를 우선시 해야하고, 그 사람과 면대면으로 이야기를 해야 일 파악이 순조롭다. 팀이 빠른 협업으로 일을 해나간다는 측면에서 같은 공간에서 함께 일하는 방식이 더욱 효율적이다. 상대방의 얼굴보면서 하는 커뮤니케이션은 화상보다 몇 배는 더 좋은 결과를 만들어낼 수 있으니까. 더구나 슬랙이나 메신저를 통해 이야기를 하는 것보다, 잠깐 등돌려 이야기하는게 속도와 진정성(특히)에서 백배 낫다. 누군가의 뻘소리를 기록하기 위해서 메신저로 이야기하는게 정신 건강에 좋다고 말하지만, 그럴거면 그 사람이랑 일을 말아야지. 정신 건강까지 생각하면서 일을 해야하는거면 일을 안하는게 되려 정신 건강에 좋다.

그럼에도 출근 못한다

어쩔 수 없는 이번 원격 근무는 어쩔 수 없이 재택 근무를 해야한다.

나도 주말에 노트북들고 커피 가게에서 책읽고, 오랫동안 코드짜고, 블로그 글 쓰는걸 좋아하지만… 갈 수 없다. 못 간다. 집에서 어떻게든 일을 해야한다. 얼추 애들이 컷으니까 일하는데 별 지장없는 내 입장이만, 유치원이나 초등학교 다니는 애들이 있는 집은 애들도 함께 쉬고 있다!! 단언컨데 절대 애들이 간만에 집에 있는 아빠, 엄마를 가만두지 않는다. 이 좋은 기회를 어떻게 날릴까. 애들은 본인들은 방학이고 아빠, 엄마는 집에 함께 있는 휴가 기간인데. ㅋㅋㅋ 워킹맘, 워킹대디면 걍 휴가를 내는게 되려 이래저래 눈치 안볼 방법일 수 있다. 하지만 이마저도 쉽지 않은게 역설 ㅠㅠ;;;; 이건 한국만의 현실이 아니라 글로벌 이슈다. 애 있는 집에서는 원격을 못한다.

뭐 꼭 애들있는 집만의 문제는 아니다. 집이라는 공간은 원래 휴식을 위한 공간이다. 누구든 그 공간 안에서 열심히 일할려고 애쓴다고 하더라도 결국은 휴식의 유혹에 시달려야 한다. 소파가 나를 땡기고 침대가 나를 땡긴다. 거기다가 주말이면 항상 눈을 고정하고 있던 TV가 나를 유혹한다. 와중에 아무도 나를 열일하라고, 결과는 어디에 있느냐고 닥달해대는 사람도 없네!

이런 유혹들을 이기고 일을 해야한다. 직장인으로써 해야할 일은 있으니까. 그래서…

• 집에 계신 분들께 선언을 해둬야 한다. 일하는 시간과 장소를.
• 팀원들과 일하는 시간을 정한다. 소위 말하는 Core Working 시간을 정해야 한다. 시도때도 없이 연락오는 것에 매번 즉각적으로 응답할 수 없다.
• 명확해야 할일과 해야할 일들을 스스로 관리해야 한다. 스스로 Loose해지면 망한다.
• 인상 관리 측면에서 세수랑 머리는 감자.
• 메신저보다는 화상 회의를 잘 사용할 줄 알아야 한다. 같은 언어권에서도 텍스트는 자칫 오해를 부르기 십상이다.
• 애가 회상 회의에 갑자기 뛰어들면!!! 놔두고 아저씨, 아줌마들 얼굴 알아두도록 하자. 나중에 용돈 챙길려면 이번 기회에 용모 파악을 잘 해둬야 한다.

그래서 개발의 원격 근무는?

원격 근무는 서울에서 일하는 직장인에게 좋은 옵션이 될 수 있다. 당연히 여러 좋은 장점들이 있으니까. 출퇴근에 시간 안버려도 되고, 장소만 적절하다면 집중과 몰입을 만들어내서 더 효과적으로 일할 수 있을테니까. 시간을 조절할 수 있으니 소위 말하는 일과 삶의 균형(??)을 맞출 수 있을지도.

단, 팀의 속도와 성과를 저해하지 않는다는 전제가 담보되어야 한다. 같은 공간에 있음으로써 얻는 가장 큰 장점은 빠른 커뮤니케이션이다. 특히 요즘과 같이 소수로 팀이 만들어지는 경우에는 더욱 더 빠른 소통과 의사 결정이 중요하다. (아마도 이게 제일 중요하지 않을까?) 누구 한명이 커뮤니케이션을 함께 하지 못하면 그 사람을 기다려야하거나 혹은 없는 상태에서 진행해야 한다. 긴급하게 논의해야할 내용이 있어서 메시지를 보냈는데 그 사람이 10분내로 응답하지 않는다면? 그렇다고 찾아볼 수 있는 공간에 있는 것도 아닌 원격에 있는데. 커뮤니케이션이 담보되지 않은 상태는 팀의 업무 진행이 담보되지 않았다는 것과 어떻게 보면 같은 맥락이다. 개발자 3명 ~ 4명 정도가 최선의 개발팀이라고 생각할 때, 누구 하나 제대로 이야기에 어울리지 못하면 개인도 팀도 망가질 가능성이 크다.

그래서 혼자 일해도 되는 직종의 경우에는 이 방식이 더 좋은 개인적인 성과를 낼 수 있을지도 모른다. 하지만 개발자는 혼자 일하는 사람이 아니다. 최근에는 더욱 더. 혹자는 스펙만 정해지면 그거 개발하면 되는거지… 라고 이야기하는 사람들이 더러 있다. 가만보면 그런 사람들이 에자일, XP 이야기를 참 열심히 하는 것 같다. “함께 다 같이 잘 해보자!“가 에자일이지, “나만 잘 하면되지!“는 아니다.

원격 근무는 상당히 매력적이다. 그만큼 도전해야할 부분들도 많고. 좋은 방안을 찾을 수 있다면 좋겠다.

– 끝 –

참고 글

Continue reading ‘Consideration in accessing API with the credential on the apache client libraries’ »]]> 본사 친구들이 신규 시스템을 개발하면서 기존에 연동하던 endpoint가 deprecated되고, 새로운 endpoint를 사용해야한다고 이야기해왔다. 변경될 API의 Swagger를 들어가서 죽 살펴보니 endpoint만 변경되고, 기능을 제공하는 URI에 대한 변경은 그닥 크지 않았다. curl을 가지고 테스트를 해봤다.

$ curl -X GET --header "Accept: application/json" --header "AUTHORIZATION: Basic Y29tbX****************XR5X3VzZXI=" \
"http://new.domain.com/abc/v2/username/abcd"
{"subject":"0a58c96afe1fd85ab7b9","username":"abcd","platform_code":"abc"}

잘 되네… 예전 도메인을 신규 도메인으로 변경하면 이상없겠네.

로컬 환경에서 어플리케이션의 설정을 변경하고, 실행한 다음에 어플리케이션의 Swagger 페이지로 들어가서 테스트를 해봤다.

음… 뭐지? 분명히 있는 사용자에 대한 정보를 조회했는데, 없다네? 그럴일이 없으니 console에 찍힌 Stack trace를 확인해보니 401 Unauthorized 오류가 찍혔다.

Caused by: org.springframework.web.client.HttpClientErrorException: 401 Unauthorized
at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:85)
at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:708)
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:661)
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:636)
at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:557)

401 오류가 발생했는데, 그걸 왜 사용자가 없다는 오류로 찍었는지도 잘못한 일이다. 하지만 원래 멀쩡하게 돌아가던 코드였고, curl로 동작을 미리 확인했을 때도 정상적인 결론을 줬던 건데 신박하게 401 오류라니??? 인증을 위해 Basic authorization 방식의 credential을 사용했는데, 그 정보가 그 사이에 변경됐는지도 본사 친구한테 물어봤지만 바뀐거가 없단다. 다른 짐작가는 이유가 따로 보이지 않으니 별수없이 Log Level을 Debug 수준으로 낮춘 다음에 HTTP 통신상에 어떤 메시지를 주고 받는지를 살펴봤다.

하지만 새로운 endpoint로 request를 쐈을 때에는 아래와 같은 response를 보낸 다음에 추가적인 request를 보내지 않고, 걍 실패해버린다.

2018-04-18 02:41:48.517 DEBUG 93188 : http-outgoing-0 HTTP/1.1 401 Unauthorized
2018-04-18 02:41:48.517 DEBUG 93188 : http-outgoing-0 Content-Encoding: gzip
2018-04-18 02:41:48.517 DEBUG 93188 : http-outgoing-0 Content-Type: application/json
2018-04-18 02:41:48.517 DEBUG 93188 : http-outgoing-0 Date: Tue, 17 Apr 2018 17:41:48 GMT
2018-04-18 02:41:48.517 DEBUG 93188 : http-outgoing-0 Vary: Accept-Encoding
2018-04-18 02:41:48.517 DEBUG 93188 : http-outgoing-0 transfer-encoding: chunked
2018-04-18 02:41:48.517 DEBUG 93188 : http-outgoing-0 Connection: keep-alive
2018-04-18 02:41:48.517 DEBUG 93188 : Connection can be kept alive indefinitely
2018-04-18 02:41:48.517 DEBUG 93188 : Authentication required
2018-04-18 02:41:48.517 DEBUG 93188 : new.domain.com:80 requested authentication
2018-04-18 02:41:48.517 DEBUG 93188 : Response contains no authentication challenges

이상한데???

Authentication required 라고 나오는데 코드상으로는 HTTP Connection factory를 생성할 때 Basic authorization을 아래와 같이 설정을 적용해뒀는데 말이다.

@Bean
public HttpClient httpClient() throws MalformedURLException {
PoolingHttpClientConnectionManager cm = Protocols.valueOf(new URL(domain).getProtocol().toUpperCase()).factory().createManager();
cm.setMaxTotal(connectionPoolSize);
cm.setDefaultMaxPerRoute(connectionPoolSize);

BasicCredentialsProvider credentialsProvider = new BasicCredentialsProvider();
credentialsProvider.setCredentials(AuthScope.ANY,
new UsernamePasswordCredentials(username, password));

return HttpClients.custom()
.setConnectionManager(cm)
.setDefaultCredentialsProvider(credentialsProvider)
.build();
}

하지만 의심이 든다. 정말 요청할 때마다 Authorization header를 셋팅해서 내보내는건지. 이전 시스템과 어떤 방식으로 통신이 이뤄졌는지 궁금해서 endpoint를 이전 시스템으로 돌려서 확인을 해봤다. 정상적으로 데이터를 주고 받을 때는 아래와 같은 response를 endpoint에서 보내줬다.

2018-04-18 02:38:09.676 DEBUG 93178 : http-outgoing-0 "HTTP/1.1 401 Unauthorized[\r][\n]"
2018-04-18 02:38:09.676 DEBUG 93178 : http-outgoing-0 "Server: Apache-Coyote/1.1[\r][\n]"
2018-04-18 02:38:09.676 DEBUG 93178 : http-outgoing-0 "WWW-Authenticate: Basic realm="Spring Security Application"[\r][\n]"
2018-04-18 02:38:09.676 DEBUG 93178 : http-outgoing-0 "Set-Cookie: JSESSIONID=78AEB7B20A1F8E1EA868A68D809E73CD; Path=/gas/; HttpOnly[\r][\n]"
2018-04-18 02:38:09.676 DEBUG 93178 : http-outgoing-0 "Content-Type: application/json;charset=utf-8[\r][\n]"
2018-04-18 02:38:09.676 DEBUG 93178 : http-outgoing-0 "Transfer-Encoding: chunked[\r][\n]"
2018-04-18 02:38:09.676 DEBUG 93178 : http-outgoing-0 "Date: Tue, 17 Apr 2018 17:38:09 GMT[\r][\n]"

이 로그가 출력된 다음에 다시 인증 헤더를 포함한 HTTP 요청이 한번 더 나간다! 이전과 이후의 로그에서 인증과 관련되어 바뀐 부분이 뭔지 두눈 부릅뜨고 살펴보니 새로 바뀐놈은 WWW-Authenticate 헤더를 주지 않는다. 이 Response Header가 어떤 역할을 하는지 살펴보니 아래와 같은 말이 나온다.

(…)The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource.(…)

근데 이게 문제가 왜 될까?? 생각해보니 Apache에 Basic 인증을 설정하면 요런 메시지 박스가 나와서 아이디와 암호를 입력하라는 경우가 생각났다.

아하… 이 경우랑 같은거구나! 실제 인증 과정에서 이뤄지는 Protocol은 아래 그림과 같이 동작한다.

이 그림에서 볼 수 있는 것처럼 하나의 API 요청을 완성하기 위해서 2번의 HTTP Request가 필요했던 것이다. 이런걸 생각도 못하고 걍 Basic Credential을 Example에서 썼던 것처럼 쓰면 문제가 해결된다고 아무 생각없이 너무 간단히 생각했던 것 같다. 연동해야할 Endpoint가 여러 군데인 경우에는 이런 설정이 제각각이기 때문에 많이 사용하는 RestTemplate 수준에서 Header 객체를 만들어 인증 값을 설정했을 것 같다. 물론 RestTemplate을 생성하는 Bean을 두고, Authorization 값을 설정하면 되긴 했겠지만 상황상 그걸 쓸 수 없었다. 변명을 하자면 그렇다는 것이다.

제대로 짜면 이렇다.

@Bean
public HttpClient httpClient() throws MalformedURLException {
....
Credentials credential = new UsernamePasswordCredentials(username, password);
HttpRequestInterceptor interceptor = (httpRequest, httpContext) ->
httpRequest.addHeader(new BasicScheme().authenticate(credential, httpRequest, httpContext));

return HttpClients.custom()
.setConnectionManager(cm)
.addInterceptorFirst(interceptor)
.build();
}

앞선 예제처럼 Credential Provider를 두는게 아니라 interceptor를 하나 추가하고, 여기에서 crednetial 값을 걍 설정해주는 것이다. 이러면 이전처럼 2번이 아니라 한번에 인증이 처리된다.

몸이 먼저 움직이기보다는 생각이 먼저 움직여야 하는데 점점 더 마음만 급해지는 것 같다.

참고자료

• https://stackoverflow.com/questions/17121213/java-io-ioexception-no-authentication-challenges-found?answertab=active#tab-top
• https://stackoverflow.com/questions/2014700/preemptive-basic-authentication-with-apache-httpclient-4

– 끝 –