50~60년대 국내 상황은 말로 표현하기 힘들다. 당시 강대국들은 전쟁 직후 한국이 다시 정상적으로 복귀하는 것은 불가능하다고 여길 정도였으니, 여러 모로 살아남기 힘든 환경이었던 것만은 분명하다. 하지만, 뭐든지 열심히 노력하는 특유의 국민성을 바탕으로 한걸음씩 내딛기 시작했고, 1988년 서울 올림픽까지 개최할 정도로 경제 성장을 이뤘다. 당시 필자가 태어난 것은 아니었지만, 여러 자료나 부모님 세대의 말씀을 조합하면, 이 같은 성장의 중심에는 제조업의 부흥이 있었기 때문이다.제조업은 국가 실물 경제의 근간이라고 할 정도로 중요한 역할을 담당한다. 단단한 제조업 생태계가 창출해 내는 부가가치를 바탕으로 서비스업이 발전한다면, 산업의 경쟁력을 잃지 않으면서 지속적인 성장을 이뤄낼 수 있는데 큰 보탬이 된다. 최근에는 인공지능과 같은 고도의 기술이 널리 퍼져 제조업의 중요성을 더욱 부각하고 있다. 전통적인 기계 산업 기술은 과학기술을 지탱하는 뿌리의 역할을 하고, 인공지능이나 데이터의 확장 등 탄탄한 제조업 중심의 주력 산업과 융합해 폭발적으로 성과를 낼 수 있다. 결국, 아무리 새로운 기술이 등장한다 해도, 제조업과는 떼려야 뗄 수 없는 관계인 셈이다.인공지능은 제조업에서 매우 유용하게 쓰이고 있다. 그 중에서 공장 자동화에 큰 역할을 하고 있는 '머신 비전(Machine Vision)'에 대해서 이야기를 해보자. 머신 비전은 사물인식, 얼굴인식, 이미지 캡션, 문자 인식 등 여러 형태로 적용되며, 최근 들어 딥 러닝을 통해 더욱 강력해지고 있다. 특히, 비전을 활용해 불량품을 검출하는 'Defect Detection'은 제조업에서 큰 역할을 할 수 있다. 대다수의 공장에서 제품 생산 마지막 공정은 '품질보증(Quality Assurance, QA)'이다. QA를 통해서 생산한 제품 혹은 부품에 문제가 없는지 확인한 후, 구매자에게 좋은 품질의 제품만을 제공해야 하기 때문에 매우 중요하다.실제로 대량생산라인을 보유하고 있는 제조업 기반 기업은 QA에 막대한 비용을 소모하고 있다. 때문에 유심히 확인하지 않거나, 몇몇 샘플들만 체크하고, 심지어 QA를 생략하는 경우도 있다. 결국 피해는 고스란히 최종 구매자에게 이어진다. 예를 들어, 새로 장만한 스마트폰이나 자동차 부품에 흠집이 있는 경우, 최종 구매자가 겪어야 할 불편함은 작지 않다. 또한, 고객 충성도 하락까지 이어질 수 있어 기업은 사전에 방지해야 한다.불량품 검출이 이루어지는 프로세스를 간단하게 알아보자. 스켈터랩스의 정수익 책임 PM의 도움을 받아 이미지로 구성했다.< 불량품 검출 프로세스, 출처: 스켈터랩스 >먼저 부품 생산 과정 중 불량을 탐지하기 위해서는 광학 기기를 사용해 사진을 찍어야 한다. 그리고 촬영된 사진을 이용해 머신 비전으로 탐지하는 것이다. 하지만, 머신 비전이 적용되었다고 해서 바로 족집게처럼 불량품을 검출해낼 수 있는 것도 아니다. 이미 많은 이들이 알고 있지만, 딥 러닝은 수많은 데이터셋을 바탕으로 선행한 학습 전제가 필요하다. 결함으로 판명된 부품들에 대한 데이터를 수집하고, 학습해 '이 부품은 이런 형태의 손상이 있으니 불량이다'라고 판단하는 방식이다. 인식하고, 학습하고, 검출하는 단계를 계속해서 반복하며 기계가 점점 '똑똑해진다'라고 할 수 있다.이어서 스켈터랩스의 사례를 참고해보자. 내부에서 개발하고 있는 불량품 검출 서비스는 크게 세가지 부분으로 구성된다. 파란색 네모 안에 있는 이름은 가제다.< 스켈터랩스의 머신 비전 불량품 검출 서비스 >하나씩 살펴보면, 'Dulok'은 실제로 현장에서 촬영되는 이미지를 모니터링하거나, 이를 클라우드에 업로드하는 '모니터링 모듈'이며, 'Ewok'은 웹상으로 부품 정보에 대해 'curation', 'labeling', 추론 결과를 확인할 수 있도록 하는 '애플리케이션'이다. 마지막으로 'Gorax'는 '학습을 통해 부품의 결함을 검출하는 모델'이다. 이 부분은 실제 서비스에서 단순히 딥 러닝을 통한 추론 외에도 다른 피쳐들이 제공되어야 한다.기존에는 사람이 이미지 상에서 결함에 대한 정의를 하나하나 내리고, 결함의 특징을 수동으로 설정해야 했다. 때문에 반도체나 LCD처럼 표면 형태가 정형화되어 있는 분야에서만 머신 비전 기술을 활용할 수 있었다. 반대로 섬유나 천연가죽 등 표면 형태가 비정형화된 분야에서는 결함 특징 값을 수동으로 설정하기 어려워 육안검사에 의존해야만 했다.그러나 점차 '머신 비전' 기술이 발전하면서 적용되는 영역은 계속 늘어나고 있다. 이는 품질을 높이는 결과로 이어져, 결과적으로는 최종 소비자들이 혜택을 받는다. 이처럼 인공지능 기술은 향후 지속적으로 발전을 거듭해 제조업의 일자리를 뺏는 것이 아닌, 함께 공생하는 생태계를 구축하는데 도움될 것이라 생각한다.이호진, 스켈터랩스 마케팅 매니저조원규 전 구글코리아 R&D총괄 사장을 주축으로 구글, 삼성, 카이스트 AI 랩 출신들로 구성된 인공지능 기술 기업 스켈터랩스에서 마케팅을 담당하고 있다#스켈터랩스 #기업문화 #인사이트 #경험공유 #조직문화 #인공지능기업 #기술기업

Angular는 비동기식 라우팅이 가능합니다. 나중에 사용할 기능들을 NgModule로 분리하여 사용자의 요청이 들어왔을 때 모듈을 불러와 기능을 사용할 수 있고, 이러한 기술을 지연 로딩이라 합니다.프로젝트가 진행되고 기능이 추가될수록 어플리케이션 번들 크기가 커지고, 결국엔 초기 로딩 시간도 길어지게 됩니다. 지연 로딩을 사용하면 초기 로딩 시간을 줄일 수 있습니다. 컴파일 단계에서 나중에 사용할 모듈들을 메인 모듈에서 분리하여 번들을 생성합니다. 그리고 사용자가 기능을 요청할 때 비동기로 스크립트를 불러와 실행합니다. 지연 로딩에 대한 소개와 사용법은 Angular 공식 문서의 Routing & Navigation — Milestom 6: Asynchronous routing 을 참고하시길 바랍니다하지만 지연 로딩을 사용할 때 유의해야할 점이 몇 가지 있습니다.지연 로딩 모듈과 인젝터(Injector)지연 로딩이 완료되었을 때 Angular는 지연 로딩된 모듈을 루트 인젝터(Root Injector)의 자식이 되는 자식 인젝터를 이용하여 초기화하고, 서비스들을 자식 인젝터에 추가합니다. 즉, 인젝터가 분리되기에 지연 로딩된 모듈의 클래스들은 자식 인젝터로의 서비스 주입이 가능하지만 루트 인젝터로 만들어진 클래스들은 불가능합니다.이는 Angular의 독특한 의존성 주입 시스템 때문입니다. Angular의 인젝터는 처음 애플리케이션이 시작되었을 때, 컴포넌트나 다른 서비스에 주입되기 전에 포함된 모든 모듈들의 서비스 제공자들을 블러와 루트 인젝터를 생성합니다. 애플리케이션이 시작되고 나면 인젝터는 서비스들을 생성하고 주입을 시작하고, 새로운 서비스들을 제공자로 추가가 불가능합니다.그러므로 지연 로딩된 서비스들은 이미 생성이 완료된 루트 인젝터로 추가가 불가능합니다. 따라서 Angular는 지연 로딩된 모듈에 대해서 새로운 자식 인젝터를 만들는 전략을 취하게 된 것입니다.자식 인젝터가 새로 만들어지기 때문에 공통된 모듈을 사용할 때 주의하여야 합니다. 예를 들어 다음과 같이 SharedModule 에 CounterService 를 서비스로 추가하고 루트 모듈인 AppModule 과 지연 로딩 모듈인 LazyModule 에 각각 SharedModule 을 import 하였습니다.import { BrowserModule } from '@angular/platform-browser'; import { NgModule } from '@angular/core'; import { RouterModule } from '@angular/router'; import { SharedModule } from './shared/shared.module'; import { AppShellComponent } from './app-shell.component'; const APP_ROUTES = [ { path: 'lazy', loadChildren: 'app/lazy/lazy.module#LazyModule' } ]; @NgModule({ imports: [ BrowserModule, SharedModule, RouterModule.forRoot(APP_ROUTES) ], declarations: [ AppShellComponent ], bootstrap: [AppShellComponent] }) export class AppModule { }import { Injectable } from '@angular/core'; @Injectable() export class CounterService { count = 0; increase(): void { this.count++; } decrease(): void { this.count--; } }import { NgModule } from '@angular/core'; import { RouterModule } from '@angular/router'; import { SharedModule } from '../shared/shared.module'; import { SomeLazyComponent } from './some-lazy.component'; const LAZY_ROUTES = [ { path: '', component: SomeLazyComponent } ]; @NgModule({ imports: [ SharedModule, RouterModule.forChild(LAZY_ROUTES) ] }) export class LazyModule { }import { NgModule } from '@angular/core'; @NgModule({ providers: [ CounterService ] }) export class SharedModule { }그리고 루트 모듈의 컴포넌트와 지연 로딩 모듈의 컴포넌트에서 각각 CounterService 를 사용하여 숫자 값을 바꿔봅니다.서로 다른 인젝터에 CounterService 인스턴스가 만들어졌기 때문에 두 컴포넌트에 표시되는 숫자값은 다릅니다. 앞에서 말했듯이 지연 로딩 모듈은 루트 인젝터가 아닌 자식 인젝터를 이용하여 초기화하기 때문입니다.만약, 지연 로딩 모듈에서 제공되는 서비스를 다른 모듈에서 사용하려면 루트 모듈에 포함시켜 줘야 합니다. 다음과 같이 루트 모듈에게만 노출시킬 서비스 제공자들을 따로 빼내어 줄 수 있습니다.import { NgModule } from '@angular/core'; import { RouterModule, Routes } from '@angular/router'; import { AccountLoginPageComponent } from './login-page.component'; const ACCOUNT_ROUTES: Routes = [ { path: 'login', component: AccountLoginPageComponent } ]; @NgModule({ imports: [ ... RouterModule.forChild(ACCOUNT_ROUTES) ], decalartions: [ AccountLoginPageComponent ] }) export class AccountLazyModule { }import { ModuleWithProviders, NgModule } from '@angular/core'; import { AccountAuthService } from './auth.service'; @NgModule({ imports: [...] }) export class AccountModule { static forRoot(): ModuleWithProviders { return { ngModule: AccountModule, providers: [ AccountAuthService ] }; } }AccountModule.forRoot() 를 루트 모듈에 import하면 다른 모듈에서도 AccountAuthService 를 사용할 수 있게 됩니다. 물론 이 경우 AccountModule를 지연로딩 모듈로 만들면 루트 모듈에 포함되기 때문에 번들을 나누는 의미가 없어질 수 있으니 AccountLazyModule 을 따로 두어 코드를 분리하였습니다.#타운컴퍼니 #개발 #개발자 #인사이트 #꿀팁

와탭랩스는 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 시장도 줄어들지는 않을 것으로 예상되고 있습니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

IT 서비스에 장애가 발생 할 경우 모니터링 프로세스는 장애를 찾는 것으로 끝나지 않습니다. 장애를 발견하는 것은 모니터링 프로세스의 시작 점이며 최종적으로 모니터링을 통해 장애의 근본 원인을 찾아낼 수 있어야 합니다. 그리고 찾아낸 원인들은 예측과 추론에서 확인까지 이르는 하나의 프로세스로 정착되어 다시금 모니터링 과정에 포함되어져야 합니다. 이렇게 서비스를 운영하는 과정에서 근본적인 장애를 찾기 위해 모니터링을 어떻게 이해해야 하는지 알아보겠습니다. 우리가 모니터링 해야 하는 지표어플리케이션 지표(WORK METRICS)- 처리량 지표(THROUGHPUT)- 성공 지표(SUCCESS)- 에러 지표(ERROR)- 성능 지표(PERFORMANCE)시스템 지표(RESOURCE METRICS)- 가동률(UTILIZATION)- 포화상태(SATURATION)- 에러 지표(ERROR)- 이용률(AVAILABILITY)이벤트(EVENTS)- 코드 변경(CODE CHANGES)- 경고 알림(ALERTS)- 규모 변경(SCALING EVENT)- 기타(ETC)IT 서비스를 운영하는 과정에서 발생하는 문제의 근본원인을 추적하기 위한 모니터링 데이터는 크게 3가지로 나눌 수 있습니다. 어플리케이션 지표(Work metrics)서비스의 흐름(트렌젝션)을 측정하여 시스템의 최상위 레벨의 이슈를 보여줍니다. 시스템 지표(Resource metrics)이용률, 상태, 에러 또는 시스템 의존적인 리소스의 이용률을 수량화합니다.이벤트(Events)코드변경, 내부 경고, 확장 이벤트와 같이 드물게 발생하는 불연속적이 이슈를 보여줍니다.일반적으로 IT 모니터링의 핵심 이슈는 어플리케이션 지표를 통해 확인할 수 있습니다. 하지만 다른 지표들 또한 어플리케이션의 지표에서 나타난 문제의 원인을 찾기 위한 중요한 요소이기 때문에 같이 모니터링 해야 합니다. 시스템 지표를 통한 모니터링인프라스트럭쳐는 대부분 시스템의 자원으로 구성됩니다. 최상위 수준에서 유용한 작업을 하는 각각의 시스템들은 다른 시스템들과 연동하기도 하는데요. 예를 들어, 여러분의 아파치 서버가 MySQL 데이터베이스를 자원으로 사용하여 요청을 처리하는 작업을 지원할 수 있습니다. 연관된 작업을 따라 들어가보면 MySQL은 제한된 커넥션 풀을 관리하기 위한 리소스를 가지고 있고 MySQL이 실행되는 서버의 물리적인 리소스 레벨에서는 CPU, Memory, Disk 같은 지표를 보게 됩니다.어플리케이션이 서비스를 제공하는 데 있어서 각각의 리소스가 그 작업을 지원한다면 우리는 장애가 발생한 경우에, 필요한 원인을 얻는 좋은 방법을 시스템을 통해서도 찾아볼수 있습니다. 이런 프로세스를 만들어 간다면 시스템에서 발생한 경고를 통해 장애의 원인을 체계적인 조사하는데 도움이 될 것입니다. 1. 최상위 어플리케이션 지표에서 시작하기첫번째 해야 하는 질문은 "발생한 장애를 설명할 수 있는가?" 이다. 처음부터 문제를 명확하게 정의하지 못하면 이슈를 분석하기 위해 파고들어가야 하는 시스템 패스를 잃어버릴 확률이 높다.다음으로 문제가 있을 것으로 보여지는 최상위 시스템의 작업 지표를 검사해라. 이 지표들은 종종 문제의 원인을 알아내거나 또는 적어도 추적해야 하는 방향을 알려 줄 것이다. 예를 들어 성공적으로 진행된 작업의 성공율이 한계치 이하로 떨어졌다면 에러 지표를 찾아보고 반환된 에러의 형러의 타입을 살펴봄으로써 문제의 방향을 찾아나갈 것이다. 반면에, 대기시간이 길고 외부 시스템에 의해서 요청된 작업처리량이 매우 높다면 시스템 과부하로 인한 문제일 확률이 높다. 다만 와탭의 어플리케이션 분석 서비스를 사용한다면 약간 방법을 달리해도 된다. 와탭의 성능 분포도(어플리케이션 히트맵)와탭의 어플리케이션 성능 분포도를 통해 문제가 발생한 트랜잭션을 드래그하여 선택하게 되면 실제 어플리케이션에서 발생하는 스탭들을 추적하여 문제 해결에 바로 도달할 수도 있다. 하지만 더 복잡한 형태의 장애라면 시스템의 리소스 정보를 찾아봐야 합니다.  2. 리소스 찾아보기최상위 work metrics를 조사하여 문제의 원인을 알수 없다면, 다음으로 시스템이 사용하는 리소스(물리적인 요소 뿐만 아니라 시스템의 리소스 역할을 하는 소프트웨어 또는 외부 서비스)들을 조사합니다. 해당 리소스가 높다면 리소스를 사용하는 하위 Application 지표를 찾아보는 방식으로 찾아나갑니다. 와탭의 데시보드(CPU, MEMORY)3. 변경 내용 찾아보기다음으로 지표에 연관된 경고와 다른 이벤트들을 살펴봅니다. 문제가 발생하기 직전 코드가 릴리즈 되었거나, 내부 경고가 발생하고나 다른 이벤트가 등록되었다면 문제와 연관된 부분을 찾아봐야 합니다. 4. 수정하기 (잊지 말기)문제의 원인을 찾았다면 문제의 원인이 되는 상태를 수정해보고 증상이 사라지는 것을 확인합니다. 증상이 더이상 나오지 않는다면 향후 유사한 문제를 피하기 위해 시스템을 어떻게 변경할지 고민해야 합니다.  서비스가 중단된 상황이 오면 1분이 중요합니다. 문제를 찾는 속도를 높이기 위해 눈앞에서 벌어진 상황에 대한 높은 집중력을 유지하면서 대쉬보드를 상황에 맞춰 재 조정합니다. 최상위 어플리케이션 데쉬보드와 각각의 서브시스템들을 위한 대시보드를 하나씩 설정합니다. 시스템 대시보드는 시스템 지표의 하위 시스템의 키 메트릭스와 함께 어플리케이션 메트릭을 확인 할 수 있어야 합니다. 이벤트 데이터도 이용가능한 상황이라면 연관 분석 차트에서 관련된 이벤트가 올라가 있어야 합니다. 와탭의 알림 서비스정리하기   서비스에 장애는 무조건 발생하지만 우리는 모니터링을 통해 빠르게 해결 할 수 있습니다. 이를 위해 표준화된 모니터링 프로세스를 만들고 대시보드로 연관관계를 만들어 놓는다면 문제를 빠르게 추적 조사할 수 있습니다. 가능하면 모든 지표는 어플리케이션 지표에서 부터 찾을 수 있도록 대시보드를 구성합니다.인프라스트럭처를 통해서도 문제를 분석할 수 있습니다. 시스템에 대해 대시보드를 설정하고 주요 지표들을 올려놓아야 합니다. 문제의 원인을 조사하는 것은 증세가 나타나는 최상위 시스템에서 부터 시작합니다. 문제가 되는 리소스가 발견되면 문제를 발견하고 수정할 때가지 리소스에서 발견되는 패턴을 조사하고 적용시키는작업을 반복해야 합니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

Single Layer Perceptron이번 포스팅에서는 모든 인공신경망의 기초가 되는 perceptron의 개념에 대해서 배워보고, 이를 이용한 단층 퍼셉트론 구조를 구현해보도록 하겠습니다.퍼셉트론은 여러분이 고등학교 과학시간에 한 번쯤은 들어보았을 인간의 신경망, 뉴런으로부터 고안되었습니다. 퍼셉트론은 여러 개의 신호를 입력받으면, 하나의 신호를 출력합니다. 이 때 퍼셉트론이 출력하는 신호는 전달 혹은 차단이라는 1 또는 0의 값을 갖게됩니다. 직관적인 예시를 들어보도록 하죠. 여러분이 매달 초 용돈, 아르바이트비를 받거나(1) 받지 않는다(0)고 가정해보겠습니다. 여러분의 통장에 입금된 이 두 가지 수익을 input(입력) 신호라고 합니다. 이 때 여러분은 두 개의 수익이 합쳐진 통장 잔고를 확인하고 전부터 갖고 싶던 옷을 살지(1) 혹은 사지 않을지(0)를 결정합니다. 이렇게 여러분이 내리는 결정이 output(출력) 신호가 되는 것입니다.하지만 여러분의 의사결정은 이것보다는 복잡할 것입니다. 용돈은 거의 생활비로만 사용하고, 아르바이트비를 주로 취미생활에 사용한다고 가정해보죠. 그럼 여러분이 옷을 살지 여부를 결정할 때에는 아르바이트비가 들어왔는지가 좀더 중요할 것입니다. 따라서 우리는 각 input(입력) 신호를 그대로 사용하지 않고, 각각에 가중치(weight)를 주어 output(출력) 신호를 결정하게 됩니다. 이것을 도식으로 나타내면 다음과 같습니다. 이처럼 input에 weight가 곱해진 형태가 정해진(혹은 학습된) 임계치를 넘을 경우 1을 출력하고 그렇지 않을 경우 0을 출력하게 하는 것이 퍼셉트론의 동작 원리입니다. 정말 간단하죠! 이는 아래 수식과 같습니다.하지만 임계치를 그때그때 바꿔주는 것은 조금 직관적이지 않습니다(저만 그런가요). 그래서 우리는 아래 형태로 식을 바꾸게 되며, 이 때 추가된 b를 bias 혹은 절편이라고 말합니다. 위 식은 여러분이 중고등학교 수학 수업을 잘 들었다면 굉장히 익숙한 형태일 것입니다. 바로 2차원 좌표축을 그리고 직선을 그었을 때, 그 직선을 기준으로 나뉘는 두 개의 공간을 표현한 식입니다. 역시 말보다는 그림이 이해하기 쉬울테니, 아래에 그림을 그려보도록 하겠습니다.위처럼 공간을 올곧은 직선으로 나누는 것을 선형으로 나눴다고 말합니다. 하지만 직선만으로 공간을 나누는 것은 유연하지 않습니다. 위와 같은 방식으로는 OR, AND, NAND 문제는 해결할 수 있지만, XOR 문제는 해결할 수 없습니다. 이와 같은 문제를 해결하기 위해서는 층을 하나 더 쌓고, 공간을 단순한 선형이 아닌 곡선으로 분리해내어 좀더 유연한 적용이 가능해져야합니다.(사실 XOR은 선형만으로도 층을 하나 더 쌓으면 해결이 가능합니다). 이에 따라 multi layer perceptron(MLP) 의 개념이 등장하고, activation function(활성함수) 의 개념이 등장하게 됩니다. 후에 활성함수의 개념을 배우게 되면, 지금 배운 단순 퍼셉트론은 활성함수로 계단함수를 가진 것과 동일하다는 것을 알게 되실겁니다.정리단층 퍼셉트론은 모든 딥러닝 공부의 시작이다.단층 퍼셉트론은 입력 신호를 받으면 임계치에 따라 0 또는 1의 값을 출력한다.이러한 단층 퍼셉트론은 결국 공간을 선형으로 잘라서 구분하는 것과 동일하다.

eBrain에서 진행하는 "개발자 채용 시 기술검증 어떻게 할 것인가"라는 미니 워크숍을 다녀왔다. 항상 고민하고 있는 주제이기도 하고 개인적으로 팬심(?)을 가지고 있는 김창준님의 강의라 한시간 거리를 극복했다.  이미 창천향로님이 강의 내용을 잘 정리해 주셨다. 하지만 내 자신의 학습을 위해 강의 내용을 재해석 해서 적어 본다. 빠져든다! 1. 현재 기술력 검증의 문제점최근의 개발자 채용에 사용되는 기술력 검증 방식은 다음과 같은 것들이 있다.  온라인 코딩 테스트 (최근에 여러 가지 플랫폼도 있다)손 코딩 테스트기술 인터뷰과제 제출이 중 최근에는 주로 알고리즘에 대한 코딩 테스트가 주가 되는 것 같다. 생각보다 난이도가 있어서 재직자들이 “이런 문제면 저는 못 들어왔을 것 같아요”라고 하는 경우도 있다. 코딩 테스트에 대해 두 가지 사례를 들어 질문을 던져 본다.  삼각형 판별 문제삼각형 판별 문제는 세 좌표가 주어졌을 때 이 삼각형이 어떤 삼각형인지 (정삼각형, 이등변 삼각형, 둔각 삼각형 등)를 맞추는 것이다. 이 프로그램이 잘 동작하는지를 검증하는 것이 QA 동네의 ‘Hello World’ 문제다. 이 문제가 주어지면 초보자들은 그냥 문제를 푼다. 하지만 전문가는 문제를 풀지 않고 “이 프로그램을 누가 쓸 것인가요?”를 물어본다. 콘텍스트에 따라서 완전히 다른 테스트의 설계가 필요하기 때문이다.  코딩 테스트도 이와 비슷하다. 코딩 테스트는 단순화된 문제를 푼다. 즉 맥락이 제거된 상태에서의 문제를 푼다. 실무는 종합적인 환경에서 이뤄진다. 따라서 이 문제를 잘 푼다는 것이 실무를 잘할 수 있는 것을 의미하지 않을 수 있다.  질문) 우리의 코딩 테스트는 과연 실무에서의 실력과 높은 상관관계가 있는가?  전문성 연구개발자는 종종 전문성의 연구 대상이 되곤 한다. 이때 연구비를 이유로 주로 혼자서 빠르게 풀 수 있는 문제로 실험이 이뤄진다. 하지만 이런 식의 실험들에서 “토이 문제”가 아닌 “복잡하고 확장된 문제"를 전달했을 때 전혀 다른 결과가 도출된다는것을 알게 되었다.  복잡한 문제, 즉 실제 문제를 풀 때는 인지적 전략이 많이 바뀐다. 또한 사회적 요소도 필요하다. 이런것들을 “토이 문제”로 검증하기는 쉽지 않다. X를 테스트하면 X를 잘하는 사람을 뽑게 된다.  즉, 알고리즘 코딩 테스트를 하면 알고리즘 코딩 테스트에 능한 사람을 뽑게 된다. 질문) 실무에 최대한 가까운 상황을 제한된 면접 시간 내에 만들어 내려면 어떻게 해야 할까? 2. 개발자 채용은 어떻게 해야 할까?채용이 더 크리티컬 한 곳이 있다. 델타포스, 네이비씰과 같은 특수부대이다. 이곳에서는 사람을 어떻게 뽑을까?  작전 지역을 설정 해 두고, 보급품과 군사장비를 실제 작전 수행 환경과 같이 조성해 놓는다. 그곳에서 직접 작전을 수행하는 것을 시뮬레이션 한다.이를  교관이 직접 따라가며 기록과 채점을 한다.  개발자의 면접 시에도 최대한 실제와 비슷한 환경을 구축하는 것이 좋다. 코딩 문제처럼 맞고 틀림만 보는 것이 아니라 과정에 대한 채점이 이뤄져야 한다. 3. 효과적인 기술력 검증을 위해서는 어떻게 준비해야 하는가?1) 우리가 하는 일을 분석한다.  우리가 하는 일에 코딩만 있는 것이 아니다. 설계도 하고, 버그도 찾고, 장애 해결도 하고, 커뮤니케이션도 한다.  2) 대표 케이스들을 뽑거나 만들어 내야 한다.  예를 들어 새롭게 코드를 작성하는 것보다 기존의 기능을 파악해서 코드를 수정하는 일을 더 많이 한다면 이런 상황을 문제로 만드는 것이 좋다.  3) 대표 케이스들로 파일럿 테스트를 해본다.  우리 회사의 뛰어난 개발자 3명과 평범한 개발자 3명에게 이 문제를 풀게 해보고 이를 기준으로 채점표를 만들어야 한다. 어느 누가 평가해도 비슷하게 나오도록 해야 한다. 뛰어난 개발자의 문제 풀이 방식을 기준으로 채점 기준을 만들 수 있다. 예를 들면 다음과 채점 기준이 나올 수 있다.  질문을 5개 이상 한다.코딩하는 과정에서 반복적인 실행을 한다. 4) 면접 후에는 결과에 대한 논의가 필요하다.  특정 항목에 대해 채점 기준이 다른 경우 이에 대한 논의 과정이 필요하다. 이는 면접관의 훈련에 도움이 된다.   4. 실습실제로 면접 문제 만드는 것을 실습해 보자.1) 수강생의 제안다음과 같은 면접 문제는 어떨까요?첫날 출근을 했는데 회사 웹서비스가 죽었습니다. 어떻게 하면 좋을까요? 2) 코칭좀 더 게임스럽게 만들어 본다. 실제 토이 서버를 죽여 놓고, 쉘을 주면서 실제로 어떻게 해결 하는지 살펴본다.옆에 조언을 줄 수 있는 가상의 3년 차 팀원(NPC처럼)을 제공한다. 제한된 답변을 하도록 한다.면접자가 다음과 같은 경우면 더 높은 점수를 줄 수 있다. 실제 업무를 할 때에는 이런 상황까지 이어진다는 것을 유념하자.  문제의 원인을 밝힌 이후에 이 문제를 근본적으로 해결하기 위한 후속조치를 말한다. 개발팀 내에 이 원인과 해결에 대한 공유를 한다.  5. 질문 답변1) 필터링의 목적으로 코딩 테스트는 의미가 있나요? 간단한 문제를 던져서 못 푸는 사람을 필터링하는 것으로는 의미가 있다. 하지만 그 이상의 목적으로 사용하는 것은 조심해야 한다고 생각한다.코딩 테스트라는 과정은 특히 지원자에게 많은 비용이 드는 과정이기 때문에 조금 더 경제적인 방법들이 있다. 예를 들면 “행동 기반 인터뷰”가 있다. 과거에 있었던 행동에 대한 구체적인 질문을 던지는 것이다.또한 코딩 테스트는 지원자에게 상당히 스트레스를 주는 방법이고, 지능이 높은 사람은 오히려 스트레스에 취약하다는 연구가 있다. 따라서 코딩 테스트를 진행하더라도 스트레스를 덜 주는 방향을 고민해야 한다.  2) 블라인드 테스트(이력서를 보지 않고 면접)의 장단점? 결국 코딩 테스트에 적합한 사람을 뽑게 될 것 같다. 코딩 테스트라는 것이 훈련 과정이 필요하기 때문에 입사에 대한 갈망을 볼 수는 있겠다. 질문 시에는 실무와 관련이 깊은 질문을 하면 좋겠다. 역시나 과거의 행동에 기반한 질문이 편향이 적고 많은 정보를 얻을 수 있다. 예를 들면 “팀장이 한 달 걸릴 일을 일주일 만에 끝내라고 한 적이 있나요? 그때 어떻게 하셨나요?”와 같은 질문이다. 3) 끈기, 성실 여부를 판단할 수 있을까요? 주위에서 끈기, 성실이라는 키워드를 생각하면 떠오르는 사람이 있을 것이다. 그 사람의 구체적인 행동을 기반으로 면접 문제를 만들어내는 것이 좋다. 행동에 대한 질문을 할 때에는 과거에 대한 질문을 하는 것이 좋다. 사람은 미래에 대해서는 거짓을 이야기 하가 쉽지만 과거의 이야기를 할 때에는 과거의 상황을 조작하는 동시에 거짓말을 하기가 쉽지 않다.  4) 채용 여부는 실력에 기반하게 되는데, 결국 연봉은 연차에 따라 주게 된다. 좀 더 세밀하게 측정할 수 있는 방법이 있을까? 임시 월급을 주고, 1달 혹은 3달 뒤에 급여를 적용하는 방법이 있다. 실제 환경에서는 보다 정확하게 퍼포먼스를 측정할 수 있다.  하지만 입사할 때 연봉이 중요한 요소가 되지 않게 하는 것이 더 주요한 방법이다. 내재적 동기를 갖게 하는 것이 더 중요하다. 연봉 인상에 따른 동기는 최대 3 달이면 없어진다. 외재적 동기는 점점 내재적 동기를 감소시킨다. 그 일을 즐기지 않게 되고, 하기 싫어지고, 성과가 없어진다. 연봉 말고 다른 협상 거리를 많이 가지고 있어야 한다. 연봉이 여러 가지 조건 중 하나가 되어야 한다.  5) 현재 잘하는 사람을 기준으로 채점 기준을 만들었다면, 다른 장점이 있는 사람이 탈락되지 않을까? 만일 현재 채점기준에는 적합하지 않지만, 다른 측면에서 장점이 있는 사람이 있다면 그 측면을 반영한 채점 기준을 만들어야 한다.  채용에 대해서 틀린 선입견을 가지고 있는 경우가 많이 있다. 예를 들면 술을 잘 먹는 사람이 협력을 잘한다.라고 생각하는 것이다. 그 반례가 있는지를 생각해 보면 그런 선입견을 깨는데 도움이 된다.  6) 비개발자와 함께 면접을 할 때 합의가 힘든 경우가 있다.  회사 안에서 어떤 사람을 뽑고 싶은지 합의가 필요하다. 우리 회사에서 핵심 인재를 추린 다음에 이 사람들의 공통점을 찾아서 인재상을 만들어야 한다.  7) 전화면접 괜찮을까요? 화상면접이 더 효과적인진 않을까요? 억양이 포함되어 있는 대화는 90%의 정보를 전달할 수 있다고 본다. 그 사람의 생각을 충분히 전달받을 수 있기 때문에 화상면접이 크게 더 효과적이라고 생각하지는 않는다.  우리나라에서는 많이 하지 않지만 면접에 대한 비용이 저렴하기 때문에 전화면접이 효과적인 수단이라고 생각한다. 단, 전화면접을 하기 전에 기준이 명확해야 한다. 느낌만으로 판단을 내리는 것은 의미가 없다. 8) 사내 전문가가 없는 영역에 대한 채용을 해야 한다면? 회사 외부의 전문가 몇 분을 찾아가서 그분들의 경험을 듣는다. 그 경험들에 기반해서 면접 문제를 만든다. 도메인에 관계없는 전문성이 있는지는 검증할 수 있는 방법이 있다. 즉, 전문가의 특징이 있다. 전문가는 공부를 한다. 실력을 향상하기 위한 꾸준한 노력을 한다.전문가는 확정적이지 않고 유연하다. 9) 러닝 커브가 좋은 사람을 찾는 방법은? 소규모 회사일수록 현재는 저평가되어 있지만 성장 가능성이 있는 사람을 채용해야 한다. 사실 능력 좋은 사람이 노력도 많이 한다. 뛰어난 사람은 “의도적 수련”의 양이 많고 질이 좋다.  학습에 관련된 테스트를 할 수도 있다. 예를 들어 “새로운 언어로 작은 프로그램을 작성해 보세요. 그리고 그 과정을 타임 로그로 남겨보세요” 와 같은 문제를 보면 학습 자체에 대한 능력을 테스트할 수 있다.  10) 개발을 잘하는 친구는 리드를 안 하려고 하고, 상대적으로 부족한 친구는 리드를 하려고 합니다.  개발을 잘하는 것에 대해서 생각해 볼 필요가 있다. 보통 개발을 잘한다고 하면 코딩을 잘하는 것만 생각하지만 협력에 대한 것이 포함되어야 한다. 흔히 하는 실수가 코딩 실력만 보고 리더를 삼으려고 하는 것이다.  내가 좋아했던 상사를 생각해 보고 그 사람의 특징을 생각해 보는 것부터 시작해 보는 것이 좋겠다. 개발 트랙, 매니저 트랙으로 나눠서 이야기하는 것은 좋지 않다.   6. 후기좋은 시간이었다. 워크숍에 참여하고 나서 어떻게 실력을 검증할것인가에 대해 구체적인 방향이 잡혔다. 우리가 현재 하고 있는 것들 중에 도움이 되는것과 그렇지 않은것이 구분 되었다. 8퍼센트에 좋은 분을 모실 수 있게 하나씩 시도해 봐야겠다.#8퍼센트 #에잇퍼센트 #개발자 #워크숍 #워크샵 #채용워크숍 #채용워크샵 #후기 #참여후기

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 잡학다이너마이트 변규홍 님을 만나보세요:)사진1. 스켈터랩스의 SW Engineer, 변규홍님규홍님의 인터뷰는 2개 파트로 나뉘어져 있습니다. 에서는 인공지능 대화 엔진을 개발에 관한 스켈터랩스 업무 이야기를 담았습니다. 을 아직 읽지 않은 독자들이라면, 먼저 ‘스켈티 인터뷰 w.Kyuhong’을 읽고 오시기를 추천합니다.’PART2. About Kyuhong Byun.Q. 자기 소개에 ‘20년 전부터 컴퓨터 공부를 시작한 컴퓨터 덕후'라는 얘기를 했다. 컴퓨터를 좋아하게 된, 그리고 개발자의 길을 선택한 계기가 따로 있나.A. 초등학교 2학년 때 컴퓨터에 대한 만화책을 우연히 선물받았다. 만화책에서 ‘GW 베이직(GW-BASIC)’언어로 작성된 컴퓨터 프로그래밍 코드가 딱 한 줄 적혀있더라. 그 한 줄을 컴퓨터가 실행하는 과정을 몇 페이지에 걸쳐 설명하는 책이었다. 책을 읽으며, ‘이걸 익힌다면 나도 게임을 만들 수 있지 않을까'란 생각을 했다. 당시 나는 일본의 컴파일(COMPILE)이라는 회사에서 제작한 PC용 게임 잡지인 디스크 스테이션(Disc Station)에 푹 빠져있었다. 그래서 GW베이직을 공부한다면 컴파일 사에 입사해서 아기자기하고 재밌는 게임을 만들 수 있겠다는 꿈을 꾸게되었다.Q. 어렸을 적의 꿈을 현실로 만들기가 쉽지 않지 않나. 어떻게 컴퓨터 공부를 이어갈 수 있었나.A. 어머니를 통해 상업계 고등학교 교과서인 ‘전자계산일반'을 구할 수 있었다. 그 책을 보면서 컴퓨터에 퀵베이직(Quick-Basic) 코드를 하나씩 입력해 보니 신기하게도 전부 그대로 실행이 되더라. 교과서를 따라 만들어보니 간단한 사칙연산을 실행하는 것에 멈추는 컴퓨터 계산기보다 훨씬 똑똑한 복합 연산 계산기까지 만들 수 있었다. 이러한 관심이 자연스럽게 한국정보올림피아드 대회 준비로 이어졌다. 대회를 준비하며 더욱 다양한 프로그래밍 언어를 배웠고, 복잡한 문제를 해결하는 알고리즘과 자료구조 구현법에 대하여 하나씩 접근해갈 수 있었다. 당시 <컴과 대화 맥스>라는 프로그램이 있었는데, 지치지 않고 나와 수다를 떨어주는 프로그램이었다. 사실 맥스는 그닥 똑똑한 프로그램은 아니었다. 툭 하면 무슨 말인지 모르겠다는 응답만 반복했지만, 그렇게 끈덕지게 대답을 이어가고 지치지 않는 다는 점이 재밌었다. 맥스와 대화하면서 맥스보다 더 똑똑하고 흥미롭게 대화를 이어갈 수 있는 프로그램을 만들고 싶은 욕심이 생겼다.Q. 어라, 그렇다면 컴파일 사의 게임프로그래머가 되는 꿈은 접은건가.A. 안타깝게도 2000년대 초에 컴파일 사는 도산했다. 그러나 컴파일 사를 이끌었던 니이타니 마사미츠 회장이 20여년 만에 컴파일마루라는 회사를 세워 게임 개발자로 돌아왔더라. 68세의 나이에 게임 개발은 물론 홍보를 위해 인터넷 방송까지 진행하고 있다. 다시 일어서는 니아티니 회장의 행보를 보면서 자극을 많이 받고있다.Q. 개인적으로 최근 가장 뿌듯함을 느낀 순간을 말한다면.A. 스켈터랩스는 자율출퇴근제를 운영하고 있다. 여기서 ‘자유'가 아닌 ‘자율'이라는 점에 주목해야 한다. ‘자율'이란 자신이 최선의 퍼포먼스를 낼 수 있도록 스스로 알맞은 규칙을 정해서 동료들과 협업함을 뜻한다고 생각한다. 사실 엄격한 출퇴근 시스템을 갖춘 이전 직장에서 스켈터랩스로 넘어오면서 한동안 자기 관리 문제를 겪었다. 체중도 많이 불었다. 건전한 몸에 건전한 정신이 깃든다고 하지 않나. 그래서 회사 근처의 헬스장에 등록하고 PT(Personal Training)을 시작했는데, 입사 초기만 해도 97킬로에 달한 몸무게를 현재는 20킬로 이상 감량한 상태다. 처음에 PT를 받기 시작했을 때 몸은 정말 힘든데, 체중도 변하지 않는 상태가 몇 주간 지속되었다. 스트레스 받고 지치기만 하더라. 그런 시기를 인내하고 견디니, 그제서야 몸에 변화가 온 것을 느낄 수 있었다. 그것도 엄청난 변화를 말이다. 이렇게 나름의 다이어트 성공 가도를 달리고 있는 것이 최근 느낀 뿌듯한 경험 중 하나다.Q. 네임카드(Name Card)에 독특한 자기소개를 발견할 수 있다. 네이버 웹툰 <공대생 너무만화>를 자문했는데, 어떻게 시작하게 되었나.A. 4년 전 카이스트에서 아티스트 레지던시 프로그램에 참여중이셨던 최삡뺩 작가와 인연을 맺게 되었다. <공대생 너무만화>의 자문으로 친구를 소개하는 과정에서 자연스럽게 친구와 함께 자문을 맡게 되었다. 사실 자문이라고 해서 거창한 것은 아니다. 공대 개그에 현실성을 불어넣는다거나 디테일을 살리는 정도다. 예를 들어 기절해 있던 공대 남학생이 이런 말을 들으면 너무 깜짝 놀라 눈을 번쩍 뜰 것 같은 대사를 요청받았다. 마침 당시에 전문연구요원 제도 존폐에 대한 얘기가 오가고 있었고, 이에 ‘전문연구요원 폐지됐대'라는 대사를 만들었다. 이 웹툰은 컷툰 형식으로 구성되어있는데, 해당 컷에 수많은 댓글이 달리는 것을 확인할 수 있었다.Q. 웹툰을 자문하면서 재미있는 일도 많았을 것 같다. 예상하지 못한 독자의 피드백을 받는 재미도 있을텐데, 에피소드를 소개해 줄 수 있나.A. 재미있는 에피소드야 굉장히 많다. <공대생 너무만화>의 이야기는 주인공이 대학에 입학하면서 시작된다. 주인공이 입학할, ‘토목공학과'지만 ‘토목공학과스럽지 않은' 학과 이름이 필요했다. 그래서 ‘사회에코시스템디자인과'라는 이름을 만들어냈다. 그런데 공교롭게도 독자들 사이에서 엉뚱한 오해가 시작되더라. <공대생 너무만화>가 교육부의 프라임 사업(산업연계 교육활성화 선도대학, PRIME) 홍보용 기획이라고. 학과를 통폐합하여 융합학과를 만드는 프라임 사업 때문에 비슷한 이름의 학과들이 생겼으니 그렇게 오해할 만은 했다. 작품이 진행되면서 오해가 풀린 일부 독자들은 아예 <공대생 너무만화>가 프라임 사업 비판 웹툰이라는 창의적인 해석을 내놓기도 하였다. 이런 저런 다양한 오해 속에서도 묵묵히 작업하는 작가분들에 대한 존경심까지 들었다.  사진2. <공대생 너무만화> 15화, 1화, 6화, © 최삡뺩웹툰의 첫 컷에 각종 수학, 과학, 혹은 프로그래밍 관련 문제를 출제하기도 했는데 문제를 받아보는 독자들의 반응이 정말 재미있다. 열심히 문제를 풀기도 하지만 엉뚱한 반응이 나오기도 한다. 한번은 ‘<발받악에 땀 망희 났어>를 아희 프린터로 실행하면 ?이다’라는 문제를 냈다. 딱 보면 발바닥에 땀이 많이 났다는 한국어 문장을 외계어처럼 적은 것처럼 보이지 않나. 그렇지만 사실 ‘아희'라는 프로그래밍 언어로 된 코드다. ‘발받'이라는 코드가 숫자 3과 5를 뜻하고 ‘땀'은 곱셈, ‘망'은 출력이라는 뜻이다. 다시 말해 ‘3과 5를 곱셈하여 출력하시오'라는 코드다. 이 컷의 베스트 댓글은 ‘그냥 한글이라길래 왠지 모르게 순간 설렌 문과입니다'더라. 이외에도 기막히게 재밌는 댓글들이 쏟아졌다. 나중엔 몇몇 아희 인터프리터의 개발자들이 테스트 케이스로 이 문제를 넣어주더라.Q. PT부터 웹툰 자문까지 다양한 활동을 하고있다. 평소의 취미는 무엇인가, 취미 부자로 보인다.A. 일단 서사, 즉 이야기라는 게 담긴 것이라면 뭐든 좋아한다. 만화부터 영화, 소설, 드라마, 연극까지 서사가 있는 콘텐츠는 다양하게 보는 편이다. 일본 스타일의 롤플레잉 게임도 서사가 풍부해서 즐겨 하고있다. SF소설 작성 특강을 듣고 꾸준히 소설도 쓰고 있다. 최근에는 컴퓨터의 기술 표준에 대한 논의에 관심을 갖고 있다. 한국인터넷거버넌스포럼(Kr-IGF, Korean Internet Governance Forum)이라는 행사에 패널로 참여했고, 인터넷 도메인 주소 규칙을 제정하는 KGP(Korean Generation Panel) 회의도 정기적으로 참관하고 있다. 깊은 논의를 거쳐 인터넷 생태계가 건강하고 발전적인 방향으로 운영되기를 바라고 있다.Q. 개발자이지만 다방면에 관심을 갖고 있는 것으로 보인다. 최근에 관심을 가지고 있는 이슈가 특별히 있는지.A. 얼마 전, 소프트웨어 마에스트로(SW Maestro) 과정 홈커밍 데이를 다녀왔다. 과학기술 정보통신부에서 매년 컴퓨터 분야에서 기술이 우수하거나 발전 가능성이 높은 100여명의 연수생과 산업계의 시니어 엔지니어 멘토를 을 선발하고 산업계의 시니어 엔지니어를 멘토로 선정하여 뛰어난 엔지니어로 성장하도록 독려하고 있다. 2010년 선발된 1기 연수생으로 홈커밍데이에 찾아가 보니 8기 연수생까지 폭넓은 연령층의 개발자 선, 후배들과 하루 종일 업계 동향, 최신 기술은 물론 다양한 주제로 이야기를 나눌 수 있었다. 이렇게 개발자로서 성장할 수 있는 기회와 개발자들이 교류할 수 있는 네트워크가 더 풍성해지고 넓어졌으면 좋겠다. 현재도 여러 기업과 비영리조직에서 다양한 캠프, 기술 컨퍼런스를 개최하는 등 다양한 성장과 교류의 장이 만들어지고 있는데, 이를 더욱 활성화하고 지원하여 양질의 개발자 네트워크가 형성되는 데 정부가 할 수 있는 일이 더 있지 않겠나.인공지능 대화 엔진 개발에도 정부의 도움이 절실하다. 다른 언어와 달리 한국어는 특히 엔진 개발을 위한 기초 자료가 너무나 부족한 게 현실이다. 자연언어처리 분야에서는 각 언어마다 이 언어에서 사람들이 실제로 쓰는 문장들을 폭넓게 모아둔 ‘말뭉치’(Corpus)가 기술 발전에 큰 영향을 준다. 특히 문장의 성분을 자세히 분석하여 함께 정리된 말뭉치가 풍성하면 풍성할수록, 머신러닝을 비롯한 다양한 기술에 힘입어 컴퓨터 스스로 사람의 언어를 스스로 학습함은 물론 이를 활용한 더 많은 가능성을 열 수 있다. 그러나 현재는 공개된 말뭉치가 너무 적고, 시대에 따라 개선되는 것도 미약하다. 그나마 안심하고 쓸 수 있는 신뢰도 있는 자료는 2000년대 초반에 구축되고 더 이상 개선이 없는 국립국어원의 ‘21세기 세종 계획’이 전부다. 많은 개발자들이 공통적으로 이 문제를 토로하는데, 어떻게 해야 메시지를 잘 전달하고 개발자끼리도 협업하여 기술 전반을 발전시킬 수 있는지에 대해 고민하고 있다.사진3. 소프트웨어 마에스트로 과정, 과학기술정보통신부가 프로그램을 운영하고 있다. 출처: SW Maestro 과정 페이스북Q. 개발자를 꿈꾸는 이들에게 하고싶은 말이 있다면.A. 수학에는 왕도가 없다고 한다. PT를 받으며 체중을 조절하는 것도 인내의 과정이었다. 개발자의 길도 마찬가지라고 생각한다. 지금 당장 눈 앞에 멋있는 결과를 내기 위해 튜토리얼(Tutorial)만 따라한다면, 단기간 내에 성과를 볼 수는 있지만 새로운 문제에 직면했을 때 스스로 해결책을 찾기 어려워진다. 때문에 튜토리얼을 따라하더라도 그 과정을 세심하게 들여다보고 원리를 이해하기 위해 인내심을 갖고 공부하면 좋겠다. 내가 구현한 코드, 내가 실행시킨 명령이 어떤 가정, 어떤 제반 환경, 어떤 원리에서 작동하는지 궁금해하고 깊이 파다 보면, 자연스럽게 같은 걸 두 번 세 번 공부하지 않고 한번에 깊게 이해할 수 있다.또한 혼자 공부할 경우 다른 사람이 이해하기 좋은 코드를 짜는 것을 소홀히 하게 되는 경향이 있다. 다른 사람이 작성한 코드를 읽어보고, 어떻게 하면 동료들이 이해하기 쉬운 코드를 짤 수 있는지 생각할 수 있을 때 폭넓은 발전을 할 수 있다. 좋은 동료와 함께 공부하는 것을 추천한다. 학생 신분이라면 소프트웨어 마에스트로 과정과 같은 기회를 적극 활용하는 것도 한 방법이다. 실제로 스켈터랩스에도 나를 비롯해 소프트웨어 마에스트로 과정을 거친 엔지니어들이 여러 명 있다.Q. 변규홍님 개인의 꿈은 무엇인가.A. 나와 하루 종일 재미있게 대화하는 챗봇을 개발하고 싶다. 일본어로 된 만화책을 집어넣으면 한국어 번역본이 바로 나오는 컴퓨터 프로그램도 만들고 싶다. 이 꿈을 위해서는 자연언어처리 기술과 머신러닝 발전에 기여하는 것이 우선이라고 생각한다. 그리고 이런 꿈을 함께 꿀 수 있는 좋은 동료를 스켈터랩스에서 더욱 많이 만나고 함께 나아가고 싶다.Q. 마지막으로 하고싶은 말은.A. 내가 가장 동경하는 개발자 중 한 분이 후배들에게 꼭 들려주고 싶은 이야기가 무어냐는 질문에 이렇게 답했다. ‘시간에 쫓겨 살지 말아요. 서두르지 않아도 괜찮아요. 넘어지거든 울어도 돼요. 아무렇지 않은 척 굴지 말고 자기 자신을 좀 더 아껴요.’ 내 생각에 우리 시대의 개발자들은 그 어느 때보다 강도 높은 경쟁 속에 살고 있다. 그 경쟁에서도 이 말을 잊지 말고 자신을 아끼고 돌아보며 살아가면 좋겠다.#스켈터랩스 #사무실풍경 #업무환경 #사내복지 #기업문화 #개발팀 #팀원인터뷰 #팀원소개 #팀원자랑

꽤 많은 분들이 디버거의 존재 자체를 모르고 있거나 혹은 디버거가 있다는 사실은 알아도 그 효용성에 의문을 제기하곤 합니다. 왜냐하면, 우리에겐 Log 클래스나 혹은 printf같은 훌륭한(?) 디버깅 도구가 있다고 생각하기 때문이죠. 물론 이렇게 필요한 변수를 찍어보면서 어떤 곳에서 버그가 있는지를 알아보는 일이 잘못된 일은 아닙니다만 복잡한 여러 상황이 맞물려 재현되는 버그는 이러한 고전적인(?) 방법을 써서 알아보기가 매우 어렵습니다.원인을 정확히 그리고 빨리 파악하려면 디버거의 사용법을 숙지하고 사용하는 것이 가장 좋습니다. 대부분의 개발 환경에서 디버거를 제공하는데 다행히 이클립스에서도 쓸만한 디버거를 내장하고 있습니다.오늘 포스팅에서는 이클립스 디버거 사용법에 대해 다루어 볼까 합니다.이클립스 디버거 뷰이클립스는 디버거 뷰를 제공하여 디버거를 사용할 수 있도록 합니다. 디버거 뷰는 어디에서 확인할 수 있을까요? 바로 우측 상단에 Debug 뷰에 들어가면 그곳에서 확인할 수 있습니다.디버깅의 시작그렇다면 어떻게 디버깅을 활성화한 상태로 프로그램을 실행할 수 있을까요? 상단 메뉴의 Run에서 프로그램을 실행할 때 Debug를 이용하여 프로그램을 실행하면 디버거가 작동하게 됩니다.브레이크 포인트 설정과 뷰보통 디버깅을 할 때 가장 먼저 하는 일이 브레이크 포인트를 잡는 일입니다. 브레이크 포인트를 에러가 일어나는 라인이나 혹은 의심이 가는 변수를 추적할 수 있는 라인쯤에 잡아놓고 프로그램을 디버깅하면 해당 라인을 실행할 때 디버거가 작동하게 되고 그곳에서 프로그램을 라인 별로 진행해가며 관찰을 진행할 수 있게 됩니다.브레이크 포인트 설정은 매우 간단합니다. 편집기 왼쪽에 파란 부분(마커 바)을 더블 클릭하게 되면 파란 원이 생기는데 이 원이 브레이크 포인트입니다. 혹은 오른 클릭하여 Toggle break point를 누르면 됩니다. 설정 후 다시 더블 클릭하게 되면 브레이크 포인트가 사라지게 됩니다.또한, 디버그의 브레이크 포인트 뷰에서 지금까지 걸어놓은 모든 브레이크 포인트들의 위치를 확인할 수 있고 활성화/비활성화, 삭제도 할 수 있습니다. 여러 브레이크 포인트가 걸려있을 때에는 이 탭에서 확인하고 관리하는 것이 더 편합니다.또한, 디버깅을 진행하고 있는 도중에도 다른 의심이 가는 라인에 브레이크 포인트를 걸 수 있습니다.스텝 단위 진행지정한 브레이크 포인트에 다다르면 동시에 디버거가 작동하게 되고 그 라인부터 스텝 단위의 진행을 할 수 있게 됩니다.이제 이 뷰의 버튼들을 이용하여 현재 상황을 진행하거나 되돌릴 수 있습니다. 자주 사용하는 버튼의 사용법을 알아보면Resume : 다음 브레이크 포인트를 만날때까지 진행합니다.Suspend : 현재 작동하고 있는 쓰레드를 멈춥니다.Terminate : 프로그램을 종료합니다.Step Into : 메서드가 존재할 경우 그 안으로 들어가 메서드 진행 상황을 볼 수 있도록 합니다.Step Over : 다음 라인으로 이동합니다. 메서드가 있어도 그냥 무시하고 다음 라인으로 이동합니다.Step Return : 현 메서드에서 바로 리턴합니다.Drop to Frame : 메서드를 처음부터 다시 실행합니다.등이 있습니다.실제로 디버깅 화면에서 버튼들을 눌러보면 쉽게 그 쓰임새를 아실 수 있습니다.변수의 상태 확인을 쉽게 해주는 변수 뷰디버깅을 진행하는 도중 변수의 값이나 객체의 상태를 알고 싶은 상황이 생기게 됩니다. 현재 의심이 가는 변수 이외에도 이 변수에 영향을 끼칠 다른 변수들이나 객체들의 상황을 실시간으로 검사할 필요가 있을 때 변수 뷰를 이용하면 도움을 얻을 수 있습니다.이곳에서 변수나 객체의 상태를 확인하고 변수의 상황에 대해서 저장할 수 있습니다. 변수나 객체의 상황을 모두 저장해서 클립보드에 붙이고 싶은 일이 생기면 해당 변수를 오른클릭 후 Copy Variables를 선택합니다.편집 창으로 돌아가 변수에서 Command + shift + i를 누르게 되면(혹은 오른 클릭 후 Inspect를 선택) Inspector 창이 뜨게 됩니다. 이 창에서 다시 한번 Command + shift + i를 누르면 해당 변수를 Expression 뷰로 보내게 되고 이곳에서 지속해서 변수의 상태를 관찰할 수 있게 됩니다.Expression 뷰 이용Expression 뷰에서는 변수 이름을 입력하거나 수행해보고 싶은 명령어를 직접 입력하여 그 결과 값을 관찰할 수 있습니다. 결과 값을 관찰할 뿐만 아니라 Expression에 써놓은 변수들은 명시적으로 지우지 않는 이상 계속해서 관찰을 수행하기 때문에 변해가는 상황을 지속해서 관찰할 일이 있는 변수나 명령문을 등록해놓기에 좋습니다.Display 뷰 이용디스플레이 뷰에서는 현 문맥에서 사용할 수 있는 명령어를 실행하거나 변수의 값을 조작하는 일을 수행하기에 적합한 환경을 제공합니다. Expression에서도 비슷한 기능을 제공하지만, 디스플레이 뷰를 이용하는 것이 더 편합니다. 메모장과 같이 쉽게 쓰고 지울 수 있기 때문입니다.또한, 원본 코드의 수정 없이 편하게 현재의 맥락을 변화시킬 수 있는 것이 가장 큰 장점이라고 볼 수 있습니다.필요한 명령어들을 적어놓은 후 실행하고 싶은 부분만 드래그하여 수행하거나 혹은 값을 리턴받을 수 있습니다. 지금은 boolean변수 하나의 값을 바꿔보기도 하고 조건 값에 따라 무언가를 리턴 받도록도 해놓은 상황을 스크린 샷으로 담아보았습니다.값을 반환받고 싶을 때는 두 번째 버튼을, 단순히 실행만 할 때에는 세 번째 버튼을 누르면 됩니다.두 번째 버튼을 눌러 값을 반환받는 상황입니다.단순히 실행만 하려면 세 번째 버튼을 누릅니다.브레이크 포인트에 조건 걸기브레이크 포인트에 조건을 거는 것이 굉장히 유용할 때가 있습니다. 특히 반복문안에 들어가 있는 코드들을 디버깅할 때 유용하지요. 반복문의 경우 모든 상황을 검사한다기보다는 특정 조건에서 값이 어떻게 들어가는지를 분석하는 경우가 더 많은데 이러한 상황을 검사하기 위해서 브레이크 포인트에 조건을 걸어야 합니다.브레이크 포인트를 거는 과정까지는 똑같습니다. 브레이크 포인트를 건 후 그 포인트에서 오른 클릭을 하면 Breakpoint properties 옵션이 있는 것을 확인할 수 있습니다. 이 옵션에서 조건문을 설정하여 디버거의 활성화 조건을 설정할 수 있습니다.먼저 Conditional을 활성화하여 어떤 조건에서 디버깅 화면으로 전환할지를 쓰면 되는데 이 창에 조건식을 쓰면 됩니다.또 hit count를 이용하여 조건을 걸 수도 있습니다. hit count에 값을 적용하면 해당 라인에 브레이크 포인트가 hit count만큼 잡힌 이후 디버깅 화면으로 전환하게 됩니다. hit count옵션은 반복문에서 한 100번쯤 이후에 디버깅을 시작하고 싶거나 하는 일이 생길 때 유용하게 쓸 수 있습니다.#스포카 #개발 #개발자 #꿀팁 #조언 #인사이트 #디버거 #디버깅 #디버그 #Eclipse

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언어에 대한 문의나 좋은 의견도 환영합니다.

우선 EOS BP 투료를 한 번쯤 해보신 분들은 매번 새롭게 등장하는 BP 후보들은 넘쳐나고 그들의 이름과 공약을 확인하는 것이 귀찮다고 느끼셨을 수 있습니다.또한 어렵게 공약을 확인하고 정말 이 팀이 EOS를 위해 무엇을 할 수 있는지 다른 팀들과 어떤점이 다른지 꼼꼼하게 비교하여 선거한 여러분의 소중한 투표권 파워는 시간이 지날수록 가치가 줄어들게 됩니다.그렇다면 나 대신에 꾸준히 선거를 대신해줄 사람이 있다면 얼마나 좋을까요?사실 이런 문제에 대해 EOS도 알고 있었으며, 어떤 해결 방법이 있을지 생각해왔습니다.그래서 바로 만들어진 것이 EOS Proxy Voting입니다.Proxy란 ‘대리인’이란 의미를 갖고 있습니다.따라서 EOS Proxy Voting은 EOS BP 대리 투표 시스템을 뜻합니다.이 대리인 투표권을 신청하게 되면 여러분은 더 이상 투표에 대해 고민하실 필요가 없게 되는 거예요!이제 이 Proxy 시스템을 어떻게 이용하는지 방법을 소개하고자 합니다.1. 어떻게 Cleos를 통해 다른 사람에게 나의 투표 권한을 넘길 수 있나요?나의 투표 권한을 Cleos를 통해 다른 사람에게 넘기기 위해선 다음과 같은 명령어를 입력해야합니다.간단하지요? 이 명령어는 eosaccount12가 자신의 투표 권한을 proxyvoter34에게 넘기겠다는 의미를 갖고 있습니다.2. 어떻게 툴킷을 통해 다른 사람에게 나의 권한을 넘길 수 있는 건가요?대표적으로 https://eostoolkit.io/vote/setproxy에서 Proxy를 설정하는 방법을 안내해드릴게요! (참고로 https://www.myeoskit.com/#/tools/proxy/https://eosvoter.eosphere.io 에서도 가능합니다. )나의 proxy를 툴킷을 통해 다른 사람에게 넘기기 위해선 먼저 Scatter 구글 확장 프로그램을 설치해야 합니다.Scatter 설치 후 EOS 계정 및 접속 정보를 Scatter에 등록하셔야 합니다. (Scatter에 정보를 등록하는 방법은 곧 업데이트 하도록 하겠습니다.)그렇다면 등록을 다 하셨을 테니 다음으로 넘어가겠습니다.우선 EOStoolkit에 접속하셔서 스캐터 계정으로 로그인하셔야 합니다.로그인 하셨다면 이제 왼쪽 카테고리에서 [Manage Voting] 항목을 보실 수 있을거에요![Manage Voting]를 클릭하시면 Voting에 관한 여러 항목이 촤르르 나오게 되는데 그 중에 [Set Proxy]를 눌러주세요!자 그럼 아래 화면에 나온 대로 그대로 따라하신 후 저장만 해주시면 됩니다.드디어 투표 권한을 지정 Proxy에게 넘기게 되었습니다.3. 어떻게 내가 설정한 Proxy를 해제할 수 있나요?Proxy 지정을 하고 며칠동안 투표에 신경을 쓰지 않았다가 오랜만에 들어간 투표 사이트에서 내가 지정한 대리인이 행사하는 나의 투표권이 마음에 들지 않을 땐 어떻게 해야할까요?해제를 해야겠지요!그렇다면 지금 내가 지정한 Proxy가 마음에 안들어서 해제하고 싶을 때는 어떻게 할지도 알아보겠습니다.Proxy 설정을 했다면, 저 네모박스에 체크되어 있을겁니다. 그 체크를 해지 하면 간단하게 내가 설정한 Proxy를 해제하게 되는 것입니다.아주 간단하네요.그럼 이제 다음은 내가 직접 Proxy가 되기 위해선 어떻게 할 수 있을지 알아보겠습니다.그 방법도 마찬가지로 Cleos 또는 Toolkit 과 Scatter를 통해 할 수 있습니다.4. Cleos를 통해서 내가 직접 Proxy가 될 수 있는 방법은 어떤게 있나요?내가 직접 Cleos를 통해 Proxy가 되기 위해선 다음과 같은 명령어를 입력해야합니다.이 명령어는 proxyvoter34는 Proxy로 지정되었는 의미를 갖고 있습니다.5. 어떻게 툴킷을 통해 내가 직접 Proxy가 될 수 있는 건가요?우선 툴킷을 통해 Proxy로 등록하기 위해선 가장 먼저https://eostoolkit.io/vote/setproxy 에 나의 Scatter 계정으로 로그인해야 합니다.(참고로 https://www.myeoskit.com/#/tools/proxy/https://eosvoter.eosphere.io 에서도 가능합니다. )로그인 하셨다면 왼쪽 카테고리에서 [Manage Voting]을 찾아주세요!찾으셨다면 해당 항목의 아래 항목에서 [Create Proxy] 를 클릭해주세요. 그럼다음과 같은 화면이 나오게 됩니다.아래 나와있는 설명 그대로 적어주시고 저장해주시면 됩니다. 다 완료하셨으면 드디어 Proxy가 되셨어요!6. 더이상 Proxy로 활동하고 싶지 않으면 어떻게 해야 하나요?더 이상 Proxy로서 활동을 하고 싶지 않다면 마찬가지로 [Manage Voting]를 통해 Proxy 철회를 할 수 있습니다.[Manage Voting]를 클릭 후 아래 항목에서 [Resign Proxy]을 누르시면 됩니다. 첫 번째 Resign 버튼은 Proxy 등록을 해지하는 것이고 두 번째 Unregister 버튼은 등록한 정보를 삭제하는 버튼입니다.각각의 버튼을 눌러 그대로 진행하시면 Proxy 철회가 완료될 거예요!자 여기까지 이제 EOS Proxy Voting을 하기 위해Proxy 설정하는 방법을 알아보았습니다. 어렵게 보이지만 Scatter 연동만 하면 Proxy를 설정하거나 내가 직접 Proxy가 되는 것은 어렵지 않습니다!아 참고로, 현재 등록된 모든 Proxy 리스트를 Aloha EOS Proxy Research Portal에서 확인할 수 있습니다.또한 해당 사이트에서 Proxy들이 자신들이 Proxy로 활동하면서 어떻게 투표를 행사할 것인지에 대한 공약도 자세히 나와있으니 한 번쯤 들어가서 보시면 Proxy를지정하는 데에 있어서도, 내가 직접 Proxy가 됨에 있어서도 도움이 될 거예요!#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심

편집자 주문맥에 따라 ‘Transaction’과 ‘트랜잭션’으로 영어와 한글을 혼용함.문맥에 따라 ‘LOCK’과 ‘lock’으로 대문자와 소문자를 혼용함.OverviewMySQL DB는 일반적인 운영환경에서 뛰어난 성능을 제공합니다. 특히 적은 양의 자료가 빈번하게 교류되는 환경에서는 더욱 빛을 발하죠. 국내에서는 주로 작은 규모의 웹사이트를 구축할 때 MySQL을 사용합니다. 그런데 문제는 사이트의 규모가 커지면서부터 생긴다는 것이죠. 조금씩 느려지는 Query가 생기면 원인도 파악하고, Query를 튜닝하고, 설계도 변경하지만 MySQL의 특징적인 문제를 곧 만나게 됩니다.테이블을 복제(CREATE SELECT)하거나 다른 테이블로 옮기면(INSERT SELECT) 작업을 하는 동안 SELECT 절에 있는 테이블들이 Lock이 걸립니다. 게다가 다른 Session에서 해당 테이블을 수정(UPDATE / DELETE)하면 복제와 이동을 마칠 때까지 대기 상태로 있어야 한다는 것입니다. 이러한 문제는 시스템을 구축하고 자료가 일정량 쌓이기 전까지는 알 수 없습니다. 또한 Oracle과 같은 DB를 사용하던 사용자가, MySQL을 사용하면 이와 같은 문제가 있을 것이라고 생각하기도 어렵습니다.이러한 특징을 가진 MySQL의 Transaction Isolation Level을 알아보고자 합니다. Transaction Isolation Level 은 Transaction의 경리 수준을 말합니다. 트랜잭션 처리 시 다른 트랜잭션에서 접근해 자료를 수정하거나 볼 수 있도록 하는 수준입니다.Transaction Isolation Level의 종류와 특성Transaction Isolation Level에는 READ UNCOMMITTED, READ COMMIITED, REPEATABLE READ, SERIALIZE 네 가지 종류가 있습니다. 1)READ UNCOMMITTED1) COMMIT 되지 않은 데이터에 다른 트랜잭션에서 접근할수 있다.2) INSERT, UPDATE, DELETE 후 COMMIT 이나 ROLLBACK에 상관없이 현재의 데이터를 읽어온다.3) ROLLBACK이 될 데이터도 읽어올 수 있으므로 주의가 필요하다.4) LOCK이 발생하지 않는다.READ COMMIITED1) COMMIT 된 데이터에 다른 트랜잭션에서 접근할 수 있다.2) 구현 방식이 차이 때문에 Query를 수행한 시점의 데이터와 정확하게 일치하지 않을 수 있다.3) LOCK이 발생하지 않는다.4) MySQL에서 많은 양의 데이터를 복제하거나 이동할 때 이 LEVEL을 추천한다.REPEATABLE READ1) Default LEVEL이다.2) SELECT시 현재 시점의 스냅샷을 만들고 스냅샷을 조회한다.3) 동일 트랜잭션 내에서 일관성을 보장한다.4) record lock과 gap lock이 발생한다.5) CREATE SELECT, INSERT SELECT시 lock이 발생한다.SERIALIZE1) 가장 강력한 LEVEL이다.2) SELECT 문에 사용하는 모든 테이블에 shared lock이 발생한다.LOCK과 테이블, 어떻게 해결할 수 있을까?지금부터는 관련된 내용을 확인해보겠습니다. 우선 현재의 경리 수준부터 알아보겠습니다.mysql> SHOW VARIABLES WHERE VARIABLE_NAME='tx_isolation'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | tx_isolation | REPEATABLE-READ | +---------------+-----------------+ 1 row in set (0.00 sec) 다음으로 TEST 테이블을 만듭니다. 이때 SELECT절의 테이블을 UPDATE할 경우, 대기 상태로 빠지는 것을 확인해보겠습니다. 테이블을 만들고 상태를 확인합니다.CREATE TABLE test.TB_PROD_BAS_TEST ( PRIMARY KEY (PROD_ID) ) SELECT T101.PROD_ID ,T101.PROD_NM ,T101.PROD_EN_NM ,T101.PROD_MEMO FROM test.TB_PROD_BAS T101 ; -- 생성시 INFORMATION_SCHEMA.PROCESSLIST 로 상태를 확인합니다. mysql> SELECT -> * -> FROM INFORMATION_SCHEMA.PROCESSLIST -> WHERE USER = 'hansj' -> AND COMMAND <> 'Sleep' -> \G *************************** 1. row *************************** ID: 11004 USER: hansj HOST: 192.168.1.150:50711 DB: test COMMAND: Query TIME: 5 STATE: Sending data INFO: CREATE TABLE test.TB_PROD_BAS_TEST ( PRIMARY KEY (PROD_ID) ) SELECT T101.PROD_ID ,T101.PROD_NM ,T101.PROD_EN_NM ,T101.PROD_MEMO FROM test.TB_PROD_BAS T101 1 row in set (0.00 sec) 다음으로 테이블 생성 시 UPDATE를 해 대기 상태로 빠지는지 확인해보겠습니다.UPDATE test.TB_PROD_BAS SET PROD_MEMO = 'TEST' WHERE PROD_ID = 1 ; mysql> SELECT -> * -> FROM INFORMATION_SCHEMA.PROCESSLIST -> WHERE USER = 'hansj' -> AND COMMAND <> 'Sleep' -> \G *************************** 1. row *************************** ID: 11004 USER: hansj HOST: 192.168.1.150:50711 DB: test COMMAND: Query TIME: 24 STATE: Sending data INFO: CREATE TABLE test.TB_PROD_BAS_TEST ( PRIMARY KEY (PROD_ID) ) SELECT T101.PROD_ID ,T101.PROD_NM ,T101.PROD_EN_NM ,T101.PROD_MEMO FROM test.TB_PROD_BAS T101 *************************** 2. row *************************** ID: 11006 USER: hansj HOST: 192.168.1.150:50719 DB: test COMMAND: Query TIME: 22 *****이부분 중요합니다.****** STATE: updating *****이부분 중요합니다.****** INFO: UPDATE test.TB_PROD_BAS SET PROD_MEMO = 'TEST' WHERE PROD_ID = 1 2 rows in set (0.00 sec) 위의 TIME을 보면 테이블이 생성될 때까지 대기하고, UPDATE 문의 상태가 updating 으로 표시됩니다. 하지만 이렇게 나올 경우 건수가 많으면 실제 UPDATE 중인지 대기상태인지 확인하기가 어렵습니다. LOCK이 걸린 테이블을 확인하려면 INNODB LOCK 테이블로 정확하게 알 수 있습니다. 아래 세 가지 테이블로 확인해보겠습니다. 보다 자세한 설명은 MySQL 홈페이지를 확인합니다.information_schema.INNODB_TRXLOCK을 걸고 있는 프로세스 정보information_schema.INNODB_LOCK_WAITS현재 LOCK이 걸려 대기중인 정보information_schema.INNODB_LOCKSLOCK을 건 정보위의 각 항목마다 테이블 생성 및 UPDATE 시 정보가 어떻게 나타나는지 확인해보겠습니다.1.information_schema.INNODB_TRXmysql> SELECT -> T101.TRX_ID -> ,T101.TRX_STATE -> ,T101.TRX_STARTED -> ,T101.TRX_REQUESTED_LOCK_ID -> ,T101.TRX_WAIT_STARTED -> ,T101.TRX_WEIGHT -> ,T101.TRX_MYSQL_THREAD_ID -> ,T101.TRX_ISOLATION_LEVEL -> ,SUBSTR(T101.TRX_QUERY,1,10)AS TRX_QUERY -> FROM information_schema.INNODB_TRX T101 -> ; +---------+-----------+---------------------+-----------------------+---------------------+------------+---------------------+---------------------+------------+ | TRX_ID | TRX_STATE | TRX_STARTED | TRX_REQUESTED_LOCK_ID | TRX_WAIT_STARTED | TRX_WEIGHT | TRX_MYSQL_THREAD_ID | TRX_ISOLATION_LEVEL | TRX_QUERY | +---------+-----------+---------------------+-----------------------+---------------------+------------+---------------------+---------------------+------------+ | 8771591 | LOCK WAIT | 2019-05-27 16:15:53 | 8771591:70031:4:306 | 2019-05-27 16:15:53 | 2 | 11006 | REPEATABLE READ | UPDATE tes | | 8771586 | RUNNING | 2019-05-27 16:15:51 | NULL | NULL | 1538969 | 11004 | REPEATABLE READ | CREATE TAB | +---------+-----------+---------------------+-----------------------+---------------------+------------+---------------------+---------------------+------------+ 2 rows in set (0.00 sec) TRX_ID_STATE트랜잭션의 상태를 나타냅니다. 실행 중인지 LOCK WAIT 상태인지 알 수 있습니다.TRX_MYSQL_THREAD_IDPROCESSLIST 의 ID를 나타냅니다.TRX_ISOLATION_LEVELISOLATION LEVEL을 나타냅니다.따라서 위의 내용을 보면 CREATE TABLE이 실행 중인 것과, UPDATE가 LOCK WAIT인 것, 그리고 관련된 PROCESSLIST의 ID까지도 알 수 있습니다2.information_schema.INNODB_LOCK_WAITSmysql> SELECT -> * -> FROM information_schema.INNODB_LOCK_WAITS T101 -> ; +-------------------+---------------------+-----------------+---------------------+ | requesting_trx_id | requested_lock_id | blocking_trx_id | blocking_lock_id | +-------------------+---------------------+-----------------+---------------------+ | 8771591 | 8771591:70031:4:306 | 8771586 | 8771586:70031:4:306 | +-------------------+---------------------+-----------------+---------------------+ 1 row in set (0.01 sec) requesting_trx_idLOCK WAIT 인 TRX_IDblocking_trx_idLOCK 을 건 TRX_ID현재 LOCK이 걸린 TRX_ID와 LOCK을 걸어둔 TRX_ID를 알 수 있습니다.3.information_schema.INNODB_LOCKSmysql> SELECT -> * -> FROM information_schema.INNODB_LOCKS -> ; +---------------------+-------------+-----------+-----------+----------------------+------------+------------+-----------+----------+-----------+ | lock_id | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data | +---------------------+-------------+-----------+-----------+----------------------+------------+------------+-----------+----------+-----------+ | 8771591:70031:4:306 | 8771591 | X | RECORD | `test`.`TB_PROD_BAS` | PRIMARY | 70031 | 4 | 306 | 1 | | 8771586:70031:4:306 | 8771586 | S | RECORD | `test`.`TB_PROD_BAS` | PRIMARY | 70031 | 4 | 306 | 1 | +---------------------+-------------+-----------+-----------+----------------------+------------+------------+-----------+----------+-----------+ 2 rows in set (0.01 sec) lock_trx_idLOCK 과 관련된 TRX_IDlock_modeX 쓰기, S 읽기 2)어떤 테이블이 LOCK을 걸고 있는지 알 수 있습니다.위의 내용들을 통해 REPEATABLE READ에서 CREATE SELECT시 SELECT 테이블에 LOCK이 걸려 UPDATE가 대기하게 되는 것을 알 수 있습니다. 이번에는 Transaction Isolation Level 을 READ COMMIITED로 변경하고 CREATE SELECT 및 UPDATE를 진행해보겠습니다.SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; SHOW VARIABLES WHERE VARIABLE_NAME='tx_isolation'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | tx_isolation | READ-COMMITTED | +---------------+-----------------+ 1 row in set (0.00 sec) UPDATE 문은 다음과 같이 수행됩니다. mysql> UPDATE test.TB_PROD_BAS -> SET PROD_MEMO = 'TEST' -> WHERE PROD_ID = 1 -> ; Query OK, 0 rows affected (0.04 sec) Rows matched: 1 Changed: 0 Warnings: 0 기존에 대기했던 것과 다르게 0.04초가 걸렸습니다.mysql> SELECT -> * -> FROM INFORMATION_SCHEMA.PROCESSLIST -> WHERE USER = 'hansj' -> AND COMMAND <> 'Sleep' -> \G *************************** 1. row *************************** ID: 11004 USER: hansj HOST: 192.168.1.150:50711 DB: test COMMAND: Query TIME: 9 STATE: Sending data INFO: CREATE TABLE test.TB_PROD_BAS_TEST ( PRIMARY KEY (PROD_ID) ) SELECT T101.PROD_ID ,T101.PROD_NM ,T101.PROD_EN_NM ,T101.PROD_MEMO FROM test.TB_PROD_BAS T101 1 row in set (0.00 sec) -- 프로세스 정보도 CREATE TABLE 만 진행중임을 알수 있습니다. mysql> SELECT -> T101.TRX_ID -> ,T101.TRX_STATE -> ,T101.TRX_STARTED -> ,T101.TRX_REQUESTED_LOCK_ID -> ,T101.TRX_WAIT_STARTED -> ,T101.TRX_WEIGHT -> ,T101.TRX_MYSQL_THREAD_ID -> ,T101.TRX_ISOLATION_LEVEL -> ,T101.TRX_QUERY -> FROM information_schema.INNODB_TRX T101 -> ; +---------+-----------+---------------------+-----------------------+------------------+------------+---------------------+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | TRX_ID | TRX_STATE | TRX_STARTED | TRX_REQUESTED_LOCK_ID | TRX_WAIT_STARTED | TRX_WEIGHT | TRX_MYSQL_THREAD_ID | TRX_ISOLATION_LEVEL | TRX_QUERY | +---------+-----------+---------------------+-----------------------+------------------+------------+---------------------+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 8771856 | RUNNING | 2019-05-27 17:17:45 | NULL | NULL | 4594347 | 11004 | READ COMMITTED | CREATE TABLE test.TB_PROD_BAS_TEST ( PRIMARY KEY (PROD_ID) ) SELECT T101.PROD_ID ,T101.PROD_NM ,T101.PROD_EN_NM ,T101.PROD_MEMO FROM test.TB_PROD_BAS T101 | +---------+-----------+---------------------+-----------------------+------------------+------------+---------------------+---------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) READ COMMITTED LEVEL로 CREATE만 수행 중인 것을 알 수 있습니다.mysql> SELECT -> * -> FROM information_schema.INNODB_LOCK_WAITS T101 -> ; Empty set (0.00 sec) mysql> SELECT -> * -> FROM information_schema.INNODB_LOCKS -> ; Empty set (0.00 sec) LOCK을 걸고 걸린 것이 없어 내용도 없습니다.Conclusion지금까지 Transaction Isolation Level 을 기준으로 CREATE SELECT 시 SELECT 에 사용되는 테이블도 LOCK이 걸릴 수 있는 것을 확인했고, 그에 따른 해결 방법까지 알아봤습니다.INSERT INTO SELECT에서도 같은 현상이 나타납니다. 그렇기 때문에 운영 중인 테이블을 복제(CREATE SELECT)하거나 다른 테이블로 옮길 경우(INSERT SELECT) Transaction Isolation Level을 READ COMMITTED 변경하고 작업하기를 권장합니다.그렇지 않으면 관련된 TABLE은 LOCK이 걸리고, 관련 Query들이 대기 상태로 빠지면서 시스템 장애가 발생할지도 모릅니다.참고1)MySQL :: MySQL 5.6 Reference Manual :: 14.7.2.1 Transaction Isolation Levels2)MySQL :: MySQL 5.6 Reference Manual :: 14.7.1 InnoDB Locking글한석종 부장 | R&D 데이터팀[email protected]브랜디, 오직 예쁜 옷만

칸반과 스크럼을 섞은 I/O 트렐로 보드코드리뷰코드리뷰를 말씀드리기 전에 I/O의 개발 프로세스부터 소개해 드리겠습니다. 저희 SW 엔지니어들은 칸반보드를 일주일 주기(sprint)로 진행해 나갑니다. devops 도입을 위해 이 개발 프로세스를 설계 하였는데요. Sprint 주기인 working day 5일 동안 이번 주안에 개발을 끝내야 하는 feature 1개와 지난 주에 개발을 마친 feature 1개의 알파테스트 그리고 지지난 주에 개발된 feature 1개의 베타테스트가 동시에 진행됩니다. 즉, 3개의 phase 가 매순간 공존하는 프로세스 입니다.코드리뷰 도구로는 bitbucket의 pull request를 사용하기로 했습니다. I/O에 있는 5명의 SW 엔지니어들은 각자 필수로 리뷰 받야할 짝꿍이 정해져 있습니다. Sprint동안 개발한 피쳐 혹은 hotfix를 merge(배포)하기 위해서는 반드시 pull request과정을 거쳐야합니다. 즉, 짝꿍을 포함한 최대 4명에게 pull request를 요청할 수 있습니다. Sprint동안 개발된 feature는 가급적 매주 목요일에 pull request하기로 하였으며 SW엔지니어들은 목요일엔 코드 리뷰 시간을 할애해 두기로 약속 했습니다.이러한 개발환경 아래 지난 2주간 제가 기억하는 pull request는 4개 였습니다. 총 review해야할 commit 수가 22개로 평균 pull request당 5.5개의 commit 을 리뷰해야 했습니다. 알파테스트에서 발생한 마이너한 hotfix는 pull request없이 merge된 걸로 알고 있어 제가 놓친 commit들도 존재 했습니다. Jira로 Ticket 관리를 안하다보니 위에 첨부된 이미지 처럼 Trello 카드링크가 카드의 제목(유즈케이스)으로 나오지 않아 조금 불편하기도 합니다.Pull reqest에 달린 Comment들.일단, bitbucket으로 코드리뷰를 2주간 진행 해보니 엔지니어간의 유대감이 생기는 느낌이 들었습니다. 그 전에는 구현상의 이슈를 이야기 나누는 수준에서 머물렀는데 이제는 서로가 직접 짠 코드를 공유하다보니 확실히 느낌이 달라졌습니다. 처음으로 목욕탕을 함께 다녀온 친구가 된 느낌이랄까요… 저만 그렇게 느꼈을 수도 있구요. 확실한 건 엔지니어마다의 개발 스타일을 파악할 수 있게되어 엔지니어와 대화할 때 상대방의 스타일에 맞춰서 낭비가 적은 커뮤니케이션을 수행할 수 있게 되었습니다.Exception Hadling feedbackMagic Number feeback뿐만아니라 위의 이미지 두 장 처럼 개발상의 안좋은 냄새를 리뷰과정에서 감지하여 개발자에게 바로바로 피드백해 줄 수 있었습니다. 물론, 좋은 개발 방식이나 설계내용을 배울 수도 있었구요.TDD(테스트주도개발)테스트주도개발의 개발 리듬 : 출처 : 구글 이미지 검색Sprint의 feature scope을 극단적으로 작게 줄여버리니 TDD 공부에 엔지니어들이 매진했습니다. 각자 포지션에 맞는 책을 하나씩 끼고 충분히 TDD을 깊게 파고 들어갔는데요. 결과적으로 안드로이드, iOS 엔지니어는 4주만에 TDD의 기본기를 확실하게 다질 수 있었습니다.안드로이드 엔지니어의 경우 최근 2주 동안 정말 놀랍게 성장했는데요. 지난 I/O diary 8에서 소개된 안드로이드의 switcher sorting 클래스는 SUT로 만들기 쉽지 않은 legacy class였습니다.그러나, 안드로이드 엔지니어가 켄트백의 TDD 책을 14장까지 정독하면서 상황을 완전히 뒤바꿔 버렸습니다. 예제로 나오는 통화 프로그램을 한 줄 한 줄 키보드로 직접 따라 쳐가며 긴호흡으로 책을 정독함으로써 자연스럽게 객체지향으로 변해가는 설계 리펙토링 원리를 피부로 체험할 수 있었는데요. 그덕에 지난 주에 진행된 소프트웨어 세미나에서 공개된 리팩토링된 switcher sorting 클래스 로직은 보기좋게 간결해졌습니다. 기존 코드의 test함수는 switcher sorting 클래스의 많은 기능을 1개의 테스트 함수에서 다 집어 넣고 검증하려다 보니 함수 길이가 50줄 이상 되어 가독성이 무척 떨어졌었는데요. 그러나, 리팩토링된 test class에는 약 5개의 test 함수(setup, teardown 제외)로 적절하게 나뉘어 리뷰어가 참 읽기 좋게 코드가 작성되었습니다. 각 test 함수도 적당한 길이로 짜여서 테스트 코드를 읽으면서 자연스럽게 설계의도를 파악할 수 있었습니다. 이렇게 단시간에 TDD를 체화한 엔지니어니어들을 보면 신기할 따름입니다.느낀점출처 : 구글 이미지 검색devops가 성공적으로 도입되려면 당분간은 완급조절이 핵심인것 같습니다. 새로운 것을 마구잡이로 도입하기보다 지금은 코드리뷰와 TDD에만 집중 할 수 있도록 팀환경을 만들어 줘야 할것 같습니다. 지난 6월 1주차에는 제가 scope 조절에 실패해서 개발 phase의 feature가 무지 무거웠습니다. 그로인해, 안드로이드 엔지니어는 테스트코드를 짤 여유가 없었습니다. 제 실수로 결국 기술부채가 쌓이고 말았습니다. 당분간 기술부채를 털어내기로 해놓고 말과 행동이 다른 사람이 되어버렸습니다. 6월 30일까지는 조바심 내지말고 TDD와 코드리뷰가 몸에 완전히 익을 때까지 feature scope가 충분히 작게 설정되도록 신중에 신중을 가해야할 듯합니다. 과도한 업무량에 좇겨 엔지니어들이 Test code coverage가 낮아지거나 코드리뷰 없이 코드가 배포되지 않도록 팀 완급조절에 지속적으로 관심을 쏟아야 겠습니다.#스위쳐 #Switcher #DevOPS #데브옵스 #개발 #개발자 #문제해결 #도입기 #인사이트