스토리 홈

인터뷰

피드

뉴스

조회수 1837

Circle CI에서 rbenv를 이용해서 Ruby 2.2와 CocoaPods 0.39 버전 사용하기

최근 Circle CI에서 Ruby 버전을 2.3으로, CocoaPods 버전을 1.0으로 업그레이드함에 따라 발생하는 빌드 문제를 rbenv를 이용해서 해결한 경험을 공유합니다. 최종적으로 완성된 Gemfile과 circle.yml 파일은 마지막 섹션에서 확인하실 수 있습니다.1. CocoaPods 1.0지난 2015년 12월에 CocoaPods 1.0.0 베타 버전이 처음 공개되었습니다. CocoaPods이 1.0 버전으로 업그레이드되면서 굉장히 많은 변화가 있었는데요. 가장 큰 변화는 DSL입니다. 추상 타겟Abstract Target과 타겟 상속Target Inheritance이 새롭게 소개되면서, 0.39 버전까지 자주 사용되던 link_with 및 :exclusive => true와 같은 구문이 제거되었습니다.이에 따라 기존에 사용하던 Podfile이 CocoaPods 1.0 버전과는 호환되지 않는 문제가 발생했습니다. 이를 해결하기 위한 가장 좋은 방법은 새로운 DSL을 사용하여 Podfile을 다시 작성하는 것이지만, 꽤 많은 서드파티 라이브러리를 사용하는 StyleShare의 경우 새로운 DSL을 적용하여 빌드하면 각종 문제로 인해 빌드가 정상적으로 이루어지지 않았습니다. 4년동안 유지되고 있는 프로젝트이다보니, 레거시 Objective-C 코드와 라이브러리, 그리고 새로운 Swift 코드와 라이브러리가 혼용되어 사용되는 것도 원인 중 하나일 것입니다.따라서 StyleShare에서는 CocoaPods 0.39 버전을 사용하기로 결정을 했습니다. 하지만 최근 Circle CI에서 CocoaPods 버전을 공식적으로 1.0 버전으로 업그레이드하면서 빌드가 깨지기 시작했습니다. Circle CI 환경에서 CocoaPods 0.39 버전을 사용하려면 어떻게 해야 할까요?▲ ㅠㅠ2. Bundler를 이용해서 Gem 관리하기Bundler는 Ruby로 작성된 라이브러리들의 버전을 관리해주는 강력한 도구입니다. CocoaPods에서 Podfile에 의존성을 기재하듯, Bundler에서는 Gemfile에 의존성을 기재합니다.source 'https://rubygems.org' gem 'cocoapods', '~> 0.39' $ gem install bundler 명령어를 사용하면 Gemfile에 기재된 의존성 라이브러리들을 설치해줍니다. 이렇게 설치된 CocoaPods을 사용할 때에는 $ pod COMMAND 대신 $ bundle exec pod COMMAND 명령어를 사용해야 합니다.$ gem install bundler $ bundle install --path vendor/bundle $ bundle exec pod --version 0.39.0 3. Ruby 2.3과 CocoaPods 0.39Bundler를 사용해서 CocoaPods 0.39 버전을 사용하기만 하면 모든 문제가 해결될 줄 알았습니다. 하지만 더 큰 삽질이 남아있었는데요. 바로 Ruby 2.3 버전이 CocoaPods 0.39 버전과 호환되지 않는 것이었습니다.$ bundle exec pod install Updating local specs repositories Analyzing dependencies 신나게 $ bundle exec pod install 명령어를 실행하니, 의존성을 분석하는 듯 싶다가 갑자기 에러를 주르륵 뱉습니다. 에러 로그의 #### Error 항목을 보면 에러 메시지가 나와있습니다.NoMethodError - undefined method `to_ary’ for #이 에러 메시지로 CocoaPods GitHub 저장소의 이슈를 검색해보면 꽤나 많은 이슈가 올라와 있습니다. 이 이슈들을 보면, 모두 Ruby 버전이 2.3이라는 공통점이 있습니다. Ruby 버전을 2.2로 내렸더니 문제가 해결됐다는 댓글들도 굉장히 많고요. Circle CI의 Ruby 버전을 2.2로 낮추면 문제가 해결될 것 같습니다.Circle CI 문서 내용에 따라 circle.yml에 Ruby 버전을 기재해봅시다.machine: ruby: version: 2.2.5 그러나 Circle CI의 OS X 컨테이너에서는 Ruby 버전 변경을 지원하지 않는다고 합니다.▲ ㅠㅠ (2)4. rbenv를 이용해서 Ruby 2.2 사용하기그러다가 알게된 것이 바로 rbenv입니다. rbenv를 사용하면 여러개의 Ruby 버전을 깔끔하게 관리할 수 있게 됩니다. rbenv는 Homebrew를 사용해서 쉽게 설치할 수 있습니다.$ brew install rbenv rbenv는 ~/.rbenv 디렉토리에 안에 여러 Ruby 버전을 설치하고 관리합니다. rbenv를 설치한 뒤 가장 먼저 할 일은 환경변수 $PATH를 설정해주는 것입니다. $PATH에는 $HOME/.rbenv/shims와 $HOME/.rbenv/bin 경로가 포함되어있어야 합니다.4.1 환경변수 설정하기Circle CI에서는 환경변수를 설정하는 편리한 인터페이스를 제공합니다. 하지만, Circle CI에서 실행되는 각 명령어는 별도의 쉘에서 실행됩니다. 그말인 즉슨, 각 명령어가 실행되기 직전에 새로운 쉘이 실행되고, $PATH 환경변수를 덮어쓰는 .bash_profile이 실행된 후 명령어가 실행된다는 뜻인데요. 이렇게 될 경우 $PATH 환경변수의 가장 우선순위는 항상 /usr/local/bin이 가지게 됩니다. 그리고 같은 이유로 $ export FOO=bar와 같은 명령어도 사용할 수 없게 됩니다.1고민을 하다가 생각해낸 방법은 바로 .bash_profile의 내용을 변경(!)하는 것입니다. 그렇게 되면 우리가 원하는 $PATH를 항상 우선순위로 둘 수 있게 됩니다. 아래와 같이 환경변수를 설정하는 명령어를 .bash_profile의 가장 아랫줄에 삽입하도록 설정했습니다.machine: pre: - echo "export PATH=\$HOME/.rbenv/shims:\$HOME/.rbenv/bin:\$PATH" >> .bash_profile - echo "export RBENV_SHELL=bash" >> .bash_profile 4.2 rbenv에 Ruby 2.2 설치하기그 다음으로 할 일은 원하는 Ruby 2.2 버전을 설치하는 것입니다. $ rbenv install -l을 사용해서 설치 가능한 모든 Ruby 버전을 조회할 수 있고, $ rbenv install 2.2.5 명령어를 사용해서 2.2.5 버전을 설치할 수 있습니다.$ rbenv install -l Available versions: 1.8.5-p113 1.8.5-p114 1.8.5-p115 1.8.5-p231 ... $ rbenv install 2.2.5 이렇게 설치된 버전은 두 가지 방법으로 사용될 수 있습니다. 한 가지 방법은 시스템 전체에서 사용하는 것이고, 다른 한 가지 방법은 프로젝트 단위로 사용하는 방법입니다. 시스템 전체에서 사용하려면 $ rbenv global 2.2.5 명령어를, 프로젝트 단위로 사용하려면 $ rbenv local 2.2.5명령어를 사용합니다.global 명령어를 사용해서 Ruby 버전을 선택하면 ~/.rbenv/version 파일에 선택된 버전이 기록됩니다.$ rbenv global 2.2.5 $ cat ~/.rbenv/version 2.2.5 local 명령어를 사용하면 현재 디렉토리의 .ruby-version 파일에 선택된 버전이 기록됩니다.$ rbenv local 2.2.5 $ cat .ruby-version 2.2.5 local 명령어로 선택된 Ruby 버전은 global 명령어로 선택된 Ruby 버전보다 우선순위가 높습니다. $ rbenv version 명령어를 사용하면 현재 선택된 버전을 확인할 수 있습니다.$ rbenv version 2.2.5 (set by /project/path/.ruby-version) Circle CI에서는 편의를 위해 global 명령어를 사용해서 Ruby 버전을 선택하도록 했습니다.dependencies: pre: - brew update - brew install rbenv - rbenv install 2.2.5 - rbenv global 2.2.5 4.3 Bundler 다시 설치하기rbenv를 사용해서 새로운 Ruby 버전을 설치했기 때문에, Circle CI 시스템에서 제공하는 Gem도 다시 설치해야 합니다. 우리는 Bundler로 Gem 의존성을 관리하기로 했으므로, Bundler만 재설치합니다.$ gem install bundler --no-ri --no-rdoc $ rbenv rehash $ gem install 명령어를 실행한 후에는 $ rbenv rehash 명령어를 실행해서 executable 경로들을 재설정해주어야 합니다.4.4 ~/.rbenv 경로 캐싱하기rbenv를 사용해서 Ruby를 설치하는 과정이 굉장히 오래 걸립니다. 이 경우, Circle CI에서 제공하는 캐싱 기능을 사용해서 이 과정을 한 번만 하고 건너뛸수 있게 됩니다.dependencies: cache_directories: - ~/.rbenv 위와 같이 circle.yml를 설정해주면 컨테이너 실행시 ~/.rbenv 디렉토리가 캐시로부터 설정됩니다. 캐싱된 디렉토리를 사용하는 경우 Ruby 버전이 미리 설치되어있기 때문에 $ rbenv install시에 --skip-existing 옵션을 추가해주어서 캐싱된 버전을 재설치하지 않도록 합니다.5. 마치며최종적으로 완성된 Gemfile과 circle.yml 파일은 다음과 같습니다.Gemfilesource 'https://rubygems.org' gem 'cocoapods', '~> 0.39' circle.ymlmachine: pre: - echo "export PATH=\$HOME/.rbenv/shims:\$HOME/.rbenv/bin:\$PATH" >> .bash_profile - echo "export RBENV_SHELL=bash" >> .bash_profile xcode: version: 7.3 dependencies: cache_directories: - ~/.rbenv pre: - brew update - brew install rbenv - rbenv install 2.2.5 --skip-existing - rbenv global 2.2.5 - gem install bundler --no-ri --no-rdoc - rbenv rehash - bundle install --path vendor/bundle override: - bundle exec pod --version - bundle exec pod install https://circleci.com/docs/environment-variables/#custom ↩#스타일쉐어 #개발 #개발자 #개발팀 #후기 #일지 #인사이트
조회수 1054

AndroidAnnotations 과 테스트

이 포스팅은 총 4부로 이어지며 현재는 4부입니다.1부 : Android, MVC, MVVM, MVP2부 : Android 와 Annotation3부 : AndroidAnnotations 과 MVC4부 : AndroidAnnotations 과 테스트앞선 3개의 포스팅을 통해 AndroidAnnotations 과 MVC 가 view 에 관여하는 동작들이 모두 View 로 분리된 것을 확인할 수 있습니다.이러한 구조덕분에 Model 에 대한 테스트와 View 에 대한 테스트가 명확히 구분지어지게 되었습니다.Test 코드를 작성함에 있어서 View 에 대한 테스트가 다소 어려움이 있다는 것을 감안한다면 Model 에 대한 테스트만 집중할 수 있는 구조가 테스트에 대한 접근을 더욱 쉽게 해줍니다.다음은 앞선 포스팅에서 정의된 코드 중에서 Model 에 대한 테스트입니다.※ 테스트코드는 Robolectric 을 이용하여 작성하도록 하겠습니다.Model Test@RunWith(RobolectricGradleTestRunner.class) public class MainModelTest { private MainModel mainModel; @Setup public void init() { mainModel = new MainModel(Robolectric.application); } @Test public void testGetReleaseState() { // given String version = "3.19" // not yet released // when boolean isReleased = mainModel.getReleaseState(version); // then assertThat(isReleased, is(equalTo(false)); // given version = "3.18" // released // when isReleased = mainModel.getReleaseState(version); // then assertThat(isReleased, is(equalTo(true)); } }위와 같이 Model 만 별도로 테스트가 용이해졌습니다.Presenter TestPresenter 에 대한 테스트는 Model 에 대한 테스트와 다릅니다.Activity 에 커플링이 높기 때문에 해당 Activity 를 직접 바인딩해야 합니다.@RunWith(RobolectricGradleTestRunner.class) public class MainViewTest { private MainActivity mainActivity; private MainView MainView; @Setup public void init() { mainActivity = Robolectric.buildActivity(MainActivity.class).create().start().resume().get(); MainView = mainActivity.mainView; } @Test public void testGetVersionText() { // given String version = "3.19" // when MainView.versionEditText.setText(version); // then assertThat(MainView.getVersionText(), is(equalTo(version)); } }Jandi Team은 View 를 테스트하기 위해서 Presenter 와 Activity 의 패키지 Level 을 같은 Level 로 유지하고 있습니다.AndroidAnnotations 에서 DI 를 설정하기 위해서는 해당 변수나 메소드는 최소 Package Scope 로 정의해야하기에 위와 같은 형태의 Field 접근을 볼 수 있습니다.정리AndroidAnnotations 를 활용한 MVC 패턴의 전환의 또다른 이점은 이와 같이 테스트를 명확히 분리할 수 있다는 장점을 주었습니다. 물론 이 방법은 MVVM, MVP 로 구현하였을때보다 나은 형태라 할 수는 없으나 View 에 대한 테스트가 좀 더 용이해진 것이라 생각합니다.※ Activity 는 왜 테스트하지 않나요?MVP 패턴에서 Activity는 Controller 의 모습을 지니고 있습니다. 이는 Unit Test 가 아닌 Behavior 테스트에 가까운 모습이며 다른 방식으로의 테스트코드 구현이 필요하다고 생각합니다.#토스랩 #잔디 #JANDI #개발 #개발자 #개발팀 #기술스택 #일지 #후기 #꿀팁 #인사이트
조회수 2768

야놀자 기술 블로그 만들기

Hello world!저는 CX서비스실에서 기획을 담당하고 있는 강미경입니다. R&D 그룹의 기술 블로그, 그 영광의 첫 포스트로 개발의 보람을 대신할 수 있어 기쁩니다. 오늘은 ‘기획자가 어쩌다가’ 기술 블로그를 만들게 되었는지 얘기해보려고 합니다.왜 기술 블로그인가제가 야놀자에 입사한 지 만 1년이 되었습니다. 입사하면서 가진 개인적인 목표 중의 하나는 블로그를 운영하는 것이었습니다. 저는 오래전부터 개인 블로그를 운영하고 있고, 외부 커뮤니티 활동에서도 팀 블로그를 운영합니다. 그래서 개발자에게는 기술 블로그에 쓸 글을 작성하는 것보다 코딩을 하는 게 더 쉬울 정도로, 글 쓰는 고통이 남다르다는 것도 알고 있지요.하지만 ‘알고 있다’고 생각하는 정보를 정리하고 그것이 잘 전달될 수 있도록 하는 것은 개발실력과는 약간은 다른 영역의 것이기도 합니다. 그래서 테크 스웩이 넘치는 블로그가 아니더라도, 꾸준히 스토리를 전달하면 그게 개인과 조직의 히스토리로써의 가치가 충분하다고 생각했습니다. 무엇보다 조직 자체의 성장에 큰 밑거름이 되고요.블로그를 시작해보자기술 블로그를 하자는 말에, 놀랍게도 한결같이 ‘관심만’ 주더군요(…) 평소 업무가 많고 바쁨을 떠나서, 보람보단 책임만 남아 유지보수 대상이 되어버릴 가능성이 무궁하지 않겠습니까. 하지만 목마른 사람이 우물을 파라고, 개발자의 도움 없이 블로그를 만들 각오를 하기에 이르렀습니다.(과거의 나를 규탄…#야놀자 #개발팀 #블로그 #인사이트 #경험공유
조회수 3739

크몽 개발팀 문화와 구조 이야기

안녕하세요. 크몽 개발자들과 함께하고 있는 크레이그(a.k.a. 크알)입니다.크몽 개발자 그룹은 1년 내 그 규모가 3배로 커지고, Data Science, Growth Hacking 조직이 만들어지는 등 질적, 양적으로 급성장하고 있는 팀입니다.크몽 개발 부서에 계신 분들은 크몽에 대해 이렇게 이야기 합니다.(참고 : 크몽 개발팀원 더팀스 인터뷰 - '신뢰할 수 있는 동료와 함께 초고속 성장을 만들어가는 크몽 팀' )"제가 크몽에서 전반적으로 느낀 인상은 능동적인 분들이 많다는 거예요. 수동적인 업무를 책임감 있게 하는 것도 중요하지만 문제를 스스로 찾고, 동료들에게 제기하고, 문제를 해결했을 때 진심으로 기뻐하면서 행복감을 느끼시는 분들이 많아요. 그게 큰 조직에 있다가 온 저에게는 정말 많은 자극이 되었어요. "- 데이터분석 KM님"크몽이 저의 개발자 커리어에서 마지막 회사였으면 좋겠다고 생각해요. 실은 진심이고요. 그동안 회사의 성장을 지켜봤고 개발적으로도 많은 변화를 경험했어요"- BackEnd Sean님이렇게 개발자들이 행복하게 개발할 수 있는 환경을 우선시하고 있습니다. 그리고 크몽의 오픈 커뮤니케이션 문화를 지향함과 동시에 ‘Work Happy’와 'Freedom with Responsibility’ 란 가치 아래 최대한 자율성을 보장된 실무자 중심의 개발 문화를 추구합니다.크몽 개발 조직 구조위 핵심 가치 아래 크몽 개발 조직 구조는 크게 ‘Go’와 ‘Chapter’로 구성되어 있습니다.Go  ; 고우선 ‘Go’는 프로젝트 개발 팀 단위로 크몽 서비스를 개선하기 위한 목표 중심의 조직입니다. 다른 회사에서는 ‘Silo’, ‘Team'로 명칭 하기도 합니다. 물리적으로 한 공간에서 스크럼을 이루어 일할 수 있도록 자원을 갖추고 있습니다. Go 안에는 Go Leader(GL) 가 있어 팀 업무 관리 및 우선순위를 정합니다.현재 크몽 개발 파트의 Go는 아래와 같이 구성되어 있습니다.UX-Go크몽 서비스 UX를 개선하기 위한 목표로 데이터를 기반으로한 UX Iteration & Growth Mission 을 수행하는 팀Data-Go데이터 파이프라인을 구축, 활용하여 조직 내 필요한 데이터 자료를 공급하고, 크몽 서비스안에 머신러닝/딥러닝 등의 인공지능 기술 영역을 담당하는 팀Dasi-Go서비스 안정적인 운영 및 릴리즈,  CRM 기술 지원을 담당하는 팀Mobile-Go검색 서비스, 서비스 카테고리 개선 등 크몽 서비스 향상을 위한 모듈 개발팀크몽 라운지Chapter  ; 챕터'Chapter'는 직군별 조직 단위로 주 1회 정도의 커뮤니케이션 타임을 통해 업무 및 기술 동향을 교환합니다. 더불어 챕터 안에서 필요한 스터디, 외부 교육 등의 직군별 자기 능력 향상을 도모하고, 회사에선 이를 적극 지원합니다. 그리고 챕터 내 프로젝트를 통해 서비스 개선에 기여하기도 합니다.크몽 개발 파트는 아래와 같은 챕터가 있습니다.(참고 : 웹 프로트엔드 챕터의 'gulp 개선기' -  https://brunch.co.kr/@kmongdev/5 )**챕터 프로젝트는 챕터 내에서 개발자분들이 스스로 필요하다는 판단 하에 빌딩 된 프로젝트입니다. 챕터 내에는 CL(Chapter Leader)가 존재하며, Chapter 구성원 관리 및 의견을 모아 조직에 전파하는 역할을 담당합니다.Guild  ; 길드개발 파트 안에서의 'Guild'는 토이 프로젝트 같은 성격의 공통 관심 분야를 지닌 프로젝트 팀이라고 볼 수 있습니다. 길드 기획 단계에서 회사 전사적으로 적용되면서, 동호회 성격으로 피보팅(Pivoting) 되어 있지만, 기본적으로 공통의 관심 분야를 같이 학습하고 프로젝트에 적용하는 팀입니다. 매주 수요일 오후 2~3시 사이의 시간은 챕터(Chapter), 고(Go)를 떠나 본인이 원하는 길드에 들어가서 새로운 영역을 탐색하고 연구하는 시간입니다.크몽 개발 파트는 아래와 같은 길드가 있습니다.(참고 : 코틀린 길드의 코틀린 리서치 이야기  https://brunch.co.kr/@kmongdev/9 )정리모든 개발 조직은 '성과 중심' 또는 '성장 중심'의 문화를 가지고 있습니다. 균형을 꾀하는 게 이상적이긴 하지만 스타트업에선 쉽지 않은 일입니다.하지만 크몽 개발 부서에선 인적 성장 중심 문화를 고민하고, 끊임없이 시도하고 있습니다. 이를 위해 여러 전문 교육 기관과 협약을 맺고 교육 지원을 하고 있으며, 국내 정상급 권위자 분들로 구성된 외부 컨설턴트 그룹을 구성해 개발자 분들께 배움과 성장의 기회를 부여하려고 노력하고 있습니다. 1년의 기간 동안 이직률3%의 수치를 기록하고 있는 크몽 개발 파트에선 신규 인력 채용 시 제 1의 인사 기준은 '높은 학력'도, '화려한 커리어'도 아닌우리와 '오랫동안' 함께 '성장'할 수 있는가?입니다. 이를 위해선 개발자 성장을 돕기 위한 환경 구축 및 관리가 필수이고,  그것이 궁극적으로는 회사 및 팀원에게도 장기적인 발전을 가져올 꺼란 굳은 믿음이 있습니다.크몽 개발 그룹CTO#크몽 #개발팀 #개발자 #사내복지 #기업문화 #조직문화 #사내스터디 #CTO
조회수 3422

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

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

응답시간 분포도

애플리케이션의 성능 개선은 웹 트랜잭션의 응답시간을 분석을 통해 이뤄집니다. 와탭의 응답시간 분포도는 대규모 트랜잭션 분석이 가능한 Heatmap 형태로 제공되고 있습니다. 와탭을 사용하는 사용자는 응답시간 분포도를 통해 웹 서비스의 응답시간이 느려지는 것을 알 수 있을 뿐만 아니라 패턴 분석을 통해 느려진 원인을 예측할 수도 있습니다. 와탭의 응답시간 분포도Y 축: 트랜잭션 응답시간을 의미합니다. 10s는 트랜잭션이 시작에서 종료까지의 시간이 10초가 걸렸다는 것을 의미합니다.X 축: 트랜잭션이 종료된 시간을 의미합니다.■: 트랜잭션이 발생한 위치에 색이 칠해집니다. 청색 계열은 정상적인 트랜잭션을 의미합니다. 노랑색과 붉은 색 계열은 에러가 발생한 트랜잭션을 의미합니다. 색상의 농도는 해당 영역에 발생한 트랜잭션의 밀도를 상대적으로 표시합니다.  와탭의 응답시간 분포도는 트랜잭션의 응답시간을 시각화하는 것입니다. 웹 서비스의 트랜잭션을 시각화 할 뿐만 아니라 추적하고자 하는 영역을 드래그하여 트랜잭션의 진행상황을 추적하는 것도 가능합니다.  추적하고 싶은 트랜잭션을 드래그 하는 모습와탭의 응답시간 분포도에서 트랜잭션을 선택하면 분석 화면으로 넘어갑니다. 해당 애플리케이션 서버 정보를 통해 선택된 트랜잭션이 어느 애플리케이션 서버에서 발생했는지 알 수 있습니다.애플리케이션과 선택된 트랜잭션 정보 화면분석하고 싶은 애플리케이션 서버를 클릭하면 해당 애플리케이션 서버에서 발생한 트랜잭션 목록을 확인 할 수 있습니다. 최종적으로 APM을 통해 확인하고 싶은 내용이 트랜잭션의 디테일한 정보일 것입니다. 와탭의 APM은 트랜잭션을 시각화하고 시각화된 트랜잭션을 선택하면 선택된 트랜잭션의 목록을 애플리케이션 서버 별로 분류하여 선택할 수 있는 구조를 가지고 있습니다. 이것은 능동적으로 웹 애플리케이션을 분석할 수 있는 최적화된 흐름이라고 생각할 수 있습니다. 사용자가 응답속도 분포도를 통해 선택한 트랜잭션 목록#와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 1233

하나부터 열까지 모두 알려주겠다! Scatter 계정 만들기 (feat. HexBP 연동하기)

스캐터(Scatter)는 암호화폐 지갑 계정에 대한 신원인증을 대행해주는 일종의 신원인증 프로그램으로, 별도의 보팅포털에 접속해서 신원인증을 통해 로그인을 도와주는 크롬의 확장 프로그램입니다.스캐터를 사용하게 되면, 기존에 여러 지갑 및 사이트로 부터 EOS 프라이빗 키를 부여 받아야 했던 번거로움 없이, 한번만 등록해놓으면 다양한 사이트에서 스캐터 계정 하나로 자신의 EOS 계정을 증명할 수 있게 됩니다.이러한 스캐터를 사용하는 방법을 지금 부터 알아보겠습니다.Step 1. Scatter 설치 및 계정 생성Scatter에서 크롬 확장 프로그램을 다운로드하여 설치하셔야 합니다.설치 후 크롬 브라우저에 설치된 Scatter 아이콘을 누르시면 다음과 같은 화면이 나타납니다.새로운 비밀번호 (최소 8글자)를 입력하시면 됩니다.비밀번호 입력 후 Create New Scatter 버튼을 누르세요.그럼 아래와 같이 12단어가 표시된 화면이 나타납니다. 바로 단어들을 복사 혹은 화면 캡처를 하여 보관해야 합니다.( * 저장하지 않은 채 다른 창을 누르시게되면 해당 화면이 사라지게 되니 꼭 바로 저장하셔야 합니다.)이 단어들은 나중에 비밀번호를 잃어버렸을 때 필요합니다.다 복사를 하셨으면 [ I wrote it down]을 눌러주세요.그 다음 화면에서 백업을 하실 지, 그냥 넘기실 지 선택하셔야 합니다.선택하시면 다음화면으로 넘어가게 됩니다.이제 더 편리하게 사용할 수 있도록 한국어 설정으로 바꿔 볼 거에요!우측 상단의 톱니바퀴 모양을 누르신 후[Language]-한국어 선택 -[Change Language] 차근차근 클릭하여진행하시면 됩니다.짜잔! 이제 한국어 버전으로 사용할 수 있습니다.이제부터 Scatter를 통해 자신의 EOS 프라이빗 키를 등록하셔야 합니다.왼쪽 상단의 [ < ]뒤로가기 버튼을 누르시면 다음과 같은 화면이 나옵니다.여기서 두번째 줄에 보이는 키 쌍(Key pairs)을 선택합니다.우측 상단의 [신규 생성]버튼을 클릭 하셔서 계정을 생성 하셔야 합니다.버튼을 누르시면 아래와 같은 화면을 확인하실 수 있습니다.이는 ‘현재 등록이 되어 있지 않다’는 것을 의미합니다.프라이빗키 항목에 자신의 EOS 프라이빗키를 넣고이름은 영어나 숫자를 이용하여 자유롭게 이름을 정하시면 됩니다.*프라이빗 키를 입력하면 퍼블릭 키는 자동으로 입력됩니다.*반드시 키 쌍 생성 버튼이 아닌 저장 버튼을 누르셔야 합니다.정상적으로 등록이 완료되면 다음과 같은 화면을 확인 하실 수 있습니다.다들 잘 따라오셨나요?만약 이 절차를 진행하셨음에도 등록이 안되었다면 계정이 EOS에 등록이 되지 않은 경우입니다.Step2 : Scatter 설정하기이제 등록된 Scatter 계정을 통해 HEX BP 사이트의 투표 시스템과 연동하는 방법을 알아보겠습니다.Scatter의 첫 화면으로 돌아가서 [톱니바퀴]를 선택합니다.해당 버튼을 누르시면 다음과 같은 화면이 나타납니다.[네트워크]를 선택합니다.해당 버튼을 누르시면 아래와 비슷한 화면이 나타납니다.이제 다시 우측 상단의 [신규 생성] 버튼을 누릅니다.해당 버튼을 누르면 네트워크 정보를 입력해야 하는 화면이 나옵니다.* 이름 : eosnet.hexlant.Io* https 선택* 도메인 혹은 IP 주소 : 목록 중에 선택* 포트 : 80* 체인 ID : aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906복사하여 붙여넣기모두 정확하게 입력 하셨으면 저장 버튼을 눌러주시기 바랍니다.이제 등록한 Chain을 계정에 연결해야 합니다![신원인증 ID]를 눌러주세요그 다음 [신규 생성]을 클릭 합니다.EOS Mainnet을 설정 한 후에 자신의 계정을 선택합니다.모두 선택하셨으면 [가져오기]를 누릅니다.[가져오기] 버튼을 누르신 후 잠시 기다리시면다음과 같은 화면이 나타납니다.이때 acticve 권한을 클릭 후 [선택한 계정 사용] 버튼을누르시기 바랍니다.*아래 개인 정보 입력하는 부분은 옵션이기 때문에 굳이 입력하지 않으셔도괜찮습니다. 모두 입력 하셨으면 [저장] 버튼을 눌러주시기 바랍니다.이제 스캐터 새 계정이 성공적으로 만들어졌습니다. 짝짝짝Step 3 : 투표하기[Login] 눌러서 Scatter 로그인 하기2. [신원인증 ID 선택]-[수락] 클릭하기3. Log out으로 바뀐 화면을 확인하실 수 있습니다.4. 투표를 하기 위해선 [Vote] 버튼을 누르셔야 합니다.5. Vote 버튼을 누르시면 체크박스가 생성됩니다! 이제 21명의 BP가 되길 원하는 후보자를 선택하시면 됩니다.누르시면 아래부분에 선택한 BP 후보자들을 확인하실 수 있습니다.후보자를 다 선택하셨다면 [Done] 버튼을 눌러 투표를마무리 해주시면 됩니다!6. [Done] 을 누르시면 마지막으로 Scatter 화면이 뜹니다. 여기서 [Accept] 버튼을 누르시면 됩니다.자 이제 투표도 모두 완료되었습니다!#헥슬란트 #HEXLANT #블록체인 #개발자 #개발팀 #기술기업 #기술중심 #Scatter
조회수 1567

TDD(파이썬) : 테스트 잘하고 계신가요?

Overview반복적인 테스트에 지쳐가고 있던 무렵, TDD방법론을 접하게 되었습니다. TDD(Test Driven Development)는 테스트 주도적인 개발로 소스코드 작업 전에 테스트 코드를 먼저 작성해 소스수정에 대한 부담을 덜고 디버깅 시간을 줄일 수 있습니다. TDD 장점소스코드의 품질이 높다.재설계 및 디버깅 시간이 절감된다.TDD 단점단기적 코드일 경우 생산성이 떨어진다.실제 코드보다 테스트 케이스가 더 커질 수 있다.파이썬에서 TDD가 필요한 이유1) 파이썬에는 정적 타입 검사 기능이 없다. (Python 3.6 에서는 정적 타입 선언 가능)2) 동적언어이기 때문에 TDD를 하기에 적합하다.3) 파이썬은 간결성과 단순함으로 생산성이 높은 반면 런타임 오류가 발생할 수도 있다.4) 파이썬을 신뢰할 수 있는 유일한 방법은 테스트를 하는 것이다.파이썬 테스트 모듈 unittest이번 글에서는 unittest를 사용해 단위 테스트를 해보겠습니다. unittest는 이미 내장되어 있어 따로 설치하지 않아도 되는 표준 라이브러리입니다. 사용방법1) import unittest 2) unittest.TestCase 상속받는 하위 클래스 생성3) TestCase.assert 메소드를 사용하여 테스트 코드를 간략화4) unittest.main() 실행그럼 간단한 예제로 단위 테스트를 해보겠습니다.1.사칙연산 함수를 추가합니다.def add(a, b):     return a + b   def substract(a, b):     return a - b   def division(a, b):     return a / b   def multiply(a, b):     return a * b 2. unittest.TestCase 상속받아 테스트 클래스를 생성합니다. 아래는 각각의 함수 결과값을 비교해 텍스트를 출력하는 코드입니다.import unittest class TddTest(unittest.TestCase): def testAdd(self):         result = lib_calc.add(10, 20)         if result == 30:             print('testAdd OK')      def testSubstract(self):         result = lib_calc.substract(20, 30)          if result > 0:             boolval = True         else:             boolval = False if boolval == False:             print('testSubstract Error')      def testDivision(self):         try:             lib_calc.division(4, 0)         except Exception as e:             print(e)      def testMultiply(self):         result = lib_calc.multiply(10, 9)          if result < 100>             print('testMultiply Error') if __name__ == '__main__':     unittest.main() 3.결과: 해당 조건에 만족해 작성한 텍스트가 출력됩니다.이번에는 unittest에서 지원하는 TestCase.assert 메소드를 사용해 간략하게 소스를 수정해보겠습니다.TestCase.assert 메소드1) assertEqual(A, B, Msg) - A, B가 같은지 테스트2) assertNotEqual(A, B, Msg) - A, B가 다른지 테스트3) assertTrue(A, Msg) - A가 True인지 테스트4) assertFalse(A, Msg) - A가 False인지 테스트5) assertIs(A, B, Msg) - A, B가 동일한 객체인지 테스트6) assertIsNot(A, B, Msg) - A, B가 동일하지 않는 객체인지 테스트7) assertIsNone(A, Msg) - A가 None인지 테스트8) assertIsNotNone(A, Msg) - A가 Not None인지 테스트9) assertRaises(ZeroDivisionError, myCalc.add, 4, 0) - 특정 에러 확인1. TestCase.assert 메소드 사용TestCase.assert 메소드를 사용하여 에러를 발생시켜 보겠습니다.import unittest class TddTest(unittest.TestCase): def testAdd(self):         result = lib_calc.add(10, 20)          # 결과 값이 일치 여부 확인         self.assertEqual(result, 31)      def testSubstract(self):         result = lib_calc.substract(20, 10)          if result > 10:             boolval = True         else:             boolval = False # 결과 값이 True 여부 확인         self.assertTrue(boolval)      def testDivision(self):         # 결과 값이 ZeroDivisionError 예외 발생 여부 확인         self.assertRaises(ZeroDivisionError, lib_calc.division, 4, 1)      def testMultiply(self):         nonechk = True result = lib_calc.multiply(10, 9)          if result > 100:             nonechk = None # 결과 값이 None 여부 확인         self.assertIsNone(nonechk) if __name__ == '__main__':     unittest.main() 2. 결과1) 테스트가 실패해도 다른 테스트에 영향을 미치지 않음2) 실패한 위치와 이유를 알 수 있음다음으로 setUp(), tearDown() 메소드를 사용하여 반복적인 테스트 메소드 실행 전, 실행 후의 동작을 처리해보겠습니다.TestCase 메소드1) setUp() - TestCase클래스의 매 테스트 메소드가 실행 전 동작2) tearDown() - 매 테스트 메소드가 실행 후 동작 1. setUp(), tearDown() 메소드 사용- setUp() 메소드로 전역 변수에 값을 지정- tearDown() 메소드로 “ 결과 값 : ” 텍스트 출력import unittest class TddTest(unittest.TestCase): aa = 0     bb = 0     result = 0 # 매 테스트 메소드 실행 전 동작     def setUp(self):        self.aa = 10        self.bb = 20 def testAdd(self):         self.result = lib_calc.add(self.aa, self.bb)          # 결과 값이 일치 여부 확인         self.assertEqual(self.result, 31)      def testSubstract(self):         self.result = lib_calc.substract(self.aa, self.bb)          if self.result > 10:             boolval = True         else:             boolval = False # 결과 값이 True 여부 확인         self.assertTrue(boolval)      def testDivision(self):         # 결과 값이 ZeroDivisionError 예외 발생 여부 확인         self.assertRaises(ZeroDivisionError, lib_calc.division, 4, 1)      def testMultiply(self):         nonechk = True self.result = lib_calc.multiply(10, 9)          if self.result > 100:             nonechk = None # 결과 값이 None 여부 확인         self.assertIsNone(nonechk)      # 매 테스트 메소드 실행 후 동작     def tearDown(self):         print(' 결과 값 : ' + str(self.result))   if __name__ == '__main__':     unittest.main() 2. 결과- setUp() 메소드로 지정한 값으로 테스트를 수행 - tearDown() 메소드로 각각의 테스트 메소드 마다 “ 결과 값 : ” 텍스트 출력실행 명령어 여러 옵션을 사용하여 실행 결과를 출력해보겠습니다.실행 명령어python -m unittest discover [option]1. -v : 상세 결과 2. -f : 첫 번째 실패 또는 오류시 중단3. -s : 시작할 디렉토리4. -p : 테스트 파일과 일치하는 패턴5. -t : 프로젝트의 최상위 디렉토리1. 상세 결과테스트 메소드명 및 해당 클래스명 출력 2. 첫 번째 실패 또는 오류시 중단첫 번째 테스트에서 오류 발생하여 중단3. 여러 옵션 실행현재경로 디렉토리 안에 tdd_test*.py 패턴에 속하는 모든 파일의 상세 결과Conclusion지금까지 파이썬에서 unittest 모듈을 이용한 테스트 코드를 작성했습니다. 처음에는 귀찮고 번거롭지만 테스트 코드를 먼저 작성하는 습관을 길러보세요. 분명 높은 품질의 소스코드를 만들 수 있을 겁니다!참고Python 테스트 시작하기파이썬 TDD 101글곽정섭 과장 | R&D 개발1팀kwakjs@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #파이썬 #Python
조회수 2743

100일 간의 챗봇 디자인 실패기-2편

본문은 100일간의 챗봇 디자인 실패기 - 1편 에서 이어집니다.각고 끝에 탄생한 린더봇의 실적은 화려했다. Microsoft에서 주최하는 기술경진대회인 ImagineCup에서 수상을 하기도 하고, 4차 산업혁명이라는 정치적(?), 시대적 흐름에 맞추어 여러 정부지원사업에서도 긍정적인 반응을 이끌어냈다. 이제 막 대학을 졸업하는 대학생들이 몇 달간 잠도 못 자고 밥도 못 먹고 로봇 인척 하며 개발 및 사용자 연구를 진행해왔다는 스토리텔링은 우리가 봐도 가히 감동적이기까지 했다. 하지만 베타 테스트를 시작한 지 한 달 만에 린더봇은 종료되었고 우리는 서비스 개발을 중단했다. 대체 무슨 일이 일어난 걸까.결론이 정해진 사용성 조사'현실왜곡장'이라는 말이 있다. 스티브잡스가 자주 사용한 기법으로 유명한데, 아무리 비현실적이거나 거짓된 내용도 그 왜곡장 안에만 있으면 가능할 것으로 생각되는 것을 말한다. 경우에 따라서는 불가능해 보인 일을 기어코 성공시키는 멋진 리더십으로 그려질 때도 있지만 대다수의 경우에는 현실을 직시하지 못하고 그들만의 망상에 빠져버리는 위험한 상태를 뜻한다.앞서 1편에서 린더봇을 통한 한 달간의 일정 입력률이 전체 캘린더 데이터 입력률에 대비하여 51%까지 나왔다는, 매우 희망적인 수치를 제시했다. 하지만 한 가지 빠뜨리고 언급하지 않은 것이 있다. 그 린더봇을 통한 입력의 80%가 서비스 사용 첫 3일 간 발생했다는 것이다. 나머지 3주 간 린더봇을 통한 일정 입력 횟수는 현저히 줄어들었다.우리가 회피하고 있었던 현실새로운 전자기기를 살때면 대부분 한번쯤은 경험해보았으리라 생각한다. 우리는 새로 만나게 된 제품에 호기심을 가지고 이리저리 만져보지만 이는 어디까지나 새로운 경험에 대한 일시적인 현상일 뿐, 대부분의 서비스는 특정 기능에 국한된 제품으로 전락하고 만다. 이러한 냉혹한 수치를 분명 인지하고 있었음에도 제품에 대한 간절한 희망 때문에 우리에게 유리한 방향으로만 수치를 읽어내는 실수를 저질렀다.준비되지 않았던 플랫폼우리는 린더봇을 제공하는 플랫폼으로 카카오톡 자동응답 API를 택했다. 비록 라인, 페이스북 메신저 등 타 메신저 플랫폼들이 챗봇을 위한 다양한 기능들을 선제적으로 제공하고 있었음에도 불구하고 카카오톡이 국내 메신저 점유율의 95%를 차지하는 시점에서 다른 메신저를 고려할 수가 없었다.카카오톡 자동응답 API결국 카톡을 선택하기는 했지만 카톡이 챗봇 써드파티 업체들을 위해 준비해놓았던 기능들을 매우 제한적이었다. 여러 아쉬운 점이 많았지만 그중에서도 ‘선톡’을 날릴 수 없다는 점과 ‘PC카톡’에서 대화를 할 수 없다는 점은 서비스 운영에 있어 매우 치명적인 문제들이었다.카카오에게 있어 '단체 선톡'은 매우 중요한 수익모델이다. 물론 지금도 수 만개의 기업고객에게 돈을 받고 ‘선톡을 날릴 수 있는 권리’를 팔고 있는 카카오 입장에서 굳이 소수의 개발사들을 위해 해당 기능을 무료로 제공할 이유는 없다고 생각한다. 또한 사용자들에게 무분별한 선톡이 발생할 경우 사용성이 저하될 여지도 충분히 있다. 하지만 다수의 해외 챗봇이 '무료 선톡'을 기반으로 한 섭스크립션, 큐레이션 서비스를 확장해나가고 있다는 점을 고려했을 때 매우 아쉬운 것은 사실이었다(특히 위챗은 매주, 또는 매일 특정 정보를 제공하는 섭스크립션/큐레이션 유형의 챗봇을 이미 하나의 카테고리로 규정하고 있다).'자동응답 API에서 선톡을 막는 것'이 사용자 편의성과 수익성을 고려한 어쩔 수 없는 선택이었다면, PC 카톡에서 자동응답 API를 통해 대화를 할 수 없었다는 점은 명백히 카톡 플랫폼 내 기술적 완성도의 부족이었다. 비록 카톡 트래픽의 대다수가 모바일에서 이루어진다고 할지언정 단순히 기술적인 이슈로 데스크탑 환경에서 자동응답 옐로아이디(현 플러스친구 통합)를 사용할 수 없었던 점은 카카오의 챗봇 환경에 대한 대응이 매우 늦었다고 밖에 볼 수 없었다.(지금도 PC에서는 자동응답 플러스친구 활용이 안되는듯하다)비록 국내 메신저 업체가 우리와 같은 작은 써드파티를 위해 조금 더 진보되고 오픈된 API를 제공해주지 않았다는 점은 아쉽지만 이 또한 업체 간의 이해관계와 시장의 속도를 현실적으로 고려하지 못한 우리의 잘못이었다.접근성, 인터페이스, 그리고 습관우리는 막연했다. 앞서 1편의 서두에서 언급했던 바와 같이 많은 사용자가 접근성 하나 때문에 메모장 대신 카톡을 선택한 것처럼, 린더봇 또한 접근성 하나로 많은 이들의 사랑을 받을 수 있을 것으로 기대했다. 우리의 챗봇을 통해 사람들이 놓치고 지나치던 많은 일정들을 캘린더로 입력시킬 수 있을 것이라 생각했다.우리가 그렸던 막연한 이상향새로운 기술을 좋아하는 IT업계 사람들이 더러 그러하듯 우리 팀 또한 ‘대화형 인터페이스(CI)’라고 하는 새로운 형태의 사용자 경험에 열광했다. 2016년 한 해 미국을 강타했던 다수의 챗봇 비즈니스를 검토하며 CI가 제시하는 미래에 매료되었다. 하지만, 우리의 기대와는 달리 베타 출시된 린더 봇의 실질적인 일정 입력률은 기존 캘린더 앱의 그것과 크게 다르지 않았다. 린더봇을 준비하며 설문을 실시한 결과 캘린더 앱을 활발히 사용하는 유저 중 주간 캘린더 입력률이 5회가 넘는 사용자가 20%가 채 되지 않았다. 우리는 린더봇을 통해 이 수치를 크게 바꿀 수 있을 것이라 생각했지만 그것은 단순히 새로운 인터페이스를 제공한다고 해서 해결될 수 있는 문제가 아니었다. 사용자들에게 필요했던 것은 ‘보다 편리한 캘린더’가 아니라 아예 ‘새로운 형태의 일정 도우미’였다. 그렇게, 지금의 일정 구독 서비스 - 린더가 탄생했다.자동응답 API를 통해 챗봇을 제공하기 전, 한 달 동안 수동으로 모든 일정 요청을 응답할 당시 한 사용자로부터 독특한 요청을 하나 받았다. 바로 재학 중인 대학원의 1년 일정을 자신의 캘린더로 넣어달라는 것이었다. 솔직히 요청을 받은 당시에는 이걸 정말 해줘야 하나 고민이 많았다. 단 한 사람을 위해 20개가 넘는 연간 대학원 일정을 캘린더로 담아줘야 한다니. 하지만 실험 당시 우리는 사용자들에게 분명 일정에 관련한 모든 입력을 도와주겠다고 약속했기에 대학원 웹사이트를 찾아 일일이 일정을 옮겨 담아주었다.실험이 끝난 후 해당 사용자는 설문에서 린더를 사용하며 가장 편리했던 기능으로 ‘연간 일정 한 번에 추가 기능’을 꼽았다. 30명의 사용자 중 단 한 명이 요청하고, 좋아했던 이 기능으로부터 지금의 ‘일정 구독 서비스 - 린더 ( https://linder.kr/ )’가 탄생했다. 챗봇의 성공 가능성이 희미해지고 있던 시점에서도 우리 팀은 ‘일정’이라는 요소를 손에서 놓지 않았다. ‘일정 데이터’가 앞으로 지니게 될 가치에 대해 고민한 결과 누군가는 80%의 비어있는 캘린더에 일정을 채워줄 수 있는 서비스를 만들어 낼 것이라는 결론을 도출하게 되었고, 그 ‘누군가’가 우리가 되지 못할 이유는 없다는 생각으로 린더를 만들기 시작했다.제품 개발 연혁- 17.01 ~ 17.02 휴먼(?) 린더봇 실험- 17.02 ~ 17.03 린더봇 베타 출시- 17.04 린더봇 중단- 17.03 ~ 17.05 일정 구독 서비스 - 린더 기획, 개발- 17.06 일정 구독 서비스 - 린더 출시2017년 11월 현재- 엔드유저(구독자): 10만 명- 파트너(기업): 삼성, SK, 현대 등 8개 사 스포츠, 교육 일정 등 협약- 누적 캘린더 181개 / 누적 등록 일정 12,000개- 평균 CTR(클릭률): 4~5%, 최대 7~8% ( 캘린더 내 일정 링크 클릭 수 / 구독자 )- 이탈률: 1% 내외 ( 구독 취소자 / 구독자 )- 제공 일정: 아이돌 스케줄, 화장품 세일, 대학교 학사일정, 스포츠 경기, 공연/축제 일정, 공채 일정 제공언론'국내 최초' 삼성, 캘린더 구독 서비스 실시…린더와 제휴 – 마이데일리(17.10.13)손 안에서 확인하는 경기일정, 현대캐피탈 배구단 캘린더 구독 서비스 실시 – 스포츠서울(17.10.18)스마트폰 달력 여니… 아이돌 스케줄이 주르륵 – 동아일보(17.11.01)#히든트랙 #챗봇 #기술기업 #개발자 #개발팀 #인사이트 #경험공유
조회수 791

컴공생의 AI 스쿨 필기 노트 ④ 교차 검증과 정규화

지금까지 Linear Regression, Logistic Regression 모델을 만들어보았는데요. 우리가 만든 모델이 과연 잘 만들어진 모델이라고 볼 수 있을까요? 이를 알기 위해서 이번 4주차 수업에서는 우리가 만든 모델의 적합성을 보다 객관적으로 평가하기 위한 방법으로 교차 검증(Cross Validation)과 정규화(Regularization)를 배웠어요. 차례대로 하나씩 알아볼까요?1. Cross Validation교차 검증은 새로운 데이터셋에 대해 반응하는 모델의 성능을 추정하는 방법이에요. 학습된 모델이 새로운 데이터를 받아들였을 때 얼마나 예측이나 분류를 잘 수행하는지 그 성능을 알기 위해서는 이에 대한 추정 방식이 필요해요. 먼저 Whole population(모집단)에서 Y와 f를 구하기 위해 Training Set(모집단에서 나온 데이터셋)에서 f와 똑같지 않지만 비슷한 모델 f^를 만들어요. 그리고 이 모델을 모집단에서 나온 또 다른 데이터 셋인 Test Set을 이용하여 확인해요. 하지만 일반적으로 Test Set이 별도로 존재하는 경우가 많지 않기 때문에 Training Set을 2개의 데이터셋으로 나눠요. 이 Training Set에서 Training Set과 Test Set을 어떻게 나누느냐에 따라 모델의 성능이 달라질 수 있어요. 이런 테스트 방법을 교차 검증(Cross validation)이라고 해요.이번 시간에는 교차 검증 방법으로 LOOCV(Leave-One-Out Cross Validation)와 K-Fold Cross Validation을 알아봤어요. LOOCV(Leave-One-Out Cross Validation)LOOCV는 n 개의 데이터 샘플에서 한 개의 데이터 샘플을 test set으로 하고, 1개를 뺀 나머지 n-1 개를 training set으로 두고 모델을 검증하는 방식이에요.K-Fold Cross ValidationK-Fold CV는 n 개의 데이터를 랜덤하게 섞어 균등하게  k개의 그룹으로 나눠요. 한 개의 그룹이 test set이고 나머지 k-1개의 그룹들이 training set이 되어 k번을 반복하게 돼요. LOOCV도 n-fold CV로 볼 수 있어요!코드로 나타내기Step1. 데이터 생성 & train set과 test set  단순 분리# model selection modulefrom sklearn.model_selection import train_test_splitfrom sklearn.discriminant_analysis import LinearDiscriminantAnalysis# read datadf = pd.read_csv('data/data01_iris.csv')data = df.iloc[:,:-1].as_matrix()target = df['Species'].factorize()[0]LOOCV와 K-Fold CV에 사용할 데이터를 구하는 코드에요. data 파일 안의 data01.csv 파일을 읽어서 데이터 프레임 형태로 가져와요.df(데이터 프레임) 안에는 이와 같은 105개의 데이터 셋이 저장되어 있어요.df(데이터 프레임)의 Sepal.Length부터 Petal.Width의 값들을 매트릭스 형태로 data에 할당해요.Species에는 ‘setosa’, ‘versicolor’, ‘virginica’ 값들이 있는데요. factorize() 을 이용하여 setosa는 0, versicolor는 1, virginica는 2로 바꿔줘요.# random splitX_train, X_test, y_train, y_test = train_test_split(            data, target, test_size=0.4, random_state=0)X_train.shape, y_train.shapeX_test.shape, y_test.shape그다음에는 data와 target 데이터를 가지고 training set과 test set으로 6:4로 나눠요.X_train.shape = (90,4),  X_test.shape = (60, 4)가 돼요.# LDA f = LinearDiscriminantAnalysis() f.fit(X_train,y_train) y_train_hat = f.predict(X_train) table_count(y_train,y_train_hat) f.score(X_train,y_train)LDA(Linear discriminant analysis)는 대표적인 확률론적 생성 모형이에요. 즉 y의 클래스 값에 따른 x의 분포에 대한 정보를 먼저 알아낸 후, 베이즈 정리를 사용하여 주어진 x에 대한 y의 확률 분포를 찾아낸다고 해요.Step2. test set 준비(1) LOOCV으로 test set 준비# leave-one-out  from sklearn.model_selection import LeaveOneOutloo = LeaveOneOut()loo.get_n_splits(X_train)scv = []for train_idx, test_idx in loo.split(X_train):    print('Train: ',train_idx,'Test: ',test_idx)    f.fit(X_train[train_idx,:],y_train[train_idx])    s = f.score(X_train[test_idx,:],y_train[test_idx])    scv.append(s) get_n_splits() 함수를 사용하여 (90,4)의 shape을 가지는 X_train을 90개로 나눠요.test set에 0부터 89까지 하나씩 할당되고 할당된 숫자 외의 나머지 숫자들은 training set으로 모델을 검증해요. 위의 결과에서도 볼 수 있듯이 test set에 0이 할당되면 train set에는 1 ~ 89가 할당되어 모델을 검증하게 돼요!(2) K-fold CV로 test set 준비# K-fold CVfrom sklearn.model_selection import KFoldkf = KFold(5)kf.get_n_splits()scv = []for train_idx, test_idx in kf.split(X_train):    print('Train: ',train_idx,'Test: ',test_idx)    f.fit(X_train[train_idx,:],y_train[train_idx])    s = f.score(X_train[test_idx,:],y_train[test_idx])    scv.append(s) KFold(5) : 위에서 배운 k-fold 교차 검증에서 k를 5로 설정하여 우리가 가지고 있는 데이터 셋을 5개의 그룹으로 나눠서 교차 검증을 할 거예요.kf.get_n_splits()를 사용하여 5번 교차 검증할 것을 정해요.위에서 90개의 데이터셋을 5개의 그룹으로 나눴어요. 그리고 각 그룹 한 개씩 test set으로 정하고 나머지 그룹들은 training set으로 할당하고 모델을 검증해요. 예를 들어 그룹 1이 0~17, 그룹 2가 18 ~ 35, 그룹 3이 36~53, 그룹 4가 54~71, 그룹 5가 72~89라고 할 때, test set에 그룹 1을 할당하면 train set에는 그룹 2, 3, 4, 5가 할당되어 모델을 검증하게 돼요.Step3. 교차 검증 시행CV는 단순히 데이터 셋을 나누는 역할을 수행할 뿐이에요. 실제로 모형의 성능(편향 오차 및 분산)을 구하려면 이렇게 나누어진 데이터셋을 사용하여 평가를 반복해야 해요. 이 과정을 자동화하는 명령이 cross_val_score()이에요.# K-fold CVfrom sklearn.model_selection import cross_val_scoref = LinearDiscriminantAnalysis()s = cross_val_score(f,X_train,y_train,cv=3)cross_val_score(f, X_train, y_train, cv=3) : cross validation iterator cv를 이용하여 X_train, y_train을 분할하고 f에 넣어서 scoring metric을 구하는 과정을 반복해요.2. Regularization앞서 말한 우리의 목적은 우리의 데이터셋에 맞는 Y와 f를 구하는 것이었어요. f를 결정하기 위해서는 먼저 결정해야 하는 요소가 있어요. 아래 다섯 가지가 f를 결정하는 요소들이에요.- Model family : linear, neural 등 방법론 결정- Tuning parameter : 모델에 맞는 파라미터 조절 - Feature selection(특징 선택) : 많은 데이터 중 어떤 데이터를 쓸지 고르는 것 - Regularization(정규화)  - Dimension reduction(차원 축소)f를 결정하는 요소 중 Regularization(정규화)에 대해 알아볼게요!정규화 선형회귀 방법은 선형회귀 계수(weight)에 대한 제약 조건을 추가함으로써 모형이 과도하게 최적화되는 현상(과최적화, overfitting)을 막는 방법이에요. 모형이 과도하게 최적화되면 모형 계수의 크기도 과도하게 증가하는 경향이 나타나요. 따라서 정규화 방법에서 추가하는 제약 조건은 일반적으로 계수의 크기를 제한하는 방법이에요. 일반적으로 Ridge Regression, Lasso, Elastic Net 이 세 가지 방법이 사용돼요.Ridge Regression머신 러닝에서는 모델의 오차를 찾기 위해 보통 최소제곱법(Least squares fitting)을 이용하여 β를 최소화시켜요. 위의 RSS는 잔차제곱식으로 예측값과 실제 값 사이의 차이를 구하는 식이에요. 회귀분석의 계수 값을 RSS을 최소화하는 β값을 찾음으로써 구할 수 있어요.Ridge Regression은 최소제곱법에 가중치들의 제곱합을 최소화하는 것을 추가적인 제약 조건으로 갖는 방법이에요. λ는 기존의 제곱합과 추가적 제약 조건의 비중을 조절하기 위한 하이퍼 파라미터에요. λ가 크면 정규화 정도가 커지고 가중치의 값들이 작아져요. λ가 작아지면 정규화 정도가 작아지며 λ가 0이 되면 일반적인 선형 회귀 모형이 돼요.코드로는 아래와 같이 나타낼 수 있어요.from sklearn.linear_model import Ridgef = Ridge(alpha=0.5)f.fit(xtrain,ytrain)f.intercept_,f.coef_f.score(xtrain,ytrain)f.score(xtest,ytest)LassoLasso는 가중치의 절댓값의 합을 최소화하는 것을 추가적인 제약 조건으로 가져요. 아래와 같이 코드로 나타낼 수 있어요.from sklearn.linear_model import Lassof = Lasso(alpha=1.0)f.fit(xtrain,ytrain)f.intercept_,f.coef_f.score(xtrain,ytrain)f.score(xtest,ytest)Elastic NetElastic Net은 가중치의 절댓값의 합과 제곱합을 동시에 제약 조건으로 가지는 모형이에요. 코드로는 아래와 같아요.from sklearn.linear_model import ElasticNetf = ElasticNet(alpha=0.1,l1_ratio=0.5)f.fit(xtrain,ytrain) f.intercept_,f.coef_f.score(xtrain,ytrain)f.score(xtest,ytest)Lasso와 Ridge Regression의 차이점왼쪽 : Lasso, 오른쪽 Ridge Regression위의 두 그림은 Lasso와 Ridge Regression의  차이점을 잘 나타내는 그림이에요. 초록색 부분은 회귀계수(회귀분석에서 독립변수가 한 단위 변화함에 따라 종속변수에 미치는 영향력 크기)가 가질 수 있는 영역이고 빨간색 원은 RSS가 같은 지점을 연결한 것을 보여주는 것으로 가운데로 갈수록 오차가 작아져요.Lasso와 Ridge Regression 모두 RSS를 희생하여 계수를 축소하는 방법이라는 공통점이 있어요.하지만 Ridge Regression과 Lasso의 가장 큰 차이점은 Ridge 회귀는 계수를 축소하되 0에 가까운 수로 축소하는 반면, Lasso는 계수를 완전히 0으로 축소화한다는 점이에요.Cross validation(교차 검증)과 Regularization(정규화)에 대해 알아보았는데요. 간단히 요약해 볼게요.Cross validation(교차 검증)은 머신러닝 모델의 타당성을 검증하는 방법 중의 하나로, 특정 데이터를 training set과 test set으로 분할한 뒤 training set을 활용해 학습하고 test set으로 테스트하여 학습의 타당성을 검증하는 방법이에요. 교차 검증에는 여러 가지 방법이 있는데 그중에서도 우리는 LOOCV와 K-Fold CV를 배웠어요.Regularization(정규화)는 모델의 일반화 오류를 줄여 과적합을 방지하는 방법을 말해요. 일반적으로 Ridge Regression, Lasso, Elastic Net 이 세 가지 방법을 사용해요.이상적인 머신러닝 모델을 만들기 위해 고려해야 할 점들은 정말 많은 것 같아요. 우리가 만든 모델이 적합한 모델인지 이번 수업시간에 배운 교차 검증과 정규화를 통해 잘 살펴봐요!* 이 글은 AI스쿨 - 인공지능 R&D 실무자 양성과정 4주차 수업에 대하여 수강생 최유진님이 작성하신 수업 후기입니다.
조회수 992

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

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

기업문화 엿볼 때, 더팀스

로그인

/