스토리 홈

인터뷰

피드

뉴스

조회수 1159

[맛있는 인터뷰 1] 잔디의 든든한 리베로, 백엔드(Back-end) 개발자 John을 만나다

[맛있는 인터뷰 1] 잔디의 든든한 리베로, 백엔드(Back-end) 개발자 John을 만나다                                    잔디의 든든한 수문장, John         스타트업(Startup)의 경우, 구성원들과 회사가 그 운명을 같이하는 것 같다.         개개인의 발전이 곧 회사의 발전으로 이루어지기 때문이다.           – John Kang, 잔디 개발팀편집자 주: 잔디에는 현재 40명 가까운 구성원들이 일본, 대만, 한국 오피스에서 일하고 있습니다. 국적, 학력, 경험이 모두 다른 멤버들. 이들이 어떤 스토리를 갖고 잔디에 합류했는지, 잔디에서 무슨 일을하고 있는지 궁금해 하시는 분들이 많았습니다. 이에 잔디 블로그에서는 매주 1회 ‘맛있는 인터뷰’라는 인터뷰 시리즈로 기업용 사내 메신저 ‘잔디’를 만드는 사람들의 이야기를 다루고자 합니다. 인터뷰는 매주 선정된 인터뷰어와 인터뷰이가 1시간 동안 점심을 함께 하며 다양한 이야기를 나누며 진행됩니다. 인터뷰이에 대해 궁금한 점은 댓글 혹은 이메일([email protected])을 통해 문의 부탁드립니다.안녕하세요, John! 맛있는 인터뷰의 첫 대상자가 되셨어요. 오늘 저희가 먹을 ‘맛있는 메뉴’는 무엇인지 설명해주세요.– 생선구이 어떠세요? 고등어와 연어 요리가 맛있는 집이 국기원 쪽에 있는데요. 비즈니스 팀의 YJ가 버디런치*때 데리고 갔던 곳인데 테이스티로드에도 나오고 꽤 맛있어요.*버디런치(Buddy Lunch): 잔디에서는 매주 금요일 점심 제비뽑기를 통해 짝을 지어 점심을 먹는 버디런치를 실행 중이다                                맛있는 인터뷰 시작 전, 인증샷 한장~!자기소개 부탁드려요.– 잔디의 백엔드(Back-end)를 맡고 있는 John입니다. 잔디에 합류한 건 반년쯤 된 것 같네요. 2014년 9월에 합류했어요. 남중-남고-공대-군대-IT회사까지 소위 ‘솔로계의 엘리트 코스’를 밟고 있는 개발자입니다. 고향은 대구이구요, 서울말을 제 2외국어로 사용하고 있습니다. 회사에서는 서울말을 하고 있지만 고향 친구들을 만나면 자동으로 사투리가 나옵니다. (하하)잔디에는 어떻게 합류하시게 됐는지?– Justin(CTO)과 YB(COO)와 함께 패스트트랙에서 창업 관련 수업을 들었어요. 그때 Justin이 농담처럼 나중에 함께 일하자 했는데 정말 이렇게 부를 줄 몰랐네요.잔디의 어떤 점에 이끌리셨나요?– 잔디라는 서비스도 매력적이었고, 함께 일할 사람들도 매력적이었어요. 개발하면서 직접 만들어보면 재미있겠다고 생각을 한 것이 있었는데 잔디가 바로 그런 서비스였어요. 게다가 함께 일할 사람들이 너무 좋았어요. 프로덕트 아이디어도 중요하지만 함께 일할 동료도 정말 중요하다고 생각해요.  몇 년 전 사업을 구상했던 적이 있는데 아이템에 대한 이견차이로 결국 무산되었던 경험이 있어요. 그 당시 연애하다 헤어진 것과 맞먹는 상실을 겪었는데요. 이런 경험이 있다 보니 뜻이 맞는 동료들이 중요하구나를 뼈저리게 느꼈어요.잔디에서의 역할이 백엔드라 하셨는데 조금 더 자세히 설명해 주실래요?– 용어가 어렵죠? 제가 하는 백엔드 업무는 사용자가 직접 눈으로 보거나 경험하는 부분이 아닌 그 뒤의 처리 과정을 담당하는 일이에요.눈에 보이지 않는 부분이요?– 쉽게 말하면 잔디를 통해 메세지를 보내면 그게 끝이 아니거든요. 메세지를 서버에 저장하고 처리해서 받는 사람에게 잘 전달되도록 해야 해요 그걸 가능하게 만드는 거죠. 잔디에선 MK와 함께 일을 하고 있어요. 업무 특성상, 안드로이드 개발자, 아이폰 개발자와도 함께 일하고 있죠.성과가 눈에 잘 보이지 않는 업무인 것 같아요.– 사실 프론트엔드(Front-end)에 비해 그런 편이죠. 백엔드와 프론트엔드 업무를 모두 해봤는데 각기 장단점이 있어요. 백엔드는 성과가 잘 안 보이는 반면 프론트엔드는 누구나 오류를 지적 할 수 있거든요.둘 다 경험이 있다고 하셨는데 어떤 쪽이 더 재미있으세요?– 어렵네요. 백엔드를 하다 지칠 땐 프론트엔드가 생각나고 프론트엔드 일을 하다 지칠 땐 백엔드가 생각나요. 지금은 백엔드에 만족하고 있어요.지금 하고 계신 업무를 좋아하시는 것 같단 생각이 드네요.– 그래 보여요? 사실 적성에 맞는 것 같아요. 모든 일이 그렇겠지만 프로그래밍은 꾸준히 발전하지 않으면 도태되기 십상이에요. 그러다 보니 계속해서 공부하게 되는 것 같아요. 저뿐만 아니라 잔디의 다른 개발자 분들도 꾸준히 공부를 하고 있고 스터디도 열심히 참여하고 있어요.바쁜 가운데 꾸준히 공부를 하신다니 인상적이네요.– Startup의 경우 구성원들과 회사가 그 운명을 같이하는 것 같아요. 개개인의 발전이 곧 회사의 발전으로 이루어지니까요. 그러니 열심히 할 수밖에 없죠.                                 오피스 근처 커피숍에서 커피 한잔!취미가 있으시다면?– 몸으로 하는 활동을 즐겨서 하고 있어요. 헬스, 조깅, 윈드서핑을 좋아해요. 한동안은 등산도 즐겨했지만 친구들이 하나둘 결혼하고 나니.. 점점 모임이 뜸해지더라고요. 일을 하면서 체력관리는 필수인 것 같아요. 어릴 땐 몰랐지만 체력관리를 하지 않으면 자기도 모르는 사이 배가 조금씩 조금씩 나오는 것 같아서..주로 혼자 하는 운동들이네요.– 정말 그렇네요? 앞으로 여유가 생긴다면 다이빙이나 서핑, 암벽 등반을 해보고 싶어요. 그리고 가능할진 모르겠지만 올해 안에 휴가를 내서 발리에 가서 서핑도 즐겨보고 싶고, 돈을 많이 벌면 레이싱도 해보고 싶어요.시간이 벌써 이렇게 됐네요. 끝으로 레이싱 얘기가 나와서 여쭤보는데 혹시 드림카가 있으신가요?– 페라리요. 잔디가 성공해야 드림카를 소유할 수 있겠죠?1시간 동안 진행된 ‘맛있는 인터뷰’를 통해 좀 더 자세히 알게된 John. 이번 인터뷰를 음식에 비유하자면 진하고 담백한 사골국 같았습니다. 개발자로서의 자부심과 일에 대한 애정이 남다른 John을 보며 조금이나마 개발팀을 머리에 그려볼 수 있었습니다. 앞으로 매 주 진행될 잔디 멤버들과의 다른 인터뷰들도 기대해주세요!#토스랩 #잔디 #JANDI #개발자 #백엔드 #개발팀 #팀원소개 #팀원인터뷰 #팀원자랑 #조직문화 #기업문화 #사내문화
조회수 1081

블록체인 진짜 하나도 모르는 디자이너의 독학일기(2)

1편에 이어 2편을 작성하기까지 참으로 많은 시간이 걸렸답니다. 물론 내용이 어려워서 이해하는 데 시간이 걸린 것도 있고... 어려운 만큼 귀차니즘이 강해져서 미루고 미룬 이유도 있지요.1편에선 블록체인이 왜 발생했는가! 에 대해서 말했어용. 혹시라도 못 보신 분들은 링크를 타고 슝 한 번 더 보고 와주시면 좋을 것 같습니다.https://brunch.co.kr/@roysday/199짧게 줄이자면, 결국 신뢰의 문제 때문이예요. 내가 널 뭘 믿고??? 라는 명제죠. 단순히 너와 나의 사이뿐만 아니라 정부나 기업 등이 해커나 서버폭발 등으로 탈탈 털리는 일을 보면서 우린 두려워진 거예요. 은행을 믿을 수 있어?? 보험사를 믿을 수 있어?? 국민연금 겁나 떼가는데 나중에 받을 수는 있는거야?? 등등...그래서 우린 누구도 깰 수 없고 변하지 않고 삭제도 되지 않는 강력한 '장부'를 만들고 싶었던 거예요. 그래서 생각해낸 가장 좋은 방법이 바로 다수에게 뿌리는 거였죠. 하지만 우린 이런 궁금증이 생겨요. 다수라구??...누가 참여하는데?? 내 컴퓨터엔 블록체인 같은 게 없는데??사실 이 부분을 이해하기가 진짜 어려웠어요. 아니 페이스북에 투표참여나 주식시장같이 '내가 이걸 산다! 투표한다! 동의한다! 클릭~!' 이런 식의 동작이 없잖아요. 그런데 어떻게 내가 동의를 했는지 안했는지 내 장부에 뭐가 언제 어떻게 기록된다는 거야??....는 궁금증이 생기는 거죠.그래서 오늘은 이 과정을 쉽게 정리해보려고 해용 :) 혹시 틀린 부분이 있다면 꼭!! 댓글로 남겨주세요!!1. 컴퓨터에게 말을 걸어보자.지금 컴퓨터를 켜고 이렇게 외쳐보세요. "윙가르디움 레비오싸."네, 아무일도 일어나지 않았어요. 혹시 무슨 일이 일어나셨다면 소름이네요. 컴퓨터는 마법주문이나 우리의 감정이나 목소리나 표정을 인식하지 못해요.(물론 요즘엔 이걸 가능하게 만들고 있어요. 놀라워요. 하지마 마법주문은 좀 시간이 걸릴 것 같아요.) 일본은 일본어를 쓰고 중국은 중국어를 쓰고 스페인은 스페인어를 써요. 컴퓨터는 2진법을 써요. 얘네들은 0 아니면 1이라는 원시적인 언어를 쓰고 있어요. 물론 인간도 아주아주 오래전엔 2진법으로 언어를 말했어요. 쿼스랜드는 원시인들은 'a(아)'와 'o(오)' 만을 사용해서 숫자를 표현했다고 해요. 아, 오, 아오아, 오아오아..등으로 말이죠. 컴퓨터는 이처럼 0와 1로 이루어진 신호들을 통해 소통해요. 그러니 우리가 컴퓨터에게 말을 걸고싶다면 2진법으로 0과 1을 마구마구 적어줘야 해요.2. 컴퓨터의 언어를 만들었졍.근데 0과 1로만 말을 걸다보니 도대체 눈이 아프고 헷갈려서 너무 어려운 거예요. 그래서 규칙을 만들었어요.A = 100 0001B = 100 0010C = 100 0011D = 100 0100...이런식으로 알파벳이나 기호, 한글 등등을 컴퓨터가 이해할 수 있는 신호와 대응시켰어요. 그래서 나온 게 컴퓨터 언어죠. 오늘 날 코딩이라고 불리는 그것들은 결국 컴퓨터의 말로 이렇게해라 저렇게 해라 명령을 내리는 거예요. 컴퓨터는 그 명령에 의해 이런저런 일들을 처리해요. 이걸 누르면 = 저 페이지로 넘어가게 해.이곳을 채우면 = 다음 칸을 적을 수 있게 해.여길 클릭하면 = 파란색으로 바뀌게 만들어줘.등등 뭔갈 하면 = 결과가 등장하는 거죠. 신기하죠? 네 저도 신기해요. 이렇게 명령어를 입력하면 결과가 짜짠.3. 규칙을 만들 수 있게 되었엉.컴퓨터는 논리에 의해서 움직여요. 뭔가를 누르면 - 계산하고 - 0이면 안하고, 1이면 해요. 사실 되게 단순하게도 '한다/안한다' 로 명확하게 움직여요. 이렇게 명확하기 때문에 사람의 목숨을 담보로 하는 수많은 것들을 만드는 거예요. 비행기도 그렇고, 인공위성, 놀이기구, 자동차 등등... 컴퓨터가 기분따라 오늘은 왠지 일하기 싫어서 땡깡이나 부려버리면 그냥 다 죽는 거잖아요. (물론 가끔 파랗게 질려서 멍청댕청해질 때가 있긴 하지만...)결정장애가 없는 특성 때문에 컴퓨터는 한 번 규칙을 정해주면 그렇게 계속 움직여요. 이런 점에서 보면 인간과 컴퓨터의 가장 큰 특징 중 하나가 '갈등' 이 아닐까 싶어요. 결정장애가 있으신 분들은 엄청 인간적인 매력을 지니신 거예요. 블록체인은 '규칙'이예요. 변하지 않고 계속 그대로 움직이는 규칙이죠.규칙을 컴퓨터에게 명령하는 거예요. 이렇게 하면 이렇게 처리해!~ 알았지? 하고 명령하는 거죠. 이 코드(=명령어)를 누가 짜요? 그렇죠 그걸 블록체인 회사에 있는 개발자님들이 만드는 거예요. 그러니 어떤 블록체인 코드가 만들어지면 처음엔 그 회사 컴퓨터에만 있을 거예요. 4. 사람들을 모아보쟈.명령어를 만들긴 만들었는데, 여튼 이제 돈을 벌어야 하잖아요. 회사니까. 많은 사람들이 우리가 만든 블록체인을 이용해줬으면 좋겠어요. 그래서 사람들을 모아야겠단 생각을 했어요. 사람들에게 막 알리기 시작했어요.블록체인은 다수의 사람들이 이용해야 의미가 있어요. 꼴랑 2명만 쓰고있으면 그 중 한명의 컴터만 털어버려도 장부를 조작할 수 있잖아요. 하지만 수백, 수천만명이 블록체인에 참여하고 있다면 얘기가 달라지죠. 그 많은 사람들의 컴터를 한꺼번에 해킹할 순 없으니까요. 그래서 사람이 많으면 많을수록 블록체인은 튼튼해져요.5. 블록을 만들면 보상을 줄께!가장 단순하고 간단한 방법은 누군가가 블록을 만들도록 하는 거예요. 블록체인은 블록이 우르르르 붙어있다는 소린데, 그 블록이란 건 사실 눈에 보이는 택배박스가 아니라 손으로 적는 기록과 같아요. 롤링페이퍼 아시죠? 딱 그런 느낌인거예요. 돌아가면서 나의 기록을 블록으로 만들어서 열차놀이를 하는거죠. 그리고 블록을 만들면 그에 대한 보상으로 무언갈 주는 거예요! 대부분 그 보상이 바로 암호화폐와 같은 것들이예요. 우린 이걸 '채굴한다.' 라고들 하죠. 열심히 노동했으니 보상을 주는 거예요.6. 블록을 어떻게 만들어? 채굴!그럼 어떻게 블록을 만들까용. 음 생각해봐요. 누구나 그냥 노트북만 있어도 블록을 만들 수 있다면 물론 순식간에 블록들이 엄청나게 만들어져서 온세상 온누리에 우리 블록체인이 아름답게 꽃피긴 하겠지만....'보상'을 줘야하는 걸 생각해보면 소름이 돋을 거에요. 더군다나 화폐의 가치가 있는 것을 만드는 데 아무나 10초만에 만들 수 있다고 하면 이건 복사기에 지폐를 위조해서 그냥 마구 쓸 수 있는 것과 비슷해요. 그래서 블록을 만드는 과정은 어려워야 해요. 개발자들은 그래서 사람들이 엄청 고민을 해야만 풀 수 있는 문제를 명령어로 만들었어요. 그리고 그걸 풀면 블록이 완성되고 보상을 받는 거예요. 물론 종이와 펜으로 푸는 건 아니예요. 인터넷에 떠돌아다니는 '이거 풀면 아이큐150 이상임' 이런 문제와 비슷하긴 하지만....이건 사람이 직접 푸는게 아니라 컴퓨터가 푸는 거에요. 예전에 막 그래픽카드가 없어서 난리가 났다..PC방에서 그래픽카드만 훔쳐갔다더라..이런 뉴스가 한참 떴었잖아요. 맞아요. 마치 영화에나 나올법한 슈퍼컴퓨터같이 엄청나게 엄청난 컴퓨터들을 잔뜩 가져다놓고 계산을 시키는 거예요. 사람은 그냥 엔터만 누르고 가만히 있으면 돼요. 고생은 컴퓨터가 하니까요. 컴퓨터는 미친듯이 계산을 해요. 모터가 탈 정도로 고생을 하죠. 그리고 마침내 문제가 풀리면 짜잔!!! 블록이 완성되었어요!! 물론 블록이 완성이 되었는 지 어쩐지는 눈으로 보지 못해요. 하지만 문제가 풀면 블록이 생기도록 명령어를 짜놓았으니 생겼을 거예요. 컴터는 명확하니까요.(항상 이걸 전제로 해요.) 그리고 약속된 보상이 생겨요. 나에게 암호화폐가 뾱! 생겼어요. 빗썸이나 코인원같은 거래소에서 현금으로 바꿀 수 있도 있어요. 7. 쉬운 방법도 있어요.이렇게 수십대의 컴퓨터와 첨단 장비들이 있어야만 블록을 만들 수 있는 건 아니예요. 일반인들도 블록을 만들 수 있어요. 다만 쉬운 만큼 보상이 굉장히 작겠죠. 단순한 예로 '스팀잇'을 들 수 있어요. 스팀잇은 겉보기엔 브런치같이 그냥 주절주절 글이나 쓰는 플랫폼처럼 보이지만...사실 그건 훼이크예요. 스팀잇에 글을 쓰는 것 자체가 사실 블록을 만드는 것과 같아요. 그래서 그 보상으로 스팀을 주는 거예요. 그래서 정확히 얘기하면 '글을 쓰니 돈을 주더라!!' 가 아니라..'블록을 만드니 보상을 준다!' 가 맞는 거예요. 블록을 만드는 방식이 '콘텐츠' 일 뿐이죠.이처럼 블록을 만드는 방식은 결국 개발사가 정하기 나름이예요. 여행사진을 500장 올릴 때마다 블록을 생성하자! 라고 규칙을 만들면 그렇게 만들어져요. 그리고 보상을 받는거구요. 기부를 하면 블록이 만들어지게 하자! 라고 할 수도 있고하루에 1km씩 뛰어다니면 블록이 만들어지게 하자! 라고 할 수도 있어요.심지어 성인사이트에서 결제를 하면 블록이 만들어지게 할 수도 있어요. 실제로도 있더라구요.규칙은 만들면 되니까요. 그래서 다양한 프로젝트들이 만들어지고 블록체인 회사들이 각자 자신만의 방법으로 사람들을 모으고 있죠. 8. 하지만 사람들은 그 사실을 잘 몰라요.스팀잇에 접속해보신 분이 계신가요?? 사실 그곳은 능력자들 천지라서 다들 블록체인을 어느정도 알고 있는 사람들이 많지만.. 또 많은 사람들은 그런거에 상관없이 그냥 돈 준다니까 가입해서 글을 쓰고 있기도 해요. 사람들은 이게 블록인지 뭔지도 몰라요. 그냥 보상준다니까 열심히 뭘 쓰고 있는거에요.내가 블록을 만드는 걸 눈으로 볼 수도 없고 손에 잡히지도 않아요. 이 모든 건 그냥 컴퓨터가 처리하고 인터넷상에 떠돌아다니는 전기신호로만 존재할 뿐이예요. 우리는 겉으로 드러난 것들만을 보죠. 그래서 수많은 블록체인 회사들이 예쁘고 쉽고 접근하기 좋은 웹페이지를 만들거나 플랫폼을 만들어서 이런저런 활동을 하게 만드는 거예요. 사실 블록체인이 정말 널리고 널려서 이제 공인인증서 등등이 필요없어지게 될 지도 몰라요. 지금도 공인인증서는 폐지수순을 밟고 있고 은행의 인증절차도 간편해지고 있잖아요. 중요한 건 우린 그냥 '우왕 편하다~~' 라는 것만 인지할 뿐 이게 왜 편해졌는지는 관심이 없어요.맞아요. 우린 알게모르게 블록을 만들고 있을 수도 있어요. 당신의 컴퓨터에서 말이죠. 이미 당신은 블록체인에 참여한 거예요. 당신도 장부에 뭔가를 기록했고, 그 블록체인에 참여한 철수란 사람이 그 후에 또 뭔가를 적으면 당신의 컴퓨터에서도 그걸 인식할 수 있어요. 그래서 당신은 철수를 모르지만 당신의 컴퓨터는 철수를 알고 있어요.  이 때문에 P2P거래도 별 인증절차없이 이루어질 수 있는 거예요. 당신의 컴퓨터는 철수를 믿고있거든요. 정리해보면 블록체인은 규칙이예요. 코드로 이루어진 일종의 어떤 규칙이죠. 이걸 블록체인회사에서 만든다음자기들이 어느정도 지분을 가져가요. 자기들이 만들었으니 좀 가지고 있어야 할 거 아니예요. 주로 암호화폐의 형태겠죠.그리고 또 어느 정도는 채굴자들을 모아서 채굴을 시켜요. 대부분은 장비가 충만하신 전문채굴자님들이겠죠. 이 분들은 적극적으로 블록을 만들어내고 많은 보상을 가져가요. 이 때의 보상도 대부분 암호화폐겠죠.나머지는 쪼끄마한 우리들이에요. 우린 그게 뭔진 잘 모르지만 그냥 재밌으니까 막 활동을 해요. 그러면서 블록들을 만들어내요. 우리도 블록체인을 튼튼하게 만드는 역할을 해주었으니 일종의 작은 보상들을 받아요. 이것도 암호화폐겠죠.이렇게 블록체인에 참여하는 컴퓨터수가 많아지면서 블록체인은 더 튼튼해지고 견고해져요. 그리고 겁나 빠르고 편해서 많은사람들이 쓰게 된다면....그게 추후엔 어떤 핵심플랫폼이 될 수도 있겠죠?...다들 그걸 꿈꾸고 열심히 블록체인 코드를 만들고 있는 거예요.여기서 궁금한 게 생겼어요. 그럼... 이런 블록체인 회사들은 돈을 어떻게 버는 걸까요???.... 생각해보면 개발비용이나...홍보나 인건비나..얘네들도 돈이 필요할 텐데 당장 가상화폐는 돈이 안되요. 이제 갓 태어난 화폐는 가치가 거의 없을 거예요. 그러니 마구 가상화폐를 만들어서 팔아도 그건 의미가 없어요. 이분들의 수익은 도대체 어디에서 나는 건지 그게 궁금해졌어요.그래서 3편에선 블록체인 회사들은 뭐 먹고 사는건지 알아보도록 하겠어요 :)어휴 힘들어..이제 저도 규칙에 의해서 자야겠어요.새벽2시가 되면 = 잠을 자라.(규칙)
조회수 1373

소프트웨어 엔지니어 용현님을 소개합니다

Read in English같이 일하고 있는 직장 동료들에 대해 얼마나 알고 계시나요? 엑스브레인처럼 작은 팀의 경우에는 함께하는 한 분 한 분이 팀 전체 분위기에 끼치는 영향이 상당하답니다. 또한, 머신러닝 툴 ‘다리아’로 저희가 꿈꾸는 데이터 사이언스계의 변혁을 일으키려면, 이를 위해 일하는 팀 또한 서로 잘 알고, 협력할 줄 알아야겠죠.각각 개성이 넘치지만, 서로 모여 엑스브레인의 매일매일을 풍족하고 즐겁게 만들어가는 팀을 소개합니다! 각 멤버들의 일상과 엑스브레인에서의 직무에 대해서도 알아보고, 또 뉴욕타임즈에 실린 “상대방과 사랑에 빠질 수 있는 36가지 질문” 중 직장 동료에게 할 수 있을 만한, 가장 흥미로운 질문들을 추려서 진행한 인터뷰를 통해 엑스브레인 팀 멤버 개개인의 색다른 매력을 만나보세요.(그렇다고 진짜로 사랑에 빠지시면 곤란합니다…)올해 8월에 합류하신 용현님은 종민님과 함께 다리아의 소프트웨어를 책임지고 있는 엑스브레인의 엔지니어이십니다. 자칭 노잼이라고 하시지만, 사실 VR의 미래와 축구에 관심이 정말 많으신 분이죠. 가끔 모니터에 코드 대신 축구게임을 띄워놓고 계신 걸 목격하기도 했답니다…액티브한 엑스브레인을 지향하는 용현님을 만나보세요!창밖을 바라보는 용현님은 무슨 생각을 하는걸까요…(궁금)안녕하세요 용현님! 엑스브레인에서의 용현님의 역할에 대해서 얘기해주세요용현: 저는 소프트웨어 엔지니어로서 종민님과 함께 소프트웨어 인프라를 개발하고 테스팅하는 역할을 하고 있습니다.용현님의 엑스브레인에서의 하루 일과는 어떻게 되나요?용현: 요즘은 점심 때쯤 나와서, 그때그때 관련된일을 합니다. 오늘은 MS SQL이라는 다른 데이터베이스에서 데이터를 가져오는 테스팅을 했습니다. 가끔은 산책을 즐기기도 하고, 주로 저녁 식사 후 작업을 하다가 퇴근합니다.용현님의 직무 중 가장 즐기는 일은?용현: 머신러닝 모듈을 클라우드 시스템에 분산처리 하기 위해서는 수진님이 개발하신 걸 스파크로 바꾸고, 코드를 보고 변형해가면서 분석해 보는게 제일 재밌는 것 같아요.반대로, 가장 하기 싫은 일은?용현: 시스템을 테스트하기 위해 환경을 구축하는 일이 가장 어렵습니다. 가끔 지시대로 해도 잘 안되는 경우가 발생하거든요.용현님 책상에 있는 물건 중 용현님을 가장 잘 대변한다고 생각하는 아이템은?용현: 책상에 있는게 별로 없어서…아마 랩탑이겠죠? 입사할 때 회사에서 제공해준 거대한 랩탑.“거대한 랩탑"어떤 계기로 소프트웨어 엔지니어가 되셨는지?용현: 원래는 전공으로 역사를 정했는데, 주변의 컴퓨터 공부를 하는 사람들을 보면서, 직접 결과물을 고안해내고 만드는 과정이 신기했어요. 내가 생각하는 대로 아웃풋을 만들 수 있다는 점이 매력적이어서요.왜 엑스브레인인가요?용현: 일단 신입 개발자로서 아직 개발되고 있는 단계의 제품 개발에 합류할 수 있는 기회를 얻고 싶었어요. ‘다리아’ 개발 과정을 초기부터 일련으로 지켜볼 수 있다는게 신기하고. 또 프로그래밍 공부를 늦게 시작한 편이라 수학적인 배경이 부족하다고 느낀 적이 많았는데, 작업을 하면서 그런 쪽으로도 많이 배울 수 있어서 좋고요.팀 내 가장 최근 합류한 멤버 중 하나로서, 용현님이 생각하시는 엑스브레인의 비전을 말해주세요.용현: 엑셀처럼 일상에서 쉽게 접하고 쓸 수 있는 머신러닝 툴의 대명사가 되는게 목표이지 않을까요?작업할 때 주로 듣는 플레이리스트 top 3 공유해 주세요용현: 코딩할 때는 주로 EDM을 듣는 편입니다. 집중이 잘되기도 하고요. Hardwell On Air이라는 스테이션을 자주 듣습니다. 최근에 나온 에픽하이 트랙도 자주 듣고 있고요.씨네마 소사이어티 때 추천하고 싶은 영화가 있다면?용현: 와치맨 (2009). 빌런이기도 한 주인공 로셱이 매우 매력적이고, 재미있습니다.10년 뒤 지금, 용현님은 어떤 모습일까요?용현: 일하는 건…지금의 모습만 유지되었으면 좋겠네요. 데드라인에 크게 쫓기지 않고, 공부도 하면서 자기계발할 시간도 갖고, 시간이 나면 친구들과 축구도 할 수 있는 사람이 되어 있었으면 좋겠어요.이 세상의 어떤 사람과도 저녁 식사를 할 수 있다면, 누구와 같이 먹고 싶나요?용현: 딱히 생각이 나지는 않지만… 주커버그? 세상에 대한 다양한 비전이 있는 거 같아서요.만약에 한 명의 엑스브레인 멤버와 식사를 해야 한다면 누구와 하실 건가요?용현: 새로 오신 정갑님과 친해질 겸 식사 같이 하고 싶네요. 이야기도 잘 하시는 것 같고 재밌을 것 같아요.유명해지고 싶나요? 어떤 방법으로요?용현: 아니요.용현님에게 “완벽한” 날이란 어떤 날인가요?용현: 일과를 끝내고 침대에 들어가서, 내일의 일을 걱정하지 않고 잠들 수 있을 정도로 보람찬 하루일 것 같아요.90살까지 살 수 있고 마지막 60년을 서른 살의 마음, 혹은 서른 살의 몸으로 살 수 있다고 해봅시다. 몸과 마음 중 어느 쪽을 택할 건가요?용현: 30살의 몸이요. 마음이란게 젊을수록 꼭 좋은 건 아닌 거 같아요.용현님의 인생에서 가장 감사하게 생각하는 것은 무엇인가요?용현: 이때까지 하고 싶은 것, 배우고 싶은 것을 할 수 있었던 배경이 아닐까요? 또 전공을 바꾼다거나 진로를 선택할 때 독립적으로 정할 수 있었던 부분…그런 특권에 감사하고 있습니다.내일 아침 눈을 떴을 때 어떤 능력이나 특성을 가지게 된다면 어떤 것이었으면 좋겠어요?용현: 하려고 마음 먹은 일을 끝까지 해나가는 행동력, 추진력!오랫동안 하고 싶었던 일이 있나요? 왜 그 일을 하지 않았나요?용현: 요리를 늘 배우고 싶었어요. 학교 다닐 때는 기숙사에 살아서 그럴 기회가 없었고.. 지금이라도 시작하고 싶네요 :)지금까지 용현님 인생에서 가장 잘해낸 일은 무엇인가요?용현: 무언갈 배우는데 최선을 다한 것일 것 같아요..학교 내에서든 밖에서든.엑스브레인에서 가장 기억에 남는 일이 있다면?용현: 주로 야외에서 했던 이벤트? “규원 산악회”라던지, 함께 축구한다던지… 팀빌딩도 되는 것 같고요.1년 뒤 갑자기 죽을 것이라는 사실을 알게 된다면 지금 용현님의 삶의 방식 중 어떤 걸 바꿀 건가요? 왜 그렇죠?용현: 요즘 푹 쉬지를 못했는데…잠을 더 많이 잘 것 같네요.상대방과 가까운 친구가 되기 위해 상대방이 나에 대해 알아야 할 것을 말해보세요.저는 성격이 무던한 편이라, 누구와도 잘 지내는 편입니다.혹시 농담의 대상으로 삼아서는 안 된다고 생각하는 것이 있다면 어떤 것들이 있을까요?용현: 약자에 관한 농담, 그리고 상대방의 약점에 관한 농담은 삼가야 된다고 봅니다 .내가 생각하는 엑스브레인의 엑기스는?용현: 자율, 배려, 배움….너무 진지한가요?#엑스브레인 #팀원소개 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑
조회수 2630

DevOps, 그 문화에 대해서...

개발 방법론이나 소프트웨어 개발과 관련된 은빛 탄환과도 같은 뉘앙스를 풍기는 접근법은 수없이 많았다. 이제는 최고의 화두로 떠오른 DevOps에 대해서 삐딱한 아키텍트의 생각으로 끄적거려 보자.주변에 DevOps를 지향하는 개발회사들이 많다. 그리고, DevOps를 무슨 완전체인 것처럼 소개하는 칼럼이나 글들도 많다. 그렇다면, DevOps의 정체는 무엇이며, 우리 회사, 우리 개발팀이나 운영팀은 그런 준비가 되어 있는 것인지에 대해서 생각해봐야 한다.사람들은 정말 DevOps가 어떤 의미이기에 사람들이 궁금해하고 있는 것일까?, 그리고. 과연 정말 내가 속한 조직과 팀이 DevOps를 지향할 수 있을까? DevOps에 대해서 삐딱한 아키텍트가 생각해보는 것이 이번 칼럼의 목적이다.DevOps는 모든 팀, 모든 회사, 모든 곳에 사용되는 만병통치약이 아니다.DevOps는 새로운 개념인가?Culture와 movement에 대해서 먼저 이야기를 시작하는 것이 맞을 듯하다. Culture는 어떤 한 국가나 집단의 문화와 같은 것을 의미한다. 그리고, movement는 어떤 움직임을 의미하는 것으로 여기서 사용되는 의미로는 사람들이 조직적으로 어떤 것을 벌리는 운동을 의미한다.일반적으로 문화란 어떤 옷, 음악, 형태를 가진 조형물 등을 포괄하는 것으로 무형, 유형의 것을 모두 포함하는 것이 문화라고 할 수 있다.그리고, 이러한 문화는 해당 문명과 조직, 사회의 모든 것을 표현하고 있는 것이며, 그것에 대비하여 문화라는 형태를 통해서 표현한다. 그래서, 소프트웨어 개발의 조직이나 기업에서도 자체적인 개발자 문화라는 것이 존재하고 있다. 이는, 일반적으로 각 회사별로 그 형태나 상황, 사람들의 모습, 역사적인 배경과 발전과정을 통하고, 어떤 사람들이 그 조직을 거쳐갔느냐에 따라서 많은 부분에 있어서, 개발자들의 문화는 매우 다르다고 할 수 있다.이처럼, 개발자 문화의 영향으로 소프트웨어 개발 방법론과 같은 무형의 것부터, 실제 산출물, 개발 소스와 같은 실제 눈에 보이는 것까지 개발자 문화란 눈에 보이는 것과 눈에 보이지 않는 것을 모두 포함한다고 할 수 있다.이런 개발자 문화를 언급하기 전에, 개발자들의 운동과 운동을 위한 선언과 같은 것에 대해서 알아보자. 그중에서도 movement를 먼저 살펴보자. 개발자들 커뮤니티와 개발자들의 요즘 철학적인 움직임은 ‘요구사항’ 변동에 대해서 이제 관대한 생각을 가지기 시작했다고 볼 수 있다.어차피, 요동치는 요구사항에 대해서 ‘완결된 요구사항’이 나올 것이라고 기대하지 않고, 요구사항은 사랑하는 애인의 변덕스러운 마음이라는 생각을 가지기 시작한 것이 DevOps의 원칙적인 기본 생각의 변화라고 먼저 이야기를 하고 싶다.이제, 개발자들은 요동치는 사람들의 마음이나 사회적인 변덕을 소프트웨어로 반영하는 것을 매우 당연스럽고 자연스러운 과정이라고 인지하기 시작한 것이라고 볼 수 있다. 이처럼 기본적으로 요구사항이 변덕스러운 기획자나 고객의 마음이 당연한 것이라고 생각한다면, 오히려, 더 행복한 개발이 가능하도록 기준이나 계획을 잡을 수 있는 것 아닐까?이것이 DevOps의 개념 전환의 기본적인 개념이라고 볼 수 있다. 오히려. 처음부터 요구사항이 잘 정해졌고, 더 이상 변하지 않을 것이라고 거짓말을 하고 있는 기획자와 고객들의 마음속에 변덕스러운 변화에 대해서 이제는 관대한 개발자가 되려는 마음을 가진 것이라고 생각할 수 있다고 소프트웨어 개발자들은 이해하기 시작한 것이다.DevOps는 이러한 마음가짐의 변화와 movement가 먼저 필요하다. 기존의 개발 방법론이나 개발 문화에서 정의하려고 하였던, 뜬구름 잡는 ‘요구사항 명세’는 어차피 불가능한 것이니까, 그 부분을 매우 관대하게 받아들이고자 변화의 마음을 가지게 된 것이라고 생각한다. 그래서, 실제 고객을 만족시키는 요리사의 마음에다가 고객의 마음을 좀 더 가까이에서 이야기를 나눌 수 있는 웨이터의 마음을 가지고 시작해야 한다고 설명하는 것이 더 현명할 수 있다.이러한 변화의 요소에는 다음과 같은 개발자들이 두려워하는 몇 가지 요소들에 대해서 이제는 정말 명확하게 이야기할 수 있기 때문에 DevOps는 가능하다고 생각한다.DevOps의 내면에 깔려 있는 소프트웨어 개발자들의 두려움을 먼저 알아야 DevOps의 기본적인 원칙에 좀 더 접근할 수 있다. 그것은 다음에 나열된 내용들은 일반적으로 소프트웨어 개발자들이 어려워하는 것들이다.1.  소프트웨어를 솔루션 형태의 디자인으로 만드는 것은 정말 어렵다개발자들은 솔루션을 만들고 그것을 디자인하고 설계, 구현한다는 것은 정말 어려운 것이라고 인지하기 시작하였다. 솔루션을 만들고, 어떤 문제를 해결한다는 것은 정말 험난하고 고된 일이라고 이미 인지하였다.2.  테스트 케이스를 작성한다는 것은 정말 어렵다수많은 사용자의 환경을 인지하고, 그것에 대응하는 완벽한 테스트는 불가능하다는 것 또한 개발자들은 인지하였다. 그리고, 그 테스트를 만들기 위해서 쥐어뜯었던 머리카락과 수많은 시간들에 대해서 완전이란 불가능하다는 것을 인지한 것이다.3.  개발 관련 문서작성 또한 매우 어려운 것이다개발자들 간에 상호 소통하기 위한 문서의 작성과 다이어그램과 모델을 만든다는 것 또한 정말 어려운 일이다. 또한, 그것을 표준이나 변화해가는 기술적인 요청과 반영 내용을 모두 담는다는 것은 정말 어려운 일이라고 인지하였다.4.  개발자 자신이 동의하지 않는 기능 구현을 허구 헌 날 해야 한다는 것간혹이 아니라, 상당 부분 발생하는 동의하지 않는, 쓸모없다고 생각하는 기능 구현에 매달리고 있는 현실에 대해서 이제는 약간은 무덤덤하게 대응할 수 있는 개발자들의 마음가짐은 정말 관해하게 변화하였다.5.  다른 사람이 작성한 코드를 다루는 것인 매우 당연하다는 것생각 이상으로 다른 사람의 코드와 프레임워크에 가두어진 상태로 프로그래밍을 해야 한다는 것에 대해서 학교에서는 가르치지 않았다는 것을 매우 두려워하고, 원망한다. 타인이 만들어 놓은 코드에 대해서 읽는 방법에 대해서 가르쳐 주지 않은 교수님이 원망스러울 뿐이다.6.  고객과 같이 비전문가와 커뮤니케이션해야 한다는 것비전문가와 소통하는 방법에 대해서 아무도 가르쳐주지 않았다. 사실은 그들과 소통하고 그들을 설득하는 것이 최선의 방법인데, 왜? 그들과 소통하는 방법은 학교에서 가르치고 있지 않는가? 혹시. 교수님들도 그것을 포기한 것 아닌가 하는 의심이 든다? 그러한 마음이 생기기 시작하였고, 과거의 방법론이나 공학에 대해서 의심을 하기 시작하였다.7.  업무 완료에 필요한 시간 예측은 필수가 되었다는 것기능 단위의 시간 예측과 일정에 대해서 ‘감’이 필요하다는 것은 실제 현업에 나와서야 만 가능하다는 것을 이야기해준 선배와 교수가 없었다는 점도 실제 현업의 초기에 어려움을 느끼는 부분들이다.8.  업무의 우선순위와 작업 할당이 애매하다는 것도대체 누가 결정하는가? 그 순서에 대해서 아무도 모른다.9.  이름을 만들고, 이름과 의미를 부여한다는 것은 매우 어렵다는 것그냥, X, Y, I, j, k를 부여하면 안 된다고 하는데, 생각 이상으로 붙여야 할 이름과 규칙들이 너무도 많다.이처럼, 소프트웨어 개발이 어려워지고 두려워지는 개발자들보다 더 어려운 것도 있다는 사실을 소프트웨어 개발자들은 경험으로 터득한다. 그것은 다음과 같은 상황이다. 그리고, 해결책도 없다는 점이다.위의 두려운 상황은 ‘단단한 마음’으로 이겨낼 수 있지만, 정마로, 다음의 상황들은 가능하면 소프트웨어 개발자들이 피하고 싶어 진다. 하지만, 우리가 지금 당장, 어제, 그리고 내일도 만날 수 있는 상황이다.1.  무능력한 경영진의 삽질2.  멍청한 동료 개발자의 어설픈 코드3.  특정 기술이 무슨 이유에서 쓰이는지도 모르고 강제로 배우거나 사용해야 하는 것4.  재미있어 시작한 개발일이 정말 반복적인 작업에 의해서 재미없어졌을 때5.  이제 쏟아지는 버그를 만나게 되었을 때하지만 가장 두려운 상황의 최고봉은 역시, ‘개발자는 고객과 대화를 나누는 것이 가장 두렵다’라는 것이 정답일 것이다. 그리고, 두려운 것은 동료와의 커뮤니케이션과 소통이다. 아마도, 이러한 고객과 동료들 사이에 있다면, 개발자는 당연한 것이지만. ‘개발하는 것이 행복하지 않다’라고 느끼는 것은 매우 당연할 것이다.여기서. DevOps는 출발한다.이렇게 ‘개발하지 않는 것이 불행한 개발일’을 하지 않게 하기 위한 일종의 movement라고 생각하면 된다.아이러니 하지만, 이러한 불행을 해결할 가장 좋은 방법은 행복의 최소 조건이나 개발자가 원하는 개발환경의 최소 조건을 만족하면 된다. 그것은 바로 자원(resource)이 충분한 환경을 만들면 가능하다. ‘돈’이 넉넉하면 부수적으로 대부분 따라오는 것들이다.하지만, 실제 개발일을 이런 환경에서 할 수 있는 방법은, ‘취미’로 개발일을 하는 경우에만 100% 만족할 수 있을 것이다. 취미는 최종 개발완룐일을 언제든지 뒤로 미룰 수 있기 때문에 ‘무한정의 리소스’를 투입할 수 있는 유일한 방법일 것이다.DevOps는 개발자가 행복하게 소프트웨어를 개발할 수 있는 환경을 만드는 것이 목표이다. 과거의 개발 방법론이나 문화, 운동들이 대부분 ‘소프트웨어 품질’을 위해서 개개인의 시간과 개개인의 능력 차이를 무시하고 진행되었다면, DevOps는 그 우선순위의 가장 높은 개념으로 ‘개발자의 행복’을 우선순위 위에 둔다.결론적으로 ‘개발자가 행복’하다면,자연스럽게 소프트웨어의 ‘품질’은 올라간다는 개념이다.물론, ‘행복’이 아니라, ‘시간 낭비’라는 단어와 ‘물자와 자원 낭비’라는 결코, 개발자는 행복하지 않을 것이다. 대부분의 개발자들은 ‘시간과 자원의 낭비’를 가장 싫어한다. DevOps는 기본적으로 개발자들을 신뢰해야 형성된다.DevOps는 소프트웨어 개발과 운영, 서비스의 효율적인 환경을 만들기 위해서 노력하는 개발 문화로써 간단하게 줄여서 설명하자면. ‘소비자, 사용자들의 서비스의 요구사항을 가장 빠르고 단순화하여 대응할 수 있는 신속한 서비스 지원 형태. 그리고, 그것을 지원하고 유지시켜주는 소프트웨어 개발 문화’라고 이야기할 수 있다. 그래서 Development / Operations를 합친 말이라고 본다.물론, 이렇게 만들어진 환경은 당연하지만 개발자를 ‘행복’하게 할 것이다.DevOps는 빠르고, 단순화, 신속함이라는 서비스 형태를 지향한다. 그리고, 그것을 지원하고 유지시켜주는 소프트웨어 개발 문화를 지향하고 있다. 실제, DevOps를 구현했다고 평가를 받고 있는 Netflix와 Flickr 등의 개발 성과물들은 정말 놀라울 정도로 효과적이다.1만 개 이상의 AWS 인스턴스를 불과 10여 명의 DevOps팀이 운영하고, 초당 4만 장 이상의 업로드 부하를 버티고. 자동화된 상태에서 하루 10회 이상의 배포본이 반영되는 매우 효과적인 개발과 운영이 접목된 환경을 만들어 낸다는 사실에 개발자 문화의 최신화 경향을 만들어 냈다.이렇든 엄청난 효율과 고속의 처리를 만들어 낸 것은 어떤 이유 때문에 가능한 것이었을까? 그리고, 이러한 DevOps의 성과물들은 일반적인 IT기업에서도 얻을 수 있는 환경일까? 가장 먼저 DevOps의 장점을 몇 가지 정리하고 넘어가자.DevOps의 장점을 서술한다면 다음의 3가지로 선언할 수 있다.1.  최소 인원으로의 개발과 운영이 가능한 환경을 지향한다2.  서비스의 배포와 운영이 자유롭고, 서비스가 매우 신속하고 빠르게 운영된다.3.  개발의 배포가 자동화되며, 그에 따라 고품질 서비스를 지향한다.자, 그렇다면. 가장 중요한 것은 이러한 DevOps는 내가 속한 조직에서 만들 수 있는 문화와 개발형 태인가? 대부분의 개발 조직에서는 이러한 것에 대해서 가장 궁금할 것이다. 결론부터 이야기하자면 DevOps가 가동되고, 개발 조직의 문화가 되려면 다음의 두 가지가 필수이다.1.  소프트웨어를 잘 만들어내는 개발자2.  잘 동작하도록 운영하는 운영자그리고, 이러한 두 가지의 조건을 만족시키기 위한 기본적인 환경적인 구성이 필요하다. 그것은 가장 먼저 소프트웨어 품질을 관리하는 제대로 된 품질관리 조직이 있어야 하며, 개발 조직이 빠르게 소프트웨어를 개발, 빌드, 테스트, 배포, 운영하게 할 수 있는 사이클을 신속하게 진행할 수 있는 개발환경을 갖추고 있어야 하고 업무 프로세스를 정의하고, 각 조직 간의 역할을 조율하는 프로세스들이 매우 자연스럽게 자동화되어지고 효율적으로 운영되고 있어야 한다. 그래야, ‘소프트웨어를 잘 만들어내는 개발자’와 ‘잘 동작하도록 운영하는 운용자’가 만들어지게 되고, 그 역할과 방법론이 효율적으로 가동되는 DevOps는 가동된다.DevOps의 원칙그렇다면, 이러한 DevOps을 세팅하고 구입하기 위해서 조직이 필요로 하는 비용적인 측면은 어떤 것들이 있을 것인지 가볍게 살펴보자. DevOps는 매우 큰 비용을 요구하는 것은 아니다. 다만, 그 비용이라는 것이 전반적으로 투자된 비용을 의미하는 것이지, 단기간에 투입되어 얻어지는 효과는 아니라는 점에 주목해야 한다.가장 먼저, 개발자들은 기능 개발과 결함의 수정 등의 변화를 얼마나 자주 일으키고 있는지 체크하고 이를 관리하거나, 관리할 수 있는 포인트를 개발자들에게 제공하고 있는가? 하는 측면이 가장 먼저라고 할 수 있다.두 번째는 운영자가 실제 서비스의 안전성과 성능의 향상을 위하여 취해지는 시스템 아키텍처 적인 변화에 대해서 얼마나 두려워하고 있으며, 이를 얼마나 수치화하여 관리하고있는지, 그리고. 그 선택을 할 수 있는지가 DevOps에 가장 중요한 측면이기도 하다.세 번째는 이러한 개발집단과 운영 집단에서 선택과 운영, 개발의 우선순위 등을 고르고 선택할 수 있는 ‘권한과 책임’이 주어지고 있느냐 하는 점이다.네 번째는 큰 조직, 큰 기업, 큰 프로세스의 운영 시에는 이러한 DevOps와 같은 콘셉트는 운영하기 매우 어렵다. 그러므로, 개발과 운영환경의 구분과 절차. 권한과 릴리즈 절차와 규칙 등에 대해서 얼마나 세분화하고 있는지, 그리고. 일에 대해서 얼마나 작은 규모로 산정하고 산출하고 있는지에 대해서도 정의되어야 한다.아쉽게도 DevOps를 구현하고 싶지만, 착각하고 있는 개발자 조직의 경우의 사례를 살펴보면 다음과 같은 실제 일들이 벌어진다고 볼 수 있다.1.  사용하지도 않는 기능을 도출하고, 이를 위하여 시간과 비용을 낭비하고 있는 경우2.  개발 후 버그를 찾기 위해서 테스트를 하고 있다고 프로세스를 정형화하는 일이다. 실제 DevOps를 지향하는 개발 조직의 경우에는 내부적으로 개발 단계에서 충분하게 품질을 고려하여 디자인되고 개발을 진행하려 노력한다.3.  예측을 위한 투자를 많이 하고 있는가?라는 질문에 소극적인 경우이다. 대부분은 그나마. 사건 발생 시에 빠르게 대처할 수 있는 환경이라고 가능한 구축하라고 권하는 경우가 태반이다.4.  소프트웨어 공학을 잘 못 받아들여 정말 중요한 지표에 집중해야 하는데, 너무 많은 지표를 도출하기 위하여 삽질을 하는 경우가 대표적인 착각되어진 개발 조직의 경우라고 볼 수 있다.DevOps을 좁게 보는 진정한 장점DevOps는 ‘잦은 배포’를 수행하면서, 잦은 릴리즈를 수행하고, 잦은 릴리즈를 통해서 위험을 하향 균등화 시키는 것이 주목적이라고 작게 정의할 수 있기도 하다. 그래서, 애자일과도 아주 잘 맞는다. TimeBox를 2주로 맞추거나 1.5주로 맞추고 배포를 진행하는 경우도 빈번하게 필자는 상황을 참조한다.하지만, 이러한 DevOps를 구현하는 데 있어서는 다음과 같은 최소한의 필요충분 요건이 필요하다.1.  잦은 개발과 버그 픽스가 가능한 개발자 환경을 구현하라2.  공유 소스 코드 버전 관리시스템도 없다면, 이러한 환경을 구성한 다는 것은 거의 불가능하지 않겠는가?3.  빌드, 테스트, 배포 단계를 자동화하기 위하여 얼마나 노력하고 있는가?4.  수작업의 실수와 반복을 어떻게 최소화하기 위해서 노력하는가?5.  개발 조직과 운영조직의 협업을 위하여 빈번한 커뮤니케이션 소통 비용을 지불하고 있는가?이러한 최소한의 필요충분조건을 만족한다면, 개발 조직은 다음과 같은 최소한의 목표를 이루기 위해서 준비를 한다고 볼 수 있다.1.  개발과 품질관리, 운영을 교집합적으로 운영하기 위한 방법을 터득하였고, 그것을 개발 조직에 내재화하기 위하여 노력 중이다.2.  신뢰성, 보안성, 개발과 배포 사이클을 보다 더 빠르게 개선하기 위해서 배포, 테스트, 세부 기능 개발, 릴리즈 관리를 목표로 조직이 운영 중이다.3.  툴이 아니라, 문화와 일하는 방법에 대한 경험을 더 우선적으로 하고 있다.DevOps의 가장 중요한 원칙위에서 이야기한 필요조건과 환경에 대한 것이 준비가 된다면, 다음과 같은 DevOps의 원칙을 실현할 준비가 된 것이다. 그 원칙을 살펴보자1.  주요 기능에 집중하고 있는가?2.  품질을 내재화하기 위하여 노력하고 있는가?3.  개발에 필요한 지식을 창출하기 위해서 과학적으로 접근하고 있는가?4.  완벽한 명세서를 만들기 위한 비용보다, 명쾌한 협업을 중시하여 커뮤니케이션 비용을 지출하고 있는가?5.  가능한 한 빨리 개발하기 위해서 시도하고 있는가?6.  사람을 존중하는 개발자 문화를 만들고 있는가?7.  최적화를 위한 방안을 고안하는데 회의나 토론을 아까워하지 않고 있으며, 그것에 대해서 투자를 아낌없이 하고 있는가?이러한 과정은 DevOps에 대해서 실현하기 위해서 노력하는 행위와 절차라고 볼 수 있다. 가능하다면 DevOps의 성숙도 모델에 대한 설명과 실제 우리가 그러한 모델을 통해서 개발 조직에 DevOps의 사상을 표현할 수 있는지에 대해서 설명할 기회가 곧 다가올 것으로 기대해본다.물론, 기술적 부채에 대해서도 한 번 거론한 다음에 그 이야기를 이야기하도록 하겠다.DevOps는 애자일과 마찬가지로 선언이고 문화에 해당한다. 즐거운 개발을 지향하고 있다면 소프트웨어 품질은 매우 당연하게 좋아진다. 행복한 개발자가 훌륭한 소프트웨어를 만든다는 것을 잊지 말자. 그것이 DevOps의 시작이며, 출발이다.
조회수 1486

스푼 라디오 안드로이드 개발자 Yong을 소개합니다!

 정말 좋아하는 일을 하면, 주말 또는 정해 놓고 쉬는 날이 없습니다. 어디선가 호탕한 웃음소리가 나면 백발백중 'Yong'의 웃음소리라는 것을 안다. 듣는 다른 이 또한 웃게 만드는 매력적인 웃음의 소유자 안드로이드 개발자이자 클라이언트팀의 리더 용을 지금 소개합니다.호탕한 웃음의 원천이요?"저는 기본적으로 일을 즐겁게 하자 라는 생각으로 일을 합니다. 함께 웃으면서 일하면 서로 함께 기분이 좋아지잖아요! 그게 저의 호탕한 웃음의 원천인 것 같습니다. 다른 분들께 매력적으로 보인다는 것은 처음 알았네요 :) 그리고 저는 원래 웃음이 많은 사람입니다"듣고 싶은 당신의 스푼 라이프클라이언트팀이 궁금합니다."클라이언트 팀은 세 파트로 나뉘어있습니다. IOS, AOS 그리고 Web입니다. 저희 팀은 다른 많은 부서들과 긴밀한 협업을 통해 제품에 대한 틀을 정의하고 프로그래밍이라는 구현 작업을 통해 제품을 만들어 사용자들에게 가치를 전달하고 있습니다. 저희는 사용자들에게 제품을 이용하는 편의성을 제공하며 사용자 상호 간의 소통의 창구적인 역할을 하게 됩니다. 또한, 사용자들의 다양한 행위를 통해 스푼은 사용자들에게 재미, 감동, 그 이상의 의미를 전달합니다. 결과적으로 사용자들이 인식하고 보고 느끼는 모든 것이자 스푼의 가치를 전달하는 최종적인 결과물이라고 할 수 있겠습니다. 그리고 저는 현재 팀에서 클라이언트 팀 리더이자 안드로이드 개발을 담당하고 있습니다."개발자 그리고 팀 리더가 되기까지"저는 원래 전공이 하드웨어 분야였습니다. 사실 원대한 꿈은 없었지만 제 스스로가 이공계에 마땅한 사람이라는 것은 알 고 있었어요. 하드웨어와 소프트웨어 가리지 않고 무언가를 개발하는 것을 좋아한다는 걸 알았거든요. 제가 진로를 선택했을 땐 안드로이드 개발이 구현되기 전이었어요. 그래서 서버랑 클라이언트(윈도우)이 둘 중에 진로를 선택해야 했었고 첫 회사에서 UI 쪽으로 업무를 시작하게 되었어요. 사실 애초 UX/UI에 관심이 많았고 적성에 맞다는 걸 느꼈어요. 제가 만든 제품을 누군가가 사용하는 것을 육안으로 보고 싶었거든요. 개발은 정말 보람된 일이자 저에게 자부심이기도 합니다.개발자로서 코딩만 하다가 팀 리더가 되어보니, 리더가 정말 힘든 일이라는 것을 알았어요. 어쩌면 코딩보다 더 어려운 일인 것 같아요. 상대방을 이해하고, 또 이해시키고 공감해야 하니까요. 제가 일을 하면서 가장 행복할 때는, 함께 한다는 느낌을 받을 때인 것 같습니다. 예를 들어서 아이디어 회의를 할 때 모두가 같은 마음으로 함께 이루어간다고 생각이 들 때가 가장 뿌듯하더라고요."함께 일하고 싶은 사람 저는 솔직한 사람을 좋아합니다. 본인의 생각을 진솔하게 이야기하고, 공감대를 잘 형성할 수 있는 사람이요. 결국 일은 사람과 사람이 함께 하니까요.  알고 싶은 Yong의 이야기나를 표현하는 한마디 - '바람'저는 자유로운 사람이 되고 싶어요. 바람처럼 유유자적하면서, 무언가 하고 싶은 것이 있을 때 자유롭게 즐길 수 있으며, 구속받지 않는 삶을 살고 싶습니다.나만의 스트레스 해소법"제가 게임을 정말 좋아해요. 거의 모든 온라인 게임은 다 했던 것 같아요. 와우, 블리자드, 배그, 오버워치 등등 정말 많이 했는데 사실 지금은 잘 안 하는 것 같아요. 예전에 마케팅팀 테드랑 주말마다 함께 온라인에서 만나서 게임을 했었는데 테드가 결혼하고 저도 아이와 함께 시간을 보내다 보니 점점 게임을 안 하게 되더라고요. 게임을 왜 좋아하냐고요? 일단 재미있잖아요! 그리고 스트레스 푸는데 아주 좋아요. 게임에 몰두하고 나면 잡생각이 없어지거든요. 게임도 개발과 비슷해요. 온전히 집중해서 하지 않으면 모든 게 틀어지거든요. 게임은 집중력 향상에도 굉장히 좋습니다!"개발은 '예술'과 같아요 "주말에 집에서 일하는 이유요? 일이 많아서나 해야 해서 하는 것은 아니에요. 단지 자유롭게 하고 싶을 때 하는 편입니다. 좋아하고 즐거운 일이니까요! 개발은 하나의 예술이라고 생각합니다. 화가가 요일을 정해놓고 그림을 그리지 않는 것처럼 개발자도 똑같아요. 좋아하는 일을 한다면 그건 일이 아니라고 생각이 들거든요. 저에게 개발은 그렇습니다. 제게 개발은 재미있는 하나의 예술과 같아요"Yong은1. 사진, 그림, 음악 등 예술에 관심이 아주 많습니다!(피아노 독주회, 전시회에 종종 가신다고 합니다. 특히나 클래식과 재즈를 좋아합니다)2. 가리는 음식은 없지만, 한식류를 좋아합니다!팀원들이 Yong을 한마디로 표현한다면?Edward Jung 曰: 웃지만 무서운 관리자 - “언제나 웃음으로 대하시지만 내가 웃는 게 웃는 게 아니야라고 느껴짐…”Julia Na 曰: 행복한 리더 - "호탕한 웃음소리가 트레이드 마크. '행복하세요'라고 말하며 팀원들에게 긍정기운을 전파합니다."Michael Chung 曰: 따뜻한 마음을 가진 개발자 - “팀원들 하나하나 직접 챙기기 때문”Roy Choi 曰: 온화한 아버지 - "개발 실력은 기본, 팀원들을 챙기며 일정 조율 및 커뮤니케이션 능력까지 겸비한 그는 클라이언트팀의 아버지"Raymond Hong 曰: 허허실실 웃음 가득 리더 - "꼼꼼히 팀원과 프로젝트를 챙기기 때문"
조회수 3949

PHP Codeigniter 환경에서 VUE 사용해보기

Overview이번에는 PHP Codeigniter 기반의 서비스에 VUE를 적용시키려고 고민했던 것들을 나누려고 합니다. VUE JS는 가상 DOM을 활용하여 실시간으로 반응 컴포넌트를 제작할 수 있는 프레임워크입니다. 또한, VUE-ROUTER 및 VUEX라는 컴페니언 라이브러리를 통해 url 라우팅 및 전역상태를 관리하기에도 탁월하죠. VUE와 다른 프레임워크와의 비교 부분은 여기를 참고해주세요. 브랜디의 관리자 서비스는 PHP Codeigniter 프레임워크로 제작되었습니다. 하지만 관리자 서비스의 규모가 점점 커지고 기능이 다양해지면서 “자주 사용하는 기능을 묶어 컴포넌트화하자!”라는 숙제가 남아 있었죠. 요즘 잠깐의 여유가 생겨 이때다 싶었습니다. 관리자 서비스에 VUE를 도입하기 위한 시도를 시작했는데요. 얼마 지나지 않아 문제점에 봉착했습니다. 바로 IE9.0…. 개발자의 숙적 IE가 또 한 번 발목을 잡았습니다. 임포트가 되지 않아….VUE를 좀 더 편리하게 사용하려면 JS의 모듈화가 필요했지만, ES2015에서는 import 혹은 require 구문을 지원하지 않아 불편하고, arrow 함수 또한 사용할 수 없습니다. 게다가 VUE의 JAX 탬플릿 구문을 사용할 수도 없었죠!! 뭔가 배보다 배꼽이 더 커질 것 같은 조짐이 보였습니다.결국 Webpack의 도움 없이 VUE를 적용하려던 시도는 여러 가지 난관을 만났고, Codeigniter 프로젝트 내부에서 Webpack을 사용하는 방법을 연구하기 시작했습니다. Webpack은 모듈 번들러입니다. Webpack의 메인 페이지를 방문하면 아래 네 개의 슬로건이 빙글빙글 돕니다.Bundle your scriptsBundle your imagesBundle your stylesBundle your assets아래의 이미지는 Webpack이 무엇을 하는 녀석인지 잘 설명해줍니다.Webpack은 실제로 번들러라고 광고하는것 처럼 Only Webpack 빌드만으로는 소스 파일들을 모아줍니다. 만약 webpack-dev-server로 실행하면 websocket을 통해 소스가 변경됐을 때 실시간으로 화면을 갱신해주는 개발 툴 제공 정도의 역할 밖에 없습니다. (…충분히 훌륭하잖아?)대부분의 기능은 엄청난 확장성을 가진 webpack의 설정으로 모듈로서 작동할 수 있죠. 예를 들면 Babel은 우리의 발목을 잡았던 IE를 위해 ES6로 작성된 js 문법을 IE에서 사용할 수 있는 ES5문법으로 너무나 쉽게 트랜스컴파일할 수 있습니다.하지만… 관리자 서비스는 위에서 언급했듯이 Codeigniter 기반입니다. 따라서 완벽히 VUE와 API서버를 분리하려면 로그인, 메뉴구성, 헤더, 푸터 등 PHP 기반으로 제작된 모든 기능들과 인증 등 기존 방식을 전부 새로 만들어야만 VUE를 온전히 사용할 수 있습니다.문제점들을 모두 해결하고 넘어가기엔 여유가 부족하기 때문에 조금씩 적용하자고 생각했습니다. 덕분에 webpack-dev-server의 실시간 소스 반영 기능을 포기해야만 했죠.(눈물) 우리의 서버는 node기반이 아닌 apache-php 기반이었기 때문입니다.자, 그럼 Codeigniter 프로잭트 하위에 웹팩을 포함시켜 Hello World까지 가는 짧은(?)여정을 시작해봅시다.Hello world로 가는 여정Node, npm 설치맥에서도 유사한 명령어로 제작할 수 있도록 CMD 위주로 진행하겠습니다. 먼저, 여기를 클릭해 Node를 설치합시다. 8.11.3 LTS버전으로 진행했습니다.맥에서는 Homebrew를 통해 간편하게~brew install node 설치 확인npm 잘 설치되었네요.web pack 폴더 생성 및 이동mkdir webpack cd webpack nom init으로 초기화npm init webpack, vue, babel 설치npm install -D webpack webpack-cli webpack-dev-server npm install -D vue-loader vue-template-compiler npm install -D babel-core babel-loader babel-preset-es2015 여기서 VUE는 설치하지 않습니다! 왜냐하면 VUE.js는 로딩만 하면 되고 필요하지 않습니다! (읭?) VUE는 Codeigniter view에서도 사용해야 하기 때문에 해당 view에서 import 해줍니다. 따라서 VUE 컴포넌트가 들어가는 시점에는 이미 전역에 vue.js 가 있습니다. 따라서 굳이 각 모듈마다 VUE를 import 했다가 webpack 설정에서 다시 vue.js를 제외할 필요는 없습니다.VUE와 template 태그를 로딩할 수 있는 로더도 설치하고, 트랜스컴파일을 위한 바벨, IE9를 지원하기 위한 es2015프리셋도 함께 설치합니다.webpack 빌드명령어 package.json의 script부분에 추가"scripts": { "build": "webpack --mode production", "build-dev": "webpack --mode development",   } 이제 VUE를 빌드할 명령어를 작성합니다. 위처럼 두 가지 명령어를 제작해두면, 추후 env를 통해 webpack.config.js를 분기시켜 원하는 환경으로 빌드할 수 있습니다. 또한 production 모드로 빌드할 땐 자동으로 옵티마이저 - uglify 내장 플러그인이 적용되어 익숙한 min.js형태로 빌드되며 development를 빌드할 땐 사람이 알아볼 수 있는 형태로 빌드되고, debugger 코드 또한 살아있습니다.weboack.config.js 작성const { VueLoaderPlugin } = require('vue-loader'); module.exports = {   entry: {     HelloWorld: './src/main.js'   },    module: {     rules: [       {         test: /\.vue$/,         loader: 'vue-loader',       },       {         test: /\.js$/,         loader: 'babel-loader',       }     ]   },    resolve: {     alias: {       'vue$':'vue/dist/vue.esm.js'     }   },    plugins: [     new VueLoaderPlugin()   ]  } webpack.config.js 가 없다면 생성한 후 위와 같이 작성합니다..babelrc 작성{     "presets": ["es2015"] } 테스트용 파일 작성1)main.js 작성import HelloWorld from './HelloWorld.vue' Vue.component('hello-world', HelloWorld); 2)HelloWorld.vue 작성 [removed] export default {   name: 'app',   data: () => {     return {       word1: 'Hello',       word2: 'World'     }   }  } [removed] 테스트 빌드npm run build-dev 빌드를 할 땐 기본적으로 ‘/dist/’ 하위에 소스코드가 떨어집니다. 자, 여기까지 진행하셨다면 폴더 구조는 다음과 같을 것입니다.지금까지 진행한 파일 모습입니다.뷰 컴포넌트가 잘 제작되고 등록되는지 확인하려면 기본 빌드 폴더인 dist 폴더에 Test.html을 작성해 브라우저로 열어봅시다.확인용 html 파일 작성<!DOCTYPE html> <html lang="en"> <head>     <meta charset="UTF-8">     <title>VUE Test</title>     <!-- VUE 플러그인 -->     [removed][removed] </head> <body>                     [removed][removed]     [removed]         new Vue({             el: '#vue'         })     [removed] </body> </html> 잘 나옵니다.정상적으로 VUE가 적용된 것을 확인합니다.코드이그나이터 설치이제 코드이그나이터 프로젝트 내부에서 VUE 컴포넌트를 출력해보기 위해 코드이그나이터 프로젝트를 생성합시다. 먼저 Codeigniter와 XAMPP를 다운로드 받습니다.Codeigniter 받으러 가기XAMPP 받으러 가기프로젝트 폴더 하위에 Codeigniter 프로젝트용 폴더를 생성합니다.mkdir codeigniter-with-vue-webpack cd codeigniter-with-vue-webpack 다운받은 Codeigniter를 해당 폴더에 압축 해제하면 Codeigniter 설치가 끝납니다.XAMPP 설치 및 DocumentRoot 변경XAMPP를 설치하고 DocumentRoot를 테스트 프로젝트 폴더로 설정한 뒤 아파치를 실행합니다.Codeigniter 프로젝트가 생성되었고, 서버 실행이 완료되었습니다. webpack 폴더를 Codeigniter 프로젝트 하위로 이동node-modules는 너무 크기 때문에 기본 파일만 복사하고, npm install로 설치합니다.Codeigniter에서 VUE를 사용하기 위한 webpack dist설정기존의 프로젝트에서 스크립트를 모아두는 폴더 하위로 빌드 결과 파일을 보내기 위하여 webpack 빌드 시 dist 폴더가 아닌 /application/scripts/vue/hello_world 하위로 빌드 결과 파일이 생성되도록 설정합니다.// 기존 module.exports = {   entry: {     HelloWorld: './src/main.js'   },    //... 생략 } // 변경후 module.exports = {   entry: {     '../../application/scripts/vue/hello_world/HelloWorld.js': './src/main.js'   },    //... 생략 } Codeigniter의 load->view 기능을 활용하여 파일 작성1)header.php// application/views/common/header.php <!DOCTYPE html> <html lang="en"> <head>     <meta charset="UTF-8">     <title>VUE Test</title>     <!-- VUE 플러그인 -->     [removed][removed] </head> 2)실제 view// application/views/vue/hello_world/vueTestPage.php <?php $this->load->view( 'common/header' ); ?> <body>                 [removed] [removed]     [removed]         new Vue({             el: '#vue'         })     [removed] </body> <?php $this->load->view( 'common/footer' ); ?> 3)footer.php// application/views/common/footer.php </html> 실제 프로젝트 구성과 유사하게 header, body, footer로 나누어 파일을 작성해봅니다. 실제로는 더 복잡하지만 이 정도만 나누겠습니다.Codeigniter 테스트용 컨트롤러 작성// application/controllers/Vue.php <?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');   class Vue extends CI_Controller {      public function index()     {         $this->load->view('vue/vueTestPage');     }  } 정말 심플(?)한 테스트용 파일 작성이 모두 끝났습니다! 이제 잘 작동하는지 확인해볼까요?코드이그나이터에서 helloworld 출력짜잔이번엔 문제의 IE에서 확인해봅시다.IE9.0 환경에서 확인IE에서도 무사히 출력되는군요. 이제 코드이그나이터 환경의 프로젝트에서도 IE까지 지원하며 무사히 VUE를 사용할 수 있게 되었습니다! (시간이 없어서 가상머신에 IE9가 설치된 윈도우7까지 테스트하진 못했습니다!) 모든 작업이 완료한 후, 파일 폴더 구조는 아래와 같습니다.붉은 네모 부분이 실제로 제작하거나 수정한 파일들입니다.Conclusion여기까지가 Codeigniter 프래임워크 환경에서 webpack + vue를 사용하기 위한 웹팩의 설정 과정 및 테스트 결과였습니다. php 서버를 사용해야 하기 때문에 webpack-dev-server의 핫리로드 기능을 사용하지 못하는 건 매우 안타까운 일입니다. 하지만 짧은 시간에 신기술을 도입하면서도 수많은 리스크를 회피할 수 있다는 건 나쁘지 않은 선택이라 생각합니다.위의 웹팩설정을 조금만 활용한다면 다른 프레임워크 프로젝트에서도 무리없이 VUE를 사용할 수 있을 겁니다! 비슷한 고민을 하셨던 개발자님들… 집에 가기 전 말고 오전에 Webpack을 설치해보세요. 안 그러면 저처럼 집에 못갈 수도 있으니까요!참고.gitignore 작성, index.php 제거 등은 내용에 포함하지 않았으며, 아래의 링크로 자세히 알 수 있음.Codeigniter index.php 없애기글강원우 과장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만 #브랜디 #개발자 #개발팀 #인사이트 #경험공유 #PHP
조회수 4064

리디북스 서비스 장애 복구 후기

지난 8월 26일에는 약 21분간 리디북스 서비스 전체가 중단되는 장애가 있었습니다.사실 서버 스택 일부에만 영향을 주는 장애는 눈에 잘 띄지 않지만 꽤 흔하게 발생하는 일입니다. 기기 1대당 외부적인 요인으로 인한 장애가 평균 2년에 1번 발생한다고 가정하면, 서버가 100대 있을 때는 대략 1주일에 1번꼴로 장애가 발생하는 셈입니다.이런 형태의 장애는 서버 스택의 한 곳에서만 발생하므로, 이중화 혹은 클러스터링을 통해서 극복하곤 합니다. 또한 원인이 명확하므로 해당 기술에 대한 이해도가 높다면 비교적 빠른 시간 내에 복구가 가능합니다.그러나 이번에 리디북스가 경험한 장애는 달랐습니다. 현재 리디북스는 2개의 데이터센터와 클라우드에 인프라가 분산되어 있는데, 이 중에서 1차 데이터센터의 전원 공급에 문제가 생겨 특정 서버 랙에 있는 서버 17대가 동시에 내려간 것입니다. 즉, 소프트웨어나 머신의 물리적인 장애가 아닌, 데이터센터의 장애였습니다. AWS로 비유를 하자면 가용 영역(Availability Zone)의 장애라고 할 수 있겠습니다.원인에 대해이번 장애의 근본적인 원인은 데이터센터가 전원을 정상적으로 공급해주지 못한 것입니다. 물론 데이터센터 혹은 클라우드 서비스(IaaS)는 고객사에게 전원과 네트워크를 안정적으로 제공해주어야 하는 의무가 있습니다.하지만 이들 역시 천재지변이나 사람의 실수에 대한 대비가 100% 완벽할 수는 없습니다. 따라서 이러한 점을 사전에 고려하고 인프라를 설계하지 못한 것이 2차적인 원인입니다.이번 계기를 통해 데이터센터 이중화를 계획하게 되었고, 사용 중인 클라우드 역시 지역(Region) 전체에 장애가 생길 경우에 대한 대비가 되어있지 않아, 이번 계기로 복제 계획(Geo-Replication)을 세우게 되었습니다.구체적인 상황당시 전원이 차단되어 강제 종료된 서버들은 아래와 같습니다.데이터베이스 프록시 x 2메인 리버스 프록시 x 1읽기 분산용 MySQL 슬레이브 x 1서점용 웹 서버 x 3추천 알고리즘 API 서버 x 1알림센터 API 서버 x 2메인 스토리지 서버 x 2출판 플랫폼용 데이터베이스 x 2테스트 및 배치 작업용 서버 x 3그림으로 표현해 보자면, 대략 아래와 같은 상황에서… 아래와 같은 상황이 된 셈입니다.서버 스택의 여러곳에 순간적으로 장애가 발생한 상황공인 IP가 할당된 메인 프록시 서버 중 1대가 내려갔지만, 실제로는 아래와 같이 가상 IP로 구성을 한 상태였기 때문에 대기 중인(stand-by) 프록시가 동작하여 곧 서점에 장애 공지를 띄울 수 있었습니다.[이미지 출처: DigitalOcean™]공지 이후의 움직임우리는 데이터센터의 복구 시점을 명확히 알 수 없어서 신규 구축(provisioning)을 시작함과 동시에, 서버들의 물리적인 위치 이동을 고려하고 있었습니다. 그러나 다행히 10분이 지난 시점에서 전원 문제는 해결되었고, 서버들은 순차적으로 부팅이 완료되었습니다.일부 서버들은 부팅 과정에서 예상치 못한 지연이 발생하기도 하였지만, 모든 서버의 부팅이 완료된 이후에도 서비스는 완전히 정상으로 돌아오지 않았습니다. 당시 우리가 겪었던 문제와 해결책은 아래와 같습니다.A. 읽기 분산용 MariaDB 슬레이브의 복제 지연(replication lag) 문제슬레이브 서버의 부팅이 완료되자 데이터베이스 프록시(HAProxy)는 해당 서버를 정상으로 간주하여 라우팅 대상에 포함하게 되었고, 애플리케이션 서버들은 정상적으로 커넥션을 맺기 시작하였습니다. 하지만 해당 슬레이브는 수십 분간 마스터를 따라잡지 못한 상태였기 때문에 최신 데이터가 보여지지 않는 문제(stale data)가 있었습니다. 우리는 즉시 해당 슬레이브를 제거하였고 지연이 사라진 이후에 다시 서비스에 투입하였습니다.B. 읽기 분산용 슬레이브의 웜업(warm-up) 문제복제 지연은 사라졌지만 서버의 CPU 사용량이 크게 높은 상태가 한동안 유지되었고, 응답속도는 정상적인 슬레이브에 비해서 많이 느렸습니다. 왜냐하면 캐시가 비워진 상태에서 바로 서비스에 투입되어, 캐시 미스가 휘몰아치는 현상(cache stampede)이 발생하였기 때문입니다. 따라서 간단한 쿼리도 평소보다 오래 걸렸고, 그대로 둔다면 커넥션풀이 꽉 차는 현상이 발생할 것으로 예상되었습니다.곧 우리는 HAProxy로 해당 서버의 가중치를 10%로 낮추어 인입되는 쿼리의 양을 조절하였으며 응답속도는 정상 수치로 돌아오게 되었습니다. 이후 스크립트를 작성하여 수동으로 캐시를 채워나감과 동시에 점차 가중치를 높여 처리량을 정상화하였습니다.프로덕션에서 사용하는 서버는 innodb_buffer_pool 이 100G 이상으로 매우 크게 설정되어 있으며, 재시작 시 캐시가 날아가는 현상을 해결하기 위해 innodb_blocking_buffer_pool_restore 옵션을 적용하고 있습니다. 하지만 지금처럼 메모리를 덤프하지 못하고 비정상 종료가 된 상황에서는 해당되지 않았습니다.C. 인메모리 데이터의 보존 문제알림센터는 다양한 프로모션과 개인화된 정보를 전달해주는 공간입니다. 알림센터의 특징은 데이터의 영구 보존(persistency)이 필요하지 않고, 매일 수백만 건의 개인화된 메시지가 기록된다는 것입니다. 이러한 특징은 인-메모리 데이터베이스에 적합하므로 우리는 Redis를 마스터/슬레이브로 구성하여 저장소로 사용하고 있었습니다.어떠한 이유로든 Redis를 재시작해야 할 경우가 생기면, 메모리 상의 데이터가 날아가는 것을 방지하기 위해 주기적으로 스냅샷을 남기고 있습니다만, 이번에는 로그가 마지막까지 기록되지 못한 상태에서 메모리의 데이터가 날아가 버렸습니다.다행히 알림 발송과 관련된 메타정보는 모두 MariaDB에 기록하고 있으므로, 우리는 이를 기반으로 소실된 시점부터의 알림을 순차적으로 재발송할 수 있었습니다. 물론 모든 알림이 신규 상태로 간주되어 아이콘이 잘못 노출되는 문제가 있었지만, 고객님들은 너그럽게 이해해 주신 것 같습니다. 😅그래서 앞으로는?리디북스 DevOps 멤버들은 이번 데이터센터 장애를 통해 현재 인프라의 한계점을 실감하였고, 앞으로의 개선 방향에 대해 고민하게 되었습니다.몇 가지를 정리하면 다음과 같습니다.랙 단위로 장애가 발생할 수 있음을 인지하고 대비하자.같은 기능을 하는 서버를 하나의 랙이나 같은 가용 영역에 두지 말자.2차 데이터센터는 더 이상 옵션이 아닌 필수다.낙뢰나 지진으로 인해 데이터센터에 문제가 생길 수도 있다.긴급하게 프로비저닝이 필요한 상황에 대비하자.문서화가 되어 있더라도 경험이 없다면 동일한 구성에 많은 시간이 소요된다.모든 구성요소들에 대한 Ansible 스크립트를 작성하여두자.캐시 웜업 스크립트도 작성하여 두자.백엔드 구성요소들 간의 불필요한 의존 관계를 끊자.단 한 줄의 코드라도 참조하고 있다면 이는 독립적인 것이 아니다.언제나 서비스 지향적인 설계를 추구하자.Uptime을 관리하자.최대 180일을 기점으로 무조건 리부팅을 하자.재시작 과정에서 다양한 문제와 개선점이 발견될 것이다.커널 패치, 보안 패치를 할 수 있는 것은 덤이다.아래와 같은 긍정적인 면도 발견하였습니다.장애 상황이 실시간으로 Slack 채널을 통해 전파되었음진행 상황에 대해 모두가 동일한 수준으로 이해할 수 있었다.모니터링 연동(integration) 기능 때문에라도, Slack은 유료로 구매할만한 값어치가 충분하다.같은 기능을 하는 서버들이 다른 랙에 많이 분산되어 있었다.인프라가 확장될 때마다 빈 공간에 필요한 서버를 추가했을 뿐이지만, 자연스럽게 물리적인 위치가 분산되는 효과가 있었다.이 외에도 특정 클러스터를 구성하는 노드들을 분산하여 배치시키자.서버별로 오너쉽이 부여되어 있어서 빠르게 복구가 된 점여러 명의 백엔드 개발자들이 병렬적으로 복구를 진행할 수 있었다.마지막으로넷플릭스의 엔지니어들은 무질서한 원숭이(Chaos Monkey)라는 프로그램을 만들어서 운영한다고 합니다. 이 원숭이는 서비스 인스턴스들을 무작위로 중단시키는 역할을 합니다. 다소 황당하게 들리지만, 넷플릭스에는 일부 서비스에 장애가 발생하더라도 나머지 부분은 문제없이 운영되어야 한다는 원칙이 있으므로, 이를 수시로 시뮬레이션하는 과정을 통해 복구 능력을 높여둔다는 것입니다.실제로 이렇게 급진적인 아이디어를 실천할 수 있는 회사는 매우 드물 것입니다. 하지만, 우리는 이번 계기를 통해 무질서한 원숭이의 필요성을 절감하였고, 이로 인해 서버를 주기적으로 리셋하는 정책을 만들게 되었으며 모든 단일 장애점(SPoF)에 대한 대비를 시작하게 되었습니다.장애를 단순히 피해라고만 생각한다면, 서로를 비난하고 책임을 전가하는 상황이 펼쳐질 것입니다. 하지만 고객의 불편함과 맞바꾼 매우 비싼 경험이라고 생각한다면, 보다 튼튼하고 회복탄력적인 시스템을 갖추기 위해 노력하게 될 것입니다. 그러다 보면 언젠가는 데이터센터 전체에 문제가 생겨도 버틸 수 있는 모습으로 진화할 것이라고 생각합니다.#리디북스 #장애복구 #역경돌파 #개발 #개발후기 #개발자 #서버개발 #서버
조회수 949

DevOps 문화 안에서의 APM의 역할 [2] (DevOps+JENNIFER)

전편에서는 개발 프로세스 내에서 모니터링 단계의 문제점과 이를 해결하기 위한 방법으로 APM의 역할이 DevOps 진영에서는 매우 중요한 이슈가 되고 있다고 정리했었다. 또한 모니터링 프로세스의 세부 단계와 모니터링 기준 값 설정에 대한 내용을 다뤘는데, 이를 기반으로 제니퍼를 활용하여 모니터링하는 방법에 대해 알아보려고 한다.장애 발견 및 알림제니퍼에서 이벤트 발생 조건은 컴파일 에러나 응답 시간 초과, OOM과 같은 애플리케이션 에러 유형이나 액티브서비스 개수, 응답 시간, CPU 사용률, 힙 메모리 사용률 등 서비스나 시스템의 상태 값으로 설정될 수 있다. 그리고 이벤트 설정시 외부연동 활성화 기능을 사용할 수 있으며, SMTP(Simple Mail Transfer Protocol) 모듈을 기본으로 제공한다. 또한 고객이 직접 이벤트 모듈을 구현할 수 있도록 인터페이스와 유틸리티를 제공한다. 참고로 제니퍼를 사용하는 고객사 중에서 자체적으로 구축한 관제 시스템에 제니퍼 이벤트를 연동하여, 별도의 WAS 경고 시스템을 만든 사례도 있다.   서비스 부하량 제어 (운영)제니퍼는 PLC(Peak Load Control)라는 서비스 부하량을 제어할 수 있는 기능을 제공한다. 트랜잭션 유입 차단의 기준이 되는 최소/최대 액티브서비스 개수를 설정하고, 해당 임계치 값 초과시 사용자에게 가이드해줄 수 있는 메시지나  리다이렉트 페이지를 설정할 수 있다.   만약에 대상 애플리케이션(서버 또는 WAS)이 처리 중인 액티브서비스 개수가 설정한 임계치 값을 초과하면 들어오는 사용자 요청은 거절되며 액티브서비스 이퀄라이저 차트의 요청 효과가 반사되고, 색상 또한 붉은색 계통으로 변하게 된다.사용자의 요청(Request)이 거절되면 PLC 관리 화면에서 설정한 메시지가 보이거나 아래와 같은 화면으로 리다이렉트 되며, 모니터링 대상 애플리케이션의 액티브서비스가 임계치보다 낮아지면 원래의 화면으로 돌아올 수 있다.  장애 원인 분석 (개발)개별 트랜잭션에 대한 프로파일 데이터를 분석하기 위해서는 대상이 되는 패키지나 클래스를 알아야 하는데, 적용 범위에 따라 프로파일 데이터 크기가 매우 커질 수 있으므로 실제로 운영되는 서비스에는 큰 부담이 될 수 있다. 하지만 제니퍼의 자동 프로파일링과 스택트레이스 기능은 설정한 응답시간을 초과한 트랜잭션에만 적용되기 때문에 실제 운영 단계에서 사용하기에 적합하다. 프로파일이란 트랜잭션의 시작점이 되는 메소드의 호출 구조를 상세하게 분석하는 기능을 말하며, 스택트레이스는 앞에서 설정한 기준 값을 초과하는 순간에 호출된 메소드 구조에 대한 로그를 남기는 것을 말한다. 만약에 설정한 응답시간을 초과하여 의심이 될만한 트랜잭션을 분포도 차트에서 찾았다면, 트랜잭션 분석 화면을 통해 문제 시점의 스택트레이스 정보를 참고하거나 응답이 지연되는 프로파일 데이터를 구간 별로 검색하여 콜-트리를 통해 문제가 되는 메소드 위치를 정확히 알아낼 수 있다.소스코드가 배포되었다면 트랜잭션 분포도 차트에서 배포 시점에 세로 축이 하나 그려진다. 해당 축을 선택하면 새로 추가되거나 수정된 리소스 목록을 조회할 수 있으며, 리소스의 배포 전/후의 내용을 분석하는 코드리뷰 기능은 개발 환경에서 반영된 소스코드를 분석해야하는 번거로움을 덜어준다.배포 이후에 액티브서비스가 빠르게 처리되지 못하고, 트랜잭션 분포도 차트가 기존의 패턴과 다르게 형성이 된다면 새로 반영된 소스코드에 문제가 있을 가능성이 매우 높다.결론인류 사회에서 자신이 속해 있는 환경과 전혀 다른 이질적인 문화나 새로운 생활 양식을 접할 때 받는 충격과 공포를 문화 충격(Culture Shock)라고 하는데, 이는 IT 분야에서도 크게 다르지 않다. 사실 DevOps는 몇년 전부터 계속 주목받고 있으며, 많은 소프트웨어 개발 조직에서 시도하고 있는 개발 방법론이다. 하지만 새로운 문화에 대한 거부감으로 인해 제대로 적용되지 못하고 있는 것이 현실이다.DevOps가 추구하는 가치인 존중과 신뢰를 바탕으로 개발과 운영의 원활한 의사소통과 협업 관계 형성은 말처럼 쉽지 않다. 어떻게 보면 이상적일 수 밖에 없는 추상적인 개념이지만 본문에서 다뤘듯이 APM을 상호 간의 의사소통 도구로써 잘 활용한다면 이상이 아닌 보다 현실에 가까워질 수 있다고 필자는 확신한다. APM은 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목표로 하는 DevOps를 개발 문화로 성공적으로 정착시키는데 가장 중요한 역할을 하는 도구라고 생각한다.
조회수 2854

WHATAP Python APM 이야기...

백엔드 서비스로 Python을 사용한다면 만나게될 상황을보다 쉽게 해결하기 위한 와탭의 Python APM, 개발하게 된 이유입니다.파이썬은 배우기 쉽고, 어디서나 실행되는 언어라고 이야기되며, 인기도 높습니다. 생각보다 많은 곳에서 배울 수 있으며, 혼자 배우기도 좋습니다. 그런데, 이 규모가 확대되어서 스타트업의 경우에 Python을 사용하여 백엔드 서비스를 개발하는 경우를 찾는 것이 어렵지 않습니다. 또는, 수학적인 알고리즘이거나 ML(머신러닝)과 같은 영역이거나 블록체인등에서 Python을 사용하여 API geteway나 broker를 사용하는 경우에 한정한 상황을 고려하고 있습니다.Python으로 백엔드 서비스를 만들 때에는 성능과 설계 부분에 대해서 많은 걱정을 하게 됩니다. 이런 상황을 만나게되는 개발자는 여러가지 문제를 만나게 됩니다. 그 문제에 와탭은 집중합니다.!와탭은 백엔드 서비스를 Python으로 개발시에 만나게 되는 상황을 가장 최우선으로 생각하게 되었습니다.Python으로 '설계', '개발'되고 '테스트'된 후에 '배포'되는 상황에서 서비스의 불완전함과 속도상의 문제, 리소스의 불협화음등을 '유지보수'하는 단계를 '성능 튜닝'이라고 정의하고, 이를 고려한 상황을 보다 단순화하는 것이라고 생각하게 되었습니다. 이를 어떻게 처리하느냐가 와탭 Python의 핵심 가치라고 생각하였습니다.----- 이 부분은 Python korea 페이스북에서 '배권한'님이 지적하신 내용을 기반으로 일부 첨언되었습니다.----- python native 개발자들에게는 불필요한 설명에 해당됩니다.파이썬은 분명, 읽기 쉽고 사용하기 쉬운 것은 장점이며, 라즈베리파이 위에서 동작되는 기민함은 정말 매력적입니다. <- 원래 문장.(* 현재에는 jvm도 동작합니다. 하지만, 작고 기민하게 다양한 IoT 디바이스에서 폭넓게 활용되는 것은 파이썬의 장점은 분명하지 않나 합니다. 이 부분에 대한 지적이 있어서 첨언합니다. )내부 구성상 비동기식으로 쓰레딩이 아니라, 단일 이벤트 루프를 사용하는 비동기식 작성은 매우 효과적입니다. <- 원래 문장.(* 이 부분도 asyncio나 gevent등에 대한 이야기이고, CPython의 언어 구현상 GIL때문에 쓰레드가 비효율적이라는 이야기를 거론하고 싶었으나, 일반적으로 파이썬에 대한 언어를 사용할때에 대부분 사용하는 이유가 단일 이벤트 루프기반의 비동기식 작성이 매우 일반적으로 사용되기 때문에, 이렇게 서술되었습니다. 하지만, 이런 설명은 백엔드로 Python을 사용하는 경우에 대부분의 프레임웍들에서 처리되고 있기 때문에 서술이 불분명하다는 지적이 있었습니다. 당연, 백엔드 서비스를 개발할때에 사용되는 wsgi interface등에 맞추어서 서술되는 경우에는 이런 설명이 무의미합니다.다만, 이렇게 서술한 이유는 Java를 기반으로 APM이 개발되어졌기 때문에 이 부분에 대한 서술이나 설명이 필요하다고 생각한 저의 과도한 설명이 되겠습니다.이 부분은 Python Native개발자들에게는 불필요한 설명이 되겠습니다. 하지만, 백엔드 서비스를 개발하면서 만나게될 환경에서는 이 부분에 대한 이해가 어느정도 필요하다고 생각되어 서술된 내용이라고 생각해주시면 감사하겠습니다. )----------------------------------------------------------------------------------------------------------------------이 방식은 복잡한 자원 경쟁이나 교착상태를 발생하지 않게 되며, 기본 코딩과 유지보수를 정말 수월하게 만들어 줍니다. 그만큼 일관성이 높은 수학 알고리즘을 구현하는데 매우 적합합니다. 하지만, 냉정하게, 비즈니스 로직이나 분기가 많은 업무 로직에 적합한 언어는 아닙니다.하지만, 수학적 알고리즘 기반의 주요 모듈 위에 데이터베이스가 일부 필요하고, 웹서비스의 형태로 가동되는 구조라면 파이썬은 매우 훌륭한 선택이 되고 있으며, 생각보다 많이 사용됩니다.그런 이유 중의 하나는 파이썬의 멀티패러다임 구성과 같은 구성에서는 자바에서처럼 굳이 프린트를 위해서 객체지향 클래스를 만들 필요 없이 간단한 함수형 스타일도 가능하게 구성이 됩니다. ( 자바 8에서는 이런 함수 기능도 추가되었습니다. )단순한 구조와 방식 때문에 파이썬 개발은 요즘처럼 ML이나 AI 등의 기술적 요소들이 많이 사용되는 환경에서는 매우 효과적입니다. 백엔드 파이썬 개발이 많이 보이게 되는 이유이기도 하죠.또한, 파이썬 개발의 단점이라고 지적되던 문제들도 현재에는 실행 속도 문제는 사실상 큰 문제가 되지 않는 상황입니다. 일례로, 파이파이(PyPY)로 실행된 파이썬 코드는 웬만한 수준의 C 코드보다 빠르게 동작합니다.굳이 더 지적하자면, 모바일 컴퓨팅과 브라우저에 따른 웹 애플리케이션 클라이언트는 굳이 파이썬으로 작성할 필요성을 느끼지 못한다고 이야기하는 정도입니다.하지만, 이런 파이썬 개발에 가장 큰 문제가 있습니다.테스팅 없이는 동작하기 어렵고,실제 동작 환경에서만 등장하는 오류의 발생파이썬의 특성상 동적 입력 형태에 따르는 더 많은 테스팅을 필요로 하고 있으며, 실제 실행시간에만 나타나는 오류를 찾는 것이 가장 큰 문제가 있습니다. 이 부분은 수많은 파이썬 개발자들을 괴롭히고 있습니다.( 단편적으로 파이썬 개발환경이 매우 고도화되어있지 않으며, 파이썬으로 백엔드 서비스를 만들 것이라고 예측하지 못한 점도 있을 것입니다. 앞으로 파이썬 개발이 더 고도화 되기를 기원합니다. )이 가장 큰 문제를 잡기 위해서와탭은 집중하였습니다.파이썬 백엔드 개발 시의 문제 해결!물론, Python도 디버깅에 대한 지원 유틸리티가 존재합니다.pdb라는 파이썬 디버깅 모듈을 통해서 Step over/Step into, 중단점(breakpoint) 설정, 콜 스택 검사, 소스 리스팅, 변수 치환 등을 할 수 있습니다.‘Phthon -m pdb 파이썬 파일. py’의 형태로 디버그 동작 화면에서 세부적인 동작을 트레이스 해보는 방식을 사용하거나, pdb모듈을 import 한 후에 pdb.set_trace()를 중단하고 싶은 부분에 넣어서 사용하는 방식도 사용됩니다. 또한, 디버그 세션을 사용하는 방식이며, PDB를 사용하여 디버깅하는 방식들도 흔하게 사용됩니다.PyCharm, PTVS, Spyder 등의 IDE를 사용해서 디버깅을 하는 방법은 전통적인 개발환경과 동일하게 사용할 수 있습니다.하지만, 이 방식들은 백엔드 서비스에는 맞지 않게 되며 개발자들은 백엔드 서비스 동작시에 디버그 추적을 위한 로그를 거는 방식을 흔하게 사용하게 됩니다. ( 너무도 전통적인 방식이죠. )정말 백엔드로 파이썬을 사용하고 있다면, 오류 추적이나 동작 메커니즘을 추적한다는 것은 매우 귀찮고 번거로운 작업이 됩니다.만들어지는 파이썬의 모든 파일에 해당 로그를 넣었다가 빼었다가, 배포의 오류를 만나는 상황까지 매우 번거로운 작업들이 끊임없이 반복되게 됩니다. 이런 상황들을 추적하기 위한 APM의 추적 기능들을 찾게 됩니다.또한, Python의 특징상 수학 알고리즘으로 구성된 API 중개인의 형태를 취할 경우에 DB에 대한 접근을 위한 ORM에서의 추적과 외부 웹 호출들이 뒤섞이게 되면서 오류 추적은 매우 짜증스러운 단계로 진화되게 됩니다.Python으로 백엔드 개발을 하게 되면만나게 되는 매우 짜증스러운 상황이죠.그래서, 와탭의 Python APM은 이 문제에 집중하기 위해서 와탭 고유의 문제 해결 방식을 그대로  아키텍처로 적용하여서 개발시에 편하고 빠르게 성능을 추적할 수 있도록 제작되었습니다. Python 백엔드 개발을 위한 최선의 방향을 제시합니다.Python개발자는 와탭의 APM을 설치하면 매우 손쉽게 웹 트랜잭션의 단계, 에러 추적, 클래스 추적, DB의 형태 및 Slow Query추적, 외부 호출 메커니즘의 구성 등을 설치 이후부터 빠르게 추적할 수 있으며, 개발자의 실수이거나 다른 외부 호출의 문제, DB와의 관계 등을 빠르게 잡아낼 수 있습니다.에러를 추적하기 위한 로그를 동작한다던지, 실환경시에 배포를 다시 한다던가 하는 귀찮은 작업을 모두 제거하는 것뿐만 아니라, 매우 통계적으로 의미 있는 와탭의 트랜잭션 추적 메커니즘을 사용할 수 있게 됩니다.파이썬을 기반으로 백엔드를 구성하는 곳이라면,와탭 APM은 매우 의미 있는 결과를 도출할 수 있습니다.와탭 Python의 세부적인 기능을 조금 더 상세하게 설명드리겠습니다.가장 먼저, 실시간 트랜잭션 모니터링!5초 주기로 트랜잭션을 수집하는 와탭의 방식은 서버의 부하를 최소화하면서 가장 의미 있는 데이터들을 수집하고 데이터 기반으로 오류와 트랜잭션을 빠르게 추적할 수 있게 합니다.파이썬 개발 시의 동작성을 체크하기 위한 와탭만의 고유의 진행 중인 트랜잭션 실시간 모니터링 기능인 아크 이퀄라이져와 동작된 웹 트랜잭션의 종료시간을 기준으로 시각화하여 동작된 트랜잭션의 상황을 한눈에 파악할 수 있습니다.와탭 Python APM위의 그림을 보면, Active Transaction으로 불리는 원형( 아크 이퀄라이져라 함 )으로 실제 동작중인 트랜잭션의 개수와 동작속도 등을 체크할 수 있으며, Hitmap을 통해서 종료된 트랜잭션의 속도를 시각화하여 볼 수 있습니다. 이 두 개의 시각화 만으로도 느린 트랜잭션을 추적 관리할 수 있습니다.Python 트랜잭션 추적 및 분석개발자는 단지 APM을 동작시켰을 뿐이지만, postgreSQL 데이터베이스에 연결하고 SQL문장을 주고받는 부분들을 하나의 시각화된 관점으로 나열해서 확인할 수 있습니다.각각의 동작 시간을 추적하는 것은 물론이고, 이 내용은 ORM으로 매핑된 상태에서도 SQL의 동작 순서대로 시각화되기 때문에 순서가 꼬이거나 문제가 발생되는 부분들을 손쉽게 찾아볼 수 있게 합니다.이외에도 와탭 APM( Java, Node, PHP 등의 모든 APM)에 기본적으로 제공되는 트랜잭션 추적 모듈 이외에도 사용자가 원하는 모듈 추적에 대한 기능들을 플러그인 형태로 정의할 수 있습니다. 더 복잡한 추적을 위해서 와탭의 고유기능을 추가적을 확대 사용이 가능합니다.WHATAP_HOME 의 plugin.json파일에 적절한 내용을 수정하여 특정 모듈의 데이터를 추적할 수 있습니다. 특정 모듈의 데이터를 추적하거나, 사용자 별로 원하는 모듈을 추적할 수 있습니다.*사용 안내:•[module_name]: 추적하고자 하는 대상의 모듈 명. import 하는 모듈 명 이기도 하다.•[class_name]: 추적하고자 하는 대상의 클래스 명. 없다면 ‘’(empty string)으로 사용한다.•[def_name]: 추적하고자 하는 대상이다.•args_indexes: 추적하고자 하는 대상의 아규먼트 인덱스. 여러 개일 경우 , 로 구분한다.•kwargs: 추적하고자 하는 대상의 키워드 명. 여러 개일 경우 , 로 구분한다.Plugin 기능 사용위의 예제에서는 Plugin과 SQL update문장의 순차적인 실행,세부 Plugin 설정에서 사용자의 모듈명, 추적 클래스 명, 추적대상과 아규먼트 인덱스, 키워드 등을 추적할 수 있습니다.*사용 예:plugin.json{"[module_name]": {      "class_name": "[class_name]",      "def_name": "[def_name]",      "args_indexes": ", ",      "kwargs": ", "},"httplib2": {      "class_name": "Http",      "def_name": "request",      "args_indexes": "1",      "kwargs": "method"},"faker.providers.address": {      "class_name": "Provider",      "def_name": "street_address",      "args_indexes": "",      "kwargs": ""}}두 번째, 데이터베이스를 매핑한 ORM과 SQL의 순서와 속도, Slow Query!매우 당연하게 파이썬을 기반으로 백엔드 개발을 할 경우에 데이터베이스를 사용하게 되며, 이에 대한 Slow Query와 관련된 추적하는 것이 개발자에게 필요하게 됩니다. 향후, RDS기반을 사용하게 되면 Query추적은 대부분의 데이터베이스 처리에 기본이 될 것입니다.현재 지원되고 있는 mysql / postgresql에 대하여 SQL Query, Fetch Count, SQL Query수행 시간을 수집합니다.Python개발 시에 RDBMS(관계형 데이터베이스 관리 시스템)를 선택하면 거의 항상 ORM(객체 관계 매핑) 라이브러리를 함께 사용하게 됩니다.특히, 파이썬에서는 이런 ORM라이브러리가 다양하고 사용하기 쉽기 때문에, 매우 흔하게 사용하고 있습니다.ORM의 장점으로는 쿼리를 생성하거나 추상화하는 대신, 데이터 베이스 시스템에 대한 접근을 쉽게 할 수 있는 장점이 있습니다. 다만, 이러한 장점 때문에 실제 만들어진 쿼리가 어떠하고 쿼리 수행 시간이 얼마나 걸리는지에 대해서는 추적이 어렵다는 점이 있습니다.이처럼, 파이썬의 특징상 ORM(객체 관계 매핑) 라이브러리를 사용할 경우에 추상화된 쿼리가 어떻게 동작하고, 실제 어떤 상황으로 발생 및 동작되는지를 한눈에 파악할 수 있게 합니다.ORM으로 매핑된 SQL의 순차적인 동작 상태 파악그리고, 세 번째. 외부 호출 추적파이썬 백엔드 개발 시에 사용되는 외부 호출(request/httplib2)등의 외부 호출과 관련된 호출 정보 및 수행 시간 등을 수집합니다.외부 호출을 사용하는 경우에는 각각의 호출에 대한 지연시간에 대해서 세밀하게 추적해야 하므로, 이와 관련된 에러와 지연시간 등을 추적하는 것은 매우 중요한 개발 시의 관점입니다.Python 외부 호출 추적마지막 중요 관점 네 번째는, 튜닝을 위한 다양한 프로파일 데이터의 제공을 이야기할 수 있습니다.와탭의 파이썬 에이전트는 위에서 나열되는 성능 저하를 위한 요소들의 전체적인 관점에서 수집하고 그 데이터들을 시각화할 수 있습니다.데이터베이스를 효율적으로 사용하고 있는지, 사용하는 ORM툴과 매핑과의 관계, 쿼리와 쿼리의 수행 시간과 상태에 대한 추적, 외부 호출시간과 각각의 지연되는 외부 호출과의 관계와 순서 등이 전체적으로 백엔드로 개발되는 Python의 성능 튜닝에 영향을 주게 되는 것이죠.그 이외에도 전체적으로 백엔드 서비스의 TPS, 응답 시간, 서비스 리소스 사용량과 어떤 에러가 발생되고 있는지를 알 수 있습니다.서비스 사용자가 사용하는 상세한 정보들을 프로파 일릉 함으로써 이들의 연관관계를 한분에 파악하게 해줍니다. 와탭에서 관리되는 프로파일 정보는 - 트랜잭션, SQL Query, 외부 HTTP호출, Error, User Agent, Client IP 등의 상관관계들입니다.그리고, 덤으로... Python이 설치 운영되는 전체적인 패키지의 버전을 한눈에 파악할 수 있는 것은 너무도 당연한 기능입니다.설치된 Python 패키지 확인그리고, 와탭의 DNA를 그대로 이어받은 APM이기 때문에, 기본적인 APM의 기능들을 대부분 담고 있습니다. 처음 와탭 APM을 접하시는 분들을 위해서 간단하게 설명드리면 다음과 같습니다.CUBE 메뉴는 시간을 기점으로 와탭 Python APM이 설치된 이후부터 현재까지의 모든 상황들을 추적 관찰할 수 있습니다. 주말에 오류 간 난 상황이라던지, 특정 오류의 발생 시점을 알고 있는 경우에 빠르게 해당 문제가 발생한 위치나 SQL 등을 추적할 수 있습니다.상세한 일간, 주간, 월간 리포트나 MAU 등을 추적할 수 있는 리포트 기능들은 와탭만이 가지고 있는 장점에 해당됩니다.Python으로 백엔드 웹서비스를 개발하고 계시다면, WHATAP Python APM은 개발과 운용을 매우 풍요롭고 빠르게 해줍니다.파이썬 백엔드 서비스 개발자라면 와탭 APM!
조회수 908

할아버지/할머니도 코딩을 해야 하는 이유

대부분의 교육은 초, 중, 고등학생이나 대학생 등 주로 젊은 층을 위주로 진행되고 있습니다. 프로그래밍 교육도 마찬가지로, 현재 10대에서 30대인 주로 젊은 층의 학생과 직장인들을 대상으로 교육이 서서히 일어나고 있습니다. 하지만 높아진 평균 수명으로 노인층이 급격히 늘어나고, 빠르게 변화하는 산업 아래 노인층의 재교육을 통한 지속적인 사회 활동이 요구 되는 시대가 되었습니다.2016년 한국의 인구분포도. 42–57세의 중장년층이 15–24의 청년층보다, 청년층이 0–9세의 유아층보다 월등히 많습니다. Wikipedia위 그래프에서 보이는 것처럼 이렇게 사회의 전체적인 평균 연령의 급격한 상승이 예고되어있음에도 불구하고, 고등학교나 대학까지의 일회성 교육이 아닌 전 연령층을 대상으로 한 지속적인 교육 제공은 아직 보편화 되어 있지 않습니다. 노인층 대상으로 진행되는 교육은 미미하며, 특히나 젊은층도 배우기 어려운 코딩 교육은 노인층에게는 교육이 불가능하거나 전혀 필요하지 않다고 여겨지고 있습니다.UC San Diego 대학의 Phillip Guo 교수Phillip Guo 교수는 HCI (사람-컴퓨터 인터랙션) 및 온라인/컴퓨터 교육 분야에서 명성이 높은 연구자입니다. Guo 교수는 처음으로 노인층에 대한 코딩 교육 연구를 진행하여 온라인에서 프로그래밍을 배운 52개국 60~80대 504명으로부터 다양한 설문조사와 심층조사를 진행한 결과를 CHI 국제 학술회에 출간했습니다. 본 연구 설명과 함께 엘리스에서 생각하는 로드맵을 소개합니다.연구본 연구는 http://www.pythontutor.com 웹사이트에서 실시된 온라인 코딩 교육 설문조사에 응한 504명의 60~85세 학생에 대한 심층 분석과 인터뷰로 이루어져있습니다. 이들이 코딩을 배우는 목적은 세가지 주요 요점으로 종합됩니다.첫째는 코딩을 배움으로서 노화되는 뇌를 자극하기 위함이고, 둘째로 젊은 시절 놓쳤던 새로운 기회를 잡기 위함, 그리고 마지막으로 어린 가족 구성원들과 소통하기 위함이었습니다.혼자 공부하는 방식의 교육은 온라인에서 특히 더 높은 이탈율을 보입니다.이들이 프로그래밍을 배우는 원동력은 교육을 통한 취업과 같은 정확히 정해진 목표보다는, 스스로의 동기부여 및 젊은층과의 소통을 위한 이유가 더 컸습니다. 코딩을 배우는 과정 중에 가장 힘든 세가지는 감퇴하는 인지력, 질문에 대답해 줄 수 있는 강사나 조교 혹은 학생이 없었고, 매번 변화하는 SW를 따라가기 어려움이 있었습니다. 첫번째를 제외한 나머지 어려움은 다른 연령층에서도 겪은 어려움이었습니다.마치며Philip Guo 교수의 논문에서 알 수 있는 것은 노인층이 노화하면서 겪을 수밖에 없는 배움의 어려움과 더불어, 현재 교육 시스템이 노인층을 전혀 고려하지 않고 있다는 것입니다. 이것은 노인층 대상의 교육을 더욱 어렵게 합니다.논문에서는 노인층에게 적합한 교육 시스템이 만들어지거나 제공된다면, 이들이 산업에 바로 투여될 수 있는 능력을 갖추기는 어려울 수도 있으나 프로그래밍 교육을 할 수 있는 선생님으로 활동할 수 있다고 서술하고 있습니다. 이를 활용하면 현재 현저히 부족한 SW 교육자 수로 어려움을 겪고 있는 공교육에 도움이 될 수 있습니다.엘리스에서는 라이브 교육 방송 진행, 헬프 센터 조교 도우미 등 학생들에게 좋은 교육을 제공하기 위해 부단히 노력하는 다양한 연령층의 온라인 조교님들이 계십니다. 언젠가는 60~80대 조교님이 활동하실 수 있다고 믿고 있습니다. 이러한 믿음을 주신 중2 아들을 둔 한 어머니의 피드백을 참조합니다. (엘리스 기초 자바 과정에서 최상위 점수를 받으셨습니다.)저는 전공도 인문학쪽이고 수학 싫어서 문과갔던 문과생인지라, 코딩처럼 논리력 요구하는 수업 따라가기나 할까 큰 기대없이 시작했었습니다.수업 초반에는 마냥 어리둥절했고, 시키는대로 따라하면 다 되었기 때문에 ‘어라 쉽잖아?’ 라고 느꼈습니다. 하지만 중반부 넘어가면서…클래스, 메소드라는 개념이 낯설기도 했고, 각종 연산자의 적용이나 변수들을 식에 적용시키는 다양한 패턴들이 적응이 잘 안되었어요. 반복문의 순서나 마침표,세미콜론, 콜론을 기억하지 못해서 다시 되돌아와서 확인한 것만도 수 십번이었습니다.다른 분들은 마치 초급 과정을 어디서 마스터 하고 온 것처럼 잘 따라가시는데, 저는 매 시간마다 헤매고 오류나고…하지만 똑똑한 것 보다 꾸준한 것이 더 낫다고… ‘머리가 안따라가면 더 오래 공부하면 되겠지’ 하고 다시 보고, 다시 풀고, 계속 질문하고그러나보니 어느 순간 이해가 가는 개념들, 저절로 외워지는 패턴들이 조금씩 늘어났어요.특히 실시간 강의라서 피드백을 받을 수 있고, 조교님이나 강사님들께 질문을 편하게 할 수 있는 시스템이 정말 좋았습니다. 비주얼 좋은 두 분이 수업을 진행해 주신 것도 좋았구요. 반응 좋은 우리 반 수강생들도 참 좋았습니다.저녁 설거지 해 두고 (때로는 저녁상을 치우기 바쁘게) 컴퓨터 앞에 앉아서 8주간 공부한 시간들이 저한테는 정말 소중한 시간이었습니다. 이렇게 집안 일 하고, 애들 챙기면서도 공부할 수 있고, 배울 수 있다는 것이 너무 좋습니다. 좋은 강의 열어주셔서 고맙습니다. ^^*p.s.수업 중에 어떤 분이 자바 알고리즘 강의 열어달라고 하시던데, 알고리즘이 뭔지 물어보고 싶었는데 못 물어봤네요 ㅋ#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개
조회수 1919

Tips for building fast portrait segmentation network with TensorFlow Lite

PrefaceDeep learning has led to a series of breakthroughs in many areas. However, successful deep learning models often require significant amounts of computational resources, memory and power. Deploying efficient deep learning models on mobile devices became the main technological challenge for many mobile tech companies.Hyperconnect developed a mobile app named Azar which has a large fan base all over the world. Recently, Machine Learning Team has been focusing on developing mobile deep learning technologies which can boost user experience in Azar app. Below, you can see a demo video of our image segmentation technology (HyperCut) running on Samsung Galaxy J7. Our benchmark target is a real-time (>= 30 fps) inference on Galaxy J7 (Exynos 7580 CPU, 1.5 GHz) using only a single core.Figure 1. Our network runs fast on mobile devices, achieving 6 ms of single inference on Pixel 1 and 28 ms on Samsung Galaxy J7. Full length video. There are several approaches to achieve fast inference speed on mobile device. 8-bit quantization is one of the popular approaches that meet our speed-accuracy requirement. We use TensorFlow Lite as our main framework for mobile inference. TensorFlow Lite supports SIMD optimized operations for 8-bit quantized weights and activations. However, TensorFlow Lite is still in pre-alpha (developer preview) stage and lacks many features. In order to achive our goal, we had to do the following:Understand details of TensorFlow and Tensorflow Lite implementation.Design our own neural network that can fully utilize optimized kernels of TensorFlow Lite. (Refer to 1, 2 and 3)Modify TOCO: TensorFlow Lite Optimizing Converter to correctly convert unsupported layers. (Refer to 4)Accelerate several quantized-layers with SIMD optimized code. (Refer to 5 and 6)We are willing to share our trials and errors in this post and we hope that readers will enjoy mobile deep learning world :)1) Why is depthwise separable layer fast in Tensorflow Lite ?Implementing low-level programs requires a bit different ideas and approaches than usual. We should be aware that especially on mobile devices using cache memory is important for fast inference.Figure 2. Memory access requires much more energy (640 pJ) than addition or multiplication.Accessing cache memory (8 pJ) is much cheaper than using the main memory (table courtesy of Ardavan Pedram) In order to get insight into how intrinsics instructions are implemented in Tensorflow Lite, we had to analyze some implementations including depthwise separable convolution with 3x3 kernelsBelow we describe some of the main optimization techniques that are used for building lightweight and faster programs.Loop UnrollingCan you spot the difference between the following two code fragments?for (int i = 0; i < 32; i++) { x[i] = 1; if (i%4 == 3) x[i] = 3; } for (int i = 0; i < 8; i++) { x[4*i ] = 1; x[4*i+1] = 1; x[4*i+2] = 1; x[4*i+3] = 3; } The former way is what we usually write, and the latter is loop-unrolled version of former one. Even though unrolling loops are discouraged from the perspective of software design and development due to severe redundancy, with low-level architecture this kind of unrolling has non-negligible benefits. In the example described above, the unrolled version avoids examining 24 conditional statements in for loop, along with neglecting 32 conditional statements of if.Furthermore, with careful implementation, these advantages can be magnified with the aid of SIMD architecture. Nowadays some compilers have options which automatically unroll some repetitive statements, yet they are unable to deal with complex loops.Separate implementation for each caseConvolution layer can take several parameters. For example, in depthwise separable layer, we can have many combinations with different parameters (depth_multiplier x stride x rate x kernel_size). Rather than writing single program available to deal with every case, in low-level architectures, writing number of case-specific implementations is preferred. The main rationale is that we need to fully utilize the special properties for each case. For convolution operation, naive implementation with several for loops can deal with arbitrary kernel size and strides, however this kind of implementation might be slow. Instead, one can concentrate on small set of actually used cases (e.g. 1x1 convolution with stride 1, 3x3 convolution with stride 2 and others) and fully consider the structure of every subproblem.For example, in TensorFlow Lite there is a kernel-optimized implementation of depthwise convolution, targeted at 3x3 kernel size:template <int kFixedOutputY, int kFixedOutputX, int kFixedStrideWidth, int kFixedStrideHeight> struct ConvKernel3x3FilterDepth8 {}; Tensorflow Lite further specifies following 16 cases with different strides, width and height of outputs for its internal implementation:template <> struct ConvKernel3x3FilterDepth8<8, 8, 1, 1> { ... } template <> struct ConvKernel3x3FilterDepth8<4, 4, 1, 1> { ... } template <> struct ConvKernel3x3FilterDepth8<4, 2, 1, 1> { ... } template <> struct ConvKernel3x3FilterDepth8<4, 1, 1, 1> { ... } template <> struct ConvKernel3x3FilterDepth8<2, 2, 1, 1> { ... } template <> struct ConvKernel3x3FilterDepth8<2, 4, 1, 1> { ... } template <> struct ConvKernel3x3FilterDepth8<1, 4, 1, 1> { ... } template <> struct ConvKernel3x3FilterDepth8<2, 1, 1, 1> { ... } template <> struct ConvKernel3x3FilterDepth8<4, 2, 2, 2> { ... } template <> struct ConvKernel3x3FilterDepth8<4, 4, 2, 2> { ... } template <> struct ConvKernel3x3FilterDepth8<4, 1, 2, 2> { ... } template <> struct ConvKernel3x3FilterDepth8<2, 2, 2, 2> { ... } template <> struct ConvKernel3x3FilterDepth8<2, 4, 2, 2> { ... } template <> struct ConvKernel3x3FilterDepth8<2, 1, 2, 2> { ... } template <> struct ConvKernel3x3FilterDepth8<1, 2, 2, 2> { ... } template <> struct ConvKernel3x3FilterDepth8<1, 4, 2, 2> { ... } Smart Memory Access PatternSince low-level programs are executed many times in repetitive fashion, minimizing duplicated memory access for both input and output is necessary. If we use SIMD architecture, we can load nearby elements together at once (Data Parallelism) and in order to reduce duplicated read memory access, we can traverse the input array by means of a snake-path.Figure 3. Memory access pattern for 8x8 output and unit stride, implemented in Tensorflow Lite's depthwise 3x3 convolution. The next example which is targeted to be used in much smaller 4x1 output block also demonstrates how to reuse preloaded variables efficiently. Note that the stored location does not change for variables which are loaded in previous stage (in the following figure, bold variables are reused):Figure 4. Memory access pattern for 4x1 output and stride 2, implemented in Tensorflow Lite's depthwise 3x3 convolution. 2) Be aware of using atrous depthwise convolutionAtrous (dilated) convolution is known to be useful to achieve better result for image segmentation[1]. We also decided to use atrous depthwise convolution in our network. One day, we tried to set stride for atrous depthwise convolution to make it accelerate computation, however we failed, because the layer usage in TensorFlow (≤ 1.8) is constrained.In Tensorflow documentation of tf.nn.depthwise_conv2d (slim.depthwise_conv2d also wraps this function), you can find this explanation of rate parameter.rate: 1-D of size 2. The dilation rate in which we sample input values across the height and width dimensions in atrous convolution. If it is greater than 1, then all values of strides must be 1.Even though TensorFlow doesn’t support strided atrous function, it doesn’t raise any error if you set rate > 1 and stride > 1. <!-- The output of layer doesn't seem to be wrong. -->>>> import tensorflow as tf >>> tf.enable_eager_execution() >>> input_tensor = tf.constant(list(range(64)), shape=[1, 8, 8, 1], dtype=tf.float32) >>> filter_tensor = tf.constant(list(range(1, 10)), shape=[3, 3, 1, 1], dtype=tf.float32) >>> print(tf.nn.depthwise_conv2d(input_tensor, filter_tensor, strides=[1, 2, 2, 1], padding="VALID", rate=[2, 2])) tf.Tensor( [[[[ 302.] [ 330.] [ 548.] [ 587.]] [[ 526.] [ 554.] [ 860.] [ 899.]] [[1284.] [1317.] [1920.] [1965.]] [[1548.] [1581.] [2280.] [2325.]]]], shape=(1, 4, 4, 1), dtype=float32) >>> 0 * 5 + 2 * 6 + 16 * 8 + 9 * 18 # The value in (0, 0) is correct 302 >>> 0 * 4 + 2 * 5 + 4 * 6 + 16 * 7 + 18 * 8 + 20 * 9 # But, the value in (0, 1) is wrong! 470 Let’s find the reason why this difference happened. If we just put tf.space_to_batch and tf.batch_to_space before and after convolution layer, then we can use convolution operation for atrous convolution (profit!). On the other hand, it isn’t straightforward how to handle stride and dilation together. In TensorFlow, we need to be aware of this problem in depthwise convolution.3) Architecture design principles for efficient segmentation networkUsually segmentation takes more time than classification since it has to upsample high spatial resolution map. Therefore, it is important to reduce inference time as much as possible to make the application run in real-time.It is important to focus on spatial resolution when designing real-time application. One of the easiest ways is to reduce the size of input images without losing accuracy. Assuming that the network is fully convolutional, you can accelerate the model about four times faster if the size of input is halved. In literature[2], it is known that small size of input images doesn’t hurt accuracy a lot.Another simple strategy to adopt is early downsampling when stacking convolution layers. Even with the same number of convolution layers, you can reduce the time with strided convolution or pooling within early layers.There is also a tip for selecting the size of input image when you use Tensorflow Lite quantized model. The optimized implementations of convolution run best when the width and height of image is multiple of 8. Tensorflow Lite first loads multiples of 8, then multiples of 4, 2 and 1 respectively. Therefore, it is the best to keep the size of every input of layer as a multiple of 8.Substituting multiple operations into single operation can improve speed a bit. For example, convolution followed by max pooling can be usually replaced by strided convolution. Transpose convolution can also be replaced by resizing followed by convolution. In general, these operations are substitutable because they perform the same role in the network. There are no big empirical differences among these operations. <!-- substitutable -->Tips described above help to accelerate inference speed but they can also hurt accuracy. Therefore, we adopted some state-of-the-art blocks rather than using naive convolution blocks.Figure 5.  Atrous spatial pyramid pooling (figure courtesy of Liang-Chieh Chen) Atrous spatial pyramid pooling[1] is a block which mimics the pyramid pooling operation with atrous convolution. DeepLab uses this block in the last layer.We also substitute most of the convolution layers with efficient depthwise separable convolution layers. They are basic building blocks for MobileNetV1[3] and MobileNetV2[4] which are well optimized in Tensorflow Lite.4) Folding batchnorm into atrous depthwise convolutionWhen quantizing convolution operation followed by batchnorm, batchnorm layer must be folded into the convolution layers to reduce computation cost. After folding, the batchnorm is reduced to folded weights and folded biases and the batchnorm-folded convolution will be computed in one convolution layer in TensorFlow Lite[5]. Batchnorm gets automatically folded using tf.contrib.quantize if the batchnorm layer comes right after the convolution layer. However, folding batchnorm into atrous depthwise convolution is not easy.In TensorFlow’s slim.separable_convolution2d, atrous depthwise convolution is implemented by adding SpaceToBatchND and BatchToSpaceND operations to normal depthwise convolution as mentioned previously. If you add a batchnorm to this operation by including argument normalizer_fn=slim.batch_norm, batchnorm does not get attached directly to the convolution layer. Instead, the graph will look like the diagram below: SpaceToBatchND → DepthwiseConv2dNative → BatchToSpaceND → BatchNorm The first thing we tried was to modify TensorFlow quantization to fold batchnorm bypassing BatchToSpaceND without changing the order of operations. With this approach, the folded bias term remained after BatchToSpaceND, away from the convolution layer. Then, it became separate BroadcastAdd operation in TensorFlow Lite model rather than fused into convolution. Surprisingly, it turned out that BroadcastAdd was much slower than the corresponding convolution operation in our experiment:Timing log from the experiment on Galaxy S8 ... [DepthwiseConv] elapsed time: 34us [BroadcastAdd] elapsed time: 107us ... To remove BroadcastAdd layer, we decided to change the network itself instead of fixing TensorFlow quantization. Within slim.separable_convolution2d layer, we swapped positions of BatchNorm and BatchToSpaceND. SpaceToBatchND → DepthwiseConv2dNative → BatchNorm → BatchToSpaceND Even though batchnorm relocation could lead to different outputs values compared to the original, we did not notice any degradation in segmentation quality.5) SIMD-optimized implementation for quantized resize bilinear layerAt the time of accelerating TensorFlow Lite framework, conv2d_transpose layer was not supported. However, we could use ResizeBilinear layer for upsampling as well. The only problem of this layer is that there is no quantized implementation, therefore we implemented our own SIMD quantized version of 2x2 upsampling ResizeBilinear layer.Figure 6. 2x2 bilinear upsampling without corner alignnment. To upsample image, original image pixels (red circles) are interlayed with new interpolated image pixels (grey circles). In order to simplify implementation we do not compute pixel values for the bottommost and rightmost pixels, denoted as green circles.for (int b = 0; b < batches; b++) { for (int y0 = 0, y = 0; y <= output_height - 2; y += 2, y0++) { for (int x0 = 0, x = 0; x <= output_width - 2; x += 2, x0++) { int32 x1 = std::min(x0 + 1, input_width - 1); int32 y1 = std::min(y0 + 1, input_height - 1); ResizeBilinearKernel2x2(x0, x1, y0, y1, x, y, depth, b, input_data, input_dims, output_data, output_dims); } } } Every new pixel value is computed for each batch separately. Our core function ResizeBilinearKernel2x2 computes 4 pixel values across multiple channels at once.Figure 7. Example of 2x2 bilinear upsampling of top left corner of image. (a) Original pixel values are simply reused and (b) – (d) used to interpolate new pixel values. Red circles represent original pixel values. Blue circles are new interpolated pixel values computed from pixel values denoted as circles with black circumference. NEON (Advanced SIMD) intrinsics enable us to process multiple data at once with a single instruction, in other words processing multiple data at once. Since we deal with uint8 input values we can store our data in one of the following formats uint8x16_t, uint8x8_t and uint8_t, that can hold 16, 8 and 1 uint8 values respectively. This representation allows to interpolate pixel values across multiple channels at once. Network architecture is highly rewarded when channels of feature maps are multiples of 16 or 8:// Handle 16 input channels at once int step = 16; for (int ic16 = ic; ic16 <= depth - step; ic16 += step) { ... ic += step; } // Handle 8 input channels at a once step = 8; for (int ic8 = ic; ic8 <= depth - step; ic8 += step) { ... ic += step; } // Handle one input channel at once for (int ic1 = ic; ic1 < depth; ic1++) { ... } SIMD implementation of quantized bilinear upsampling is straightforward. Top left pixel value is reused (Fig. 7a). Bottom left (Fig. 7b) and top right (Fig. 7c) pixel values are mean of two adjacent original pixel values. Finally, botom right pixel (Fig. 7d) is mean of 4 diagonally adjacent original pixel values.The only issue that we have to take care of is 8-bit integer overflow. Without a solid knowledge of NEON intrinsics we could go down the rabbit hole of taking care of overflowing by ourself. Fortunately, the range of NEON intrinsics is broad and we can utilize those intrinsics that fit our needs. The snippet of code below (using vrhaddq_u8) shows an interpolation (Fig. 7d) of 16 pixel values at once for bottom right pixel value:// Bottom right output_ptr += output_x_offset; uint8x16_t left_interpolation = vrhaddq_u8(x0y0, x0y1); uint8x16_t right_interpolation = vrhaddq_u8(x1y0, x1y1); uint8x16_t bottom_right_interpolation = vrhaddq_u8(left_interpolation, right_interpolation); vst1q_u8(output_ptr, bottom_right_interpolation); 6) Pitfalls in softmax layer and demo codeThe first impression of inference in TensorFlow Lite was very slow. It took 85 ms in Galaxy J7 at that time. We tested the first prototype of TensorFlow Lite demo app by just changing the output size from 1,001 to 51,200 (= 160x160x2)After profiling, we found out that there were two unbelievable bottlenecks in implementation. Out of 85 ms of inference time, tensors[idx].copyTo(outputs.get(idx)); line in Tensor.java took up to 11 ms (13 %) and softmax layer 23 ms (27 %). If we would be able to accelerate those operations, we could reduce almost 40 % of the total inference time!First, we looked at the demo code and identified tensors[idx].copyTo(outputs.get(idx)); as a source of problem. It seemed that the slowdown was caused by copyTo operation, but to our surprise it came from int[] dstShape = NativeInterpreterWrapper.shapeOf(dst); because it checks every element (in our case, 51,200) of array to fill the shape. After fixing the output size, we gained 13 % speedup in inference time.<T> T copyTo(T dst) { ... // This is just example, of course, hardcoding output shape here is a bad practice // In our actual app, we build our own JNI interface with just using c++ code // int[] dstShape = NativeInterpreterWrapper.shapeOf(dst); int[] dstShape = {1, width*height*channel}; ... } The softmax layer was our next problem. TensorFlow Lite’s optimized softmax implementation assumes that depth (= channel) is bigger than outer_size (= height x width). In classification task, the usual output looks like [1, 1(height), 1(width), 1001(depth)], but in our segmentation task, depth is 2 and outer_size is multiple of height and width (outer_size » depth). Implementation of softmax layer in Tensorflow Lite is optimized for classification task and therefore loops over depth instead of outer_size. This leads to unacceptably slow inference time of softmax layer when used in segmentation network.We can solve this problem in many different ways. First, we can just use sigmoid layer instead of softmax in 2-class portrait segmentation. TensorFlow Lite has very well optimized sigmoid layer.Secondly, we could write SIMD optimized code and loop over depth instead of outer_size. You can see similar implementation at Tencent’s ncnn softmax layer, however, this approach has still its shortcomings. Unlike ncnn, TensorFlow Lite uses NHWC as a default tensor format:Figure 8. NHWC vs NCHW In other words, for NHWC, near elements of tensor hold channel-wise information and not spatial-wise. It is not simple to write optimized code for any channel size, unless you include transpose operation before and after softmax layer. In our case, we tried to implement softmax layer assumming 2-channel output.Thirdly, we can implement softmax layer using pre-calculated lookup table. Because we use 8-bit quantization and 2-class output (foreground and background) there are only 65,536 (= 256x256) different combinations of quantized input values that can be stored in lookup table:for (int fg = 0; fg < 256; fg++) { for (int bg = 0; bg < 256; bg++) { // Dequantize float fg_real = input->params.scale * (fg - input->params.zero_point); float bg_real = input->params.scale * (bg - input->params.zero_point); // Pre-calculating Softmax Values ... // Quantize precalculated_softmax[x][y] = static_cast<uint8_t>(clamped); } } ConclusionIn this post, we described the main challenges we had to solve in order to run portrait segmentation network on mobile devices. Our main focus was to keep high segmentation accuracy while being able to support even old devices, such as Samsung Galaxy J7. We wish our tips and tricks can give a better understanding of how to overcome common challenges when designing neural networks and inference engines for mobile devices.At the top of this post you can see portrait segmentation effect that is now available in Azar app. If you have any questions or want to discuss anything related to segmentation task, contact us at [email protected]. Enjoy Azar and mobile deep learning world!References[1] L. Chen, G. Papandreou, F. Schroff, H. Adam. Rethinking Atrous Convolution for Semantic Image Segmentation. June 17, 2017, https://arxiv.org/abs/1706.05587[2] C. Szegedy, V. Vanhoucke, S. Ioffe, J. Shlens, Z. Wojna. Rethinking the Inception Architecture for Computer Vision. December 11, 2015, https://arxiv.org/abs/1512.00567[3] A. Howard, M. Zhu, B. Chen, D. Kalenichenko, W. Wang, T. Weyand, M. Andreetto, H. Adam. MobileNets: Efficient Convolutional Neural Networks for Mobile Vision Applications, April 17, 2017, https://arxiv.org/abs/1704.04861[4] M. Sandler, A. Howard, M. Zhu, A. Zhmoginov, L. Chen. MobileNetV2: Inverted Residuals and Linear Bottlenecks. January 18, 2018, https://arxiv.org/abs/1801.04381[5] B. Jacob, S. Kligys, B. Chen, M. Zhu, M. Tang, A. Howard, H. Adam, D. Kalenichenko. Quantization and Training of Neural Networks for Efficient Integer-Arithmetic-Only Inference. December 15, 2017, https://arxiv.org/abs/1712.05877
조회수 1105

주니어 개발자가 외칩니다, "Hello, System Architecture!"

Overview주니어 개발자는 시스템 아키텍처(System Architecture) 또는 시스템 디자인(System Design)이라는 단어에 덜컥 겁부터 먹습니다. 지금 진행하고 있는 개발에만 집중하다 보니 큰 그림을 놓치고 있는 게 아닐까 란 생각이 들었죠. 조금 더 큰 그림을 보고자 공부를 시작했습니다. 문득 같은 생각을 하는 주니어 개발자 분들도 많을 것 같다고 생각했어요. 그래서 이번 글은 시스템 아키텍처에 ㅇ_ㅇ? 뀨? 하는 표정을 짓는 주니어 개발자들을 위해 썼습니다.상상의 나래: 가상의 패션 e커머스상상의 나래를 펼쳐봅시다. 패션 e커머스 서비스를 이용하는 김유저 씨가 구매한 옷이 마음에 들어 상품 리뷰를 남기고 싶어한다고요.김유저 씨는 본인의 착용 사진과 텍스트 리뷰를 작성하고 ‘리뷰 등록하기’ 버튼에 엔터를 탁! 누를 겁니다. 그런데 말이죠. 김유저 씨는 요청하고 싶은 웹서버의 IP 주소를 모르기 때문에 요청을 보낼 수가 없습니다.내 정체를 알려줘: DNS (Domain Name System)그래서, DNS(Domain Name System)에게 물어봅니다. 서버의 도메인 이름으로부터 해당 서버의 IP 주소를 알려주는 것이 바로 DNS입니다. 도메인 이름에 대한 질의를 하고, 만일 해당 도메인 이름이 DNS에 ‘A Record’ 형태로 등록이 되어 있다면 도메인 이름에 해당하는 IP 주소를 응답으로 돌려줍니다.서비스에서 자체 DNS 시스템을 가지고 있을 수 있습니다. 예를 들어 Route 53, Cloud Flare같은 서비스가 있습니다. 그렇다면 또 한 가지 의문이 생깁니다. 왜 서비스는 시스템적 부담을 안고서 자체 DNS 서버를 구축하고 있는 걸까요? 그 이유로 두 가지를 꼽을 수 있습니다.첫 번째로는 신뢰도가 높습니다. 직접 DNS Record를 관리 및 운영하기 때문입니다. 두 번째로는 보안이 우수합니다. 만약 공개하고 싶지 않은 IP 주소, 예를 들어 Database IP 주소 같은 건 공개하지 않습니다. 1)작업장소: Web Server이제 웹서버의 IP 주소를 알았으니 통신을 시도합니다. 웹서버는 웹서비스에서 필요로 하는 다양한 요청과 그에 대한 응답을 제공합니다. 클라이언트가 리뷰에 대한 사진과 텍스트를 등록하고 싶다면 웹서버에게 등록하라는 요청을 보내야 합니다.웹서버에서 요청을 받으면 사용자가 요구한 대로 사진과 텍스트를 등록하고, 그에 대한 결과 정보를 응답으로 보내줄 것입니다. 웹서버 내부에서는 그 과정에 필요한 연산을 수행합니다. 서버 개발자는 이 연산에 대한 코드를 작성하고요.센스가 없는 서버:API (Application Programing Interface)서버는 사람이 아닙니다. 센스나 재치가 없죠. 미리 정의되지 않은 요청은 대응하지 못합니다. (어버버버버 퉤! Error 404!) 그래서 약속한 요청을 보내면 약속한 방식으로 응답해줄게라고 명세를 제공합니다.약속한 요청으로 데이터를 보내면 원하는 요청에서 데이터를 정제해 잘 처리했는지, 또는 처리된 데이터를 약속한 방식(예를 들어, JSON 방식)으로 내보내죠. 웹서버는 정의된 API에 맞춰 요청과 응답을 합니다.그런데 웹서버가 수많은 요청을 받고 응답하면 과부하가 일어날 수도 있습니다. 사용자 수가 어마어마한 규모로 늘어나서 서버가 펑! 하고 터진다면, 김유저 씨는 서비스를 더 이상 이용할 수 없을 겁니다. 이용하고 싶지도 않을 겁니다!따라서, 서버가 감당하는 요청을 나누기 위해 같은 역할을 하는 서버 장비 수를 늘릴 수도 있습니다. 그러면 요청이 각기 다른 웹서버 장비에 분산되어 한 번에 감당할 수 있는 요청 수가 더욱 많아집니다.이 구역의 매니저는 나야: Load Balancer그림처럼 서버가 4대 존재하는 상황이라면, 서버 4대에 일을 적절히 분배해주는 역할이 필요합니다. 그것이 로드 밸런서(Load Balancer)입니다. 로드 밸런서가 서버에게 일을 나누는 방법론은 여러 가지가 있습니다.Random: 랜덤으로 분배하기Least loaded: 가장 적은 양의 작업을 처리하고 있는 서버에게 요청을 할당하기Round Robin: 순서를 정하여 돌아가며 작업 분배하기많이 쓰는 로드 밸런서의 종류는 Layer 4, Layer 7을 꼽을 수 있습니다.Layer 4 Load Balancer: 데이터의 내용을 보지 않고 IP주소 및 TCP/UDP 정보에 따라 단순히 분배를 해줍니다.Layer 7 Load Balancer: 서버가 하는 역할이 분리되어 있는 환경에서 데이터의 내용을 보고 각기 맞는 역할을 하는 서버에게 분배를 해줍니다.로드 밸런서는 클라이언트가 요청을 보내야 할 서버를 골라야 하는 부담을 덜어주며, 로드 밸런서에게 할당된 vIP (가상 IP)로 요청을 보내기만 하면 로드 밸런서에서 알아서 작업을 나눠줍니다. 서버에서는 적절한 로드 밸런서를 사용하면 들어오는 요청이 여러 장비에 분산되어 처리량이 늘어나고 응답 시간이 줄어드는 효과를 기대할 수 있습니다. 컨텐츠 저장소: CDN(Content Delivery Network)이제 웹서버가 클라이언트의 요청에 의해 웹페이지에 대한 응답 결과를 돌려줬습니다. 이때 클라이언트의 화면에 렌더링해야 하는 수많은 이미지가 필요합니다. 이 이미지들을 웹서버가 전부 주려면 데이터의 용량이 너무 크고, 무거워서 서버가 헥헥거리죠. (서버가 죽으면 어떻게 될까요? 클라이언트님이 경쟁사로 환승하겠죠.. 안 돼요..) 따라서 웹서버는 직접 이미지를 주는 대신 CDN(Content Delivery Network)에게 요청하라고 이야기합니다. CDN은 일반적으로 용량이 큰 컨텐츠 데이터(이미지, 비디오, 자바스크립트 라이브러리 등)를 빠른 속도로 제공하기 위해 사용자와 가까운 곳에 분산되어 있는 데이터 저장 서버입니다. 클라이언트는 용량이 큰 컨텐츠 데이터를 가까운 CDN에 요청해 멀리 있는 웹서버에서 직접 받는 것보다 빠르게 받을 수 있습니다. CDN이 동작하는 방식에는 크게 Push CDN, Pull CDN이 있습니다. Push CDN: 서버에서 컨텐츠가 업로드되거나, 변경되었을 때 모두 반영하는 방식 Pull CDN: 클라이언트가 요청할 때마다 컨텐츠가 CDN에 새로 저장되는 방식 두 방식 모두 장단점이 있습니다. Push CDN은 모든 컨텐츠를 갖고 있기에 웹서버에 요청할 일이 없지만 유지하는데 필요한 용량과 비용이 많이 필요하겠죠? Pull CDN은 클라이언트가 요청한 컨텐츠가 있으면 바로 응답하지만 그렇지 않을 땐 데이터를 웹서버로부터 가져와야 하기 때문에 서버에 요청하는 부담이 존재합니다. 컨텐츠명은 그대로인데 내용만 변경되었다면 인지하지 못하고 옛버전의 컨텐츠를 제공하죠. 그래서 Pull CDN에 들어가는 컨텐츠는 TTL(Time To Live)이 적용됩니다. TTL이란 유통기한이라고 생각하면 쉽습니다. 일정시간이 지나면 해당 데이터가 삭제되는 것이죠. 이런 방식이 적용된다면 Pull CDN의 최대 단점을 보완할 수 있습니다. 이렇게 보완이 되면 수정된 데이터에 대해서도 대응이 가능하며 서버의 용량 즉, 비용적 부담이 해소될 겁니다.소중한 내 데이터: Database서비스를 제공하다 보면 클라이언트의 소중한 정보, 이력, 상품 가격, 상품 정보 등 다양한 데이터를 저장하고, 또 제공합니다. 하지만 수많은 데이터를 웹서버에 전부 저장하고 사용하기엔 데이터의 양이 너무 많아 저장 공간도 부족하고, 데이터를 원하는 모양에 맞게 정제하기가 어렵습니다. 그래서 데이터를 저장하는 데이터베이스 서버가 따로 존재합니다.민감한 정보를 다루는 데이터베이스는 ACID라는 성질을 만족해야 하는데요.Atomicity(원자성): 데이터베이스에 적용되는 명령이 중간만 실행되지 않고 완전히 성공하거나 완전히 실패해야 한다는 것을 의미합니다. 반만 적용된 명령이 있다면 헷갈리겠죠.Consistency(일관성): 데이터베이스가 수행한 명령이 일관적으로 반영되어 있어야 한다는 의미입니다. 예를 들어 계좌에 돈을 입금했는데 잔고에 반영되지 않는다면 당황스러울 겁니다.Isolation(고립성): 데이터베이스가 수행하는 명령 도중 다른 명령이 끼어들지 못한다는 것을 의미합니다.Durability(지속성): 성공적으로 수행한 명령은 영원히 그 이후 상태로 남아있어야 한다는 걸 의미합니다. 갑자기 하루 뒤에 명령이 취소되거나 이전 상태로 롤백되면 안 됩니다. Replication (복제 / 이중화)큰 시스템에서는 똑같은 데이터베이스가 여럿 존재한다고 하는데요. 그렇다면 왜 비용적인 부담을 안으면서까지 복제 데이터베이스를 구축해놓는 걸까요? 만약에 데이터베이스가 정상적으로 동작하지 않는다면 클라이언트의 데이터를 변경하지 못하며, 클라이언트가 원하는 정보를 제공하지 못하는 불상사가 일어나게 됩니다. 글로만 써도 벌써 땀이 납니다. 그러므로 복제해놓은 데이터베이스를 얼른 마스터로 등업해 데이터 흐름에 차질이 없도록 대비해야 합니다.만약 하나의 데이터베이스가 어떤 일을 수행할 때 다른 요청들은 계속 기다려야 합니다. 그렇다면 데이터를 변경하는 데이터베이스는 하나, 읽기만 하는 데이터베이스는 여러 대가 존재해도 되지 않을까요? 바로 여기서 Master-Slave의 개념이 탄생합니다.master-slave-replicaMaster-Slave Replica (a.k.a 주인-노예)요청을 분산하기 위해서 데이터베이스를 늘리다 보면 master-slave 토픽이 등장합니다.Mater: CRUD(Create, Read, Update, Delete)가 모두 가능Slave: R(Read)만 가능Master가 데이터를 변경할 동안 읽기에 대한 요청은 Slave에게 보내집니다. 그렇게 하면 읽기 요청은 분산되어 훨씬 더 수월하고 빠른 속도로 데이터 처리가 가능할 것입니다. 만약 Master가 변경된다면 아래 계급인 Slave, Replica 데이터베이스에게도 이 정보를 전해야 합니다. 다시 말해, 자신에게 들어온 요청(Query)을 동일하게 보내 빠른 시간 안에 동기화를 시켜주죠. 하지만 동기화도 시간이 걸리는 작업이므로 무한대로 Slave Replica를 늘려 확장하기는 어렵습니다.Master-Master Replica의문이 하나 생길 겁니다. “여러 대의 Master를 두어서 변경도 가능하고, 읽기도 가능하게 하면 되지 않을까?”앞서 언급했듯이 같은 데이터의 변경 가능한 데이터베이스는 하나여야 할 것입니다. 동시에 같은 데이터를 변경했을 때 갈등을 해소하기 위한 방법론은 존재하지만, 그 방식이 복잡하고 오래 걸립니다. 안정성도 낮아지고, 효율도 떨어집니다. 그래서 Master-Slave 아키텍처를 선호하는 것이죠.Sharding그러면 같은 데이터베이스 테이블을 동시에 변경하는 건 불가능한 걸까요? 그것을 해소하기 위해 샤딩(Sharding)이라는 방법론을 사용합니다. 샤딩된 테이블은 개념적으론 하나의 테이블처럼 보이지만 사실 그 내용물이 쪼개져 있습니다. 쪼개는 방법은 여러 가지 선택할 수 있습니다만, 분명한 건 겹치는 데이터 없이 쪼갠다는 것입니다. 그래서 같은 테이블이어도 쪼개져 있다면 그 테이블에 동시에 접근해 데이터를 변경할 수 있는 것이죠.이외에 서비스별, 기능별로 쪼개어 데이터베이스를 관리하는 Federation 등 많은 데이터베이스 디자인 방법론이 존재합니다.시스템 아키텍처가 가지고 있어야 할 최소본 아키텍처요점: 시스템 아키텍쳐에서 고려해야 할 성질이렇게 간단한 시스템 아키텍처의 면면을 살펴봤습니다. 시스템 개발자라면 시스템을 디자인하면서 반드시 고려해야 할 성질들을 만날 텐데요. 위에서 소개한 내용들 역시 아래의 성질들을 충족하기 위해 탄생했다고 볼 수 있습니다.Scalability (확장성): 10만 명의 요청을 처리할 수 있는 시스템과 1000만 명의 요청을 처리할 수 있는 시스템은 다릅니다. 확장성을 고려한 시스템은 앞으로 클라이언트 수가 늘어났을 때 무리 없이 모든 요청을 처리할 수 있을 겁니다.Performance (성능): 속도와 정확성을 말합니다. 요청한 내용을 정확하고 빠르게 돌려주어야 합니다.Latency (응답 시간): 모든 요청은 클라이언트가 불편해하지 않을 정도로 빠른 시간 안에 돌려주어야 합니다.Throughput (처리량): 같은 시간 안에 더욱 많은 요청을 처리한다면 좋은 시스템입니다.Availability (접근성): 사용자가 언제든지 시스템에 요청을 보내서 응답을 받을 수 있어야 합니다. 비록 서버 장비 한두 대가 문제가 생겨 제 기능을 하지 못하더라도 사용자는 그 사실을 몰라야 합니다.Consistency (일관성): 사용자가 서버에 보낸 요청이 올바르게 반영되어야 하고, 일정한 결과를 돌려주어야 합니다. 요청을 보낼 때마다 불규칙한 결과를 돌려준다면 믿을 수 없는 서비스가 될 것입니다.결론발로 그렸나 싶을 정도의 그림과 기나긴 글을 마무리 지으며주니어 개발자로서 시스템 아키텍처를 공부하면서 느낀 점이 있다면 시스템에 대한 완벽한 대응은 없으며, 모두 장단점이 존재한다는 것입니다. (이것을 보통 trade-off라고 표현합니다.)하지만 설계하는 서비스를 잘 알고 서비스에서 무게를 둬야 할 부분을 파악한다면, 그에 맞는 시스템을 설계하고 디자인할 수 있을 겁니다. 김유저 씨도 만족시킬 수 있을 거고요. 꼬박 이틀을 밤새워서 쓴 글이 아직 시스템 아키텍처를 두려워하는 다른 주니어 개발자분들에게 도움이 되었으면 합니다. 이번에는 시스템에서 아주 기초적인 부분을 공부했으니 다음 글에선 MSA(MicroService Architecture)를 씹어봅시다! 겁이 나고 무서워도 외쳐보세요. “Hello, System Architecture!”이 세상 모든 주니어 개발자분들, 퐈잇팅입니다.참고1) 추가적인 이점에 대하여: 웹서버에서 요청을 보낼 때 database 도메인 네임으로 보낼 경우, 멀리 있는 공인 DNS 서버 (예를 들면 google public DNS server: 8.8.8.8)에 물어오는 것보다 자체 DNS 서버에 물어오는 것이 훨씬 더 빠른 속도로 응답을 받아올 수 있습니다.출처GitHub - donnemartin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.글오연주 사원 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #주니어개발자

기업문화 엿볼 때, 더팀스

로그인

/