스토리 홈

인터뷰

피드

뉴스

조회수 1738

Database를 왜 사용할까요?

개발자들이 Database 프로그램을 선택한 이유Database(이하 DB) 프로그램을 처음 접한 건 Dos에서 사용하는 Database III plus였습니다. 이때는 학생이었기 때문에 프로그램 개발에 관심이 많았지만 대량의 데이터를 다룰 일은 없었습니다. 다음으로 접한 건 clipper였습니다. 과거 C언어를 하던 사람이면 자료 처리를 위해 한 번쯤은 접해봤을 겁니다. 이때까지는 Dos를 주로 사용했고, 간단한 자료를 다루었기 때문에 File 처리만으로도 충분한 결과를 얻을 수 있었죠.그렇다면 DB는 다중 사용자 환경이 되고 바로 사용하게 되었을까요? 예전에 다중 사용자들이 사용했던 걸 꼽자면 PC 통신과 Web이 있을 것입니다. 초창기의 Web은 PHP, ASP가 개발되기 전이었고 Java는 C보다 성능이 낮아 CGI를 C로 구현했으니 게시판이나 자료실 등도 C로 개발했습니다.규모가 큰 PC 통신은 DB를 사용했지만 사설 BBS나 01410 등에 들어가는 외부 업체는 File로 처리했습니다. 이 시기에 사설 BBS나 01410 서비스를 제공하는 업체들은 Workstation을 구입하거나 x86 계열을 구입해 운영체제 (SCO UNIX, Free BSD, Linux 등)를 사용했지만 이때 역시 C로 개발을 했었습니다. 이런 환경에서 점점 File 처리의 한계가 나타나기 시작했던 것이죠.C File lock 예)int iFd, iResult; iFd = open(“LockTest”,O_RDWR);  iResult = lockf(iFd, F_LOCK,10L); /* 필요한 작업 처리 */ close(iFd); 유저가 늘어나고 운영 체제 내부적으로 동시에 처리하는 프로세스가 증가하면서 자료가 깨지는 현상이 나타납니다. 개발자들은 어쩔 수없이 DB를 선택하기 시작했습니다.DB의 장점들DB를 도입하면 여러 가지 장점이 생깁니다. SQL 문장만 익히면 프로그램으로 일일이 구현해야 했던 것들을 명령어만으로 수행할 수 있고 자료의 무결성 또한 보장해 주며, 개발의 생산성까지 높입니다. 만약 특정 날짜의 자료들을 읽어와서 제목 순으로 보여줘야 할 경우, 프로그램으로 개발한 자료를 날짜 별로 읽어 배열에 담고 Quick sort 알고리즘을 적용해 정렬한 후 자료를 보여줘야 합니다. 하지만 DB에서 SQL 문장을 사용하면 간단하게 완성할 수 있습니다. SELECT * FROM TABLE WHERE DATETIME = 날짜 ORDER BY TITLE ; 조심 또 조심!하지만 DB 역시 만능은 아니기 때문에 모든 자료를 처리할 수는 없습니다. 예를 들어 문서(pdf, doc, hwp등) , 이미지(jpg, gif 등), 압축(zip,rar 등) 등의 바이너리 파일입니다. (물론 DB에서 BLOB 자료형을 지원하므로 하드웨어 자원과 성능만 받쳐준다면 불가능한 것은 아닙니다.) 하드웨어 자원과 성능에는 한계가 있기 때문에 DB로 해야 할 일과 하지 말아야 할 일을 구분해야 합니다. 만약 이를 생각하지 않고 DB에 모든 자료를 넣는다면 어떤 문제가 생길까요? 크게 두 가지가 있습니다.첫 번째는 바이너리를 파일을 읽고 쓸 때 발생하는 시간이 문제가 될 수 있습니다. 그 이유는 DB가 Connection Pool로 접속을 관장하는데, 이는 한정된 자원으로 최소한의 시간을 사용해야 많은 유저가 사용할 수 있기 때문입니다. 만약 바이너리 파일을 DB에 올리면서 오랜 시간 접속을 유지한다면 그만큼 다른 유저가 사용할 수 없을 테고, 결국은 DB에서 감당할 수 있는 유저의 수가 줄어들 것입니다.두 번째는 백업의 문제가 있습니다. 우리는 DB에 장애가 발생할 때를 대비해 DB 전체 백업을 합니다. 그런데 DB에 바이너리 파일이 들어가면 백업 시간이 많이 늘어나 원하는 시간 안에 백업을 하지 못하는 일이 발생할 수도 있습니다. 따라서 DB에 바이너리 파일을 넣을 때는 아주 적은 용량의 파일만 넣어야 합니다. 배치에 대하여: OLTP, OLAPDB 용량이 커지면 Query를 수행해도 원하는 결과를 볼 수 없고 DB에 부담을 많이 주는 Query가 발생합니다. 그래서 주기적으로 Query를 돌려 결과를 테이블에 넣고 필요할 때마다 이를 볼 수 있게 배치 처리를 하며 해결합니다. 일, 월, 년 단위의 집계 자료를 구축하면서 시스템에 부하를 줄 수 있기 때문에 보통 야간에 처리를 하죠. 그런데 만약 DB 용량이 너무 커져서 전일자 집계를 배치로 처리하지 못하는 일이 발생하면 어떻게 할까요?여기서 사용할 수 있는 것이 OLAP(OnLine Analytical Processing) DB입니다. 일반적으로 유저가 사용하는 건 OLTP(OnLine Transaction Processing) 입니다. 대표적으로 Oracle, MySQL PostgreSQL 등이 있습니다. 여기서 MySQL 을 제외하고 Oracle과 PostgreSQL 은 Partition, HASH 조인, Parallel을 지원하여 OLAP 환경에서도 어느 정도 사용 가능합니다.OLAP DB는 주로 DW 환경에서 사용하며 대표적으로 Teradata와 Oracle Exadata 등이 있습니다. OLAP DB 와 비교가 안 될 정도를 빠르게 배치 작업을 처리할 수 있습니다. (자세한 내용은 다음 글에서 설명하겠습니다.)Conclusion지금까지의 이야기를 정리하면 ‘여러 유저가 동시에 안정적으로 자료 처리를 하려면 DB를 사용하고, 자료의 양과 처리 형태(OLAP, OLTP) 에 따라 DB를 선택하면 된다’는 것이었습니다. 자세한 설명을 하자면 각 DB별 특성을 기술해야 하기 때문에 오늘은 전체적인 내용부터 살펴봤습니다. 다음 글에서는 유저가 사용하는 OLTP에 대해 살펴보겠습니다. 글한석종 부장 | R&D 데이터팀[email protected]#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 1057

블록체인 진짜 하나도 모르는 디자이너의 독학일기(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시가 되면 = 잠을 자라.(규칙)
조회수 1133

안드로이드 디버깅 방법

디버깅(Debugging)은 오류가 발생했을 때 발생 위치를 확인할 수 있는 방법입니다. 앱이 일시 중지된 상태에서 변수를 검사하고 식을 평가해 런타임 오류 원인을 판별할 수 있죠. 중단점 걸기우선 확인하고 싶은 라인에 중단점을 걸어 앱 실행을 일시 중지합니다. 중단점을 거는 방법은 라인 옆의 빈공간을 클릭 하거나 단축키 (Command+F8 / Control+F8)를 클릭합니다. 아래 이미지의 라인 옆의 빨간 점이 중단점입니다.앱이 실행 중일 때오른쪽 상단의 Attach debugger to Android process를 클릭해 디버깅 모드를 실행할 수 있습니다.앱이 실행 중이지 않을 때Debug ‘app’ 버튼 또는 단축키(^D)를 클릭해 디버깅 모드를 실행합니다.앱이 실행되다가 단점을 만나면 아래와 같이 앱은 일시중지될 겁니다.이때 디버깅 탭의 도구들을 사용해서 앱의 상태를 확인할 수 있습니다.만약 Variables 영역이 보이지 않으면, 1번 영역에서 Restore Variables View를 클릭합니다. 이 영역은 변수의 객체 트리를 확인할 수 있습니다.변수 위에 마우스 커서를 올리면 Variables 영역을 보지 않고도 변수를 확인할 수 있습니다. + 를 누르면 더 자세한 객체 트리도 확인할 수 있습니다. 객체는 왼쪽의 화살표를 누르면 객체에 속한 필드도 확인할 수 있습니다.객체 트리 확인객체에 속한 필드 확인2번 영역은 현재 어느 메서드에 멈춰있는지 알려줍니다. main에서 시작해 run, invoke… onCreateView에 일시중지한 것을 보여줍니다.1번 영역의 Restore Watches View를 클릭하면 아래 화면이 보입니다.Watches는 break 된 상태에서 코드를 실행할 수 있는 창입니다. 모든 코드를 사용할 수 있는 것은 아니고 현재 라인에서 사용 가능한 코드만 쓸 수 있습니다. + 버튼을 눌러 확인하고 싶은 코드를 입력하면 결과를 바로 확인할 수 있습니다.아래 이미지는 디버깅 탭입니다. 각 버튼의 기능을 알아볼까요?디버깅 탭중단점을 만나 일시중지된 상태에서 Step Over 버튼을 클릭해 다음 줄로 이동합시다.Step Into 버튼을 클릭해 getContents() 메서드의 첫 라인으로 이동합니다.Step Out 버튼을 클릭해 getContents() 메서드 밖의 다음 줄로 이동합니다.Step Over 버튼을 눌러 코드의 다음 줄로 이동합니다.지금까지 안드로이드 디버깅 방법을 알아봤습니다. 기능이 많아서 처음부터 다 활용할 순 없겠지만 계속 기능을 사용하다 보면 점점 익숙해지지 않을까요? 참고앱 디버깅  |  Android Developers급식어플 블로그 : 네이버 블로그글김보예 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #안드로이드 #Android #디버깅 #문제해결
조회수 931

크로키닷컴을 소개합니다 #6

크로키닷컴 6번째 인터뷰!오늘은 지그재그 앱 개발을 담당해주시는 앱 개발자 연미님, 하경님과 함께 현재 채용 중인 [안드로이드/iOS 개발자] 포지션 및 지그재그 앱에 관해 소개해보도록 하겠습니다. :-)Chapter 1. 저를 소개합니다!Q. 연미님, 하경님 안녕하세요! 이번 인터뷰이로 선정되신 소감과 간단한 자기소개 부탁드립니다.하경 저는 입사하기 전에 저희 파트 형준님 인터뷰(3편)를 봤었는데 되게 인상 깊었거든요. 그래서 제가 면접을 볼 때도 그 얘기를 했던 게 엊그제 같은데.. 제가 어느새 인터뷰를 하고 있는 모습을 보니 신기하고 뿌듯하네요. (웃음)연미 저는 앱 개발뿐만 아니라 다른 포지션에 대해 도움이 되는 정보를 드릴 수 있게 돼서 감사하게 생각하고 있습니다. 초대해주셔서 감사해요!하경 저는 iOS 개발을 주로 하고 있는 김하경이라고 합니다. iOS를 하다가 최근에는 조그만 것들부터 안드로이드도 시도해보고 있어요. 이번에 저희 지그재그 결제 서비스인 Z결제 소속으로 들어가게 되었는데요, 커머스 앱의 가장 중요한 기능 중 하나인 리뷰 서비스 개발을 맡게 되었어요. 한동안 굉장히 바쁘게 일하지 않을까 생각합니다.연미 저도 하경님과 같이 앱 개발을 하고 있는 손연미입니다. 저는 지그재그 서비스의 초반부터 안드로이드/iOS 개발을 모두 해왔는데, 요즘은 안드로이드 쪽에 좀 더 집중해서 하고 있어요. 이번에 저는 지그재그 서비스를 폭풍 성장시킬 그로쓰팀의 일원으로 들어가게 되었는데요, 유저의 사용성뿐만 아니라 또 다른 시야에서 서비스의 성장을 같이 일궈낼 예정입니다. (앗, 그러면 하경님이 입사 8개월 만에 연미님의 품을 벗어나게 된 건가요?)하경 네 맞아요. 저희가 이번에 처음으로 떨어지게 되었는데 약간은 두렵네요.연미 혹시 괴롭히는 사람 있으면 말하세요. 제가 혼내줄게요!오늘도 평화로운 지그재그 팀Q. 하경님은 지그재그로 이직을 하고 싶으셨던 이유나 계기가 따로 있으셨나요?하경 저는 예전에 정말 소규모의 스타트업에서 처음 iOS 개발을 시작했었어요. 심지어 같이 일하는 동료도 iOS 개발이 처음이었다 보니 같이 배워가는 입장이라 어려운 점이 많았고, 항상 부족하다는 느낌을 받았어요. 계속 검색에 의존하여 개발을 하다 보니, '더 좋은 코드를 짤 순 없을까?' 하는 욕구가 있었는데 우연히 지그재그의 글을 보게 되었어요. 지그재그 기술 블로그나 브런치 글들을 보면 아시겠지만, 성장이라는 문구가 되게 많이 나오거든요! 그게 저에게 굉장히 매력적이었어요. 채용 공고에도 같이 성장하고 싶은 팀원을 구한다고 적혀있길래 망설임 없이 지원했습니다. 저는 그때도 그렇고 지금도 그렇고 항상 성장하고 싶어요.(실제로 입사하시고 나서 겪어본 지그재그는 어떤가요?)하경 전 직장과 비교했을 때 저에게는 지그재그가 큰 회사로 느껴졌어요. 그러다 보니 왠지 이미 굳어진 정책 안에서 정해져 있는 일만 해야 하지 않을까 하는 개인적인 생각이 있었는데, 실제로 겪어보니 전혀 아니었어요. 매우 빠르게 성장하며 끊임 없이 변하고 있고, 이것 저것 새로운 걸 많이 시도해보는 게 신기했어요. 코드 리뷰도 처음 입사했을 당시에는 모든 코드에 대해 서로 꼼꼼히 리뷰한 후에 배포가 가능해서 그 과정에서 정말 많이 배울 수 있어서 너무 좋았는데, 최근에는 작은 부분에 대해서는 코드 리뷰를 거치지 않고 담당자가 빠르게 배포할 수 있도록 자율성을 부여하고 있어요. 이렇게 자율적으로 맡게 되니, 코드에 대한 책임감이 더 커지고 공부도 더 열심히 하게 되는 것 같아요.Q. 연미님은 지그재그 서비스 초기에 합류해서 지금까지 함께하고 계신데요! 처음 합류하시게 된 계기가 궁금합니다.연미 이전 회사에서는 주로 파견을 나가서 근무한 적이 많았어요. 그러다보니 제가 애정을 담아 지속적으로 키워나갈 수 있는 서비스가 없는 점이 항상 아쉬웠어요. 그래서 그런 서비스를 만들어나가는 사람들을 만나 함께 발전시켜나가고 싶다는 생각을 늘 했었는데, 운이 좋게도 지그재그 팀을 만나게 되었네요.(합류를 결정하실 때, CTO 상민님과 함께 일을 해보고 싶었던 마음도 한 몫(?) 했다고 들었어요!)연미 제 주변에서 상민님은 천재 개발자라고 불렸어요. 그러다 보니 저도 상민님과 함께 일하면서 배우고 싶었고, 같이 파이팅해보고 싶다는 의지가 매우 강했어요. 그렇게 합류한 이후 지금까지 상민님과 함께 개발을 하면서 정말 많이 배웠어요. 그리고 상민님과 저의 커뮤니케이션 스타일이 비슷한 부분이 있는데, 그래서 더 편하게 좋은 팀워크를 유지해올 수 있었던 것 같아요. 둘 다 말수가 적은 편이라 업무에 필요한 말만 간단히 주고 받는 편인데, 그게 오히려 서로에게 편하게 느껴진다는 것? (웃음)천재 개발자 상민님의 기술 블로그 놀러 오세요! https://devblog.croquis.com(하경님께서 이전에 코드 리뷰에 대해 언급해주셨는데요, 연미님은 개발팀의 문화로 자리 잡은 코드 리뷰에 대해 어떻게 생각하시나요?)연미 개발자들에게 코드 리뷰는 책임감이고, 방향성이고, 하나의 커뮤니케이션 방식이라고 생각해요. '우리는 코드로 얘기한다.'고 생각하는 개발자들이 모여있기 때문에, 서로가 어떤 생각을 가지고 코드를 짰는지 공유하고, 미처 발견하지 못한 문제점이 있다면 같이 해결해보고 하는 거죠. 같이 sync를 맞추고 신뢰를 쌓아가는 과정이랄까요? 다른 인터뷰에서도 다른 분들이 말씀하시긴 했지만, 우리 지그재그 팀은 다들 서비스에 대한 애정을 바탕으로 더 나은 서비스를 만들고 싶어하는 사람들이라서 이런 문화를 매우 선호하고 환영합니다!Chapter 2. 업무와 일하는 방식Q. 오늘은 지그재그 팀이 목적 조직으로 대대적인 조직개편을 한 그 첫 날인데요, 이 변화에 대해 두 분이 기대하는 점 또는 걱정되는 점이 있다면요?연미 작년에 인원이 많이 늘었고 회사도 커지면서 각자의 R&R이 명확해지다 보니 '함께 한다'는 느낌이 조금 약하게 느껴졌었어요. 그런데 목적 조직은 모두 하나의 목적을 가지고 으쌰 으쌰 하기 때문에 그렇게 생각을 덜 하게 되지 않을까 싶어요. 다만 조직개편 후에 놓치지 않도록 신경써야 되겠다고 생각하는 부분은 각 프로젝트팀의 목적 범위 외의 부분인 것 같아요. 주요 프로젝트 목적에 너무 치중하다보면 다른 부분에서 소홀해질 수 있기 때문에, 그런 경우가 생기지 않도록 어떻게 대비할 것인지 생각해두면 좋을 것 같아요.하경 우선 업무에 보다 집중을 할 수 있는 환경이 된 것 같아 기대가 됩니다. 그리고 개발자는 개발팀, 디자이너는 디자인팀 이렇게 각자의 팀에서 협업을 진행했었는데, 이제는 같이 한 팀이 되어 하나의 목적을 달성해나가게 되었으니 커뮤니케이션이 훨씬 더 수월해진 것 같기도 하고요. 그리고 그럴 일은 절대 없게끔 할테지만, 각 팀의 목적이 훨씬 뚜렷해진 만큼 만에 하나라도 목적을 달성하지 못하게 된다면 제가 너무 우울해지지 않을까 하는 생각이 들기도 해요. 반드시 달성하고 싶어요!Q. 지그재그 앱의 역사를 함께 해오셨는데, 새로운 기술이 도입될 때마다 적용시키는 과정이 궁금해요. 연미 인원이 늘기 전까지는 새로운 기술들에 대해서 시도를 많이 못해봤던 것 같아요. 1년 전부터 팀원이 늘어나게 되면서는 레거시를 바꾸는 작업을 계속 진행하고 있어요. 서비스 초기에 적용된 기존의 기술들을 계속 사용하기보다는 새로 합류하는 팀원들의 의견을 많이 들어보고 적용하려고 하고요. 예전 버전에서 지속적으로 업그레이드를 하고 있다고 생각해주시면 될 것 같아요.하경 우리 지그재그 팀원분들은 기술 그 자체이신 분들이 굉장히 많거든요. 다른 팀원들이 새로운 기술을 접목해서 우리 서비스에 득이 된다면 새로운 기술은 언제든 배우고 싶어요. 물론 서비스의 안정성이 가장 중요하기 때문에, 접목해보기 전 새로운 기술에 대한 충분한 공부가 선행되어야 하는 건 필수라고 생각해요!(새로운 걸 배운다는 게 쉬운 일은 아닌데요..!)하경 어렵지 않아요. 되려 재밌어요! 새로운 걸 배운다는 게 제가 개발을 하는 데 있어서 활력을 불어넣어주는 거라고 생각하거든요. 기존에 하던 대로만 개발을 해오다 보면 지루해져서, 새로운 걸 시도해보곤 한답니다.연미 학습 속도가 정말 빨라요. 뚝딱 하고 만들어내시거든요.하경 아니에요..(부끄) 재밌어서 하다 보니 그렇게 되었네요.빛의 속도 하경님!Q. 서비스 초기부터 앱 파트를 이끌어오신 연미님! 성과를 이루기 위해 해왔던 업무 방식이나 프로세스가 있다면 어떤 것인가요?연미 저는 업무에 대한 흥미도가 성과 향상에 많은 영향을 미친다고 생각해요. 그래서 태스크의 담당자를 정할 때에는 그 태스크에 관심이 있고 하고 싶어하는 팀원이 있는지를 우선적으로 고려하는 편이에요. 만약 지원자가 없는 업무라면 그땐 팀원들과 이야기를 나누며 팀의 상황에 따라 분배를 하긴 하지만요. (웃음)그리고 2019년 초반에는 앱 파트 팀원이 총 3명이었는데요, 그땐 집중 프로젝트라는 것을 적용해봤어요. 각자 하나의 프로젝트를 맡아서 본인이 주도적으로 타 팀과 커뮤니케이션을 하면서 프로젝트를 완료할 수 있게끔 해본 거였는데, 결론적으로는 팀원 분들이 좋아하셨어요! 책임감도 키울 수 있었고, 비즈니스적인 측면에서도 성장할 수 있었다고 생각해요. 내 프로젝트다!라는 생각이 있다 보니까 아이디어도 내보고, 의견 전달도 많이 하면서 진행될 수 있어 좋았습니다 .하경 집중 프로젝트를 통해 미리 경험을 했어서 그런지 이번에 목적 조직에 들어간 게 어색하지 않은 것 같아요. 이미 그 방식에 적응되어 있는 것 같거든요.Q. 하경님은 작년 제1회 지그재그 배 해커톤에서 1등을 하셨어요! 그때 만드신 프로젝트 '휴가봇'이 회사에서 실제로 활용되고 있는데, 기분이 어떠세요?하경 작년 추석쯤에 해커톤을 했었는데요, 뭘 만들어볼까 하다가 회사 생활하면서 작은 부분이지만 불편하게 느껴졌던 부분을 개선해보고 싶어서 만들게 되었어요. 이름은 달비 휴가봇이고 같은 Dev.팀의 우식님과 만들었는데, 이게 이렇게 큰 영향을 끼치게 될 줄 몰랐어요! 사실 지금도 계속 사용 중이니 계속 기능 업데이트를 위해 공부를 하게 되고요. 그래서 신기하기도 하고 뿌듯하기도 하답니다. 원래 쓰던 기술이 아닌 새로운 기술을 배우면서 만들어봤던 프로젝트라서 더 재밌었고, 만약 개발에 지루함을 느끼신 분이라면 이런 프로젝트도 시도해보시면 좋을 것 같아요.연미 새로운 기술을 쓰다 보면 시야가 넓어지거든요. 정말 추천드리고 싶습니다. 하경 그리고 달비 휴가봇을 같이 만들어주신 우식님께도 감사인사를 전하고 싶습니다. 지금까지도 얼떨결에 같이 개발을 하고 계시거든요..(웃음)Chapter 3. 저희 공고를 소개합니다!Q. 현재 채용 중인 [안드로이드/iOS 개발자] 얘기를 해볼까 해요. 어떤 앱 개발자를 찾고 있는지 말씀해주시겠어요?연미 일단 현재는 경력이 3년 정도는 있으신 분을 찾고 있어요. 아무래도 계속 새로운 작업들이 진행되고 있기도 하고 새로운 기술을 계속 적용하며 함께 업데이트를 해나가실 분을 모시고 있기 때문에 어느 정도의 경력은 있으시면 좋을 것 같아요.그래서 Dev.팀이 이번에 인턴쉽을 진행했을 때에도 앱 개발 분야는 별도로 접수를 받지는 않았는데요, 나중에 기회가 된다면 저희도 인턴이나 신입 개발자분들도 모시고 싶어요!하경 개인적으로 바라는 부분이기도 하지만 서비스에 대한 애정이나 관심이 있으신 분이면 좋겠어요. 저랑 같이 텅장을 만드실 분이랄까요.. (웃음) 장난이고요, 애정과 그 서비스에 쏟는 열정은 비례하다고 생각하거든요.연미 사용자가 지그재그 앱을 어떻게 더 편하게 사용할 수 있을지 같이 고민해주실 분을 찾고 있어요. 그리고 채용 공고 내에 우대사항으로 적힌 부분은 정말 우대사항이기 때문에 해당 기술을 알고 계시면 더욱 좋겠지만 모르셔도 괜찮아요. 들어오셔서 같이 배워나가시는 분들도 많이 계시고, 또 필요하면 팀 내에서 개발 스터디를 직접 오픈하실 수도 있고 이미 활발하게 진행중인 스터디에 참여하실 수도 있으니까요.하경 아! 그리고 서로에게 동기부여가 될 수 있는 팀원분을 모시고 싶어요. 앞에서 말씀 드렸던 코드 리뷰 같은 경우에도 서로 코드를 공유 하면서 모르는 기술도 알 수 있게 되고, 몰랐던 문제점을 알아갈 수 있으니 각자의 발전에도 도움이 되거든요! 저희 팀에서 자체적으로 OOP스터디도 진행했었는데, 같이 배우고 공유하면서 회사와 개인의 발전에 목표를 가지실 분이었으면 좋겠어요!Q. 지그재그의 예비 지원자에게 전하는 메시지!연미 지그재그 팀은 사업적인 측면에서도 그렇고, 기술적인 측면에서도 성장 가능성이 무한해요. 아무래도 새로운 시도를 할 때 오픈 마인드이기 때문이지 않을까 싶은데요, 팀원의 성장을 위해서 적극적으로 지원을 해주기 때문에 회사와 함께 발전하고 싶으신 분들은 맘껏 지원해주셨으면 좋겠어요.하경 주저하지 마시고 지원해주셨으면 좋겠어요! 전 개인적으로 빠르게 성장하고 있는 회사에서 일하다 보니 제 자신이 능동적이고 주도적으로 변해가는 걸 느꼈는데요, 그게 되게 회사에서 재밌게 일할 수 있게 해주는 것 같아요.Chapter 4. 마무리Q. 2020년 두 분의 목표가 있으신가요?하경 2019년에는 개인적으로 이사를 하게 되면서 인테리어에도 관심을 갖게 되었고, 특히 제가 청소에 빠지게 됐어요. 부모님이 보시면 어이없어하시겠지만. (웃음) 다른 것에 좀 더 포커싱이 가있었다 보니 개발 공부를 많이 못했던 것 같아요. 그래서 올해엔 공부를 열심히 할 생각이고, 마인드도 바꿔보려고요! 더 긍정적인 마인드!연미 저도 비슷한데, 개발자로서의 역할을 더 강화하고 싶어요. 저의 테크니컬한 부분을 더 발전시켜보려고요. 개인적인 목표는.. 내 집 장만입니다.하경 그거.. 작년 목표 아니었나요..?(웃음) 저는 건강관리도! 점심마다 샐러드를 먹고 있는데요, 공개적으로 말해두면 더 열심히 지키지 않을까 싶어 추가로 말씀드려봅니다.Q. 다음으로 인터뷰를 진행했으면 하는 팀이 계신가요? 궁금한 팀이 있으면 말씀해주세요!하경 저는 Relations팀이요. 전반적인 채용을 담당해주셔서 그 과정도 궁금하고, 이번에 팀 인원도 두 분 더 합류하셨는데 어떤 변화들이 생겼는지 궁금해요.연미 저는 3PL분들이요! 각자 프로젝트마다 어떤 방식으로 업무를 진행해가실 예정인지, 주간 미팅 때 공유해주시긴 했지만 좀 더 구체적인 가이드라인과 비전이 궁금해요. 이 인터뷰가 성사되고 많은 분들께 읽혀진다면, 각 팀의 목표에 공감하시는 좋은 분들이 많이 합류해주시지 않을까요! (*3PL은 지그재그의 새로운 프로젝트팀 리더 세 분을 의미합니다!)지그재그에서는 안드로이드/iOS 개발자를 포함하여 활발하게 채용을 진행하고 있습니다. 지그재그 팀과 함께, 수면 아래 숨겨진 가치를 찾아내는 경험에 동참할 팀원을 꼭 모시고 싶습니다 :-) 궁금하신 점은 언제나 [email protected] 또는 http://facebook.com/zigzagcareer로 연락 주세요!지그재그 [안드로이드/iOS 개발자] 포지션을 소개합니다!이런 일을 합니다.안드로이드, iOS이런 분을 모십니다.안드로이드iOS이 중 하나라도 가능하시다면 더더욱 좋아요 :)공통안드로이드iOS지원 방법채용 절차혜택과 복지   더 많은 공고는 채용 사이트에서 확인 가능합니다! >>> 채용 사이트 바로가기
조회수 1270

크로키닷컴을 소개합니다 #4

오랜만에 돌아온 크로키닷컴 인터뷰!요즘 채용이 활발하게 진행 중인 크로키닷컴의 [프론트엔드 개발자] 에 관해 궁금해하시는 분들을 위해, Dev.팀에서 근무하고 있는 프론트엔드 개발자 두 분! 영준님, 케빈님을 모셨습니다.Chapter 1. 저를 소개합니다!Q. 영준님, 케빈님 반갑습니다! 간단하게 자기소개 부탁드릴게요.영준 저는 프론트엔드 개발자 김영준이고요, 지그재그의 또 다른 신사업 서비스를 만들어가고 있습니다. 프론트엔드 개발은 5년 정도 했고, 요즘은 신사업 서비스에 새로운 기능이 들어갈 예정이라 그 작업을 열심히 하고 있습니다! 참, 원래 저는 공대 출신은 아니고 디자인과를 졸업했어요.(우와.. 디자이너에서 개발자로 전향하신 특별한 계기가 있으셨나요?)그때 당시 어도비 플래시가 잘 되던 시기였는데, 플래시가 좋아서 그쪽 수업을 많이 들었거든요. 그때부터 관심을 갖게 돼서 첫 회사에는 플래시 개발자로 입사했었어요. 이후에 플래시 사용률이 점차 줄어들면서 프론트엔드 개발 쪽으로 전향하게 되었습니다.케빈 어.. 제 본명은 성훈이고요.(웃음) 저는 원래 풀스택 개발자로 2년 정도 일을 했었어요. 본격적으로 프론트엔드 쪽으로 전향한 지 2년 정도 된 것 같아요. 저도 영준님이랑 비슷하게 공대는 아니고 영상그래픽을 전공했어요. 3D나 특수효과 같은 거? 교양수업으로 HTML 수업을 듣다가 개발에 관심이 생겨서 시작하게 됐습니다!(그렇군요! 케빈님 곧 있으면 입사 100일을 맞이하시게 되는데 소감이 어떠신가요?)프론트엔드 포지션에 온전히 집중해서 일을 해본 건 처음이에요. 이전에 바라 왔던 업무환경에 많이 근접한 것 같고 점차 적응 중에 있습니다.Q. 어떠한 연말을 보내고 계신가요?영준 어! 저 얘기할 거 있어요. 얼마 전부터 회사에서 전세자금 대출 이자를 지원해주기 시작한 덕분에 난생처음으로 독립을 하게 됐거든요. 이자를 지원받게 되니 집도 더 잘 구하게 된 것 같아요! 그래서 요즘은 자취 초년생으로서 이것저것 해보고 있어요. 요리도 해보고 그동안 해보고 싶었던 것들? 하지만 집에서 부모님이 해주시는 게 얼마나 감사한 지도 알게 됐어요. (그래도 다시 돌아가긴 싫으시겠죠?)영준 네, 독립해서 진짜 좋아요. 그래서 요즘 일하는 시간 외에는 인테리어 고민을 많이 하고 있어요. 지금 집에는 아무것도 없거든요. 곧 영준님만의 감성으로 채워질 집!케빈 아.. 저는 딱히 뭐가 없는데..영준 아 아직 입양 안 받았어요?케빈 아! 맞아요. 제가 동물을 입양하려고 준비하고 있어요. 그 동물에 대해서 공부 먼저 하고 제대로 알게 된 다음 입양하려고요. (입양이요? 강아지? 고양이?!) 케빈 페럿이라고 아세요? 페럿을 입양하려고 공부하고 있어요. 돈도 많이 든다고 해서 모으고 있기도 하고요. 그것 빼고는 하는 게 없어요 아직.키우는 분이 별로 없는 희귀한 동물, 페럿! 애교가 많은 동물이라고 하네요 :-)Chapter 2. 직잭러가 되어가는 과정Q. 지그재그로 이직하고 싶었던 특별한 계기나 이유가 있었나요?영준 이직할 때 개발자로서 성장이 가능한 회사를 찾으려고 했어요. 이전 회사가 에이전시이다 보니 코드 리뷰 문화가 없었거든요. 코드 리뷰는 프로덕트에도 좋은 영향을 끼치지만 개발자 개개인의 성장에 더 영향을 많이 끼친다고 생각했거든요.(실제로 겪어본 이후로는 확신합니다!)프로덕트에 대한 이해를 높이는 것은 물론 양질의 코드를 실컷 볼 수 있고, 또 어느 코드 하나 허투루 작성할 수 없어요. 그래서 꼭 코드 리뷰가 있는 회사로 가려고 했는데, 지그재그가 딱 그랬습니다!케빈 저도 코드 리뷰 문화에 한 표! 저는 프론트엔드 분야에서는 늦게 공부를 시작했기 때문에 배울 수 있는 환경이 매우 중요하다고 생각했거든요. 아 그리고 저는 이직을 고려할 때, 그 회사에 대해서 미리 프레스나 github을 다 찾아보는데, 그러다 보면 이 회사는 '이렇게 근무를 하는구나'가 어느 정도 보이더라고요. 근데 지그재그 팀을 찾아보면서 여기서 꼭 같이 일해보고 싶다고 생각했어요. 찾아보시면 지그재그 개발 문화와 관련된 소스코드나 오픈소스 프로젝트가 공개되어 있는데요, 왜 이런 코드를 썼고 이런 규칙을 정했는지 오픈해두고 같이 생각해볼 수 있게끔 되어 있어요.영준 저는 기술 블로그도 재밌게 봤어요.케빈 맞아요. 특히 주니어의 입장에서는 발전에 대한 욕망이라고 해야 하나?(웃음) 욕심이 클 수밖에 없는데 기술 블로그가 지그재그 팀에 대한 궁금증을 풀어주는데 많은 도움이 됐어요.나름 활발한 (?) 지그재그 기술 블로그에도 놀러 오세요! https://devblog.croquis.com/ko/Q. 입사 전 인터뷰 때 가장 인상 깊었던 질문이나 에피소드가 있으신가요?영준 일단 면접 절차 진행이 너무 친절해서 당시 기억이 엄청 좋았어요. 또 정해진 질문지에 대한 뻔한 대답보다, 저에게 fit된 인터뷰를 진행했던 것도 좋았고요. 전 회사에서는 인터렉션 관련된 작업을 많이 했었는데, 쟈니님(CEO)이 인터렉션이 프로덕트에 어떤 도움을 줄 수 있을까에 대한 질문이 되게 참신하고 좋게 다가왔습니다. 물론 제가 답한 것 들 이외에도 어떤 영향을 끼칠 수 있는지 말해주어서 더 좋았어요! 아, 재밌는 에피소드가 하나 있는데.. 쟈니님이 '영준님은 친구들 사이에서 어떤 사람이에요?'라고 질문을 하셔서 '먹는 것 좋아하는 사람이요.'라고 대답했더니, 쟈니님이 '그럼 안 되겠네요. 저희는 밥을 다 사드리기 때문에 영준님이 오시면 거덜 날 것 같아요'라고 하셨어요.(빅웃음) 쟈니님은 워낙 장난이 많으신 분이라 재밌었어요.케빈 저는 2차 인터뷰 때 엄청 떨었어요. 그래서 어떤 질문이 나왔고 어떻게 대답을 했었는지 하나도 기억이 안 나네요. 입사 후 수습기간이 끝나갈 즈음에 쟈니님과 미팅을 한 번 더 했었는데, 쟈니님이 제가 인터뷰 때 떨었던 것과는 너무 다르게 업무 커뮤니케이션을 잘한다는 팀원들의 반응이 많아서 놀랐다고 하셨어요.영준 케빈님 1차 인터뷰 때에도 엄청 긴장되시지 않았어요?케빈 맞아요. 그땐 그래도 기술적인 질문이 많아서 나름 덜 떨었답니다.(?) 그리고 아까 영준님이 답해주셨듯이, 저도 마찬가지로 제가 경험한 것을 중심으로 질문을 많이 해주셔서 수월하게 대답할 수 있었던 것 같아요. 입사한 지 얼마 되지 않아 interviewer로 몇 번 참석했었는데, 지원자분의 경험을 중심으로 대화를 나누는 게 실제로 지원자분에 대해서 더 잘 알아갈 수 있는 좋은 방법인 것 같아요!Q. 입사 전 기대했던 지그재그의 모습과 실제 겪어본 지그재그의 모습은 어때요? 많이 다른가요?케빈 저는 기대했던 것과 크게 다르지 않았어요. 많은 개발자들이 기술적으로 더 성장할 수 없다고 느껴질 때 상실감을 크게 느낄 거예요. 전 직장에서도 서로 토론하고 의견을 공유하는 문화가 있었는데 바쁘다 보니 그 문화가 점점 사라지게 되어 많이 안타까웠죠. 그래서 지금은 지그재그 개발팀의 좋은 문화가 유지될 수 있게, 계속 활발하게 운영이 될 수 있도록 적극적으로 참여하려고 노력하고 있어요. 영준 사실 전 지그재그 팀이 딱딱한 분위기에서 업무를 할 거라고 생각했었어요. 워낙에 빠르게 성장하고 있는 회사이다 보니? 근데 막상 들어와 보니 이만큼 같이 일하는 게 재밌고 캐릭터가 독특한 사람들이 많은 회사는 처음이에요. 그리고 저희가 매주 월요일에 전 직원이 모여서 주간 미팅을 하잖아요. 거기서 팀별로 프로젝트 진행상황을 공유하는데 정확한 데이터 수치를 기반으로 꼼꼼하게 분석하고 리뷰하는 모습에 놀랐어요. 추가적으로 개발에 대한 열정이 있는 동료들이 많았으면 하는 소망도 있었는데, 실제로 만난 지그재그는 개발 욕심 가득한 사람들의 모임이라 매일매일 자극받으며 근무하고 있어요.매주 월요일 전직원이 참여하는 주간 미팅!Q. 지그재그 팀에 들어온 후에서야 비로소 알 수 있었던 좋은 문화나 제도가 있을까요?영준 사내 스터디가 많은 거? 아마 우리 회사가 다른 어떤 회사보다 스터디가 많을걸요? 원한다면 누구든 만들어서 모집할 수 있거든요. 다들 매우 적극적입니다.(그럼 영준님은 몇 개의 스터디에 참여하고 계세요?) 저는 1월에 새로 시작할 스터디까지 하면 두 개요!케빈 개발자들에겐 스터디도 큰 요소일 거예요. 다양한 스터디가 지속적으로 운영되는 게 쉬운 일은 아니라, 기술 블로그를 보면 '진짜 이만큼이나 공부한다고?'라고 의문이 들 수밖에 없으니까요. 아! 그리고 스터디는 아니지만 개발 미식회라는 프로그램이 있어요. 다른 사람들과 함께 의논해보고 싶은 코드가 있거나 혹은 본인이 만든 코드를 공유하고 싶은 사람이 자발적으로 신청자를 받아서 점심을 함께 먹으면서 발표도 하고 의견도 나누는 시간이에요. 한 달에 1-2회 정도 진행이 되고 있어요. 다음 주에 저도 발표하기로 했거든요. 신청자가 없어서 못하게 되면 안 되는데..영준 그리고 발표를 했던 사람은 다음 개발 미식회의 점심 메뉴를 선정할 수 있는 특혜가 주어집니다.(웃음)케빈 오! 그건 몰랐어요. 그리고 저는 저번에 영준님이 발표하실 때에도 신청해서 들었어요. 영준 다들 서로 발표를 하고 싶어서 바쁜 와중에도 열심히 공부해요. 바쁠 땐 듣는 게 좀 부담스러울 텐데도, 다들 적극적으로 들어주려고 하니 고맙죠.영준 님의 개발 미식회 모습! 제가 더 떨리네요 @.@Chapter 3. Dev. 팀은 이런 분을 찾아요!Q. 먼저 Dev. 팀은 어떤 방식으로 일을 하나요?영준 백엔드에 계시는 분들도 그렇고 다른 포지션에 계신 분들도 프론트엔드에 관심이 많으셔서 도와주실 때가 많이 있어요. 아무래도 다들 공부를 많이 하다 보니 그런 것 같아요. 그러다 보니 업무 할 때 같이 고민할 수 있어서 좋죠. 그리고 프로젝트를 일정에 맞추어 진행하다 보면 포기해야 될 부분이 생기기 마련인데요, 지그재그 팀은 유저의 사용성 향상을 위해 기획했던 것들을 최대한 포기하지 않고 가져갈 수 있는 방향을 모색하는 편이에요. 포기하면서 잃는 것도 생각하고 얻게 되는 것도 생각해야 하니 항상 신중해야 합니다.케빈 프로젝트를 진행하면서 문제가 생기면 다 같이 의논해서 풀려고 해요. 그리고 그 과정에서 여러 가지 다른 의견이 나오면 합의점을 찾으려고 하고요. 이건 팀 내에서 뿐만 아니라 유관부서랑 함께 일할 때도 같아요. 팀원들 모두가 개인적인 관점이 아닌 product 관점과 사용자 관점으로 생각하려고 하기 때문이죠. 또 프로젝트를 통해 유저분들에게 더 좋은 경험을 전달해주고자 노력하고 있어요. 그래서 유저분들의 기대에 부응한 부분과 그렇지 못한 부분이 무엇인지에 대해 사용자 데이터를 기반으로 회고하는 과정도 함께 진행하고 있습니다.Q. 회사 안에서 해보고 싶은 특별한 프로젝트가 있으신가요?영준 저는 직잭버디를 뽑는 시스템을 만들고 싶어요. 그리고 의류, 패션에 관련된 새 프로젝트도 해보고 싶네요. (*직잭버디는 신규 입사자의 빠른 적응을 도와드리는 멘토링 프로그램입니다!)케빈 저는 개인적으로 점심시간 메뉴 고르는 룰렛을 만들고 싶어요. 회사 주변에 밥집이 너무 많아서 오히려 메뉴를 고르기가 어려워요. 만들면 잘 쓰지 않을까요? 의견을 받아서 다 같이 만들어봐도 재밌을 것 같아요.Q. 요즘 [프론트엔드 개발자] 채용이 한창인데요, 어떤 분과 함께 일하고 싶으신가요?케빈 개발 환경을 기반으로 여러 개발 항목들을 유저의 관점에서 대조해 봤을 때, 깊게 생각해보고 경험해 본 분이면 좋겠어요. 유저의 관점에서 더 생각해보고 적용하시는 분이라면 지그재그 서비스에 대해 애정을 가지고 일할 수 있을 것 같아요.영준 요구사항에 맞게 동작하는 프로그램을 만드는 것은 물론, 유저의 사용성을 생각하는 개발자였으면 좋겠어요. 예를 들면 모바일 기기에서의 최소 터치 영역을 생각한다든지... 유저를 직접 만나는 최접점에 있는 개발이다 보니, 사용성에 관해서는 가장 관심이 많아야 한다고 생각하거든요. 또 프론트엔드 개발 자체가 빠르게 발전하고 있는데, 왜 이렇게 바뀌고 있는지를 생각하는 개발자면 좋을 것 같아요. 그리고 회사가 커지면서 여러 가지 새로운 서비스들도 생기고 새로운 경험도 많이 하게 될 텐데요, 새로운 걸 만들어 보고 겪어보고 싶은 분이라면 지원해주세요!케빈 평소에 업무를 하실 때 깊이 있게 고민하면서 선택하신 본인의 라이브러리, 도구들에 대해 왜 이런 선택을 했는지.. 또 코드 한 줄 한 줄을 어떤 의도로 작성했는지에 대해 생각해보신 분이라면 어렵지 않게 인터뷰를 진행하실 수 있을 거예요. 또, 그런 분들이 계시다면 저희도 꼭 모시고 싶어요!Chapter 4. 마무리Q. 올해 지그재그 팀에 합류하면서 개인적으로 성장한 부분, 그리고 2020년의 목표나 버킷리스트가 있으신가요?영준 지그재그 서비스가 이커머스가 되어가는 과정을 함께 하면서 성장했다고 느꼈어요. 내년 목표는 신사업 성공시키기! 업무 외적으로는 운동을 열심히 해서 바다에서 사진 찍는 거예요. (몸짱 영준)케빈 저는 Z결제 서비스가 오픈되면서 마케팅 이벤트를 위한 개발을 많이 했는데요, 이벤트에 대한 유저의 반응이 폭발적인 걸 보면서 더 유저의 입장에서 생각하려고 하는 스스로를 보며 성장하고 있다고 느꼈어요. 더 공부하려고 하기도 하고요. 그리고 개인적으로는 내년에 영어공부를 열심히 하고 싶어요. 제가 즐겨하는 PC게임이 있는데, 외국인 유저와 더 편하게 대화하면서 게임하고 싶어서요.(웃음)Q. 다음 인터뷰는 어느 팀에서 하면 좋을까요? 그 팀에 특히 궁금한 것이 있다면요?영준 저는 서버 개발자 또는 데이터 팀이요! 지그재그 서비스의 서버 개발자들은 각자 태스크를 부여받아서 진행하는 방식으로 업무를 한다고 들었는데, 구체적으로 R&R이나 업무 프로세스가 어떤 방식으로 이루어지는지 궁금해요. 그리고 데이터 팀에는 수많은 데이터들을 앞으로 지그재그 서비스의 발전을 위해 어떻게 활용할 수 있을지, 그리고 데이터팀에 계시는 인성님께 어떻게 그렇게 매일 웃으며 즐겁게 지내실 수 있는지 여쭤보고 싶어요.케빈 저는 디자인 팀! 지그재그의 다양한 디자인들을 작업하고 의사결정을 내리기까지의 논의 방식이 궁금해요. 그리고 디자인 팀에도 인원이 늘었는데, 그로 인해 어떠한 변화가 생겼는지도 궁금합니다.지그재그에서는 웹 프론트엔드 개발자를 포함하여 활발하게 채용을 진행하고 있습니다. 지그재그 팀과 함께, 수면 아래 숨겨진 가치를 찾아내는 경험에 동참할 팀원을 꼭 모시고 싶습니다 :-) 궁금하신 점은 언제나 [email protected] 또는 http://facebook.com/zigzagcareer로 연락 주세요!지그재그 [웹 프론트엔드 개발자] 포지션을 소개합니다!이런 일을 합니다.이런 분을 모십니다.이 중 하나라도 가능하시다면 더더욱 좋아요 :)지원 방법채용 절차혜택과 복지   더 많은 공고는 채용 사이트에서 확인 가능합니다! >>> 채용 사이트 바로가기
조회수 1276

Event-Driven Programming

Overview마이크로 서비스 사이의 결합도를 낮추고 비동기적인 문제들을 처리할 때는 Event-driven 아키텍쳐가 유용합니다. 이번 글에서는 AWS에서 제공하는 SNS Topic을 이용해 Event-Driven을 알아보겠습니다. Event-Driven Programming프로그램의 제어 흐름이 이벤트의 발생에 의해 결정되는 컴퓨터 프로그래밍 패러다임입니다. publish/subscribe (이하 pub/sub)메시징서버리스 및 MSA에서 안정성 및 확장성을 높이기 위하여 사용되는 비동기 서비스 통신 방법입니다. 게시된 메시지를 다른 시스템에 비동기적으로 전달하고, Topic을 구독하는 모든 구독자는 모든 메시지를 받을 수 있습니다. 특히 게시자는 누가 구독하고 있는지 알지 않아도 되고, 구독자도 메시지의 출처를 알 필요는 없습니다. pub/sub 메시징 기본 / 출처: AWS Compute BlogAmazon SNS Topicpub/sub 방식의 메시징 서비스입니다. AWS의 여러 서비스들이 SNS에 이벤트를 게시할 수 있습니다. SNS Event Publishers / 출처: AWS Compute Blog위의 그림과 같이 구독자는 게시자 서비스에서 트리거된 이벤트에 응답해 필요한 작업을 진행합니다. 예시로 Elastic Transcoder 서비스에서의 Topic을 활용해보겠습니다. 네 가지의 순서를 거칩니다.1. SNS 토픽 생성2. Elastic Transcoder 등록Optional 항목인 Notification 영역에서 상태별 이벤트를 설정할 수 있습니다. On Completion Event에 위에서 생성한 Topic을 선택해 이벤트를 전달받도록 설정합니다. 3. SNS Topic에 구독자로 등록트랜스 코딩이 완료 후 처리할 프로세스를 가진 Lambda 함수 생성하여 위에서 생성한 SNS Topic에 구독자로 등록합니다. 현재 SNS Topic에서 제공하는 프로토콜은 HTTP, HTTPS, Email, Email-JSON, Amazon SQS, Application, AWS Lambda, SMS가 있습니다.4. 서비스 간 이벤트 전달출처: AWS Compute BlogSNS Topic으로 이벤트를 제공하는 AWS 서비스 중 하나를 살펴봤습니다. 이를 이용하면 마이크로 서비스 간에 이벤트를 전달하고 서비스의 분리 및 확장에 유용하게 사용할 수 있습니다.Conclusion오늘은 SNS Topic을 이용한 Event-Driven을 알아봤습니다. 다음 글에서는 마이크로 서비스에서 사용할 수 있는 AWS 서비스들을 다뤄보겠습니다.참고Event-Driven Computing with Amazon SNS and AWS Compute, Storage, Database, and Networking Services글이상근 팀장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 2598

Next.js 튜토리얼 8편: 컴포넌트 스타일링

* 이 글은 Next.js의 공식 튜토리얼을 번역한 글입니다.** 오역 및 오탈자가 있을 수 있습니다. 발견하시면 제보해주세요!목차1편: 시작하기 2편: 페이지 이동 3편: 공유 컴포넌트4편: 동적 페이지 5편: 라우트 마스킹6편: 서버 사이드 7편: 데이터 가져오기 8편: 컴포넌트 스타일링 - 현재 글9편: 배포하기개요지금까지 컴포넌트를 스타일링 하는 것을 미뤄왔습니다. 그러나 이제는 몇 가지 스타일을 적용해볼만 합니다.React 애플리케이션에는 컴포넌트를 스타일링 할 수 있는 여러가지 기술들이 있습니다. 크게 두 가지 방법으로 분류할 수 있습니다:1. 전통적인 CSS 파일 기반의 스타일링 (SASS, PostCSS 등)2. CSS in Js 스타일링 결과적으로 전통적인 CSS 파일 기반의 스타일링(특히 SSR)은 실용적인 문제가 많아 Next.js에서 스타일을 지정할 때는 이 방법을 사용하지 않는 것이 좋습니다. 대신 CSS in JS 방법을 추천합니다. 이 방법은 CSS 파일들을 불러오는 것보다 개별적인 컴포넌트 스타일링 할 때 사용 할 수 있습니다.Next.js는 styled-jsx라는 CSS in JS 프레임워크를 미리 설치해두었습니다. 컴포넌트에 이미 익숙한 CSS를 작성할 수 있습니다. 이 CSS는 해당 컴포넌트에만 적용되며 심지어 하위 컴포넌트에도 적용되지 않습니다.이는 CSS가 범위가 있음을 뜻합니다.styled-jsx를 어떻게 사용할 수 있는지 살펴봅시다.설치이번 장에서는 간단한 Next.js 애플리케이션이 필요합니다. 다음의 샘플 애플리케이션을 다운받아주세요:아래의 명령어로 실행시킬 수 있습니다:이제 http://localhost:3000로 이동하여 애플리케이션에 접근할 수 있습니다.home 페이지 스타일링하기home 페이지(pages/index.js)에 스타일을 추가해봅시다.간단히 pages/index.js를 다음과 같이 변경해주세요:   <style jsx> 엘리먼트를 살펴봅시다. 이것은 CSS를 작성하는 곳입니다.코드를 바꾼 후 블로그 home 페이지는 다음과 같이 보일 것입니다:위의 코드에서 스타일 태그 안에 직접 스타일을 작성하지 않고 템플릿 문자열 안에 작성하였습니다.템플릿 문자열({``}) 없이 직접 CSS를 작성해봅시다:어떤 일이 일어날까요?- 아무 일도 일어나지 않는다.- 새로운 스타일이 적용된다.- "문법 에러: 기대되지 않는 토큰"이라는 에러가 발생한다.- "허용되지 않는 스타일 제공자"라는 에러가 발생한다.스타일은 템플릿 문자열 안에 위치해야 합니다styled-jsx는 babel 플러그인을 통해 동작합니다. babel 플러그인은 빌드 과정에서 모든 CSS를 분해하고 적용합니다. (스타일이 추가 시간 없이 적용됩니다)styled-jsx 내에 제약 조건을 제공합니다. 나중에 styled-jsx 안에 동적 변수를 사용할 수 있습니다. 이것이 스타일을 템플릿 문자열 ({``}) 안에 작성해야하는 이유입니다.스타일과 중첩된 컴포넌트home 페이지에 작은 변화를 만들어봅시다. 다음과 같이 링크 컴포넌트를 분리시켰습니다:    import Layout from '../components/MyLayout.js'   pages/index.js 안의 내용을 위와 같이 수정해봅시다.무슨 일이 일어나나요?- 아무런 일도 일어나지 않는다.- 링크가 아닌 h1만 스타일이 적용된다.- 페이지에 에러가 발생한다.- 콘솔에 에러가 발생한다.중첩된 컴포넌트에는 적용되지 않습니다위의 코드를 실행하면 다음과 같이 보입니다:보다시피 CSS는 하위 컴포넌트 내부의 엘리멘트에는 적용되지 않습니다.styled-jsx의 특징은 더 큰 애플리케이션에서 스타일들을 관리할 때 도움이 됩니다.이 경우에는 하위 컴포넌트에 직접 스타일을 적용해야 합니다. 지금 상황에서는 링크 컴포넌트에 직접 스타일을 적용해야 합니다:다른 방법로는 global selectors을 사용할 수 있습니다.전역 스타일때때로 하위 컴포넌트 안의 스타일을 바꿔야 합니다. 일례로 React에서 마크다운을 사용하는 경우가 있습니다. post 페이지(pages/post.js)에서 볼 수 있습니다.post 페이지는 전역 스타일이 유용하게 쓰일 수 있는 곳입니다. styled-jsx를 사용하여 몇 가지 전역 스타일을 추가해봅시다. pages/post.js에 다음과 같은 내용을 적용해주세요.다음 내용을 적용하기 전에 npm install --save react-markdown 명령어를 통해 react-markdown 컴포넌트를 설치해주세요. 무슨 일이 일어나나요?- 아무런 일도 일어나지 않는다.- 마크다운 컨텐츠에 스타일이 적용된다.- 페이지에 에러가 발생한다.- 콘솔에 에러가 발생한다.전역 스타일이 동작합니다전역적으로 스타일이 적용되므로 잘 동작합니다.이 기능은 매우 유용할 수 있지만 항상 전역 prop 없이 스타일을 작성하길 추천합니다.여전히 일반적인 스타일 태그보다 좋은 방법입니다. styled-jsx를 사용하면 필요한 모든 접두사와 CSS 유효성 검사가 babel 플러그인 내부에서 수행되어 추가적인 런타임 오버헤드가 없습니다.다음엔 무엇을 해야할까요이 편에서는 styled-jsx의 표면만 다루었습니다. 더 많은 것들을 할 수 있습니다. styled-jsx Github 저장소에서 더 많은 내용을 참고하세요.Next.js에서 꽤나 괜찮은 다른 스타일링 방법들이 있습니다. 이 부분도 같이 참고해주세요.#트레바리 #개발자 #안드로이드 #앱개발 #Next.js #백엔드 #인사이트 #경험공유
조회수 10189

파이썬의 시간대에 대해 알아보기(datetime.timezone)

안녕하세요. 스포카 크리에이터 김두리입니다.  스포카는 많은 프로덕트에서 국제화 서비스를 제공하고 있습니다. 그래서 시간대와 시간을 제대로 정확하게 처리하는 것은 중요합니다. 하지만 파이썬의 datetime.datetime은 날짜(datetime.date)와 시각(datetime.time)의 정보를 담고 있고, 시간대(datetime.timezone)의 정보는 담거나 담지 않을 수도 있으므로 헷갈리는 부분이 존재합니다.     시간을 처리할 때 시간대는 왜 중요할까요? 시간대가 명시되지 않은 시각은 충분한 정보를 내포하고 있지 않습니다. 저는 얼마 전, Google Calendar API를 이용하여 작업할 때 골치 아픈 일을 겪었습니다. 오늘의 일정을 불러오고 싶어서 오늘 0시~24시로 데이터를 요청했지만, 계속해서 결괏값에 다음 날의 일정도 포함되어서 반환되었습니다.   왜 다음날 일정도 포함되었던 걸까요? 아래와 같은 코드를 작성하여 Google Calendar API에 요청했습니다.   today = datetime.date.today() from_ = datetime.datetime(today.year, today.month, today.day, 0, 0, 0) to = datetime.datetime(today.year, today.month, today.day, 23, 59, 59) events = get_events_from_google_calendar(from_, to)   몇 시간 동안 머리를 싸매고 코드를 한 줄 한 줄 따져가며 고민을 했습니다. 결국, 제가 요청한 시각에 시간대가 지정되어 있지 않아 get_events_from_google_calendar() 함수 내부에서 from_과 to가 의도하지 않은 시간대의 시각으로 인식되어서 발생했던 문제라는 것을 알게 되었습니다.  # 원래 의도했던 시간대: 대한민국 시간대(KST)에서 오늘 0시 0분 0초 KST = datetime.timezone(datetime.timedelta(hours=9)) from1 = datetime.datetime(today.year, today.month, today.day, 0, 0, 0, tzinfo=KST) # get_events_from_google_calendar()가 받아들인 시간대: UTC 시간대에서 오늘 0시 0분 0초 from2 = datetime.datetime(today.year, today.month, today.day, 0, 0, 0, tzinfo=datetime.timezone.utc)   위 예제에서 from2 - from1를 하게 되면 timedelta(hours=9)가 계산됩니다. 우리가 원했던 것은 KST 기준 오늘 0시부터의 일정이었지만, Google Calendar API에서는 시간대를 UTC로 취급하여 KST 기준 오늘 9시부터 다음날 9시까지의 일정을 불러왔던 것입니다.  이렇듯 시간 관련 작업을 할 때 시간대에 대해 제대로 알고 있지 않으면 의도치 않게 많은 시간을 소모하게 될 수도 있습니다.  오늘은 제가 파이썬으로 시간대 관련 처리를 하며 모았던 정보를 정리하여 공유하고자 글을 작성하게 되었습니다.  시간대  나라 또는 지역마다 살아가는 시각이 다르기 때문에 시간대에 따른 편차가 존재합니다. 이 차이가 피부로 잘 와닿지 않은 채 살아가더라도 캘린더 API나 국제화 서비스 준비 등등 시간과 관련된 작업을 진행하다 보면 시간대 문제에 직면하게 됩니다.  시간대는 영국의 그리니치 천문대(본초 자오선, 경도 0도)를 기준으로 지역에 따른 시간의 차이, 다시 말해 지구의 자전에 따른 지역 사이에 생기는 낮과 밤의 차이를 인위적으로 조정하기 위해 고안된 시간의 구분 선을 일컫는다. 시간대는 협정 세계시(UTC)를 기준으로 한 상대적인 차이로 나타낸다.     UTC에 대한 더 자세한 내용은 여기를 참고해주세요.   시간대에 대한 더 자세한 내용은 여기를 참고해주세요.   파이썬의 datetime.datetime.now()는 실행 환경의 시간대에 따라서 시각을 표시합니다.  2019-01-01 00:00:00 +09:00에 시간대가 Asia/Seoul로 설정된 제 랩탑에서 현재 시각을 가지고 오면, 아래와 같은 시각이 표시됩니다.  >>> print(datetime.datetime.now()) 2019-01-01 00:00:00.000000   그런데, 같은 시각에 Asia/Taipei로 설정된 랩탑에서는 현재 시각이 아래와 같이 표시됩니다.  >>> print(datetime.datetime.now()) 2018-12-31 23:00:00.000000  위의 예제처럼 시간대에 따라 시각이 다를 수 있다는 것을 알 수 있습니다.  나라별 시간대 비교해보기  UTC를 기준으로 시간이 빠르면 +시차, 시간이 느리면 -시차로 표시합니다.                                                                                                                                시간대나라코드UTC-5미국(동부)ESTUTC영국GMTUTC+8대만TWUTC+9대한민국KSTUTC+9일본JSTUTC+10오스트레일리아(동부)AEST     나라별 시간대 차이에 대한 더 자세한 내용은 여기를 참고해주세요.   시간대를 명확히 표시하지 않은 시각은 혼동을 일으킬 수 있습니다. 예를 들어서, 서울에 살고 있는 점주가 2019년 1월 1일 0시 0분에 방문한 고객을 알고 싶어 한다고 가정해봅시다. 이 데이터를 파이썬으로 표현하면 아래와 같이 적을 수 있습니다.  KST = datetime.timezone(datetime.timedelta(hours=9)) korea_1_1 = datetime.datetime(2019, 1, 1, 0, 0, 0, tzinfo=KST)   만약, 대만에 사는 점주가 이를 요청했다면 아래와 같이 적을 수 있습니다.  TW = datetime.timezone(datetime.timedelta(hours=8)) taipei_1_1 = datetime.datetime(2019, 1, 1, 0, 0, 0, tzinfo=TW)   위 예제에서 보이는 것 같이 대한민국과 대만에 있는 점주가 같은 시각을 요청했더라도, 시간대(KST/TW)에 따라서 별도로 처리해야 합니다.  assert korea_1_1 != taipei_1_1 assert taipei_1_1 - korea_1_1 == datetime.timedelta(hours=1) # 같은 시각이지만 시간대에 따라서 시간차가 있습니다.   그렇기 때문에 시간대가 표시되어 있지 않은 2019년 1월 1일이라는 정보만으로는 정확한 시각을 알 수 없습니다.  naive_1_1 = datetime.datetime(2019, 1, 1, 0, 0, 0) assert korea_1_1 != naive_1_1 assert taipei_1_1 != naive_1_1   이런 상황을 해결하기 위해 시각은 어떤 한 시각을 기준으로 하여 그 차이가 표시되어야 합니다. 그 기준으로 정한 것이 UTC입니다. 대한민국은 UTC를 기준으로 아홉시간 빠르기 때문에 korea_1_1의 시각을 UTC 시간대로 표현하면 2018-12-31 15:00:00+00:00입니다. 대만은 UTC를 기준으로 여덟시간 빠르기 때문에 taipei_1_1의 시각을 UTC 시간대로 표현하면 2018-12-31 16:00:00+00:00입니다. 위의 시각은 각각 대한민국(2019-01-01 00:00:00+09:00), 대만(2019-01-01 00:00:00+08:00)으로 표시할 수 있습니다. 이렇게 시간대와 같이 표시하면 혼란 없이 정상적으로 처리할 수 있습니다.  datetime  datetime은 파이썬에서 기본으로 제공하는 표준 라이브러리로, 간단하거나 복잡한 방식으로 날짜와 시각을 조작하기 위한 클래스를 제공합니다.  The datetime module supplies classes for manipulating dates and times in both simple and complex ways.  datetime은 시간대 포함 여부에 따라서 naive datetime, aware datetime 두 가지로 나눕니다.  naive datetime / aware datetime  datetime의 타입을 알아봅시다. 파이썬에서 시간 관련 연산을 하다 보면 종종 아래와 같은 에러 문구를 만날 수 있습니다.  >>> a = datetime.datetime.now() >>> b = datetime.datetime.now(datetime.timezone.utc) >>> a - b Traceback (most recent call last): File "", line 1, in TypeError: can't subtract offset-naive and offset-aware datetimes      naive datetime : naive datetime 객체는 그 자체만으로 시간대를 찾을 수 있는 충분한 정보를 포함하지 않습니다. (e.g. datetime.datetime(2019, 2, 15, 4, 58, 4, 114979))   aware datetime(timezone-aware) : 시간대를 포함합니다. (e.g.datetime.datetime(2019, 2, 15, 4, 58, 4, 114979, tzinfo=)) aware datetime 객체는 자신의 시각 정보를 다른 aware datetime 객체와 상대적인 값으로 조정할 수 있도록 시간대나 일광 절약 시간 정책 혹은 적용 가능한 알고리즘 정보를 담고 있습니다.   tzinfo는 UTC, 시간대 이름 및 DST 오프셋에서 로컬 시간의 오프셋을 나타내는 방법을 담고 있습니다. 더 자세한 내용은 공식 문서를 확인해주세요.  naive datetime은 어느 시간대를 기준으로 하는 시각인지 모호하므로 aware datetime을 이용하는 것을 권장합니다.  직접 확인해보기  준비한 몇 가지 코드를 보며 확인해봅시다. naive datetime과 aware datetime의 차이를 확인하고, 시간대 지정 방법에 대한 내용을 다룹니다.  개발환경     Python 3.7   pytz   여기서는 datetime을 쉽게 다루기 위해 pytz 라이브러리를 사용합니다. pytz는 아래와 같은 장점이 있습니다.    시간대를 시간차가 아닌 사람이 알아보기 쉬운 지역 이름으로 비교적 쉽게 설정할 수 있습니다.   원하는 시간대의 aware datetime으로 변경해주는 localize() 메소드를 제공합니다.   pytz 사용에 앞서, pytz가 제공하는 시간대 식별자를 확인하시려면 다음을 따라 해주세요. import pytz for tz in pytz.all_timezones: print(tz)  혹은 여기를 참고하셔도 좋습니다.  naive datetime  naive datetime은 날짜와 시각만을 갖습니다.  import datetime datetime.datetime.utcnow() # UTC 기준 naive datetime : datetime.datetime(2019, 2, 15, 4, 54, 29, 281594) datetime.datetime.now() # 실행 환경 시간대 기준 naive datetime : datetime.datetime(2019, 2, 15, 13, 54, 32, 939155)   aware datetime naive datetime과 달리 aware datetime은 시간대 정보(tzinfo) 도 갖습니다. import datetime from pytz import utc utc.localize(datetime.datetime.utcnow()) # UTC 기준 aware datetime : datetime.datetime(2019, 2, 15, 4, 55, 3, 310474, tzinfo=)   now는 UTC를 기준으로 현재 시각을 생성합니다. 하지만, naive한 시각입니다.  now = datetime.datetime.utcnow()   이 시각은 naive한 시각이므로 pytz.timezone.localize를 통해 timezone-aware한 시각으로 변환된 시각과 동일하지 않습니다.  assert now != utc.localize(now)   시간대 제대로 지정하기  시간대가 무엇이고, 명시하는 것이 왜 중요한지 알게 되셨다면 시간대를 원하는 의도에 맞게 지정하는 방법에 대해 알아봅시다.  import datetime from pytz import timezone, utc KST = timezone('Asia/Seoul') now = datetime.datetime.utcnow() # UTC 기준 naive datetime : datetime.datetime(2019, 2, 15, 4, 18, 28, 805879) utc.localize(now) # UTC 기준 aware datetime : datetime.datetime(2019, 2, 15, 4, 18, 28, 805879, tzinfo=) KST.localize(now) # UTC 시각, 시간대만 KST : datetime.datetime(2019, 2, 15, 4, 18, 28, 805879, tzinfo=) utc.localize(now).astimezone(KST) # KST 기준 aware datetime : datetime.datetime(2019, 2, 15, 13, 18, 28, 805879, tzinfo=)   replace() 메소드로 날짜나 시간대를 변경할 수 있습니다.  KST = timezone('Asia/Seoul') TW = timezone('Asia/Taipei') date = datetime.datetime.now() # datetime.datetime(2019, 2, 15, 13, 59, 44, 872224) date.replace(hour=10) # hour만 변경 # datetime.datetime(2019, 2, 15, 10, 59, 44, 872224) date.replace(tzinfo=KST) # tzinfo만 변경 # datetime.datetime(2019, 2, 15, 13, 59, 44, 872224, tzinfo=) date.replace(tzinfo=TW) # tzinfo만 변경 # datetime.datetime(2019, 2, 15, 13, 59, 44, 872224, tzinfo=)   하지만 replace는 그 속성 자체만을 바꿔버리는 것이기 때문에 사용에 주의할 필요가 있습니다.  now = datetime.datetime.utcnow() assert utc.localize(now) == now.replace(tzinfo=utc) assert KST.localize(now) != now.replace(tzinfo=KST) assert TW.localize(now) != now.replace(tzinfo=TW)  그뿐만 아니라 replace()를 이용할 경우 의도하지 않은 시간대로 설정될 수도 있으므로 유의해야 합니다. 그 이유는 아래와 같습니다.     시간대는 생각보다 자주 바뀝니다(더 자세한 내용은 스포카의 규칙 2번을 참고해주세요). 이렇게 변경되는 사항들은 tz database에 기록되는데, pytz는 이에 기반합니다. pytz의 버전이 2018.9와 같은 날짜로 되어있는데 2018.9 버전은 2018년 9월 기준 시간대 테이블을 기준으로 시간대를 만들어주는 버전입니다. 이 버전에선 Asia/Seoul의 시간대는 UTC+9입니다.   pytz는 무슨 이유에서 인지 datetime.replace()나 datetime.astimezone()에서 호출될 때 이 tz database 타임 테이블의 맨 첫 번째(가장 오래된) 기록을 가지고 변환을 시도합니다. 서울의 경우 초기에 UTC+8:28이었기 때문에 이 정보를 기반으로 변환합니다.   그래서 pytz를 사용할 때는 pytz.timezone.localize()를 항상 써야 하고, .astimezone()같은 파이썬의 표준 메서드들을 사용하고 싶다면 datetime.timezone을 사용해야 합니다.  스포카의 규칙 스포카에서 datetime을 다룰 때 흔히 따르는 두 가지 큰 원칙이 있습니다.  1. naive datetime은 절대 사용하지 않습니다. 가장 큰 이유는 naive datetime과 aware datetime을 서로 섞어서 쓰지 못한다는 것입니다.  >>> from datetime import datetime, timezone >>> datetime.utcnow() + datetime.now(tz=timezone.utc) Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'datetime.datetime' and 'datetime.datetime'   동적 타입 언어에서 쓸 수 있는 가장 간단한 타입 검사 수단인 isinstance() 체크로도 이 둘을 구별할 수가 없으므로, 코드의 어느 지점에서 naive datetime이 섞이기 시작하면 예기치 않은 지점에서 버그 발생 가능성이 급격히 올라갑니다. Python 2에서 str과 unicode를 섞으면 안 되는 것과 비슷한 이유라고 생각하시면 됩니다.  2. 장기적으로 보존해야 하는 datetime은 항상 UTC를 기준으로 저장합니다. 지역 시간대는 지정학적 또는 정치적인 이유로 생각보다 자주 바뀝니다. 예컨대 1961년 이전까지 한국은 UTC+08:30을 지역 시간대로 사용했었고, 1988년 올림픽 즈음에는 일광 절약 시간대를 시행하고 있었습니다. 시간대 데이터베이스(tz database)는 이런 변경 내역을 담고 있고, pytz가 제공하는 시간대 객체의 동작에도 반영되어 있습니다. 그 때문에 시간대 데이터베이스가 제때 업데이트되지 않거나, 갑작스러운 시간대 변경으로 데이터베이스에 반영이 늦어지거나 하면, 시간 계산에서 오차가 발생할 여지가 있습니다. 또한 같은 aware datetime 이어도 서로 다른 시간대를 가진 datetime끼리 연산하거나 하는 상황도 문제를 복잡하게 만들고, DB나 다른 서비스의 API를 사용할 때, 그 서비스가 시간대를 제대로 다루는 데에 필요한 복잡도를 감수하는 대신 단순히 UTC 기준의 고정 오프셋 시간대만 사용하는 등의 이유로 서로 지원 범위가 맞지 않아 곤란을 겪을 수도 있습니다.  혼선을 줄일 수 있는 좋은 규칙 중 하나는, str과 unicode를 다루던 것과 비슷하게 모든 내부적인 계산에서 UTC 기준의 aware datetime만 사용하고, 사용자에게 보여줘야 할 때만 필요한 시간대로 변환해서 보여 주는 것입니다.  스포카에서는 메인 서버의 dodo.datetime 유틸리티 모듈도 이런 규칙을 따르고 있으며, 대부분의 SQLAlchemy DB 모델 객체의 DateTime 컬럼에서 timezone=True 옵션을 켜서 사용하고 있습니다.  정리  시간 관련 작업을 하신다면 아래 사항을 꼭 기억해주세요.시간대를 명시합시다.시각을 애플리케이션 로직이나 데이터베이스에서 저장할 때는 UTC로 사용하고, 유저에게 표시할 때만 유저의 시간대로 변환하여 보여주도록 합시다.    백엔드 서버끼리 통신할 때도 항상 UTC를 사용한다는 가정을 하면, 시간대가 없더라도 robust하게 처리할 수 있습니다.
조회수 1820

서비스 중단 없이 Amazon EKS로 옮긴 이야기 - VCNC Engineering Blog

Amazon EKS는 AWS의 관리형 Kubernetes 서비스입니다. 2017년 11월 AWS re:Invent에서 프리뷰 버전이 출시되었고, 2018년 6월에 상용(GA) 버전이 미국 리전에만 출시되었습니다. 그래서 서울 리전을 사용해야 했던 타다 프로젝트에서는 Kubernetes 클러스터를 직접 kops로 설치하여 운영할 수 밖에 없었습니다.2019년 1월, 오랜 기다림 끝에 드디어 서울 리전에 EKS가 출시되어 기쁜 마음으로 EKS로 옮겨가게 되었습니다. 이 글에서는 직접 구축한 클러스터 대비 EKS의 특징에는 어떤 것이 있는지 살펴보고, 서비스 중단 없이 EKS로 옮기기 위한 전략을 공유하고자 합니다.EKS 서울 리전 출시를 염원하던 한국인(?)들EKS는 뭐가 다른가요?AWS에서 마스터 노드를 관리해줍니다.Kubernetes 클러스터는 마스터 노드와 워커 노드로 구성되어 있습니다. EKS는 이 중에서 마스터 노드를 직접 EC2로 띄울 필요 없이 AWS에서 관리해주는 서비스입니다. RDS를 사용할 때 직접 DB 인스턴스를 생성하지 않는 것과 비슷합니다. 별도의 설정 없이도 알아서 여러 가용 영역에 마스터 노드를 실행하여 HA(고가용성) 구성을 해주고, 비정상 마스터 노드를 자동으로 감지하고 교체합니다. 또한 자동화된 버전 업그레이드 및 패치를 지원합니다. EKS를 사용하더라도 워커 노드는 직접 EC2 인스턴스를 생성·관리해야 합니다.EKS 클러스터의 요금은 2019년 2월 현재 시간당 $0.20입니다. 타다에서는 기존에 t2.medium 3대를 마스터 노드로 사용하고 있었기 때문에 관리를 직접 하지 않는 대신 비용이 약간 증가하게 되었습니다.AWS IAM 기반 인증을 사용합니다.VCNC에서는 기존에 Kubernetes API에 접속할 때 가장 간단한 basic auth 인증 방식을 사용했습니다. 그 대신 외부 네트워크에서 접근할 수 없게 해두고 필요한 경우 Bastion 호스트를 통해 SSH 터널링하여 접속했습니다.EKS의 API 서버는 인터넷에 노출되어 있으며, 별도로 네트워크 접근 제한 설정을 할 수 없고 AWS IAM으로 사용자를 인증합니다. (물론 공개망에 노출되어 있으면 Kubernetes API 서버에 보안 취약점이 발견되는 경우 안전하지 않을 수 있는 단점이 있습니다. 앞으로 PrivateLink가 지원되면 해결될 것입니다.)IAM은 인증에만 사용되고, 특정 작업을 할 수 있는 권한은 Kubernetes 기본 RBAC로 관리됩니다. IAM 사용자나 역할을 RBAC 그룹에 매핑할 수 있습니다.EKS 인증 흐름도워커 노드 당 Pod 개수 제한이 있습니다.예를 들어 c5.large 인스턴스에는 29개의 Pod을 띄울 수 있습니다. (표 참고) 그러므로 기존 클러스터에서 노드 당 Pod이 몇 개나 되는지 미리 확인할 필요가 있습니다. 왜 이런 제약이 있을까요?Kubernetes에서는 네트워킹 플러그인으로 Pod 사이에 네트워크 통신하는 방식을 다양하게 설정할 수 있습니다. EKS는 기본적으로 amazon-vpc-cni-k8s를 사용합니다. 이 네트워킹 플러그인은 VPC 상에서 유효한 실제 IP를 Pod에 할당합니다.그러기 위해서는 하나의 EC2 인스턴스에서 여러 개의 IP를 받아와야 하고, 이를 위해 추가적인 네트워크 인터페이스(ENI)를 붙입니다. 그런데 인스턴스 타입에 따라 추가할 수 있는 ENI 수와 ENI 당 IP 수에 제한이 있습니다. 따라서 이 제한이 워커 노드 하나에 띄울 수 있는 Pod 개수 제한이 됩니다.flannel 등 오버레이 네트워크 기반의 다른 네트워크 플러그인을 사용하면 이러한 제약을 피할 수 있습니다. 하지만 EKS에서 기본 제공하는 방법을 그대로 사용하는 것이 좋고, Pod을 엄청나게 많이 띄워야 하는 상황이 아니어서 시도하지 않았습니다.EKS로 중단 없이 넘어가기개요타다의 Kubernetes 클러스터에서 돌아가는 서비스들은 모두 영속적인(persistent) 상태를 가지고 있지 않습니다. 따라서 EKS 클러스터 위에 동일한 서비스를 띄우고 외부 트래픽을 옮겨주기만 하면 특별히 데이터를 옮기지 않고도 이전이 가능했습니다. 또한 거의 대부분의 Kubernetes 리소스는 Helm 차트로 생성한 것이기 때문에 새로운 클러스터에 동일한 서비스를 띄우는 작업도 쉽게 할 수 있었습니다.이전 작업은 다음과 같은 순서로 진행했습니다.EKS 클러스터를 만들고 워커 노드를 생성모든 서비스 다시 설치트래픽을 새 클러스터로 보내기이전 클러스터 제거EKS 클러스터를 만들고 워커 노드를 생성타다의 AWS 환경은 거의 모두 Terraform으로 정의되어 관리되고 있습니다. EKS 클러스터와 워커 노드도 HashiCorp Learn의 문서를 참고해서 Terraform으로 생성했습니다. 해당 문서에 설명이 잘 되어 있어서 거의 그대로 따라할 수 있었습니다.EKS 클러스터 설정은 재사용 가능하도록 Terraform 모듈로 만들었습니다. 덕분에 테스트용 클러스터와 실서비스용 클러스터를 동일한 모듈로 변수만 바꿔서 설정할 수 있었습니다.모든 서비스 다시 설치타다의 Kubernetes 리소스는 Helm 차트로 관리되고 있어서 기존 차트를 거의 그대로 설치할 수 있었습니다. 사용자에게 직접적인 영향을 덜 주는 워커 서비스를 먼저 설치해서 제대로 동작하는 것을 확인한 뒤, 마지막으로 프론트엔드 서비스를 설치하였습니다.트래픽을 새 클러스터로 보내기타다의 모든 트래픽은 NLB로 들어온 뒤 NGINX를 거쳐 다시 적절한 Pod에 라우팅됩니다. 그러므로 타다의 모든 도메인은 NLB를 가리키고 있습니다.타다는 Route 53을 DNS 서버로 사용합니다. Route 53에는 가중치 기반 DNS 레코드를 설정할 수 있습니다. 이를 이용하여 일부 트래픽만 새 클러스터의 NLB로 보낼 수 있습니다. 처음에는 아주 적은 트래픽만 새 클러스터로 보내다가 문제 없이 작동하는 것을 확인한 다음 조금씩 트래픽을 늘려나갔습니다.DNS 가중치 설정으로 일부 트래픽만 새 클러스터의 NLB로 보낼 수 있습니다.DNS 설정에서 이전 클러스터로 가는 레코드를 완전히 제거한 뒤에도, DNS 캐시 등의 이유로 일부 클라이언트가 이전 클러스터에 접속할 수도 있습니다. 따라서, 이전 클러스터 NLB에 새 클러스터의 노드들을 붙여서 아직 DNS를 따라오지 못한 클라이언트들의 요청을 처리하였습니다.이전 클러스터 제거가장 신나면서 조심해야 하는 작업입니다. 먼저 이전 클러스터로 트래픽이 전혀 들어오지 않는 것을 확인하였습니다. 그 다음에는 Terraform에서 이전 클러스터 리소스에 대한 참조를 제거한 뒤, terraform destroy 명령으로 이전 클러스터와 관련된 리소스를 한번에 삭제할 수 있었습니다.맺음말Kubernetes는 깔끔한 추상화를 통해 컨테이너 기반 배포를 간단하게 만들어주지만, 직접 클러스터를 관리해야 하는 부담이 있었습니다. Amazon EKS는 이러한 부담을 많이 덜어주는 좋은 서비스입니다. 앞으로 EKS의 무궁한 발전을 기원합니다.VCNC에는 오랫동안 쌓아온 AWS 인프라 운영 경험이 있습니다. 타다에서는 그동안의 경험과 비교적 최근에 시작한 프로젝트의 이점을 살려 컨테이너, Infrastructure as Code 등 업계 표준의 인프라 관리 방법론을 적극 도입하려고 노력하고 있습니다. 앞으로도 이에 관해 기술 블로그에 더 자세히 공유할 계획이니 기대해주세요. 또한 저희와 함께 안정적인 서비스를 만들어나갈 좋은 분들을 기다리고 있으니 VCNC 채용에도 많은 관심 부탁드립니다.
조회수 1637

프로세스 모델의 적합도 검사하기

프로세스 모델 도출은 프로세스 마이닝의 출발점이며, 매우 유용합니다. 원본 데이터로부터 프로세스 흐름 모델을 자동으로 구성하여 실제 프로세스를 알 수 있습니다. 이렇게 도출된 프로세스 모델과 이벤트 로그를 비교하는 것이 적합도 검사(Conformance checking)입니다. 적합도는 이전에 말씀드린 정확도(Precision)와는 다른 개념입니다. 정확도(Precision)는 Underfitting을 피하여 데이터를 정확하게 설명할 수 있으나 정확도가 높을수록 프로세스 모델이 대체로 복잡해지게 됩니다. 하지만 적합도가 높다고 하여 프로세스 모델이 복잡해지는 것은 아닙니다.적합도 검사의 기본 아이디어는 프로세스 모델 위에 이벤트 로그를 재생하는 것입니다.아래 예제 모델에 이벤트 로그 a → c → e → g를 재생하여 적합성 검사를 해보겠습니다.[그림 1] 프로세스 모델 예제먼저 a 이벤트를 수행하였습니다.[그림 2] a 이벤트 수행 후다음으로 c 이벤트를 수행했습니다.[그림 3] a, c 이벤트 수행 후이벤트 로그에서는 다음에 e를 수행해야 합니다. [그림 3]을 보면 e를 수행하기 위해서는 d가 먼저 수행되어야 합니다. 하지만 실제 로그에서는 d 수행 없이 e가 수행되었기 때문에 d를 무시하고 e를 수행합니다.마지막으로 g 이벤트 수행하여 프로세스를 마칩니다.이벤트 로그 재생이 완료되면 액티비티 d에 실행되지 못한 토큰이 남아있게 됩니다. [그림 5] 이벤트 로그 재생 후 남아 있는 토큰프로세스 모델 위에 이벤트 로그를 재생하는 동안 얼마나 많은 토큰을 사용하고(이벤트 수행 횟수) 어떤 이벤트를 생략하고 추가했는지 기록합니다. 이를 통해 기록된 이벤트 로그와 모델의 적합도를 비교할 수 있습니다. 적합도가 1이면 모든 로그가 프로세스 모델에 잘 맞는다는 뜻이고, 0에 가까우면 적합도가 매우 낮다는 의미입니다.적합도 검사는 어디에 활용할 수 있을까요? 사람들이 표준 프로세스와 달리 행동하는 이유를 찾을 때 활용 가능합니다. 왜 사람들이 기존 프로세스를 벗어나는지, 벗어나는 부분에 대해서는 잘 보고되었는지 확인할 수 있습니다. 일반적인 감사(Audit and compliance) 절차에도 활용 가능합니다.다른 사례는 도출된 프로세스 모델의 품질을 측정하기 위해 활용할 수 있습니다. 여러 알고리즘을 사용하여 프로세스 모델을 도출했을 경우 어떤 모델이 가장 적합하고 좋은 모델인지 비교해 볼 수 있습니다.마지막으로 프로세스 설명이 제대로 되어 있는지 실제 행동을 기반으로 확인할 수 있습니다. 예를 들어 어떤 서비스를 제공하는 경우 서비스 실행 방법 매뉴얼과 실제로 제공되는 서비스를 비교하여 일치하는지 확인할 수 있습니다.※ 본 블로그에 사용된 그림은 Van der Aalst 교수님 강의자료를 사용하였습니다.#퍼즐데이터 #개발팀 #개발자 #개발후기 #인사이트
조회수 3737

개발자, 디자이너, 기획자의 온도차

 아마 가장 많은 분들이 생각하시기에 가장 걱정되는 부분이라고 생각이 듭니다.그래서 저 역시도 이 이야기를 하는 것에 좀 조심스럽습니다. 이야기는 바로 "업무를 대하는 개발자, 기획자, 디자이너 간의   온도차."입니다. (다시 한번 말씀드려요! 제가 사용한 방법이 백프로 모두에게 맞는 말은 아닙니다!!) 스타트업은 큰 기업처럼 디자인팀, 개발팀, 기획팀이 갈려서 서로의 팀장에게 허가를 받고, 기획을 시작하고, 개발을 시작하고, 디자인하는 그런 상하관계의 구조가 아닙니다. 서로서로들 비슷한 경력들과 환경에서 서비스를 제작하는 사람들이 많죠. 특히, 젊은 스타트업 기업들은 대학생들이나 대학원생 등 아직 본격적인 사회생활을 해보지 않은 인원들이 더 많을 것으로 알고 있습니다. 아시다시피, 다들 맞춰진 직무를 기반으로 개발자는 개발자의 생각과 계산에 따라서 일을 진행하고 있고, 기획자는 기한에 맞춰 예상했던 진행대로 일을 진행하고 싶어 하고, 디자이너들은 보다 다은 디자인으로 서비스를 보이려 다양한 자료들을 모으고 분석하여 제작자의 아이디어를 입혀 새로운 콘텐츠를 제작하려 노력합니다.문제는 서로가 서로의 일에 대하여 모른다는 것입니다. 스타트업의 팀원들 간의 커뮤니케이션은 마치 연애와 같아서 서로 이야기해주지 않으면 모를 수밖에 없고, 서로 어떻게 일을 하는지, 얼마나 시간이 걸릴 것이다 등 일정에 대한 공유나, 업무를 하는 절차를 이야기 해주짖 않으면, 원치 않는 감정의 골이 생기기 마련입니다. 이런 문제를 해결하기 위해, 기업은 매일매일 아침시간에 진행하는 Scrum이라든지, Jira, Taskworld, Trello 등 다양한 프로젝트 매니지먼트 툴을 사용하고, 스크럼 마스터나, 다양한 서비스를 제작해 보신 PM(Project Manager), 또는 PO(Product Owner)님들이 각부서의 현황들을 파악하고, 다양한 부서를 총괄하고 관리합니다.그러나, 기본적으로 국내 스타트업 상황은업무자들의 수가 절대적으로 부족하고,젊은 개발자나 디자이너 같은 경우는 생업(또는 학업)과 스타트업을 동시에 하는 인원이 많고,젊은 창업자들과 직원들의 경우, 프로젝트 경험이 없어 이러한 분업구조를  낯설어하고,개발자와 디자이너 역시 자신이 작업하는 프로젝트가 언제쯤 끝날지 가늠할 수 없는 상황이 생기고,적은 인원들이 많은 프로젝트를  진행하느라 예민한 구조가 되어 남을 이해하기 힘든 상황등의 다양한 이유들 때문에 각 직군 간의 갈등 상황이 큰 기업에 대비하여 많이 생기고 있습니다(물론 큰 기업도 문제가 없진 않다고 합니다.).이 전설의 짤을 보신적이 있으신 분들도 많으실듯... (출처: http://9gag.com/) 이러한 갈등 해결 방안은 다음에 더  디테일하게 설명드리도록 하고, 이번 글에서는 간단히 저가 생각하는 발전방향에 대하여  이야기해보도록 하겠습니다. 앞서 말씀드린 것과 같이, 스타트업 팀원들의 관계는 마치 연예와 비슷하다고 생각합니다. 말하지 않으면 모를 수밖에 없는 노릇이고, 말을 해줘도 이해할 수 없는 일들이 수두룩 합니다(그런 이유로 저는, 스타트업에서 근무하시는 분들은 서로의 업무에 대하여 어느 정도의 배경지식을 배우는 게 필요하다고 생각합니다.). 그럼에도 불구하고 우리는 항상 이야기를 해야 해요. 연애를 할 때도 말이 안 통해도 될 때까지 이야기하듯이. 스타트업에서의 업무는 끊임없이 피보팅을 진행하고, 하루하루 떠오르는 처리해야 할 일들이 생깁니다. 그리고, 그러한 변경사항들에 관하여  이야기할 때, 서로가 서로의 말을 이해해 주지 못한다면, 더 큰 갈등 상황들을 야기하기 마련이지요. 그러나, 만약 각 직군의 전문가들이 서로의 업무에 대한 배경이나, 아주 기본적이더라도 기초사항을 알고 있다면, 서로의 업무량에 대한 불만이 아무래도 적을  수밖에 없다고 생각합니다. 제가 스타트업을 진행할 당시를 말씀드리자면, 저는 창업 당시 기획자로서 서비스를 기획하고, 프로젝트를 관리하고, 투자 또는 공모전 등에 쓰일 기획서 등을 제작하는 업무를 주로 하였습니다. 디자인에 관하여는 무엇을 논할 수 있는 실력도 아니고, 개발에 관하여는 더더욱 그렇습니다. 그러므로 기획서를 작성할 때나, 어떤 계획을 할 때 “원하는 시간”을 개발자나 디자이너에게 요청하고, 그러한 요청 사안과 당사자들과의 이야기를 통해 조정하고 계획을 진행하는 것이 주  업무였습니다. 그리고 나름 생각하기에는 "개발이나 디자인을 하나도 모르는 사람이 일의 진행 정도를 스스로 보고 판단하고, 기한을 준다는 것은 올바르지 않다."라고 생각하여 아주 기초적일 수 있지만 웹 공부와 포토샵 일러스트 디자인 등의 디자인과 개발 툴 공부를 꾸준히 하면서 개발과 기획에서 어느 정도  서포트할 수 있는 실력을 기르기 위해 많은 시간을 투자했었습니다. 그리고 이러한 노력 덕분에 서로의 직군과 업무에 대한 고충을 이해할 수 있어서 많은 이점을 가질 수 있었지만, 그럼에도 불구하고, 자주자주 일이 딜레이 되는 상황이 발생하였고, 그러함에 따라서 개발자와 디자이너와 기획자들이 조금씩 소원해지고  섭섭해지는 상황이 발생하였던 것 같습니다. 그래서 하나 더 생각했던 것이, "일을 처음 시작하는 초보들에게도 바로 적용해서 업무에 도입할 수 없는 어려운 프로젝트 매니지먼트 툴이 아닌 서로의 작업현황이나, 상태 정도를 가늠할 수 있는 PM 툴을 만들어 보자." 하는 것이었습니다. 그래서 창업 당시 사용한 아주 간단한 툴이 있는데, 이 프로젝트 메니지 방법은 내일 이미지로 보여드리면서 설명드릴게요. :) 그리고 지금은 Taskworld나 Jira 같은 더 전문적인 툴을 사용하고 있지만, 해당 툴에 대한 전문전 지식이 아직 없는 분들은 엑셀 등으로 서로의 일을 정리해서 공유하는 것도 좋을 것 같네요! 기회가 되면, 요즘은 제가 어떤 식으로 툴을 사용하는지 설명하는 글도 적도록 하겠습니다! 마지막으로 긴 글을 세줄 정리하자면, 1. 개발자, 기획자, 디자이너는 달라요. x나 달라요.... 2. 다르면 잘 들어보고 뭘 하는지 아는 것이 중요하다고 생각합니다. 3. 그리고 서로가 어떤 일을 하고 있는지 현황을 파악할 수 있다면 더 좋겠죠?오늘도 읽어주셔서 감사합니다! 좋은 하루들 되세요:)#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트

기업문화 엿볼 때, 더팀스

로그인

/