새로운 시도라는 건 항상 두려움이다. 있던 틀 안에서의 나는 안전하다. 그 안전함을 벗어나 미지로 향하고 싸워야한다는 건 괴롭기도 하고 어떤 때는 정말 하기 싫다.
와중에 모든 일이 생각만큼 순조롭지도 않고, 별 생각하지도 않았던 곳에서 장애물이 튀어나마 마음도 괴롭고 몸도 괴롭게 한다. 요즘이 아마도 딱 이런 형국이다. 업무적으로도 개인적으로도.
아마도 살아오면서 성공보다는 좌절이 많았고, 그냥 주저앉아서 한걸음도 움직이기 싫은 적도 있었다. 마음대로 되지 않고, 하고 싶어도 할 수 없었다. 그럼에도 어떻게든 일어나 지친 걸음을 내딛었고, 정말 걷기 싫은 걸음을 내딛어 걸었다. 그래서 지금 여기에 있다.
Hi~ There.
어렵지만 그래도 가야겠지. 결론은? 글쎄 해피 엔딩일지 새드 엔딩일지 모른다. 그럼에도 다른 사람이 결론을 내주는 것보다는 성격상 내가 결론을 내는게 좋다. 부디 해피 엔딩이어야 하는데 말이다.
지난 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는 아니다.Jira 보드 놓고 한일/할일 혹은 넋두리를 한다. 어찌보면 딱 아침 조회다!! ㅎㅎ
11시가 되면 5~7명쯤 개발팟 인원들이 행아웃에서 모인다. 가장 연장자 분이 BGM을 깔아놓으면 사람들이 모일동안 감상의 시간을 갖는다. 얼추 참석자들이 모이면 진행자가 순서대로 Jira 보드에서 담당자를 선택하면 업무 이야기를 공유한다. 오늘 할일이나 어제 겪었던/논의했던 이슈나 Blocker들에 대해 이야기한다. 진도를 많이 빼신 분은 Backlog에서 할만한 일이나 Sustaining꺼리를 물어본다. 동료가 봐줬으면 하는 걸 이야기하면 그걸 도와주거나 아님 팟 리드가 처리되어야 할 꺼리를 백로그에서 뽑는다. 두루두루 이야기하고, 마지막으로 팟 리드가 어떤 일들이 있으면 챙겼으면 좋겠다는 것으로 마무리한다.
형식을 보면 에자일식은 아니고 칸반 스타일인가? 오피스에서 모여서 이야기할 때는 15분안에 끝내는게 목표였고, 대부분 그 시간안에 마쳤던 것 같다. 하지만 온라인으로 진행하면서 전체 시간이 좀 오래 걸린다. 이건 꼭 데일리 뿐만 아니라 거의 모든 회의들이 오피스 미팅룸에서 모여서 하던 것보다는 전체적으로 길어졌다. 한번에 여러 사람이 한꺼번에 이야기할 수 없다는 제한이 있기 때문이기도 하고 같이 얼굴 맞대고 이야기할 기회가 없다보니 다들 한 두마디씩 더 하는 것 같다. ^^;
정리하고 데일리에서 나온 것들 가운데 바로 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시 사이를 근무 시간으로 정한 이유는 그 시간이 보편적으로 연락 가능하고 협업이 가능한 시간임을 모두가 암묵적으로 동의하기 때문이다. 메신저 뒤에 숨어서 페이크치다 걸리면 쪽팔린다. 재택이라고 하더라도 근무 시간이 변경된 건 없다. 가능하면 지켜야 하고 못지키면 이야기해서 협업에 방해되지 않도록 알려야 한다.
부재는 알려라. 오피스 공간에서 근무를 선호하는 이유는 고개 돌리면 동료가 옆에 있고, 이야기할 수 있기 때문이다. 온라인으로 일을 하는 경우에도 마찬가지 환경이 되야 한다. 오피스에도 자리 비운다면 자리 비운다고 동료에게 이야기한다. 마찬가지로 행동하면 된다. 재택이라고 다르지 않다.
팀을 생각해야 한다. 재택은 공간적으로 팀을 배제한다. 혼자있는데 뭔, 팀… 때문에 더욱 더 개인화된다. 같은 공간에 팀이 모여있는 공기와 자신만의 공간에서 느끼는 공기는 당연히 틀리다. 팀이 팀으로 느껴지는 이유는 공간적인 이유가 크다. 하지만 재택은 이를 분리한다. 이런 거리감을 인위적으로 줄일 수 없다. 강제로 줄여봐야 파열음만 난다. 스스로 팀원이어야 한다. 자발적으로 팀의 상황을 이해하고 팀의 발전을 위해 기여해야 한다. 정해진 일만 하겠다면 재택과 맞지 않는다. 아니 되려 팀 플레이 자체가 맞지 않는거 아닐까도 싶다.
••••••
재택은 팀 플레이를 시험한다고 보여진다. 공간으로 분리된 상황에서 개인이 팀이라는 인위적인 공동체를 유지할 수 있을 것인가? 이 과정에 스스로 있기도 하고, 결과가 어떻게 나올지 기대된다. 본사에서도 실패했고, 때문에 공간을 중심으로 팀을 유지하는 것이 현재 정책이었다. 이제까지 나도 이에 동감했고, 크게 바뀌지 않았다.
하지만 기대 이외의 결과를 보고 싶다. 당장 재난 형국을 넘어서기 위해서도, 그리고 먼 미래를 위해서도 ^^;
2020년은 파란만장하게 시작했다. 그리고 3월의 어느 시점을 관통하는 지금 개인을 넘어 전세계적으로 “코로나19 바이러스“로 혼란의 도가니 안에 있다.
바이러스의 습격은 한국 기업에게 원격 근무를 선택지로 강요하고 있다. 한 공간에 사람이 모이는 것 자체가 감염의 근거를 제공하기 때문에 업무를 이어가기 위한 어쩔 수 없는 선택이 되버렸다. 몇 일 전직원 휴가를 쓸 수 있겠지만, 그 기간은 몇 일을 못 넘긴다. 감당이 된다면 직원들이 사장님 “쵝오!!!” 를 외칠텐데 말이다.
나도 현재 원격 근무를 시전중이다. 불가항력적인 몇몇 부서를 제외하고는 오피스에 속한 모든 사람들이 원격 근무를 하고 있다. 다른 팀들과 비교했을 때 개발팀은 해외 팀들과 그동안 협업을 해왔고, 그 팀들은 어떤 식으로 원격 근무를 하는지를 봤었으니까… 협업할려고 본사갔더니 이 친구가 원격 근무하는 친구라서 삼실에 안나온다는… 뱅기타고 힘들게 날라왔는데, 정작 만나는게 행아웃(Hangout)이면, 거참…
개발자라면 한번 쯤 원격 근무를 생각해봤을 것이다. 태국의 어느 한 동네에서 호젓하게 자신만의 코딩 세계에 빠져서 일하다가 무더위에 지칠 무렵이면 바다가에서 수영으로 스트레스를 날려버리는. 그리고 늦은 석양을 바라보며 PR 날리고 함께 즐기는 친구들과 바에서 맥주 한잔? 걍 생각만 해도 멋있네.
Financial Case Study: Kim and Ryan Desmond, CodingNomads
하지만 실상은 이렇지 않을까? 서로 갈린 시차로 오해가 생긴 슬랙으로 인해 팀원들과 오해가 쌓인다. 문자의 한계를 벗어나 화상 회의로 진행할려 했으나 화질은 뚝뚝 끊어지고, 웅웅대서 뭔 소리를 하는지 하나도 알아들을 수 없다. 와중에 원격에서 참가한 사람들이 많다보니 서로 이야기할 순서를 못잡는다. 결국 눈치보다가 해야할 이야기를 못하고 마무리된다. 이미 해는 저물어가는데 느려터진 VPN 때문에 PR을 날릴 수가 없다. 이럴거면 때려치라는 매니저의 얼굴이 아른거린다.
각자가 일하는 방식이 있기 때문에 원격 근무는 호불호가 갈린다. 특히 사회 분위기와 관련이 깊달까? 미국처럼 개인 문화가 발달한 곳에서는 원격 근무가 잘 받아들여진다. 개인이 해야할 일을 잘 해내기만 하면 된다. 다른 사람 일은 신경쓸 필요없이 계획된 일들 가운데 자신이 하기로 한 일만 잘 하면 된다. 이런 분위기에서는 원격 근무가 되려 더 좋은 결과를 낼 수 있을 수도 있다. 같은 공간에서 팀으로 일할 때는 업무 외적으로 시간이 소모되는 경우가 크니까.
이에 반해 한국처럼 조직을 우선시하고, 계층적 조직 문화가 발달한 곳에서는 원격 근무가 힘들다. 보고를 우선시 해야하고, 그 사람과 면대면으로 이야기를 해야 일 파악이 순조롭다. 팀이 빠른 협업으로 일을 해나간다는 측면에서 같은 공간에서 함께 일하는 방식이 더욱 효율적이다. 상대방의 얼굴보면서 하는 커뮤니케이션은 화상보다 몇 배는 더 좋은 결과를 만들어낼 수 있으니까. 더구나 슬랙이나 메신저를 통해 이야기를 하는 것보다, 잠깐 등돌려 이야기하는게 속도와 진정성(특히)에서 백배 낫다. 누군가의 뻘소리를 기록하기 위해서 메신저로 이야기하는게 정신 건강에 좋다고 말하지만, 그럴거면 그 사람이랑 일을 말아야지. 정신 건강까지 생각하면서 일을 해야하는거면 일을 안하는게 되려 정신 건강에 좋다.
어쩔 수 없는 이번 원격 근무는 어쩔 수 없이 재택 근무를 해야한다.
나도 주말에 노트북들고 커피 가게에서 책읽고, 오랫동안 코드짜고, 블로그 글 쓰는걸 좋아하지만… 갈 수 없다. 못 간다. 집에서 어떻게든 일을 해야한다. 얼추 애들이 컷으니까 일하는데 별 지장없는 내 입장이만, 유치원이나 초등학교 다니는 애들이 있는 집은 애들도 함께 쉬고 있다!! 단언컨데 절대 애들이 간만에 집에 있는 아빠, 엄마를 가만두지 않는다. 이 좋은 기회를 어떻게 날릴까. 애들은 본인들은 방학이고 아빠, 엄마는 집에 함께 있는 휴가 기간인데. ㅋㅋㅋ 워킹맘, 워킹대디면 걍 휴가를 내는게 되려 이래저래 눈치 안볼 방법일 수 있다. 하지만 이마저도 쉽지 않은게 역설 ㅠㅠ;;;; 이건 한국만의 현실이 아니라 글로벌 이슈다. 애 있는 집에서는 원격을 못한다.
뭐 꼭 애들있는 집만의 문제는 아니다. 집이라는 공간은 원래 휴식을 위한 공간이다. 누구든 그 공간 안에서 열심히 일할려고 애쓴다고 하더라도 결국은 휴식의 유혹에 시달려야 한다. 소파가 나를 땡기고 침대가 나를 땡긴다. 거기다가 주말이면 항상 눈을 고정하고 있던 TV가 나를 유혹한다. 와중에 아무도 나를 열일하라고, 결과는 어디에 있느냐고 닥달해대는 사람도 없네!
이런 유혹들을 이기고 일을 해야한다. 직장인으로써 해야할 일은 있으니까. 그래서…
원격 근무는 서울에서 일하는 직장인에게 좋은 옵션이 될 수 있다. 당연히 여러 좋은 장점들이 있으니까. 출퇴근에 시간 안버려도 되고, 장소만 적절하다면 집중과 몰입을 만들어내서 더 효과적으로 일할 수 있을테니까. 시간을 조절할 수 있으니 소위 말하는 일과 삶의 균형(??)을 맞출 수 있을지도.
단, 팀의 속도와 성과를 저해하지 않는다는 전제가 담보되어야 한다. 같은 공간에 있음으로써 얻는 가장 큰 장점은 빠른 커뮤니케이션이다. 특히 요즘과 같이 소수로 팀이 만들어지는 경우에는 더욱 더 빠른 소통과 의사 결정이 중요하다. (아마도 이게 제일 중요하지 않을까?) 누구 한명이 커뮤니케이션을 함께 하지 못하면 그 사람을 기다려야하거나 혹은 없는 상태에서 진행해야 한다. 긴급하게 논의해야할 내용이 있어서 메시지를 보냈는데 그 사람이 10분내로 응답하지 않는다면? 그렇다고 찾아볼 수 있는 공간에 있는 것도 아닌 원격에 있는데. 커뮤니케이션이 담보되지 않은 상태는 팀의 업무 진행이 담보되지 않았다는 것과 어떻게 보면 같은 맥락이다. 개발자 3명 ~ 4명 정도가 최선의 개발팀이라고 생각할 때, 누구 하나 제대로 이야기에 어울리지 못하면 개인도 팀도 망가질 가능성이 크다.
Face-To-Face Communication: 6 Reasons to Lead in Person
그래서 혼자 일해도 되는 직종의 경우에는 이 방식이 더 좋은 개인적인 성과를 낼 수 있을지도 모른다. 하지만 개발자는 혼자 일하는 사람이 아니다. 최근에는 더욱 더. 혹자는 스펙만 정해지면 그거 개발하면 되는거지… 라고 이야기하는 사람들이 더러 있다. 가만보면 그런 사람들이 에자일, XP 이야기를 참 열심히 하는 것 같다. “함께 다 같이 잘 해보자!“가 에자일이지, “나만 잘 하면되지!“는 아니다.
원격 근무는 상당히 매력적이다. 그만큼 도전해야할 부분들도 많고. 좋은 방안을 찾을 수 있다면 좋겠다.
– 끝 –
참고 글
한국에서 인터넷 서비스는 IE 지원이 없으면 말도 안되는 이야기다. 적어도 작년까지는 확실히 그랬던 것 같다. 그랬을거야…
새로운 Frontend Application을 개발할 일이 있어서, CRA 프로젝를 생성했다. 별 생각없이 열심히 개발했다.
$ npx create-react-app new-app npx: 99개의 패키지를 19.738초만에 설치했습니다. Creating a new React app in /Users/tchi/Workspace/works/new-app. Installing packages. This might take a couple of minutes. Installing react, react-dom, and react-scripts with cra-template... ... We suggest that you begin by typing: cd new-app yarn start Happy hacking!
얼추 개발을 마무리해서 QA분들께 검증을 부탁했더니 IE에서 아예 동작을 안한다는… 응 뭐지?
"browserslist": {
"production": [
"> 0.2%",
"not dead",
"not op_mini all"
],
"development": [
"last 1 chrome version",
"last 1 firefox version",
"last 1 safari version"
]
}
개발 모드에서는 당연히 IE가지고 개발하는 frontend 개발자는 없으니까 그럴 수 있다고 치자. 그래도 IE11 정도면 당연히 지원되어야 하는거 아닌가? 그래도 0.2% 정도는 넘을거고, 죽은 Browser라고 보기에는 Rendering이나 보안 측면에서 나쁘지는 않았으니까. 그런데 왜 기본 동작이 안되는거지. 분명 작년에는 Ajax 관련된 부분을 빼고는 Rendering 정도는 문제가 없었는데 말이다.
ReactJS 사이트를 뒤져보니 CRA 앱에서 지원하는 브라우져 기준이 나온다.
Supported Browsers
By default, the generated project supports all modern browsers. Support for Internet Explorer 9, 10, and 11 requires polyfills. For a set of polyfills to support older browsers, use react-app-polyfill.
음… IE11이 Modern Browser가 아니구나… IE11가 이정도 취급을 받는데, 얼마나 지분이 있는거지 궁금해서 함 찾아봤다. 2019년 11월 기준이긴 하지만 Global 지표로 IE는 아예 지표에서 보이지도 않는다. 흐미…
따로 IE부분만 filtering해서 살펴봤더니 IE 총합이 3.66%이다. 아마도 IE11, 10, 9, 8이 사용되는 IE의 총합일텐데, 3.66% 수준은 정말 충격적이다. 더욱 놀라온 건 한국에서만 Edge를 안쓰는 줄 알았는데 전세계적으로도 버림받은 브라우저라는 것이다. 나름 MS에서 야심차게 개발한 놈인데, 가열차게 시장에서는 외면받았다. 이정도 되니까 MS에서도 Chromium으로 갈아타서 Edge를 다시 만들었겠지.
이정도 쯤 되니까 한국은 상황이 어떻지 하는게 궁금해서 함 찾아봤다. 항상 IE, IE라는 이야기를 많이 들어서 점유율이 30% 이상은 되겠지라는 기대를 했다. 그런데 의외로 한국의 브라우저 통계 데이터에서 IE가 차지하는 비중이 20% 미만이다. 막판에 약간 올라가긴 했지만 전체 비중이 15% ~ 20% 수준에 머문다. 조만간 한국에서도 굳이 Frontend App을 개발할 때 IE를 고려하지 않을 날이 올거라는 희망이 있다는 이야기. 물론 철옹성처럼 바뀌지 않는 금융권이나 공공기관 웹들이 버틸거기 때문에 IE가 아예 사라지지는 않을 것이라고 확신한다. 그럼에도 내가 만드는 앱이 동작되고 지원해야할 브라우저 목록에서 조만간(한 5년?) 사이에 IE가 빠지긴 할 것 같다.
본래 정리할려는 내용으로 다시 돌아가서…
IE를 지원하지 않는 최근 CRA가 IE를 지원하도록 만들려면 react-app-polyfill을 사용하면 된다. npm install react-app-polyfill –save 명령이면 간단하게 최신 polyfill 지원 사항을 CRA 프로젝트에 추가할 수 있다. 물론 이것만으로는 동작하지 않고, 최상위 JS 파일인 index.js 파일에 지원해야할 브라우저 버전에 대한 사항을 import 해줘야 한다.
// These must be the first lines in src/index.js import 'react-app-polyfill/ie11'; import 'react-app-polyfill/stable';
코멘트에 나온 것처럼 index.js 파일의 가장 앞선 라인에 이 2가지 import 항목들을 추가해주면 크롬에서 돌던 기능들이 자연스럽게 IE11에서도 동작한다. Promise, fetch 등 작년까지만해도 하나씩 잡아줘야 했던 것들이 이 간단한 설정으로 동작한다. CRA를 사용하면 대부분 것들을 Behind the scene에서 처리해주기 때문에 개인적으로 좋아한다. Polyfill에 대한 사항도 마찬가지 컨셉으로 지원해주니 일관성을 제대로 유지하는 것 같다. 물론 Babel 수준에서 마이크로 세팅해서 최적화하는 걸 즐기시는 분들도 있다. 내가 이정도 역량이 있는 Frontend 개발자는 아니기 때문에 UI를 구조화된 코드로 만들 수 있다는 것만으로 만족한다.
Frontend에 개발할 때 모듈화된 CSS를 사용할려면 scss를 추천한다. devDependencies에 node-sass를 추가하고 기본 생성된 *.css 파일의 이름을 *.scss로 변경하고 각 css 파일의 import를 scss 파일로 교체해주면 된다. 진행중인 프로젝트에 적용할려면 짜증나기 때문에 프로젝트 생성 초기에 설정을 변경해주는게 인생 편하다.
– 끝 –
반응형 웹을 만들어보는게 해보고 싶은 일들 가운데 하나다. 모바일 시대가 이미 20년이 넘었는데, 내가 하던 웹은 PC 환경에 머물러 있었다. 굳이 모바일을 지원할 필요가 없기도 했던게 변명의 이유로 가장 컸다고 자조하고 싶다. 혹은 굳이 내가 그런걸 해야할까? 하는 섣부른 허세가 가득했다.
지금도 작업하는 대부분의 작업이 PC 환경에 국한되어 있다. 일단 UI가 6년전에서 일도 전진하지 못했다. 그러니 새롭게 FE APP을 만들더라도 UI 자체는 그 밥에 그 나물이다.
이번에 새로운 기능 하나 하면서 드디어 구태 의연한 한국식 UI 스타일을 벗어버릴 수 있었다. 이것이 가능한 이유는 굳이 이것 저것 덕지덕지 붙이는 기능들이 없다. 기존 화면들은 화면에 뭘 그렇게 많이 요구하는지 나래비세울 항목들이 많다보니 PC형 화면이 아니면 배치 자체가 힘든 경우가 허다했다. 화면에 노출되는 정보다 간단한 목록이 전부다. PC와 모바일을 동시에 지원해보기 적당한 항목들이고 기능의 크기다.
반응형이라고 해서 거창하게 들리지만 한 기능을 PC와 모바일 2개 채널에 제공해보는 것이다. 예전이라면 한 기능을 2가지 채널에 제공하더라도 각각의 Frontend App을 따로 만들었다. 도메인만 보더라도 PC에서 사용하는 도메인은 www.features.co.kr 과 같은 도메인을 사용했다면 모바일은 m.features.co.kr 형태를 사용했으니까. 도메인이 틀리니 당연히 코드도 틀린 방식으로 가는 걸 자연스러워 했던 것 같다.
예전에는 이런 접근 방법이 상당히 맞는 소리같아 보였는데, 최근에는 이게 뭔 짓인가 싶기도 하다. 같은 기능인데 굳이 m자 붙힌 모바일 도메인을 따로 만들었을까? 도메인과 인증서에 비용도 들어가고, 되려 어플리케이션에서 이걸 감안해서 코드를 짜는게 더 귀찮데… 어쩌면 “남들도 저렇게 하는데 우리도 같이 가는게 맞지!”라고 관성이고 타성이다. 최근에는 이런 것들에 대해 한번씩은 질문할 수 있는 마음이 생긴게 다행이라고 보인다.
반응형이라고 거창하게 이야기를 했지만, 따지고 보면 화면 크기에 대해 어떤 방식으로 보여지는지를 제어하는게 고작이다. 이 부분을 제어하기 위해 지원하는 CSS상의 기능이 미디어쿼리(MediaQuery)라는 것이다. 한참 전부터 존재했던 거지만, 언제나 그렇듯 안 해본게 문제다. 이걸 사용하지 않고 할려면 Javascript로 화면 크기 혹은 UA를 확인해서 화면을 제어해야 한다. 이런 방식은 정말 엄청난 수고를 필요로 하고 관리도 문제다.
...default style for all(pc)...
@media screen and (max-width: 768px) {
body {
background-color: lightgreen;
}
}
위의 코드를 보면 기본으로 PC 환경의 CSS 스타일을 기본으로 사용하고 모바일의 경우에 대한 스타일을 추가로 정의한다. 이렇게 되면 기존 정의된 스타일을 오버라이딩(Overriding)한다. Landscape 상태에서는 화면 폭이 넓기 때문에 굳이 특별한 UI 상태를 정의할 필요가 없다. 우리의 주 관심은 Portrait 상태다.
화면이 짧은 경우, 표시해야 할 정보를 없애거나 표현 형태를 변경해야 한다. 이 방식을 적용할 때 전체적인 레이아웃의 유연성이 담보되야 한다. 음… 테이블(table) 같은 UI 요소를 사용하지 말라는 거다. div, p, span 같은 요소들을 사용하면서 display 속성으로 있는 flex, inline-block들을 활용해서 정보를 배열한다. 그럼 정보를 좀 더 깔끔하게 없애거나 다른 형식으로 표시하는데 유리하다.
물론 숨기는 방식은 별로 선호할만한 방법은 아니다. PC에서 나오는 항목을 굳이 모바일이라고 숨길 필요는 없으니까. 또한 클라이언트로 전달되는 정보 혹은 데이터의 물리적인 양도 바뀌지 않는다. 단순히 안보이는 것 뿐이니까.
내가 회사에서 가장 많이 출장가는 사람 가운데 한 명이다. 체류 일정으로는 넘사벽 1등이었는데, 최근에는 본사쪽과 좀 더 긴밀하게 일하는 분들이 생겨서 그나마 이 기록도 내줘야 할 듯 싶다. 내가 아닌 다른 분들이 본사 혹은 다른 지역의 개발팀들과 호기롭게 커뮤니케이션하고 함께 일하는 모습 보면 기분이 좋다. 우리가 가기만 했었는데, 최근에는 본사/타지역 친구들이 한국 오피스에 와서 함께 한국의 문제점을 해결하기 위해 일한다. 이야기해보면 본사 개발팀 친구들도 우리랑 비슷한 업무 부담과 기대를 가지고 한국 오피스에 왔다는 걸 알 수 있다. 보면 그 친구들도 와서 일은 참 열심이 한다.
다들 한국이 아닌 외국에 출장 간다는 것에 대한 환상이 있을 것 같다. 나도 처음 출장에는 그런 환상이 있었으니까. 하지만 프로 출장러가 되다보니 실제 함께 출장온 분들이 실망하는 경우가 많다. 물론 첫 3번의 출장에서 완벽한 스케줄을 작성해주신 분들이 계셔서 LA에서 봐야할 곳들은 웬만큼 봤다. (거봐~~~~) 물론 그 다음에 라라랜드가 떠버리는 바람에 더 봐야할 곳들이 생기긴 했지만,.. 굳이… 혹여 어느 분들이 나랑 출장 일정을 함께 할지 모르겠지만, 실망감 최소화를 위해 가장 최근 버전의 일상 동선을 공유해보고자 한다.
~~~~
보통 일을 시작하기 하루 전에 도착한다. 그래서 한국에서 일요일에 출발하고 LA에는 일요일에 도착한다. 와중에 떠난 시간보다 더 빠른 시간에.
많이 피곤할 것 같은 일정이라면 휴식을 위해서 하루 정도 더 여유를 두기도 하지만 굳이 그러고 싶지는 않다. 10시간의 비행의 피곤함도 있지만, 17시간의 시차는 쉽게 하루를 온전히 쉬는 것도 힘들게 한다. 면세 팩소주를 사오는게 일상이 되었기 때문에 도착 당일은 팩소주로 장시간 비행의 피로를 잊어보려한다. 아쉽지만 절반의 성공과 실패로 나뉜다.
아침에 일어나는 시간은 언제나 다름없이 새벽이다. 대부분 “약속의 새벽 3시”에 한번 깬다. 더 잘 수 있다면 눈에 선 핏줄이 훨씬 덜하다. 한번 깨면 다시 자기 힘든 스타일이라 처음 잘 때 잘 자길 기도한다. 하지만 기도발이 약한지 성공 확률은 20%가 되지 않는다.
일반 수면 유도제를 몇 번 시도해봤지만 정신만 몽롱하지 새벽 그 약속을 못어긴다. 왜 깨는겨!!! 결국 처방받은 수면제가 정답이다. 한 알이면 4시간, 두알이면 확실히 8시간 이상 잔다. 단 술먹고 먹으면 영영 못깨어날 수 있으니 조심하자.
최근에는 아침 6시 즈음에 호텔에 있는 운동 시설에서 걷기나 자전거 타기를 한다. 한국에서 하지도 않는 운동을 출장와서 한다는 것도 우숩다. 하지만 하면 조금이라도 일상 생활에 도움이 된다. 이번 출장에는 일정의 절반 동안 아침 운동을 했는데, 한날과 안한 날의 차이가 있다. 조금이라도 즐겁게 일하고 싶다면 권한다. 하지만 과도한 운동은 코피를 동반할 수 있으니 조심하자.
운동하고 씻고 출근 준비를 마치면 얼추 8시 혹은 8시 반이다. 여러 사람들과 함께 온 출장이라면 불러서 같이 이동하거나 출발 시간이 안맞으면 걍 “우버(Uber)” 불러서 출근한다. 주로 묶는 호텔과 캠퍼스(본사 사무실)까지 안밀리면 10분, 15분이다. 지하철타고 출근하는데 못해도 한시간 이상인데, 도어 투 도어(Door-to-Door)로 이 시간밖에 안걸린다는 엄청 매력적이다.
캠퍼스에 도착하면 항상 빌지 카페에 가장 먼저 들른다. 하루 시작은 역시 핫 아메리카노다. 유기농 빵도 9시 전에는 남아있는데, 특히 애플 파이랑 크로와상은 일품이다. 커피랑 빵은 다른 식당에 맛이 뒤지지 않는다.
출장와서 매번 같은 아메리카노만 시켜먹다보니 특이했나보다. 카페 직원이 얼굴만 보고 “아메리카노?” 라고 간단히 묻고 내 이름을 컵에 적는다. 처음에는 신기하기도 했지만, 이쯤되니 카페 고참 직원들은 내 이름을 기억하고 있다. 웃어야 할지 울어야 할지 모르겠다. 그럼에도 웃으면서 내 이름을 불러주니 즐거운 경험이다.
커피도 받았고, 간단히 배도 채웠으니 이제 일할 시간이다.
오전에는 보통 1개 회의를 잡거나 잡지 않는다. 보통 첫주에 진행하는 미팅의 2/3 정도는 출장 오기 전에 모두 잡는다. 내 출장은 대부분 한국 업무를 구현하기 위해서다. 일을 하기 위해서 필요한 사람들이 누구인지 사전에 파악하고, 일정을 확인 한 다음에 출발 비행기 타기전에 미팅을 잡는다. 사실 상대편에게 미팅을 잡아달라 부탁하면 제대로 된 적이 거의 없다. 사실, 그 친구들은 관심이 없다. 그 친구들은 내가 도움을 받아야 할 사람들일 뿐이다. 목마른 사람이 우물 파는게 당연하다. 컨텍스트를 알리는 이메일이나 슬랙 메시지를 사전에 보내놓고, 캘린더 빈 시간에 꽂아넣는다.
미팅에서 이야기를 하다보면 후속 미팅이 잡히고, 이러면 2주일 정도 본사 친구들과 해야할 일들에 대한 충분한 의견 교환이 이뤄진다. 그렇다고 항상 원하는 결과가 만들어지지 못하지만, 적어도 내가 이런 생각을 가지고 있고, 그 친구들은 내 생각에 대해 어떻게 생각하는지, 이걸 바탕으로 전략을 수정할지 혹은 개발 방향을 어떤 방식으로 구체화할 것인지를 한국 팀 내부에서 논의할 수 있다.
미팅은 한국식 미팅과는 거리가 멀다. 대부분 기본 미팅 시간은 30분이다. 물론 격론이 오가거나 화제꺼리가 많으면 시간을 초과하는 경우도 생긴다. 이런 일이 예상되는 경우 드물게 1시간 미팅을 잡기도 한다. 종종 10분, 15분만에 “아, 그거였구나!” 하면서 싱겁게 마무리 되는 경우가 많다. 시간을 초과하는 경우도 있다. 이러면 “정리가 된건야 만거야??” 싶게 아리송하게 마무리된 미팅이 되어 버릴 수 있다. 출장와서 잡은 미팅을 의미없이 날려버리지 않을려면 핵심되는 이야기 중심으로 이야기하고, 시간 관리를 타이트하게 해야한다.
어느 정도의 이슈가 의견이 교환했기 때문에 다음 내용 정리는 슬랙이나 이메일로 이뤄진다. 손쉽게 이슈가 정리된다면 실행 아이템을 Jira ticket으로 만들거나 Favro Card로 만들어두고 멘션(Mention) 해준다. 이러면 그 일이 어떻게 굴러가는지 나도 트래킹을 할 수 있다.
물론 대부분 미팅에서 회의록을 작성한다. 본사 친구들이 작성하는 경우에는 대부분 회의하면서 문서를 작성한다. 물론 한국에서 출장간 사람들이 작성하는 경우도 있긴 하지만 미팅이 끝난 후 기억을 더듬어 적는 편이다. 나를 포함해 같이 출장을 가는 친구들은 두어명을 빼고는 토종 한국인이기 때문에 듣고 말하는 것만으로도 벅차다. 그나마 회의록을 작성한다는 것만으로도 예전에 비하면 장족의 발전이라고 생각한다. 한국에서도 미팅하면 회의록을 작성할려고 하지만, 특히 출장와서 진행하는 미팅에서는 일종의 Evidence 차원에서도 우리가 이런 이야기를 나눴다라는 사실을 기록할 필요가 있다.
Google docs로 작성된 회의록은 전체 Share로 관련된 사람들에게 전달한다. 회의에 참석한 사람들 뿐만 아니라 다른 관심있는 사람들도 문서를 볼 수 있어야 한다. 그래야 논의된 이슈와 결과/결정에 대해 누구든 확인할 수 있고, 필요한 경우에 코멘트를 붙여가면서 추가적인 정리가 이뤄질 수 있다. 처음에는 특정한 몇몇 사람들을 찍어서 보냈었다. 하지만 본사 친구들처럼 열린 커뮤니케이션이 되려 회의 내용이 정보로써 팔딱팔딱 숨쉬게 만들어 준다는 걸 느끼게 되서 1~2년 전부터는 특별한 경우가 아니라면 코멘트 가능한 전체 공유 링크로 전달한다. 물론 굳이 회의 내용을 안봤으면 하는 친구까지 보는 바람에 의미없는 논쟁이 생긴적도 있긴 하지만, 이 과정을 넘어서면 논쟁한 본사 직원도 어느새 친구가 된다.
오전 미팅이 있는 경우에는 거의 이 미팅 하나로 오전을 채운다. 없다면 밤사이 한국에서 온 메일들을 보거나 출장과 관련된 코딩 작업을 진행한다. 개발자는 출장전에 출장의 목표를 설정하고, MVP(Minimum Viable Product)를 정한다. MVP를 달성하기 위한 수단으로 회의나 담당자를 만나러 다닌다고 보면 된다. 특히나 한국에서 본사 시스템/플랫폼과 관련된 개발을 하는 경우, 17시간이라는 시차 문제 때문에 제대로 지원받지 못한다. 몇 년이 흘러도 이 부분은 어떻게 개선이 안된다. 그래서 출장을 오가고, 이 기간을 통해 해결되는 경우가 많다.
아무리 본사 친구들이 문서를 잘 만든다고 하더라도 항상 문서는 코드를 따라오지 못한다. 같은 시간대에 있고, 책상이 바로 옆자리에 있는데 굳이 문서를 볼 필요가 뭐가 있나? 걍 그 친구한테 잠깐 책상으로 가도 되겠나 물어보고 이것 좀 이상한거 같은데 봐달라고 하면 대부분 기꺼운 마음으로 대답해준다.
얼추 점심 시간이 되면 회사 구내 식당으로 가서 밥을 먹는다. 밖에 나가서 먹으면 이동하는 시간도 많이 들 뿐더러 오후에 미팅이 있는 경우에는 서둘로 돌아와야 한다. 더구나 구내식당보다 맛있으리라는 보장도 거의 없다. LA 로컬 음식을 몇 번 먹어봤지만, 그나마 캠퍼스의 식당이 평균 이상이다. 그리고 언제나 김치가 있다!! 의외로 맛이 있다. 특정 팀과 관련된 일을 주로 하는 경우에는 종종 해당 팀과 점심을 먹는다. 가장 어려운 영어가 생활 영어다. 용어 자체도 기술 용어를 한참이나 벗어난 이야기들을 하는데… 열심히 듣고, 열심히 밥을 먹는다.
오후에 대부분의 미팅이 몰려있고, 3개 정도 제대로 컨퍼런스 룸에서 회의를 마치고나면, 공허할만큼 기운 빠진다. 빌지 카페에서 커피를 충전해도 마지막 미팅쯤이면 말이 잘 안나온다. 더구나 잠을 잘 못잔 경우에는 내가 생각하기에도 듣는 친구들에게 민망할 정도로 말이 꼬인다. 정책이나 상황을 설명해야 하는 미팅의 경우에는 매우 많이 난감하다. 하지만 기술 미팅의 경우에는 말로 하다 안되면 화이트보드를 이용하면 된다. 화이트보드 없는 회의실이 없으니까.
개발자들끼리도 말만 가지고 시스템이나 서비스의 동작을 설명하는건 어렵다. 한국말로 해도 어려운데, 그것도 살짝 정신줄 놓은 영어로 하는 판이니… 일면식 없는 상대끼리 얼마나 갑갑하겠는가? 이럴때 유용한 물건이 화이트보드와 노트북(랩탑말고)이다. 네모, 동그라미, 그리고 선. 이게 대부분이다. 좀 더 고급진 그림에는 실린더도 등장하지만. ㅎㅎ
모든 미팅을 마치면 잠깐 쉬었다가 미진했던 코딩을 하거나 미팅에서 나온 내용들을 확인하한 작업을 한다. 특히나 미팅에서 논의된 내용들이 MVP 관련 사항이고, 막혔던 부분들에 대한 것들이라면 정말 즐겁다. 특히 권한 때문에 진행이 안되던 경우, 미팅에서 “어, 그래? 그거 내가 주께~ 근데 그거 누가 못준다고 해?, 아… 그 친구 원래 그래. 미팅 끝나고 개발자 권한 줄테니까 함 해봐, 슬랙으로 핑줄께!” 이런 이야기들이 오고 갔다면 정말 좋다. “원래 그런” 친구들은 어디에나 있다는 걸 새삼 깨닭는다.
코딩 작업을 하다보면 저말 잘 이해가 안되는 부분들이 생기기도 한다. 뭐 찬찬히 보고 관련된 다른 부분들을 공부한다면 충분히 답이 나오겠지만, 출장 기간은 짧다. 지금 이 지점에서 이 길이 맞다라는 걸 확신하지 못하고 한국으로 돌아가면 몇 일 걸릴 일이 몇 달이 걸린다. 당장 궁금하기도 하고 해결해야 할 일이기 때문에 미팅한 친구한테 핑 때리고 데스크로 간다. 옆에 붙어서 막힌 코드를 보여주고, 내가 원하는 것과 현재 코드의 문제점을 확인한다. 대부분 마법같은 환경 설정에서 뭔가가 빠졌거나 권한 부족이다. 거의 대부분은 그 친구의 자리에서 해결된다. Damn!!
저녁이 되면 LA의 교통은 정체 지옥으로 변한다. 오후 4시부터 시작된 정체는 7시 반까지는 최소 이어진다. 처음 출장왔을 때 정체는 5시 반부터 시작됐고, 밀려도 서울 정도는 아니었는데 요즘은 15분 걸려오는 호텔을 45분, 1시간 걸려 도착한다. 저녁 먹으로 아예 4시 근방에 출발할게 아니라면 대부분은 근방 소텔이나 “우버 이츠(Uber eats)”로 해결한다. 최소 3일에 한번, 저녁은 한식을 먹는다. 소텔에 있는 순두부집에서 저녁을 많이 먹었는데, 사람들이 질려한다. -_-;;;; 우버 이츠라는 신세상을 발견한 다음에는 K타운 갈 일이 더욱 없어졌다. 굳이 그 오래 걸리는 길을 차타고 갈 이유가 없으니 말이다.
보통 퇴근은 캠퍼스에서 밥을 먹는 경우에는 8시쯤 퇴근한다. 밥도 먹고 밀리는 순간도 피하고. 이렇게 돌아와서 씻고 뻣으면 그대로 잔다. 그대로 잘 수 있다면 상당히 행복한 케이스다. 뒤척이다가 맥주 한잔? 와인 한잔 하는 파티와 어우리게 될 수도… 물론 분위기 좋은 바에가서 먹는 경우는 없다. 대부분 호텔방에서 어울려서 먹는다. 주인장이 되버린 방 주인은 다음날 크리링을 신청해야겠지만. 처음 출장와서 한동안은 술을 마시면 그나마 잠을 자는데 도움이 됐지만 지금은 이래도 그만 저래도 그만이다. 어떤일이 생겨도 아침에 일어나는 시간은 약속의 그 시간이기 때문에 되려 늦게까지 이야기하느라 잠을 못자면 다음 날이 더 힘들다.
이렇게 일정을 마쳤으면 이제 방으로 돌아와 잠을 청한다. 여러 음악앱을 깔아서 써봤는데, 내 취향을 알아주는(??) 뮤직을 틀어주는 앱은 유투브인 것 같다. 김광석 노래나 클래식 10곡 깔아놓고 잠을 청한다.
주말을 낀 출장의 경우, 대부분은 잔다. 잘 수 있을때까지 잔다. 12시간 이상 침대와 몰아일체가 되어 있으면 허리가 끊어질 정도로 아프다. 연속으로 이렇게 잔적은 없지만, 드문드문이라도 이정도 자면 그나마 괜찮다. 적당히 깬 후 호텔 비스트로에서 커피 한잔 먹은 다음, 저녁 먹으로 간다. 보통 주말은 K타운 고기집에서 하루 한끼 먹는 식사를 해결한다. 이렇게 먹고 나면 다음 날 일요일도 12시간 이상 잘 수 있다. 물론 이렇게 잔다고 하더라도 항상 새벽 3, 4시에는 뭔 약속이라도 한 것처럼 귀신같이 눈이 떠진다. 하루 한끼가 말이 되냐고 할지 모르지만 잘 수 있을 때 자는게 그 다음 주의 시간을 위해 꼭 필요하다.
이렇게 평일의 출장 일상은 이렇게 흘러간다. 주말이 끼지 않은 출장의 경우에는 금요일 밤이나 토요일 아침에 한국으로 출발하는 비행기를 탄다. 어찌됐든 한국에 돌아와서 랜딩하는 순간, 넘 기분이 좋다. 참 신기한 일이지만, 집에 와서 김치찌개랑 소주 한잔 먹고 잠자면 그 못자던 잠이 한꺼번에 쏟아진다. 10시간 가까이를 논스톱으로 잔다.
출장후에는 출장에서 논의된 이야기들을 내부적으로 가능한 빠르게 공유하고, 그 다음 스텝을 F/U해야 한다. 망각의 동물이 사람이다. 나도 까먹지만, 본사에서 나랑 미팅한 그 친구들도 까먹는다. 후속 작업이 바로 이어질 수 있도록 해야지 본사에서 미팅한 내용들이 자연스럽게 이어져 결과로 매듭될 수 있다. 다음 한주는 지난 주 출장의 내용들을 공유하고, 어떤께 후속 작업을 진행할지 팀에 있는 친구들이랑 이야기해야 한다. 마무리와 새로운 시작을 잘 하자.
– 끝 –
매니저이긴 하지만 개발자다. 각자 해야할 일들이 많다. 하지만 일의 우선 순위는 매니저로써 혹은 리더로써의 일들이 항상 높은 우선 순위를 가진다. 심적으로는 코딩을 하고 싶다. 그리고 코딩하면서, 로직의 흐름에 몸을 맡기고 있으면 아무 생각도 없다. 하지만 종종 이런 몰입 상태를 유지하다가는 정작 팀의 결정 사항들이 뒤로 밀려지거나 처리할 문서들이 한가득 쌓인다. 결국 우선 순위는 팀에 영향을 미칠 수 있는 일들이 먼저다. 코딩과는 거리가 있는 ㅠㅠ
하지만 팀에서 개발자로써의 지분을 가지고 있기 때문에 해야만 하는 코딩도 있다. 까먹거나 방만해질 때 “일로써 코딩“을 해야한다. 나름 부지런하다고 생각하지만 놓친다. 하지만 옆에 나보다 더 부지런한 친구들이 있다. 내가 다른 일을 하고 있거나 띵가띵가 거리고 있다가 그 친구들이 함께 놀지 않는다. 각자의 일 스타일로 계속 결과를 만들어낸다. 나의 결과가 그들의 결과와 합쳐져야 제대로 된 시스템을 완성할 수 있다. 앞서 나가는 코드 결과를 PR로 받아봤을 때, 나도 그들에게 PR을 보내고 싶다. 즐거운 자극이고, 상당한 압박이다.
본사 출장중에 여러 풍경들이 있지만, 가장 내가 좋아하는 풍경이다. 비록 코딩을 했던 건 아니지만, 이제 코딩을 할 수 있다. 즐거운 마음으로 PR을 만들어야지. “워크홀릭(Workaholic)”이라지만 당장은 일에서 즐거움을 찾을 수 있으니 것도 나쁘지 않다. 주 52시간이 실행되면 이것도 쉽지 않을테니 즐길 수 있을 때, 즐기자.
이 책이 2002년도에 첫판이 나왔다니까 현재 시점이랑은 17년의 갭이 존재한다. 하지만 최근에 나왔다는 여러 책들과 그 내용을 비교해봐도 팀을 관점에서 17년전이 사고와 현재가 틀리지 않았다. 미국적 사고여서 그런건가 싶기도 하다. 내가 겪어왔던 17년의 세월동안에 리더십에 관련된 이야기들이 한국에서는 몇 번의 변곡점이 있었다고 생각되니까.
픽션식으로 한 회사내에서 이뤄지는 두달 동안의 변화를 이야기식으로 풀어냈다. 글이 흥미진지하다. 하지만 전달해야 할 내용은 줄거리의 흐름에 잘 녹아져있다. 왜 베스트셀러인지 충분히 공감된다.
~~~
신뢰(Trust)는 진정한 팀웍을 이루는 가장 기본 요소다. 때문에 서로를 이해하고 상대방에게 열린 태도를 갖추지 못한다면 팀웍은 기대할 수 없다. 제대로 된 팀이라면 팀원간에 서로 등돌리지 말아야 한다. 자신의 실수와 약점을 솔직하고 두려움없이 이야기하고 인정할 수 있어야 한다. (their mistakes, their weakness, and their concerns without fear of reprisal)
미팅에서 이야기가 오가지만, 이야기는 이야기일 뿐 서로 문제가 되지 않기 위해서 그러는 척 할 뿐 짐심을 담아서 문제를 이해하고 그 문제 혹은 해결 방법에 동의(agreement)는 어렵다.
다른 사람의 소중한 시간을 배려하기 위해 전체 팀원들에게 중요한 이야기만 팀 미팅에서 이야기해야 한다? 완전히 개인적인 이야기나 특정 사람을 비난할 목적의 이야기가 아니라면 팀 미팅에서 함께 다뤄져야하고 미팅에 들어온 사람들은 온전히 그 이야기에 집중하고, 들어야 한다. 미팅 시간에 다른 짓을 하는거야말로 미팅 시간에 모인 다른 사람들의 소중한 시간을 낭비하게 만드는 결과를 초래한다. IT회사라고 해서 원온원(One-on-one)을 주창하지만, 그건 소통의 한 수단일 뿐 결국에는 소통 방식의 한 수단일 뿐이다. 다른 사람들도 알아야 한다면 팀 미팅이 되려 더 좋은 선택이고 합리적인 소통 방법을 찾는 것이 좋은 팀 문화다.
Relationship setting – 신뢰(Trust)는 그냥 만들어지는게 아니라 그 사람에 대해 아는 것부터 시작한다. 사람을 처음부터 알기는 불가능하고, 그 사람의 가족이나 집안 환경 혹은 성장 배경등을 알 때 얼추 짐작을 시작할 수 있다. 일상적인 생활의 일부를 공유하고 있어야지 그 사람의 태도나 성격을 짐작할 수 있다. 일이 본격적으로 힘들어 지더라도 이런 배경 지식이 업무 가운데서 신뢰가 쌓여가는데 도움이 된다.
사람들이 서로 싸운(arguing, heated debating)다고 해서 이걸 인위적으로 중재해서 가식적인 평화 상태를 만드는 건 리더로써 올바른 선택이 아니다. 문제가 있다면 그걸 수면위로 드러내고, 팀 내부에서 자연스럽게 결론이 도출될 수 있도록 가이드해야 한다.
팀원들이 팀 내에서 개인의 현재 위치를 인식하게 만들어야 한다. 팀/회사를 위해 공헌하는 측면에서 딱 1개씩 잘하는 것과 고쳐야 할 것들을 다른 팀원들 앞에서 이야기하는게 필요하다. 이 과정은 개인이 생각하는 면과 다른 팀원들이 생각하는 그 팀워에 대한 시각차가 어떤 것들이 있는지 드러내고, 이 차이를 어떤 방식으로 메꿀지를 명확하게 할 수 있다.
다른 사람들과의 협업을 포기하고, 저 혼자 잘났다고 생각하는 사람이 있다면, 그 사람을 가만히 두면 안된다. 그 사람의 태도로 인해 팀내 협업이 망가질 수 있고, 혼자 잘 났다고 하는 자존심(Ego)를 되려 키워줄 수 있기 때문에 팀에 마이너스로 동작한다. 그런 징후가 보이면 바로 싹을 잘라야한다. 탑신병자처럼 개인 플레이만 고집하고 개인 성과에만 집착하는 경우라면 아무리 능력이 좋더라도 팀원으로써의 가치가 없다. 과감하게 팀에서 배제하고, 필요하다면 내보내는게 맞다.
Inattention to results – the tendency of team members to seek out individual recognition and attention at the expense of results, the goals of the entire team. The key is to make the collective ego greater than the individual ones.
팀이 의미있는 결과를 만들어내는지를 지속적으로 체크해야 한다. 두말할 나위없이 이익을 많이 내는게 확실한 결과겠지만, 이건 말그대로 결과론적이다. 이보다는 지속적인 개선을 통해 궁극적인 Goal을 달성해야 한다. 따라서 단기적인 달성 가능한 목표(Goal) 수립이 필요하고, 이 목표를 위한 진행 단계(Milestone)를 정한다. 그리고 지속적으로 진행 결과 및 과정을 리뷰하고 필요한 수정을 거쳐야 한다. 단기 목표는 구성원 모두가 헷갈림없이 이해하고 동의해야 한다. 그래야 팀의 목표에 모두가 동참할 수 있으며, 이게 안되면 각자 도생(Individual status or ego)의 방법을 찾게 된다. 합의된 목표에 대한 진행 상태는 일별로 체크 가능해야하며, 그 결과 역시 투명하게 공유되어야 한다.
농구팀을 상상해보자. 전반전이 끝난 후 라커룸에서 선수들에게 피드백을 줘야하는 코치가 있다. 코치가 피드백을 준다고, 센터 불러서 코치실에서 원온원(One-on-one)하고, 포인트 가드, SF, PF 다 따로 불러서 이야기한다면? 각자의 피드백이 팀 선수들 사이에서 팀 플레이로 살아날까? 선수 개인은 어떨지 모르겠지만, 팀 플레이는 기대하기 힘들다. (That’s not a team. It’s a collection of individuals.) 마찬가지로 팀에서 각자가 하는 일 역시 팀 플에이어야 한다. 누구는 Frontend를 담당하고 있기 때문에 Backend에 대한 관심이나 책임이 없다고 하거나 그 역도 마찬가지다. 팀으로써 우리는 모두 팀이 하는 어떤 일에 대해서도 책임이 있고, 기능적으로 다른 일을 하고 있기 때문에 나는 책임이 없다고 이야기한다면 그 사람은 팀원으로 불합격이다. 기능이 Fabric으로 엮여서 공동의 목표를 수행한다고 했을 때, 나는 반드시 다른 팀원들이 어떤 일을 하고 있고 협업 플레이를 위해 뭘 해야하지 주의깊게 살펴야 한다.
Fear of conflict – You have tension. But there is almost no constructive conflict. Passive, sarcastic comments are not the kind of conflict I’m talking about.
건설적인 토론은 문제 해결을 위해 서로의 의견을 가감없이 테이블위에 올리고, 그 가운데 무엇이 최선인지를 따지는 것을 의미한다. 단순히 난 말을 했고, 넌 이야기를 들었다로 결론내려지는 토론은 전혀 의미없다. 또한 괜히 다른 사람과의 의견 충돌을 두려워해서 이도 저도 아닌 상태가 되도록 방치하는 것도 되려 팀이 앞으로 나아가는 것을 방해하는 짓이다. 치열하게 논쟁하고 싸워서 의미있는 결론이 내려지는 팀 문화가 가치있다. 되려 이런 걸 두려워해서 빅마우스 앞에서 입도 뻥긋안하는 그게 쳐내야할 적폐다.
p96. Lack of commitment – Even if people generally willing to commit, they aren’t going to do so because they need to weigh in before they can really buy-in.
p98. Avoidance of accountability – Once we achieve clarity and buy-in, it is then that we have to hold each other accountable for what we sign up to do, for high standards of performance and behavior. And as simple as that sounds, most executives hate to do it, especially when it comes to a peer’s behavior because they want to avoid interpersonal discomfort.
당신이 결과를 가장 우선시하는 팀(Your first team)이 당신의 팀이다. 개인이 부서장이나 팀장이더라도 그 팀의 결과를 우선으로 삼는다면 그건 개인/팀 이기주의다. 회사에 소속되어 있다면 회사가 잘 되도록 만드는 것이 조직의 일원으로써 갖는 최선의 미덕이다. 이걸 달성하기 위해 가장 먼저 고려해야하는 것은 내가 일한 결과가 누구를 위한 것이냐하는 문제다. 내가 이끌고 있는 팀이 우선이다면 앞서 이야기한 것처럼 팀 이기주의다. 되려 팀장으로써 소속된 본부의 결과를 위해 최선을 하는 것이 맞다. 마찬가지로 본부장도 회사를 위한 결정을 따르고 그 결정을 결과로 이뤄내기를 기대하기 때문에.
그러나 이렇다고 해서 자신이 이끄는 팀을 고려하지 말라는 것은 아니다. 본부의 팀장들이 나의 First Team이 될 것이고, 개발팀은 Secondary Team이 되면 되니까. 신경쓰지 말라는 이야기가 아니라 노력이 어느 부분에 더 집중되어야 하는지를 이야기한다. (Well, you don’t have to destroy it. But you do have to be willing to make it secondary. And for many of you, that might very well feel like abandonment.)
만일 동료가 나의 전문 영역이라는 부분에 대한 이야기가 내가 느끼기에 간섭(혹은 침범)이라고 느껴질 때, 방어적이된다. 이런 태도는 함께하는 동료에 대한 믿음이 부족함에서 오지 않을까 싶다. 그리고 전문가로써 자신에 기량에 대한 의문이라고 생각하기 때문일 것이다. 자존심(ego)와도 깊은 관련성이 있다.
일을 못한 부분에 대해서는 책임을 져야한다. 그리고 못한 부분이 있다면 그 부분을 동료로써 과감하게 질책해야 한다. 되려 그럴수도 있지… 하게 되면 일을 하지 못한 그 동료는 앞으로도 그래도 되는구나라는 안이한 생각을 한다. 담당하는 일과 관련해서 문제를 일으켰거나 일정을 제대로 못지킨다면 그 부분의 책임을 동료 사이라도 명확하게 지적해야 한다. 그 다음에 그 문제를 해결할 방안을 같이 모색해야한다. 책임이 있는 부분에 대해서는 책임을 인정하고, 또 인정하도록 챌린지(Challenge)해야 한다.
Trust is knowing that when a team member does push you, they’re doing it because they care about the team. But we have to push in a way that doesn’t piss people off. Absolutely. Push with respect, and under the assumption that the other person is probably doing the right thing. But push anyway. And never hold back.
It requires team members to make themselves vulnerable to one another and be confident that their respective vulnerabilities will not be used against them. The vulnerabilities I’m referring to include the weakness, skill deficiencies, interpersonal shortcomings, mistakes, and requests for help. It is only when team members are truly comfortable being exposed to one another that they begin to act without concern for protecting themselves. As a result, they can focus their energy and attention completely on the job at hand, rather than on being strategically disingenuous or political with one another.
Team effectiveness exercise – It requires team members to identify the single most important contribution that each of their peers makes the team, as well as the one area that they must either improve upon or eliminate for the good of the team. All members then report their responses, focusing on one person at a time, usually beginning with the team leader.
Demonstrate vulnerability first. This requires that a leader risk losing face in front of the team so that subordinates will take the same risk themselves. What’s more, team leaders must create an environment that does not punish vulnerability. Even well-intentioned teams can subtly discourage trust by chastising one another for admissions of weakness or failure. Finally, displays of vulnerability on the part of a team leader must be genuine; they cannot be staged. One of the best ways to lose the trust of a team is to feign vulnerability in order to manipulate the emotions of others.
It is important to distinguish productive ideological conflict from destructive fighting and interpersonal politics. Ideological conflict is to limit to concepts and ideas and avoids personality-focused, mean-spirited attacks. However, it can have many of the same external qualities of interpersonal conflict – passion, emotion, and frustration – so much so that an outside observer might easily mistake it for unproductive discord.
When team members openly debate and disagree about the important ideas, they often turn to back-channel personal attacks, which are far nastier and more harmful than any heated argument over issues.
It is key that leaders demonstrate restraint when their people engage in conflict, and allow a resolution to occur naturally, as messy as it can sometimes be. This can be a challenge because many leaders feel that they are somehow failing in their jobs by losing control of their teams during conflicts.
In the context of a team, commitment is a function of two things: clarity and buy-in. Great teams make clear and timely decisions and move forward with complete buy-in from every member of the team, even those who voted against the decision.
Consensus – Great teams understand the danger of seeking consensus, and find ways to achieve buy-in even when the complete agreement is impossible. They understand that reasonable human beings do not need to get their way in order to support a decision, but only need to know that their opinions have been heard and considered. And when the agreement is not possible due to an impasse, the leader of the team is allowed to make the call.
Certainty – That’s because they understand the old military axiom that a decision is better than no decision. They also realize that it is better to make a decision boldly and be wrong than it is to waffle. If wrong, change the direction with equal boldness.
More than any other member of the team, the leader must be comfortable with the prospect of making a decision that ultimately turns out to be wrong. And the leader must be constantly pushing the group for closure around issues, as well as adherence to schedules that the team has set. What the leader cannot do is place too high a premium on certainty or consensus.
The most effective and efficient means of maintaining high standards of performance on a team is peer pressure. One of the benefits is the reduction of the need for excessive bureaucracy around performance management and corrective action. More than any policy or system, there is nothing like the fear of letting down respected teammates that motivates people to improve their performance.
Simple and regular progress review – Relying on them to do so on their own, with no clear expectations or structure, is inviting the potential for the avoidance of accountability.
Team Rewards – By shifting rewards away from individual performance to team achievement, the team can create a culture of accountability. This occurs because a team is unlikely to stand by quietly and fail because a peer is not pulling his or her weight.
They do not live and breathe n order to achieve meaningful objectives, nut rather merely to exist or survive. Unfortunately for these groups, no amount of trust, conflict, commitment, or accountability can compensate for a lack of desire to win.
By making results clear and rewarding only those behaviors and actions that contribute to those results.
Teams that say, “We’ll do our best”, are subtly, if not purposefully, preparing themselves for failure.
Team leaders must be selfless and objective, and reserve rewards and recognition for those who make real contributions to the achievement of group goals.
~~~
종종 찾아보면서 읽고, 내용을 새기면 좋을 듯 싶다.
다른 글에서 슬랙(Slack)을 업무용으로 괜찮게 사용하기 위한 팁을 몇가지 소개했다. 이번은 슬랙이라는 커뮤니케이션 도구 혹은 커뮤니케이션 공간의 배려에 대해 이야기 해보고 싶다.
슬랙은 업무용 메신저다. 메신저가 다 같은 메신저일 뿐이지, 다른게 뭐냐??? 라고 이야기하는 분이 있다면 일상과 일(업무)을 구분하지 못하는 분이다. 슬랙류를 사용하는 이유는 업무를 위해서지 수다떨기 위함이 아니다.
슬랙은 기본적으로 일을 위해 쓴다. 그렇기 때문에 이 공간에서 이뤄지는 일상적인 대화는 정보(Information)의 가치를 갖는다. 업무를 진행하는데 있어서 정보의 중요성은 모두가 공감할 것이다. 그리고 정보의 가치는 필요한 사람에게 전달 가능할 때 가장 빛을 발한다.
슬랙의 대화는 공개 채널(Public Channel) / 비공개 채널(Private Channel) / 1:1 메시지(DM – Direct Message)의 3가지 형태로 이뤄진다. 정보 가치를 갖는 대화가 업무 관련 담당자들에게 도움이 될려면, 대화 기록에 자유롭게 접근할 수 있어야 한다. 특정 이슈 혹은. 주제에 대한 이해 당사자이외에도 관심있는 사람들의 다양한 관점들이 모아지면, 정보의 가치가 더욱 커질 수 있다. 이런 부분을 고려한다면 가장 효과적인 대화 형태는 공개 채널이다.
공개 채널의 투명성은 어떤 면에서는 참가자들이 신중한 대화를 하도록 부작용 혹은 순작용으로 동작한다. 속된 말로 아무말 대잔치를 할 수는 없다. 본인이 던지는 이슈 혹은 질문받은 내용들을 한번 더 생각하게 만든다. 물론 이런 이유로 공개 채널에서 이야기하기를 꺼리고 눈팅만 하기도 한다. 누구는 속된 말로 “자기검열” 아니냐… 이야기할 수 있지만 정제된 대화라면 더욱 더 정보 가치를 지닐 수 있다.
비공개 채널은 채널에 초대받은 사람만 참여가 가능하다. 그리고 1:1 메시지는 당연히 개인간 대화니 초대받지 않은 다른 사람이 메시지 내용을 볼 수 없다. 이 환경에서 주고받는 정보는 고립된다. 제한된 사람만 내용을 알고 있고 모르는 사람은 소외된다. 좀 더 과장하자면 정보를 무기로 사용하게 된다. 이러면 안된다.
채널의 물리적인 종류는 앞서 이야기한 바와 같이 공개 / 비공개 유형으로 나뉜다. 이를 실제 운영상 관점에서 살펴보자. 회사 혹은 조직의 특성에 따라 슬랙 채널에 어떤 의미를 두는지는 경우에 따라 다른다. 그렇지만 일반적인 경우 한 팀은 하나의 대표 슬랙 체널을 갖는다. 내가 현재 속한 라이엇 개발팀의 경우 #team-dev 형식의 채널의 이름을 부여한다. 팀 채널의 경우에는 팀에 소속된 사람들이 기본 멤버로 참여하고, 이루어지는 대화들도 대부분 팀에 한정된 이야기들이다.
개발팀에서 이뤄지는 일들에 대해 관련된 사람들이 질문하거나 논의하는 장소는 팀 채널이 아니다. 이런 목적을 위해 #ask-dev 채널이 존재한다. 이 채널의 참여자는 물론 개발팀에 있는 모두가 포함되며, 업무 관여자(Stakeholder)들이 모두 참여한다. 이 채널에서는 개발팀이 아닌 일반 업무 관여자들은 주로 업무 현황이나 이슈에 대한 질문을 던진다. 개발팀은 이 채널을 주요 당사자들이 알아야할 중요 전달 사항이나 공유 사항들을 이야기한다. 두 가지 모두 의미를 가지는 정보가 되고, 관련된 당사자들이 종종 챙겨봐야 할 내용들이다.
이 이외에도 채널의 이름을 통해 의미를 부여하는 방법은 다양하게 있다. 특정한 프로젝트를 위한 채널의 경우에는 #prj-something 이라는 방식으로 이름을 짓는다. 이 채널의 구성원은 프로젝트 실무를 진행하는 주요 담당자들이 기본 멤버가 된다. 주로는 PO 혹은 PM, 개발자, QA 담당자들이 기본 멤버가 되며, 필요에 따라서 이해 당사자들이 참여한다. 프로젝트가 완료되어 하나의 제품이 되었다면, 이제 제품에 대한 질의 응답을 위한 #ask-something 채널로 진화한다. 혹은 완료되어 특정 팀의 운영 범위로 들어간다면 채널을 Archive 시키고, 이후에 관련된 논의들을 개발팀이 운영하는 #ask-dev 채널로 통합히기도 한다. Archive 시킨다고 하더라도 내용이 어디 사라지는 것도 아니고 검색도 당연히 할 수 있기 때문에 문제없다.
채널의 이름을 통한 부여된 의미를 현재 내가 속한 조직의 기준으로 정리하면 대강 아래와 같다. 각 조직의 현황에 맞춘 일관성을 유지할 수 있다면 아래 열거된 내용 이외에도 다른 명명 규칙을 정의한다. 하지만 접두어를 통해 제시하는 용도의 일관성은 지켜져야하기 때문에 가급적 합의된(혹은 정의된) 규칙을 지켜줘야 한다. 목적에 맞는 채널을 찾는 사람의 경우, 아래 열거된 간단한 추론을 통해 팀의 채널을 찾아올 수 있기 때문이다.
이제 배려를 이야기해자. 몇몇 채널의 명명 규칙을 이야기하면서 누가 그 채널의 주체가 되어야 하는지도 언급했다. 그리고 앞서서 채널은 정보의 공유를 위해 공개 채널을 유지하는 것이 바람직하다는 이야기도 했다. 그런데 여기서 왜 배려가 튀어 나올까?
각각의 채널에는 각 채널의 주체와 목적이 있다. 특정 팀의 채널은 말그대로 그 팀을 위한 전용 공간이고 또한 되어야 한다. 프로젝트 채널의 경우에도 비슷한 맥락을 따른다. 그럼에도 채널을 공개 채널로 유지해야 하는 이유는 공유되어야 할 내용이 자유롭게 공유되기 위함이다. 그런데 팀과 직접 연관된 사람도 아닌 사람이 팀 혹은 프로젝트 채널에서 불쑥불쑥 튀어 나와 이야기를 한다면?
뭐가 문제인가 싶긴 하지만… 나는 이 부분에서 2가지 문제를 지적하고 싶다. 첫 번째 문제는 팀 채널이나 ask 채널의 구분이 모호해진다. 즉 이야기를 공유할 적절한 공간이 어디인지 헷갈리기 시작한다. 대화가 어디에서 시작되는지가 헷갈리니 나중에는 그 내용을 어디에서 찾아야 할지 헷갈린다. 이 문제는 비슷비슷한 성격의 채널들이 여러개 생겨나면 가장 대표적으로 나타난다.
두 번째 문제는 자연스러운 무관심이다. 특정 팀이나 프로젝트 채널의 경우에는 업무 이야기도 많이 하지만 짤방부터 아재 개그까지 다양한 이야기들이 난무한다. 물론 그 가운데 의미있는 정보도 있다. 그렇지만 다른 도메인의 이야기들은 나에게는 4차원의 이야기인 경우가 다반사 아닌가? 그럼 결국 몇 번 보게 되지만, 그럼에도 Mute한다. 안읽은 내용이 있기 때문에 신경쓰는 것보다는 차라리 해당 채널을 나오는게 개인적으로는 정신 건강에 더 좋다.
이 관점에서 채널의 주인 팀에서 다른 팀을 존중하는 배려는 그럼 뭘까? 가장 먼저 해당 팀에서 다른 팀의 팀원을 초대할 때 먼저 신중해야 한다. 정보를 전달하는데 있어서 본인의 팀 채널에서 정보를 전달하는 것어 과연 올바른지 한번 생각해보자. 맞지 않다고 생각이 들면 팀 채널이 아니라 ask 채널로 가야한다. 혹은 전달해줘야 할 사람이 있는 팀의 ask 채널. 것도 아니면 prj 채널 혹은 nt 채널이 정보가 나타나야할 맞는 곳일 수 있다. 괜히 엄하게 초대해서 초대받은 당사자를 뻘쭘하게 만들 수 있다.
역으로 초대받은 쪽에서도 해당 정보를 공유받았다면, 공유받은 정보만 잘 보관하자. 그 내용을 본인의 팀 채널 혹은 ask 채널에 링크든 공유 형태든 가져오면 된다. 가져왔으면 굳이 초대 받은 채널에 남을 이유가 없다. 바로 Leave를 선택하자. 만약 이후라도 공유해줄 내용이 있다면 아마도 또 부른다. 그 사람이 날 불렀다는 건 그 사람이 궁해서지 내가 궁한건 아니니까.
정보를 잘 퍼갈 수 있는 방법은 뭘까? 스크린 캡쳐??? ㅋㅋㅋ
어이없는 소리같지만 실제로 이런 경우가 정말 많다. 아마 증거 확보차원이라고 생각한다. 근데 뭘 위한 증거일까? ㅎㅎㅎ 근데 정말 많이 이미지로 캡쳐 후 공유한다.
슬랙은 다른(혹은 같아도) 공개 채널의 대화를 자유롭게 공유할 수 있다. 공유와 링크 복붙으로 메뉴가 나뉘지만, 본질적으로는 같다. 근데 아래와 같은 경우는 어떻게 해야할까?
공유해야할 내용은 3줄인데 각각이 구분된 메시지 있다. 두줄을 어떻게 하면 함께 공유할 수 있을까? 예시지만 함께 공유되어야 하는 경우에는 이미지 캡쳐가 동료들에게 더 효과적일 수 있다. 그중에 어느 하나만 공유하면 나머지는 무시될 수 있으니까.
하지만 원칙적으로 작성하는 사람이 공유 가능한 형태로 작성하지 않은 잘못이 더 크다. 직설적으로 이야기하자면 동료에 대한 배려심 부족? 사실은 단톡방의 습관에서 유발된 것이다. 본인이 아닌 3자가 공유하기위해 분리된 메시지가 아닌 한 메시지로 작성해야했다.
업무를 위한 대화가 시작되었다면 그 내용은 반드시 쓰레드화 되어야 한다. 당연히 업무 공유를 위해서다. 업무 관련 내용들이 쓰레드 형식이 아닌 평면적인 형태로 채널에 올라와서 한 페이지 분량 이상이 되면 캡쳐로도 공유하기 함들어진다. 상식적으로 업무에 관련된 내용들이 어떤 채널에서든 시작이 되었다면 그걸 주제로 새로운 글의 실타래가 시작되어야 한다. 요즘에는 거의 습관적으로 
(:use_the_threads:) 라는 이모지를 글을 시작한 사람이 적지 않았더라도 일하는 사람의 기본이라고 생각하자.
그럼에도 불구하고 여전히 많은 분들이 슬랙을 단톡방처럼 사용하신다. 업무를 위한 이성적인 문구가 아닌 단발성 단어로 된 줄들이 이어진다. 제대로 된 정보없이 쓰레드의 라인 수만 길어진다. 과도한 라인수는 난독증을 유발한다. 항상 이럴 필요는 없지만, 정보의 가치를 생각한다면 의미있는 글의 흐름을 고려해야 한다. 물론 여러 사람들이 이런 쓰기를 다 같이 하는 건 무지 어렵다. 시킨다고 되지도 않는다. 이게 될려면 하나의 문화로 정착되어야 가능하다. “될 수 있을까?“는 다소 의문이긴 하지만… ㅎㅎ
슬랙이 업무용 메신저로 써본 사람이라면 정말 편리하다는 걸 알 수 있다. 그러다보니 많은 소통이 슬랙을 통해 이뤄진다. 일견 사람들간의 피드백이 빨리졌고, 업무 처리 속도 역시 향상됐다.
하지만 이 과정에서 좋은 모습만 있는 것은 아니다. 관심있는 채널에 올라오는 메시지에 민감해지고, 알림을 통해 전체(@all, @channel) 혹은 특정 사람을 호출하는 것이 일상화됐다. 사람들은 알림에 신경질적으로 바뀐다. 특히나 한 지역이 아니라 시차가 나뉜 경우에는 이 문제가 좀 더 심각하다. 새벽 2~3시쯤 숙면을 취하고 있는데 슬랙 알림을 받으면 편한 마음이 안된다.
가장 속편한 방법은 어느 글에서나 이야기하는 거지만, 장문의 글보다는 찾아가서 대화하는 거다. 대부분 그게 안되기 때문에 슬랙을 이용하지만, 만약 글이 장문이 되는 경우에는 슬랙보다는 메일이 효과적이다. 정리할 내용이 많다면 메일 보내고, 슬랙으로 살짝 “멜 보셈” 이라고 메시지를 남겨두는게 훨씬 효과적이다. 메일 회신이 안온다면? 슬랙 메시지 한번 더 보내면 된다. 🙂
그리고 슬랙으로 인한 숙면 방해에서 벗어나고 싶다면 다음 설정을 권한다.
대강 아래 그림과 같은 구도로 업무 이야기/토론이 진행되었으면 좋겠다는 바램이다.
일단은 나 스스로부터 먼저 습관이 되어야겠다.
– 끝 –
배치(Batch)라는 작업은 주기적으로 실행되는 작업을 말한다. 다루는 데이터가 적은 경우는 별 걱정이 없다. 하지만 다룰 데이터가 많다면 과연 이 작업이 정해진 시간안에 끝날지 걱정하게 된다. 배치 작업은 대량의 데이터에 대한 문제도 있지만, 한 주기안에 그 일이 끝나야한다는 시간적인 제약도 존재하는 문제기도 하다.
서비스와 이를 뒷받침하는 시스템은 계속 진화한다. 그리고 데이터와 시간에 대한 최적화도 진화에 맞춰 지속되어야 한다. 최근의 시스템은 MSA(Microservice Architecture)를 따라 보편적으로 개발한다. 그리고 기존의 시스템들도 MSA화 하기 위한 방향으로 변경을 진행한다. 내가 있는 라이엇게임즈 개발팀에서도 시스템을 개편하거나 신규 시스템들은 모두 MSA를 따라 개발 작업을 진행한다.
MSA 방식으로 구성된 시스템은 Monolithic 방식으로 구성된 시스템보다는 내부 Component간 연동이 느릴 수밖에 없다. 어플리케이션 내부의 함수 콜이 작은 어플리케이션간의 RESTful API 호출로 바뀌었기 때문에 당연히 느릴 수밖에 없다. 각각의 컴포넌트는 독립적이고 자율적인 형태로 바뀌었지만, 이에 대한 반대 급부로 컴포넌트간의 연동 속도 저하가 단점이 될 수 밖에는 없다. 배치 작업 가운데 여러 외부 컴포넌트를 연동하는 경우가 많다면 MSA를 따르면서 전반적인 시스템의 최적화가 난관에 봉착하게 마련이다. 생각보다 한 주기의 시간안에 작업을 끝내는게 심각하게 어려운 작업이라는 것을 새롭게 알 수 있게 될 수 도 있다..
이 글에서는 팀이 MSA 환경에서 어떻게 배치 시스템의 속도 문제를 사고의 전환으로 해결했는지 소개한다.
휴면 계정은 개인 정보 보호 조치 가운데 하나다. 계정이 1년 동안 아무런 활동도 없으면, 해당 계정과 관련된 개인 정보를 라이브 시스템에서 없애고 이를 라이브 시스템과 분리된 별도의 공간에 저장하는 조치다. 유럽에서 GDPR이 작년(2017)에 실행되면서 개인 정보 보호 조치를 강화했지만, 한국에서는 이미 2015년에 이 조치를 실행했다. 이런 경우들을 두고보면 개인 정보를 다루는 법률적인 측면에서 한국이 되려 다른 나라보다 선두에 있음에 틀림없다. 꼭 이런 조치를 실행하고, 시스템을 만들어야 하는가에 대한 논의가 있긴하다. 하지만 불필요한 개인 정보를 굳이 라이브 시스템에 둘 이유는 없다. 필요없다면 지우는게 맞다. 이런 측면에서 옳은 정책임에는 틀림없다. 다만 이를 어떻게 구현하고 실행할지 그 방법론이 문제가 될 수 있을지도 모르겠다.
휴면 계정 대상자는 휴면 조치를 취하기 전 1개월내에 최소 1회 이상, 계정 소유주에게 휴면 조치가 취해진다는 사실을 알려야 한다. 그럼에도 불구하고 추가적인 활동이 없다면 최종 활동이 있었던 시점으로부터 1년이 되는 날에 계정에 대한 휴면 조치를 실행한다.
1년 동안 아무런 활동도 없는 계정들을 추출하기 위해서 어떤 방식을 사용하나? 가장 쉽고 일반적으로 생각할 수 있는 방안은 매일 전체 Active 계정들(ACCOUNT 테이블)을 추출한 다음에 해당 계정들의 최종 Activity Date를 확인하는 방법이다.
안목있는 아키텍트가 있다면, 최종 활동에 대한 정보를 하나의 테이블(RECENT_ACTIVITY)에 모아둘 것이다. 그리고 모든 데이터가 하나의 데이터베이스에 있는 구조라면 이 문제를 가장 손쉽게 해결할 수 있다. SQL 쿼리 한방으로.
SELECT * FROM ACCOUNT, RECENT_ACTIVITY WHERE ACCOUNT.id = RECENT_ACTIVITY.account_id AND RECENT_ACTIVITY.activity_datetime < now() - 365;
휴면 계정으로 추출된 계정 정보들을 휴면 계정화하고, 이를 계정 테이블에서 삭제한다. 정말 깔끔하다. 휴면 계정화 1개월 전에 보내야하는 통보 기능도 비슷한 쿼리로 이메일 주소를 추출해서 처리할 수 있다.
SELECT * FROM ACCOUNT, RECENT_ACTIVITY WHERE ACCOUNT.id = RECENT_ACTIVITY.account_id AND RECENT_ACTIVITY.activity_datetime < now() - 335;
원래 있던 쿼리의 365를 335로 간단히 바꾸면 통보를 위한 대상자도 손쉽게 추출할 수 있다.
MSA를 서비스에 적용하면서 이제 역할에 따른 DBMS를 별도로 분리한다. MSA의 기본 원칙 가운데 하나는 하나의 마이크로서비스가 자신의 데이터를 서비스를 위해 정의한 저장소에 관리하고, 해당 데이터가 필요한 다른 서비스들은 API를 통해 참조하는 것을 원칙으로 한다.
이제 최종 활동에 대한 관리 기능이 별개의 서비스(ActivityLogger)로 분리된다. 잦은 로깅으로 전체 서비스에 영향을 주던 민폐를 걷어내고, 온전히 로깅에 대한 역할을 담당하는 마이크로서비스로 거듭난다. 계정의 최종 활동일을 계정 테이블에 담고자하는 노력이 있긴 했지만, 계정 테이블은 많은 서비스들에서 기본적으로 참조하는 데이터 영역이고, 잦은 업데이트는 과도한 IO 부하를 일으키기 때문에 ActivityLogger 서비스의 API를 통해 참조해서 처리하기로 한다.
ElasticSearch를 통해 구현된 최종 활동 API는 빠른 응답 속도를 보장한다. 이를 사용하기로 했기 때문에 어쩔 수 없이 전체 계정들을 모두 로딩 후 API를 호출해서 최종 Activity Date를 구하고, 1년이 경과한 계정을 찾는다. 하지만 백만 건이 넘는 계정에 모두 로딩해서 처리하는 건 많은 소요 시간을 필요로 한다. 계정 아이디에 따라 이를 N개의 그룹으로 나누고, 각 그룹을 로딩해서 동시에 처리하도록 병렬 쓰레딩을 도입한다.
어차피 전체 계정들을 모두 로딩해야했기 때문에 이메일 통보 기능과 휴면화 기능을 2개의 배치 작업에서 1개의 배치 작업으로 합친다.
전체 데이터 셋과 유사한 환경을 구성하고, 테스트를 해보니 6시간이면 배치 작업이 성공적으로 완료됐다. 이제 라이브 서비스에서 실제로 배치를 실행할 시점이다.
테스트 환경과 달리 라이브 환경은 계정 테이블에 대한 다양한 조회와 변경이 존재하기 때문에 6시간 보다 완료 시간이 2시간 더 걸렸다. 하지만 24시간내에 작업이 완료됐기 때문에 ActivityLogger 서비스의 도입은 성공적으로 마무리가 됐다. 굿!!
성공적인 사업의 확장과 MSA의 도입으로 조직과 서비스 시스템들은 수평적인 확장을 통해 안정적인 서비스를 제공한다.
가입자 증가로 휴면 처리 시간이 점차 오래 걸린다. 12시간
과정에서
하루안에 휴면 처리 배치가 완료되어야 하지만 이대로 두면 하루를 넘길 것이 분명하다. 계정 데이터에 대한 그룹을 세분화하고, 추가 장비들을 도입해서 병렬화를 높이는 것도 방법이긴 하지만 과도한 조회로 인해 계정 테이블에 무리를 주는 건 그닥 올바른 방법으로 보이지 않는다.
MSA 적용 전/후의 휴면 계정 처리 시스템이 갖는 가장 큰 차이점은 대상 계정을 추출하는 방식이다. MSA 적용 이전의 Monolithic 시스템 상황에서는 DBMS를 통해 전체 계정을 조회했다. 이후에는 직접 전체 계정을 조회하는 방식이 적용됐다. 방식의 차이가 있긴 하지만 모두 전체 계정을 조회한다는 점에는 차이가 없다. 바꿔 이야기하면 두 방식 모두 가입자가 늘어나는 상황에서는 모두 문제를 가질 수 밖에는 없게 된다.
우리가 해야할 문제를 다시 한번 짚어보자. 계정의 휴면화가 진행되는 과정을 살펴보면 1년이 되기 한 달 전에 계정의 소유주에게 알림을 주고, 1년이 경과한 시점에 휴면화를 처리한다. 즉 시간의 흐름에 따라 발생하는 이벤트다. 그리고 꼭 전체 계정을 대상으로 해야할 작업이 아니라 이 조건은 특정 계정에 관련된 이슈라고 정의할 수 있다.
문제를 이렇게 다시 정리해보니, 계정을 시간 조건에 의한 State Machine으로 간주하면 쉬운 해결 방안을 찾을 수 있다. 즉 위 조건에 따르면 다음과 같은 계정의 상태 전이가 이뤄진다.
NOTIFIED 혹은 DORMANTED 상태에서 계정에 Activity가 발생했다면, 당연히 ACTIVE 상태로 변경된다. 그리고 각각의 상태 변화가 발생하는 시점에서 필요한 작업들을 해주면 된다. 예를 들어 이메일을 발송하거나 계정의 개인 정보를 분리된 데이터베이스로 옮기는 작업들이 이에 속한다.
이렇게 정리되면 계정의 상태 변화를 발생시킬 수 있는 도구만 있으면 된다. 그리고 생각외로 이런 기능을 지원해주는 Repository들을 손쉽게 찾아볼 수 있다.
휴면 계정 처리 작업에서 계정을 시간을 조건으로 한 State Machine으로 정의하고 보니, 계정 테이블을 직접 연동하는 것이 아니라 휴면 프로세스를 위한 State Machine용 repository를 만들어버리는데 훨씬 더 깔끔한 접근 방법이다. 이런 식으로 방향을 잡으니 아예 휴면 계정을 위한 별도의 마이크로 서비스를 만드는게 더 효과적이다. 그래서 다음과 같은 방식으로 휴면 계정 처리 서비스의 아키텍쳐와 도구들을 잡았다.
이와 같은 구조로 변경되면 앞서 이야기했던 배치 작업이 없어진다. 시간의 흐름에 따른 개별 계정의 상태 변화는 DynamoDB와 ActivityLogger 서비스에 의해 실시간으로 처리된다. 더 이상 배치 작업이 하루 안에 마무리 될지 가지고 조바심내지 않아도 된다.
마이크로서비스 아키텍처는 서비스를 제공하는 환경을 크게 탈바꿈시켰다. 개발된 기능을 배포하는 시간을 크게 줄였을 뿐만 아니라 서비스의 독립성과 빠른 배포 주기를 기본 사상으로 가지고 있기 때문이다. 이를 충실히만 따른다면 빠른 피드백 사이클을 갖는 서비스의 개발과 유지가 가능하다.
하지만 모든 것에는 장단이 있기 마련이다. 때문에 모든 Monolithic 어플리케이션을 악의 축으로 보고, 이를 MSA화 하는 것은 상당한 위험을 내포하고 있다. 실제 변화를 꾀하기 전에 단기적으로 발생하는 손익도 반드시 고려해야한다. 이 글에서 이야기한 것처럼 예기치 않은 부작용이 발생할 수 있으며 관련된 추가 비용이 발생한다.
MSA를 효과적으로 반영하기 위해서는 상황에 맞는 적절한 도구들을 활용해야 한다. 휴면 계정용 서비스를 구현하는데는 AWS DynamoDB라는 도구를 이용해 시간에 따른 이벤트를 활용할 수 있었다. 물론 DynamoDB도 Expiration이라는 것을 정확하게 체크하지는 못한다. 해당 시간이 지난 후 4시간 안에는 지워진다지 정각에 지워지는건 아니다. 하지만 휴면 계정을 실행하는데 10분 ~ 20분의 차이는 서비스의 동작에 영향을 미치지 않는다.
마이크로서비스는 기능에 집중하기 때문에 해당 기능에 최적화된 도구를 사용할 수 있느냐 없느냐에 따라 서비스의 효율성이 좌우된다. MSA 환경에서 아키텍트는 특정 도구만 고집할 것이 아니라 다양한 도구들이 어떤 특성을 가지고 있고, 상황에 따라 유연하게 도구들이 사용될 수 있도록 가이드할 수 있어야 한다. 물론 어느 한 사람이 현재의 도구나 최신 기술들을 모두 알기란 불가능하고 또 그럴 필요도 없다. 개념이면 충분하다. 그럼 활용할 수 있는 시점에 도구들을 찾아내기만 하면 된다.
무엇보다도 중요한 점은 하나의 틀에 얽매이지 않는 자세가 중요하다. MSA가 아무리 좋다고 하지만, 본인이 있는 환경에 어울리지 않는다면 사용하지 않는 용기도 가지고 있어야 한다. 좋은 개발자 혹은 테크 리더가 보여줘야 할 태도중에는 항상 최신이 아닌 최선을 위해 최신 기술을 미룰줄도 알아야 하는게 아닐까 싶다.
– 끝 –