스토리 홈

인터뷰

피드

뉴스

조회수 657

MZ세대 팀원이 믿고 따르는 리더의 조건

직장을 다니면서 혹시 이런 말을 접해 본 적이 있으신가요? ‘나 퇴사할 거야!’, ‘나 유튜브 시작할 거야!’. 이 두 가지 말은 몇 년 전까지 직장인 2대 허언이었는데요. 지금은 2대 허언이 바뀌지 않았을까 합니다. 링크드인 조사에 따르면, 밀레니엄 세대는 대학 졸업 후 32세 전까지 직업을 평균 2.85번 바꾼다고 해요. 평생직장의 개념이 퇴색하고 있고, 우수한 직원을 장기근속시키기 위해서 회사와 리더들에게 노력이 요구됨을 시사하고 있습니다."요즘 애들은 끈기가 없어! 라떼는 말이야."“요즘 애들은 끈기가 없어! 라떼는 말이야.”하지만 안타깝게도 기성세대들은 MZ세대의 배경을 이해하지 못한 채 불만을 토로합니다. 오늘은 MZ세대 팀원이 믿고 따르는 팀장, 리더의 조건을 알아보려 합니다. 밀레니얼 세대를 사로잡는 리더, 성과를 내는 리더가 되려면 어떻게 해야 할지 살펴보겠습니다.1. 진정성으로 신뢰를 얻는다.MZ세대는 가식적인 친절함보다 진정성 있는 리더를 원합니다. 진정성이란 말 그대로 마음에서 우러나는 참된 마음인데요. 팀장, 리더라고 하더라도 실수나 문제가 있을 때 슬쩍 넘어가는 게 아닌, 솔직하게 이야기하는 모습을 보여야 합니다. 예를 들어 진행하고 있던 업무가 무산되거나, 예정된 담당자가 변경되었다면 타당한 이유와 내용을 정확히 전달해야 합니다. 리더를 신뢰하는 직원은 안정감을 느끼게 된다고 하는데요. 팀장에 대한 신뢰도가 높은 직원일수록 위험을 감수하고 혁신적인 시도를 할 가능성이 높다고 하네요. MZ세대 팀원이 혁신적인 시도를 원하신다면 진정성 있게 대해주세요.2. 기회를 주고 인정한다.MZ세대는 수평적인 커뮤니케이션과 탈권위주의를 추구하는데요. 권위주의적 리더는 회사 정보나 권한, 목표를 독점할 때 생기게 됩니다. 팀장만 참여하는 회의가 있다면 일반 팀원에게도 회의 내용을 공유해 주세요. 모든 일을 알고 하는 것과 모르고 하는 일은 천지 땅 차이입니다.택시 기사가 되었다고 가정을 해보죠. 그리고 목적지를 알려주지 않는 손님이 탔다고 생각해 보세요. 갑자기 ‘우회전이요’, ‘좌회전이요’라고 말하는 불안한 상황. 택시 기사는 눈을 가리고 운전하는 것 같은 막막함을 느끼게 됩니다. 손님은 지름길로 갈 수 있었을 텐데 기회를 놓치거나, 갑작스러운 방향 전환으로 사고를 당할 수도 있죠.직원의 역량 강화를 위해 전체적인 맥락을 알려주시고, 업무의 기회를 주세요. 업무 기회가 없다면 MZ세대는 ‘이곳에서는 성장할 수 없겠구나’라는 생각을 하게 됩니다. MZ세대가 대기업을 퇴사하는 이유 중 하나는 기계 부품처럼 일하는 구조라고 하는데요. ‘언제까지 이거 해와’라는 업무 지시보다, 일의 목적과 취지, 맥락을 함께 설명해 주시는 게 좋습니다.3. 업무 환경을 개선한다.오픈서베이의 조사 결과에 의하면 3년 차 미만 또는 Z세대는 ‘메신저, 문자’를 통한 커뮤니케이션을 선호한다고 하는데요. 대면이 편한 베이비붐 세대와는 상반되는 결과입니다. 코로나19로 재택근무와 자율출퇴근제가 일상이 된 시대에 발맞춰 업무 환경을 개선해야 합니다.MZ세대는 청소년기부터 IT 기기와 인터넷, 스마트폰을 접했기 때문에 스마트한 환경에 익숙한데요. 업무를 할 때에도 여러 툴의 도움을 받아 일을 하죠. 기업용 업무 툴은 떨어져 있더라도 원활하게 커뮤니케이션을 할 수 있습니다. 채팅은 물론 화상회의도 가능하죠. 업무 관리 기능이 들어간 협업툴의 경우에는 모든 정보를 공유할 수 있어서 자연스럽게 수평적인 문화가 만들어지기도 하죠.  요즘 우리 사회에서는 일상 곳곳에서 세대 갈등을 마주하고 있습니다. 명절에 만난 친척 어른과 조카 사이에서, 회사의 부장과 신입 사원 사이에서, 지하철에서 만난 승객 사이에서도 서로의 입장을 생각하지 않아 갈등이 생깁니다. 자신이 보고 들은 경험만 강조한다면 이런 감정의 골은 점점 깊어지겠죠. 좋은 리더란 조직원 간의 갈등을 조성하기보다, 앞으로 조직을 이끌어 갈 세대를 명확히 이해하고 변화를 꾀하는 것. 직원을 배려하는 문화와 업무 환경을 구축하는 것이야말로 MZ세대 팀원을 지킬 수 있는 방법이 아닐까요.협업툴 플로우 바로가기
조회수 2274

Dropwizard와 Asynchronous HBase 적용기

Background워크인사이트 서비스는 루비 온 레일즈 기반으로 작성된 웹 애플리케이션입니다. 주로 사용하는 데이터의 대부분은 HBase에 저장되어 있습니다. HBase는 자바로 작성된 API를 기본으로 제공하므로, 레일즈가 직접 HBase의 데이터에 접근할 수 없습니다. 따라서 데이터를 효과적으로 읽어들이기 위해서는 두 가지 방법 중 하나를 선택해야 합니다. 첫 번째는 HBase Java API를 이용하기 위해 웹 애플리케이션 역시 자바 기반의 프레임워크로 재작성하는 것이고, 두 번째는 HBase 스토리지 측 데이터 형식과 레일즈 웹서비스 측 데이터 형식을 서로 연결해주는 RPC 중개자를 도입하는 것입니다. 첫 번째 방법은 프로그래밍 언어를 통일함으로써 데이터 통신의 일관성은 물론 시스템 안정성이나 성능 측면에서 좀 더 낫다는 장점이 있는 반면에, 현재까지 작성한 레일즈 애플리케이션을 전부 자바 기반의 프레임워크로 재작성해야한다는 단점이 있습니다. 두 번째 방법은 보다 범용성을 지향하는 방식으로 향후 시스템의 확장에 좀 더 유용하지만, 첫 번째 방법보다 시스템 전체 성능은 뒤떨어진다는 단점을 갖고 있습니다.당시에는 이미 워크인사이트의 개발이 상당히 진척된 상태였기 때문에, 레일즈 프레임워크를 그대로 유지하면서 자바와 소통할 수 있는 JRuby를 사용하는 것이 최선인 것 같았습니다. 하지만 실험 결과 JRuby는 실 사용할 수 없을 정도의 성능을 냈습니다. 무엇보다도 레일즈 지원이 아직 미성숙한 상태였고, 사용중인 루비 젬 중에도 네이티브 C 구현 루비만 지원하는 젬이 상당 수 있었으며, 이러한 이유들로 인해 결국 JRuby는 대안에서 제외되었습니다. 루비 온 레일즈를 버리고 다른 자바 기반 프레임워크로 전면 재작성하기에는 너무 큰 소모비용과 위험요소가 있었기에 다른 방식을 고려하게 됩니다.그래서 조이는, 앞서 말한 크게 두 가지의 대안 중 두 번째, 범용 데이터 중개자를 도입하기로 결정하고, Thrift를 선택하기로 결정하였습니다. Thrift는 페이스북에서 처음 개발하였고, 현재는 아파치 재단에서 관리하고 있는 범용 RPC 프레임워크입니다. 비슷한 기능을 가진 다른 프레임워크로는 구글의 Protocol Buffer나 아파치 Avro등이 있습니다만, Thrift를 선택한 이유는 지원하는 프로그래밍 언어의 종류가 가장 다양하다는 것이었고, 워낙 많은 사용 사례가 있어 신뢰성이 검증되었다는 판단을 했기 때문입니다. Thrift는 그 규모에 걸맞게 다양한 플랫폼별 배포판을 지원하고 있으며, 조이는 현재 사용중인 하둡 시스템 관리용 Cloudera manager를 지원하는 배포판을 이용하여 디플로이하였습니다. 레일즈와의 연동도 thrift젬을 이용하여 손쉽게 할 수 있었습니다. 테스팅 결과도 문제 없었고, 이것으로 모든 것이 잘 돌아가는 줄 알았습니다.그림1. Thrift를 적용한 ZOYI Back-end SystemProblem워크인사이트는 런칭 이후 지금까지 가파른 성장세를 이어오고 있습니다. 서비스 초기에 느긋한 속도로 성장하던 적용 매장 증가 추세는, 2015년 현재 기하급수적으로 증가하는 상승곡선을 그리고 있으며, 그에 따른 시스템의 스케일 업 & 아웃 이슈도 매 달 새롭게 발생하고 있습니다.그림2. 오픈 이후 워크인사이트가 구동 중인 실제 매장 수문제없이 잘 굴러갈 것만 같았던 Thrift서비스 역시 조이의 성장세에 따라 점차 부하가 걸리기 시작했는데, 당초에 기대했던 범용 RPC 프레임워크가 보장하는 확장성과 동시성과는 조금 다른 성격의 문제가 발생하게 되었습니다. 시스템에 대규모 질의가 집중되는 시점에 병목 현상이 발생하고, 이것이 CPU와 메모리의 한도를 초과하면 그대로 다운되는 현상이었습니다. 특히 메모리 사용량이 복구되지 못하고 계속 쌓여만 가는 누수 현상이 치명적이었습니다. 게다가 이렇게 다운된 Thrift가 재시작된 경우, 레일즈와의 연결을 복구하지 못하는 현상도 비주기적으로 발생하였습니다.조이의 하둡 클러스터는 본래부터 확장성을 고려하여 설계되었기 때문에, Thrift에서 발생한 이러한 문제는 생소한 것이었습니다. 다각도에서 테스트를 해 봤지만, 처음에는 원인을 파악하기가 쉽지 않았습니다. 리부트된 클러스터도 자가 복구가 되지 않아, 개발팀이 직접 클라우데라 매니저를 주시하고 있다가 Thrift 서버의 다운 시점에 수동으로 재시작을 해 줘야 하기도 했습니다. 데이터 변환 프로토콜의 문제인지 검토해 보았으나, Thrift 프로토콜이 갖는 본질적 결함은 더더욱 아니었습니다. 자바 언어가 갖고 있는 내재적 결함도 아니었습니다. HBase가 제공하는 자바 API의 문제도 아니었습니다.하지만 심도 있는 검증 과정을 통해, Thrift의 가비지 컬렉션이 제대로 작동하지 않는 문제를 발견하였고, 이는 단순히 Thrift의 최적화의 문제가 아니라는 결론에 이르렀습니다.Dropwizard그렇게 고심하던 개발팀은, 2014년의 워크인사이트 첫 런칭 시점으로 되돌아가서 생각해보기로 합니다. 당시의 조이가 먼저 생각했던 방식은 JVM 기반의 프레임워크였는데, 자바를 이용하여 서비스 레벨도 구현하면 Thrift에서의 데이터 변환 과정에서 야기되는 문제를 원천적으로 방지할 수 있음에 다시금 주목하게 되었습니다. 많은 프로그래밍 언어간의 데이터 통신을 위해 설계된 Thrift는 사실 레일즈와 자바로 균일하게 구축된 조이 시스템에는 필요 이상으로 무겁고 큰 프레임워크였습니다. 조이가 겪은 이런 Thrift의 문제를, 해외의 여러 기업들도 경험하였고 각기 다른 방법으로 최적화를 진행한 것도 알게 되었습니다. 이렇게 된 이상 바꿀 수 밖에 없었던 것입니다.그래서 다음 대안을 찾기 위해 많은 리서치와 스터디를 진행했습니다. 넘쳐나는 프레임워크들의 홍수 속에서 가볍고 안정적이며 구현이 편리한 프레임워크를 찾기란 쉽지 않았습니다만, 결국 Dropwizard라는 자바 프레임워크를 도입하기로 결정하게 됩니다. Dropwizard는 이미 잘 알려져 있는 Spring이나 Play 등과 같은 풀 스택 자바 프레임워크와는 다른, 경량 REST API 프레임워크입니다. Dropwizard는 모듈화가 잘 되어 있고, 숙성된 자바 생태계의 안정적인 라이브러리(Jetty, Jersey, Jackson)들을 사용하였으며, 모던 자바에 걸맞는 방식(리플렉션, 동시성 등)을 사용하기 쉽게 패키징되어있습니다. 국내에는 잘 알려지지 않았지만, 해외에서는 이미 Airbnb 등 유수의 스타트업들이 실제 서비스에 사용함으로써 그 유용성을 입증하고 있는 프레임워크입니다.그림3. Dropwizard로 새로 구성된 ZOYI Back-end System다만, 처음 사용하는 프레임워크에 조이의 모든 서비스를 포팅하는 것은 불가능에 가까웠고, 설령 하더라도 엄청난 리스크를 감당할 가치가 있는 지 의문이었습니다. 레일즈가 보장해주는 빠른 기능 구현과 쉬운 배포 및 강력한 ORM 등은 루비 온 레일즈가 주는 최대의 강점이기에, 이를 포기하기는 쉽지 않았습니다. 생산성과 성능, 어느 한 쪽도 놓치고 싶지 않았습니다.그래서 조이는 두 마리 토끼를 다 잡아 보기로 결정합니다. 레일즈의 장점을 유지하면서, Dropwizard의 최대 장점인 HBase 데이터 접근의 유연성도 살릴 수 있는 방법을 찾기로 하였고, 결론적으로 Dropwizard는 기존의 Thrift가 담당하던 데이터 중개자의 역할만을 수행하게 되었습니다. Dropwizard의 잘 나뉘어진 모듈화는 이를 가능하게 해 주었습니다. 모든 모듈을 사용하면 풀 스택 프레임워크에 버금가는 규모의 시스템도 구축할 수 있지만, 필요한 것만 선택하여 사용하면 가볍고 빠르게 작동하는 미들웨어 역할도 가능한 것입니다.Asynchronous HBase, and Java 8Dropwizard가 HBase 연결에 사용한 클라이언트 모듈은 AsyncHBase입니다. Asynchronous HBase는, 타임스탬프 기반 데이터베이스인 OpenTSDB를 만든 팀이 자신들의 제품에 HBase를 연동하기 위해 기존의 HBase 클라이언트인 HTable을 대체하는 모듈을 재작성한 것으로, 완전한 비동기 방식과 넌블록킹 및 스레드 안전성 보장이 강점이라 할 수 있습니다. AsyncHBase와 Dropwizard를 연동하는 것은 매우 수월했습니다. 테스트 결과, 간결한 코드로도 초당 수 만 단위의 동시성을 안정적으로 처리할 수 있음을 검증했습니다. 조이는 OpenTSDB를 실시간 데이터 분석에 사용하고 있어, 해당 팀이 제공하는 제품의 품질과 전망에 대해 신뢰를 갖고 있었습니다. 테스트 결과는 이 신뢰를 더욱 뒷받침해주었고, 본 모듈을 Dropwizard의 HBase 연결 모듈로 선정하게 되었습니다.또한, Dropwizard와 AsyncHBase의 도입과 함께 처음으로 자바 버전 8로의 이식도 진행하게 되었습니다. 자바 8은 람다와 스트림 등 함수형 프로그래밍의 여러 기법을 대거 도입하였고, 자바 특유의 장황한 문법을 조금 더 간결하게 축약할 수 있는 장점이 있습니다. Dropwizard와 AsyncHBase 모두 자바 8과 순조롭게 연동되었으며, 이 결과에 만족한 조이는 기존의 하둡 맵 리듀스 프로젝트 역시 자바 8로 버전업하기로 결정하였습니다.PerformanceDropwizard의 성능 테스트 결과는 만족스러웠습니다. AsyncBase도 기대를 저버리지 않는 결과를 보여 주었습니다. HBase Java API와의 매끄러운 연동은, 성능 측면에서 기존과는 비교할 수 없을 정도의 향상을 보여주었고, 이 덕분에 기존 맵 리듀스 워크플로우 중 일부를 실시간 처리로 옮겨, 좀 더 유연하고 동적인 분석이 가능하게 되었습니다.다음의 비교는 Thrift와 Dropwizard의 각각의 벤치마크 테스트를 100개 동시 작업, 단위당 10000개의 요청으로 수행한 경우의 결과를 나타낸 것입니다.그림4. Thrift 테스트 시의 메모리 사용량Concurrency Level: 100 Time taken for tests: 514.315 seconds Complete requests: 10000 Failed requests: 0 Total transferred: 32090000 bytes HTML transferred: 27600000 bytes Requests per second: 19.44 [#/sec] (mean) Time per request: 5143.151 [ms] (mean) Time per request: 51.432 [ms] (mean, across all concurrent requests) Transfer rate: 60.93 [Kbytes/sec] received Thrift 벤치마크 결과. 전체 수행에 514초가 걸렸습니다.그림5. Dropwizard 테스트 시의 메모리 사용량Concurrency Level: 100 Time taken for tests: 4.599 seconds Complete requests: 10000 Failed requests: 121 (Connect: 0, Receive: 0, Length: 121, Exceptions: 0) Non-2xx responses: 121 Total transferred: 23288000 bytes HTML transferred: 21559452 bytes Requests per second: 2174.25 [#/sec] (mean) Time per request: 45.993 [ms] (mean) Time per request: 0.460 [ms] (mean, across all concurrent requests) Transfer rate: 4944.72 [Kbytes/sec] received Dropwizard 벤치마크 결과. 전체 수행에 4초가 걸렸습니다!그림6. 초당 처리량 (높을수록 좋음)벤치마크 테스팅 시 스레드 분산이 최적화 된 경우에는 최대 100배 이상의 속도 향상이 있었습니다. Dropwizard는 기존 Thrift에 비하여 성능 향상은 물론, 안정성 면에서도 시스템이 다운된 이후에 자동 복구되지 않는 현상도 사라졌습니다. 무엇보다도 짧은 코드만으로 대규모의 질의에도 견고하고 신속하게 반응하는 서비스를 구현할 수 있다는 점이 Dropwizard의 가장 큰 장점입니다.Conclusion유용한 오픈소스 프로젝트는 시장에 너무나도 많이 널려 있습니다. 이 중에 어떤 것을 선택하는가는 소프트웨어 기업에게 중요한 안건이며, 잘못된 결정은 프로젝트 자체는 물론 회사의 생사를 결정하기까지 합니다. 조이는 적합성, 성능, 안정성, 생산성 등 모든 면에서 조이의 서비스와 알맞는 제품을 찾으려고 항상 노력하고 있으며, 가능한 한 넓고 깊은 검증, 분석 및 연구를 통해 최적의 대안을 찾아내고 있습니다. 그 결과, 이번 Dropwizard와 Asynchronous HBase를 도입하여 기존의 Thrift를 대체하는 프로젝트는 예상보다 훨씬 좋은 성과를 낼 수 있었습니다. 국내에는 Dropwizard의 실무 사용기 등을 찾아보기 힘들고, 한글화된 문서 자체도 찾기 쉽지 않은데, 이 글이 앞으로의 선택을 고민하는 분들, 드롭위자드에 관심이 있는 분들께 도움이 될 수 있으면 좋겠습니다.#조이코퍼레이션 #개발팀 #개발자 #개발환경 #업무환경 #인사이트 #경험공유
조회수 2423

[H2W@NL] 로봇과 디자인

디자인이란 단어가 이제는 어디서나 익숙합니다. 그만큼 디자인의 정의와 역할은 다양한 영역에서 분화되어 있기도 합니다. 네이버랩스에서는 로봇이라는 대상에 대해 여러 분야의 디자인이 진행되고, 종국에는 통합됩니다. 하나의 로봇으로 이어지는, 로봇시스템/UX/ID 각각의 디자인에 대해 물었습니다.Q. 어떤 ‘디자인’을 하나요?로봇의 메커니즘에서 인터페이스까지, 최적의 시스템을 디자인(김인혁|Robot) 제가 하는 디자인은, 시스템 디자인이라고 말할 수 있습니다. 아, 물론 제가 속한 Robot팀엔 더 많은 디자인 과정들이 있어요. 로봇의 기구, 전장, SW 등 각각의 영역에서도 디자인 과정이 존재합니다. 저는 그 중에서 주로 시스템 제어 엔지니어로서의 디자인을 이야기할 수 있겠네요.사실 시스템이란 말이 좀 모호하죠. 과학분야에선 이렇게 정의할 수 있습니다. 구성 요소들이 내외부와 경계를 가진 상태에서 각 요소 간에 긴밀한 상호작용을 하는 집합체. 쉽게 설명하고 싶었는데, 여전히 어렵긴 하네요.로봇은 단순한 기능을 구현할 때에도 복잡한 요소들이 동시에 작동합니다. 메커니즘, 동력원, 에너지원, 제어기와 인터페이스 등. 이들이 서로 잘 연결되어 작동할 수 있어야 합니다. 이를 위한 최적의 시스템을 구성하는 디자인이라 하겠습니다.로봇, 그리고 사람, 그 사이에서의 상호작용(김석태|UX) UX의 입장에서는 HRI (human-robot interaction) 디자인이라고 정의할 수 있습니다. 앱이나 웹 등의 화면 기반 인터페이스와는 조건이 다른데요. 물리 공간에서 로봇이 동작한다는 점이 그렇습니다. 주변 사물이나 사람을 로봇이 인식하는 순간처럼 다양한 상황에서 로봇이 어떻게 동작하거나 반응해야 하는지, 그리고 로봇을 활용한 서비스는 다른 디바이스나 앱과 달리 어떤 방식을 통해 제공되어야 더욱 직관적으로 사람과 상호작용이 가능한지 등을 디자인하고 있습니다.기술만큼, 인상과 매력도 중요하다(김승우|ID) 로봇의 외관도 중요합니다. 로봇은 여전히 일반인들에겐 생소합니다. 이들에게 로봇은 흥미로움을 일으키는 대상일 수도 있지만, 마주치는 순간 기피하고 싶은 이질적 존재일 수도 있어요. 그래서 외관을 통해 느끼는 인상과 그 효과에 대해 세심한 접근을 하고 있습니다. 로봇 서비스가 보편화되지 않은 시점에서는, 사람들이 기대하는 로봇다운 매력을 잘 체감할 수 있게 하는 것도 로봇 대중화를 위해 중요한 역할인 것 같습니다.“기술이 지닌 본래의 가치를 더욱 잘 느낄 수 있도록 전달하는 것, 그것도 디자인의 역할입니다.” Q. 어떤 프로세스로 작업하나요?단순한 목표를 위해 필요한 복잡한 과정들(김인혁|Robot) 기본 목표라고 한다면, 일단 요구 스펙을 잘 만족하는 시스템을 설계하는 것입니다. 현실은 아주 복잡하죠. 요소들이 워낙 다양하기 때문인데요. PoC, 성능 테스트 등 평가 과정을 거치면 조정해야 할 것들이 많아집니다. 아예 새로 개발을 할지를 고민하게 될 때도 있는데, 참고할만한 레퍼런스가 없을 때는 참 어려워집니다. 이럴 때는 원론적으로 풀 수밖에 없죠. 공학적인 문제부터 정의하고 문제 해결을 위한 방법론을 탐색합니다. 이런 일들이 수없이 많지만, 시스템 디자인의 일반적인 프로세스이기도 합니다. 목표는 단순하지만, 과정은 현란하죠.산업을 이해하면 목표가 보이고, 사람을 이해하면 디테일이 보인다(김석태|UX) 앞서 말씀드린 것처럼, 서비스 로봇은 다른 앱/웹 서비스와 상황이 많이 다르죠. 앱이라면 프로토타이핑과 검증 과정을 상당히 빠른 주기로 반복할 수 있는데, 로봇은 그런 면에서는 제약이 있습니다.일단 로봇 서비스 산업에 대한 이해부터 시작하였습니다. 그간 어떤 로봇들이 어떤 서비스를 했고, 학계에서는 어떤 연구들이 선행 되었는지를 꼼꼼히 연구했습니다. 그리고 나니 목표 수준이 좀 더 명확해지고, 시나리오를 구체화할 수 있었습니다.중요한 건 역시 사람에 대한 이해입니다. 실제로 유용하다고 느낄까? 어떤 니즈가 여전히 숨어있을까? 로봇이 대신 해 주었을 때 더 가치 있는 것은? 이런 질문에 대한 답을 찾은 후 다음 숙제가 이어집니다. 사람들의 삶 속으로 이질감없이 자연스럽게 녹아 들기 위한 인터랙션입니다. 인터랙션 상황들을 정의하는 일부터가 시작이고, 어떤 이슈나 문제가 있는지를 찾아냅니다. 가장 단순하면서도 자연스러운 해결 방법은 무엇일지 실험을 통해 검증합니다. 이 과정에서 굉장히 많은 디테일들이 새롭게 발견됩니다.기술에 대한 이해도 중요합니다. 예를 들어 최근 AROUND C에는 디자이너가 가장 이상적인 로봇의 속도 및 이동 경로를 선택하면, 이를 바탕으로 딥러닝 기술을 적용해 최적화된 자율주행을 할 수 있는 기술이 적용되어 있습니다. 지켜보는 사람이 언제 안정감을 느끼는지, 로봇과 사람이 교차할 때엔 상대 속도나 동선을 어떻게 할지, 공간상의 제약이 복합적으로 작용하면 어떤 기준을 세워야 할지 등등. 수많은 요소들 사이에서 최적의 인터랙션 디자인을 설계해야 합니다. 이런 사소해보이는 사용자 경험이 로봇 서비스 과정에서 뜻밖의 감동까지도 전달할 수 있다고 생각합니다.“우리가 추구하는 기본 방향은, 실용적이면서도 사람을 배려하는 로봇입니다. 문제 상황을 분석해 나온 다양한 해결책 중에, 사람이 직관적으로 파악할 수 있는 방법을 택합니다.” 최근에는 AROUND C에서는 gaze, sound, lighting을 통한 비언어적 커뮤니케이션을 테스트하고 있습니다. 왜 굳이 로봇이 직접 말하게 하지 않고 비언어적 커뮤니케이션을 연구할까요? 그게 서비스 시나리오 상에서 더 직관적이며, 심지어 더 똑똑해 보이기 때문입니다. 스타워즈의 R2D2와 C3PO를 떠올리시면 됩니다. 점과 선을 활용해 가장 로봇다운 눈을 디자인 했고, 이를 통해 다양한 상태 정보를 사람에게 직관적으로 전달하고자 했습니다.전체의 통일감과 개별 디자인의 완성도라는 두개의 과녁(김승우|ID) 제가 공을 들이는 건 전체 제품의 통일감과, 개별 디자인의 완성도입니다. 네이버랩스에서 그간 공개했던 제품들은 작은 디바이스부터 중형 로봇, 대형 차량 센서박스에 이르기까지 다양한 카테고리에 걸쳐 있습니다. 디자인의 토대가 되는 조형 요소인 제품의 크기와 형태, 구조가 상이하다 보니 각각의 형태와 구조적 특성을 고려하면서도 전체 제품에 통일감이 느껴지도록 하는데 많은 노력을 기울여 왔습니다. 기업에서 일관된 메시지를 전달하는 것은 그 기업을 신뢰할 수 있는가에 대한 중요한 가치라고 생각해요. 디자인도 마찬가지입니다. 네이버랩스라는 기술 기업에서 전달해야 할 가치는 ‘정밀함’과 ‘단단함’이라고 생각했고, 로봇을 포함한 전체 제품에서 이 키워드들을 담은 일관된 디자인 언어가 느껴질 수 있도록 조형의 기본이 되는 면, 면의 기본이 되는 선을 세밀하게 다듬으며 디자인했습니다.또한 개별 디자인의 완성도를 위해 밸런스와 디테일을 중요하게 생각합니다. 로봇은 움직이기 때문에 다양한 각도에서 바라보게 되고, 어느 방향에서 보아도 완성도 높은 밸런스가 특히 중요합니다. 잘 안보이는 곳의 디테일도 쉽게 드러나기 때문에 세밀한 디테일을 놓치지 않기 위해 노력하고요.로봇의 경우엔 일반인들의 디자인 완성도에 대한 기대 수준이 더 높은 편입니다. 이런 기대를 충족시키는 동시에 기술적인 요구도 충족해야 합니다. 예를 들어, AMBIDEX의 전체 디자인 균형을 잡는 과정에서 팔의 부피를 늘리는 선택이 필요했는데, 동시에 무게는 가볍게 유지해야만 로봇의 기능을 100% 발휘할 수 있었습니다. 경량성이 AMBIDEX라는 로봇 팔 기술의 핵심 특성이기 때문이죠. 외관 부피를 늘려 디자인 밸런스를 최적으로 잡으면서도 1g을 더 줄이기 위해 질량을 체크하며 표면과 두께를 조정하고, 강성을 높이는 내부 구조를 추가하며 문제를 해결했습니다. 이런 디자인 과정을 거쳤기에 외관에서도 내부의 단단함과 견고함이 배어 나온다고 생각합니다.Q. 서로 어떻게 협업을 하나요?어차피 목표는 하나(김인혁|Robot) 각기 다른 분야의 전문가들이 협업할 때의 견해차이는 프로세스를 통해 해결되어야 한다고 생각해요. 그게 아니라 의견의 일방향성이 생기면 그건 곤란하죠. 저는 각 분야의 선/후행을 두지 않고 초기부터 과정 전반에 걸쳐 계속 공유하고 의견을 나누며 서로의 수용성을 늘리는 것이 아주 중요하다고 생각해요.“한 영역의 전문가가 모든 결정을 하고 다른 분야의 전문가는 일방적으로 종속되어야 한다면, 그건 문제가 있습니다. 선행과 후행을 나누면 안됩니다. 초기부터 같이 고민하고 대화하고 함께 풀어야 합니다.” (김석태|UX) 저도 커뮤니케이션이 협업 과제를 빠르게 가속하는 가장 중요한 요소라고 봅니다. 다양한 관점에서 의견을 나누는 건 정말 필요해요. 그 과정 없이 한번에 이상적인 솔루션을 바라는 건 무리입니다. 지금 진행 중인 1784 프로젝트 역시 이러한 소통을 원활히 이어가고 있기 때문에 좋은 협업이 진행되고 있고요.(김승우|ID) 차이란 것은 자연스럽죠. 좋은 결과를 위해 필수적입니다. 궁극적인 목표를 달성하고자 한다는 동질감을 느끼기 때문에 서로의 진정성을 확인허는 과정이기도 합니다. 어떤 디자인이라도 많은 협의와 조율이 전제됩니다. 하나의 입장에 매몰되어 있는지 되돌아보기도 하고, 전체를 바라보는 기회로 삼기도 합니다.Q. 앞으로의 도전은?(김인혁|Robot) 우리의 목표는 사람에게 도움이 되는 로봇을 개발하는 것입니다. 단순하죠. 이를 기술 관점에서 고민하고, 가장 적합한 답을 찾고, 그 답을 세상과 공유하고 싶습니다. 그것이 제가 맡은 역할이라 생각하고요. 그 역할을 잘 할 수 있도록 연구개발자로서도, 프로젝트를 리드하고 완성하는 실무자로서도 역량에 깊이를 더하고 싶습니다.새로운 스탠다드라는 설레는 도전(김석태|UX) 이제는 실험실이나 전시장이 아니라, 우리가 실제 살아가는 공간으로 로봇이 들어옵니다. 그런 시대에 도달했습니다. UX디자이너로서는 완전히 새로운 기회이자 설레는 도전입니다. 한때 모바일이란 세상으로 패러다임이 이동했던 시기가 있었죠. 이제는 가상 세계에서 제공하던 다양한 서비스와 기술들이 일상의 물리 공간으로 다시 돌아올 것입니다. 서비스 로봇을 통해 이 분야의 새로운 스탠다드를 만들고 싶습니다.(김승우|ID) 네이버랩스에서는 늘 흥미로운 프로젝트들이 진행되어 왔습니다. 그 중에서도 로봇 디자인은, 다른 어느 로봇보다도 디자인 완성도가 높으며, 동시에 기능적 가치를 충실히 구현하는 것을 목표로 진행해 왔습니다. 게다가 로봇은 외관 그 자체가 하나의 강렬한 인상이자 브랜드 체험 요소가 되기 때문에 더욱 큰 책임감을 느끼고 있습니다. 네이버랩스는 기술이 강점인 회사입니다. 동시에 디자인 또한 우리의 탁월한 강점입니다. 이를 위해 앞으로도 노력하려고 합니다. 네이버랩스의 인재상은 passionate self-motivated team player입니다. 어쩌면 '자기주도적 팀플레이어'라는 말은 형용모순(形容矛盾)일 지도 모릅니다. 하지만 우린 계속 시도했고, 문화는 계속 쌓여갑니다. 다양한 분야의 전문가들이 경계없이 협력하고 스스로 결정하며 함께 도전하는 곳의 이야기를 전합니다. How to work at NAVER LABSH2W@NL 시리즈 전체보기
조회수 1389

플랫폼 기획에 대한 생각들

5월부터 크고작은 프로젝을 하면서 생각해본 것들을 쭉 정리해 봤다. 답을 찾은 문제도 있고 확인되지 않은 가설도 있다.헤게모니 싸움- 서비스 이용자가 서비스 제공자를 고를 수 있게 하는 게 맞을까? 아니면 그냥 결제만 하면 우리가 알아서 알맞은 사람을 보내는 게 나을까?- 서비스 제공자를 고를 수 있게 할지 말지는 서비스 요금 표준화와 연결되는군. 서비스 제공자 간 차이를 인정하지 않고 요금을 표준화해볼까? 구매전환율은 높아질 거 같다.- 아니야! 서비스 제공자들이 같은 서비스를 제공하는 건 말이 안 되지. 객관적인 기준을 정하고 이에 따라 분류해서 서비스 요금을 차별화해보자. 근데 이렇게 하면 잘 팔리는 서비스 제공자만 팔리고 좀 떨어지는 사람은 안 팔릴 텐데?- 서비스 공급자를 고를 수 있다면 서비스 공급자의 객관적인 등급과 퀄리티에 따라 요금 차별화를 두는 것이 맞지 않을까?- 서비스 공급자는 넘쳐나고, 서비스 수요자가 소수라면.. 수요자가 갑이고 공급자는 을이 되겠군.- 이렇게 갑과 을이 명확하고 서비스 공급자가 넘쳐난다면, 서비스 공급자에 따른 요금 차별화를 통해서 고객에게 선택할 권리를 줘야 하지 않을까? 갑인 서비스 수요자를 잡아야 하니깐 당연히 그래 보인다.- 서비스 공급자의 차이를 인정하고 수요자가 공급자를 고를 수 있게 한다면 , 서비스 공급자들은 적극적으로 플랫폼에서 경력을 쌓고, 소비자에게 어필하기 위해 노력할 것임. 이는 플랫폼에서의 신뢰도를 쌓기 위한 공급자의 노력에 의해 평균 서비스 퀄리티가 높아지는 선순환의 고리가 시작된다.- 서비스 공급자의 퀄리티, 프로세스를 완벽히 통제하고 표준화할 수 없다면, 수요자는 공급자를 고를 수 있게 하는 것이 맞다.- 서비스 공급자의 서비스 가 표준화되지 않은 상태에서 일괄적인 배정을 하게 되면 엄청난 operation cost가 발생하는 것이 불 보듯 뻔함.- 홈클은 매니저간 서비스 퀄리티 차이가 분명 있었지만, 매니저의 절대적인 숫자가 부족해서 어쩔 수 없이매니저를 선택할 수 없는 방법을 택함. 서비스 퀄리티를 운에 맡길 수밖에 없었음. 지금 생각해 보면 Taskrabbit 모델이 우리나라에선 더 맞을지도 모른다.- 서비스 공급자가 넘쳐나고 , 서비스 수요자가 소수인 경우 수요자가 공급자를 고를 수 있게 하고 공급자의 등급이나 실력에 따라 요금에 차별화를 두는 게 효율적으로 작동할 거 같다. 검증이 필요하다.- 공급자에게는 플랫폼 상의 매칭 횟수, 리뷰, 평점 등 명확하고 신뢰할 수 있는 객관적 기준이 필요하다.- 등급에 따른 공급자의 임금 상한액과 혜택을 차별화하는 것도 좋은 방법이군.- 객관적이고 신뢰가 가는 공급자의 등급 설정은 수요자에게는 플랫폼에 대한 신뢰감을 주고, 공급자의 서비스 퀄리티를 컨트롤할 수 있는 강력한 방법이 된다. 이건 가설 검증.- 공급자에게 오랜 기간 동안 플랫폼을 통해 쌓인 리뷰와 reputation은 선생님에게 매우 귀중한 자산이 된다. (에어비앤비 참고) 자산이 생기면 플랫폼에서의 이탈이 힘들어짐.비즈니스 모델- 플랫폼의 '핵심 operation'을 통해서 수익을 낼 수 있어야 단단한 플랫폼으로 성장 가능. 적어도 플랫폼 수수료는 25%는 넘어야 한다. 엑셀 몇번 돌려보면 이는 명확함.- 플랫폼의 성장을 위해서는 당연히 공급자들이 돈을 벌어야 한다. 이건 여러 차례 증명되어온 사실.  - 과금은 ‘을 사이드’ 에게 하는 것이 수월함. 을 사이드가 돈을 버는 사이드라면 더욱더 수월하다.- 수요자와 공급자가 업의 특성상 가까워지기 쉽다면, 매 건당 수수료 부과는 플랫폼 이탈을 부추길 수 있다.- 공급자가 플랫폼을 통해 자신의 서비스에 대한 객관적인 사실 (매칭 횟수, 리뷰수, 긍정적 리뷰%)과 수요자의 주관적인 평가를 쌓아나갈 수 있고, 이를 통해 자신의 reputation을 쌓아서 안정적으로 돈을 벌게 된다면 거리낌 없이 플랫폼에 돈을 낼 것이다.- 수요자의 진짜 리뷰, 자신의 등급 등 자신을 어필할 수 있는 내용을 블로그 형식의 팝업창을 잠재적 수요자에게 노출하면서 공급자 자신이 ‘일감 구인중’이라는 사실을 알릴 수 있는 권한을 얻으려면 돈을 내야 하는 과금 체계가 합리적으로 작동할 듯. (월 단위 과금)3달간 경험을 통해서 느낌.'내'일을 하고 싶다.#삼분의일 #기획 #기획자 #인사이트 #경험공유 #조언 #BM #비즈니스모델
조회수 1239

한가위

안녕하세요.집에서 공항까지, 공항에서 집까지 편안한 여행길의 동반자 벅시 입니다.이 글을 읽으시는 모든 분들께 민족의 대명절 한가위를 풍성하게 보내시길 진심으로 기원하며,긴 연휴를 맞아 여행을 다녀오시는 분들도 벅시를 이용해 안전하게 다녀오시길 바라겠습니다.지난 근황 이 후 글이 작성되지 않은 이유는...노예 12년을 촬영 하였기 때문입니다... 흑흑... 대표 순 나쁜 ㅅ...흠흠, 그동안 있었던 일 중 특이할 만 한 일들을 좀 소개시켜드려 볼려고 합니다.1. 서울국제트레블마트 참가지난 9월 12일부터 서울그랜드힐튼호텔에서 2017 서울국제트래블마트에 참가 하였습니다.국내외 여행관련 업체들이 참가하여 진검승부...아니 정보교류 및 비지니스 협업을 위해 개최되고 있는 행사 입니다.저희 벅시는 교통 플랫폼이지만 여행과 밀접한 관련이 있으니 참가하는게 인지상정!다양한 바이어들과의 만남도 가졌구요. 긍정적으로 사업 제휴에 대해서 논의도 가능할 것 같습니다.벅시의 부스근데 행사장에 왠 뽀로로가 있어서... 미행했습니다.이렇게 돌아다니고사람들한테 막 시비를 걸더라구요얘도 기어코 시비를 걸더라구요.아무튼 저는 영어 잘 못해서... 함께 갔던 영어 잘하시는 분께서 그렇다라고 하네요.하하하 영어를 잘하니 일해라 하하하2. 평창 다녀 온 경험저희 벅시가 평창에서 무엇을 좀 해보려고 하는데요. 아직 비밀입니다. 눈치채도 모른척 해주십쇼.아무튼 평창을 다녀오게 되었는데요. 이번 평창 출장건은 다소 아쉬움을 남기게 되어서 저 개인적으로는 안타깝습니다. 뭐 그래도 이것저것 구경하고, 여러가지로 견문을 넓힐 수 있어서보람차다 할 수 있겠습니다.평창 가는 길은 너무 멀었습니다.사실 소고기 먹어서 행복했습니다.뭐 제 돈도 아닌데 알게 뭡니까3. VISA 영프리미엄 행사 참가흑흑비자.... VISA.... 오오... 감히 우리와 비교할 수 없는 그 회사.그렇습니다. 여행비자(ㅎ) 아닌 VISA 카드 그거 맞습니다.쑥스럽지만 우리 벅시가 VISA 카드와의 제휴를 통해서 혜택을 드릴 수 있게 되었습니다.비자 영프리미엄/인피니트/시그니처로 결제하시면 차량 업그레이드 나간다는거...꼭! 기억해주시길...많이 사랑해주시길 바랍니다.후후후이런것도 막 주심솔직히 이거는 뭐 제 알바 아니고 더 중요한게 이 행사에 요즘 핫한김숙&김생민 소비&절약요정들이 게스트였다는 것! 숙이 누나 미안해요 이게 최선임사진도 찍고 그랬는데 제 핸드폰이 매우 스튜핏해서... 이 참에 회사에서 저 핸드폰 좀 그뤠잇하게 바꿔줬으면 하네요....스튜핏황금연휴로 인해서 저희 벅시서비스를 찾아 주시는 분들이 많아 저희는 매우 행복합니다.최선을 다해 서비스를 하기 위해 준비를 많이 하고 있는데불편이 생기는 일이 있을까봐 반면에 노심초사 하고 있습니다.그리고 여러 업체들에서도 저희를 기억해주시고 찾아주셔서 또 감사합니다.파트너로서 서로 윈윈할 수 있는 아이템을 만들기 위해서 계속 노력하고 있습니다.더욱 노력하는 벅시가 되겠습니다.그럼 다들 연휴 잘 보내시고 저는 다시 일하러...흑흑모두 화이팅~!아 참 모두 풍성한 한가위 되시길!#벅시 #스타트업일상 #운영 #성장 #일지 #기업문화 #조직문화 #사내복지
조회수 1351

하나부터 열까지 모두 알려주겠다! 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
조회수 1362

[우리는 비투링커 #4] '빵빠레' 하나면 행복한 그녀, 박예지 님 ♥

안녕하세요, 비투링크의 소식을 전하는 미나 입니다! 벌써 한달이 지나, 다시 돌아 온 [우리는 비투링커] 시간인데요.3월의 비투링커로 선정된 그녀는 누구일까요?'빵빠레' 라면... 요거?*~*~짜잔~*~*자.. 먼저 추천영상을 함께 보시죠!이번 영상의 주제는 "엽기적인 그녀" 입니다 (ㅋㅋㅋ)보고있으면 참 밝은 그녀는 누구일지!▼▼영상 클릭 클릭▼▼3월의 비투링커 추천영상 (영상 고퀄주의 ㅋㅋㅋㅋ)그 주인공은... "엽기적인(?) No No~ 보고있으면 참 밝은 그녀" 박예지님 입니다!(짝짝짝짝!!!!!)3월의 비투링커 박예지님 :)특별히 빵빠레를 먹으면서 인터뷰 하고 싶었지만....빵빠레가 회사근처에 안팔더라구요 (또르르)그래서 그냥 빈손으로 예지님을 만났습니다.그래도 활짝 웃고 있던 그녀...................^^안녕하세요, 저는 비투링크 Brand Operation Division 내 구매팀에서제품구매, 발주 및 운영을 담당하고 있는 박예지 입니다 ^_^정말 0.1%도 예상치 못했어요. 팀원들이랑 꽤 친하다고 생각했는데, 정말 아무도 말을 안해주더라구요 ㅋㅋㅋ 그래서 제가 타운홀미팅날 연차를 써서 직접 영상을 못봐서 아쉬워요 ㅠㅠ그래도 이후에 영상을 봤는데, 진짜 행복했어요 ^_^ 보면서 같은 팀 제용님의 흑역사가 될 거 같다는 생각이 살짝 들었지만요...........:) 사실은 전 워낙 스트레스를 안받는 성격이기도 해요!또, 받게되면 내부에서 받기보다는, 외부 거래처와 커뮤니케이션을 하며 받는 스트레스가 대부분이에요. 그래서 팀원들이랑 같이 얘기하고, 간식을 사먹는다던지, 달달한 커피를 마시러 간다던지, 바깥공기를 쐬러 간다던지 ㅋㅋ 많은 것들을 팀원들과 함께 해요 :)슬픈 건, 요즘 회사근처에 빵빠레가 안팔아요..................... (슬퍼요 ㅠ_ㅠ)옛날엔 2+1 행사하고 그랬는데... 대체품을 찾고 있는데, 빵빠레를 대신 할 수 없을거같아요 ㅋㅋㅋ작년 송년회 때 같이 찍은 팀사진!주말엔 주로 제가 키우는 강아지 (단추) 랑 시간을 보내요 ^_^눈이 단추구멍 같아서 ㅋㅋㅋ 이름이 단추에요 (크큭)너무 애교쟁이 ㅠㅠ그리고, 제가 요즘 찾은 저만의 비밀스러운....... 문화생활이 있는데요.저 폴댄스 배웁니다!!!! 지금 거의 6개월 째 하고 있는데요. 정말 재밌어요 ^_^사진은...공개할 슈 없숴요~ (부끄러움)대박! 폴댄스라니 :) 멋져멋져... 저는 사실 몰래 예지님이 폴댄스하시는 사진 봤는데장난아니네여 섹시해 ㅠㅠ 저두 하고싶어요 ㅋㅋㅋㅋㅋㅋ제 컵이름은 "구갈동 빨간거" 입니다 ㅋㅋㅋ제 별명 너무 대충 지은거 같아요 ㅋㅋㅋ 불만이에요 !!이유는 제가 맨날 입술을 빨갛게 바르고 다녀서 ..........ㅋㅋㅋㅋㅋㅋㅋㅋㅋ근데 또 바꿔달라고 하기 무서워요 ㅋㅋ이상한 별명할까봐여... 빨간걸로 있을게요 그냥(좌) 한스킨 Blemish Cover (우) 23 Years old Sibiton cream [출처: 네이버 블로그]저는 한스킨 블레미쉬 커버 (Blemish Cover) 과 23 Years Old 시비통 크림 (Sibiton Cream) 을 추천합니다 :) 첫 번째 제품은, 컨실러 제품인데요. 커버력이 진짜 좋으면서도 촉촉한 게 장점! 휴대하기도 편하고, 가끔을 얇게 펴바르면 BB크림처럼도 사용할 수 있어요!두번째 제품은 크림인테, 이름이 약간 욕같져? ㅋㅋ 피부에 보호막을 설치해줘서 수분감도 오래 지속되고, 붉은 홍조피부 진정효과도 있어서 데일리로 사용하기 좋은 비타민 크림이에요!(친구한테 추천해줬는데, 친구가 지금까지도 계속 사용하고 있어요 ㅋㅋ)올해를 시작하면서 많은 계획을 세웠는데요!그 중에 꼭 이루고 싶은 건, "유럽여행" 을 가는 거에요 ^_^원래 1년에 한번 이상은 꼭 해외여행을 가는데요, 가장 멀리 갔던 게 동남아 였어요!올해가 제가 앞으로 살 날 중에 가장 젊고 예쁠 때니까꼭 가보도록 하겠습니다 :)손잡아주실 분 찾습니다 ^^....인터뷰 하는내내 예지님 때문에 저도 계속 웃었던 거 같아요 ㅎㅎㅎ앞으로도 계속 미소 잃지않는 밝은 예지님으로 ^_^(담엔 빵빠레 같이 먹어효)#비투링크 #팀원 #팀원소개 #팀원인터뷰 #인터뷰 #팀원자랑 #기업문화
조회수 1121

스타트업, 시작하기 전에...

나는 후배들에게 스타트업과 관련하여 어떻게 성공하는 가에 대해서는 이야기할 성공 경험과 성공을 말할 능력은 없다. 다만, 무수히 많게 도전한 대부분의 사업의 실패 경험만 있을 뿐이다. 그래서, 성공하는 법은 이야기할 수 없고, 다만, 실패하거나 망하는 방법을 피하는 방법에 대해서만 이야기한다.'바둑은 운의 기예이다.'라는 말이 있다.사업과 성공, 승부에 대한 단어를 생각하기에 가장 좋은 비유는 바둑인것 같다. 알파고와 이세돌 9단의 대국을 보면서 사업에 대한 여러가지 생각이 떠올랐다. 보통, 바둑은 기예의 대결이라고 한다. 기량만이 신뢰할 수 있는 최상의 무기라고 바둑을 아는 사람들 대부분 그렇게 이야기한다.하지만, 승부의 결과는 꼭 그렇지 않다. 기량과 관계없이도 승부는 갈릴 수 있다. 이론으로 설명 안되고, 인력과 기량을 초월한 그 무엇으로 승부는 갈린다. 그러한 것을 많은 사람들은 '운'이라고 이야기한다. 물론, 그런 '운'도 기량의 하나라고 이야기하는 사람들도 있다.일단, 사업 성공의 비밀은 '운(運)'이 좋아야 한다. 시대적인 배경이건, 주변 인맥의 힘이건, 전쟁이건, 태어난 나라의 혜택이건... 일단, '운(運)'이 필요하다. 하지만, 이것은 어떻게 선택하거나 원한다고 생기는 것이 아닌, 외부의 효과이기 때문에 그런 천운을 받은 사람은 말 그대로 복 받은 사람이다. 그리고, 대부분은 '운'이 없다.그리고, 팀을 구성하고 팀원들이 세팅되는 것도 대부분 '운(運)'이 좌지우지한다. 그것 또한 어떻게 할 수 없는 외부 요인이다. 사업은 개인의 노력으로 어떻게 해결되지 못하는 것이 대부분이다. 그것을 알고 시작하도록 하자.다만, 이러한 '운'을 제외하고 통제할 수 있거나 판단할 수 있는 것들에 대해서 이야기하려 한다. 창업을 하고 싶은 사람에게 이야기해줄 키워드는 몇 가지밖에 없다.하나. 하늘이 내린 운...둘. 만들어진 제품이나 서비스를 구매할 시장, 마켓의 존재 유무셋. 너무 빨리 만들면 안 된다. 적당하게 시간을 맞추어야 한다.넷. 너무 많은 기능이 들어가거나 너무 적게 들어가면 안 된다. 적절한 비용으로 만들어진 적절한 제품이어야 한다.영어 키워드로 나열하면. Lucky, Market, right timeing/product, 실제 계산할 수 있거나 통제할 수 있는 것은 시장에 대한 판단과 적절한 시기와 적절한 기능에 대한 통제이다. 물론, 절대적인 것은 '운'이라고 생각하자.물론, 운은 있었으나 너무 빨리 만들거나, 너무 많은 기능으로 구현된 제품과 서비스를 내놓으면 실패한다. 내가 그러했다. 결국, 운을 기회로 만들고, 성공이라는 키워드로 바꾸는 것은 결국 '기량'과 '실력'의 차이라고 생각한다.뭐, 더 냉정하게 이야기한다면. 대한민국에서 사업에 성공하려면 '땅'이나 '부동산'을 사는 것이 최선이었다. 미래는 어떻게 될 것인지 모르겠지만, 최소한 2016년도까지는 그러한 것이 맞는 것 같다. 국내 벤처회사들 중에 우연인지 아닌지 모르겠지만. 대부분 '건물'과 '땅'을 구매했던 회사들은 살아남아있다. 아니, 그렇게 행동할 수 있는 결정을 내린 똑똑한 임원들이 그 회사를 살린것인지도 모르겠다.다만, 스타트업을 만들고 제대로 된 회사를 만든 다는 것이 얼마나 많은 고통 이상의 것들을 경험해야 하는 것인지 잘 아는 필자이기 때문에 '사업'에 대해서 진지하게 고민하라고 이야기하고 싶다. 이번 글의 주된 내용은 '사업'을 시작하기 전에 그런 것들을 고민해 보라는 것이다.성공과 성취에 대한 형이상학적은 뜬구름 잡는 이야기가 아니라, 조금은 현실적인 부분에 있어서 충분하게 생각하고 고민하고, 정말 자기가 하고 싶은 일이 의미가 있는 것인지에 대해서 생각해보았으면 하는 마음에서 그동안의 경험을 기반으로 몇 가지를 정리해본다. 그다음에 사업을 시작하는 생각을 결정해도 충분히 늦지 않을 것이다.일단, 창업을 꿈꾸는 사람들이 다음과 같은 이유로 회사를 그만둔다는 것이라면 다시 한번 창업을 생각하기 바란다.첫 번째. 사업이라는 것이 경영과 영업이 그렇게 대단해 보이지 않는다. 경영진과 영업이 하는 일이 그렇게 많아 보이지 않는다. 더군다나, 잘하고 있는 것 같지도 않다. ( 경영이나 사업, 영업이 쉬워 보일 때가 있다. )회사에서 열씨미~~ 일을 하는 직원들은 정신없는데, 경영진이나 영업진들이 하는 일은 명쾌하게 보이 지를 않는다. 다들 노는 것 같고, 무슨 일을 하는지 잘 모르겠다. 당장 물건을 만들 거서 서비스에 집중하기보다 뜬구름 잡는 이야기만 하는 사람들만 많은 것 같이 보인다.특히, 소프트웨어를 개발하고 있는 내가 보기에는 회사의 경영진이 제대로 고객과 대응하지 못하고, 잘못된 대응을 하면서 소프트웨어 개발자인 내 일이 점점 더 힘들어지고 있다. 그래서, 내가 직접 하는 것이 현명하다고 생각을 자주 하게 된다.쉽게 이야기해서 ‘경영진은 제대로 경영을 못하고, 영업팀은 제대로 고객 응대를 잘 못하고 있는 것 같다는 생각이 드는 때에, 스타트업을 생각하는 개발자의 경우에는 필자는 말리고 싶다.이런 생각을 하고 있는 개발자라면 아직은 '소프트웨어 개발'에 대해서 밖에 잘 모르는 상황이므로, 아직은 '창업'을 꿈꿀 때가 아니라고 필자는 창업을 만류하겠다. 아직은 언제나 자신이 하는 일이 더 커 보이고, 더 어렵게 생각되는 것은 매우 당연한 것이고, 일반적인 사람들의 입장에서는 그렇게 보이는 것이 매우 당연한 것이다. 그래서, 너무 자신의 좁은 시야만을 가지고 있기 때문에 창업을 하거나 스타트업을 하는 것에 대해서 깊이 있게 생각하기 바란다. 그렇게 너무 일반적인 '직장인'의 시선으로 밖에 회사의 업무를 파악하지 못한 것이기 때문에 아직은 '창업'을 할 때가 아닌 것 같다.두 번째. 아주 멋진 아이디어가 있고, 이 아이디어에 대해서 회사에서 받아들여지지 않는다. 정말 획기적인 아이디어인데... 이 아이디어는 분명, 누군가가 이 서비스가 만들어지면 열광할 것이다라는 믿음을 가지고 있을 때이다.누군지는 잘 모르겠지만, 내 아이디어를 필요로 하는 그 누군가를 위해서 이 아이템과 이 아이디어를 실현하고 싶다는 생각을 자꾸 떠올리게 한다. 다만, 이 아이템 와 아이디어가 쓸모 있을 것이라는 확신은 약간 부족한 정도일 뿐이다.하지만. 그 아이템과 아이디어가 '돈'을 주고 구매할 대상이 정말 존재할 것인지에 대해서 먼저 의심을 가져야 한다.조금은 구체적인 아이디어를 통해서, 실제 구매할 대상이거나, 아니면. 최소한 내가 '돈'을 내고 살 수 있는 아이디어가 구체화될 때까지 창업을 뒤로 미루라고 조언을 주고 싶다.언제나 기술이나 아이디어가 실제 실현되고 시장에서 제 역할을 하기 위해서는 실질적인 '구매자'가 분명하게 존재해야 한다. 단지, '아이디어'와 '서비스'의 아이디어만 가지고 실제 사업을 수행한다는 것은 매우 쉽지 않은 일이다.세 번째. 아이디어를 충분하게 구현을 하지 않았지만, 이 아이디어는 분명하게 성공할 수 있는 가능성이 있다. '돈'만 있으면, 충분하게 사람을 구하고, 서비스를 준비해서 시작할 수 있을 것이다.만일 이런 생각을 가지고 있다면, '작은 서비스'나 '작은 프로토 타입'이라도 실제 개발하여 보는 것을 먼저 하라고 권하고 싶다.어떤 아이디어이건 실제 구현을 하다 보면, 실제 머릿속으로 구상했던 것과는 전혀 다른 의미를 가지거나, 많이 부족하거나, 구체적인 실현 아이디어들이 덜 생각되어진 경우가 많다. 대부분의 성공적인 스타트업을 수행한 사람들의 사례를 살펴보면, 작은 것부터라도 실제 구현하고 실제 만들어본 후에 일을 시작한 경우가 많다는 것이다.이 외에 에도 내가 만들고 싶은 무언가를 위해서 창업과 비즈니스를 꿈꾸고 있는 개발자가 있다면, 이번 칼럼에서 몇 가지를 조언하고 싶은 것 중에 가장 큰 것은 '꿈'을 실현하는 데 있어서 '현실적인 일'에 대해서 너무 무시하거나, 너무 작게 생각하지 않기를 바란다.필자 역시 무언가를 만들고 싶어서 창업을 시작했을 때에는 정말 신났던 기억이 난다. 내가 만들고 싶은 제품에 대한 아이디어를 구상하고 구현하고 싶은 무언가를 만들고 테스트하고, 하고 싶은 것을 위해서, 만들고 싶은 것만을 위해서 그 이야기만을 나누는 사람들을 모으고, 그 꿈에 대해서 이야기할 때에 정말 즐거웠다.하지만, 나중에 알게 되었다. 실제, 사람을 모으고, 사람과 호흡하면서 실제 무언가를 만들어 나가는 '이익'을 위한 조직인 회사라는 곳과 공동작업이라는 것을 위해서 얼마나 많은 부수적인 작업들과 생각, 비전과 프로세스, 목표 등에 대해서 제품 개발 업무 이외의 수많은 작업들과 필요한 행정적인 업무들이 정말 많다는 것, 그러한 업무들이 정말 많다는 것을 나중에야 알게 된다.물론, 이러한 일을 대신해주고, 도와줄 사람을 구하는 것도 방법일 것이다. 하지만, 그 역시 사람이 투입되게 되면 '비용'이 들어가는 것이고, 어떤 사람이라고 하더라도, 자신과 똑같은 생각을 일치하게끔 가지는 것은 정말 매우 어려운 일이다.현재 시점에서 필자가 생각하는 무언가 목표로 하고 있는 서비스를 개발하는 것과, 다른 부수적인 업무들을 구분하고, 그러하게 만들어진 '가치'를 실제 시장에 내어 놓고, 실현하는 것을 퍼센트로 구분한다면 필자는 이렇게 정의한다.무언가를 만들어 내갈때에는 처음에는 개발이 50%, 다른 잡스러운 업무가 50%라고 생각할 수 있다. 순수하게 소프트웨어를 개발하고 구성하고 테스트하는 업무가 50이고, 다른 잡스러운 행정적인 것들의 업무가 50%를 넘어서는 수준으로 발생한다.은행을 찾아가는 법, 세금에 관련된 것, 직원을 고용하는 것에도 규칙이 있다는 것, 사람을 뽑고 관리하고, 시간을 조절하고, 근무장소에 대한 것, 사무실 청소부터 작은 소모품에 대한 관리까지 정말 많은 것이 있다.사람들과의 트러블은 매우 당연하게 발생하고, 별것 아닌 것 같지만 시간을 끊임없이 소모하게 되는 수많은 서류들이 '업무'로써 존재한다.정말 제품과 서비스를 만드는 것 이외의 전혀 상관없다고 생각하는 것들에 대해서 생각해야 하고 아이디어를 가져야 하고, 경험을 가져야 한다. 그런 업무에 대해서 생각하고 고민해야 하고 투자해야 한다.그리고, 실제 '서비스'나 '제품'이 나왔다면, 이러한 것들을 유지하기 위한 개발업무가 30%, 기타 잡스러운 업무가 30%, 해당 제품과 서비스를 관리를 하고, 유지 보수하는 업무가 전체의 40%에 해당한다.실질적으로 소프트웨어를 개발하는 업무는 전체적인 업무의 30%이며, 실제 아이디어를 구현하는 것보다 더 어려운 40%의 비용과 시간을 수정 유지 보수하기 위해서 시간과 비용을 소모하게 된다.처음에 잘 만들지 않은 소프트웨어라면, 이 유지보수 비용은 기하급수적으로 증가한다. 그리고, 대부분이 처음 만들어진 것을 다시 만든다. 그것이 소프트웨어 기업이고, IT기업인 것이다.개발자라면 창업이건, 기업을 만들건 몇 가지를 착각하면 안 된다. 그리고, 기억해야 한다. 대중 매체와 미디어에서 이야기하는 정말 성공한 사람들이 제대로 이야기를 해주지 않는구나라고 생각하는 것이 가장 현명하다.정말 뛰어나게 성공한 사람들은 자신들의 '운'에 대해서 잘 설명하기 어렵다. 그리고, 자신들이 가지고 있었던 배경과 기회에 대해서 잘 설명하지 못한다. 그래서, 대부분 사람들은 자신의 진정한 성공 스토리를 이야기하기보다는 자신이 생각하는 멋지고, 폼난 부분들만 설명할 뿐이다.'그 사람들은 좋은 부분만 이야기하고 있는 것이구나'라는 것을 한참 후에야 느끼고 이해할 수 있는 것이 실제 창업을 하고 사업을 하면서 알게 될 것이다.여기까지 느끼게 되면 이제야 '소프트웨어 개발을 하고 유지보수를 할 수 있으며, 행정적인 것을 끌어 갈 수 있게 된다. 하지만, 가장 어려운 것이 남아 있다. 여기까지 왔으면, 이제 사업가가 될 준비가 30%가 된 것이다.그것은 내가 만들고 싶은 사업 아이템을 위해서 자본을 끌어들이는 것을 고민하고 설득할 준비를 하는 것과 물건을 팔기 위해 고객을 찾아가는 것을 이제 시작해야 한다. 사실, 이제부터 본격적으로 '사업'에 대해서 구상해야 한다.그리고, 내가 생각한 아이디어와 서비스, 비즈니스를 손쉽게 시장과 고객에게 설득하기 위한 논리와 쉬운 설명방법을 생각해야 한다. 소비자와 투자자들은 언제나 '돈'을 가지고 있다. 그리고, 자신들이 필요한 서비스들에게 '유료'로 돈을 지불하고 구매할 용의가 있으며, 투자자는 '성공할만한 아이디어'에게 투자할 준비가 되어 있다.정말 필요하고 매력적인 제품과 서비스라면 '소비자'와 '투자자'를 찾는 것이 어렵지 않을 것이다. 실제, 시장에 '돈'은 정말 풍부하다.하지만, 대부분, 소비자에게 필요한 서비스를 매력적으로 설명하는 것이 얼마나 어려우며, 투자자에게 이 아이디어가 얼마나 매력적인지에 대해서 설명하는 것이 얼마나 어려운 것인가에 대해서 나중에야 느끼게 된다.자신이 혼자서 흥분하고, 자신만 좋아서 무언가를 만드는 행위는 그냥, 자신의 '개발 놀이', '사업 놀이'에 가깝다. 물론, 이러한 '놀이'를 했는데, 자신의 '놀이'의 파격적인 아이디어와 미래적인 가치를 발견한 소비자와 투자자를 바로 찾는 다면, 그것은 정말 대단한 행운을 얻은 것이다.그래서, 보통은 '창업'과 '사업'을 하려고 하는 사람이 있다면, 자신의 아이디어를 어떻게 정리하고 어떻게 설명하고, 어떻게 시장에 선을 보일 것인가에 대해서 충분한 연습과 충분한 준비를 하는 것이 정말 중요한 것이다.개인적으로는 대한민국의 창업과 관련된 수많은 프로세스들이 이러한 '최소한의 과정'을 위해서는 나름 정제되어 있는 프로세스를 가지고 있다고 생각한다. 물론, 이 제도들의 유용성이나 가치에 대해서는 이번 이야기에서 장황하게 설명하기에는 부족하기 때문에 단편적인 측면에서 '사업'을 준비하는 사람의 입장에서 어떤 방법으로 무엇을 먼저 '문서화'해야 하는지에 대해서 명쾌하게 가르쳐준다.굳이, 정부과제를 신청하지 않는다고 하더라도, 내가 하고 싶은 일과 내가 하고 싶은 것에 대해서 종이로 작성이 불가능하고, 단어로 설명할 수 없고, 구체적으로 무엇을 만드는지에 대해서 기술할 수 없다면, 그 사업과 아이템은 처음부터 다시 생각하는 것이 현명하다고 하고 싶다.물론, 이 프로세스를 통해서 수백 페이지의 문서를 만든다고 프로젝트가 성공하는 것은 아니다. 또한, 이러한 문서를 잘 만든다고 서비스와 아이템이 실현되는 것도 아니다.실제, 필자가 본 정말 자신의 생각을 잘 정리하는 사람은 이 프로세스에 맞추어서 내가 만들고자 하는 서비스의 정의와 이 서비스는 어떻게 만들어지며, 어떤 기술들이 필요하고, 어떤 시장과 어떤 환경을 예측하고 있는지에 대해서 많지 않은 문서로 충분하게 설명을 할 수 있다.그것이 이런 사업계획서를 작성하는 주목적이 된다. 그러니, 사업과 창업을 꿈꾸는 개발자라면 창업이나 프로젝트의 사업계획서를 꾸준하게 작성해보는 것이 어떨까 한다. 특히나, 기업 내부에 있다면 이러한 문서를 만드는 방법이나 표현법에 대해서 가감 없이 평가해줄 수 있는 유경험자들이 충분하게 있으니, 이런 도전을 한번 이상은 꼭 해보기를 바란다.물론, 그렇다고 해서, 성공하는 것도 아니다. 다만, 실수를 줄여주고, 내가 생각한 아이디어를 좀 더 구체적으로 표현하는 방법을 터득한 것뿐이다.회사를 만든다는 것은 정말 다른 것이다.회사를 만든다는 것은 정말 어렵다거나 쉽다거나의 문제가 아니다. 정말, 그동안 해온 일과 다를 것이다. 특히, 회사를 만든다는 것은 제품만 만든다는 것과 얼마나 다른 것인가? 에 대해서 깊이 있게 생각해야 한다.회사라는 법인체는 분명, 법적으로 살아있는 인격체이다. 그러한 인격체가 어떻게 만들어지고, 그 내부에 속한 조직원들에게 어떤 목소리를 내어야 하고, 그 과정을 어떻게 이겨내고, 어떻게 찾아가야 하는가에 대해서 깊이 있게 생각해야 한다.복잡한 경영이론과 개론을 이야기하는 것이 아니라, 여러 사람이 모여서 어떤 목표를 이루어 나가는 것에 있어서 구체적인 목표와 비전, 그리고. 문화에 대해서 어떻게 가져갈 것인가에 대해서 기준을 세워야 한다.그리고 다시 자신에게 되묻는 것을 계속 반복해야 한다.'정말 만들고 싶어서 고른 것인가?''아니면, 팔릴 것 같아서 만든 것인가?'필자는 어는 것이 정답인지 잘 모르겠다. 실제, 만들고 싶어서 만들었는데 잘된 경우도 보았으며, 잘 팔릴 것 같다고 생각한 제품이 실제 운이 좋거나, 일부 기술이 잘 개발되어져서 성공한 경우도 많이 보았다.현재 대한민국의 스타트업의 세계를 보면, 매우 재미있는 현상이 있다. 그것은 중견기업의 IT기업이 스타트업의 아이템과 비즈니스 모델을 적절한 가격에 사들인다는 것이다. 저 멀리 실리콘 벨리에서 수천억, 수조 원에 팔리는 환상적인 이야기는 아니지만, 구체적인 사업모델과 수익모델이 만들어지고, 이익을 보고 있거나, 무료 앱이지만 충분한 다운로드 횟수가 100만 다운로드를 넘어선 앱들이, 적절한 가격에 회사가 통째로 팔리는 경우를 보고 있거나, 자문을 하고 있다.구체적은 한국형 M&A의 시장이 가동되고 있는 것을 볼 수 있다는 것이 매우 고무적인 일이다. 현재는 무료 앱이라고 하더라도, 수백만 다운로드와 수십만 이상의 사용자를 가지고 있는 앱의 경우에도 충분하게 가치가 있다는 것을 시장에서 반응하고 있다. 현재의 투자자나 투자기업들은 스타트업에게 '비즈니스 모델'과 '수익 모델'에 대해서 질문하고 유도하지만, 충분하게 사용자를 확보한 모델의 경우에는 그 가치를 인정한다는 것이다.오히려, 그러한 모델로 진행된 스타트업의 경우에는 적절한 비즈니스 모델을 가진 모기업을 찾아주거나, 필요한 모델들끼리의 결합을 유도하기 시작했다. 이제 한국도 충분하게 M&A 시장이 소프트웨어 기업에서는 시작된 것이다.소프트웨어 사업은 혁신이 필요한가?소프트웨어 개발기업에게는 '혁신'이라는 단어가 꼭 필요한가에 대해서 필자에게 질문이 들어온다면, 필자는 '혁신'이 꼭 필요하다고 대답한다. 특히나 소프트웨어는 '정보'를 다루는 것이고 '정보'가 필요한 곳으로 옮겨가게 하고, 변환되게 하는 것이 소프트웨어 기업의 역할이다. 아무리 사소한 정보라고 하더라도, 손쉽고, 빠르고, 필요한 형태로 제공되는 것은 분명, 현시점에 없는 것이기 때문에 '혁신'이라고 평가할 수 있다.하지만, 이러한 '없는 것이 만들어진다'는 것에 대해서 소프트웨어 개발자들에게 설명을 할 때에 매우 난처한 경우가 간혹 발생한다. 특히나, 개발 경력이 조금 축적된 개발자들의 경우에 몇 가지 정보들을 재가공하여 만들어진 비즈니스 모델이나 환경에 대해서 매우 폄하하는 식의 발언을 하는 경우가 많다.필자 역시 그러했다. 소프트웨어 개발자이기 때문에 복잡하고 어려운 것을 만들고, 무언가 대단하게 기술적인 내용을 연구하고 실현하는 것이 '혁신'이라고 착각했던 것이다.그냥, 그것은 '기술자'로써의 연구를 위한 과제이지, 현재 비즈니스의 세계나 소프트웨어의 세계에서 이야기하는 '혁신'하고는 거리가 있는 것이다. 정말, '연구만을 위한 기술개발'은 존재하지 않는다.만일 그러한 '연구만을 위한 개발'을 하고 싶다면, 필자는 '오픈소스'를 사용하여 세상을 위하여 재능기부를 하는 마음으로 연구하라고 권하고 싶다. 이렇게, 진행하다고 어느 정도 필요한 가치 이상을 가지게 되었을 때에 기회가 오는 경우도 종종 발견한다.다만, 이러한 '연구'를 위한 기업을 만들거나 조직을 만드는 것은 그냥 가상 기업의 형태로, 자신의 여유 있는 시간을 투자하는 것으로 만족하기를 바란다고 이야기하고 싶다. 물론, 그것 이상의 가치가 있다고 생각하여 개인이 투자하는 것은 전적으로 개인의 선택이기 때문에 말리지는 않겠지만, 굳이, 그렇게 어렵게 할 필요 있는가 싶다.기업을 창업하는 이유는 무언가 구체적인 서비스가 결정되고, 그것에 충분한 자금이나 인력, 시간을 투입하여 시장에서 빠르게 가치를 실현하기 위해서 기업을 만들고 조직을 만드는 것이다. 그 뿐이라고 생각한다.그렇다면, 소프트웨어 산업에서 혁신이란 무엇인가?없는 것을 새롭게 만드는 것은 무엇인가?기술이란 도대체 뭐지?혼동하지 말자. 소프트웨어 산업에서의 혁신은 분명, 없는 것을 만드는 것이다. 그리고, 그 없는 것을 사용하는 소비자가 나타나는 것이다. 그것이 소프트웨어 산업에 있어서의 혁신이다.가장 유명하게 혁신을 설명한 방법이 있다. 가장 혁신을 쉽게 설명한 사례는 Tom Peters의 이야기 중에 '또 다른 햄버거를 내놓지 않는 것이다'라는 말로서 그 내용을 설명해보겠다. 그 글에서는 햄버거로 '혁신'에 대해서 설명한다. '와퍼(Whopper)가 있는데 불고기 와퍼가 나온다고 이것은 혁신이 아니다'. 정형화된 Fast Food는 변하지 않는다. 단지, 그 내용물이 좀 바뀐 것은 혁신이 아니라는 것이다. '정형화되고 싸고 빠른 것'이라는 FastFood인데 그 프로세스는 그대로이며, 빠르고 간편하게 먹는 패스트푸드의 성격은 변하지 않았다.그래서, 와퍼 대신에 불고기 와퍼가 나온 것은 혁신이라고 볼 수 없다. 하지만, 이런 패스트푸드를 정면에서 다시 해석하게 되면 혁신이 된다. 바로 인 앤 아웃 버거이다.신선한 재료와 재료의 선도를 목표로 하고 싸구려 냉동감자 대신에 생감자 French Fried를 튀겨 주는 것이다. 햄버거를 만드는 데 신선하고 선도가 좋은 재료와 생감자를 사용하여 제품을 만든다는 혁신을 실현한 것 In-N-Out의 생각이다.이러한 것처럼 '혁신'이란 기존의 가치를 바꾼 것이다. 그것이 '혁신'이다.물론, 개발자들 간에도 논쟁이 있다. 골수 소프트웨어 개발자들의 경우에 스티브 잡스가 만들어 낸 아이폰의 혁신이 과연 혁신인가? 과거의 것을 합쳐놓은 것 아닌가?라는 식으로 평가할 수 있다. 이런 생각을 가지고 있다면, '혁신'에 대해서 제대로 이해할 수 없는 소프트웨어 개발자가 되어버린 것이라고 필자는 이야기하고 싶다.그래도 스타트업을 하고 싶다면회사를 그만두고 한 번 창업하라고 한다. 사실, 기업이란 작게 망해봐야 정말 제대로 된 경험을 가지게 된다. 그래서, 가능한 젊었을 때에 부담스럽지 않게 망했을 때에 사업을 해보는 것이 가장 현명한 것인지도 모르겠다.한편으로는 두려움이 없고, 그 결과에 대한 책임감에 대해서 잘 모르는 무모한 시절에 창업을 하는 것이 더 현명한 지도 모르겠다.필자는 20대의 무모함과 도전정신으로 창업과 스타트업의 무거운 무게감을 이겨냈다고 생각한다. 현재, 필자의 경우에는 성공보다는 성취감에 더 집중하고 있고, 필자가 하고 싶은 일을 충분하게 하는 것으로 만족한다.너무 많은 준비를 한다고 성공의 요소가 충족되는 것도 아니고, 너무 적은 준비를 한다고 실패의 가능성이 높아지는 것이 아니다. 필자가 경험한 20년의 시간들을 뒤돌아 본다면, 사업은 그런 것 같다.99가지의 필요 충분한 요건을 세웠지만, 1가지의 요소 때문에 실패하는 경우를 보았고, 99가지를 엉터리로 했지만, 1가지의 요소 때문에 성공한 사람들을 보았다. 심지어, 그냥 운으로 성공한 사람도 있었다.필자의 주변을 돌아보면, 현재 대한민국에서 성공적으로 스타트업을 한 사람이라고 평가받는 경우는 정확한 시기에 자신이 만든 서비스를 보유한 기업을 정당한 ‘가격’에 현금으로 팔았거나, 자신의 솔루션을 ‘현금’으로 큰 기업에 판매한 사람들이거나, 투자를 받은 이후에 ‘현금’으로 성공적으로 exit 한 경우를 ‘성공’한 사람으로 평가한다.하지만, 필자는 꼭 그렇게 성공하는 모델을 후배들에게 추천하지 않는다. 필자가 생각하는 성공한 스타트업은 ‘자신이 만들고 싶어 하는 서비스’를 만들고, 자신이 일하고 싶은 동료들과 어울려서 10년이 넘도록 자신의 서비스와 솔루션을 만들고 유지 보수하면서, 자신이 개척한 시장의 소비자들과 공존하는 방법을 터득한 사람들을 ‘성취’한 사람들이라고 평가하고 싶다.후배들은 ‘성공’한 현금을 가진 사람이 될 것인지? ‘성취’한 사람이 될것인이지에 대해서는 각자의 목표와 비전에 맞추어서 생각하기 바란다. 과연, 인생의 목표는 ‘성공’인가? ‘성취’인가?
조회수 3233

Attention is all you need paper 뽀개기

이번 포스팅에서는 포자랩스에서 핵심적으로 쓰고 있는 모델인 transformer의 논문을 요약하면서 추가적인 기법들도 설명드리겠습니다.Why?Long-term dependency problemsequence data를 처리하기 위해 이전까지 많이 쓰이던 model은 recurrent model이었습니다. recurrent model은 t번째에 대한 output을 만들기 위해, t번째 input과 t-1번째 hidden state를 이용했습니다. 이렇게 한다면 자연스럽게 문장의 순차적인 특성이 유지됩니다. 문장을 쓸 때 뒤의 단어부터 쓰지 않고 처음부터 차례차례 쓰는 것과 마찬가지인것입니다.하지만 recurrent model의 경우 많은 개선점이 있었음에도 long-term dependency에 취약하다는 단점이 있었습니다. 예를 들어, “저는 언어학을 좋아하고, 인공지능중에서도 딥러닝을 배우고 있고 자연어 처리에 관심이 많습니다.”라는 문장을 만드는 게 model의 task라고 해봅시다. 이때 ‘자연어’라는 단어를 만드는데 ‘언어학’이라는 단어는 중요한 단서입니다.그러나, 두 단어 사이의 거리가 가깝지 않으므로 model은 앞의 ‘언어학’이라는 단어를 이용해 자연어’라는 단어를 만들지 못하고, 언어학 보다 가까운 단어인 ‘딥러닝’을 보고 ‘이미지’를 만들 수도 있는 거죠. 이처럼, 어떤 정보와 다른 정보 사이의 거리가 멀 때 해당 정보를 이용하지 못하는 것이 long-term dependency problem입니다.recurrent model은 순차적인 특성이 유지되는 뛰어난 장점이 있었음에도, long-term dependency problem이라는 단점을 가지고 있었습니다.이와 달리 transformer는 recurrence를 사용하지 않고 대신 attention mechanism만을 사용해 input과 output의 dependency를 포착해냈습니다.Parallelizationrecurrent model은 학습 시, t번째 hidden state를 얻기 위해서 t-1번째 hidden state가 필요했습니다. 즉, 순서대로 계산될 필요가 있었습니다. 그래서 병렬 처리를 할 수 없었고 계산 속도가 느렸습니다.하지만 transformer에서는 학습 시 encoder에서는 각각의 position에 대해, 즉 각각의 단어에 대해 attention을 해주기만 하고, decoder에서는 masking 기법을 이용해 병렬 처리가 가능하게 됩니다. (masking이 어떤 것인지는 이후에 설명해 드리겠습니다)Model ArchitectureEncoder and Decoder structureencoder는 input sequence (x1,...,xn)<math>(x1,...,xn)</math>에 대해 다른 representation인 z=(z1,...,zn)<math>z=(z1,...,zn)</math>으로 바꿔줍니다.decoder는 z를 받아, output sequence (y1,...,yn)<math>(y1,...,yn)</math>를 하나씩 만들어냅니다.각각의 step에서 다음 symbol을 만들 때 이전에 만들어진 output(symbol)을 이용합니다. 예를 들어, “저는 사람입니다.”라는 문장에서 ‘사람입니다’를 만들 때, ‘저는’이라는 symbol을 이용하는 거죠. 이런 특성을 auto-regressive 하다고 합니다.Encoder and Decoder stacksEncoderN개의 동일한 layer로 구성돼 있습니다. input $x$가 첫 번째 layer에 들어가게 되고, layer(x)<math>layer(x)</math>가 다시 layer에 들어가는 식입니다.그리고 각각의 layer는 두 개의 sub-layer, multi-head self-attention mechanism과 position-wise fully connected feed-forward network를 가지고 있습니다.이때 두 개의 sub-layer에 residual connection을 이용합니다. residual connection은 input을 output으로 그대로 전달하는 것을 말합니다. 이때 sub-layer의 output dimension을 embedding dimension과 맞춰줍니다. x+Sublayer(x)<math>x+Sublayer(x)</math>를 하기 위해서, 즉 residual connection을 하기 위해서는 두 값의 차원을 맞춰줄 필요가 있습니다. 그 후에 layer normalization을 적용합니다.Decoder역시 N개의 동일한 layer로 이루어져 있습니다.encoder와 달리 encoder의 결과에 multi-head attention을 수행할 sub-layer를 추가합니다.마찬가지로 sub-layer에 residual connection을 사용한 뒤, layer normalization을 해줍니다.decoder에서는 encoder와 달리 순차적으로 결과를 만들어내야 하기 때문에, self-attention을 변형합니다. 바로 masking을 해주는 것이죠. masking을 통해, position i<math>i</math> 보다 이후에 있는 position에 attention을 주지 못하게 합니다. 즉, position i<math>i</math>에 대한 예측은 미리 알고 있는 output들에만 의존을 하는 것입니다.위의 예시를 보면, a를 예측할 때는 a이후에 있는 b,c에는 attention이 주어지지 않는 것입니다. 그리고 b를 예측할 때는 b이전에 있는 a만 attention이 주어질 수 있고 이후에 있는 c는 attention이 주어지지 않는 것이죠.Embeddings and Softmaxembedding 값을 고정시키지 않고, 학습을 하면서 embedding값이 변경되는 learned embedding을 사용했습니다. 이때 input과 output은 같은 embedding layer를 사용합니다.또한 decoder output을 다음 token의 확률로 바꾸기 위해 learned linear transformation과 softmax function을 사용했습니다. learned linear transformation을 사용했다는 것은 decoder output에 weight matrix W<math>W</math>를 곱해주는데, 이때 W<math>W</math>가 학습된다는 것입니다.Attentionattention은 단어의 의미처럼 특정 정보에 좀 더 주의를 기울이는 것입니다.예를 들어 model이 수행해야 하는 task가 번역이라고 해봅시다. source는 영어이고 target은 한국어입니다. “Hi, my name is poza.”라는 문장과 대응되는 “안녕, 내 이름은 포자야.”라는 문장이 있습니다. model이 이름은이라는 token을 decode할 때, source에서 가장 중요한 것은 name입니다.그렇다면, source의 모든 token이 비슷한 중요도를 갖기 보다는 name이 더 큰 중요도를 가지면 되겠죠. 이때, 더 큰 중요도를 갖게 만드는 방법이 바로 attention입니다.Scaled Dot-Product Attention해당 논문의 attention을 Scaled Dot-Product Attention이라고 부릅니다. 수식을 살펴보면 이렇게 부르는 이유를 알 수 있습니다.Attention(Q,K,V)=softmax(QKT√dk)V<math>Attention(Q,K,V)=softmax(QKTdk)V</math>먼저 input은 dk<math>dk</math> dimension의 query와 key들, dv<math>dv</math> dimension의 value들로 이루어져 있습니다.이때 모든 query와 key에 대한 dot-product를 계산하고 각각을 √dk<math>dk</math>로 나누어줍니다. dot-product를 하고 √dk<math>dk</math>로 scaling을 해주기 때문에 Scaled Dot-Product Attention인 것입니다. 그리고 여기에 softmax를 적용해 value들에 대한 weights를 얻어냅니다.key와 value는 attention이 이루어지는 위치에 상관없이 같은 값을 갖게 됩니다. 이때 query와 key에 대한 dot-product를 계산하면 각각의 query와 key 사이의 유사도를 구할 수 있게 됩니다. 흔히 들어본 cosine similarity는 dot-product에서 vector의 magnitude로 나눈 것입니다. √dk<math>dk</math>로 scaling을 해주는 이유는 dot-products의 값이 커질수록 softmax 함수에서 기울기의 변화가 거의 없는 부분으로 가기 때문입니다.softmax를 거친 값을 value에 곱해준다면, query와 유사한 value일수록, 즉 중요한 value일수록 더 높은 값을 가지게 됩니다. 중요한 정보에 더 관심을 둔다는 attention의 원리에 알맞은 것입니다.Multi-Head Attention위의 그림을 수식으로 나타내면 다음과 같습니다.MultiHead(Q,K,V)=Concat(head1,...,headh)WO<math>MultiHead(Q,K,V)=Concat(head1,...,headh)WO</math>where headi=Attention(QWQi,KWKi,VWVi)dmodel<math>dmodel</math> dimension의 key, value, query들로 하나의 attention을 수행하는 대신 key, value, query들에 각각 다른 학습된 linear projection을 h번 수행하는 게 더 좋다고 합니다. 즉, 동일한 Q,K,V<math>Q,K,V</math>에 각각 다른 weight matrix W<math>W</math>를 곱해주는 것이죠. 이때 parameter matrix는 WQi∈Rdmodelxdk,WKi∈Rdmodelxdk,WVi∈Rdmodelxdv,WOi∈Rhdvxdmodel<math>WiQ∈Rdmodelxdk,WiK∈Rdmodelxdk,WiV∈Rdmodelxdv,WiO∈Rhdvxdmodel</math>입니다.순서대로 query, key, value, output에 대한 parameter matrix입니다. projection이라고 하는 이유는 각각의 값들이 parameter matrix와 곱해졌을 때 dk,dv,dmodel<math>dk,dv,dmodel</math>차원으로 project되기 때문입니다. 논문에서는 dk=dv=dmodel/h<math>dk=dv=dmodel/h</math>를 사용했는데 꼭 dk<math>dk</math>와 dv<math>dv</math>가 같을 필요는 없습니다.이렇게 project된 key, value, query들은 병렬적으로 attention function을 거쳐 dv<math>dv</math>dimension output 값으로 나오게 됩니다.그 다음 여러 개의 head<math>head</math>를 concatenate하고 다시 projection을 수행합니다. 그래서 최종적인 dmodel<math>dmodel</math> dimension output 값이 나오게 되는거죠.각각의 과정에서 dimension을 표현하면 아래와 같습니다.*dQ,dK,dV<math>dQ,dK,dV</math>는 각각 query, key, value 개수Self-Attentionencoder self-attention layerkey, value, query들은 모두 encoder의 이전 layer의 output에서 옵니다. 따라서 이전 layer의 모든 position에 attention을 줄 수 있습니다. 만약 첫번째 layer라면 positional encoding이 더해진 input embedding이 됩니다.decoder self-attention layerencoder와 비슷하게 decoder에서도 self-attention을 줄 수 있습니다. 하지만 i<math>i</math>번째 output을 다시 i+1<math>i+1</math>번째 input으로 사용하는 auto-regressive한 특성을 유지하기 위해 , masking out된 scaled dot-product attention을 적용했습니다.masking out이 됐다는 것은 i<math>i</math>번째 position에 대한 attention을 얻을 때, i<math>i</math>번째 이후에 있는 모든 position은 Attention(Q,K,V)=softmax(QKT√dk)V<math>Attention(Q,K,V)=softmax(QKTdk)V</math>에서 softmax의 input 값을 −∞<math>−∞</math>로 설정한 것입니다. 이렇게 한다면, i<math>i</math>번째 이후에 있는 position에 attention을 주는 경우가 없겠죠.Encoder-Decoder Attention Layerquery들은 이전 decoder layer에서 오고 key와 value들은 encoder의 output에서 오게 됩니다. 그래서 decoder의 모든 position에서 input sequence 즉, encoder output의 모든 position에 attention을 줄 수 있게 됩니다.query가 decoder layer의 output인 이유는 query라는 것이 조건에 해당하기 때문입니다. 좀 더 풀어서 설명하면, ‘지금 decoder에서 이런 값이 나왔는데 무엇이 output이 돼야 할까?’가 query인 것이죠.이때 query는 이미 이전 layer에서 masking out됐으므로, i번째 position까지만 attention을 얻게 됩니다.이 같은 과정은 sequence-to-sequence의 전형적인 encoder-decoder mechanisms를 따라한 것입니다.*모든 position에서 attention을 줄 수 있다는 게 이해가 안되면 링크를 참고하시기 바랍니다.Position-wise Feed-Forward Networksencoder와 decoder의 각각의 layer는 아래와 같은 fully connected feed-forward network를 포함하고 있습니다.position 마다, 즉 개별 단어마다 적용되기 때문에 position-wise입니다. network는 두 번의 linear transformation과 activation function ReLU로 이루어져 있습니다.FFN(x)=max(0,xW1+b1)W2+b2x<math>x</math>에 linear transformation을 적용한 뒤, ReLU(max(0,z))<math>ReLU(max(0,z))</math>를 거쳐 다시 한번 linear transformation을 적용합니다.이때 각각의 position마다 같은 parameter W,b<math>W,b</math>를 사용하지만, layer가 달라지면 다른 parameter를 사용합니다.kernel size가 1이고 channel이 layer인 convolution을 두 번 수행한 것으로도 위 과정을 이해할 수 있습니다.Positional Encodingtransfomer는 recurrence도 아니고 convolution도 아니기 때문에, 단어의sequence를 이용하기 위해서는 단어의 position에 대한 정보를 추가해줄 필요가 있었습니다.그래서 encoder와 decoder의 input embedding에 positional encoding을 더해줬습니다.positional encoding은 dmodel<math>dmodel</math>(embedding 차원)과 같은 차원을 갖기 때문에 positional encoding vector와 embedding vector는 더해질 수 있습니다.논문에서는 다른 *frequency를 가지는 sine과 cosine 함수를 이용했습니다.*주어진 구간내에서 완료되는 cycle의 개수PE(pos,2i)=sin(pos/100002i/dmodel)<math>PE(pos,2i)=sin(pos/100002i/dmodel)</math>PE(pos,2i+1)=cos(pos/100002i/dmodel)<math>PE(pos,2i+1)=cos(pos/100002i/dmodel)</math>pos<math>pos</math>는 position ,i<math>i</math>는 dimension 이고 주기가 100002i/dmodel⋅2π<math>100002i/dmodel⋅2π</math>인 삼각 함수입니다. 즉, pos<math>pos</math>는 sequence에서 단어의 위치이고 해당 단어는 i<math>i</math>에 0부터 dmodel2<math>dmodel2</math>까지를 대입해 dmodel<math>dmodel</math>차원의 positional encoding vector를 얻게 됩니다. k=2i+1<math>k=2i+1</math>일 때는 cosine 함수를, k=2i<math>k=2i</math>일 때는 sine 함수를 이용합니다. 이렇게 positional encoding vector를 pos<math>pos</math>마다 구한다면 비록 같은 column이라고 할지라도 pos<math>pos</math>가 다르다면 다른 값을 가지게 됩니다. 즉, pos<math>pos</math>마다 다른 pos<math>pos</math>와 구분되는 positional encoding 값을 얻게 되는 것입니다.PEpos=[cos(pos/1),sin(pos/100002/dmodel),cos(pos/10000)2/dmodel,...,sin(pos/10000)]<math>PEpos=[cos(pos/1),sin(pos/100002/dmodel),cos(pos/10000)2/dmodel,...,sin(pos/10000)]</math>이때 PEpos+k<math>PEpos+k</math>는 PEpos<math>PEpos</math>의 linear function으로 나타낼 수 있습니다. 표기를 간단히 하기 위해 c=100002idmodel<math>c=100002idmodel</math>라고 해봅시다. sin(a+b)=sin(a)cos(b)+cos(a)sin(b)<math>sin(a+b)=sin(a)cos(b)+cos(a)sin(b)</math>이고 cos(a+b)=cos(a)cos(b)−sin(a)sin(b)<math>cos(a+b)=cos(a)cos(b)−sin(a)sin(b)</math> 이므로 다음이 성립합니다.PE(pos,2i)=sin(posc)<math>PE(pos,2i)=sin(posc)</math>PE(pos,2i+1)=cos(posc)<math>PE(pos,2i+1)=cos(posc)</math>PE(pos+k,2i)=sin(pos+kc)=sin(posc)cos(kc)+cos(posc)sin(kc)=PE(pos,2i)cos(kc)+cos(posc)sin(kc)<math>PE(pos+k,2i)=sin(pos+kc)=sin(posc)cos(kc)+cos(posc)sin(kc)=PE(pos,2i)cos(kc)+cos(posc)sin(kc)</math>PE(pos+k,2i+1)=cos(pos+kc)=cos(posc)cos(kc)−sin(posc)sin(kc)=PE(pos,2i+1)cos(kc)−sin(posc)sin(kc)<math>PE(pos+k,2i+1)=cos(pos+kc)=cos(posc)cos(kc)−sin(posc)sin(kc)=PE(pos,2i+1)cos(kc)−sin(posc)sin(kc)</math>이런 성질 때문에 model이 relative position에 의해 attention하는 것을 더 쉽게 배울 수 있습니다.논문에서는 학습된 positional embedding 대신 sinusoidal version을 선택했습니다. 만약 학습된 positional embedding을 사용할 경우 training보다 더 긴 sequence가 inference시에 입력으로 들어온다면 문제가 되지만 sinusoidal의 경우 constant하기 때문에 문제가 되지 않습니다. 그냥 좀 더 많은 값을 계산하기만 하면 되는거죠.Trainingtraining에 사용된 기법들을 알아보겠습니다.Optimizer많이 쓰이는 Adam optimizer를 사용했습니다.특이한 점은 learning rate를 training동안 고정시키지 않고 다음 식에 따라 변화시켰다는 것입니다.lrate=d−0.5model⋅min(step_num−0.5,step_num⋅warmup_steps−1.5)warmup_step<math>warmup_step</math>까지는 linear하게 learning rate를 증가시키다가, warmup_step<math>warmup_step</math> 이후에는 step_num<math>step_num</math>의 inverse square root에 비례하도록 감소시킵니다.이렇게 하는 이유는 처음에는 학습이 잘 되지 않은 상태이므로 learning rate를 빠르게 증가시켜 변화를 크게 주다가, 학습이 꽤 됐을 시점에 learning rate를 천천히 감소시켜 변화를 작게 주기 위해서입니다.RegularizationResidual ConnectionIdentity Mappings in Deep Residual Networks라는 논문에서 제시된 방법이고, 아래의 수식이 residual connection을 나타낸 것입니다.yl=h(xl)+F(xl,Wl)<math>yl=h(xl)+F(xl,Wl)</math>xl+1=f(yl)<math>xl+1=f(yl)</math>이때 h(xl)=xl<math>h(xl)=xl</math>입니다. 논문 제목에서 나온 것처럼 identity mapping을 해주는 것이죠.특정한 위치에서의 xL<math>xL</math>을 다음과 같이 xl<math>xl</math>과 residual 함수의 합으로 표시할 수 있습니다.x2=x1+F(x1,W1)<math>x2=x1+F(x1,W1)</math>x3=x2+F(x2,W2)=x1+F(x1,W1)+F(x2,W2)<math>x3=x2+F(x2,W2)=x1+F(x1,W1)+F(x2,W2)</math>xL=xl+L−1∑i=1F(xi,Wi)<math>xL=xl+∑i=1L−1F(xi,Wi)</math>그리고 미분을 한다면 다음과 같이 됩니다.σϵσxl=σϵσxLσxLσxl=σϵσxL(1+σσxlL−1∑i=1F(xi,Wi))<math>σϵσxl=σϵσxLσxLσxl=σϵσxL(1+σσxl∑i=1L−1F(xi,Wi))</math>이때, σϵσxL<math>σϵσxL</math>은 상위 layer의 gradient 값이 변하지 않고 그대로 하위 layer에 전달되는 것을 보여줍니다. 즉, layer를 거칠수록 gradient가 사라지는 vanishing gradient 문제를 완화해주는 것입니다.또한 forward path나 backward path를 간단하게 표현할 수 있게 됩니다.Layer NormalizationLayer Normalization이라는 논문에서 제시된 방법입니다.μl=1HH∑i=1ali<math>μl=1H∑i=1Hail</math>σl= ⎷1HH∑i=1(ali−μl)2<math>σl=1H∑i=1H(ail−μl)2</math>같은 layer에 있는 모든 hidden unit은 동일한 μ<math>μ</math>와 σ<math>σ</math>를 공유합니다.그리고 현재 input xt<math>xt</math>, 이전의 hidden state ht−1<math>ht−1</math>, at=Whhht−1+Wxhxt<math>at=Whhht−1+Wxhxt</math>, parameter g,b<math>g,b</math>가 있을 때 다음과 같이 normalization을 해줍니다.ht=f[gσt⊙(at−μt)+b]<math>ht=f[gσt⊙(at−μt)+b]</math>이렇게 한다면, gradient가 exploding하거나 vanishing하는 문제를 완화시키고 gradient 값이 안정적인 값을 가짐로 더 빨리 학습을 시킬 수 있습니다.(논문에서 recurrent를 기준으로 설명했으므로 이에 따랐습니다.)DropoutDropout: a simple way to prevent neural networks from overfitting라는 논문에서 제시된 방법입니다.dropout이라는 용어는 neural network에서 unit들을 dropout하는 것을 가리킵니다. 즉, 해당 unit을 network에서 일시적으로 제거하는 것입니다. 그래서 다른 unit과의 모든 connection이 사라지게 됩니다. 어떤 unit을 dropout할지는 random하게 정합니다.dropout은 training data에 overfitting되는 문제를 어느정도 막아줍니다. dropout된 unit들은 training되지 않는 것이니 training data에 값이 조정되지 않기 때문입니다.Label SmoothingRethinking the inception architecture for computer vision라는 논문에서 제시된 방법입니다.training동안 실제 정답인 label의 logit은 다른 logit보다 훨씬 큰 값을 갖게 됩니다. 이렇게 해서 model이 주어진 input x<math>x</math>에 대한 label y<math>y</math>를 맞추는 것이죠.하지만 이렇게 된다면 문제가 발생합니다. overfitting될 수도 있고 가장 큰 logit을 가지는 것과 나머지 사이의 차이를 점점 크게 만들어버립니다. 결국 model이 다른 data에 적응하는 능력을 감소시킵니다.model이 덜 confident하게 만들기 위해, label distribution q(k∣x)=δk,y<math>q(k∣x)=δk,y</math>를 (k가 y일 경우 1, 나머지는 0) 다음과 같이 대체할 수 있습니다.q′(k|x)=(1−ϵ)δk,y+ϵu(k)<math>q′(k|x)=(1−ϵ)δk,y+ϵu(k)</math>각각 label에 대한 분포 u(k)<math>u(k)</math>, smooting parameter ϵ<math>ϵ</math>입니다. 위와 같다면, k=y인 경우에도 model은 p(y∣x)=1<math>p(y∣x)=1</math>이 아니라 p(y∣x)=(1−ϵ)<math>p(y∣x)=(1−ϵ)</math>이 되겠죠. 100%의 확신이 아닌 그보다 덜한 확신을 하게 되는 것입니다.Conclusiontransformer는 recurrence를 이용하지 않고도 빠르고 정확하게 sequential data를 처리할 수 있는 model로 제시되었습니다.여러가지 기법이 사용됐지만, 가장 핵심적인 것은 encoder와 decoder에서 attention을 통해 query와 가장 밀접한 연관성을 가지는 value를 강조할 수 있고 병렬화가 가능해진 것입니다.Referencehttp://www.whydsp.org/280http://mlexplained.com/2017/12/29/attention-is-all-you-need-explained/http://openresearch.ai/t/identity-mappings-in-deep-residual-networks/47https://m.blog.naver.com/PostView.nhn?blogId=laonple&logNo=220793640991&proxyReferer=https://www.google.co.kr/https://www.researchgate.net/figure/Sample-of-a-feed-forward-neural-network_fig1_234055177https://arxiv.org/abs/1603.05027https://arxiv.org/abs/1607.06450http://jmlr.org/papers/volume15/srivastava14a.old/srivastava14a.pdfhttps://arxiv.org/pdf/1512.00567.pdf
조회수 911

[퍼포몸쓰 일상] #0 어쩌다 슬라운드

다니던 회사를 그만두고 한 달 정도 방황했다. 친구들의 동업 제안, 머릿속을 맴도는 사업 아이디어, 이런저런 스카우트 제의. 무엇하나 쉬운 게 없다고 생각했다. 핑계처럼 로켓펀치를 켜고 뻑뻑한 눈알 위를 겉도는 채용공고를 훑었다.딱 하나, 홈에 덜컥 걸리는 느낌이 들었다. 저녁 8시 40분. 입사 지원하고 두 시간이 채 지나지 않아 전화가 걸려왔다. 당황과 반가움 중간 어딘가의 감정을 안고 통화했던 기억이 난다. 그들이 찾던 포지션이 신기할 정도로 나와 맞아떨어진다는 데서 오는 반가움. 굉장히 빠른 액션에서 오는 당황. 전화받고 이틀 후 오전 11시로 인터뷰 약속이 잡혔는데 재밌는 건 그 날이 일요일이었다는 거다. 많은 인터뷰를 봤지만(인터뷰어로서, 인터뷰이로서) 주말 오전 인터뷰는 처음이었다. 좋고 나쁨을 떠나서 나에겐 이례적인 일이라 가벼운 마음으로 갈지, 진중한 마음으로 갈지 갈팡질팡했다.일요일 오전 11시.매트리스 업계의 적폐를 바꾸고 싶다던 두 남자와 만나 가장 먼저 한 이야기는 폴리에스테르 빨대에 관해서였다. 거북이의 콧구멍에서 빨대를 뽑아내는 영상 속 거북이가 얼마나 쾌감에 젖은 표정을 지었는지가 우리의 첫 이야기 소재였다. 아무도 어색해하지 않고 첫 만남에서 그런 이야기부터 시작했다는 게 지금도 조금 어처구니가 없지만 우리는 꽤 진지하게 이야기를 이어나갔다.다른 건 모르겠고, 제품 하나는 잘 만들고 싶었다던 그들은 고맙게도 내가 개인적으로 끄적이던 콘텐츠들을 너무나 마음에 들어했다. 반대로 난 짧은 대화에서도 묻어 나오는 그들의 제품에 대한 자부심과 전문성, 열의가 좋았다. 난 내 길지 않은 커리어의 대부분인 4년 반 정도를 스타트업에서 보냈다. 그래서 초기 스타트업이 멤버의 유능함과는 별개로 얼마나 고단한 길을 걷는지 잘 알고 있다.'그동안 쉼 없이 고생했으니 이번엔 좀 편하게 일하자''일단 돈 많이 주는 곳으로 가자''이름이 알려진 곳으로 가자'이직 고민을 하면서 머릿속을 가득 메웠던 생각들은 결국 사람 앞에 스러졌다. 초기 스타트업에서 굴러다녔던 경험만큼, 능력 있고 좋은 사람들과 같이 일하는 즐거움을 알기에 두 명의 founder와 이야기하면서 다시 한번 가족을 생각하지 않는 이기적인 결정을 내렸다(부모님, 장모님, 마누라 죄송합니다).一切有爲法 如夢幻泡影 如露亦如電 應作如是觀스타트업을 하면서 가장 많이 떠올리는 문구다(참고로 교회 다닌다). 현실의 꿈이 비록 손에 잡히지 않더라도 꿈을 빚기 위해 그렇게 난 슬라운드에 콘텐츠 마케터로 합류했다.  
조회수 1417

A씨의 일주일

스포카 개발팀 문성원입니다. 오늘은 스포카 개발팀의 가공의 개발자 A씨의 일주일을 통해, 스포카 개발팀에서는 일주일간의 개발 일정을 어떻게 진행하는지 살펴보겠습니다. 평소 스타트업(Startup) 개발팀의 문화에 관심이 있으셨던 분들에게 도움이 되길 바랍니다.월요일오전 10시, A씨는 평소보다 조금 일찍 사무실에 도착했습니다. 매주 월요일은 스포카 전체 미팅이 있는 날이기 때문이죠. 한 주간 각자 진행한 것을 토대로 이번 주에 진행할 일을 대외적으로 공표하는 이 회의에 앞서, 스포카 개발팀은 따로 미팅을 잠깐 가집니다. 그동안 지난 주 개발 사항, 이번 주 구현 목록 등을 트렐로(Trello)를 통해 정리한 뒤, 이를 전체 미팅에서 공유합니다. A씨는 지난 주에 미쳐 다 구현하지 못했던 서버의 몇 가지 기능과 클라이언트 신버전 배포 준비를 하게 되었습니다.정신없이 회의 하고 났더니 벌써 점심시간입니다. 늘 가던 근처 식당에서 즐겁게 점심을 먹고 사무실로 올라온 A씨는 막간을 이용해 간밤에 올라온 스포카 개발 블로그의 원고를 검토합니다. 몇 가지 오탈자와 맞춤법을 지적한 뒤 모두가 지루해할 월요일 오후 1~2시경에 공개하는 것이 목표입니다.올라간 블로그 글을 확인한 뒤에, A씨는 구현해야 할 서버 기능을 살펴보기로 했습니다. 생각보단 많긴 하지만 일주일 안에는 어떻게든 끝낼 수도 있을 것 같은 분량이네요. 우선 트렐로에 올라온 카드의 명세를 토대로 작업해야 할 내용을 체크리스트(Check List)로 정리합니다. 그다음은 모두가 짐작하시듯이 열심히 일합니다. A씨는 프로니까요.어느덧 저녁 시간이 다 되었습니다. 특별히 일이 없는 이상 야근은 하지 않는 주의인 A씨지만, 오늘만큼은 저녁을 먹고 조금 더 남아있기로 합니다. 팀 내에서 진행하고 있는 스터디 때문이죠. 혼자서 읽기는 까다로웠던 책을 다 같이 읽어보니 조금은 이해가 더 되는 느낌이 드네요.화요일A씨는 오전에 작업하던 중 이상한 점을 발견합니다. 구현하기로 한 기능이 기존 기능과 모순이 되기 때문이죠. 이걸 어떻게 해결할까 고민하던 A씨는 다행히 사무실에 남아있던 엔에이블러(Enabler)팀원들과 간단하게 미팅을 합니다. 문제를 설명하고 명세를 다시 확인한 A씨는 작성한 회의록과 함께 배포합니다. 트렐로의 해당 카드에도 첨부하여 나중에 다시 볼 수 있게 하는 것은 기본입니다.뜻하지 않은 문제 때문에 오전을 날려서 기분이 나빠진 A씨지만, 다행히 좋아하는 스파게티를 먹고 기운을 내기로 했습니다. 사무실에 올라와 인터넷 뉴스와 페이스북을 잠시 보던 A씨는 암묵적으로만 정해진 점심시간이 끝나자 바로 작업을 시작합니다. A씨는 프로니까요.그런데 문제가 있습니다. 오전에 배포한 회의록을 읽어 본 다른 팀원들이 이건 다른 문제의 원인이 될 수 있다고 합니다. A씨는 새 기능 추가가 단순히 로직이 아니라 클라이언트 UI를 포함한 대규모 변경이 필요하다는 것을 깨닫습니다. A씨는 새 기능에 대한 대략적인 스케치를 발사믹 목업(Balsamiq Mockup)으로 마친 뒤 이를 다시 배포합니다. 또한, 관련된 카드에 설명도 잊지 않습니다.수요일매주 수요일 오전에 스포카 개발팀은 짧은 미팅을 합니다. 금주의 진행사항 중 변경사항이나 도움이 필요한 내용을 공유하는 자리인데요. 여기서 A씨는 어제 일을 다시 정리해서 이야기하고, 일정이 지연될 수 있음을 전달합니다. A씨에게 할당된 카드 일부를 다음 주로 미루거나, 좀 한가한 사람에게 나눠주는 형식으로 짐을 던 A씨였지만, 여전히 큰일이 되어버린 기능 변경은 무거운 짐입니다.이런 대량의 작업 때문에 고민하던 A씨에게 같은 팀 B씨가 어떤 라이브러리를 소개해줍니다. A씨는 처음 보는 라이브러리인지라 B씨가 전담해서 가르쳐주는 모양이 되었지만, 생각보다 문제 해결에 큰 도움이 될 것 같습니다. 마침 다음 주에 개발 블로그에 글을 써야 할 당번이 된 A씨는 그 라이브러리에 대해 좀 더 공부해서 쓰기로 정합니다.B씨의 도움 덕에 진행 속도가 붙은 A씨는, 금주 업무 중 하나였던 클라이언트 새 버전의 테스트를 내일부터 진행하기 위해 페이스북이나 인터넷 뉴스도 보지 않은 채 열심히 일합니다. 이런 A씨의 프로다운 모습에 하늘도 감탄했는지, 퇴근 시간인 7시 전에 작업을 끝낸 A씨는 구현된 기능들을 테스트 해 보고 팀의 다른 개발자와 공유하기 위해 github에 만들어진 스포카 서버 코드 저장소에 푸시(Push)합니다.목요일구글 플레이(Google Play)는 하루 정도면 배포가 되니 다행이지만 애플 앱스토어(Apple App Store)는 일주일 정도의 심사기간이 있기 때문에 거절(Reject)당하지 않게 철저히 준비해야 합니다. 그래서 어느 때보다 A씨는 날카로운 눈매로 클라이언트를 점검합니다. 아니나 다를까 메뉴를 이동하다 보니 화면 구성이 흐트러지는 버그가 발견되었습니다. 하지만 프로답게 A씨는 당황하지 않고 재현 조건을 확인한 뒤, 클라이언트 담당자인 C씨에게 알려줍니다. “클라이언트 관련한 버그를 찾았는데, 트렐로를 확인해보세요.”라구요. QA(Quality Assurance) 업무 역시 스포카 개발팀은 직접 처리합니다.밖에 비가 오는지라 피자를 시켜먹은 뒤, 자리에 앉아 잠깐 쉬고 있던 A씨에게 D씨가 다가와서는, “어제 푸시한 소스를 내려받다(Pull)가 충돌(Conflict)이 났는데, 어떻게 병합(Merge)해야 할지 모르겠네요.” 라며 묻습니다. A씨는 D씨와 충돌이 난 소스를 함께 검토하고 문제가 발생하지 않게끔 조정한 뒤 이를 다시 푸시해서 상황을 종료합니다.이러는 사이 C씨가 A씨가 말한 버그를 고쳤다며 다시 확인해보라고 트렐로의 관련 카드를 “테스트” 리스트로 옮깁니다. A씨는 재현된 상황에서 문제 없이 동작하는 것을 확인하고 카드를 “완료” 리스트로 다시 옮깁니다. 이제 클라이언트 앱을 심의 신청하고 어제 구현한 서버 쪽 코드의 개선사항이 있는지 살펴봅니다. 서버는 클라이언트가 앱스토어나 플레이에 준비되는 것을 확인한 뒤, DotCloud에서 제공하는 배포 스크립트를 통해 손쉽게 버전업할 수 있기 때문에 시간이 좀 남아 있습니다. 현재로선 특별히 더 손댈 부분이 없다는 걸 확인한 A씨는 오늘도 즐겁게 퇴근합니다.금요일월요일과 마찬가지로 오늘도 A씨는 평소보다 조금 서둘러서 사무실에 도착했습니다. 오늘은 사내 전체적으로 한 주간 있었던 업무 내용을 간략하게 보고하는 자리가 있습니다. A씨는 이번 주에 맡은 서버 개발이 이러저러해서 이렇고 저렇게 바뀌었다고 설명한 뒤, 앱스토어에 신청되었다는 사실을 공지합니다. 전체 보고가 끝난 뒤엔 개발팀은 따로 남아서 약간 자세하게 금주 작업을 공유하면서 트렐로의 “완료” 상태에 있는 카드들을 정리하는 시간을 갖습니다.점심을 먹고 나서, 이번 주에 더는 급한 일정이 없다는 것을 확인한 A씨는 개발 블로그에 쓸 글을 정리하기 시작합니다. 수요일에 B씨가 알려 준 라이브러리의 사용 방법은 대강 배웠지만, 그것을 남에게 설명할 수 있을 만큼 자세히 알지는 못했기 때문에 A씨는 한동안 공식 문서와 예제 코드들과 씨름합니다. 그래도 어느새 옆에서 거들기 시작한 B씨 덕에 글은 생각보다 순조롭게 마무리되었습니다. 이제 다음 주 월요일까지 퇴고해서 블로그에 공개하기만 하면 되죠.생각보다 오늘 업무를 끝낸 A씨는 친구들과 약속이 있는 홍대로 가기 위해, 7시 정시에 사무실을 떠납니다.#스포카 #개발 #개발자 #개발팀 #개발자의일주일 #개발자의일상 #인사이트 #경험공유

기업문화 엿볼 때, 더팀스

로그인

/