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

개발자와 개발 조직에게 소스코드 리뷰는 필수적이다. 팀간의 협업과 대화를 보다 원활하게 만들어 주는 매우 필요한 절차이다. 슬랙과 같은 협업도구가 명쾌하게 의미 있게 활용되려면 개발팀 간의 소스코드 리뷰는 필수적으로 수행되는 것이 좋다.매우 당연한 이야기이지만, 소스코드 리뷰는 거북하고 불편하고 어렵고 힘들다. 그럼에도 불구하고 필수적인 이벤트가 되어야 하는 이유가 너무도 많다. 개발자들에게 코드리뷰에 대한 이슈를 설득하고 실제 행위를 발생시키는 것은 정말 어려운일이다. 더군다나 뜬금없이 코드리뷰 이야기를 회사나 팀리더에게서 갑자기 듣는다면 개발자는 매우 불편해 한다. 그것은 매우 당연한 반응이다. 그러므로, 가능하다면 팀 세팅 초기 시부터 이 소스코드 리뷰 문화는 만들어질 수 있게 노력하는 것이 최선일 것이다.초기에 세팅된다면 그 후에 들어오는 팀원들은 자연스럽게 그 문화에 익숙해진다. 이런 일련의 작업들은 결국 조직과 팀의 단결과 협력, 향후 유지보수에 매우 긍정적인 효과를 준다.매우 당연하지만 개발자들은 팀에 소속되고 빠져나가기를 반복한다. 이를 두려워하지 않는 방법 중에 가장 먼저 선택할 수 있는 것이 바로 코드 리뷰라는 행위다. 인수인계와 유지보수를 위해서 소스코드 리뷰를 각 단계별에 배치해두고, 그 시간을 투자하는 것을  아까워하지 않도록 하자.그렇다면, 소프트웨어의 본체인 소스코드를 타인이 리뷰한다는 것이 왜 어려울까? 그것은 소스코드는 언제나 완성상태가 아니라는 점 때문이다. 개발자의 생각은 무언가 다양한 변화를 예측하고 있고, 그 상세한 준비를 담고 있다. 언제나 소스코드는 완성 상태가 아니라, 변화되어야 하는 시간의 축을 담고 있기 때문이다.하지만, 소프트웨어 품질이 중요한 현재의 시점에서 본다면, 코드 리뷰라는 행위는 정말 필수 불가결한 행위에  해당한다고 생각한다.이런 필수적인 코드리뷰는 그 형태와 범위에 대해서 팀 내부에 잘 정의되어야 한다.그래서, 보통 이 코드리뷰를 어떻게 할 것인가에 대해서 조직이나 담당하는 사람의 경우에는 명쾌한 판단 기준이 있어야 한다. 그러한 ‘판단기준’을 가져야만 명확한  리뷰될 수 있다.이를 두고, 디자이너에게는 크리틱(critique-비평)이 있고, 개발자에게는 코드리뷰가 있다고 정의한다.좋은 비평을 받고 좋은 리뷰를 하려면 다음의 3가지 원칙이 필수이다.1. 리뷰는 언제나 상호 합의가 되어진 상황에서 진행되어야 한다.2. 리뷰어의 해당 결과물에 대해서 객관성을 가지고 서로 인지해야 한다3. 개발자 자신의 작업물에 대해서 정말 객관적으로 바라볼 수 있는 작성가가 선정되어야 한다.특히, 소프트웨어 코드는 정량적인 검토와 정성적인 검토를 구분해야 한다. 이 영역의 구분이 모호해지면, 리뷰는 그 방향성을 상실하게 된다. 그중에 특히, 정량적인 검토와 기본적인 규칙들은 가능한 자동화하고, 소스 형상관리 도구에서 기본적인 것들의 규칙들을 지키도록 권장하여야 한다. 최소한 이 정량적인 것만 자동화하고  규칙화해도 소프트웨어의 품질은 급상승한다.하지만, 코드는 논쟁을 발생시키고, 어떤 것이 우선적인지에 대해서 서술하기 매우 어렵다. 이러한 점은 정성적인 부분에 대해서 검토할 때에 고민하자.코드리뷰의 정도는 어느 정도 해주어야 하는가?그 전부터 주목하는 개발 방법론의 추세는 ‘테스팅’을 주로 하고, SRS와 같은 요구사항에 집중하기 보다는, TDD와 같은 방법으로 완성 산출물을 높이는 방법을 현재에는 주로 사용하고 있다.그것은 과거에는 요구사항을 통해서 결과물이 완성되는 SI성 개발이 주로였다면, 현재에는 요구사항은 계속 변화하고 버그 없는 결과물이 중요시되는 테스트를 얼마나 더 집중적으로 하느냐에 따른 웹서비스의 시대이기 때문에 그 방향성은 시대에 따라서 변화를 많이 하였다. 그래서, 슬프지만, 당장의 성과물을 위해서라면 코드리뷰보다는 테스팅에 집중하는 것이 더 효율적이다. 빠르게 고속 개발하고 테스트를 통해서 버그를 찾은 다음 수정하는 것이 ‘특정 기능들을 나열하고 기능을 만족하는 소프트웨어’의 경우에는 테스트 주도 개발 방법이 가장 적합하다고 할 수 있다.물론, 이러한 방향성이나 전체적인 틀에 대해서는 아키텍트가 잘 결정하여야 한다. 내가 속한 개발 결과물이 어떤 결과물이냐에 따라서 이 방법은 혼용되어져서 사용되어야 하기 때문이다.하지만, 이번 글의 주목적은 코드리뷰. SRS중심이건, TDD중심이건. 코드리뷰는 중요하다는 것을 강조하고 싶다. 특히, 코드리뷰는 ‘기능 나열’이 아닌, 어느 정도 이상의 복잡도나 코드 품질이 필요한 경우에는 필수적으로 수행하는 것이 매우 현명한 행동이다.물론, 코드리뷰 행위가 불필요한 업무들도 많다. 정해져 있는 단순한 업무를 수행하는 경우에는 굳이 할 필요 없다. 국내에서 SI를 하는 경우에는 대부분 코드리뷰가 필요 없는 업무를 하는 소프트웨어 개발자들이 절대 다수인 경우도 많이 보았다.일반적인 SI의 형태라면 워크 스루의 형태만 적합하다. 특정 도메인에 매몰되어 있고, 처리방법이 명쾌하기 때문에, 해당 경험들을 교환하는 것으로도 충분하기 때문이다. 그리고, 자동화된 테스트 수행방법을 최대한 갖추어두는 것이 가장 현명하다.그러므로, 코드리뷰는 어느 정도 솔루션이나 서비스 등을 고려하고 있는 곳에서 더욱 적합하다고 정의한다.코드리뷰는 특정 제품이나 서비스를 발전적으로 지향하고 있는 경우라면 필수적으로 선택해야 한다. 하지만, 일부 제품의 경우에는 발전적인 지향이 굳이 필요 없는 제품 라인업을 가진 경우에도 굳이 수행할 필요 없다.그 경우에는 선택적인 코드리뷰를 지향하면 된다. 비용상의 문제 때문에 굳이 코드리뷰를 억지로 진행할 필요는 없는 경우도 많다. 대부분의 소프트웨어 개발은 테스트 케이스를 잘 만들고, 통과시키는 것으로써 충분한 신뢰를 가지면 충분한 경우가 대부분이다.특히, 시장이 고착상태이거나, 특별한 변화의 폭이 없다면, 그 정도로 충분한 경우가 된다. 다만, 글로벌 서비스나 웹서비스 등의 지속적인 확장이 필요한 경우라면, 코드리뷰는 필수라고 할 수 있다.코드리뷰가 필요 없는 경우 체크리스트는 다음의 5가지 정도를 체크해보자.1. 특정 도메인만 다루는 팀이나 회사의 개발팀인가?2. 지난 2~3년 정도 솔루션이 크게 변한 것이 없으며, 향후로도 기업이나 팀에서 투자가 없을 예정이다.3. 현재 개발자들이 해당 솔루션에 대한 개발일을 5년 이상하고 있다.4. 기능 위주의 SI성 업무를 주로 처리하고 있으며, 복잡한 알고리즘은 존재하지 않는다.5. 비용과 일정상 개발팀에게 리소스 투여가 불가능하다위의 사례에서 1개 이상이라도 체크된다면, 코드리뷰는 성립하기 힘들다. 대부분 단념하고, TDD나 테스트 케이스를 가능한 많이 축적하여 소프트웨어 품질을 올리기를 권장한다.코드리뷰가 필요한 경우의 체크리스트도 다음의 5가지 정도를 체크해보자.1. 다국어와 시장이 다변화된 환경에서 소프트웨어가 구동되어야 한다.2. 코드의 복잡도가 높으며, 단순 기능 나열의 요구사항이 아니라, 소프트웨어 아키텍처가 별도로 구성되기 시작하였다.3. 사용자의 경험성을 증가하기 위하여 매우 많은 변화가 예측된다.4. 현재 개발 중인 서비스는 중단 없이, 지속적으로 발전되어야 하는 서비스이다.5. 목표 요구사항이 계속 변화하고 있고, 프레임워크를 지향하여 소프트웨어 품질의 요구사항이 매우 중요하다.위의 케이스에서 하나라도 해당이 된다면, 코드리뷰는 매우 효과적으로 소프트웨어에 의미 있는 결과물들을 얻어 내기 위한 좋은 방법이 된다.하지만, 다음과 같은 경우도 같이 고려하여야 한다.코드리뷰의 정도와 질에 대한 검토 리스트의 최소 체크리스트는 다음의 3가지이다. 물론, 이 정의는 조직 내의 아키텍트나 아키텍트 롤을 하는 사람이 결정하는 것이 좋다.1. 실험적인 코드인가?2. 1~2명 이상이 공동으로 작업하는 코드인가?3. 향후 버려질 가능성이 높은 코드인가?코드리뷰를 하지 않는 경우에는 해당 코드의 repository나 디렉터리를 완전하게 분리하고, 리뷰가 안된 코드를 명쾌하게 구분할 수 있어야 한다. 그리고, 그 정보는 팀 전체에게 공개되어야 한다.가장 첫 번째는 코딩규칙 가이드라인의 준수 여부를 체크하는 것이다.개발자들 간의 상호 중요한 것은 스타일 가이드이다. 하지만, 정말 지키기 어려운 것 또한 스타일 가이드라고 할 수 있다. 하지만, 스타일 가이드는 가능한 준수해야 한다. 하지만, 100% 준수하려는 것은 매우 비효율적인 상황을 만들 수 있다. 하지만, 이 경우에 최소한 리뷰어가 제시하는 기준이나 변경 방향에는 대부분 수긍하는 것이 가장 현명하며, 이 부분은 해당 팀의 가장 경험이 풍부한 사람이 리드하는 것이 좋다.그래서, 소프트웨어 개발에는 경험이 풍부한 아키텍트의 역할과 선임의 역할이 가장 중요하다. 소셜에서 이야기하는 가장 중요한 포인트는 이런 경험이 풍부한 선임 개발자가 있다면, 돈이 얼마가 들더라도 ‘개발팀’에 모셔야 한다! 가 정답일 것이다.아직까지 이 부분은 ‘공학’으로 해결할 수 없고, ‘엔지니어링’과 ‘경험’에 의존할  수밖에 없다.주석의 경우에도 ‘가독성’이 충 부한 코드에는 서술할 필요 없다. 이 부분에 대해서는 꾸준한 팀원들 간에 코딩 문화에 대해서  커뮤니케이션하면서 주석의 범위에 대해서 공론화하는 것이 현명하다. 그래서, 소프트웨어 개발은 대부분이 ‘커뮤니케이션’이고 ‘소통’이다. 그래서, ‘팀워크’이 가장 중요한 것이고. 변수의 명칭에 대해서도 ‘명확’하다는 선에서 합의해야 한다.테스트가 쉽지 않은 구조는 다른 문제를 야기한다. Junit과 같은 단위 테스트 도구로 손쉽게 정의가 가능한 구조가 아니라면, 변경해야 한다.코드리뷰 후에 분명하고 타당한 지적에도 고집이 세서 변화가 없는 경우에는 한두 번 이야기하고 더 이상 변화가 없다면, 포기하고. 해당 코드를 격리하여 관리하는 것이 현명하다.  팀원들 간에 감정이 상하는 것이 더 위험하다. 사람은 변하지 않는다 감정에 대한 다툼이나 기대를 할 필요가 없다.UI가 중요한 코드는 해당 코드들이 급변할 가능성이 농후하다. 처음부터 공을 들여서 추상화를 실현하지 않으면, 해당 코드 때문에 프로젝트가 심각해질 수 있다. 사용자에게 더 좋은 경험을 전달하려고 하면, UI코드는 계속 변화를 일으킨다.테스트 코드 여부? 로직에 대한 검토, 변수 네이밍 검토와 레이아웃에 대한 것들? 에 대해서는 다음과 같이 판단하고 체크해보자.코드리뷰는 대부분 ‘직관’에 의존한다. 그래서, 정말 어렵고. 경험이 풍부한 사람이 할  수밖에 없다. 다만, 이러한 코드 리뷰 시의 체크리스트 항목을 몇 가지 간단하게 정리할 수 있다. 최소한의 2가지는 꼭 지키자.코드 리뷰 시의 필수 내용 두 가지는 다음과 같다.1. 코드 검토는 1시간 이내에 끝낼 분량으로 검토한다.2. 코드는 200라인 이상을 한 번에 검토하지 마라이 기준이 어겨지면, 리뷰어는 제대로 된 리뷰를 하기 어려울 것이다.  그리고, 이러한 리뷰를 하는 동안 기능에 대한 검토 체크사항에 대해서 나열해 보면 다음과 같이 나열이 될 수 있을 것이다.1. 시스템의 요구사항이 제대로 반영되었는가?2. 시스템의 설계의 규격대로 구현되었는가?3. 과도한 코딩을 하고 있지 않는가?4. 같은 기능 구현을 더 단순하게 할 수 있는가?5. 함수의 입출력 값은 명확한가?6. 빌딩 블록들( 알고리즘, 자료구조, 데이터 타입, 템플릿, 라이브러리, API )등이 적절하게 사용되었는가?7. 좋은 패턴과 추상화( 상태도, 모듈화 )등을 사용해서 구현하고 있는가?8. 의존도가 높은 함수나 라이브러리 등의 의존관계에 대해서 별도 기술하고 있는가?9. 함수의 반환(exit)은 한 곳에서 이루어지고 있는가?10. 모든 변수는 사용 전에 초기화하고 있는가?11. 사용하지 않는 변수가 있는가?12. 하나의 함수는 하나의 기능만 수행하고 있는가?또한, 스타일과 코딩 가이드에 대해서고 검토하고 리딩을 해야 한다.1. 코딩 스타일 가이드를 준수하고 있는가?2. 각 파일의 헤더 정보가 존재하는가?3. 각 함수의 정보를 코드에 대해서 설명하기에 충분한가?4. 주석은 적절하게 기술되어있는가?5. 코드는 잘  구조화되어있는가? ( 가독성, 기능적 측면 )6. 헤더, 함수 정보를 도구로 추출해서 자동으로 문서화할 수 있는 구조인가?7. 변수와 함수의 이름이 일관되게 기술되어 있는가?8. 프로젝트의 가이드를 통한 네이밍 규칙을 준수하고 있는가?9. 숫자의 경우 단위에 대해서 기술하고 있는가?10. 숫자를 직접 서술하지 않고, 상수를 사용하고 있는가?11. 어셈블리 코드를 사용하였다면 이를 대체할 방법은 없는가?12. 수행되지 않는 코드는 없는가?13. 주석 처리된 코드는 삭제가 되었는가? ( 버전 체크가 되었는가? )14. 간결하지만 너무 특이한 코드가 존재하는가?15. 설명을 보거나 작성자에게 물어봐야만 이해가 가능한 코드가 있는가?16. 구현 예정인 기능이 있다면, ToDo주석으로 표시되어 있는가?가장 중요한 아키텍처에 대한 검토를 잊으면  안 된다.1. 함수의 길이는 적당한가? ( 화면을 넘기면  안 된다. )2. 이 코드는 재사용이 가능한가?3. 전역 변수는 최소로 사용하였는가?4. 변수의 범위는 적절하게 선언되었는가?5. 클래스와 함수가 관련된 기능끼리 그룹화가 되었는가? ( 응집도는 어떤가? )6. 관련된 함수들이 흩어져 있지 않는가?7. 중복된 함수나 클래스가 있지 않는가?8. 코드가 이식성을 고려하여 작성되었는가? ( 프로세스의 특성을 받는 변수 타입이 고려되어있는가? )9. 데이터에 맞게 타입이 구체적으로 선언되었는가?10. If/else구분이 2단계 이상 중접되었다면 이를 함수로 더 구분하라11. Switch/case문이 중첩되었다면 이를 더 구분하라12. 리소스에 lock이 있다면, unlock은 반드시 이루어지는가?13. 힙 메모리 할당과 해제는 항상 짝을 이루는가?14. 스택 변수를 반환하고 있는가?15. 외부/공개 라이브러리 사용하였을 경우에 MIT 라이선스를 확인했는가? GPL의 경우에는 관련된 영역에서만 사용해야 한다.16. 블로킹 api호출시에 비동기적인 방식으로 처리하고 있는가?당연하겠지만, 예외처리 관련 체크리스트도 제대로 검토해야 한다.1. 입력 파라미터의 유효 범위는 체크하고 있는가?2. 에러코드와 예외(exception)의 호출 함수는 분명하게 반환되고 있는가?3. 호출 함수가 어려와 예외처리 코드를 가지고 있는가?4. Null포인트와 음수가 처리되는 구조인가?5. 에러코드에 대해서 명쾌하게 선언하고 처리하고 있는가?6. switch문에 default가 존재하고, 예외처리를 하고 있는가?7. 배열 사용시에 index범위를 체크하는가?8. 포인트 사용시에 유요한 범위를 체크하는가?9. Garbage collection을 제대로 하고 있는가?10. 수학계 산시에 overflow, underflow가 발생할 가능성이 있는가?11. 에러 조건이 체크되고 에러 발생 시 로깅 정보를 남기는가?12. 에러 메시지와 에러코드가 에러의 의미를 잘  전달하는가?13. Try/catch 에러 핸들링 사용방법은 적절하게 구현되었는가?요즘 프로그램은 대부분 이벤트성으로 구동되지만, 시간의 흐름에 대한 체크는 프로그램의 뼈대를 이루게 된다. 이 부분에 대해서도 제대로 검토해야 한다.1. 최악의 조건에 대해서 고려하였는가?2. 무한루프와 재귀 함수는 특이사항이 아니라면 없어야 한다.3. 재귀 함수 사용시에 call stack값의 최댓값이 고정되어 있는가?4. 경쟁조건이 존재하는가?5. 스레드는 정상 생성, 정상 동작하는 코드를 가지고 있는가?6. 불필요한 최적화를 통해서 코드 가독성을 희생하였는가?7. 임베디드의 경우에도 최적화가 매우 중요하지 않다면, 가독성을 더 중요하게 해야 한다가장 중요한 검증과 시험에 대해서도 제대로 인지하여야 한다. 그리고, 테스트를 위해서 가능한 최대한 자동화를 하기 위한 방법들을 이용해야 한다.1. 코드는 시험하기 쉽게 작성되었는가?2. 단위 테스트가 쉽게 될 수 있는가?3. 에러 핸들링 코드도 잘  테스트되었는가?4. 컴파일, 링크 체크 시에 경고 메시지도 100% 처리하였는가?5. 경계값, 음수값, 0/1등의 가독성이 떨어지는 코드에 대해서 충분하게 경계하고 있는가?6. 테스트를 위한 fault 조건 재현을 쉽게 할 수 있는가?7. 모든 인터페이스와 모든 예외 조건에 대해서 테스트 코드가 있는가?8. 최악의 조건에서도 리소스 사용은 문제가 없는가?9. 런타임 시의 오류와 로그에 대비한 시스템이 있는가?10. 테스트를 위한 주석 코드가 존재하는가?간혹 등장하는 하드웨어에 대한 테스트도  마찬가지이다. 다음과 같은 기준들을 통해서 검토해야 한다.1. I/O 오퍼레이션 코드에 대한 테스트로 하드웨어가 정상적인 동작을 보장하는가?2. 최소/최대 타이밍 요구사항에 대해서도 하드웨어 인터페이스가 충족하는가?3. 멀티 바이트 하드웨어 레지스터가 read/write오퍼레이션 중에도 값이 바뀌지 않음을 보장하는가?4. 시스템이 잘 정의된 하드웨어 상태로 리셋하는 것을 S/W가 보장하는가?5. 하드웨어의 전압이 떨어지거나 전원이 차단되는 경우에 잘 처리하는가?6. 대기모드 진입 시와 빠져나 올 때에 시스템이 옳게 동작하는가?7. 사용하지 않는 인터럽트 벡터가 에러 핸들러에 연결되어 있는가?8. EEPROM손상(데이터 깨짐)을 막기 위한 메커니즘이 있는가? ( 쓰기 동작 중 powe loss)등구체적으로 코드리뷰를 하고자 한다면, 다음의 코드리뷰에 대한 기법과 적당한 방법을 다음과 같이 설명할 수 있다.이러한 코드 리뷰를 위한 몇 가지 방법들이 알려져 있다. 그것들을 몇 가지 정리하여 보면 다음과 같다. 코드 인스펙션은 가장 정형화된 기법으로 전문화된 코드리뷰팀을 통해서 구분하는 방법이다. 이 방법은 리소스가 풍부하고, 일정에 여유가 있는 경우에만 사용이 가능하다. 대부분 대기업이나 대형 포털에서 구현 가능한 방법이라고 할 수 있다. ( 이런 곳에 있다면 행복해 하자. ~.~ ) 하여간, 비용과 일정 등이 있다면 이 방법이 현명하다. 그리고, 코드리뷰에 대한 품질에 대해서 정량적인 보고와 구성을 만들어 낼 수 있다는 것은 코드 인스팩션의 가장 좋은 장점이다. 이 코드 인스팩션을 하기 위한 롤을 구분하면 다음과 같이 4가지 롤로 구분할 수 있다.1. ModeratorA. 실질적인 매니저로 팀 간의 인터페이스와 리소스, 인프라를 확보하고, 프로세스에 대한 정의와 산출물의 정리를 담당한다.2. ReaderA. 각 산출물을 읽고, 리뷰하고, 방향성을 제시한다. 보통, 지식이 많은 사람이 담당한다.3. Designer/CoderA. Reader의 지시에 따라서 코드를 검증하고 잠재적인 발견 등의 수정 방안을 만든다.4. TesterA. 진행 중인 코드와 권장 수정 코드에 대해서 검증한다.그리고, 코드 인스펙션은 다음과 같은 6단계로 진행된다.1. PlanningA. 계획 수립2. OverviewA. 교육과 역할 정의3. PreparationA. 인터뷰와 필요한 문서 습득, 툴 환경 구축4. Meeting(Inspection)A. 각자의 역할대로 수행5. ReworkA. 보고된 Defect 수정6. Follow-upA. 보고된 Defect가 수정되었는지 확인이러한 절차를 통해서, 코드 인스팩션이 수행되면, 상당히 명쾌한 리뷰가 진행되게 된다. 하지만, 일정과 비용 문제 때문에 이 작업은 대부분의 스타트업에서는 선택하기 어렵다. 그래서 사용하는 방법 중의 하나가 팀 리뷰이다.팀 리뷰는 일정한 계획과 프로세스만 따르는 방법으로, 코드 인스펙션보다는 좀 덜 정형화된 방법으로 진행한다. 보통은 일주일에 한번 정도 팀 리뷰를 수행하거나, 특정 모듈이나 기능이 완료되는 시점을 기준으로 테스트 결과를 가지고 리뷰를 하는 방법을 사용한다.또한, 위험하거나 의견이 필요한 경우에도 팀 리뷰는 유용하다. 일반적인 팀에서 사용하는 방법이다.하지만, 이 역시. ‘리뷰’에 대한 제대로 된 인식이 없다면, 적용하기 어렵다. 그래서, 가끔 사용되는 방법이고, 과거 국내 SI업체들이 주로 사용하던 방법 중의 하나가 ‘웍쓰로’이다.웍 쓰루(Walkthrough)는 단체로 하는 코드 리뷰 기법 중에 비정형적인 방법으로, 발표자가 리뷰의 주제나 시간을 정해서 발표하고 동료들로부터 의견이나 아이디어를 듣는 시간을 가지는 방법으로써 주로 사례에 대한 정보 공유나 아이디어 수집을 위해서 사용하는 방법이다.이 방법은 ‘특정 도메인’에 종속된 코드를 만들거나, 비슷한 SI성 형태의 업무를 수행하는 경우에 적합하다. 그래서, 국내의 SI업체에서는 적극적으로 사용되면 좋겠지만. 이 ‘시간’마저도 부정확하고, 갑을병정의 SI체게에서 ‘정보공유’나 ‘아이디어 수집’과 같은 커뮤니케이션이 자유롭게 일어나는 것은 매우 힘들다.이 웍 쓰루는 동일한 조직 내에서 동일한 목적의식이 분명한 팀에서나 활용이 가능한 방법이다. 웍 쓰루를 SI에서 시도한 경우에는 대부분 실패했거나, 목적의식이 다르기 때문에 불분명한 결론들이 대부분 도출되었다.대부분의 국내 스타트업이나 IT 전문기업들은 ‘리뷰’에 대해서 상급 관리자들이 제대로 허락을 해주지 않는다.대부분은 팀내에서 어떻게든 자체적으로 해보려고 한다. 그래서, 팀장의 권한 선에서 적절하게 리뷰를 하는 방법 중의 하나가 Peer review or over the shoulder review방법이다. 이 방법은 보통 2~3명이 진행하는 코드리 뷰로 코드의 작성자가 모니터를 보면서 코드를 설명하고, 다른 한 사람이 설명을 들으면서 아이디어를 제안하거나 Defect를 발견하는 방법이다.또한, 이 방법은 신입사원이나 인턴사원의 경우에 업무 이해도를 높이면서 해당 코드를 사용할 수 있는 수준으로 활용할 경우에 의미 있는 방법이다. 문제는 이 방법은 개발자의 인력 투입이 거의 두배 이상으로 증가하는 것으로써, 고품질의 영역을 개발하거나, 빠른 시간 안에 신입 개발자의 업무 이해도를 높이는 경우가 아니라면 시행하지 않는다.이렇게도 리뷰가 진행이 되지 않으면, Passaroud는 돌려 보기 방법을 사용한다. 이 방법은 원래 상세한 리뷰 방법은 아니다. 온라인이나 실시간성이 아니라, 리파지토리나 이메일 등을 사용하여 천천히 리뷰하는 방식에 해당하는데, 속도는 느리지만, 중요한 코드이거나, 제품의 기능 개선이 필요한 경우에는 아주 의미가 있다. 보통은 제품의 기능 개선을 위하여 사용하는 방법이다.이처럼 리뷰의 방법에는 다양한 방법이 있지만, 결론적으로는 어느 정도 개발 조직이 서로  커뮤니케이션하고, 목적의식을 통일하고, 적절한 시간 분배를 통해서 리뷰를 할 수 있는 시간을 만들어 내느냐가 리뷰의 핵심이라고 할 수 있다.리뷰를 통해서 소프트웨어의 품질을  끌어올리고, 개발자들과 소통하고, 방향성을 만들어 내며, 새로운 기능 개선 작업을 위해서 리뷰는 다양하게 활용된다. 어떤 관점으로 리뷰를 할 것이고, 어떤 관점으로 리뷰라는 프로세스를 개발 프로세스에 탑재할 것인가에 대해서 진지하게 고민하는 것. 그것이 아키텍트의 첫 번째 역할 아닌가 한다.

지난 토요일 매우 더웠던 어느 여름밤, 관심일정 구독 서비스: 린더가 앱스토어 라이프스타일 16위에 올랐다.물론 출시에 맞추어 마케팅을 진행하다 보면 초기에 순위 상승 효과가 다소 있기 마련이고, 요즘 같은 시대에 앱스토어 순위 좀 올랐다고 그게 그리 큰 대수냐랴고 말하는 사람도 있겠지만서도, 이 앱을 스토어에 올리기까지의 험난했던 과정을 누구보다도 잘 아는 사람으로서 비록 잠깐이지만 한여름밤의 꿈 같았던 이 과정과 결과를 글로 간직하고 싶었다.모든 스타트업, 아니 작은 중소기업이 그렇겠지만 우리는 매우 소수의 인력으로 구성되어있고, 그 소수의 인원 하나하나가 정말 많은 일을 담당하고 있다. 관심일정 구독 서비스: 린더는 다소 독특한 서비스 구조 특성상 사업 초기부터 B2B, B2C 모두를 대상으로 운영이 되고 있으며, 하루하루 예상치 못한 새로운 일들의 연속이 이어진다. 혹자는 이를 도전적이고 진취적인 경험이라 포장할 수도 있겠지만, 당장 어제는 한 번도 해본 적 없는 B2B SEO 작업을 하다가 오늘은 또 ASO 전문가가 되어야 하는 우리 당사자들 입장에서는 이러한 일련의 과정이 매우 가혹할 수밖에 없다.린더를 만들어 가는 과정에서 정말 많이 다퉜다(물론 앞으로도 많이 다투겠지만). 앞서 말한 가혹한 과정 속에서 여유를 가지고 서로가 서로를 대하기는 쉽지 않았기에, 당장 회사가, 서비스가 몇 달 후에도 계속 존재할지 아무도 모르는 상황에서 희망을 품고 모두가 함께 서비스의 미래를 바라보기는 정말 쉽지 않았다. 하지만 그 다툼의 근간에는 제품에 대한 기대와 열망이 있었다는 것을 모두가 알고 있었고, 기능 하나하나 쉽게 양보하지 않았지만 결국 하나의 공통된 목표 하에 조금씩 타협해나갈 수 있었다. 그렇게 우리는 현재 '린더'라는 이름을 달고 세상에 태어난 총 5개의 서비스를 운영하고 있다.'린더웹'으로 불리우는 기본 캘린더 연동 서비스는 작년 6월에 출시되어 현재까지 약 20만 명의 사용자를 확보하였고, 올해 4월, 7월에 각각 출시된 '린더안드로이드앱'과 '린더iOS앱'은 현재까지 총 2만여 다운로드와 1만 MAU를 확보하였다. 이 과정에서 우리와 협업을 희망하는 기업들을 위해 별도의 관리툴을 솔루션 형태로 제작, '린더 파트너스'라는 기업용 일정 마케팅 솔루션을 바탕으로 롯데자이언츠, 두산베어스, 아디다스 코리아 등 20여 개의 기업과 함께 협업하고 있으며, 빠르고 정확한 일정 데이터 생산을 위해 일정 데이터 형태에 최적화된 데이터 관리툴 '린더 CMS'를 개발하여 최소한의 인력과 비용으로 일정 데이터 생산이 가능케 했다.일정 구독 플랫폼: 린더지난 1년간 우리 팀은 사용자들의 구독 니즈를 충족시키기 위해 밤낮으로 다양한 일정들을 찾아 헤맸고, 어느덧 300여 개가 넘는 여러 캘린더를 운영하게 되었다. 그리고 지속적으로 높은 일정 데이터 생산 비용을 감당해야 했었던 이전에 비해 이제는 20만 명이 넘는 사용자들의 빗발치는 일정 제보와 20여 개가 넘는 파트너들의 일정 공급을 바탕으로 보다 효율적인 운영이 가능해졌다. 밤낮으로 일정을 찾아 헤매던 기존의 과정은 체계화된 시스템 덕분에 상당 부문 개선되어 변동성 높은 일정 데이터의 정확도를 지속적으로 향상 시켜나가고 있다.일정 제보 화면이제 우리는 감히 린더를 단순 구독 '서비스'를 넘어 국내 유일의 일정 구독 '플랫폼'이라고 부를 수 있는 자신감이 생겼다. 사용자들은 하루에도 몇 번씩 새로운 일정을 제보하는 동시에 구독을 희망하는 새로운 캘린더를 요청하고, 마찬가지로 '입점'을 희망하는 기업의 니즈 또한 지속적으로 증가하여 지난주에만 스포츠, 학교, 공연 3개의 각기 다른 분야에서 '일정 구독 제공'에 대한 문의가 들어왔다. 이들은 '일정'이라는 공통된 포맷 하에 각자 자신들의 일정을 팬, 학생, 또는 고객들에게 제공하기를 희망하였다.린더와 VUX(음성 기반 사용자 경험)   최근 AI 스피커 시장이 확장됨에 따라 각 회사들은 VUX기반 컨텐츠 확보에 열을 올리고 있다. 카카오가 NUGU를 운영하는 경쟁사 SKT에 멜론뮤직의 음악 컨텐츠를 공급하지 않을 것은 불 보듯 뻔한 사실이고, 결국 SKT는 자체 음악 서비스인 '뮤직메이트'를 새로이 시작했다. 역으로 네이버에게 배달의민족과의 협력 기회를 뺏긴 카카오는 '주문하기' 기능을 확대하여 자체 배달 서비스를 시작했다. '음악 컨텐츠'가 되었건, '배달 컨텐츠'가 되었건, 날씨 알려주는 것 외에 딱히 할 줄 아는 게 없는 현시대의 인공지능들에게 린더의 일정 컨텐츠는 높은 활용 가치가 있을 수 있다.단순히 내 캘린더와 연동되어 내가 어제 입력했던 일정들을 읊어주는 것이 아니라, 내가 좋아할 만한, 필요로 할만한 일정들을 미리 찾아서 알려줄 수 있다면 정말 멋지지 않을까. 캘린더에 표시도 안 한 2학기 수강신청을 10분 전에 내게 먼저 알려줄 수 있는 앱이 있다면, 아침에 일어나자마자 고대하던 신상 구두가 출시되었음을 알려주는 스피커가 있다면 분명 그 사용자 경험은 어디에서도 쉽게 경험할 수 없는 수준일 것이다.린더의 타이밍 타이밍은 중요하다. 비트, 풀러스 등 높은 제품 퀄리티 및 운영 능력에도 불구하고 시대가 받아들일 준비가 되지 않은 서비스들의 말로를 먼발치에서 지켜보았다. 약 1년 전 내부적으로 우리의 타이밍에 대해 논의를 진행했던 적이 있었고, 당시 우리가 내린 결론은 린더의 타이밍이 결코 늦으면 늦었지 빠르지는 않았다는 것이었다. 이미 사람들은 일정을 받아보는 경험을 받아들일 준비가 되어있으며, 1년 간 린더를 통해 일정을 받아보는 경험을 누리고 있는 20만의 사용자가 이를 방증한다.우리가 생각한 그 '타이밍'이 틀리지 않았다면, 꼭 '린더'라는 이름이 아니더라도 '일정을 받아보는 경험'을 만들어가는 것은 반드시 누군가가 성공해야만 하는 일이다. 지도로 길을 찾으며 불편함을 느끼지 못했던 세상에 누군가가 네비게이션을 선사한것처럼, '일정을 받아보는 경험'은 근 미래에 없어서는 안 될 선물이 될 것이다.    일정 구독 플랫폼은 분명 많은 이들의 삶에 변화를 줄 수 있다. 작게 보면 좋아하는 공연의 티켓팅을 놓쳐 매번 공연에 참여하지 못할뻔한 어느 팬의 하루를 행복하게 바꾸어 놓을 수 있고, 크게 보면 복수전공 신청 기간을 깜빡하고 놓쳐 복수 전공을 하지 못할뻔한 어느 대학생의 삶을 송두리째 바꾸어 놓을 수 있다.이 일은 반드시 누군가가 해내야만 한다. 그냥 있어 보이고 싶어서, 스타트업다워 보이고 싶어서 내뱉는 말이 아니라, 진심으로, 사력을 다해 누군가는 반드시 이 일정 구독 플랫폼을 만들어 내야만 한다. '일정을 받아보는 경험'이 일상화 되었을때 비로소 우리의 삶은 조금 더 질적으로 풍요로워질 수 있다.린더가 앱스토어 10위권에 오른 이번 사건이 완전히 새로운 형태의 일정 구독 플랫폼의 시작을 알리는 출발선이 되었으면 한다. 다시 또 높은 순위권으로 올라오기 위해서는 아마 한동안 많은 노력들이 필요로 될 것으로 예상되기에, 우리는 앞으로도 화장품 세일, 아이돌 스케줄, 대학교 학사일정, 스포츠 경기, 마트 휴무일, 공연, 전시 등을 넘어 사람들이 필요로 하는 새로운 일정 컨텐츠를 찾아 헤맬것이다.세상 사람 모두가 일정을 받아보는 날이 오기를 꿈꾸며, 와, 근데 이번 여름밤은 정말 더워도 너무 덥다.#히든트랙 #챗봇 #기술기업 #개발자 #개발팀 #인사이트 #경험공유

안녕하세요. 데이블 백엔드 개발팀 최형주입니다.이번에 말씀드릴 내용은 서버 없는 컴퓨팅(Serverless Computing)의 널리 사용되는 AWS(Amazon Web Service)의 Lambda에 대한 내용입니다. AWS Lambda는 메모리 설정값에 따라 CPU 파워가 결정되는데, 그 메모리 설정값에 따라 CPU 파워가 어떻게 변화하는지에 대한 실험 내용을 설명하겠습니다. 처음에 AWS Lambda가 무엇인지 간략하게 소개를 하고 왜 이번 실험을 하게 되는지 배경 설명을 드릴 것입니다. 그다음 메모리 설정값에 따른 CPU 파워는 어떻게 결정되는지를 규명하고 마지막으로 이번 포스트를 간략히 요약겠습니다.목차1. AWS Lambda란?2. 실험배경3. 메모리 설정값과 CPU 파워의 관계4. 요약AWS Lambda란?AWS Lamba의 웹사이트AWS Lambda는 이벤트에 응답하여 코드를 실행하고 자동으로 기본 컴퓨팅 리소스를 관리하는 서버 없는 컴퓨팅 서비스입니다. 즉 코드를 업로드 하기만 하면 높은 가용성과 확장성을 보장하는 Lambda 플랫폼에서 코드를 실행합니다.AWS Lambda를 사용의 장점은 서버관리 불필요(Serverless), 지속적인 조정(Scaling), 밀리 초 단위의 측정 및 과금(Demand-based Pricing)입니다. 즉 서버를 프로비저닝(Provisioning)하거나 관리할 필요 없이 AWS Lambda에서 코드를 자동으로 실행하기 때문에 코드를 작성하고 AWS Lambda에 업로드하기만 하면 됩니다. 또한, 각 트리거에 대한 응답으로 코드를 실행하여 애플리케이션을 자동으로 확장하거나 축소합니다. 즉 코드는 병렬로 실행되고 각 트리거는 개별적으로 처리되어 정확히 워크로드(Workload) 규모에 맞게 조정됩니다. 과금 방식은 100밀리 초 단위로 코드가 실행되는 시간 및 코드가 트리거 되는 회수를 기준으로 요금이 부과됩니다. 코드가 실행되지 않을 때는 요금이 부과되지 않습니다.실험 배경AWS Lambda의 과금은 요청 요금과 컴퓨팅 요금의 합으로 계산됩니다. 요청 요금은 Lambda 함수를 호출한 총 요청 수에 대해 요금을 부과하고, 컴퓨팅 요금은 사용자가 업로드한 코드를 실행한 시간을 계산하여 100ms당 요금을 부과합니다. 컴퓨팅 요금은 사용자가 설정한 메모리 크기에 선형 비례하여 다르게 부과됩니다. 예를 들어 128MB 메모리에서는 100ms당 0.000000208$이고 256MB는 128MB의 약 두 배인 0.000000417$입니다. 그리고 512MB에서는 256MB의 두 배인 0.000000834$입니다. 또한, 더 큰 메모리를 사용할수록 더 큰 CPU 파워를 제공합니다.가장 큰 메모리 설정값을 사용하면 좋겠지만, 비용적인 측면을 고려해볼 때 사용자 입장에서의 사용 목적은 AWS Lambda로부터 최소한의 요금으로 최대한의 계산 효율을 뽑아내는 것입니다. 이 목적을 달성하기 위해서는 Lambda 함수를 실행할 때 메모리의 크기와 CPU의 파워(코어 수, 연산능력)를 명확하게 규명할 수 있어야 합니다. 메모리 크기는 사용자가 설정할 수 있습니다. 하지만 아쉽게도 아마존에서는 CPU 용량은 설정한 메모리 크기에 비례하여 결정된다고만 설명되어 있고 어느 정도의 성능을 가졌는지 명시하지 않고 있습니다.하지만 데이블의 백엔드 개발팀에서, 실험을 통하여 AWS Lambda에서 메모리 설정값에 따라 CPU 파워가 어떻게 변하는지 규명해냈습니다. 이제 그것을 이 포스팅을 통해 설명해 드리고자합니다.메모리 설정값과 CPU 파워의 관계"설정한 메모리 크기와 CPU 파워는 지수적 감쇠 관계(Exponential Decay)를 보인다"앞서 "CPU 파워는 메모리 설정한 값에 비례하여 증가한다”라고 했습니다. "그러면 어느 정도로 어떻게 비례하는가?”, “당연히 선형관계 아닌가?"라는 질문이 자연스럽게 나올 것입니다. 저희는 이 질문에 대답하기 위해 각 메모리 설정값별로 100만 번의 덧셈연산을 하여 각 설정 별 처리시간을 계산해 보았습니다. 다음 [그림 1]은 100만 번의 덧셈 연산을 했을 때 처리시간을 나타낸 그래프입니다. X축은 할당한 메모리의 크기를 나타내고 Y축은 처리시간을 초 단위로 측정한 것입니다. 보시는 바와 같이 처리시간은 메모리 크기에 따라 지수적으로 감소함을 알 수 있었습니다. 그러므로 AWS Lambda에서는 설정한 메모리 크기와 CPU 파워는 지수적 감쇠 관계(Exponential Decay)를 보인다고 결론을 내릴 수 있습니다. 예를 들면 현재 설정한 메모리보다 2배 높은 CPU 파워를 사용하고 싶으면 2배로 큰 메모리 용량을 설정해야 합니다.[그림 1] 메모리 설정값에 따른 처리시간필요로 하는 메모리 크기와 사용하는 응용에 따라 다르겠지만, 일반적으로 메모리의 크기에 상관없이 사용하는 비용이 거의 같다고 얘기할 수 있습니다. [그림 2]는 앞서 100만 번 덧셈 연산을 1만 번 호출했을 때의 각 메모리 설정값 별 요금을 나타낸 것입니다. X축은 설정한 메모리 크기이고 Y축은 각 메모리 설정값 별 요금입니다. 보시는 바와 같이 분포가 급격히 변하지 않고 대체로 균일한 것을 알 수 있습니다.[그림 2] 메모리 설정값에 따른 요금하지만 프로그램의 실행 시간은 단순히 CPU 파워로만으로 처리 시간이 결정되지 않기 때문에 다양한 요인을 검토해야 합니다. 알고리즘의 시간복잡도, 메모리의 크기와 접근 횟수, 네트워크 비용 등 다양한 것들이 처리 시간에 영향을 미치기 때문에 단순히 메모리 설정값을 늘려서 사용하는 방법은 옳지 못합니다. 그러므로 위 자료를 참고 용도로만 사용하셔서 하고자 하는 목적에 맞게 가장 최적의 메모리 설정값을 설정하시면 됩니다.요약AWS Lambda는 대표적인 서버 없는 컴퓨팅 서비스입니다. AWS Lambda에서 뛰어난 가성비를 얻고자 할 때는 각 설정값에 따라 제공하는 자원을 예측할 수 있어야 합니다. 여러 설정값 중 가장 성능에 큰 영향을 미치는 것은 사용하고자 하는 메모리 크기인데 이 크기에 따라 CPU 파워가 결정됩니다. 하지만 각 메모리 설정값에 따른 CPU 파워 정보를 아마존에서 제공해 주지 않고 있으므로 실험을 통해서 확인하였습니다. 실험 결과 설정한 메모리 크기와 CPU 파워는 지수적 감쇠 관계(Exponential Decay)를 규명했습니다. 이 규명은 단순한 프로그램에서만 확인한 것이기 때문에 최고의 효율을 가지는 AWS Lambda를 사용하기 위해서는 그 밖의 다양한 것들을 고려하여 설정해야 합니다.  기타머신 성능 및 정보- 사용하는 CPU는 Intel(R) Xeon(R) CPU E5-2666 v3 @ 2.90GHz, 코어의 개수는 2개, 그리고 캐시의 크기는 25600 KB 임(사용하는 Microcode는 바뀔 수 있음)- 메모리는 약 3.67GB를 가짐실험에 사용한 Lambda 함수import osimport multiprocessingimport timeimport subprocessdef lambda_handler(event, context):mem_bytes = os.sysconf('SC_PAGE_SIZE') * os.sysconf('SC_PHYS_PAGES')mem_gib = mem_bytes/(1024.**3)num_cores = multiprocessing.cpu_count()#start_time = time.time()print subprocess.check_output ('vmstat -s', shell=True)sum = 0for i in range(1000000):sum += iif sum 000 == 0:print subprocess.check_output ('vmstat -s', shell=True)print subprocess.check_output ('vmstat -s', shell=True)hostname = subprocess.check_output ('hostname', shell=True)cpuinfo = subprocess.check_output ('cat /proc/cpuinfo', shell=True)meminfo = subprocess.check_output('cat /proc/meminfo', shell = True)print hostnameprint '--------------------------------------------------------------\n\n'print 'CPU Information'print cpuinfoprint '--------------------------------------------------------------\n\n'print 'Memory Information'print meminfoprint '\n\n\n\n'참고 자료https://aws.amazon.com/ko/lambda/details/#데이블 #개발 #개발자 #인사이트 #꿀팁 #AWS #조언

Logstash로 로그를 수집한 후 Elasticsearch와 Kibana로 분석하는 방법을 다룬 글은 많다. 그런데 이상하더라 이 말이지. 로그를 분석하고 경향을 파악하는 정도라면야 괜찮은데 심각한 오류 로그를 발견했을 때 Slack이나 이메일 등으로 알람 받을 수단이 마땅치 않더라. 사람이 키바나 대시보드를 5분마다 확인할 수도 없는 노릇이다. (이건 새로운 차원의 고문?)이런 생각을 먼저 한 사람이 있기 마련이라 Yelp의 elastalert라던가 Elasticsearch의 X-Pack을 활용하면 이런 문제를 해소할 수 있다. 오늘은 그 중에서 후자를 살펴볼 예정이다.경고! X-Pack은 Elasticsearch가 유료 서비스 시장을 열려고 야심차게 미는 모양인데 “자기네가 직접 만들었으니 쿨하겠지?”라고 쉽게 생각하면 하루 안에 절벽 아래로 떨어지는 끔찍한 기분을 맞이할 수도 있다.X-Pack은 가격이 상당한데 Alert 등을 설정하려면 전적으로 RESTful API에 의존해야 한다. 적어도 아직까지는! 이 사실을 깨닫자마자 당황할 수 있는데 침착하자. 이것은 시작일 뿐이다. 여러분이 검색엔진의 초보라면 그 다음 난관은 검색 쿼리를 작성하는 것이다. “나는 그냥 OutOfMemoryError 로그를 발견하면 알람을 보내줬으면 좋겠어"라고 쉽게 생각했겠지만 그 간단한 결과를 얻으려면 험난한 여정을 거쳐야 한다."search" : { "request" : { "indices" : [ "", ], "body" : { "query" : { "bool" : { "must" : { "multi_match": { "query": "OutOfMemoryError", "fields": ["message", "log"] } }, "filter" : { "range": { "@timestamp": { "from": "{{ctx.trigger.scheduled_time}}||-5m", "to": "{{ctx.trigger.triggered_time}}" } } } } } } } }음… 좋다. 일단 이렇게 작성한 쿼리가 제대로 된 것인지 테스트하려면 어떻게 해야 하는가? 검색 API로 대충 테스트해볼 수는 있다.GET logstash-2017.02.2*/_search { "query" : { "bool" : { "must" : { "multi_match": { "query": "OutOfMemoryError", "fields": ["message", "log"] } } } } }어찌어찌 잘 나온다. 그래서 잘 돌 줄 알았지? 그럴 줄 알고 있다가 이런 메시지를 만난다.Trying to query 1157 shards, which is over the limit of 1000. This limit exists because querying many shards at the same time can make the job of the coordinating node very CPU and/or memory intensive. It is usually a better idea to have a smaller number of larger shards. Update [action.search.shard_count.limit] to a greater value if you really want to query that many shards at the same time.음… logstash 인덱스를 매시간마다 분할했더니 샤드가 꽤 많아진 모양이다. 그래서 최근 두 개의 인덱스로 검색 대상을 제한하려고 한다. Date math support in index names라는 문서에 인덱스 이름을 동적으로 바꾸는 법이 나와 있긴 하다. 그런데 막상 내가 짠 게 어떤 값이 나오는지 확인하는 방법은 제대로 안 나온다. 예를 들어 가 logstash-2017.02.22t01로 해석되는지 어떻게 아는가? 많은 삽질 끝에 방법을 찾았다.를 URL 인코딩한다.그렇게 얻은 값 을 가지고 인덱스 조회 API를 호출한다. GET /3Clogstash-{now-1h/d}t{now-1h{HH}}>그러면 다음과 같이 결과가 나와서 인덱스 이름이 어떻게 해석됐는지 확인할 수 있다.{ "logstash-2017.02.23t01": { "aliases": {}, "mappings": { /* 중략 */ } }여기까지는 전적으로 검색 쿼리 작성 경험이 부족해서 발생한 삽질이다. 하지만 애플리케이션 로그 분석을 패턴화하지 않고 이렇게 검색 쿼리를 복잡하게 짜야 한다니 아직 갈 길이 멀다는 생각이 든다. DataDog 또는 NewRelic 같은 상용 서비스를 참고해서 개선하면 좋겠다.이제 결과를 알람으로 보내면 된다. 이래저래 고생하다 대충 아래와 같은 형태로 완성했다.PUT _xpack/watcher/watch/outofmemoryerror { "trigger" : { "schedule" : { "cron" : "0 0/4 * * * ?" } }, "input" : { "search" : { "request" : { "indices" : [ "", "" ], "body" : { "query" : { "bool" : { "must" : { "multi_match": { "query": "OutOfMemoryError", "fields": ["message", "log"] } }, "filter" : { "range": { "@timestamp": { "from": "{{ctx.trigger.scheduled_time}}||-5m", "to": "{{ctx.trigger.triggered_time}}" } } } } }, "sort" : [ { "@timestamp" : {"order" : "desc"}}, "_score" ] } } } }, "condition" : { "compare" : { "ctx.payload.hits.total" : { "gt" : 0 }} }, "actions" : { "notify-slack" : { "throttle_period" : "5m", "slack" : { "message" : { "to" : [ "#ops", "@dev" ], "text" : "로그 모니터링 알람", "attachments" : [ { "title" : "OutOfMemoryError", "text" : "지난 5분 동안 해당 오류가 {{ctx.payload.hits.total}}회 발생했습니다. 가장 최근의 오류는 다음과 같습니다.", "color" : "warning" }, { "fields": [ { "title": "환경", "value": "Prod", "short": true }, { "title": "발생시각", "value": "{{ctx.payload.hits.hits.0._source.@timestamp}}", "short": true }, { "title": "메시지", "value": "{{ctx.payload.hits.hits.0._source.message}}", "short": false }, { "title": "확인명령어", "value": "`GET /{{ctx.payload.hits.hits.0._index}}/{{ctx.payload.hits.hits.0._type}}/{{ctx.payload.hits.hits.0._id}}`", "short": false } ], "color" : "warning" } ] } } } } }4분마다 검색 쿼리를 실행해서 최근 5분 간의 레코드를 감시하기 때문에 동일한 오류에 대해 2회 연속으로 알람을 받을 가능성이 있다. X-Pack은 이를 우회할 방법을 제공하지 않는 것 같다. 그래서 쿼리가 발견한 레코드의 인덱스 ID를 Slack 메시지 중 확인명령어 필드에 넣었다. 알람이 두 번 왔지만 인덱스 아이디가 동일하다면 오류가 한번 발생한 것으로 간주하면 된다.참고 문서위의 Alert를 작성하며 도움을 받은 문서는 다음과 같다.Multi Search Template은 검색 쿼리를 짤 때 도움이 됐다.Search Input 문서는 검색 쿼리 또는 검색 결과를 작성할 때 어떤 변수를 사용할 수 있는지 설명한다. 예) {{ctx.payload.hits.hits.0._source.message}}Watcher APIsSlack ActionDate math support in index names 문서는 인덱스 이름을 동적으로 바꾸는 법을 설명한다.기타Elasticsearch Cloud는 기본적으로 이메일 발송을 지원하기 때문에elasticsearch.yml 설정에 xpack.notification.email를 추가하지 않아도 된다. 아니, 추가하면 잘못된 설정이라며 거부한다. Illegal이라고만 하지 이유를 자세히 알려주지 않기 때문에 삽질하기 쉽니다. Invalid addresses라고 오류 로그가 찍히면 이것은 설정 문제가 아니다. 이메일 설정 메뉴로 가서 Watcher Whitelist에 수신 이메일 주소를 등록하면 문제가 해결된다.테스트용 로그 메시지를 Fluentd로 보내고 싶다면 fluent-cat 명령을 이용한다.echo '{"message":"Dummy OutOfMemoryError"}' | fluent-cat kubernetes.logOriginally published at Andromeda Rabbit.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #인사이트

들어가기 전: 실제로 프로젝트와 팀원들과의 작업 환경을 구축한 경험을 바탕으로 작성했습니다. 한마디로 실화. Overview소스를 수정할 때마다 지속적인 테스트를 하기 위해 AWS lambda 로컬 테스트 환경, SAM을 결합해서 환경을 구축했습니다. 이번 글에서는 팀원을 추가하고 CodeCommit을 리포지토리로 사용하는 것도 소개하겠습니다. 예상 구성도테스트 환경 구축, 도저언!1. 팀원 추가하기 IAM 서비스를 이용해서 프로젝트를 같이 사용할 유저를 추가합니다. IAM에 유저를 추가하면 AWS 콘솔을 같이 사용할 수 있습니다. 사용자 추가를 클릭해 유저를 추가합니다. 팀원마다 한 개의 계정을 추가해야 합니다. 사용자 세부 정보 설정 > 엑서스 유형에서 ‘프로그램 방식 엑서스’와 ‘AWS Managrment Console 엑서스’를 체크합니다. 여기에서는 개발2팀 팀원인 강원우 과장의 계정을 생성했습니다.1) 비번은 귀찮으니 미리 세팅해둡시다. 유저 계정은 그룹을 생성해서 관리하면 편합니다. 그룹을 사용하면 보다 편리하게 계정 권한을 제어할 수 있기 때문입니다. 이번 예제에서는 그룹 이름을 codeStarGroup으로 만들었습니다. AWSCodeStarFullAcess를 정책으로 설정하고 ‘그룹생성’을 클릭해 그룹을 추가합니다. 2) codeStarGroup에 체크한 후, ‘다음: 검토’를 클릭해 진행합니다.‘사용자 만들기’를 클릭해 생성을 마무리합니다.계정 추가를 완료했습니다.사용자 이름(위의 예시에서는 kanggw)을 클릭하고, 뒤이어 ‘보안자격 증명’ 탭을 클릭합니다.콘솔 로그인 링크를 공유합시다. 링크를 입력하고 들어가면 그룹 로그인이 활성화가 되어있다는 걸 볼 수 있습니다.2. CodeStar 설정하기 프로젝트 인원을 무사히 추가했습니다. 이제 프로젝트를 만들어 봅시다. CodeStar 프로젝트 세팅 방법은 R&D본부 윤석호 이사님이 쓴 ‘애플리케이션 개발부터 배포까지, AWS CodeStar’를 참고해주세요.새 프로젝트를 생성합니다.python AWS Lambda를 선택합니다.프로젝트 이름은 ‘admin-lambda-API’로 입력하겠습니다. 그 후에 ‘다음’을 클릭합니다.‘프로젝트 생성’을 클릭합니다.우리는 Git을 이용해 로컬에서 직접 관리할 것이므로 ‘명령행 도구’를 선택한 후, ‘건너뛰기’를 클릭합니다.3분 만에 프로젝트가 생성되었습니다. 참 쉽죠?3. 프로젝트에 팀원 추가하기프로젝트를 같이 하려면 팀원을 추가해야겠죠. 팀원 추가는 codeStar 대시보드 좌측의 ‘팀’ 탭을 클릭하면 됩니다.‘팀원 추가’ 클릭IAM에서 등록한 팀원의 정보를 불러옵니다. ‘추가’를 클릭해 팀원을 추가합니다. 여기에서 중요한 사실 하나! 프로젝트의 소유자로 지정해야 소스 접근 및 코드 변경이 가능합니다.4. 코드 체크 아웃앞서 설명한 것처럼 직접 Git으로 소스를 받아야 하기 때문에 codeCommit으로 이동합니다. codeStar 대시보드 왼쪽 ‘코드’ 탭을 클릭하면 코드 내역들을 확인할 수 있습니다.‘URL 복제 > HTTPS’를 클릭해 경로를 복사합니다. 소스를 클론하기 전에 계정에 깃허용을 먼저 해주세요. IAM 돌아와서는 계정 설정을 변경해야 합니다.사용자 > kangww > 보안 자격 증명 탭 클릭 > HTTPS Git 자격 증명 > 생성Git에서 사용할 ID와 비밀번호를 받았습니다. 해당 정보를 팀원에게 전달합니다. 이제 workspace로 이동해 체크아웃을 시작합니다.git clone [복사한 경로] [id 입력] [pw 입력] clone이 완료 되었습니다. 이제 기본 프로젝트가 들어있기 때문에 바로 실행할 수 있습니다. 미리 설치된 SAM으로 실행해보겠습니다.이제 해당 경로에 이동해 SAM을 돌려서 정상적으로 구동되는지 확인해봅시다. (SAM설치 방식은 부록에서 소개합니다.) sam local start-api -p 3333 성공적으로 SAM이 구동되었습니다. (짝짝) http://localhost:3333 으로 접근해 결과를 확인할 수 있습니다. 이제 로컬에서 작업을 진행하면서 바로 바로 확인이 가능해졌습니다. 만약 동료와 함께 개발한다면 아래처럼 구동해야 자신의 IP에 접근할 수 있습니다.sam local start-api -p 3333 -host [자신의아이피] 글을 마치며CodeStar의 관리와 배포 기능은 강력합니다. 많은 부분을 알아서 해주니 고마울 뿐입니다.3) 이제 Lambda의 local 테스트 환경인 SAM을 이용해서 배포 전 과정까지 간편하게 테스트를 해보세요. 배포의 복잡함을 codeStar에서 해결하고 테스트를 하거나 개발을 할 때는 SAM을 이용해 효율적으로 업무를 진행합시다.글 쓰면서 발견한 다섯 가지1) codeDeploy > executeChangeSet 에 구동될 때 cloundFormation 이 자동 세팅 됩니다. 엄청 편합니다. API 배포가 진행되면 lambda에서 바로 수정하는 게 편합니다.2) codeCommit은 https 보다 ssh방식을 권장하며, https방식으로 하다가 꼬이면 여기를 클릭해 해결하세요.3) codeStar는 다음과 같은 추가 구성을 자동 세팅합니다.codeStar 용 S3 버킷codePipeLine용 S3 버킷cloundFormation 세팅lambda 세팅4) IDE를 cloud9을 사용하면 EC2 및 EBS가 생성되니 주의하세요. 그리고 생각보다 느립니다.5) 로컬에서 Git push를 하면 약 5분 정도 뒤에 최종적으로 배포됩니다.부록1)SAM을 설치하기 전, 여기를 클릭해 docker를 미리 설치하세요.2)SAM 설치 안내는 여기를 클릭하세요. ( npm install -g aws-sam-local )참고1)강원우 과장은 귀여운 두 달팽이, 이토와 준지의 주인이기도 하다. 2)AWSCodeStarFullAcess는 codestar 접근에 대한 권한을 부여한다.3)자동 배포까지 2~5분 정도 걸리는 게 어렵게 느껴질 수 있다.글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

OverviewDB를 다뤄봤다면 SELECT문도 아실 겁니다. 가장 먼저 접하는 명령어 중에 하나이기도 하죠. 보통은 아래처럼 사용합니다. SELECT문SELECT     * FROM 테이블명  ; 명령을 주면 지정한 테이블에 저장된 모든 내용을 검색합니다. 이번 글에서는 테이블을 만들고 SELECT하는 과정을 다뤄보겠습니다. DB는 MySQL 5.6을 기준으로 하고, Tool은 MySQLWorkbench를 사용하겠습니다.Query, 너란 녀석테이블은 위와 같이 생성할 수 있습니다. 위의 내용은 MySQLWorkbench를 이용해 Model을 표시하면 아래와 같습니다. 구성원의 정보를 저장하도록 했고, 컬럼마다 의미를 갖게 됩니다. MBR_ID (구성원 아이디) : DB에서 구성원을 식별하는 아이디MBR_INDFY_NO (구성원 식별 번호) : 구성원을 실제 구별하는 번호로 과거에는 주민등록번호가 많이 사용되었고, 요즘은 e-mail 이 많이 사용됩니다.MBR_NM (구성원 명) : 구성원의 이름 테스트 데이터를 입력해 실행하면 어떤 결과가 나오는지 보겠습니다.가장 기본적인 SELECT문 실행계획을 보면 아래와 같이 나옵니다.실행 계획은 DB가 어떻게 Query를 수행할 건지 보여줍니다. Query가 복잡해지면 실행 계획을 보면서 Query가 올바르게 작성됐는지 확인하고 필요하다면 Query를 수정해야 합니다. DB를 시작할 때부터 실행 계획을 보는 습관을 기르는 게 중요한 이유입니다. 각 항목에 대한 설명id : SELECT 문에 있는 순차 식별자로 Query 를 구분하는 아이디select_type : SELECT의 유형SIMPLE : Subquery나 union 이 없는 단순한 SELECTtable : 참조되는 테이블의 명칭TB_MBR_BAS : 참조되는 테이블명type : 검색하는 방식ALL : TABLE의 모든 ROW를 스캔 위의 이미지는 임의로 만든 자료를 이용해 Query를 실행한 결과입니다. 실행 계획은 TABLE : TB_MBR_BAS 를 TYPE : ALL 전체 검색한다고 나옵니다. 실행한 내용도 같습니다. 여기서 MBR_NM 이 “나서영”인 자료를 검색해볼까요. WHERE 조건이 들어가자 실행 계획도 내용이 변경되었습니다. rows와 Extra에도 값이 있는데요. 두 항목을 잠시 짚고 넘어가겠습니다. rows : Query를 수행하기 위해 접근해야 하는 열의 수Extra : MySQL 이 Query 를 수행할때의 추가 정보Using where : Query 수행시 TABLE에서 값을 가져와 조건을 필터링 함 위의 결과처럼 전체를 검색해 필요한 자료만 추출하는 것을 FULL TABLE SCAN or FULL SCAN 이라고 합니다. 그러나 FULL SCAN은 성능이 좋지 않기 때문에 우선 꼭 필요한 Query인지 검토해야 합니다. 보통 MBR_NM에 INDEX를 추가해서 해결하는데요. INDEX를 추가해서 같은 Query를 수행하면 실행 계획은 어떻게 달라질까요. 분명 같은 Query였는데 INDEX에 따라 실행 계획이 변경된 걸 알 수 있습니다. INDEX를 추가해도 수행한 결과는 같지만 검색 속도에 많은 차이가 있습니다. 각 항목에 대한 설명type - ref : 인덱스로 자료를 검색하는 것으로 현재는 매칭(=) 자료 검색을 나타냄possible_keys : 현재 조건에 사용가능한 INDEX를 나타냄(인덱스가 N개일 수 있음) IX_MBR_BAS_02 : 현재 조건에 사용 가능한 INDEXkey : Query 수행시 사용될 INDEX (possible_keys 가 N 개일 경우 USE INDEX, FORCE INDEX, IGNORE INDEX 로 원하는 INDEX 로 바꾸어 수행할수 있음)key_len : 수행되는 INDEX 컬럼의 최대 BYTE 수를 나타냄152 : 수행되는 INDEX 컬럼의 BYTE 수가 152ref : INDEX 컬럼과 비교되는 상수 여부 or JOIN 시 선행 컬럼 constant : 상수 조건으로 INDEX 수행rows : 678 : 678 rows 접근하여 값을 찾음Extra : using index condition : INDEX 조건에 대하여 스토리지 엔진이 처리(MySQL의 구성에서 스토리지 엔진과 MySQL 엔진이 통신을 주고 받는데 스토리지 엔진에서 처리 하여 속도가 향상됨) ConclusionINDEX가 없으면 결과가 나오기까지 5초 정도 걸리지만, 반대로 INDEX가 있으면 1초 안에 결과가 나옵니다. 별거 아닌 것 같아 보이지만 실무에서는 엄청난 차이입니다. Query를 작성할 때 실행 계획을 확인하고 조금이라도 빨리 결과가 나올 수 있도록 하는 것이 중요하기 때문이죠. 다음 글에서는 단일 TABLE 을 SELECT하는 것을 주제로 이야기를 나눠보겠습니다. 무사히 SELECT하길 바라며.글한석종 부장 | R&D 데이터팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

비트윈 팀은 비트윈 안드로이드 클라이언트(이하 안드로이드 클라이언트)를 가볍고 반응성 좋은 애플리케이션으로 만들기 위해 노력하고 있습니다. 이 글에서는 간결하고 유지보수하기 쉬운 코드를 작성하기 위해 Reflection을 사용했었고 그로 인해 성능 이슈가 발생했던 것을 소개합니다. 또한 그 과정에서 발생한 Reflection 성능저하를 해결하기 위해 시도했던 여러 방법을 공유하도록 하겠습니다.다양한 형태의 데이터¶Java를 이용해 서비스를 개발하는 경우 POJO로 서비스에 필요한 다양한 모델 클래스들을 만들어 사용하곤 합니다. 안드로이드 클라이언트 역시 모델을 클래스 정의해 사용하고 있습니다. 하지만 서비스 내에서 데이터는 정의된 클래스 이외에도 다양한 형태로 존재합니다. 안드로이드 클라이언트에서 하나의 데이터는 아래와 같은 형태로 존재합니다.JSON: 비트윈 서비스에서 HTTP API는 JSON 형태로 요청과 응답을 주고 받고 있습니다.Thrift: TCP를 이용한 채팅 API는 Thrift를 이용하여 프로토콜을 정의해 서버와 통신을 합니다.ContentValues: 안드로이드에서는 Database 에 데이터를 저장할 때, 해당 정보는 ContentValues 형태로 변환돼야 합니다.Cursor: Database에 저장된 정보는 Cursor 형태로 접근가능 합니다.POJO: 변수와 Getter/Setter로 구성된 클래스 입니다. 비지니스 로직에서 사용됩니다.코드 전반에서 다양한 형태의 데이터가 주는 혼란을 줄이기 위해 항상 POJO로 변환한 뒤 코드를 작성하기로 했습니다.다양한 데이터를 어떻게 상호 변환할 것 인가?¶JSON 같은 경우는 Parsing 후 Object로 변환해 주는 라이브러리(Gson, Jackson JSON)가 존재하지만 다른 형태(Thrift, Cursor..)들은 만족스러운 라이브러리가 존재하지 않았습니다. 그렇다고 모든 형태에 대해 변환하는 코드를 직접 작성하면 필요한 경우 아래와 같은 코드를 매번 작성해줘야 합니다. 이와 같이 작성하는 경우 Cursor에서 원하는 데이터를 일일이 가져와야 합니다.@Overridepublic void bindView(View view, Context context, Cursor cursor) { final ViewHolder holder = getViewHolder(view); final String author = cursor.getString("author"); final String content = cursor.getString("content"); final Long timeMills = cursor.getLong("time"); final ReadStatus readStatus = ReadStatus.fromValue(cursor.getString("readStatus")); final CAttachment attachment = JSONUtils.parseAttachment(cursor.getLong("createdTime")); holder.authorTextView.setText(author); holder.contentTextView.setText(content); holder.readStatusView.setReadStatus(readStatus); ...}하지만 각 형태의 필드명(Key)이 서로 같도록 맞춰주면 각각의 Getter와 Setter를 호출해 형태를 변환해주는 Utility Class를 제작할 수 있습니다.@Overridepublic void bindView(View view, Context context, Cursor cursor) { final ViewHolder holder = getViewHolder(view); Message message = ReflectionUtils.fromCursor(cursor, Message.class); holder.authorTextView.setText(message.getAuthor()); holder.contentTextView.setText(message.getContent()); holder.readStatusView.setReadStatus(message.getReadStatus()); ...}이런 식으로 코드를 작성하면 이해하기 쉽고, 모델이 변경되는 경우에도 유지보수가 비교적 편하다는 장점이 있습니다. 따라서 필요한 데이터를 POJO로 작성하고 다양한 형태의 데이터를 POJO로 변환하기로 했습니다. 서버로부터 받은 JSON 혹은 Thrift객체는 자동으로 POJO로 변환되고 POJO는 다시 ContentValues 형태로 DB에 저장됩니다. DB에 있는 데이터를 화면에 보여줄때는 Cursor로부터 데이터를 가져와서 POJO로 변환 후 적절한 가공을 하여 View에 보여주게 됩니다.POJO 형태로 여러 데이터 변환필요Reflection 사용과 성능저하¶처음에는 Reflection을 이용해 여러 데이터를 POJO로 만들거나 POJO를 다른 형태로 변환하도록 구현했습니다. 대상 Class의 newInstance/getMethod/invoke 함수를 이용해 객체 인스턴스를 생성하고 Getter/Setter를 호출하여 값을 세팅하거나 가져오도록 했습니다. 앞서 설명한 ReflectionUtils.fromCursor(cursor, Message.class)를 예를 들면 아래와 같습니다.public T fromCursor(Cursor cursor, Class clazz) { T instance = (T) clazz.newInstance(); for (int i=0; i final String columnName = cursor.getColumnName(i); final Class<?> type = clazz.getField(columnName).getType(); final Object value = getValueFromCursor(cursor, type); final Class<?>[] parameterType = { type }; final Object[] parameter = { value }; Method m = clazz.getMethod(toSetterName(columnName), parameterType); m.invoke(instance, value); } return instance;}Reflection을 이용하면 동적으로 Class의 정보(필드, 메서드)를 조회하고 호출할 수 있기 때문에 코드를 손쉽게 작성할 수 있습니다. 하지만 Reflection은 튜토리얼 문서에서 설명된 것처럼 성능저하 문제가 있습니다. 한두 번의 Relfection 호출로 인한 성능저하는 무시할 수 있다고 해도, 필드가 많거나 필드로 Collection을 가진 클래스의 경우에는 수십 번이 넘는 Reflection이 호출될 수 있습니다. 실제로 이 때문에 안드로이드 클라이언트에서 종종 반응성이 떨어지는 경우가 발생했습니다. 특히 CursorAdapter에서 Cursor를 POJO로 변환하는 코드 때문에 ListView에서의 스크롤이 버벅이기도 했습니다.Bytecode 생성¶Reflection 성능저하를 해결하려고 처음으로 선택한 방식은 Bytecode 생성입니다. Google Guice 등의 다양한 자바 프로젝트에서도 Bytecode를 생성하는 방식으로 성능 문제를 해결합니다. 다만 안드로이드의 Dalvik VM의 경우 일반적인 JVM의 Bytecode와는 스펙이 다릅니다. 이 때문에 기존의 자바 프로젝트에서 Bytecode 생성에 사용되는 CGLib 같은 라이브러리 대신 Dexmaker를 이용하여야 했습니다.CGLib¶CGLib는 Bytecode를 직접 생성하는 대신 FastClass, FastMethod 등 펀리한 클래스를 이용할 수 있습니다. FastClass나 FastMethod를 이용하면 내부적으로 알맞게 Bytecode를 만들거나 이미 생성된 Bytecode를 이용해 비교적 빠른 속도로 객체를 만들거나 함수를 호출 할 수 있습니다.public T create() { return (T) fastClazz.newInstance();} public Object get(Object target) { result = fastMethod.invoke(target, (Object[]) null);} public void set(Object target, Object value) { Object[] params = { value }; fastMethod.invoke(target, params);}Dexmaker¶하지만 Dexmaker는 Bytecode 생성 자체에 초점이 맞춰진 라이브러리라서 FastClass나 FastMethod 같은 편리한 클래스가 존재하지 않습니다. 결국, 다음과 같이 Bytecode 생성하는 코드를 직접 한땀 한땀 작성해야 합니다.public DexMethod generateClasses(Class<?> clazz, String clazzName){ dexMaker.declare(declaringType, ..., Modifier.PUBLIC, TypeId.OBJECT, ...); TypeId<?> targetClassTypeId = TypeId.get(clazz); MethodId invokeId = declaringType.getMethod(TypeId.OBJECT, "invoke", TypeId.OBJECT, TypeId.OBJECT); Code code = dexMaker.declare(invokeId, Modifier.PUBLIC); if (isGetter == true) { Local<Object> insertedInstance = code.getParameter(0, TypeId.OBJECT); Local instance = code.newLocal(targetClassTypeId); Local returnValue = code.newLocal(TypeId.get(method.getReturnType())); Local value = code.newLocal(TypeId.OBJECT); code.cast(instance, insertedInstance); MethodId executeId = ... code.invokeVirtual(executeId, returnValue, instance); code.cast(value, returnValue); code.returnValue(value); } else { ... } // constructor Code constructor = dexMaker.declare(declaringType.getConstructor(), Modifier.PUBLIC); Local<?> thisRef = constructor.getThis(declaringType); constructor.invokeDirect(TypeId.OBJECT.getConstructor(), null, thisRef); constructor.returnVoid();}Dexmaker를 이용한 방식을 구현하여 동작까지 확인했으나, 다음과 같은 이유로 실제 적용은 하지 못했습니다.Bytecode를 메모리에 저장하는 경우, 프로세스가 종료된 이후 실행 시 Bytecode를 다시 생성해 애플리케이션의 처음 실행성능이 떨어진다.Bytecode를 스토리지에 저장하는 경우, 원본 클래스가 변경됐는지를 매번 검사하거나 업데이트마다 해당 스토리지를 지워야 한다.더 좋은 방법이 생각났다.Annotation Processor¶최종적으로 저희가 선택한 방식은 컴파일 시점에 형태변환 코드를 자동으로 생성하는 것입니다. Reflection으로 접근하지 않아 속도도 빠르고, Java코드가 미리 작성돼 관리하기도 편하기 때문입니다. POJO 클래스에 알맞은 Annotation을 달아두고, APT를 이용해 Annotation이 달린 모델 클래스에 대해 형태변환 코드를 자동으로 생성했습니다.형태 변환이 필요한 클래스에 Annotation(@GenerateAccessor)을 표시합니다.@GenerateAccessorpublic class Message { private Integer id; private String content; public Integer getId() { return id; } ...}javac에서 APT 사용 옵션과 Processor를 지정합니다. 그러면 Annotation이 표시된 클래스에 대해 Processor의 작업이 수행됩니다. Processor에서 코드를 생성할 때에는 StringBuilder 등으로 실제 코드를 일일이 작성하는 것이 아니라 Velocity라는 template 라이브러리를 이용합니다. Processor는 아래와 같은 소스코드를 생성합니다.public class Message$$Accessor implements Accessor { public kr.co.vcnc.binding.performance.Message create() { return new kr.co.vcnc.binding.performance.Message(); } public Object get(Object target, String fieldName) throws IllegalArgumentException { kr.co.vcnc.binding.performance.Message source = (kr.co.vcnc.binding.performance.Message) target; switch(fieldName.hashCode()) { case 3355: { return source.getId(); } case -1724546052: { return source.getContent(); } ... default: throw new IllegalArgumentException(...); } } public void set(Object target, String fieldName, Object value) throws IllegalArgumentException { kr.co.vcnc.binding.performance.Message source = (kr.co.vcnc.binding.performance.Message) target; switch(fieldName.hashCode()) { case 3355: { source.setId( (java.lang.Integer) value); return; } case -1724546052: { source.setContent( (java.lang.String) value); return; } ... default: throw new IllegalArgumentException(...); } }}여기서 저희가 정의한 Accessor는 객체를 만들거나 특정 필드의 값을 가져오거나 세팅하는 인터페이스로, 객체의 형태를 변환할 때 이용됩니다. get,set 메서드는 필드 이름의 hashCode 값을 이용해 해당하는 getter,setter를 호출합니다. hashCode를 이용해 switch-case문을 사용한 이유는 Map을 이용하는 것보다 성능상 이득이 있기 때문입니다. 단순 메모리 접근이 Java에서 제공하는 HashMap과 같은 자료구조 사용보다 훨씬 빠릅니다. APT를 이용해 변환코드를 자동으로 생성하면 여러 장점이 있습니다.Reflection을 사용하지 않고 Method를 직접 수행해서 빠르다.Bytecode 생성과 달리 애플리케이션 처음 실행될 때 코드 생성이 필요 없고 만들어진 코드가 APK에 포함된다.Compile 시점에 코드가 생성돼서 Model 변화가 바로 반영된다.APT를 이용한 Code생성으로 Reflection 속도저하를 해결할 수 있습니다. 이 방식은 애플리케이션 반응성이 중요하고 상대적으로 Reflection 속도저하가 큰 안드로이드 라이브러리에서 최근 많이 사용하고 있습니다. (AndroidAnnotations, ButterKnife, Dagger)성능 비교¶다음은 Reflection, Dexmaker, Code Generating(APT)를 이용해 JSONObject를 Object로 변환하는 작업을 50번 수행한 결과입니다.성능 비교 결과이처럼 최신 OS 버전일수록 Reflection의 성능저하가 다른 방법에 비해 상대적으로 더 큽니다. 반대로 Dexmaker의 생성 속도는 빨라져 APT 방식과의 성능격차는 점점 작아집니다. 하지만 역시 APT를 통한 Code 생성이 모든 환경에서 가장 좋은 성능을 보입니다.마치며¶서비스 모델을 반복적으로 정의하지 않으면서 변환하는 방법을 알아봤습니다. 그 과정에서 Reflection 의 속도저하, Dexmaker 의 단점도 설명해 드렸고 결국 APT가 좋은 해결책이라고 판단했습니다. 저희는 이 글에서 설명해 드린 방식을 추상화해 Binding이라는 라이브러리를 만들어 사용하고 있습니다. Binding은 POJO를 다양한 JSON, Cursor, ContentValues등 다양한 형태로 변환해주는 라이브러리입니다. 뛰어난 확장성으로 다양한 형태의 데이터로 변경하는 플러그인을 만들어서 사용할 수 있습니다.Message message = Bindings.for(Message.class).bind().from(AndroidSources.cursor(cursor));Message message = Bindings.for(Message.class).bind().from(JSONSources.jsonString(jsonString));String jsonString = Bindings.for(Message.class).bind(message).to(JSONTargets.jsonString());위와 같이 Java상에 존재할 수 있는 다양한 타입의 객체에 대해 일종의 데이터 Binding 기능을 수행합니다. Binding 라이브러리도 기회가 되면 소개해드리겠습니다. 윗글에서 궁금하신 점이 있으시거나 잘못된 부분이 있으면 답글을 달아주시기 바랍니다. 감사합니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!

* 이 글은 MobX의 MobX and React 튜토리얼을 번역한 글입니다.** 오역 및 오탈자가 있을 수 있습니다. 발견하시면 제보해주세요!개요MobX은 간단하고 확장 가능하며 테스트를 거친 상태 관리 솔루션입니다. 이 튜토리얼은 10분 안에 MobX의 중요한 컨셉들을 모두 소개합니다. MobX는 독립적인 라이브러리지만 대부분의 사람들은 React와 함께 사용합니다. 그래서 이 튜토리얼은 MobX와 React의 조합에 중점을 두고 설명합니다.The core idea상태는 각 애플리케이션의 핵심입니다. 버그를 만드는 관리가 되지 않는 애플리케이션을 만드는 가장 빠른 방법은 주변의 로컬 변수들과 동기화 되지 않는 상태나 일관성 없는 상태를 만드는 것입니다. 그래서 많은 상태 관리 솔루션들이 상태를 변할 수 없게 만드는 식으로 상태를 수정할 수 있는 방법들을 제한하려고 합니다. 하지만 이 방법은 새로운 문제들을 생성합니다. 데이터를 표준화 해야 하고 참조 무결성이 보장되지 않으며 프로토타입과 같은 유용한 컨셉들을 활용하지 못하게 됩니다.MobX는 일관성 없는 상태를 만들 수 없도록 주요 문제를 해결하여 상태 관리를 간단하게 만들었습니다. 이를 위한 전략은 간단합니다. 애플리케이션 상태로부터 파생될 수 있는 모든 것들을 자동으로 파생되도록 하는 것입니다.개념적으로 MobX는 애플리케이션을 스프레드시트로 간주합니다.1. 가장 먼저 애플리케이션 상태가 있습니다. 애플리케이션의 모델을 채우는 객체, 배열, 원시, 참조의 그래프입니다. 이 값들은 애플리케이션의 "데이터 셀"입니다.2. 둘째로 파생 값이 있습니다. 기본적으로 애플리케이션으로부터 자동으로 계산될 수 있는 모든 값들입니다. 이 파생 값이나 계산된 값들은 완료되지 않은 todo들의 수와 같이 간단한 값부터 todo의 시각적 HTML 표현과 같은 복잡한 내용까지 다양합니다. 스프레드시트 용어로는 애플리케이션의 공식이나 차트가 있습니다.3. 리액션은 파생 값과 매우 비슷합니다. 주된 차이점은 값을 생성하지 않는 함수라는 점입니다. 대신 자동으로 특정 작업들을 수행시킵니다. 대체로 I/O와 관련된 작업입니다. 리액션은 적당할 때에 자동으로 DOM이 업데이트되거나 네트워크 요청을 하도록 만듭니다.4. 마지막으로 액션이 있습니다. 액션은 상태를 변경하는 모든 것들을 말합니다. MobX는 모든 사용자의 액션으로 발생하는 상태 변화들이 전부 자동으로 파생 값과 리액션으로 처리되도록 합니다. 동기화되고 결함이 없습니다.간단한 todo store이론은 충분합니다. 위의 내용을 유심히 읽는 것보다 실제 예시를 보는 것이이해하기 아마도 더 쉽습니다. 아주 간단한 ToDo store을 가지고 시작해봅시다. 아래의 모든 코드 블록들은 수정이 가능하므로 run code  버튼을 클릭하여 실행시킬 수 있습니다. 아래의 코드는  todo 목록이 포함된 매우 직관적인 TodoStore입니다. MobX는 아직 포함되지 않았습니다.우리는 todos 목록이 있는 todoStore 인스턴스를 이제 막 만들었습니다. 어떤 객체들로 todoStore을 채울 시간입니다. 변경 사항들을 보기 위해 각 변화 이후에 todoStore.report를 호출하고 로그를 남깁니다. 레포트는 의도적으로 항상 첫 번째 할 일만 출력합니다. 이 때문에 예시가 좀 인위적이지만 아래에서 볼 수 있듯이 MobX의 의존성 추적이 동적임을 잘 보여줍니다.결과:반응형으로 만들기지금까지 이 코드에서 특별한 것은 아무것도 없었습니다. 그러나 report를 명시적으로 호출할 필요가 없다면 어떨까요? 각 상태가 변할 때마다 report가 호출되길 원한다고 선언할 수 있습니까? 그러면 report에 영향을 줄 수도 있는 모든 코드에서 report를 호출해야 합니다. 최신의 report가 출력되기를 원하지만 그것을 모두 작성하고 싶지는 않습니다.운이 좋게도 이것은 MobX가 여러분을 위해 동작하는 것입니다. 자동으로 상태에 연관되어 있는 코드를 실행합니다. 그래서 report 함수는 스프레드시트의 차트와 같이 자동으로 업데이트 됩니다. 이를 위해 TodoStore를 관찰할 수 있어야 MobX가 모든 변경 사항들을 추적할 수 있습니다. 이를 수행하도록 클래스를 변경해봅시다.또한 completedTodosCount 속성은 자동으로 todo 목록에서 파생될 수 있습니다. @observable과 @computed 데코레이터를 사용하여 객체에서 관찰할 수 있는 속성들을 생성할 수 있습니다.이게 끝입니다! 시간에 따라 변할 수 있는 값들을 MobX에게 알려주기 위해 @observable를 표시했습니다. 계산은 상태로부터 파생될 수 있는 것들을 확인하기 위해 @computed를 사용하여 표시됩니다.pendingRequrests와 assignee 속성들은 지금까지 사용되지 않았지만 앞으로 이 튜토리얼에서 사용됩니다. 이 페이지의 모든 예시들을 짧게 만들기 위해 ES6와 JSX 그리고 데코레이터를 사용합니다. MobX의 모든 데코레이터들은 ES5 부분들을 가지고 있으니 걱정하지 마세요.생성자에 report를 출력하는 작은 함수를 만들고 autorun으로 감쌌습니다. Autorun은 한 번 동작되는 리액션을 만들고 함수 안에서 사용되는 관찰 가능한 모든 데이터들이 변경될 때마다 자동으로 다시 실행합니다. report는 관찰 가능한 todos 속성을 사용하기 때문에 적절할 때 레포트를 출력합니다. 이것은 다음 리스트에서 설명됩니다. 실행 버튼을 눌러보세요:report은 자동으로 동시에 중간 값을 빼먹지 않고 출력하였습니다. 유심히 로그를 보면 새로운 로그에서는 4번째 줄이 없는 것을 발견할 수 있습니다. 뒤의 데이터가 변경되는 것으로 report가 실제로 변경되지 않기 때문입니다. 반면에 첫 번째 할일의 이름이 바뀐 것은 report에서 실제로 사용되는 이름이기 때문에 report를 업데이트 하였습니다. 이것은 todos 배열이 autorun에 의해 관찰되는 것이 아니라 todo 아이템들 안에 있는 개별적인 속성을 관찰하고 있다는 것을 잘 설명해줍니다.반응형 React 만들기지금까지 바보 같은 report를 반응형으로 만들었습니다. 이제 이 store에서 반응형 유저 인터페이스를 만들 시간입니다. React 컴포넌트들은 이름값을 못하고 반응형이 아닙니다. mobx-react 패키지의 @observer 데코레이터는 React 컴포넌트 render 함수를 autorun으로 감싸 자동으로 상태에 따라 컴포넌트가 동기되도록 만듭니다. 개념적으로 이전에 report를 가지고 했던 것과 다르지 않습니다.다음 코드는 몇 개의 React 컴포넌트를 정의합니다. 이 안의 MobX는 @observer 데코레이터 뿐입니다. 이것으로 충분히 데이터가 변경될 때 각 컴포넌트가 개별적으로 다시 렌더링하도록 만들 수 있습니다. 더이상 setState를 호출할 필요가 없으며 설정이 필요한 셀렉터나 상위 컴포넌트를 사용하는 상태의 적절한 부분을 찾을 필요도 없습니다. 기본적으로 모든 컴포넌트들은 더 똑똑해졌지만 아직 부족합니다.아래의 코드를 보기 위해 run code 버튼을 클릭하세요. 코드는 수정이 가능하므로 자유롭게 동작시킬 수 있습니다. 예를 들어 @observer 호출을 모두 지우거나 TodoView의 데코레이터만 지워보세요. 오른쪽의 미리보기에서 숫자들은 컴포넌트가 렌더링될 때마다 표시합니다. 다음 코드는 다른 작업을 수행하지 않고 데이터를 변경해야 한다는 것을 잘 보여줍니다. MobX는 자동으로 store의 상태에 따라 유저 인터페이스의 적절한 부분들을 다시 파생하고 업데이트합니다.참조 사용하기 지금까지 관찰가능한 객체(프로토타입과 일반 객체 둘 다)와 배열, 원시를 만들었습니다. MobX에서 참고를 다루는 방법에 대해 궁금하지 않나요? 상태가 그래프를 형성할 수 있나요? 이전 코드에서는 todos의 assignee 속성이 있는 것을 알았을 것입니다. 또 다른 "store"을 생성하여 assignee에 포함되는 사람들의 값을 전달하고 그들에게 할일이 할당해줍시다.두 개의 독립적인 store이 있습니다. 하나는 사람들이 있고 하나는 할 일들이 있습니다. 사람 store의 사람을 assignee에 할당하기 위해 참조를 할당했습니다. 변경사항들은 TodoView에 의해 자동으로 선택됩니다. MobX를 사용하면 데이터를 표준화할 필요가 없고 업데이트될 컴포넌트들을 지정하기 위해 셀렉터를 작성할 필요가 없습니다. 실제로 데이터가 어디에 저장되는지는 중요하지 않습니다. 오랫동안 객체들은 관찰가능하게 만들어졌고 MobX는 그것들을 추적할 수 있습니다. 실제 JavaScript 참조가 동작합니다. MobX는 파생과 관련이 있으면 자동으로 그것들을 추적합니다. 테스트 해보기위해 다음의 인풋 박스에 이름을 변경해보세요. (먼저 위의 Run code 버튼을 클릭했는지 확인해보세요)위의 인풋 박스의 HTML은 간단합니다:비동기 액션작은 Todo 애플리케이션에 있는 모든 것들은 상태로부터 파생되기 때문에 언제 상태가 변화하는지는 중요하지 않습니다. 비동기 액션을 만드는 것은 매우 수월합니다. 새로운 할일 아이템을 비동기적으로 로드하려면 아래의 버튼을 여러번 클릭하세요.코드는 매우 직관적입니다. UI가 현재 로딩되는 상태를 반영하도록 store의 pendingRequests 속성을 업데이트하는 것으로 시작합니다. 로딩이 끝날 때 store의 todos를 업데이트하고 pendingReqeust 카운터를 증가시킵니다. 이 스니펫을 이전 TodoList 정의와 비교하여 pendingRequests 속성이 어떻게 사용되는지 확인하세요.개발자 도구mobx-react-devtools 패키지는 화면의 오른쪽 최상단에서 찾을 수 있고 모든 Mobx+ReactJS 애플리케이션 내에서 사용할 수 있는 개발자 도구를 제공합니다. 첫 번째 버튼을 클릭하면 각 다시 렌더링되는 @observer 컴포넌트가 표시됩니다. 두 번째 버튼을 클릭하고 미리보기에서 해당 컴포넌트 중 하나를 클릭하면 해당 컴포넌트의 종속성 트리가 표시되므로 주어진 순간에 관찰중인 데이터 조각을 정확하게 검사할 수 있습니다.결론끝났습니다! 관용구는 없습니다. 완전한 UI를 형성하는 간단하고 선언적인 컴포넌트들입니다. 그리고 상태로부터 완전하고 반응형으로 파생됩니다. 여러분의 애플리케이션에서 mobx와 mobx-react를 사용하기 시작할 준비가 되었습니다. 지금까지 배운 것들을 짧게 요약하였습니다:1. MobX가 객체들을 관찰할 수 있도록 @observable 데코레이터 또는 observable(객체 혹은 배열)을 사용하세요.2. @computed 데코레이터는 상태로부터 자동으로 파생되는 함수를 만들기 위해 사용될 수 있습니다.3. 관찰 가능한 상태에 의존하는 함수들을 자동으로 실행하기 위해 autorun을 사용하세요. 로깅하거나 네트워크 요청하기에 유용합니다.4. React 컴포넌트를 진짜 반응형으로 만들기 위해 mobx-react 패키지의 @observer 데코레이터를 사용하세요. 자동으로 효율적으로 업데이트합니다. 심지어 많은 양의 데이터가 있는 아주 복잡한 애플리케이션에서도 사용됩니다.위의 수정 가능한 코드 블록을 사용하여 조금만 더 만져보면 MobX가 모든 변경 사항에 어떻게 반응하는지 기본적인 느낌을 얻을 수 있습니다. 예를 들어 언제 호출되는지 보기 위해 report 함수에 로그를 추가하거나 report를 출력하지 않고 이것이 TodoList 렌더링에 어떤 영향을 주는지 확인하세요. 아니면 특정 상황에서만 출력하세요...MobX는 상태 컨테이너가 아닙니다사람들은 종종 MobX를 Redux의 대안으로 사용합니다. MobX는 기술적인 문제를 해결하는 라이브러리일 뿐이며 아키텍처나 상태 컨테이너가 아닙니다. 그러한 의미에서 위의 예시들이 고안된 것으로 메서드에서 로직을 캡슐화하거나 store나 컨트롤러에서 구성하는 것과 같은 적절한 엔지니어링 기법을 사용하는 것이 좋습니다. 또는 HackerNesw의 누군가는 이렇게 말했습니다:"MobX는 많은 곳에서 언급되었지만 나는 마냥 좋다고 말할 수 없습니다. MobX로 작성하는 것은 컨트롤러/디스패처/액션/슈퍼바이저 또는 다른 형태의 데이터 흐름을 관리하여 애플리케이션의 요구 사항을 패턴화할 수 있습니다."#트레바리 #개발자 #안드로이드 #앱개발 #MobX #React #백엔드 #인사이트 #경험공유

Overview“JIRA하고, 자빠졌네!” 세종대왕은 확실히 개발자의 두뇌를 가지고 있었던 게 분명합니다. 먼 시대를 지나 오늘날 QA를 하는 저에게 응원을 해주시니 말입니다. 하지만 그는 틀렸습니다. 걱정과는 다르게 다행히 자빠지진 않았거든요. 지라(JIRA) 덕분입니다.갑자기 지라 이야기가 나와 당황하셨죠? 축하해주세요. 드디어 브랜디도 지라를 사용하게 되었답니다. (짝짝짝!) 지라 도입은 처음이라 세팅부터 쉽지 않았는데요. 이번 글은 눈물겨웠던 지라 세팅 과정과 브랜디의 이슈관리를 소개하겠습니다. 스크럼을 쓰면 좋은 점스크럼(Scrum)은 요구 사항 분석부터 하는 칸반(Kanban)보다 효율적입니다. 안드로이드와 iOS로도 나눠져 있고 업무를 짧게 반복하기 때문이죠. 스크럼에 적합한 워크플로우(Workflow)를 볼까요? 이것은 실제로 브랜디 R&D본부에서 사용하고 있기도 합니다. 스크럼에 적합한 워크플로우IN PROGRESS: 이슈나 개발 요건을 티켓으로 만들면 IN PROGRESS 상태가 됩니다. RESOLVED: 이슈나 개발 요건이 완료되면 RESOLVED 상태로 변경합니다.QA: QA가 필요한 개발 요건은 QA상태로 변경합니다.PASS: 이슈 또는 개발 요건이 수정되었거나 문제가 없다면 PASS 상태로 변경합니다.FAIL: 이슈 또는 개발 요건이 제대로 수정되지 않았거나 다른 이슈가 발생하면 FAIL 상태로 변경합니다.QA불필요: QA가 필요하지 않은 개발 요건은 QA불필요 상태로 변경합니다.DONE: 이슈를 해결했거나 개발을 완료하면 DONE 상태로 변경합니다CLOSE: 담당 팀장님이 이슈 확인 후 CLOSE 처리합니다. 예를 들어보겠습니다. 킥오프 서비스 회의를 하고, SB를 제작, 리뷰합니다. 이후에 디자인팀과 개발팀 일정을 공유하고 스크럼 마스터는 스프린트 주기를 책정하죠. 스프린트가 시작되면 개발자는 스토리 티켓을 작성하는데요. 개발이 끝나면 QA가 필요한 티켓은 테스트를 진행하고, QA가 종료되면 스프린트도 종료됩니다.Epic 티켓위의 이미지는 Epic 티켓입니다. Android, iOS, 이슈 등 모든 티켓은 Epic 안에서 관리합니다. 한 곳에서 한꺼번에 관리하기 때문에 히스토리 관리가 편하고, 진행 상황도 확인할 수 있습니다.티켓 생성개발팀의 티켓 생성입니다. 개발자는 SB를 보고 개발 티켓을 작성합니다. 개발 티켓 작성 후에 개발이 진행되며 QA 판단 여부를 체크해 QA 상태로 변경합니다. 변경된 티켓에 관한 QA가 진행되며 문제가 없으면 해당 티켓은 종료됩니다.이슈 생성다음은 이슈 생성입니다. 파악한 SB는 디자인 시안과 비교하며 개발이 된 Android, iOS 테스트 파일을 QA합니다. QA를 진행할 때 발생한 이슈는 지라 티켓으로 등록하여 이슈를 관리합니다. 모든 이슈 티켓 종료되면 해당 차수의 QA는 끝나고 마침내 상용에 배포합니다. 배포가 완료되면 필수 및 크리티컬 리그레이션 테스트가 진행됩니다. Conclusion실수는 항상 모든 것이 끝난 이후에 보이기 마련입니다. 수십 번 QA를 해도 보이지 않던 문제들이 상용에 올라간 이후부터 보이기 시작하죠. 스크럼은 이런 실수들을 가장 최소화할 수 있는 툴이 아닐까 생각합니다. 물론 아무리 좋은 툴을 써도 팀원들과 함께 뭉치는 것보다 중요한 것은 없겠죠. 다음 글은 자동화를 주제로 찾아뵙겠습니다. JIRA하고 자빠지지 않는 개발자가 됩시다!글김치영 대리 | R&D PM팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #JIRA

안녕하세요, 8퍼센트입니다.8퍼센트는 다양한 매체와 콘텐츠로 이야기를 전하고 있습니다. 이번엔 인터뷰를 통해 8퍼센트를 이루고 있는 각 팀들의 이야기를 들어보며 고객에게 더 가까이 다가가고자 합니다. 그 첫 번째 주인공은 서비스 개발을 담당하는 ‘프로덕트’ 팀입니다.Q. 안녕하세요, 인터뷰를 위해 프로덕트 팀 허재영 님과 이호성 CTO님이 자리해주셨는데요. 먼저, 8퍼센트의 제품을 만드는 프로덕트팀은 구체적으로 어떤 일을 하시나요?A. 프로덕트 팀은 8퍼센트의 서비스를 만드는 팀입니다. 고객들이 8퍼센트를 이용하는 데 있어서 불편함이 없도록 서비스를 개선하고 유지하는 역할을 하고 있습니다. 예를 들어 기존의 인터넷 기반 금융 서비스는 공인인증서, Active X를 보면 알 수 있듯이 사용자의 편리함에 초점을 두고 있지 않습니다. 저희의 역할은 사용자들에게 더 편리하고 효율적인 금융 생활을 할 수 있도록 새로운 금융서비스를 시도하는 것입니다.Q. 새로운 금융시스템을 구축하고 운영해나가는 과정이 쉽지 않을 것 같은데, 그것에 대해 어려움과 극복해낸 경험이 궁금합니다.A. 8퍼센트는 이미 만들어진 솔루션을 사용하거나 외주를 통해 시스템을 구축하는 기존의 회사들과 다르게 직접 바닥부터 금융 시스템을 쌓고 있습니다. 금융시스템은 정확함과 안정성을 빼놓을 수 없는데 사용자가 많아지고 시스템이 거대해질수록 생각지 못한 부분에서 오류가 생기게 됩니다. 이러한 오류는 회사의 손실을 발생시키고, 고객들의 신뢰를 잃게 합니다. 위와 같은 일이 발생하지 않게 시스템을 정밀하게 설계하는 것은 기본이고 추가로 발생하는 문제들에 대해 올바르게 대처하는 것이 금융 시스템을 구축하고 운영하는 과정입니다. 물론 힘든 과정이지만 단계별로 시스템을 구축하는 것이 앞으로 남들과 다른 서비스를 제공할 수 있는 기반이 된다고 생각합니다.서비스 초기, 지급 프로세스에 문제가 있었던 적이 있었는데, 이를 인지하고 그에 대한 대응을 진행했습니다. 또한, 대응에 그치지 않고 테스트와 수정한 부분에 대해 제대로 동작하고 있는지 알아보는 QA(Quality Assurance) 프로세스를 갖추는 계기가 되었습니다. Q. 그렇게 만들어지는 8퍼센트 서비스만의 차별화된 점은 무엇인가요?A. 첫 번째는 '자동 투자'입니다. 자동 투자를 선택하게 되면 예치금과 상환된 투자금이 지속적으로 재투자됩니다. 따라서, 고객이 직접 신경 쓰지 않아도 자산을 쉽게 불릴 수 있습니다. 두 번째는 '스페셜딜'입니다. 일부 스페셜딜은 기업이 제공하는 서비스를 투자자가 직접 체험해볼 수 있으며, 이를 통해 고객은 투자 이외의 부수적인 혜택을 누릴 수 있습니다. 소개해드릴 마지막 차별점은 다양한 업체와의 제휴입니다. 8퍼센트는 현재, 기존 금융권에 있는 많은 금융 회사들과 제휴를 맺고 있습니다. 기존 금융 회사가 오랜 시간 쌓아놓은 시스템과 노하우, 그리고 8퍼센트의 서비스를 합쳐 좋은 서비스를 제공하는 것은 저희 서비스의 강점이 된다고 생각합니다. 또한, 기존 금융권뿐 아니라 토스와 같은 스타트업과의 제휴 역시, 토스 플랫폼에서 간편하게 8퍼센트 서비스를 이용할 수 있다는 점에서 이런 다양한 제휴는 저희만의 차별점이 된다고 생각합니다.Q. 8퍼센트 서비스에는 정말 다양한 장점이 있는 것 같습니다. 이렇게 좋은 서비스를 구상할 때 중요하게 생각하는 기준이 무엇인가요?A. 프로덕트 팀에서는 제품을 구상하는 데 있어서 ‘고객들에게 전달될 수 있는 가치’, ‘안정성과 정확성’, ‘사용성’ 이렇게 세 가지 기준을 중요하게 생각하고 있습니다. 금융 서비스는 대부분 돈으로 환산되는 가치를 추구합니다. 프로덕트 팀이 추구하는 금전적인 가치 역시 투자를 했을 때 돈을 벌고, 대출을 통해 돈을 절약하는 것입니다. 이러한 금전적 가치는 개인과 개인들이 서로 연결되어 발생한다는 점에서 사회적 가치에 기여한다 생각합니다. 또한, 핀테크 서비스들이 나오기 이전에 투자와 대출은 상당히 무겁고 다가가기 힘든 면이 있었습니다. 그래서 프로덕트 팀에서는 투자와 대출로 이뤄진 8퍼센트 서비스를 이용자가 손쉽게 쓸 수 있게 만드는 ‘사용성’이 제품을 구상하는 데 있어서 중요한 기준이 됩니다. 예를 들어, 토스 플랫폼을 통해서 저희 투자 서비스를 이용할 수 있게 하는 것도 ‘사용성’을 높이는 것의 일환입니다.Q. 얘기를 들어보니 명확한 기준을 통해 좋은 서비스가 나오는 것 같습니다. 8퍼센트 투자나 대출 서비스를 직접 이용하시나요? A. 모두가 소액부터 거액까지 다양하게 투자 서비스를 직접 체험하고 있습니다. 이는 고객의 입장에서 생각해볼 기회가 되어 일하는데 좋은 자극이 됩니다. ‘개밥 먹기’라고 개 사료를 만드는 회사에서 실제로 먹어보면서 제품이 어떤지 테스트하는 것에서 유래한 말이 있습니다. 8퍼센트 역시 이런 '개밥 먹기' 테스트를 꾸준히 하고 있습니다. 상품 2.0이 처음 출시되었을 때, 직접 소액 대출을 받아 안내, 혹은 연체 문자가 잘 오는지 등 대출 프로세스를 경험하기 위해서 대출 서비스를 이용했습니다. 물론 회사 내부 관계자에게 대출하기 위해 투자자를 모은다는 것은 윤리적인 문제가 있기 때문에 딜을 내부로만 열어서 회사 분들이 투자한 것만으로 모집했습니다. 신용등급은 당연히 떨어지지 않았고 상환하며 아직 잘 쓰고 있습니다.Q. 현재 P2P 금융 법제화에 대한 논의가 활발히 진행되고 있는데, 과거 새로운 규제가 생겼을 때 대처한 경험이 궁금합니다.A. 지금까지 가장 큰 변화는 작년 5월 가이드라인이 시행되면서 일어났습니다. 그전까지 투자자들로부터 모집한 자금은 회사의 소속으로 되어있었는데, 회사가 부도가 나게 되면 그 돈이 압류되어 투자자들의 돈을 못 빼는 현상이 발생할 수 있었습니다. 가이드라인에서 제시한 부분 중 가장 큰 것이 바로 이에 대한 것입니다. 투자자의 돈을 제삼자가 보관하게 해라 즉, 금융기관이 그 돈을 보관하게 하라는 것인데 이를 위해 농협과 함께 설계부터 시작해 지금의 시스템을 만들었습니다. 농협 측에 자금을 보관하고 저희가 시스템상으로 자금의 흐름을 요청하는 식으로 자금이 직접 저희를 통하지 않고 P2P 거래가 이루어지게 되었습니다.Q. 프로덕트 팀의 대처 능력이라면 법제화 같은 변화에서도 흔들림 없는 서비스를 제공할 수 있을 것 같습니다. 마지막으로 프로덕트팀의 목표는 무엇인가요?A. 프로덕트 팀에서는 항상 ‘우리가 바라는 프로덕트가 무엇일까?’ 고민합니다. 개발자로서 가장 안타까운 것은 열 명의 팀원들이 서로 힘내서 만들어내는 서비스가 사라지는 것입니다. 더 나아가, 사라지지 않는다는 것은 사회적인 가치를 인정받는다는 것입니다. 물론 돈을 만들어낸다는 얘기이기도 하지만 우리가 열심히 만든 자식과도 같은 서비스의 사회적인 가치를 인정받고 지속가능하게 하는 것이 최종적인 목표입니다. 특히 이번 18년도 1분기에 8퍼센트의 단기적 성장과 함께 미래 계획이 구체화 되고 그에 대한 긍정적인 확신이 생겨 큰 동기부여가 되었습니다. 8퍼센트 고객들도 더 편리하고 효율적인 서비스를 만들어갈 저희와 끝까지 동행해주셨으면 좋겠습니다.인터뷰는 8퍼센트의 모든 팀을 소개할 때까지 계속되니 많이 기대해주세요:)> 8퍼센트 서비스 보러 가기 #8퍼센트 #에잇퍼센트 #프로덕트팀 #프로덕트 #인터뷰 #팀원소개 #팀소개

Go 서버 개발을 시작하며   특정 API만 다른 언어로 구현해서 최대의 성능을 내보자! 저희 서버는 대부분 Django framework 위에서 구현된 광고 할당 / 컨텐츠 할당 / 허니스크린 앱 서비스 이렇게 나눌 수 있는데 Python 이라는 언어 특성상 높은 성능을 기대하기가 어려웠습니다. 하지만 세가지 서비스에서 락스크린에서 어떤 컨텐츠나 광고를 보여줄지 결정하는 Allocation(할당) API 가 가장 많이 호출되고 있었는데 빈도로 보면 80% 정도로 높은 비중을 차지하고 있어서 이 Allocation API 들을 성능이 좋은 다른 언어로 구현하면 어떨까 하는 팀내 의견이 있었습니다. Why Go? 저는 예전부터 Java,  C# 등의 컴파일 언어에 익숙해서 기존 Java 와 C, 그리고 Go 라는 최근에 새로 나온 언어 중에서 아래 블로그글과 같이 여러 reference 들을 통해 성능이 좋다는 Go 로 이 API 들을 포팅하는 작업을 시작하게 되었습니다. Go 에 대한 첫 인상은 Java, C계열 언어보다 덜 verbose 보였고 python 보다는 strongly-typed, encapsulated 하다보니 자유도를 제한해서 코드를 보기 쉽게 하는 것을 선호하는 저의 성격과도 잘 맞는 언어였습니다.     출처: Carles Mateo, Performance of several languages서버 개발 환경   Server design How to import libraries  GVT (https://github.com/FiloSottile/gvt) – Go 는 vendering tool 을 통해 dependency 를 관리할 수 있습니다. GVT 의 경우 처음 도입했을 때 별로 유명하지 않았는데 사용법이 간단해서 도입하게 되었습니다. 아래와 같이 참조하고 있는 revision 을 관리해주며 update 통해서 최신 소스를 받아 올수 있습니다.   { "version": 0, "dependencies": [ { "importpath": "github.com/Buzzvil/go-env", "repository": "https://github.com/Buzzvil/go-env", "vcs": "git", "revision": "2d8489d40184a12c4d09d09ce1ff717e5dbb0745", "branch": "master", "notests": true }, ....  Design pattern  Go 언어에서는 package level cycling dependency 를 허용하지 않아서 좀더 명확한 구조를 만들기 좋았습니다. 예를들어 Service 에서는 Controller 를 참조할수 없고 Model 에서는 Controller / Service / DTO 등을 참조할수 없도록 강제했습니다. 모든 API 요청은 Route 를 통해 Controller 에게 전달되고 이 때 생성된 DTO (Data transfer object) 들을 Controller 가 직접 혹은 Service layer 에서 처리하도록 하였고 DB 에 접근할 때는 모델을 통해 혹은 직접 접근하도록 했지만 추후 구조가 복잡해지면 DB 쿼리 등을 담당하는 DAO (Data access object) 를 도입할 계획입니다   Libraries                  요소이름선택 이유NetworkGinWeb 서버이다 보니 네트워크 성능을 최우선으로 고려, 벤치마크 표를 보고 이 라이브러리를 선택Redis & cachego-redis역시 성능을 가장 중요한 지표로 보고 이 라이브러리 선택MysqlGormORM 없이는 개발하기 힘든 시대이죠. 여러 Database를 지원하고 ORM 중에서도 method chaining 을 사용하는 Gorm 을 선택Dynamoguregu dynamoAWS에서 제공하는 Dynamo 패키지를 그대로 사용하면 코드 양이 너무 많아지고 역시 method chaining 을 지원해서 선택Environment variablescaarlos0 envGo 에서는 tag 를 이용하면 좀더 코드를 간결하고 읽기 쉽게 사용할수 있는데 이 라이브러리가 환경변수를 읽어오기 쉽도록 해줌   Redis cache  func SetCache(key string, obj interface{}, expiration time.Duration) error { err := getCodec().Set(&cache.Item{ Key: key, Object: obj, Expiration: expiration, }) return err } func GetCache(key string, obj interface{}) error { return getCodec().Get(key, obj) }  Mysql  var config model.DeviceContentConfig env.GetDatabase().Where(&model.DeviceContentConfig{DeviceId: deviceId}).FirstOrInit(&config)  Dynamo if err := env.GetDynamoDb().Table(env.Config.DynamoTableProfile).Get(keyId, deviceId).All(&profiles); err == nil && len(profiles) > 0 { ... }  Environment variables  var ( Config = ServerConfigStruct{} onceConfig sync.Once ) type ( ServerConfigStruct struct { ServerEnv string `env:"SERVER_ENV"` LogLevel string .... } ) func LoadServerConfig(configDir string) { onceConfig.Do(func() {//최초 한번반 호출되도록 env.Parse(&Config) } }    Unit test   환경 구성 Test 환경에는 Redis / Mysql / Elastic search 등에 대한 independent / isolated 된 환경이 필요해서 이를 위해 docker 환경을 따로 구성하였습니다. Test case 작성은 아래와 같이 package 를 분리해서 작성했습니다.  package buzzscreen_test var ts *httptest.Server func TestMain(m *testing.M) { ts = tests.GetTestServer(m) // 환경 시작 tearDownElasticSearch := tests.SetupElasticSearch() tearDownDatabase := tests.SetupDatabase() code := m.Run() // 여기서 작성한 TestCase 들 실행 // 환경 종료 tearDownDatabase() tearDownElasticSearch() ts.Close() os.Exit(code) }  Mock server는 은 http.RoundTripper interface 를 구현해서 http.Client 의 Transport 멤버로 설정해서 구현했습니다. 아래는 Test case 작성 예제입니다.  httpClient := network.DefaultHttpClient mockServer := mock.NewTargetServer(network.GetHost(MockServerUrl)) .AddResponseHandler(&mock.ResponseHandler{ WriteToBody: func() []byte { return []byte(mockRes) }, Path: "/path", Method: http.MethodGet, }) clientPatcher := mock.PatchClient(httpClient, mockServer) defer clientPatcher.RemovePatch()  Unit test 관련해서는 내용이 방대해서 추후 다른 포스트를 통해 자세히 소개하도록 하겠습니다.  Infra API 요청 분할 AWS Application load balancer 여러 API 중에서 할당 API 를 제외한 요청은 기존의 Django 서버로 요청을 보내고 할당요청에 대해서만 Go서버로 요청을 보내도록 구현하기 위해 먼저 시도 했던 것은 AWS Application load balancer (이후 ALB) 였습니다. ALB 의 특징이 path 로 요청을 구별해서 처리할수 있었기 때문에 Allocation API 만 Go 서버 로 요청이 가도록 구현했습니다.  출처: Amazon Devops Blog, Introducing Application Load Balancer   하지만 이렇게 오랫동안 서비스 하지 못했는데 그 이유는 서버 구성이 하나 더 늘어나고 앞단에 ALB 까지 추가되다 보니 이를 관리하는데 추가 리소스가 들어가게 되어서 어떻게 하면 이러한 비용을 줄일수 있을까 고민하게 되었습니다.   Using docker & nginx  Go로 작성된 서버가 독립적인 Micro service 냐 아니면 Django 서버에서 특정 API 를 독립시켜 성능을 강화한 모듈이냐 의 정체성을 두고 생각해봤을때 후자가 조금더 적합하다보니 Go / Django 서버는 한 묶음으로 관리하는 것이 명확했습니다. Docker 를 도입하면서 nginx container 가 proxy 역할을 하고 path를 보고 Go container / Django container 로 요청을 보내는 구성을 가지게 되었습니다.  글을 마치며   시작은 미약하였으나 끝은 창대하리라 하나의 API를 이전했음에도 불구하고 Allocation API 에 대해서는 약 1/3, 서버 Instance 비용은 1/2.5 수준으로 감소했습니다.   설명: 기존 4개의 Django 인스턴스의 CPU 사용률이 모두 13% 정도 감소, Go 인스턴스의 CPU 사용율은 17% 정도   17 / (13 * 4)  ≒ 1 / 3  충분히 만족할만한 성과가 나와서 그 뒤로 몇가지 API도 Go 로 옮겼고 새로 작성하는 API 는 Go 환경 안에서 직접 구현하는 중입니다. 처음에는 호출이 많은 하나의 API 를 다른 언어로 포팅하기 위해 시작한 작업이었는데 Container 기술을 도입하는 등 서버 Infra 까지 변경하면서 상당히 큰 작업이 뒤따르게 되었습니다. 하지만 이 작업을 하면서 많은 동료들의 도움과 조언이 있었고 결국 완성할수 있었습니다. 이렇게 실험적인 도전을 성공 할수 있는 환경에 여러분을 초대하고 싶습니다! Go언어에 대한 문의나 좋은 의견도 환영합니다.