스토리 홈

인터뷰

피드

뉴스

조회수 2185

SaaS 와 On-Premises 장단점

와탭랩스는 SaaS 기반의 IT 모니터링 서비스로도 사용할 수 있지만 On-Premises 솔루션으로도 제공되기 때문에 고객과 대화할 때 SaaS와 On-Premises의 장단점에 대한 답을 드려야 할 때가 많습니다.어떻게 비교해야 할까. SaaS와 On-Premises를 비교하기 위해서는 도입 프로세스에서 운영까지의 지속되는 과정에서의 장단점들을 알아봐야 합니다. 많은 고객들이 SaaS를 설명드릴 때, TCO를 기반으로 하는 가격 비교를 하지만 이는 일부일 뿐입니다. Total cost of ownership (TCO) is a financial estimate intended to help buyers and owners determine the direct and indirect costs of a product or system. It is a management accounting concept that can be used in full cost accounting or even ecological economics where it includes social costs.----TCO시스템 또는 제품 구매시에 들어가는 모든 직간접 비용을 의미. 구매비용에서 운영비용은 물론 사회적 비용까지  모두 포함.왜 SaaS로 넘어가야 하나요?현대 조직은 효율적인 비용 구조에 대한 지속적인 압박을 받고 있습니다. 그렇기 때문에 많은 기업들이 IT 기반의 효율적인 기업 관리 시스템을 갖추어 나갔지만 역설적으로 IT 시스템들은 여전히 비싼 가격에 대규모 도입 방식을 사용해 왔습니다. 하지만 클라우드 시장이 만들어지면서 SaaS 시장이 빠르게 발전하고 있습니다. SaaS(Software-as-a- Service)는 공급자가 원격에서 솔루션을 제공하여 관리하는 인터넷 기반의 서비스를 의미합니다. 초기 SMB시장을 위주로 확장을 하던 SaaS 기반의 서비스는 이제 소규만을 위한 서비스가 아닙니다. 소규모 스타트업 뿐만이 아니라 많은 엔터프라이즈 기업들이 SaaS 서비스를 사용하고 있습니다. 낮은 도입 비용SaaS는 On-Premises 방식에 비해 도입 비용이 현저히 낮습니다. 기존 On-Premises의 비용의 많은 부분들이 채널, 컨설팅, 영업 관리 비용이 포함된 금액이였지만 SaaS 방식의 서비스들은 해당 솔루션 기능에 대한 비용만을 청구합니다. 더 이상 부가적인 비용 지출을 하지 않아도 됩니다. 또한 SaaS 기반의 서비스는 실무자가 직접 도입하고 사용해 볼 수 있기 때문에  POC없이 기업에 도입하고 구매 여부를 진행 할 수 있습니다.  POC (Proof Of Concept)기존에 시장에서 사용돼지 않던, 신기술을 프로젝트에 도입하기에 앞서, 검증하기 위한 목적으로 사용. 사업과 관계가 약간은 동떨어진 기술 검토를 위한 프로젝트고객사에서 하고, 업무는 아주 간단한 것을 수반. 신기술 여부는 중요치 않음낮은 TCOSaaS 솔루션은 유지보수 비용 부담이 없습니다. 업데이트에 요금을 부과하지 않으며 대규모 시스템 업데이트로 인한 부담도 존재하지 않습니다. 소프트웨어 구매시 발생하는 하드웨어 구매 비용으로부터 자유로우며 하드웨어를 유지 보수하거나 업데이트 해야 할 일도 없습니다. SaaS 솔루션은 구매비용(CAPEX) 운영비용(OPEX) 모두 절감할 수 있습니다. CAPEX미래의 이윤 창출을 위해 지출한 비용. 기업이 고정자산을 구매하거나, 유효수명이 당회계연도를 초과하는 기존의 고정자산 투자에 돈을사용할 때 발생.회사가 장비, 토지, 건물 등의 물질자산을 구입하거나 유지, 보수할 때 사용되는 비용.OPEX업무지출 또는 운영비용이라고도 하며 갖춰진 설비를 운영하는 데 드는 제반 비용을 의미. OPEX는 인건비, 재료비, 수선유지비와 같은 직접 비용과 제세공과금 등의 간접 비용으로 구성되어 있으며 통상 CAPEX와 함께 대조적으로 많이 쓰이는 용어.빠른 출시SaaS 솔루션은 이미 시장에 배포되는 과정에서 테스트가 완료되어 있습니다. 처음부터 적용하기가 쉬우며 업데이트도 번거롭지 않습니다. 기업은 최신 서비스를 바로 적용하여 더 높은 ROI를 만들어 낼 수 있습니다. 사용량 기반의 과금SaaS는 사용량 단위의 유동적인 과금이 가능합니다. 이는 반대로 대규모 도입후에 시스템이 줄어들게 되더라도 과금이 같이 줄어드는 장점을 가지고 있습니다. 낮은 위험도SaaS는 사용랑 기반의 과금과 쉬운 도입을 제공하기 때문에 On-Promises에 비해 솔루션 변경에 대한 위험도가 낮습니다. 솔루션 사용하기 위해 인프라스트럭처를 도입하지 않기  때문에 해지시에 사용하지 않는 인프라스트럭처가 존재할 위험에서도 빠져나갈 수 있습니다. SaaS 솔루션 도입시 고민해야 할 점SaaS 솔루션이 장점이 많은 구조이긴 하지만 아래와 같이 도입시 고민해야 하는 것들이 있습니다. 인터넷 의존성외부망을 열수 없는 환경에서는 사용할 수가 없습니다. 기업의 정책에 따라 기업의 인터넷 환경을 열수 없다면 SaaS 솔루션을 도입할 수 없습니다. 기업 내재화고객이 SI를 통해 자사를 위한 서비스를 요구하는 경우에 맞지 않습니다. 또는 데이터의 거주 위치에 대해 민감한 경우에도 문제가 될 수 있습니다. 클라우드가 대중화 되면서 데이터의 거주 위치는 실제로 의미가 없어지고 있습니다.On-Premises 솔루션을 도입하는 이유사내에 솔루션을 설치하는 On-Premises 방식은 IT 서비스와 함께 만들어진 방식이며 현재까지도 엔터프라이즈 규모의 기업들이 가장 좋아하는 방식입니다. 기업 내재화On-Premises 방식은 SI를 통한 기업 맞춤형 솔루션 제공이 가능합니다. 기업이 자사에 최적화된 방식으로 솔루션을 변경하여 사용함으로써 만족도를 높일 수 있습니다. 데이터 소유On-Premises 방식은 솔루션과 데이터가 모두 사내에 존재함니다. 외부망이 열려있지 않더라도 사내에서 데이터가 가공되고 처리되기 때문에 문제없이 사용할 수 있습니다.  On-Premises를 떠나는 이유클라우드의 도입과 함께 많은 엔터프라이즈 기업들이 아래의 이유로 On-Premises에서 SaaS로의 전환을 고민하고 있습니다. 비용On-premises의 높은 도입 비용에 대한 고민이 높아지고 있습니다. 특히 클라우드 생태계에서 노드락 라이센스는 의미가 없어지고 있습니다.노드락 라이선스별도의 라이선스 서버없이 해당 장비에서만 사용 가능한 라이선스입니다.플로팅 라이선스별도의 라이선스 서버를 구축하여 클라이언트 요청이 있을때 라이선스 서버에서 클라이언트로 라이선스를 할당하는 방식입니다.유지보수엔터프라이즈 기업은 자사의 수많은 솔루션들을 유지보수 하는 데 지쳐가고 있습니다. 솔루션 유지 보수 비용은 On-Premises 솔루션 가격에 포함되어 있는 경우도 있기 때문에 개개별로 관리하기도 어려운 부분이 있습니다. 점점 복잡해지는 IT 환경 속에서 기업은 유지보수에 대해 민감해지고 있습니다.On-Premises의 대안 Private SaaS SaaS와 On-Premises의 장점을 합친 방식으로 SaaS 솔루션 전체를 패키지로 제공하는 방식입니다. 와탭랩스의 경우 IT 모니터링 서비스 전체를 패키징하여 기업에 제공하고 있습니다. 엔터프라이즈 기업의 서비스 운영팀에 설치하고 기업 내부에서 서비스 방식으로 사용할 수 있습니다. 빌링까지 포함되어 있는 제품이기 때문에 사용량을 체크할 수 있으며 일반적으로는 년단위의 라이센스를 사용하게 됩니다.마무리SaaS와 On-Premises 솔루션을 비교한다면 SaaS가 미래의 솔루션이라고 할 수 있습니다. 하지만 Private 클라우드를 도입하고 외부에 망을 열지 않는 다면 On-Premises를 사용해야 합니다. 뿐만 아니라 와탭랩스의 경우처럼 SaaS 솔루션 전체를 On-Premises로 제공하는 기업들도 있기 때문에 On-Premises 시장도 줄어들지는 않을 것으로 예상되고 있습니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 1895

CTE for postgresql and sqlalchemy

저희 서비스는 가게마다 웹에서 접속할 수 있는 어드민을 제공하는데, 프렌차이즈가 아닌 하나의 독립적인 가게들일 경우 정보를 가져와 나타내는 데는 굳이 CTE 를 쓸 필요가 없지만 프렌차이즈일 경우 본사와 지점들로 나누어져 있어서 본사와 지점들 정보를 다 가져오기 위해서 CTE 를 사용하게 되었습니다.그럼 postgresql 의 CTEReadme 에 나와 있는 예제와 sqlalchemy core 로 변환하는 것까지 살펴보겠습니다.CTE란?Common table expression 의 약자로 ‘공통 테이블 식’입니다.CTE 특징WITH절 같은 SELECT 문에서 효과적으로 테이블 식을 정의 할 수 있습니다.CTE는 VIEW의 사용방법과 비슷하지만, VIEW보다 편리합니다.VIEW와 달리 사전에 CTE를 정의할 필요가 없습니다.개체로 저장되지 않고, 쿼리 지속시간에만 존재합니다.CTE는 재귀 쿼리를 사용할 수 있습니다.재귀 CTE는 여러행을 반환 가능합니다.동일 문에서 결과 테이블을 여러번 참조 가능합니다.재귀 CTE 예제아래 예제는 ‘A’부서 하위에 있는 부서만 추출하는 예제입니다.일단 재귀 CTE를 이용한 쿼리를 사용하려면 ‘WITH RECURSIVE’ 키워드를 추가해야 합니다.Table ‘department’ 인접 리스트로 조직 구조를 나타냅니다.CREATE TABLE department ( id INTEGER PRIMARY KEY, -- department ID parent_department INTEGER REFERENCES department, -- upper department ID name TEXT -- department name ); INSERT INTO department (id, parent_department, "name") VALUES (0, NULL, 'ROOT'), (1, 0, 'A'), (2, 1, 'B'), (3, 2, 'C'), (4, 2, 'D'), (5, 0, 'E'), (6, 4, 'F'), (7, 5, 'G');부서 구조:ROOT-+->A-+->B-+->C | | | +->D-+->F +->E-+->G A의 하위 부서를 추출, 다음과 같은 재귀 쿼리를 사용할 수 있습니다.WITH RECURSIVE subdepartment AS ( -- non-recursive term SELECT * FROM department WHERE name = 'A' UNION ALL -- recursive term SELECT d.* FROM department AS d JOIN subdepartment AS sd ON (d.parent_department = sd.id) ) SELECT * FROM subdepartment ORDER BY name;위의 쿼리는 다음과 같이 설명할 수 있습니다.중간 테이블(Intermediate table), 작업 테이블(work table), 결과 테이블(result table)이 있습니다.초기화비재귀 구간을 실행 (SELECT * FROM department WHERE name = ‘A’)ResultTable = WorkTable = (‘A’) 결과 테이블과 작업 테이블에 결과를 배치합니다.IntermediateTable = () 중간 테이블을 비웁니다.재귀 쿼리 실행(SELECT d.* FROM WT AS d JOIN subdepartment AS sd ON d.parent_department = sd.id) 하위 부서와 작업 테이블을 바꾸고, 재귀 구간을 실행합니다.중간 테이블에 쿼리 결과를 할당합니다.결과 테이블 및 작업 테이블에 중간테이블 추가합니다.중간 테이블을 비웁니다.재귀가 끝났는지 확인2번 과정의 중간테이블이 비어 있으면 재귀의 실행이 종료되고, 결과 테이블은 반환됩니다.중간테이블이 비어 있지 않으면 다시 2번의 과정으로 돌아갑니다.“subdepartment”는 재귀 표현을 포함하고 있는 CTE입니다. 먼저 비재귀항이 평가되고, 다음 재귀항이 평가됩니다. 재귀항은 평가하고 처리하는 데이터가 없을 때까지 결과가 반복적으로 이전 결과에 추가됩니다. 끝으로 마지막 SELECT가 실행되고 데이터는 결과 집합에서 추출됩니다.CTE의 한계점SEARCH 및 CYCLE 절은 구현되지 않습니다.상호 재귀는 허용되지 않습니다.UNION ALL의 마지막 SELECT만 재귀 이름을 포함할 수 있습니다.재귀와 재귀스캔(RecursiveScan) 계획의 비용은 항상 0입니다sqlalchemy 로 변환sqlalchemy 에서 필요한 모듈들을 불러옵니다.from sqlalchemy import Table, Column, Text, Integer, MetaData, select metadata = MetaData() department 테이블을 정의합니다.department = Table('department', metadata, Column('id',Integer), Column('parent_department',Integer), Column('name',Text)) WITH 절부터 시작되는 CTE 부분의 비재귀항을 subdepartment로 만듭니다. 재귀 사용을 위해 .cte( recursive=True) 부분을 붙여줍니다.subdepartment = select([ department.c.id, department.c.parent_department, department.c.name]).where(department.c.name == 'A') \ .cte(recursive=True) department 와 subdepartment 에 각각 alias를 붙여줍니다.subd_alias = subdepartment.alias() department_alias = department.alias() CTE 부분의 재귀항과 비재귀 항을 union all 해주는 subdepartment를 만듭니다. (이 부분이 postgresql 예제 쿼리에서 봤던 WITH RECURSIVE subdepartment 전체를 나타내는 부분이라 할 수 있습니다.)subdepartment = subdepartment.union_all( select([ department_alias.c.id, department_alias.c.parent_department, department_alias.c.name]) \ .where(department_alias.c.parent_department == subd_alias.c.id)) 마지막으로 결과 쿼리를 출력하기 위한 statement를 만듭니다.statement = select([ subdepartment.c.id, subdepartment.c.parent_department, subdepartment.c.name]).order_by(subdepartment.c.name) 원문: CTEReadme참조: 공통 테이블 식 사용 ,공통 테이블 식을 사용하는 재귀 쿼리#스포카 #개발 #개발자 #서버개발 #개발팀 #꿀팁 #인사이트 #조언
조회수 2850

iOS 개발을 위한 11가지 노하우

Overview기고 제안을 받자마자 iOS 개발을 시작했을 때가 떠올랐습니다. 신대륙을 마주한 것 같았던 그때의 기분을 아직도 잊지 못하기 때문입니다. 당시까지만 해도 Android 개발만 했기 때문에 iOS는 그야말로 미지의 영역이었습니다. 게다가 개발을 시작하려고 조심스럽게 첫 발을 내딛은 순간, 입이 떡 벌어질 수밖에 없었죠.“이렇게 느린 IDE가 있다니…““개발자 프로그램이 뭐 이렇게 비싸?”XCodeXCode는 그동안 접했던 IDE 중에서도 가장 최악이었고, 개발자 프로그램 등록은 13만 원 상당의 비용을 지불해야 했습니다. 가장 중요한 건 맥 컴퓨터(Macintosh)를 보유해야만 했죠. 처음 개발을 시작하려니 넘어야 할 산이 매우 많았습니다. 맞습니다. 팜므파탈의 대명사 마타하리(Mata Hari)처럼 iOS 개발은 밀당과도 같습니다. 분명 매력적인 일이지만 XCode와 개발자 프로그램 등록은 빙산의 일각이기 때문입니다. iOS는 곳곳에 구덩이를 파고 초보 개발자들을 집어삼킬 준비를 하고있습니다. (예를 들면 리소스를 묶어놓은 R.java 파일 같은 레퍼런스가 없습니다. 흑.)그래서 준비했습니다. 수많은 초보 개발자들이 iOS의 구덩이를 피해갈 수 있는 팁을 말이죠.iOS의 구덩이를 피하는 11가지 방법1.비싼 맥(Macintosh)을 사세요.iOS 개발자에게 MacOS는 필수입니다. XCode가 MacOS만 지원하기 때문입니다. 오픈 소스로 공개된 Swift에는 제약이 없지만 XCode는 MacOS에서만 동작하는 제약이 있습니다. 따라서 맥은 iOS 개발자에게 가장 필요한 준비물입니다. 게다가 하드웨어 리소스를 많이 사용하는 XCode 탓에 더 크고, 더 비싸고, 더 아름다운 맥을 구매하셔야 합니다. Macbook이나 Macbook Air 모두 추천하지 않습니다. 15형 Macbook Pro 모델을 비롯해, Mac Pro나 iMac Pro 등의 고급 모델을 사용하면.. 개발이 잘 됩니다.2.돈을 내세요.iOS를 개발하려면 가장 먼저 Apple Developer Portal에서 연 129,000원의 개발자 프로그램에 등록해야 합니다. XCode를 사용해서 코드만 볼 것이라면 문제가 되지 않지만, 디바이스에 앱을 설치하고, 테스트하며, AppStore에 배포할 거라면 반드시 구매해야 합니다. 이 계정은 앞서 말한 것처럼 1년이 지나면 다시 구매해야 합니다. 만약 기업 개발자로 등록하려면 Enterprise Program이 따로 준비되어 있습니다. 기업을 위해 특화된 In-House 배포 등의 이점이 있습니다. 구매해야할 것이 꽤 많죠? 이제 익숙해져야 합니다.3.XCode를 설치하세요.XCode는 Mac App Store에서 설치할 수 있습니다. 용량이 크기 때문에 설치하기 전에 하드디스크 저장공간부터 확인하는 것이 좋습니다. 처음 실행하면 추가 컴포넌트를 다운로드하는 과정이 실행되고, 그 이후에 XCode를 사용할 수 있습니다. XCode와 관련된 자세한 내용은 아래에서 자세하게 다루겠습니다.4.어려운 것에 대비하세요.1)인증서‘들’XCode 설치 이후에도 몇 가지를 발급 받고, 셋업해야 합니다. 방 탈출 게임처럼 한 단계 한 단계 거치는 과정이 필요합니다. 첫 번째로 인증서‘들’을 발급받아야 합니다. 애플을 대신해 앱을 설치하고, 배포할 수 있는 권한을 위임 받는 과정입니다. 이 인증서들은 Apple Developer Portal의 ‘Certificates, IDS & Profiles’ 항목에서 발급 받을 수 있으며, MacOS의 키체인 앱을 이용해 개인 키를 생성하는 방식으로도 방식으로 발급 받을 수 있습니다. 2)디바이스 등록디바이스-iOS-에 개발한 앱을 설치하려면 애플 개발자 계정에 개발용 디바이스를 등록해야 합니다. 이 과정은 XCode에 신규 디바이스를 연결하고, 빌드 및 배포를 할 때 XCode가 알아서 합니다. 만약 디바이스를 보유하고 있지 않은 상황이라면 해당 디바이스의 UUID를 받아서 개발자 포털에 직접 등록할 수도 있습니다. 3)Bundle IDBundle ID는, 앱의 고유한 ID입니다. iOS가 앱을 식별할 때 사용하는 식별자이며, 보통 ‘com.companyname.appname’ 의 형식으로 회사나 개인의 도메인을 거꾸로 쓰는 것이 보편적입니다. 하지만 Bundle ID는 어디까지나 개발자가 결정하는 영역이므로 인스턴스 이름 지정하듯이 자신만의 고유한 방법을 사용해서 Bundle ID를 지정해도 문제가 없습니다. 4)Provisioning ProfileProvisioning Profile은 디바이스 정보와 앱 정보, 인증서 정보를 매핑해주는 Profile입니다. 최신 XCode에서는 이 Provisioning Profile을 자동으로 관리해주기 때문에 따로 신경쓰지 않아도 좋습니다.5.개발자 포럼에 질문하거나, StackOverflow에 질문하거나!질문하는 사람은 아름답습니다. 궁금하거나, 잘 안 풀리는 코드는 개발자 포럼에서 질문할 수 있습니다. 대신 영어 실력이 좋아야 합니다.크게 기대는 하지 않는 것이 좋습니다. 등록된 discussion에 대한 답글들이 ‘나도 같은 상황이다’, ‘나도 궁금한 점이다’ 등의 다른 개발자들의 답변 정도가 일반적이기 때문이죠.그들의 답변...저는 개발자 포럼보다 StackOverflow를 더 선호합니다. 참여하는 개발자 규모가 다르기 때문에 보다 양질의 정보를 빠르게 찾을 수 있습니다. (하지만 허위 정보도 존재합니다.) Vote 시스템으로 신뢰 높은 정보를 필터링할 수 있으나, 어떤 정보를 선택할지는 당신의 몫입니다.6. iTunesConnect와 친하게 지내세요.앱을 개발했다면, iTunesConnect를 통해 앱을 전 세계의 사용자들에게 배포할 수 있습니다. iTunesConnect는 iOS용으로 개발된 바이너리를 배포하는 등 앱 배포/테스트와 관련된 전반적인 사항들을 관리할 수 있는 포털입니다. AppStore에서 앱을 판매하려면 이 iTunesConnect를 통해 애플과 계약을 해야만 가능합니다. 출시할 앱을 등록하기도 하고, 앱의 사용자들이 어떤 경향을 보이는지 Trend Analysis를 확인할 수도 있습니다.iTunesConnectiTunesConnect에는 다양한 메뉴들이 있고, 앱을 배포하고 관리하는데 필요한 여러 툴이 있으므로 개발 중에 시선을 환기하고자 한다면 iTunesConnect를 한 바퀴 둘러보는 것도 좋습니다. 언젠가는 다 사용하게 될 테니까요.7.앱 개발을 마쳐도 XCode를 사용하세요.앱을 개발하고 iTunesConnect에 업로드하려면, XCode를 통해 간접적으로 바이너리를 업로드하게 됩니다. 서드파티 앱을 사용할 수도 있지만, 제가 주로 많이 사용하는 방식은 XCode입니다. 소스코드가 준비되었다면, XCode 메뉴의 Product > Archive 메뉴를 선택해 XCode가 배포용 앱을 빌드합니다. 빌드가 완료되면, 자동으로 Organizer 창이 열리면서 앱을 업로드할 수 있게 되죠. 이 때 미리 구매한 개발자 계정의 인증서가 준비되어 있어야 합니다. 모든 준비가 완료되고 아카이빙이 완료되면, Organizer의 Archives 탭에서 우측단의 ‘Upload to App Store…’ 버튼으로 바이너리 업로드를 진행할 수 있습니다.8.배포 전에 시험비행을 해봅시다.앱을 개발했다면, 테스트플라이트(TestFlight)를 통해 실제로 앱을 배포하기 전 ‘시험비행’을 할 수 있습니다. iTunesConnect에 관련 테스터들을 등록하고, 등록된 사용자들을 대상으로 미리 앱을 테스트할 수 있도록 요청하는 것이죠. 이 테스트플라이트에 배포된 바이너리를 그대로 AppStore에 배포하게 되므로, 테스트용으로 유용합니다.TestFlight테스트플라이트는 원래 iOS 배포 관리 솔루션을 제공하는 업체였지만 지금은 애플이 인수해 iTunesConnect에서 관리하도록 제공하고 있습니다.9.앱이 죽는다면 Organizer로 확인하세요.iOS는 충돌보고 Crash Report를 Organizer를 통해 오류를 확인합니다. 앱을 설치한 사용자가 동의하면 XCode는 iOS가 앱을 실행하면서 발생한 Crash Report를 애플에 자동으로 업로드합니다. 업로드된 Crash Report들은 XCode의 Organizer를 통해 다운로드하고, 확인할 수 있습니다. Organizer는 XCode > Window > Organizer 항목에서 실행하세요.Organizer와 Crash ReportCrash Report는 Organizer의 상단 Crashes 탭에서 확인이 가능합니다. 또 현재 보고 있는 Crash Report의 어느 부분에서 오류가 발생했는지 알고 싶다면 우측단의 ‘Open in Porject…’ 버튼을 눌러보면 됩니다.10.내 친구 XCode최근 XCode는 메이저 업데이트를 통해 사용성과 퍼포먼스를 향상시켰습니다. 하지만 이만큼 무겁고 느린 통합개발툴 IDE는 이클립스(Eclipse) 이후에 처음입니다. 안드로이드의 경우 IntelliJ 기반의 Android Studio로 쾌적한 개발환경을 제공하고 있는 반면, XCode의 업데이트는 퍼포먼스나 사용성 개선보다는 Swift의 메이저 버전 반영에 더 급급한 느낌입니다. (업데이트 때마다 속지만 ‘혹시 이번에는..’하고 또 속아 넘어갑니다.) XCode 사용을 위한 네 가지 팁을 소개합니다.1)XCode는 모노로그입니다.XCode는 로그를 따로 ‘예쁘게’ 볼 수 없습니다. 검은 화면에 흰 로그가 정리되지 않은 상태로 마구마구 출력됩니다. 개발자들에게는 쥐약같은 상황이죠. 이런 불편한 로그 출력 방식 때문에 저는 별도의 GlobalLogger 모듈을 작성해서 다음과 같은 스타일로 로그를 출력하도록 하고 있습니다.$$ BrandiLogger Error Log ##MESSAGE: Initial Parameter is not exist. ##LOCATION: BRLogPringer.swift @Line: 122 2)iOS개발자를 위한 휴식시간, 빌드 타임XCode의 빌드 타임은 개발자에겐 기나긴 휴식 시간입니다. 소스가 비대해질수록 퍼포먼스는 떨어지며, 담배 한 대를 태우고, 화장실에서 손을 씻고 들어와도 빌드가 절반도 안 된 상황을 마주할 겁니다. 빌드 타임을 줄이고자 구글링을 하면 몇 가지 팁을 발견할 수 있는데, 특히 빌드 타임을 가장 많이 단축할 수 있는 방법이 있습니다.짜잔! 공개합니다!먼저, 프로젝트 셋팅의 ‘Build Settings’ 항목에서 ‘Optimization Level’을 검색합니다. ‘Swift Compiler - Code Generation’ 항목을 찾을 수 있는데요. 여기서 Optimization Level의 Debug 항목을 ‘None’으로 설정하면, 빌드시간이 엄청나게 줄어든 것을 확인할 수 있습니다. Brandi iOS 버전의 소스코드는 원래 컴파일에 7분 이상이 소요되었지만, Optimization Level을 변경한 후 1분 내외로 단축되었습니다. Optimization Setting을 변경할 때는 꼭 Debug 항목만 변경하고, Release 버전은 기존 설정을 유지하는 것이 좋습니다. 그래야 빌드 과정에서의 버그를 막을 수 있기 때문이죠. 만약 이 설정으로 개발하던 도중 소스가 충돌되면 Command+Shift+K 단축키를 눌러 소스를 한 번 클린하고, 재빌드하세요. 충돌이 사라지는 경우가 많습니다. 빠른 빌드를 위해 종종 감수해야 하는 부분이기도 합니다. 3)Derived Data빌드가 자꾸 안되고 꼬일 때는 Derived Data 폴더를 삭제 해 보세요. Derived Data 폴더는 XCode > File > Project Settings(Workspace Settings) 항목에서 ‘Derived Data’ 항목 아래의 폴더 경로에서 접근할 수 있습니다. Derived Data 접근 경로Derived Data 폴더를 삭제하면 거짓말처럼 빌드 오류가 사라지는 기적을 만날 수 있습니다. 4)CocoaPods‘바퀴를 두 번 발명할 필요는 없다’는 격언이 있습니다. 이것을 개발에 적용하면 ‘잘 만들어진 라이브러리를 사용하라’ 정도가 되겠습니다. 개발자의 개발 시간을 현저하게 단축시키는 오픈소스 라이브러리. 이것들을 간편하게 사용하는 방식이 iOS에도 존재하는데, 바로 CocoaPods입니다. 프로젝트 Root 폴더에 Podfile을 생성하고, 원하는 오픈소스 라이브러리들을 명시한 후에 ‘pod install’ 명령어를 입력해주면….CocoaPods오픈소스 라이브러리가 설치되었습니다. 귀찮은 소스 다운로드와 임포트 과정을 거치지 않아도 됩니다. CocoaPods 설치와 사용에 관한 글은 구글링으로 쉽게 찾을 수 있습니다. 꼭 사용하길 권합니다.Mac App Store에서의 XCode 평점XCode는 느리고 불편합니다. 숨겨진 편의기능도 많지만 고질적인 빌드 문제와 사용성 문제를 마주하면 높은 평점을 줄 수가 없습니다. 그런데, 저만 그렇게 생각하진 않더라고요.(위 스크린샷 참조) XCode의 사용법은 기회가 되면 따로 정리하겠습니다.11.어떤 경우에도 대응할 수 있는 화면 구성을 원한다면, AutoLayoutiOS를 사용하면서, 금융권이나 쇼핑 앱들을 사용하다 보면 이런 상황이 발생합니다. 금융권 앱. 화면에 꽉 차지 않는 레이아웃 혹은 비정상적으로 커진 글씨본래 iOS는 단일 디바이스를 지향하는 플랫폼이었습니다. 아이폰 시리즈도 해상도가 변하지 않았기 때문에, 디바이스 종류가 많은 안드로이드처럼 다양한 스크린 사이즈를 지원할 필요가 없었습니다. 하지만 이제는 iPhone SE, iPhone 8, iPhone 8 Plus의 해상도에 iPhone X의 해상도까지 더해지면서 그야말로 ‘해상도 춘추전국시대’가 되었습니다.이런 다양한 해상도를 모두 지원하는 레이아웃을 구성하려면, iOS에서는 AutoLayout을 사용해야 합니다. AutoLayout은 Xib Editor에서 AutoLayout을 활성화하는 방식으로 사용할 수 있습니다. 거기에 한 가지 덧붙이면 Layout Constraints라는 개념도 있습니다. 레이아웃에 조건을 주는 방식입니다. 예를 들어 ‘어떤 해상도에서든 이 컴포넌트는 왼쪽 끝으로부터 10Point의 여백을 가지도록 한다’ 라는 식이죠. AutoLayout, Layout Constraint이 Layout Constraint를 이용하면 짧은 시간 안에 다양한 해상도를 지원하는 레이아웃을 쉽게 만들 수 있습니다. 가히 AutoLayout의 꽃입니다.ConclusionXCode/iOS 개발과 관련된 팁은 대부분 구글링으로 찾을 수 있습니다. 다룰 내용이 많지만 초보 iOS개발자들이 당황할 수 있는 내용을 중심으로 글을 썼습니다. 소소한 이야기지만, 분명 도움을 받을 수 있을 겁니다.글이정환 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #iOS #개발기 #업무환경 #인사이트 #경험공유 
조회수 1077

2016, 개발자의 Life.. 꿈...#1

주변 개발자들의 삶이 매우 행복을 추구하는 삶으로 변해가고 있다는 것을 느낀다. 주변의 개발자들의 모습을 몇 가지 정리해보자. 이를 '지속 개발을 위한 개발자 Life 스타일'이라고 정의하겠다.개발자#A10년 넘게 개발하던 패키지를 기반으로 필요 기능을 최소화하여 1인 개발기업에 성공하였고 제주도로 내려가서 지역에 속한 분들과 호흡하는 삶을 추구하면서도 소프트웨어 개발의 핵심을 잃지 않았다. 정말, MVP 기능에 최대한 집중하면서 필요한 시장 영역을 더 확대하지 않고, 소프트웨어를 개발하고 있는 개발자와 해당 소프트웨어를 사용하는 고객과 시장에 대해서 같이 합리적으로 지속할 수 있는 지속할 수 있는 소프트웨어 개발의 삶을 이루었다.그리고, 그러한 Life환경을 주변에 전파하면서 불과 얼마 전 또 한 명의 구 루급 개발자에게 비슷한 삶의 길을 가르쳐준다. 정말 부러운 개발자들...개발자#B복잡한 업무나 더 많은 보수를 위해서 더 좋은 회사를 찾기보다는 삶이 존재하는 근무시간을 위해서 재택근무를 찾고 있다. 비용도 최대한 낮추면서 생활을 위한 회사를 찾아다니고 있다. 아무래도, 외국계 개발회사를 선택할 것 같다.개발자#C오픈소스 진형에서 인정받는 개발자이다. 본인이 원하는 오픈소스 프로젝트를 추진하는 것을 보장받고 외국계 기업의 원격근무를 선택했다. 보수도 나쁘지 않고, 근무시간은 알아서 하는 것이지만, 원격으로 일하는 것이기 때문에 '능력'을 보여주기 위해 더 많은 시간을 소프트웨어 개발에 투자한다. 굳이, 서울 시내에 있을 필요가 없기 때문에 외각으로 집도 옮겼다.개발자#D일부러, 실리콘 벨리의 스타트업을 선택했다. 조만간 상장 예정인데 매우 큰 혜택을 받을 것 같다. 그 역시 지속 개발이 가능한 삶을 추구한다.2016년 올 초의 개발자 트렌드는 '지속 개발을 위한 Life'를 지향하는 개발자들이 늘어났다고 평가해본다.우리 모두 지속개발이 가능한 삶을 지향해 보는 것은 어떨까나...
조회수 1048

컴공생의 AI 스쿨 필기 노트 ⑥인공신경망

인공지능, 머신러닝, 딥러닝이번 6주차 AI 스쿨에서는 딥러닝의 가장 기초적인 부분을 배웠어요. 인공지능과 머신러닝, 그리고 딥러닝을 많이 들어보긴 했는데 이 셋의 차이는 무엇일까요?인공지능이라는 개념은 1956년 미국 다트머스 대학에 있던 존 매카시 교수가 개최한 다트머스 회의에서 처음 등장했고 최근 몇 년 사이 폭발적으로 성장하고 있는 중이에요. 1956년 당시 인공지능의 선구자들이 꿈꾼 것은 최종적으로 '인간의 지능과 유사한 특성을 가진 복잡한 컴퓨터'를 제작하는 것이었죠. 이렇듯 인간의 감각, 사고력을 지닌 채 인간처럼 생각하는 것을 인공지능이라고 해요.인공지능은 위 세 개념 중 가장 큰 개념이에요. 머신러닝은 일반적으로 사람들이 이야기하는 인공지능, 즉 머신러닝에 기반한 인공지능을 말하는데요. 인공지능을 구현하는 구체적인 접근 방식이라고 할 수 있어요.머신러닝에는 linear regression, logistic regression 등의 여러 알고리즘이 있는데요.  그중 학습에 사용되는 모델을 딥러닝이라고 해요. 즉 딥러닝은 완전한 머신러닝을 실현하는 기능이라고 볼 수 있어요. 이러한 딥러닝의 등장으로 인해 머신러닝의 실용성은 강화됐고 인공지능의 영역은 확장됐다고 해요.인공 신경망(Neural Network)오늘 수업의 핵심인 인공 신경망(Neural Network)은 어떻게 만들어졌을까요?뉴런의 구조이것은 우리 몸에 존재하는 신경세포인 뉴런이에요. 뉴런은 전기적인 신호를 전달하는 특이한 세포인데 뇌는 뉴런의 집합체라고 할 수 있어요. 뉴런은 수상 돌기(dendrites, input)에서 신호를 받아들이고 축색 돌기(axon terminals, output)에서 신호를 전송해요. 신호가 전달되기 위해서는 일정 기준(임곗값 : threshold) 이상의 전기 신호가 존재해야 해요. 이 신호들의 전달을 통해서 정보를 전송하고 저장해요.이런 신경세포로 이뤄진 신경망 시스템을 위의 그림처럼 표현할 수 있어요. 이처럼 인공신경망은 사람 몸속의 신경들을 모방해서 만든 시스템이에요.위의 식처럼 뉴런을 수학적으로 표현할 수 있는데요. 입력 값들(X)에 가중치를 두어(W) 값 (f(x))을 구하고 그 값과 임계치와의 관계를 활성함수(active function)*로 판단하여 결괏값을 출력하게 돼요.( * 활성함수는 인공신경망의 개별 뉴런에 들어오는 입력신호의 총합을 출력 신호로 변환하는 함수로 비선형 함수(non-linear function)를 씁니다.**)이때 활성함수는 뉴런에서 임곗값을 넘었을 때만 출력하는 부분을 표현한 것으로 sigmoid 함수, Relu 함수 등 여러 방식이 있어요.인공 신경망의 구조인공 신경망 구조는 위의 그림처럼 나타낼 수 있어요. 인공 신경망 구조는 입력층(input layer), 은닉층(hidden layer), 출력층(output layer)으로 이루어져 있어요. 위의 그림은 그 구조에 의해 3-layer Neural Network 또는 2-hidden-layer Neural Network라 부를 수 있는데요. 3-layer Neural Network는 3개의 층을 가지는 인공신경망이라는 뜻이고, 위 그림에서는 은닉층1, 은닉층2, 출력층이 해당되겠죠. 인공 신경망에 입력층과 출력층은 항상 존재하기 때문에 은닉층의 개수만을 고려하여 부르기도 해요. 위 그림에서는 은닉층이 2개 있기 때문에 2-hidden-layer Neural Network라고 부를 수 있어요. 전파(Propagation)이번에는 실제로 학습하는 과정인 인공신경망의 알고리즘에 대해 알아볼게요. 순전파(Forward Propagation)와 역전파(Backward Propagation)가 있어요.순전파는 입력값에서 출력값으로 가중치를 업데이트를 하고 활성화 함수를 통해서 결괏값을 가져오는 것을 말해요. 인공신경망이 설계된 정방향(input → hidden → output)으로 데이터가 흘러가기 때문에 순전파라고 해요. 말 그대로 입력값을 앞쪽으로 보낸다고 생각하면 돼요.역전파는 출력값을 통해서 역으로 입력값 방향으로 오차를 다시 보내며 가중치를 재 업데이트하는 것이에요. 출력값에서 계산된 오차에 가중치를 사용해 바로 이전 층의 뉴런들이 얼마나 오차에 영향을 미쳤는지 계산해요. 결과에 영향을 많이 미친 뉴런일수록 더 많은 오차를 돌려줘요.개념을 코드에 적용하기NumPy로 구현된 Neural Network(이하 NN)의 작동 방법을 살펴볼게요. NN은 총 2개의 레이어로 이루어져 있어요. 이번 과제에서는 입력 x가 들어왔을 때, 레이블에 따라 예측치가 1로 수렴하는지 알 수 있는 인공신경망을 구현하는 것이 목적이에요.Neural Network다음 코드는 simpleNueralNet() 클래스를 나타내는 코드예요. simpleNueralNet()은 두 개의 레이어로 구성된 NN이에요.N, D_in, H, D_out = 64, 1000, 100, 10- N은 batch size, 즉 한 번에 처리할 수 있는 데이터 사이즈를 말해요. - D_in은 입력값 차원에 쓰이는 값으로 1000을 할당해요.- H는 은닉층 차원에 쓰이는 값으로 100을 할당해요.- D_out은 출력값 차원에 쓰이는 값으로 10을 할당해요.아래 코드를 통해서 랜덤 입력과 출력 데이터를 만들어요.x = np.zeros((N, D_in))     #1  x.fill(0.025)                         #2y = np.ones((N, D_out))   #31. np.zeros() 함수를 사용하여 (64, 1000)의 차원을 갖는 0인 행렬을 만들어요.2. fill() 함수를 통해 x 안의 모든 0을 0.025로 바꿔요.3. np.zeros() 함수를 사용해 (64, 10)의 차원을 갖는 0인 행렬을 만들어요.아래는 랜덤 값을 갖는 가중치(weight)들을 초기화하는 코드예요. w1은 1000, 100 차원의 랜덤 값을 갖는 행렬로, w2는 100, 10차원의 랜덤 값을 갖는 행렬로 만들어요.w1 = np.random.randn(D_in, H)   w2 = np.random.randn(H, D_out)learning_rate는 학습 속도를 의미해요. 아래는 단계별로 움직이는 학습 속도를 1e-6으로 정의하는 코드예요.learning_rate = 1e-6이제 5000번의 순전파를 할 거예요.h = x.dot(w1)     h_relu = relu(h)  y_pred = h_relu.dot(w2)h는 은닉층에 전달할 값이에요. x와 w1을 행렬곱한 값을 가져요.활성 함수 relu에 h를 넣어서 계산해요.y_pred는 예상되는 출력값이에요. relu로 계산된 h_relu와 가중치 w2를 행렬곱한 값이에요.아래는 순전파로 얻은 y_pred에서 진짜 y를 뺀 값을 제곱한 것의 합을 구해 손실 값(loss)을 구하는 코드예요. print(loss) 코드로 손실을 확인할 수 있어요.loss = np.square(y_pred - y).sum()순전파 후 역전파를 이용해 손실에 대한 가중치 w1과 w2의 gradients를 계산하여 update 할 거예요.grad_y_pred = 2.0 * (y_pred - y)              #1grad_w2 = h_relu.T.dot(grad_y_pred)    #2grad_h_relu = grad_y_pred.dot(w2.T)    #3grad_h = grad_h_relu.copy()                    #4grad_h[h < 0>grad_w1 = x.T.dot(grad_h)                         #61. 순전파로 얻은 y_pred에서 진짜 y값을 뺀 값에 2.0을 곱하여 grad_y_pred를 구해요.2. grad_w2는 순전파에서 y_pred = h_relu.dot(w2) 식을 사용했으므로  h_relu.T.dot(grad_y_pred) 로 구해요. h_relu가 반대로 곱해지기 때문에 T를 이용하여 shape을 바꿔줘야 해요.3. grad_h_relu는 방금 위에서 사용한 y_pred = h_relu.dot(w2)을 이용하여 grad_y_pred.dot(w2.T) 로 구해요. 이번에는 w2 shape의 반대를 grad_y_pred에 곱해줘야 해요.4. 순전파에서 h_relu = relu(h)였는데요. 역전파에선 grad_h와 grad_h_relu가 같기 때문에 copy() 함수로 그대로 복사해요!5. 0보다 작은 h는 0으로 만들어요.6. 가중치 w1의 값인 grad_w1은 순전파의 h = x.dot(w1)와 반대로 x.T.doT(grad_h) 곱해요. 역전파는 순전파의 식에서 이항한다고 생각하면 조금 더 쉽게 이해할 수 있을 것 같아요. 이항한 값은 .T를 붙여서 표현한다고 생각하면 될 것 같아요.아래는 가중치를 재업데이트하는 코드예요.w1 -= learning_rate * grad_w1 w2 -= learning_rate * grad_w2 과제1을 통하여 NN을 알아보았는데요. 복잡하지만 순전파와 역전파를 알고 있다면 많이 어렵지는 않은 것 같아요. 과제 2는 정확도를 95% 이상으로 만들어보는 과제인데 여러 가지 방법을 동원해서 풀어보는데 생각보다 쉽지가 않아요. ^^;이번 수업시간에 배운 딥러닝의 기초인 신경망은 굉장히 중요한 개념이라고 해요. 신경망을 기반으로 한 딥러닝을 강화하여 안면인식을 가능하게 하거나 저장된 데이터를 정확하게 인식하고 분류할 수 있는 기기들도 만들어지고 있어요. 이처럼 AI는 점진적으로 활용 범위가 넓어지고 있기 때문에 이 수업을 통해 쌓은 AI 지식을 마음껏 뽐낼 수 있는 날이 왔으면 좋겠어요!** 왜 활성함수로 비선형 함수를 쓸까요?선형함수인 h(x)=cx를 활성함수로 사용한 3-layer 네트워크를 생각해봐요. 이를 식으로 나타내면 y(x) = h(h(h(x)))가 되는데요.  이는 y(x) = c3x와 같습니다.  이렇게 활성함수로 선형함수를 사용하면 은닉층을 사용하는 이점이 없어요.* 이 글은 AI스쿨 - 인공지능 R&D 실무자 양성과정 6주차 수업에 대해 수강생 최유진님이 작성하신 수업 후기입니다.
조회수 3550

코인원 개발자는 어떻게 일할까?

코인원의 파이콘 한국 2018 참여기 그 두번째 이야기!코인원의 핵심, 코인원의 자랑 ‘코인원 개발자’들에 대한 이야기를 나눠보려 합니다.지금의 코인원이 있을 수 있는 이유는 바로 더 좋은 프로덕트를 만들어내기 위해 치열하게 고민하는 개발 크루들의 노력이 있었기 때문입니다.코인원은 지난 파이콘 한국 2018 ‘열린공간(Open Speak Talking)’ 세션에 참여했습니다. 이 시간을 통해 그동안 코인원 개발 크루들이 축적한 지식과 경험 그리고 노하우를 공유했어요. 파이콘이 개발자들을 위한 행사인만큼, 코인원의 개발문화와 환경, 채용 원칙에 대한 심도깊은 이야기가 오고갔답니다.그래서 예고했던대로 코인원 개발자들의 ‘Mini Interview’를 통해 개발 크루들은 기술본부를 어떻게 만들어나가고 있는지 자세히 알려드릴게요 :-)'파이콘 한국 2018' 후기 1탄 현장스케치▼코인원X'파이콘 한국 2018' 현장스케치!파이썬 개발자들의 즐거운 축제, ‘파이콘 한국 2018’이 지난 19일 성황리에 막을 내렸습니다. 이번 행사...blog.naver.com지난 8월 19일 진행된 파이콘 열린공간 현장, Open Speak Talking!진우님(CTO)을 집중 심문하고 있는 피플팀 수장 대경님코인원 기술본부는 어떻게 구성되어 있나요?진우님(CTO) : 안녕하세요, 코인원 CTO(Chief Technical Officer, 최고기술책임자) 이진우 입니다. 현재 코인원 기술본부는 총 8개의 팀으로 이루어져 있는데요. Core팀, Web팀, API팀, APP팀, QA팀, SRE팀, 데이터팀, 기술연구팀으로 나뉘어진답니다. 코인원 기술본부는 사용자에게 편리한 서비스를 제공하기 위해 프로덕트를 만들어나가고 있어요. 먼저, 사용자에게 직접적으로 보여지는 화면인 프론트엔드를 책임지는 ‘Web팀과 APP팀’ 그리고 사용자에게 보이지 않지만 시스템의 안쪽에서 수행되는 백엔드를 책임지며 프론트엔드에서 필요로하는 결과를 제공하는 ‘Core팀, API팀, QA팀, SRE팀, 데이터팀, 기술연구팀’이 인터렉티브하게 일하고 있습니다.저희는 암호화폐 거래소 코인원을 더욱 더 잘 구축하고, 개선하고, 안전하게 운영하는 것을 목표로 삼고 있어요. 또한 개발 뿐만 아니라, 지속적인 블록체인 연구를 통해 거래소에 최신 기술 트렌드를 반영할 수 있도록 항상 고민하죠.파이콘의 질문왕, 웹팀의 경화님 :)저 멍때리는거 아니에요, OST에 집중하고 있는거에요. (feat. 새로찬가로찬님)눈감은거아니에요, 뜬거에요. (feat. 킹갓제너럴대현님)코인원 개발자들은 어떻게 일하나요?경화님 (Web developer) : 코인원 개발자들은 서로 어떤 업무를 하고 있는지 눈으로 트래킹 할 수 있고, 투명하게 업무를 공유할 수 있는 개발환경을 만들고 있어요. 저희는 협업툴로 Jira와 Confluence를 사용하고 있습니다. 협업툴로 업무의 효율성을 높이면서 새로운 개발업무에 집중하는데 많은 도움이 되고 있어요. 또한 협업툴 이외에도 새로운 기술 도입에 긍정적이라 자기주도하에 여러가지 기술을 실무에 적용해볼 수 있다는 점이 매력적이죠.새로찬님 (Engineer) : 주어진 요구사항에 맞게 그대로 개발하기 보다는 요구사항의 필요성에 대해 공감하고 더 좋은 방향으로 만들 수 있도록 기획, 디자인, 개발 모든 단계에서 능동적으로 의견을 제시합니다. 기술본부에서는 빠르게 변화하는 시장상황에 맞추기 위해 매일 아침마다 PM, 개발자, 디자이너가 모여 *데일리스크럼을 진행하는데요, 서로의 Task나 Project 진행상황을 공유하고 최고의 프로덕트를 사용자에게 전달하기 위해 노력하고 있어요. *데일리스크럼이란? 정해진 시간에 개발크루들이 모여서 어제 했던 일과 오늘의 할 일 등을 공유하고, 다른 개발 크루들이 이야기하는 업무현황을 들으면서 내가 기여할 수 있는 부분과 이슈를 빠르게 파악할 수 있는 자리에요! 대현님 (Engineer) : 서비스를 만드는데 있어 주도적으로 그리고 적극적으로 개발업무를 수행합니다. 예를 들어, 코인원 Live Service에서 Manual하게 처리하고 있었던 이슈들을 자동화하는 프로젝트가 있었는데요. 수동으로 해결할 수 있는 부분이지만, 이를 서비스 기획자분들과 연계해 Task로 만들어 해결방안을 얻을 수 있었습니다. 또한 여기서 그치는게 아니라, 계속해서 코인원 사용자들을 위해 필요한 기능들을 추가하는 프로젝트에 참여하면서 많은 재미를 느꼈죠.왼쪽부터 파이콘의 나이스걸 (윤정님), 개발자 (희수님), ddddeveloper (선우님)개발본부의 공식포즈, 쁘쁘브브브이 종헌님 ㅇ_ㅇV코인원 개발자가 되면 어떤 점들이 좋나요?희수님 (Engineer) : 이전에 경험하지 못했던 거래소 프로덕트를 만들어볼 수 있다는 점이 정말 좋습니다. 저는 원래 암호화폐와 핀테크에 관심이 많았는데요. 코인원에서 거래소 프로덕트를 직접 만들면서 관심 분야에 대해서도 더 많이 알게 되고, 또 이런 서비스를 개발할 때 중요한 것이 무엇인지 고민해보면서 배워가는 것이 정말 많아요. 제가 코인원 합류 이전에 개발한 프로덕트들과는 성향이 많이 달라서 더 재미를 느끼고 있어요!종헌님 (Web developer) : 함께 일하는 모든 개발자 분들이 더 효율적인 개발 프로세스를 만들기 위해 치열하게 고민하는 것을 보면서 매일 놀라고 있어요. 서비스를 개발하며 느끼는 문제점을 도출하면서 치열하게 토론하고, 그 문제들을 해결하기 위한 아이디어들을 직접 시도해 볼 수 있어서 좋아요. 일을 더 효율적으로, 즐겁게 할 수 있는 환경을 만드는 과정이 코인원만의 애자일을 만들어나가는 것 같아 더 열정적으로 일할 수 있는 것 같습니다.선우님 (Web developer) : 많은 사용자들이 직접 이용하는 서비스를 만드는 개발자로서 다양한 문제 상황을 직면하고 해결해 나가며 보고 배우는게 많습니다. 또 코인원 기술본부는 여느 코인원 조직처럼 언제든 자신의 의견을 자유롭게 이야기하는 분위기가 형성돼있어요. 특히 하나의 프로젝트가 끝나면 회고(Retro)를 진행하는데, 프로젝트의 진행과정, 이슈, 결과물을 공유하면서 저 자신을 성장시켜나갈 수 있는 요소들이 많습니다.안녕하세요, 코인원 신입개발자 (a.k.a CTO) 입니다. (인사성 밝음밝음)“코인원에서는 어떤개발자를 원하나요?진우님 (CTO) : 블록체인을 좋아하고, 개발을 좋아하시는 분이라면 언제든지 환영입니다. 코인원 개발 크루들을 생각했을 때 ‘몰입’이라는 단어가 가장 먼저 떠오르는데요. 모두가 마니아적이고 덕후기질이 있어, 자기주도적으로 업무를 하고 적극적으로 개발할 것들을 찾고 실행합니다.  앞으로 코인원 개발 크루로 합류하실 분들 또한, 적극적으로 아이디어를 내고, 그 아이디어를 실현할 수 있도록 프로젝트를 리딩할 수 있는 분이었으면 해요. 물론 개발하는데 있어서는 누구보다 신중한 자세가 필요하겠죠? 누구보다도 내가 짠 개발코드를 꼼꼼하게 검토하고, 표용력이 있어 좋은 아이디어에는 귀 기울일 줄 아는 분들이셨으면 좋겠습니다. 참고로 Node.js, Python, Spring, C#, AngularJS를 업무에 많이 활용하고 있답니다.개발을 사랑하시는 분! 블록체인을 함께 탐험할 준비가 되신 분! 코인원 개발자 채용에 많은 관심 부탁 드립니다.코인원 개발자 채용에 많은 관심 부탁드립니다 :-)지금까지 미니 인터뷰를 통해 코인원 개발 크루들의 이야기를 들어봤습니다:) 블록체인이라는 새로운 기술 영역에서 매일매일 즐겁게 도전하고 있는 코인원 개발팀에 합류하고 싶은 분들은 현재 코인원 개발자 채용이 진행되고 있으니 지금 바로 확인해주세요!#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트 #기업문화 #조직문화 #팀원소개 #인터뷰
조회수 2896

DevOps 팀을 위한 모니터링 팁

다음 중 몇 개나 해당하시나요?1~5명 규모의 작은 개발팀에서 일한다.DevOps 조직이다.우여곡절 끝에 서비스는 런칭했지만, 개발과 동시에 운영을 해야하는 상황이다.서버 인프라 지식이 별로 없다.무중단 서비스 운영 경험이 별로 없다.팀 내에 시스템 엔지니어(SE)와 데이터베이스 전문가(DBA)가 없다.하나라도 해당한다면 이 글이 도움이 될 지도 모릅니다.누구나 쉽고 빠르게 앱을 만들고 서비스를 런칭할 수 있는 시대가 되었지만 문제는 런칭 이후입니다. 런칭 이후에는 고객이 100명이라도 안정적인(High Availability) 서비스를 운영해야 하는 것이 백엔드 개발자의 임무이기 때문입니다.안정적인 서비스를 운영하기 위해서는 체계적인 모니터링 필수라고 하는데 그마저도 쉽지 않습니다. 가장 큰 문제는 (장애가 터지기 전까지) 무엇을 모니터링 해야 하는지조차 모른다는 것이고, 당장 개발해야할 것들이 산더미처럼 쌓여있는데 사람도 부족한 것도 문제입니다.그렇지만 누군가는 해야하는 일입니다. 리디북스 역시 모니터링이 전혀 없던 시절이 있었으나, 크고 작은 실패와 좌절을 겪으며 조금씩 경험을 쌓아가고 있습니다. 이번 글에서는 우리가 모니터링과 관련하여 고민해 온 내용들을 소개해볼까 합니다.어떻게 모니터링할 것인가시스템의 안정성을 높이기 위해 투입해야 하는 노력은 지수적으로 증가합니다. 아래 표에서 보듯이 SLA 를 99.999% 에서 99.9999% 로 높이려고 한다면 1년에 약 5분의 가용시간을 얻을 뿐이지만 이를 위해 수백시간 이상의 노력을 들여야 합니다.가용성연간 장애 시간주간 장애 시간99.995%26.28 분30.24 초99.999%5.26 분6.05 초99.9999%0.525 분0.6048 초완벽함을 추구하면 할 수록 얻을 수 있는 고객 만족은 미미한 것에 비해 이를 위한 개발자의 노력은 기하급수적으로 증가합니다. 따라서, 먼저 대응의 적정선을 찾고 효율적으로 움직이기 위한 계획을 세워야 합니다.리디북스에서는 해야할 일을 4가지로 분류하여 중요한 일부터 처리하는 아이젠하워 매트릭스에서 그 대응 원칙을 차용하였는데, 그 이유는 시사하는 바가 동일하기 때문이었습니다. 즉, 중요한 것은 대부분 긴급하지 않고, 긴급한 것은 대체로 중요하지 않다는 점입니다. 그리고 매트릭스의 두 축은 아래와 같습니다.얼마나 급한가?사무실의 무선 인터넷이 안된다면 서비스에 큰 문제는 아니지만, 당장 해결해야 하는 급한 일입니다. 반대로 백업 스크립트가 며칠째 동작하지 않아서 최근 데이터의 스냅샷이 없다면, 이는 당장 해결할 필요는 없겠지만 매우 중요한 일입니다.그리고 장애란, 단순히 “고장”을 의미하는 것이 아니라 서비스 이용에 지장이 없더라도 어떤 수치나 결과가 예상과 다른 상황을 의미해야 합니다. 예를 들어, 웹서버의 평균 CPU 사용률이 70%가 넘는다거나 네트워크 대역폭을 90% 이상 사용하는 상황은 정상이 아닙니다. 조금만 트래픽이 몰려도 문제가 발생할 가능성이 매우 높기 때문에 잠재적인 장애로 간주해야 합니다.우리는 급한 문제를 우선적으로 처리하는 경향이 있어서, 덜 급하지만 더 중요한 일을 놓치는 경우가 많습니다. 이를 피하려면 장애의 그 심각도에 따라서도 구분해야 합니다.얼마나 심각한가?심각도를 처음부터 너무 상세하게 구분할 필요는 없으며, 크게 서비스 이용에 치명적인 것과 그렇지 않은 것으로 나누어 생각하면 됩니다. “치명적”의 의미는 서비스마다 다를 수 있지만 대개 아래에 해당합니다.사업에 지장을 초래한다.고객을 잃는다.만약 웹페이지의 로딩 속도가 매우 느려서 나쁜 이미지를 준다면 이 역시 치명적일 수 있습니다. 실제로 아마존에서는 로딩 속도가 100ms 지연될 때마다 눈에 띄는 매출 하락이 발생했다는 테스트 결과가 있습니다. 따라서 속도에 대한 매트릭을 모니터링 지표에 추가하는 것은 좋은 선택입니다.이상을 토대로 장애 종류에 따른 대응 원칙을 정리하면 아래와 같습니다. 급함안급함심각함➀ 즉각 대응, 즉각 인지➁ 평소 보완, 항상 경계안심각함➂ 빨리 대응, 최소 대응➃ 대응하지 않기이 중에서 항상 의식하고 놓치지 말아야 하는 것은 안급하지만 잠재적으로 심각한 장애(➁)입니다. 그리고 모니터링은 한 번 시작하게 되면 관리를 위한 비용이 꾸준히 투입되어야 하기 때문에 사소한 문제(➂, ➃)를 굳이 파헤치는 것은 오히려 독이 될 수도 있습니다.모니터링 측면에서 본다면 발생중인 장애는 최대한 빨리 발견하는 것이 중요하며, 잠재적인 장애는 상태의 변화를 최대한 빨리 감지하는 것이 중요합니다. 예를 들어, 디스크의 여유공간은 완전히 바닥나기 전까지 어떠한 경고도 나타나지 않지만 부족한 상황이 발생하면 어떤 부작용이 생길지 예측할 수 없습니다.필수 모니터링 갖추기모니터링을 해야할 대상은 기술 스택과 코드 구현에 따라 달라지겠지만, 빼놓을 수 없는 것들이 몇 가지 있습니다. 리디북스에서는 서버의 프로비저닝과 동시에 아래 내용들을 함께 준비하고 있습니다.1. 리소스 및 시스템 모니터링각종 시스템 리소스 및 하드웨어 상태는 필수 모니터링 대상입니다. 모니터링 툴을 설치해보면 측정해주는 항목들이 너무 많아서 당황스러운 경험을 하게 되는데요. 그 중에서도 우리가 주목하고 있는 항목들은 아래와 같습니다.CPU UsageLoad AverageDisk UsageDisk Utilization (iowait, IOPS)Swap Memory Usage (사용시)Temperature (인프라 직접 구축시)RAID Status (인프라 직접 구축시)S.M.A.R.T Errors (인프라 직접 구축시)이 중 몇가지는 New Relic 에서 무료로 지원하므로 당장 여력이 없다면 이를 이용하는 것도 좋은 방법입니다.클라우드 환경이 아닌 데이터센터에서 인프라를 직접 구축하여 운영하고 있다면 좀 더 많은 노력이 필요합니다. 하드웨어적인 장애를 직접 신경써야 하기 때문입니다. 실제로 팬(fan)이 고장나거나 케이블이 환풍구를 막아서 서버의 온도가 비정상적으로 높아지다가 기기가 오동작하는 어처구니없는 상황도 발생합니다.Disk서버 환경에서 SSD 사용이 점점 대세가 되어가고 있는데, 최근 구글이 공개한 정보에 따르면 SSD에서 배드블럭이 발생하는 일은 매우 흔하며, 시간이 오래될 수록 안정성이 떨어진다고 합니다.따라서 디스크와 관련된 RAID나 S.M.A.R.T 오류는 가능한 빨리 대응해야 합니다. 특히 RAID 장비를 구성할 때에는 같은 공정에서 출하된 같은 벤더의 제품을 일괄적으로 구매해서 사용하기 때문에, 동일한 하드웨어 결함을 지니고 있거나 평균 수명도 비슷하므로 결코 안이하게 대응해서는 안됩니다.리디북스에서는 전자책 원본을 보관하는 스토리지에서 4개의 사본(replica) 중 3개가 연달아 깨지는 끔찍한 사고를 경험한 이후로, 디스크 오류는 1순위로 대응하고 있습니다. 참고로 스토리지 서버를 구축한지 3년째가 되는 해였고, 모두 S사의 제품이었습니다.iowait 은 CPU가 유휴(idle) 상태로 I/O를 대기하는 시간을 나타낸 수치입니다. 이를 통해 현재 시스템이 I/O 병목을 겪고 있는지 판단할 수 있기 때문에 중요합니다. 이 수치가 너무 높다면 블록 디바이스나 네트워크가 너무 느린 상황이거나 포화 상태일 수 있으므로, 더 높은 IOPS 장비로 업그레이드하거나 부하를 분산해야 합니다.단, CPU 성능에 영향을 받는 수치이므로 고성능 CPU를 사용할수록 평균 iowait이 높게 측정됩니다. (따라서 성능을 평가하기 위한 지표로는 IOPS도 함께 분석해야 합니다.)Load AverageLoad Average(평균 부하)는 마치 서버의 종합 성적표 같아서, 이 역시 주목할 필요가 있습니다. Load Average에 변동이 생긴다면 평소와는 다른 처리량(throughput)을 내고 있다는 뜻입니다. 요청량이 증가하여 수치가 올라갔다면 서버 증설과 튜닝에 대비해야 하지만, 그렇지 않다면 어딘가 병목이 발생하여 처리 효율이 낮아졌다는 신호입니다.아직 Load Average를 모니터링하고 있지 않다면 주요 서버군부터 아래 규칙을 참고하여 초기 기준치를 설정하기를 권장합니다. 물론 어디까지나 초기 설정 값이며, 실제 상황에 적합하지 않을 수 있습니다.Warning Level : 0.7 * number of cores Critical Level : 1.0 * number of cores간혹 커널 자체에 문제가 있거나, 커널 모드에서 예외가 발생하는 경우에는 syslogd 데몬이 남기는 로그를 파악해야 합니다. Papertrail, Splunk, Loggly 등의 서비스는 크리티컬 수준 이상의 syslog 에 대해 알림을 설정할 수 있을 뿐 아니라, 텍스트 형태로 남겨지는 모든 로그에 대한 관리를 쉽게 도와줍니다. 비록 유료지만 커널 모니터링 용으로만 사용한다면 비용이 많이 들지 않습니다.2. 응용프로그램 모니터링앱이나 서버에서 발생하는 크래시와 예외를 수집하는 도구 역시 장애 예방에 필수입니다. 해당 기능을 실시간으로 제공하는 다양한 서비스들이 존재하는데 많이 쓰이는 것으로는 Sentry, Rollbar, Airbrake, NewRelic APM 등이 있습니다. 대부분 5분만에 설정이 가능한데다 어느것을 선택하더라도 핵심 기능에는 부족함이 없습니다.단, 현재까지 가성비로는 Sentry가 제일 뛰어납니다. Python의 Flask와 Jinja의 개발자로 유명한 Armin Ronacher가 팀에 합류했기에 발전가능성 측면에서도 많은 기대가 됩니다.Sentry의 실시간 에러 대시보드3. 데이터베이스 모니터링팀에 DBA가 있나요? 모든 서버 개발자들이 인덱스와 스토리지 엔진의 특징에 대해 잘 이해하고, DB를 능숙하게 다루나요? 그것도 아니라면 개발자들이 작성한 모든 스키마와 쿼리에 대한 검증 과정을 거치고 있나요? 만약 그렇지 않다면 슬로우쿼리 모니터링은 필수입니다.우리가 서비스 초기에 겪은 문제의 대부분은 인덱스를 잘 다루지 못하거나 새로 도입한 ORM에 대한 이해도가 낮아서 발생한 문제였습니다. 그 중에서도 특정 쿼리가 너무 많은 I/O를 유발하던 것이 주된 원인이었으며, 작고 가벼운 쿼리가 너무 많이 호출되어 문제가 된 경우는 거의 없었습니다.잘못 설계된 스키마나 쿼리는 평소에는 드러나지 않다가 사용자가 몰리기 시작하면 큰 부하를 발생시켜서 기어이 서비스를 마비시키곤 합니다. 문제가 커지기 전에 그 조짐을 감지할 수는 없을까, 고민 끝에 우리가 시도한 방법은 “2초 이상 수행되는 쿼리에 대해서 로그를 남기고, 초당 3개 이상 로그가 발생할 경우 알림”을 받도록 하는 것이었습니다.MySQL에서는 아래 설정으로 로그를 활성화시킬 수 있습니다.[mysqld] long_query_time=2 # 2초 이상 수행되는 쿼리에 대해서 slow_query_log=1 # 로그를 남겨주세요 쿼리 분석에는 Percona의 pt-query-digest 를 추천합니다. VividCortext 혹은 MONyog 등의 솔루션은 시각적으로 화려하고 실제로도 강력한 기능을 갖추고 있지만, 유료라는 큰 단점이 있습니다.모니터링을 통해 알림을 받게 되면 문제가 더 커지기 전에 해당 기능을 수정하거나 중단시킬 기회가 생깁니다. 특히 새롭게 추가한 기능을 배포할 때 서비스가 불안해 질 수 있는데, 퍼포먼스 문제를 미리 발견하고 롤백을 서두를 수 있다는 것도 장점입니다.물론 가장 이상적인 상황은 n초 이상 수행되는 쿼리를 모두 없애는 것입니다. 하지만 현실은 튜닝을 포기하고 테이블을 풀스캔하도록 두는게 나은 선택일 수 있으며, OLAP/ETL 인프라가 별도로 구축되어 있지 않은 상황에서는 어쩔 수 없이 슬로우쿼리가 발생하게 됩니다. 우리가 초당 로그 갯수로 판단을 하게된 것도 이러한 이유 때문이었습니다.자동으로 슬로우 쿼리를 받아보면 문제해결에 도움이 됩니다.4. 배치 작업(scheduled task) 모니터링매일 백업 스크립트를 돌리고는 있는데, 백업이 정상적으로 완료가 되었는지는 어떻게 판단하면 될까요? 에러는 위에서 설명한 도구들로 확인이 가능하겠지만 스크립트가 수행도중 멈춰버렸거나, 서버의 전원이 꺼졌다면? 게다가 크론 작업(crontab)이 수십개가 넘어가면 이를 수동으로 체크하는 것도 일이므로, 반드시 자동화해야 합니다.이러한 상황에서 활용할 수 있는 유용한 도구가 PushMon 입니다. PushMon은 정해진 시간에 ping을 보내지 않으면 이메일이나 SMS로 알림을 주는 서비스로, 원리는 매우 단순하나 없어서는 안될 기능을 “무료”로 제공합니다.모니터링에 대응하기모니터링을 효율적으로 하기 위한, 즉 서비스 안정성을 높이기 위한 핵심 원칙은 “필요한 인원이 필요한 알림만 받는것”입니다.알림이 너무 많이 와서 음소거(Mute)를 하고 싶은 생각이 든다면 모니터링 체계에 문제가 있다는 신호입니다. 불필요하게 많은 경고는 안전 불감증을 낳을 뿐더러 정작 중요한 경고를 놓칠 확률을 높이기 때문입니다. 치명적인 알림은 모든 채널로 즉각 수신하고, 경고성 알림은 메일로 수신하되 정기 리포트나 메일함 자동분류 기능을 이용하여 중요한 정보를 놓치지 않는 습관이 중요합니다.불필요하게 많은 인원이 알림을 받는 상황도 문제입니다. 알림 수신자를 늘리면 모니터링의 퀄리티가 높아질 것이라고 생각하지만 절대 그렇지 않습니다. 오히려 방관자 효과가 발생하여 아무도 알림에 대응하지 않는 상황이 발생하게 됩니다. 따라서 알림이 발생했을 때에는 1차, 2차 담당자를 사전에 지정하고 운영할 필요가 있습니다.방관자 효과의 적절한 예팀에서 Slack을 사용한다면 기능 연동을 통해 실시간으로 이슈를 파악할 수 있고, 담당자 지정을 보다 쉽고 명확하게 할 수 있습니다. 특히, 별것 아닌 이모티콘(emoji) 만으로도 방관자 효과를 크게 줄일 수 있는데, 예를 들면 아래와 같습니다.👀 - 확인중 ✅ - 확인 완료 😱 - 확인은 하였으나 나는 해결을 못하겠음Sentry를 Slack에 연동한 모습또한, 모니터링 시스템에 대한 모니터링도 중요합니다. SaaS를 이용하는 경우에는 최악의 경우 해당 서비스의 점검기간에 대비할 수 없으며, 심지어는 점검중이라는 사실 조차 인지하지 못할 수 있습니다. 이에 대비하기 위해 리디북스에서는 Server Density로 모니터링을 모니터링하고 있습니다.맺음말장애를 얼마나 꼼꼼하게 예방하는지, 그리고 얼마나 즉각적으로 반응하는지는 팀 구성원의 실력으로 정해지는것이 아니라 팀의 문화와 원칙에 따라 정해집니다. 아직 팀에 뚜렷한 대응 원칙이 없다면 먼저 상황에 맞는 기준과 척도를 결정하고 공유해볼 것을 추천합니다.무엇보다 DevOps를 수행하는 것은 사람임을 잊지 말아야 합니다. 인간은 99.99% 가용성이나 24/7 을 보장하지 못하며, Uptime은 하루도 되지 않습니다. 최근 DevOps가 대세가 되어가지만 Ops에서의 인간적인 측면은 진지하게 고려되지 않고 있습니다. 이러한 환경을 개선하기 위한 HumanOps에 대한 소개와 함께 글을 마칩니다.     HumanOps 계명시스템을 만들고 고치는 것은 인간이다.인간은 지치고 스트레스를 받으며, 행복과 슬픔을 느낀다.시스템은 아직 감정이 없다. 오로지 SLA만 있다.인간은 스위치 온/오프 상태를 반복해야 한다.시스템을 운영하는 인간의 행복이 시스템의 안정성에 영향을 준다.빈번한 알림 == 인간의 피로최대한 자동화하고, 최후의 수단으로 인간에게 이관하라.문서화하고, 훈련하고, 시간을 아껴라.창피 주지 마라.인간의 문제는 시스템의 문제다.인간의 건강은 사업의 건강에 영향을 준다.인간 > 시스템#리디북스 #개발 #DevOPS #모니터링 #인사이트 #서버개발 #운영 #꿀팁
조회수 4270

파이썬 코딩 컨벤션

스포카 개발팀 문성원입니다. 저희는 (익히 아시다시피) 서버를 개발하는데 파이썬(Python)을 사용하고 있는데, 오늘은 이러한 파이썬 코드를 작성할 때 기준이 되는 코딩 컨벤션(Coding Convention)에 대해서 알아보겠습니다.Coding Convention코딩 컨벤션이란 개념에 대해 생소하신 분들도 계실 테니 이를 먼저 알아보죠. 코딩 컨벤션은 프로그램 코드를 작성할 때 사용되는 일종의 기준입니다. 이를테면 들여쓰기(Indentation)는 공백으로 할거냐 탭으로 할거냐. 부터 var a = 3; 과 같은 코드에서 a와 =를 붙이느냐 마느냐라던지를 정해주는 것이죠. 알고 계시는 것처럼 이러한 차이는 특별히 실행 결과의 영향을 주지 않습니다. 다르게 이야기하자면 “실행 결과에 별 차이가 없는 선택지들”이기 때문에 일관성이 있는 기준을 두어 통일하자는 것이지요.그렇다면 왜 이런 선택지를 통일해야 할까요? 불행히도 우리가 작성한 코드는 많은 사람들이 보게 됩니다. 같이 일하는 동료, 이바지하고 있는 프로젝트의 리뷰어, 심지어 내일의 자기 자신까지도 말이죠. 그런데 이런 많은 사람들이 우리가 코드를 작성할 때 했던 선택지를 일일이 추론해서 이해하는 건 굉장히 피곤하고 짜증 나는 일입니다. 그래서 우리는 사소한 것부터 일종의 규칙을 정해서 이런 짜증과 불편함을 줄이려는 겁니다. 또한, 일반적으로 좋은 기준에는 훌륭한 프로그래머들의 좋은 습관이 배어있기 때문에 더 나은 품질의 코드를 작성하는 데에도 많은 도움이 됩니다.이런 코딩 컨벤션은 극단적으로 이야기하면 프로젝트마다 하나씩 존재한다고 볼 수도 있지만, 일반적으로 그 언어문화를 공유하는 공동체에서 인정하는 컨벤션은 대부분 통일되어 있습니다. 파이썬은 지금부터 살펴볼 PEP 8이 대표적입니다.PEP?PEP(Python Enhance Proposal)이란 이름대로 본디 파이썬을 개선하기 위한 개선 제안서를 뜻합니다. 이러한 제안서는 새로운 기능이나 구현을 제안하는 Standard Track, (구현을 포함하지 않는) 파이썬의 디자인 이슈나 일반적인 지침, 혹은 커뮤니티에의 정보를 제안하는 Informational, 그리고 파이썬 개발 과정의 개선을 제안하는 Process의 3가지로 구분할 수 있습니다. (좀 더 자세한 사항은 PEP에 대해 다루고 있는 PEP인 PEP 1을 참고하세요.) 파이썬은 언어의 컨벤션을 이러한 제안서(Process)로 나타내고 있는데 이것이 바로 PEP 8입니다.Laplace’s Box기본적으로 가이드라인이니만큼 규칙만 빽빽할 것 같지만, PEP 8는 서두부터 예외를 언급한 섹션이 있습니다.A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.스타일 가이드는 일관성(consistency)에 관한 것입니다. 이 스타일 가이드의 일관성은 중요하죠. 하지만 프로젝트의 일관성은 더욱 중요하며, 하나의 모듈이나 함수의 일관성은 더더욱 중요합니다.But most importantly: know when to be inconsistent – sometimes the style guide just doesn’t apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don’t hesitate to ask!하지만 가장 중요한 건 언제 이것을 어길지 아는 것입니다. – 때때로 스타일 가이드는 적용되지 않습니다. 의심이 들 때는 여러분의 최선의 판단을 따르세요. 다른 예제를 보고 어느 게 제일 나은지 골라야 합니다. 질문을 주저하지 마세요!Two good reasons to break a particular rule:When applying the rule would make the code less readable, even for someone who is used to reading code that follows the rules.To be consistent with surrounding code that also breaks it (maybe for historic reasons) – although this is also an opportunity to clean up someone else’s mess (in true XP style).다음은 규칙들을 어기는 2가지 좋은 예외 사항입니다.규칙을 적용한 코드가 (규칙을 숙지한 사람 눈에도) 읽기 어려운 경우일관성을 지키려고 한 수정이 다른 규칙을 어기는 경우(아마도 역사적인 이유겠죠.)아직 아무것도 안나왔는데 좀 이르다구요?It’s all about common sense예외 규정을 보여주며 시작하는 PEP 8이지만 얼개는 그리 복잡하지도 않고 크게 난해하지도 않습니다. 여기서는 대표적인 몇 가지만 추려서 소개하겠습니다.Code lay-out들여쓰기는 공백 4칸을 권장합니다.한 줄은 최대 79자까지최상위(top-level) 함수와 클래스 정의는 2줄씩 띄어 씁니다.클래스 내의 메소드 정의는 1줄씩 띄어 씁니다.Whitespace in Expressions and Statements다음과 같은 곳의 불필요한 공백은 피합니다.대괄호([])와 소괄호(())안쉼표(,), 쌍점(:)과 쌍반점(;) 앞키워드 인자(keyword argument)와 인자의 기본값(default parameter value)의 = 는 붙여 씁니다.Comments코드와 모순되는 주석은 없느니만 못합니다. 항상 코드에 따라 갱신해야 합니다.불필요한 주석은 달지 마세요.한 줄 주석은 신중히 다세요.문서화 문자열(Docstring)에 대한 컨벤션은 PEP 257을 참고하세요.Naming Conventions변수명에서 _(밑줄)은 위치에 따라 다음과 같은 의미가 있습니다._single_leading_underscore: 내부적으로 사용되는 변수를 일컫습니다.single_trailing_underscore_: 파이썬 기본 키워드와 충돌을 피하려고 사용합니다.__double_leading_underscore: 클래스 속성으로 사용되면 그 이름을 변경합니다. (ex. FooBar에 정의된 __boo는 _FooBar__boo로 바뀝니다.)__double_leading_and_trailing_underscore__: 마술(magic)을 부리는 용도로 사용되거나 사용자가 조정할 수 있는 네임스페이스 안의 속성을 뜻합니다. 이런 이름을 새로 만들지 마시고 오직 문서대로만 사용하세요.소문자 L, 대문자 O, 대문자 I는 변수명으로 사용하지 마세요. 어떤 폰트에서는 가독성이 굉장히 안 좋습니다.모듈(Module) 명은 짧은 소문자로 구성되며 필요하다면 밑줄로 나눕니다.모듈은 파이썬 파일(.py)에 대응하기 때문에 파일 시스템의 영향을 받으니 주의하세요.C/C++ 확장 모듈은 밑줄로 시작합니다.클래스 명은 카멜케이스(CamelCase)로 작성합니다.내부적으로 쓰이면 밑줄을 앞에 붙입니다.예외(Exception)는 실제로 에러인 경우엔 “Error”를 뒤에 붙입니다.함수명은 소문자로 구성하되 필요하면 밑줄로 나눕니다.대소문자 혼용은 이미 흔하게 사용되는 부분에 대해서만 하위호환을 위해 허용합니다.인스턴스 메소드의 첫 번째 인자는 언제나 self입니다.클래스 메소드의 첫 번째 인자는 언제나 cls입니다.메소드명은 함수명과 같으나 비공개(non-public) 메소드, 혹은 변수면 밑줄을 앞에 붙입니다.서브 클래스(sub-class)의 이름충돌을 막기 위해서는 밑줄 2개를 앞에 붙입니다.상수(Constant)는 모듈 단위에서만 정의하며 모두 대문자에 필요하다면 밑줄로 나눕니다.Programming Recommendations코드는 될 수 있으면 어떤 구현(PyPy, Jython, IronPython등)에서도 불이익이 없게끔 작성되어야 합니다.None을 비교할때는 is나 is not만 사용합니다.클래스 기반의 예외를 사용하세요.모듈이나 패키지에 자기 도메인에 특화된(domain-specific)한 기반 예외 클래스(base exception class)를 빌트인(built-in)된 예외를 서브클래싱해 정의하는게 좋습니다. 이 때 클래스는 항상 문서화 문자열을 포함해야 합니다.class MessageError(Exception): """Base class for errors in the email package."""raise ValueError('message')가 (예전에 쓰이던) raise ValueError, 'message'보다 낫습니다.예외를 except:로 잡기보단 명확히 예외를 명시합니다.(ex. except ImportError:try: 블록의 코드는 필요한 것만 최소한으로 작성합니다.string 모듈보다는 string 메소드를 사용합니다. 메소드는 모듈보다 더 빠르고, 유니코드 문자열에 대해 같은 API를 공유합니다.접두사나 접미사를 검사할 때는 startswith()와 endwith()를 사용합니다.객체의 타입을 비교할 때는 isinstance()를 사용합니다.빈 시퀀스(문자열, 리스트(list), 튜플(tuple))는 조건문에서 거짓(false)입니다.불린형(boolean)의 값을 조건문에서 ==를 통해 비교하지 마세요.Give me a reason하지만 몇몇 규칙은 그 자체만으론 명확한 이유를 찾기 어려운 것도 있습니다. 가령 예를 들면 이런 규칙이 있습니다.More than one space around an assignment (or other) operator to align it with another.Yes:x = 1 y = 2 long_variable = 3No:x = 1 y = 2 long_variable = 3보통 저런 식으로 공백을 통해 =를 맞추는 건 보기에도 좋아 보입니다. 하지만 변수가 추가되는 경우에는 어떨까요. 변수가 추가 될때마다 공백을 유지하기 위해 불필요한 변경이 생깁니다. 이는 소스를 병합(merge)할 때 혼란을 일으키기 쉽습니다.언뜻 보면 잘 이해가 안 가는 규칙은 이런 것도 있습니다.Imports should usually be on separate lines, e.g.:Yes: import os import sys No: import sys, os굳이 한 줄씩 내려쓰면 길어지기만 하고 보기 안 좋지 않을까요? 하지만 이 역시 대부분의 변경 추적 도구가 행 기반임을 고려하면 그렇지 않습니다.#스포카 #개발 #파이썬 #개발자 #Python #컨벤션 #이벤트참여 #이벤트후기 #후기
조회수 1160

레진 기술 블로그 - AWS Auto Scalinging Group 을 이용한 배포

레진코믹스의 서버 시스템은 잘 알려진대로 Google AppEngine에서 서비스되고 있지만, 이런저런 이유로 인해 최근에는 일부 컴포넌트가 Amazon Web Service에서 서비스되고 있습니다. AWS 에 새로운 시스템을 셋업하면서, 기존에 사용하던 PaaS인 GAE에서는 전혀 고민할 필요 없었던, 배포시스템에 대한 고민이 필요했습니다. 좋은 배포전략과 시스템은 안정적으로 서비스를 개발하고 운영하는데 있어서 필수적이죠.초기에는 Beanstalk을 이용한 운영에서, Fabric 을 이용한 배포 등의 시행착오 과정을 거쳤으나, 현재는 (스케일링을 위해 어차피 사용할 수밖에 없는) Auto Scaling Group을 이용해서 Blue-green deployment로 운영 중입니다. ASG는 여러 특징 덕분에 배포에도 유용하게 사용할 수 있습니다.ASG를 이용한 가장 간단한 배포는, Instance termination policy 를 응용할 수 있습니다. 기본적으로 ASG가 어떤 인스턴스를 종료할지는 AWS Documentation 에 정리되어 있으며, 추가적으로 다음과 같은 방식을 선택할 수 있습니다.OldestInstanceNewestInstanceOldestLaunchConfigurationClosestToNextInstanceHour여기서 주목할 건 OldestInstance 입니다. ASG가 항상 최신 버전의 어플리케이션으로 스케일아웃되게 구성되어 있다면, 단순히 인스턴스의 수를 두배로 늘린 뒤 Termination policy 를 OldestInstance 로 바꾸고 원래대로 돌리면 구버전 인스턴스들부터 종료되면서 배포가 끝납니다. 그러나 이 경우, 배포 직후 모니터링 과정에서 문제가 발생할 경우 기존의 인스턴스들이 이미 종료된 상태이기 때문에 롤백을 위해서는 (인스턴스를 다시 생성하면서) 배포를 다시 한번 해야 하는 반큼 빠른 롤백이 어렵습니다.Auto scaling lifecycle 을 이용하면, 이를 해결하기 위한 다른 방법도 있습니다. Lifecycle 은 다음과 같은 상태 변화를 가집니다.기본적으로,ASG의 인스턴스는 InService 상태로 진입하면서 (설정이 되어 있다면) ELB에 추가됩니다.ASG의 인스턴스는 InService 상태에서 빠져나오면서 (설정이 되어 있다면) ELB에서 제거됩니다.이를 이용하면, 다음과 같은 시나리오로 배포를 할 수 있습니다.똑같은 ASG 두 개를 구성(Group B / Group G)하고, 그 중 하나의 그룹으로만 서비스를 운영합니다.Group B가 라이브 중이면 Group G의 인스턴스는 0개입니다.새로운 버전을 배포한다면, Group G의 인스턴스 숫자를 Group B와 동일하게 맞춰줍니다.Group G가 InService로 들어가고 ELB healthy 상태가 되면, Group B의 인스턴스를 전부 Standby로 전환합니다.롤백이 필요하면 Standby 상태인 Group B를 InService 로 전환하고 Group G의 인스턴스를 종료하거나 Standby로 전환합니다.문제가 없다면 Standby 상태인 Group B의 인스턴스를 종료합니다.이제 훨씬 빠르고 안전하게 배포 및 롤백이 가능합니다. 물론 실제로는 생각보다 손이 많이 가는 관계로(특히 PaaS인 GAE에 비하면), 이를 한번에 해주는 스크립트를 작성해서 사용중입니다. 대략 간략하게는 다음과 같습니다. 실제 사용중인 스크립트에는 dry run 등의 잡다한 기능이 많이 들어가 있어서 걷어낸 pseudo code 입니다. 스크립트는 사내 PyPI 저장소를 통해 공유해서 사용 중입니다.def deploy(prefix, image_name, image_version): '''Deploy specified Docker image name and version into Auto Scaling Group''' asg_names = get_asg_names_from_tag(prefix, 'docker:image:name', image_name) groups = get_auto_scaling_groups(asg_names) # Find deployment target set future_set = set(map(lambda g: g['AutoScalingGroupName'].split('-')[-1], filter(lambda g: not g['DesiredCapacity'], groups))) if len(future_set) != 1: raise ValueError('Cannot specify target auto scaling group') future_set = next(iter(future_set)) if future_set == 'green': current_set = 'blue' elif future_set == 'blue': current_set = 'green' else: raise ValueError('Set name shoud be green or blue') # Deploy to future group future_groups = filter(lambda g: g['AutoScalingGroupName'].endswith(future_set), groups) for group in future_groups: asg_client.create_or_update_tags(Tags=[ { 'ResourceId': group['AutoScalingGroupName'], 'ResourceType': 'auto-scaling-group', 'PropagateAtLaunch': True, 'Key': 'docker:image:version', 'Value': image_version, } ]) # Set capacity, scaling policy, scheduled actions same as current group set_desired_capacity_from(current_set, group) move_scheduled_actions_from(current_set, group) move_scaling_policies(current_set, group) # Await ELB healthy of instances in group await_elb_healthy(future_groups) # Entering standby for current group for group in filter(lambda g: g['AutoScalingGroupName'].endswith(current_set), groups): asg_client.enter_standby( AutoScalingGroupName=group['AutoScalingGroupName'], InstanceIds=list(map(lambda i: i['InstanceId'], group['Instances'])), ShouldDecrementDesiredCapacity=True ) def rollback(prefix, image_name, image_version): '''Rollback standby Auto Scaling Group to service''' asg_names = get_asg_names_from_tag(prefix, 'docker:image:name', image_name) groups = get_auto_scaling_groups(asg_names) def filter_group_by_instance_state(groups, state): return filter( lambda g: len(filter(lambda i: i['LifecycleState'] == state, g['Instances'])) == g['DesiredCapacity'] and g['DesiredCapacity'], groups ) standby_groups = filter_group_by_instance_state(groups, 'Standby') inservice_groups = filter_group_by_instance_state(groups, 'InService') # Entering in-service for standby group for group in standby_groups: asg_client.exit_standby( AutoScalingGroupName=group['AutoScalingGroupName'], InstanceIds=list(map(lambda i: i['InstanceId'], group['Instances'])) ) # Await ELB healthy of instances in standby group await_elb_healthy(standby_groups) # Terminate instances to rollback for group in inservice_groups: asg_client.set_desired_capacity(AutoScalingGroupName=group['AutoScalingGroupName'], DesiredCapacity=0) current_set = group['AutoScalingGroupName'].split('-')[-1] move_scheduled_actions_from(current_set, group) move_scaling_policies(current_set, group) 몇 가지 더…Standby 로 돌리는 것 이외에 Detached 상태로 바꾸는 것도 방법입니다만, 인스턴스가 ASG에서 제거될 경우, 자신이 소속된 ASG를 알려주는 값인 aws:autoscaling:groupName 태그가 제거되므로 인스턴스나 ASG가 많아질 경우 번거롭습니다.cloud-init 를 어느 정도 최적화해두고 ELB healthcheck 를 좀 더 민감하게 설정하면, ELB 에 투입될 때까지 걸리는 시간을 상당히 줄일 수 있긴 하므로, 단일 ASG로 배포를 하더라도 롤백에 걸리는 시간을 줄일 수 있습니다. 저희는 scaleout 시작부터 ELB에서 healthy 로 찍힐 때까지 70초 가량 걸리는데, 그럼에도 불구하고 아래의 이유 때문에 현재의 방식으로 운영중입니다.같은 방식으로 단일 ASG로 배포를 할 수도 있지만, 배포중에 혹은 롤백 중에 scaleout이 돌면서 구버전 혹은 롤백 버전의 인스턴스가 투입되어버리면 매우 귀찮아집니다. 이를 방지하기 위해서라도 (Blue-green 방식의) ASG 두 개를 운영하는게 안전합니다.같은 이유로, 배포 대상의 버전을 S3나 github 등에 기록하는 대신 ASG의 태그에 버전을 써 두고 cloud-init 의 user-data에서 그 버전으로 어플리케이션을 띄우게 구성해 두었습니다. 이 경우 인스턴스의 태그만 확인해도 현재 어떤 버전이 서비스되고 있는지 확인할 수 있다는 장점도 있습니다.다만 ASG의 태그에 Tag on instance 를 체크해 두더라도, cloud-init 안에서 이를 조회하는 경우는 주의해야 합니다. ASG의 태그가 인스턴스로 복사되는 시점은 명확하지 않습니다. 스크립트 실행 중에 인스턴스에는 ASG의 태그가 있을 수도, 없을 수도 있습니다.굳이 인스턴스의 Lifecycle 을 Standby / InService 로 전환하지 않고도 ELB 를 두 개 운영하고 route 53 에서의 CNAME/ALIAS swap 도 방법이지만, DNS TTL은 아무리 짧아도 60초는 걸리고, JVM처럼 골치아픈 동작 사례도 있는만큼 선택하지 않았습니다.물론 이 방법이 최선은 절대 아니며(심지어 배포할때마다 돈이 들어갑니다!), 현재는 자원의 활용 등 다른 측면에서의 고민 때문에 새로운 구성을 고민하고 있습니다. 이건 언젠가 나중에 다시 공유하겠습니다. :)
조회수 476

자바스크립트, 웹페이지의 들러리에서 주인공으로!

지루한 통근(학) 시간. 대중교통으로 이동하는 동안에는 자연스럽게 스마트폰을 찾게 되지 않나요? SNS로 다른 사람과 연락을 하거나, 재미있는 영상을 보기도 하죠. 이때 우리는 웹페이지에 있는 텍스트, 이미지, 영상 등 수많은 정보를 보게 됩니다. 웹페이지를 보기 위해 어떤 브라우저를 사용하시나요? 대부분 Chrome이나 Internet Explorer 등을 사용하실 거예요. 이 브라우저를 개발하다가 만들어진 언어에 대해 이야기해볼게요.움직이는 브라우저 ― 자바스크립트의 탄생지금은 대부분 Chrome이나 Internet Explorer와 같은 브라우저를 사용하지만 1990년대 초반만 해도 Mosaic(모자이크)라는 브라우저를 사용했어요.Mosaic 브라우저의 Yahoo! 페이지 (출처 : dweb3d.com on Pinterest)이 당시의 웹페이지는 대부분 흰색 바탕에 검은색 글씨, 그리고 파란색 글씨로 된 링크로만 구성되어 있었는데요. 지금의 웹페이지와 비교해보면 굉장히 지루하고 단조롭죠.아마도 같은 지루함을 느꼈던 것 같은 '브랜든 아이크'라는 사람이 새로운 브라우저를 개발했는데 단 10일 만에 웹페이지에 동작을 넣을 수 있는 언어를 뚝딱 만들어냈어요. 지금처럼 버튼을 눌렀을 때 안내 창이 뜨게 하는 등 좀 더 생동감 있는 웹페이지를 만들 수 있게 된 거예요.이때 만들어진 언어가 바로 JavaScript 랍니다!Java? Javascript! ― 이름의 유래Java와 [removed] 이름이 유사하네요!JavaScript라는 언어가 생소한 분들도 아마 Java라는 언어는 한 번쯤 들어보셨을 거예요. 이 두 언어는 이름이 비슷하지만 전혀 다른 언어예요. 마치 인도와 인도네시아처럼요!이와 관련해서 재밌는 일화가 있는데, 사실 지금의 JavaScript는 초창기에 Mocha(모카)라는 이름으로 개발되었어요. 그런데 당시에 Java 언어가 개발되어 큰 인기를 끌게 되자 Java를 만든 회사와 협약을 체결해 이름을 JavaScript로 변경했답니다. Java의 인기가 높아짐에 따라 덩달아 JavaScript의 인기도 높아지게 되었죠! Javascript 전성시대JavaScript의 인기가 높아지게 된 이유는 비단 Java의 유명세 때문만은 아니에요. 2000년대 중반에 들어서서 기술이 점점 더 발전함에 따라 웹페이지에서 시각적인 것이 중요해졌는데, 태생부터가 웹페이지를 생동감 있게 만들기 위해 개발된 JavaScript는 이런 상황에 활용되기 제격이었던 겁니다.많은 사람들이 웹페이지에 JavaScript를 사용하게 되고, 또 JavaScript를 잘 활용하기 위해 관련 정보들을 모은 라이브러리(자료집)가 발달하면서 활용 분야는 더욱더 넓어졌어요.Node.js : JavaScript의 변신!특히 node.js라고 하는 라이브러리는 JavaScript가 웹페이지를 표현하는 역할에 그치지 않고, 웹페이지와 웹페이지 사이를 연결해주는 연결고리(서버) 역할을 하게 해주었어요.이렇게 JavaScript를 사용하는 분야가 증가하면서 사용자 수도 폭발적으로 증가하게 되었고 현재 JavaScript는 웹 개발에 필수적인 언어로 자리매김하게 되었습니다.또 다른 장점 ― Javascript를 배우는 이유수많은 사람들이 JavaScript를 배우려고 하는 이유는 또 있어요. 우선 C언어나 Java보다 시작하기 쉽다는 점 때문인데요. 예를 들면 C나 Java는 변수를 선언할 때 숫자형, 문자형 등 자료의 유형을 명시해주어야 하지만 JavaScript는 그럴 필요가 없어요. 쉽게 이야기하면 앞의 두 언어는 자료를 상자에 담아서 관리할 때 반드시 자료의 크기에 맞는 상자를 준비해줘야 하지만 JavaScript는 그럴 필요 없이 마치 요술 상자처럼 하나의 상자에 모든 자료를 담을 수 있죠! 그래서 어떤 자료를 다룰 때 그 자료의 형태를 일일이 따져보지 않아도 된다는 편리함이 있어요.JavaScript는 앞서 이야기했던 것처럼 웹페이지를 꾸미거나 이들의 연결망을 만들고, 엄청 많은 자료들을 저장하는 저장소(데이터베이스)를 짓는 데에도 쓰이는 등 활용하는 분야가 무궁무진합니다.웹페이지를 보조하기 위해 탄생한 언어가 웹페이지를 만들기 위한 주류 언어가 되다니, 정말 놀랍지 않나요? 앞으로 JavaScript가 어떤 분야에서 활약하게 될지 더욱더 기대되는 이유입니다!>> 자바스크립트 과목 보기(참고 자료)Press release announcing JavaScript, "Netscape and Sun announce JavaScript", PR Newswire, December 4, 1995.Brendan Eich (3 April 2008). "Popularity". Retrieved 2018-07-06.              
조회수 1734

우리는 비정상인걸까?

필자는 스팀헌트라는 스팀 블록체인 기반 댑 프로젝트를 진행하고 있다. 스타트업을 하면서 저마다의 관점과 철학이 다른 문제이겠으나, 내가 지금까지 약 1년간 경험해본 이놈의 "블록체인"이라는 업계는 뭔가 정상적이지 않다. 그간 나름 "스타트업"이라는 업계 전반의 경험에 비추어 봤을때 이바닥 관행들이 뭐가 내게는 비정상적으로 보이는지 간략히 살펴보면 다음과 같다.1.대부분의 "블록체인" 태그를 달고 나오는 프로젝트들은 가장 처음 하는 일이 펀딩이다. 아직 제품은 커녕 그냥 프로젝트 소개하는 랜딩페이지에 수십명의 팀원, 어드바이저 리스트, 현실성이 있을까 싶은 각종 기업 로고들이 파트너사로 나열되어 있다.2.그들에게 "제품"이란 마치 수십 수백페이지의 엄청난 공을 들인 "화이트페이퍼"인듯 하다. 왜냐하면 위에서 얘기한 랜딩페이지 맨 위에 항상 가장 대문짝 만한 자리를 차지하고, 이미 3개국어는 기본, 5개국어 버전까지 준비해 놨기 때문이다.3.이런 제품도 없고 요상한 랜딩페이지만 있는 프로젝트들이 수십, 수백억의 ICO, IEO, 프라이빗 세일 등등의 단어로 치장된 "토큰 세일"을 진행한다. 이들이 초기에 들이는 자원중 99% 이상은 카톡방 관리, 텔레그램방 관리, 코인판 (사이트 이름이다) 마케팅, 각종 밋업, 컨퍼런스 참여, 유투버들 마케팅 등등이다. 물론 이런 행동들은 성공적인 펀딩을 위해 필요한 일들이긴 하다. 다만, 일반적인 스타트업이라면 초기에 99%의 자원이 제품과 유저들에게 쏟아야 마땅한 단계에 그게 아니라는게 내겐 비정상적인걸로 보일 뿐.4.아직 제품도 없는 팀이 팀원 리스트를 꾸린걸 보면 거의 중견급 스타트업 레벨이다. 아직 유저도 없고 비즈니스도 없는 팀이 CEO, CTO, CMO, CSO, C.... 레벨이 5명은 기본, 개발자 5-6명을 리스트에 박아놓는다. 일반적인 스타트업에서는 MVP가 어느정도 검증되고 나서 스케일을 낼때 하는 일들이다. 마치 삽도 뜨기 전에 삽질할 사람들 수십명을 모아놓은 그림이다. 이 중 십중팔구는 삽을 뜨려고 보니 땅바닥이 콘크리트 바닥이라 팔 수가 없거나, 애초에 팔 의지도 없었던게 대부분이지만...5.어드바이저 리스트... 내가 가장 요상하게 여기던 관행인데, 어느 프로젝트를 들어가도 이력이 화려해 보이는 어드바이저들 5명 이상은 기본으로 갖고 들어가더라. 내가 맨 처음 이바닥 들어갈때는 나름 "뭐, 아무도 가본 길이 아니니 조언해줄 사람들이 많이 필요할수도 있겠지.."라고 착각했었다. 알고보니, 그들은 그저 위에 자리를 채워주는 역할과 아주 약간의 투자자+거래소 인맥을 소개시켜주는 역할을 하는 사람들이더라. 이렇게 이름만 팔아주고 대부분 총 발행량의 0.5 ~ 2, 3%까지 토큰을 받아가는데, 대부분 상장과 함께 가장 먼저 덤핑될 토큰들이라는게 업계의 공통된 시각이다. 사실, 이 바닥이 그리 넓지 않아서 거래소 인맥 소개시켜주는건 인맥이 넓으신 1-2명으로도 충분히 커버 가능하다. 아예 제대로된 엑셀러레이터 들어가면 그들이 백배는 더 전문적으로 잘 해주는 영역이기도 하다. 아무리 생각해도 삽도 안떠본 스타트업이 저 많은 어드바이저 리스트를 꾸려야 할 이유를 지금도 못찾았고, 앞으로도 모를것 같다.6.지금이야 STO니 해서 증권형 토큰들이 하나둘씩 나오지만, ICO하는 대부분의 코인들은 본인들이 "유틸리티" 코인이라고 주장한다. 뭐, 토큰 모델 디자인상 유틸리티 토큰일 수 있다. 그런데 문제는, 이를 배포할 때 초기 토큰 홀더들은 100% "투자자"라는데에 있다. 그들이 주장하는 토큰의 유틸리티, 유저 페르소나와 1도 관계 없는 사람들이 대부분 토큰을 갖게 되고, 시장 상장 후 차익 실현을 위해 보유하는 경우가 거의 백프로다. 마치 사탕 사먹으라고 발행한 백원짜리 동전을 손에 쥔 백명의 사람들이 사실 사탕 사먹으려는게 아니고 모두 이백원, 삼백원에 팔기위해 손에 쥐고 있는것과 같은 논리다. 이러니, "유틸리티" 토큰이라는게 작동할리가 없다.7.백서... 어드바이저와 함께 내가 가장 요상하게 여기는거다. 대부분의 프로젝트가 삽도 뜨기 전에 수십, 수백장짜리의 백서부터 쓴다. 읽어보면 완전 세상을 바꿀 의지가 넘쳐 흐르는 철학적 도입부 + 본인들의 기술이 세상에 없던, 혹은 현존하는 기술은 거의 쓰레기 수준이라는 설명 + 삽도 떠본적 없는데 3-5개년 중장기 계획이 세워져 있고, 3년후에는 이미 이 시장을 평정해 있는 이야기들로 점철되어 있다. 제품도 없고 유저도 없는 상태에서 쓰여지는 수십페이지짜리 백서라는건, 그냥 대학교에서 팀플 리포트 A학점정도 맞을 만큼 잘 써진 그냥 소설 페이퍼정도인데, 이걸 무슨 신주단지마냥 만들어서 돌리는지 도무지 이해할수가 없다.8.투자자 생태계가 진짜 엄청나게 요상하게 꾸려져 있다. 일반적인 스타트업에서 보통 시드펀딩을 위해 VC들을 만나보면, 그들은 이 제품이 진짜 어떤 문제를 해결중인건지, 그 문제 해결에 열광하는 유저들이 얼마나 존재하는지, 이게 스케일이 가능한 형태인지, 스케일 했을때 시장규모가 얼마나 될건지, 이놈들이 그중 얼마나 먹을 수 있는 팀원들인지... 보통 이런걸 본다. 이런걸 봐야 나중에 스케일에 성공해서 엑싯이 되든 상장이 되든 해서 투자 수익을 얻을 수 있기 때문이다. 한편, 이바닥 투자자들이 가장 중요시 여기는 것들을 나열해 보면 다음과 같다.1) 백서가 얼마나 있어빌리티하게 작성되어 있는지 (본인들이 잘 모르는 개념들이 잔뜩 들어가 있을수록 높은 점수를 받는다)2) 흥행성 - 이 프로젝트가 얼마나 "호재"를 잘 타서 토큰 가격 펌핑이 가능한 구조인건지. 파트너사들, 각종 MOU, 화려한 이력이 있는 팀, 어드바이저 등등이 보통 활용된다.3) 토큰 분배 - 프라이빗 세일에서 디스카운트 먹은 투자자들 규모가 얼마나 되는지, 팀/어드바이저들은 얼마를 던질 준비가 되어 있는지4) 토큰 상장 - 소위 "대형" 거래소에 처음부터 상장될건지, 얼마나 많은 거래소에서 유통될건지...이 어디에도 "제품"이나 "유저"와 관련된 내용은 하나도 없다. 즉, 투자자들이 진짜 그들 제품의 성공 가능성에 대해 점쳐보며 투자할 분위기도, 그럴 생태계도 아닌게 이 판이다.9.원래 비트코인도, 이더리움도, 이런 탈중앙화 퍼블릭 블록체인 프로젝트의 강점은 오픈소스 프로젝트라는데에 있다. 모든 소스코드가 깃헙에 투명하게 공개되어 있고, 누구나 개발에 기여할 수 있다. 그런데, 이 후에 쏟아진 수 많은 블록체인 프로젝트들이 개발이 이루어지지 않거나, 본인들 소스코드는 비공개라고 하는 경우가 허다하다. 심지어 깃헙 링크가 아예 없는 프로젝트도 수두룩 하다.10.글로벌 프로젝트라는데 물론 아직 "글로벌" 유저도 없고, 레딧이나 트위터 등의 활동도 전무하고, 공식 커뮤니케이션 채널은 카카오톡 오픈챗이나 텔레그램 채널이란다. 가끔 싱가포르나 어디 글로벌 컨퍼런스에서 머리 노란 사람들과 사진 몇방 찍고 이걸 블로그나 신문기사로 찍어내면 글로벌 프로젝트가 되는 분위기다.이렇게 요상한 관행들이 어떤 결과를 가져왔는지 한번 살펴보자. 뭐, 가격 폭락하고 거품 빠지고... 이딴걸 얘기하려는게 아니다. 일반적인 스타트업 업계에 비해 이바닥의 현 성적표가 얼마나 초라한지를 보는거다.1. 전체 ICO의 78% 이상은 스캠으로 판명, 7%는 실패하거나 프로젝트가 사멸하였다 (블룸버그).2. 가장 큰 네트워크 규모를 자랑하는 이더리움 블록체인에서 돌아가는 1,375개의 댑 (DApp - 블록체인에서 돌아가는 앱을 뜻하는 단어)들 중 86%는 유저가 단 한명도 없으며, 93%는 아예 온 체인 트랜잭션이 단 한 건도 발생하지 않은 댑이다 (크립토글로브).3. 이더리움 지갑 보유자 전체의 고작 2%만이 이더리움 댑을 사용하는 유저이다 (dapp.com)4. CoinGecko에 리스팅 되어 있는 전체 4,139개의 프로젝트 중 과거 30일 동안 단 한번이라도 개발 커밋이 이루어진 프로젝트는 단 64개 밖에 없다 (2019년 2월 28일 기준).이걸 스타트업 상황에 비교해서 설명해보면 이렇다.전체 스타트업 중 78%는 사기를 쳤고, 7%는 삽도 못떠보고 망했다. 86%는 유저를 1명도 못만들었고, 93%는 유저는 있는데 유저들의 사용 이력이 1도 없다. 특정 운영체제를 쓰는 스마트폰 보유자들의 고작 2%만이 실제 앱 스토어에서 앱을 다운받아 사용하는 유저이다. 전체 스타트업 중 고작 1.5%만이 과거 30일동안 단 한번이라도 개발 커밋이 이루어졌다. 정말 요상하지 않는가? 그런데 더 충격적인건... 이걸 요상하게 여기는 우리 팀이 더 비정상이라고 보는 이 업계 시각이다. 내가 하는 스팀헌트라는 프로젝트에 대해서는 다음 글에서 상세히 소개할 예정이지만, 우리는 처음에 제품부터 만들어서 유저를 모으고, 가설을 검증하고, 사업모델을 모색하고... 그 다음 펀딩을 추진하는, 지금까지 스타트업에서 있었던 아주 일반적인 트리를 타고 있었다.백서? 물론 없었다. 제품 운영도 안해보고 저런 소설을 내 스스로 쓰는거에 대한 오글거림도 있었고, 솔직히 수만명의 커뮤니티 유저들을 상대하다 보면 그런짓에 시간을 쓸 여유도 없었다.웹사이트에는 그냥 이렇게 끄적여 놨었다...ㅎㅎ그런데, 우리는 아주 일반적인 단계라고 여기며 요즘 펀딩을 준비하고 있는데, 거의 모든 관계자들이 그놈의 "백서"를 요구한다. 제품부터 열어봅시다, 유저부터 한번 봅시다 하고 말꺼내는 사람들이 거짓말 안보태고 10에 1명 찾아볼까 말까였다. 우리도 얼마전까지는 "우린 그런 소설책 쓸 시간이 없어요~~" 이랬었는데... 결국 우리도 백기를 들고 일주일만에 백서를 써버렸다. 근데 사실 써보고 나니, 우린 제품도 1년이나 운영하면서 나름 가설 검증을 많이 해 놓은 단계라 그런지 백서가 쉽게 써지긴 하더라. 로드맵도 3-5년 후 이야기는 있지도 않다. 1년 앞에 어떻게 될지 모르는게 일반적인데 굳이 3-5년후를 쓸 가치를 못느낀다.사실, 위에서 소개한 뭔가 이 바닥에서는 "비정상"처럼 여겨지는 일반적인 스타트업들이 타는 트리를 타고 있는 블록체인 프로젝트들이, 스팀헌트가 만들어진 스팀 블록체인에는 수두룩하게 많다. 아니, 스팀에서는 오히려 위에서처럼 백서만 들고와서 펀딩하는 프로젝트들을 더 까는 경향이 있다.스팀이 코인의 시총만 따지면 40-50위권 수준이라 유명새를 타지 못한 상태이지만, 그 블록체인을 기반으로 움직이는 60여개의 댑들은 이미 실제 유저들을 어마어마하게 거느리고, 이더리움이나 EOS마냥 메타마스크나 스캐터를 깔지 않으면 로그인조차 할 수 없는 상태가 아닌, 일반적인 앱을 쓰는것과 동일한 UX에 모바일에서도 100%로 돌아간다. 코인판의 수 많은 사람들이 거래소에서 pump and dump에만 열을 올리고 있는 사이 스팀에서는 실제 소셜 앱들을 만들기 위한 스타트업 다운 스타트업 생태계가 만들어지고 있던 거다.출처 - https://stateofthedapps.com (2019년 1월 7일 기준)https://stateofthedapps.com라고, 이더리움, EOS등 2,500개 이상의 댑들의 유저수, 트랜젝션을 기반으로 순위를 매기는 공신력 있는 사이트가 있다 (무슨 돈만내면 별점 매겨주는 ICO레이팅 그딴 사이트가 아니다). 거기 차트에 들어가보면 이미 스팀기반 댑들이 상위권을 차지하고 있다. 스팀헌트도 항상 상위 10-20위사이에서 왔다갔다 하면서 최상위권을 유지중이다. 또한, 대부분이 도박, 게임등인 이더리움/EOS와는 달리 스팀기반 댑들은 소셜 서비스라는게 엣지이다. 스팀헌트 역시 테크 얼리어답터들의 "커뮤니티" 플랫폼이다.오늘을 기점으로 다시 브런치 활동을 시작하려고 한다. 내가 직전에 연재하던 시리즈가 "기획돌이의 스타트업 고군분투기"였는데, 이건 일반적인 스타트업에서 좌충우돌하던 깨달음에 대한 글들이였다면, 오늘부터 연재할 글들은 이 "비정상"이 "정상"처럼 여겨지는 블록체인판에서 내가 스팀헌트 프로젝트를 운영하면서 겪게되는 좌충우돌에 대한 이야기들을 소개할 예정이니, 많은 관심과 구독 부탁드린다.글쓴이는 스팀헌트 (Steemhunt) 라는 스팀 블록체인 기반 제품 큐레이션 플랫폼의 Co-founder 및 디자이너 입니다. 비즈니스를 전공하고 대기업에서 기획자로 일하다가 스타트업을 창업하고 본업을 디자이너로 전향하게 되는 과정에서 경험한 다양한 고군분투기를 연재하고 있습니다.현재 운영중인 스팀헌트 (Steemhunt)는 전 세계 2,500개가 넘는 블록체인 기반 앱들 중에서 Top 10에 들어갈 정도로 전 세계 150개국 이상의 많은 유저들을 보유한 글로벌 디앱 (DApp - Decentralised Application) 입니다 (출처 - https://www.stateofthedapps.com/rankings).스팀헌트 웹사이트 바로가기
조회수 22563

Next.js 튜토리얼 9편: 배포하기

* 이 글은 Next.js의 공식 튜토리얼을 번역한 글입니다.** 오역 및 오탈자가 있을 수 있습니다. 발견하시면 제보해주세요!목차1편: 시작하기 2편: 페이지 이동 3편: 공유 컴포넌트4편: 동적 페이지5편: 라우트 마스킹6편: 서버 사이드7편: 데이터 가져오기8편: 컴포넌트 스타일링9편: 배포하기 - 현재 글개요아래와 같은 궁금증이 생긴 적이 있나요?어떻게 내가 만든 Next.js 애플리케이션을 배포할 수 있나요?아직 배포에 대해 이야기하지 않았지만 배포하는 것은 꽤 간단하고 직관적입니다.Node.js를 동작할 수 있는 곳이라면 어디든 Next.js 애플리케이션을 배포할 수 있습니다. 매우 간단한 ▲ZEIT now로 배포하는 데에도 불구하고 어떤 잠금 장치도 없습니다.설치이번 장에서는 간단한 Next.js 애플리케이션이 필요합니다. 다음의 샘플 애플리케이션을 다운받아주세요:아래의 명령어로 실행시킬 수 있습니다:이제 http://localhost:3000로 이동하여 애플리케이션에 접근할 수 있습니다.Build와 Start처음으로 프로덕션에 우리의 Next.js 애플리케이션을 빌드해야 합니다. 빌드는 최적화된 프로덕션의 코드 세트를 생산합니다.이를 위해 간단히 다음의 npm 스크립트를 추가하세요:그런 다음 하나의 포트에서 Next.js를 시작해야 합니다. 사이드 렌더링을 수행하고 페이지를 제공합니다. (위의 명령으로 빌드됩니다)이를 위해 다음의 npm 스크립트를 추가하세요:이러면 3000 포트에서 우리의 애플리케이션이 시작됩니다.이제 프로덕션에서 애플리케이션을 동작시키 위해 다음의 명령어를 실행할 수 있습니다:두 개의 인스턴스 실행하기애플리케이션의 인스턴스 두 개를 실행시켜 봅시다. 대부분 앱을 수평으로 확장하기 위해 이 작업을 수행합니다. 처음으로 start npm 스크립트를 다음과 같이 변경해봅시다:만약 Winodws라면 next start -p %PORT%로 스크립트를 변경해야 합니다.이제 애플리케이션을 처음으로 빌드해봅시다.npm run build그러면 터미널에서 다음의 명령어로 실행시켜 봅시다:PORT=8000 npm startPORT=9000 npm startWinodws에서는 다른 명령어를 실행시켜야 합니다. 하나의 옵션은 애플리케이션에 cross-env npm 모듈을 설치하는 것입니다.그런 다음 커맨드 라인에서 cross-env PORT=9000 npm start를 동작시켜 주세요.두 개의 포트 모두에서 애플리케이션에 접근할 수 있나요?- 네. http://localhost:8000와 http://localhost:9000 둘 다 접근할 수 있습니다.- http://localhost:8000에서만 접근 가능합니다.- http://localhost:9000에서만 접근 가능합니다.- 둘 다 접근할 수 없습니다.한 번의 빌드로 많은 인스턴스 실행시키기보다시피 애플리케이션을 한 번 빌드해야 합니다. 그런 다음 원하는만큼의 많은 포트들을 시작할 수 있습니다.▲ZEIT now에 배포하기Next.js 애플리케이션을 빌드하고 시작하는 방법을 배웠습니다. npm 스크립트를 사용하여 모든 것을 수행했습니다. 그래서 원하는 배포 서비스를 사용해서 동작하도록 애플리케이션을 설정할 수 있습니다.하지만 ▲ZEIT now를 사용하면 딱 한 번의 과정만 수행하면 됩니다.다음과 같은 npm 스크립트만 추가해주세요:그런 다음 now를 설치해주세요. 설치 후 다음 명령어를 적용해주세요:now기본적으로 애플리케이션의 루트 디렉터리 안에서 "now" 명령어를 실행합니다.여기에서 애플리케이션을 시작하는 포트로 8000 포트를 지정했지만 ZEIT now에 배포할 때 변경하지 않았습니다.그러면 ZEIT now에 배포할 때 애플리케이션에 접근할 수 있는 포트는 어떤 것일까요?- 8000- 443 (혹은 언급되는 포트가 없음)- URL에 언급한 모든 포트- 에러를 표시한다. "443 포트에서만 시작할 수 있습니다"ZEIT는 항상 443 포트를 사용합니다실제로 8000 포트에서 애플리케이션을 시작해도 now에 배포될 때는 443 포트를 사용해서 접근할 수 있습니다. ("https" 웹사이트의 기본 포트)이것은 ▲ZEIT now의 특징입니다. 원하는 포트에서 애플리케이션을 시작해야 합니다. ▲ZEIT now는 항상 443 포트로 매핑합니다.로컬에서 애플리케이션 빌드하기▲ZEIT now는 npm build 스크립트를 발견하고 빌드 인프라 내부에 빌드합니다.하지만 모든 호스팅 제공자가 이와 같은 것을 가지고 있지는 않습니다.이 경우 로컬에서 다음의 명령어를 사용해서 빌드할 수 있습니다:npm run build그런 다음 .next 디렉터리를 사용하여 애플리케이션을 배포하세요.커스텀 서버를 사용하여 애플리케이션 배포하기우리가 막 배포한 애플리케이션은 커스텀 서버 코드를 사용하지 않았습니다. 하지만 만약 사용한 경우에는 어떻게 배포할 수 있을까요?다음의 브랜치로 체크아웃하세요:커스텀 서버를 사용하여 애플리케이션을 실행하기 위해 애플리케이션에 Express를 추가해주세요:npm install --save express애플리케이션 빌드하기이를 위해 next build를 사용하여 애플리케이션을 배포할 수 있습니다. 다음의 npm 스크립트를 추가해주세요:애플리케이션 시작하기프로덕션 애플리케이션임을 알리기 위해 커스텀 서버 코드를 생성해야 합니다.이를 위해 server.js로부터 이 코드를 살펴봅시다.이 부분을 살펴봅시다:그러면 프로덕션으로 이와 같이 애플리케이션을 시작할 수 있습니다.그래서 "npm start" 스크립트는 다음처럼 변경됩니다:마무리Next.js 애플리케이션을 배포하는 것에 대해 거의 다 배웠습니다.문서에서 Next.js 배포하기에 대해 더 배울 수 있습니다.배포에 대한 질문이 있다면 자유롭게 Slack에서 물어보거나 issue를 제출하세요.#트레바리 #개발자 #안드로이드 #앱개발 #Next.js #백엔드 #인사이트 #경험공유

기업문화 엿볼 때, 더팀스

로그인

/