비트윈에서는 서비스 초기부터 HBase를 주요 데이터베이스로 사용하였습니다. HBase에서도 일반적인 다른 NoSQL처럼 트랜잭션을 제공하지 않습니다. HBase, Cassandra와 MongoDB는 하나의 행 혹은 하나의 Document에 대한 원자적 연산만 제공합니다. 하지만 여러 행에 대한 연산들을 원자적으로 실행할 수 있게 해주는 추상화된 트랜잭션 기능이 없다면 보통의 서비스 개발에 어려움을 겪게 됩니다. 비트윈 개발팀은 이런 문제를 해결하기 위해 노력했으며, 결국 HBase에서 트랜잭션을 제공해주는 라이브러리인 Haeinsa를 구현하여 실제 서비스에 적용하여 성공적으로 운영하고 있습니다. VCNC에서는 Haeinsa를 오픈소스로 공개하고 이번 글에서 이를 소개하고자 합니다.Haeinsa란 무엇인가?Haeinsa는 Percolator에서 영감을 받아 만들어진 트랜잭션 라이브러리입니다. HAcid, HBaseSI 등 HBase상에서 구현된 트랜잭션 프로젝트는 몇 개 있었지만, 성능상 큰 문제가 있었습니다. 실제로 서비스에 적용할 수 없었기 때문에 Haeinsa를 구현하게 되었습니다. Haeinsa를 이용하면 다음과 같은 코드를 통해 여러 행에 대한 트랜잭션을 쉽게 사용할 수 있습니다. 아래 예시에는 Put연산만 나와 있지만, 해인사는 Put외에도 Get, Delete, Scan 등 HBase에서 제공하는 일반적인 연산들을 모두 제공합니다.HaeinsaTransaction tx = tm.begin(); HaeinsaPut put1 = new HaeinsaPut(rowKey1); put1.add(family, qualifier, value1); table.put(tx, put1); HaeinsaPut put2 = new HaeinsaPut(rowKey2); put2.add(family, qualifier, value2); table.put(tx, put2); tx.commit(); Haeinsa의 특징Haeinsa의 특징을 간략하게 정리하면 다음과 같습니다. 좀 더 자세한 사항들은 Haeinsa 위키를 참고해 주시기 바랍니다.ACID: Multi-Row, Multi-Table에 대해 ACID 속성을 모두 만족하는 트랜잭션을 제공합니다.Linear Scalability: 트래픽이 늘어나더라도 HBase 노드들만 늘려주면 처리량을 늘릴 수 있습니다.Serializability: Snapshot Isolation보다 강력한 Isolation Level인 Serializability를 제공합니다.Low Overhead: NoSQL상에서의 트랜잭션을 위한 다른 프로젝트에 비해 오버헤드가 적습니다.Fault Tolerant: 서버나 클라이언트가 갑자기 죽더라도 트렌젝션의 무결성에는 아무 영향을 미치지 않습니다.Easy Migration: Haeinsa는 HBase를 전혀 건드리지 않고 클라이언트 라이브러리만 이용하여 트랜잭션을 구현합니다. 각 테이블에 Haeinsa 내부적으로 사용하는 Lock Column Family만 추가해주면 기존에 사용하던 HBase 클러스터에도 Haeinsa를 쉽게 적용할 수 있습니다.Used in practice: 비트윈에서는 Haeinsa를 이용하여 하루에 3억 건 이상의 트랜잭션을 처리하고 있습니다.Haeinsa는 오픈소스입니다. 고칠 점이 있다면 언제든지 GitHub에 리포지터리에서 개선에 참여하실 수 있습니다.Haeinsa의 성능Haeinsa는 같은 수의 연산을 처리하는 트랜잭션이라도 소수의 Row에 연산이 여러 번 일어나는 경우가 성능상 유리합니다. 다음 몇 가지 성능 테스트 그래프를 통해 Haeinsa의 성능에 대해 알아보겠습니다.아래 그래프는 3개의 Row에 총 6개의 Write, 3개의 Read연산을 수행한 트랜잭션의 테스트 결과입니다. 두 개의 Row에 3Write, 1Read 연산을 하고, 한 개의 Row에 1Read 연산을 한 것으로, 비트윈에서 가장 많이 일어나는 요청인 메시지 전송에 대해 시뮬레이션한 것입니다. 실제 서비스에서 가장 많이 일어나는 종류의 트랜잭션이라고 생각할 수 있습니다. 그런데 그냥 HBase를 사용하는 것보다 Haeinsa를 이용하는 것이 더 오히려 좋은 성능을 내는 것을 알 수 있습니다. 이는 Haeinsa에서는 커밋 시에만 모든 변경사항을 묶어서 한 번에 반영하기 때문에, 매번 RPC가 일어나는 일반 HBase보다 더 좋은 성능을 내는 것입니다.HBase 클러스터가 커질수록 트랜잭션 처리량이 늘어납니다. HBase와 마찬가지입니다.HBase 클러스터의 크기에 따른 응답시간 입니다. HBase와 다르지 않습니다..아래 그래프는 2개의 Row에 각각 한 개의 Write, 나머지 한 개의 Row에는 한 개의 Read 연산을 하는 트랜잭션에 대해 테스트한 것입니다. 각 Row에 하나의 연산만이 일어나기 때문에 최악의 경우라고 할 수 있습니다. 처리량과 응답시간 모두 그냥 HBase를 사용하는 것보다 2배에서 3배 정도 좋지 않은 것을 알 수 있습니다. 하지만 이 수치는 DynamoDB 상의 트랜잭션과 같은 다른 트랜잭션 라이브러리와 비교한다면 상당히 좋은 수준입니다.HBase보다 처리량이 떨어지긴 하지만, 클러스터가 커질수록 처리량이 늘어납니다.HBase보다 응답시간이 크긴 하지만 클러스터 크기에 따른 변화가 HBase와 크게 다르지 않습니다.프리젠테이션Haeinsa에 대한 전반적인 동작 원리와 성능을 소개하는 프리젠테이션입니다. 좀 더 자세히 알고 싶으시다면 아래 프리젠테이션이나 Haeinsa 위키를 참고해주세요.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/2d4b2bd00fc201314ae312fe4cd13937?" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true" style="border: 0px; background: padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 750px; height: 563px;">

안녕하세요. 스포카 크리에이터팀 문성원입니다. 현대적인 프로그래밍 환경에서 네트워크는 더는 특정 직군의 개발자만 접하는 분야가 아닙니다. 그런 만큼 대량의 요청을 네트워크를 통해 송수신하는 프로그램이 생각보다 성능이 나오지 않는 경우를 경험하신 분들도 많으실 겁니다. 물론 스포카 개발팀도 예외는 아니었습니다. 그래서 오늘은 저희의 이러한 경험과 그 해결책-eventlet을 통한 비동기 I/O(Asynchronous I/O)-에 대해 소개합니다.Why우선 스포카 개발팀에서 겪었던 문제부터 시작하죠. 얼마 전 페이스북(facebook)의 FQL(Facebook Query Language)를 통해 정보를 수집해서 이를 활용하는 기능을 작성해야 했습니다. 기존의 함수들은 필요할 때마다 FQL을 요청하는 방식이었고 당연히 이건 너무 느렸죠. 그래서 생각한 것이 “하루의 일정 시간마다 대량의 FQL 요청을 보내서 필요한 정보를 미리 갱신시켜놓자.”였습니다. 여기까진 좋았죠. 이때 제가 작성한 코드의 얼개를 살펴보면 대강 이렇습니다.# 페이스북 계정들을 가져와서 반복하면서for account in FacebookAccount.query:    account.update() #FQL을 보내자.view rawgistfile1.py hosted with ❤ by GitHub그런데 문제가 있었습니다. 기존의 FQL을 보내는 FacebookAccount.update()는 FQL요청이 완료될때까지 멈추고 기다립니다. 대부분의 FQL요청이 2, 3초 정도 걸린다고 했을 때 이러한 지연은 매우 치명적입니다. 대안이 필요했고 자연스레 떠오른 것이 서두에 소개한 비동기 I/O(Asynchronous I/O)였습니다.Asynchronous과거 일부 고급 서버 개발자만 알고 있는(혹은 알아야 하는) 기술로 치부되던 ‘비동기(Asynchronous)’란 개념은 2000년대 들어 등장한 Ajax(Asynchronous JavaScript and XML)의 성공 이후 많은 개발자에게 강한 인상을 줬습니다. 사용자는 HTTP 요청이 끝날 때까지 멈추어 있는 하얀 화면으로부터 해방되었고, 다양하고 많은 요청과 응답들이 자연스럽게 서버로 흘러들어 가서 나왔습니다. 개발자들의 이러한 경험과 통찰은 이후 node.js와 같은 플랫폼의 등장에도 많은 영향을 끼쳤습니다.다시 문제로 돌아가죠. 그렇다면 이러한 비동기에 관한 개념은 위의 상황을 어떻게 해결할 수 있을까요? 문제의 원인부터 다시 살펴봅시다. 2, 3초 정도씩 걸리는 FQL 요청이 문제일까요? 물론 요청이 매우 빨리 처리된다면 별도의 처리 없이도 저 코드는 문제없이 동작합니다. 하지만 현실적으로 이런 I/O의 속도를 빠르게 하는데에는 물리적으로 한계가 있습니다. 오히려 여기에서 주목해야 할 점은 ‘2, 3초’ 보다 ‘기다린다’라는 점입니다. FacebookAccount.update() 같은 경우, I/O가 처리되는 동안 CPU는 하던 일을 멈추고 문자 그대로 기다리게 됩니다. 만약 CPU가 멈추지 않고 다른 요청을 보낸다면 어떨까요? 이렇게 말이죠.비동기만으로는 부족하다?이러한 아이디어는 그동안 많은 개발자가 대량의 I/O를 다루는 올바른 방식으로 여겨왔습니다. 하지만 보통 이러한 비동기 I/O를 통한 구현은 동기식 I/O와는 좀 다른 형태를 띠게 됩니다. 이렇게 말이죠.# http://docs.python.org/library/asyncore.html#asyncore-example-basic-http-clientimport asyncore, socketclass HTTPClient(asyncore.dispatcher):    def __init__(self, host, path):        asyncore.dispatcher.__init__(self)        self.create_socket(socket.AF_INET, socket.SOCK_STREAM)        self.connect( (host, 80) )        self.buffer = 'GET %s HTTP/1.0\r\n\r\n' % path    def handle_connect(self):        pass    def handle_close(self):        self.close()    def handle_read(self):        print self.recv(8192)    def writable(self):        return (len(self.buffer) > 0)    def handle_write(self):        sent = self.send(self.buffer)        self.buffer = self.buffer[sent:]client = HTTPClient('www.python.org', '/')asyncore.loop()view rawgistfile1.py hosted with ❤ by GitHub불행하게도, 이 경우 기존에 사용하던 urllib2대신 HTTP 요청을 처리하는 핸들러를 이처럼 재작성 해야합니다. 거기에 FacebookAccount.update()의 호출 방식마저 바뀔 수 있죠. 더군다나 콜백(Callback) 투성이의 코드는 유지보수가 쉬어 보이지도 않습니다. 여러모로 손이 많이 가는 상황이죠.결국, 기존 코드를 최대한 수정하지 않으면서도, 어느 정도 성능은 보장되는 그런 해결책이 필요했습니다. 그런 해결책이 있을까요? 다행히도 그렇습니다.What저희가 해결책으로 택한 eventlet은 Python(정확히는 CPython)에서 코루틴(Coroutine)을 지원하기 위해 만들어진 greenlet을 이용해 작성된 네트워크 관련 라이브러리입니다. 생소한 용어가 갑자기 튀어나와서 놀라셨을지도 모르니 우선 eventlet에 대해 설명하기 전에 앞에 나온 용어들을 찬찬히 한번 살펴보죠.코루틴과 greenlet먼저 코루틴(Coroutine)부터 살펴보죠. 전산학도라면 누구나 그 이름을 한번은 들어봤을 도널드 카누쓰(Donald Knuth)는 자신의 저서 The Art of Computer Programming에서 코루틴을 다음과 같이 설명합니다.Subroutines are special cases of more general program components, called “coroutines.” In contrast to the unsymmetric relationship between a main routine and a subroutine, there is complete symmetry between coroutines, which call on each other.코루틴은 우리가 잘 알고 있는 서브루틴(Subroutine)과 달리 진입점(Entry Point)이 여러 개일 수 있습니다. 쉽게 이야기하면 실행을 멈췄다가(Suspend) 재개(Resume)할 수 있다는 점인데요. 이 특성을 살리면 우리가 익히 아는 스레드(Thread)처럼 쓸 수 있게 됩니다. 다만 스레드와 달리 코루틴은 비선점적(Non-Preemptive)이기때문에 코드의 흐름을 전적으로 사용자가 제어할 수 있습니다.하지만 불행히도 모든 언어에서 이런 코루틴이 지원되진 않습니다. greenlet은 이런 코루틴을 CPython에서 지원하기 위해 작성된 라이브러리입니다.eventlet코루틴을 통해 스레드를 대체할 수 있다는 점에 주목한 사람들은 greenlet을 통해 유용한 네트워크 라이브러리를 만들어냈습니다. eventlet도 그 중 하나죠. 잠시 eventlet의 소갯글을 봅시다.Eventlet is a concurrent networking library for Python that allows you to change how you run your code, not how you write it.위에서 볼 수 있듯이 eventlet은 사용성에 중점을 두었습니다. 기존의 블로킹 I/O 스타일의 프로그래밍에 익숙한 개발자들도 쉽게 비동기 I/O의 장점을 얻을 수 있게끔 하는 게 목적이죠.특히 저희가 주목한 점은 eventlet의 멍키패치 기능입니다. 멍키패치는 본래 동적 언어에서 런타임에 코드를 고쳐서 별도의 파일 변경 없이 본래 소스의 기능을 변경하는 것을 말합니다. eventlet은 eventlet.monkey_patch 메서드를 통해 표준 라이브러리의 I/O 라이브러리를 논블러킹으로 동작하게끔 변경해서 코루틴에 적합하게 만듭니다.How앞서 소개한 eventlet.monkey_patch를 이용하면 실제로 고칠 부분은 정말로 적어집니다. 다음 코드가 eventlet을 이용해 변경한 전부입니다.import eventleteventlet.monkey_patch() #표준 라이브러리를 변환# 여러가지 import를 하고...pool = eventlet.GreenPool()# 페이스북 계정들을 가져와서 반복하면서for account in FacebookAccount.query:    # 코루틴들에게 떠넘기자.    pool.spawn_n(FacebookAccount.update, account)        pool.waitall()view rawgistfile1.py hosted with ❤ by GitHub정말 적죠? 조금만 구체적으로 살펴보죠. 우선 eventlet.monkey_patch는 socket이나 select등의 Python 표준 라이브러리를 eventlet.green 패키지안에 정의된 코루틴 친화적인 모듈들로 바꿔치기 합니다.# from eventlet/pathcer.pydef monkey_patch(**on):    """Globally patches certain system modules to be greenthread-friendly.    The keyword arguments afford some control over which modules are patched.    If no keyword arguments are supplied, all possible modules are patched.    If keywords are set to True, only the specified modules are patched.  E.g.,    ``monkey_patch(socket=True, select=True)`` patches only the select and     socket modules.  Most arguments patch the single module of the same name     (os, time, select).  The exceptions are socket, which also patches the ssl     module if present; and thread, which patches thread, threading, and Queue.    It's safe to call monkey_patch multiple times.    """        accepted_args = set(('os', 'select', 'socket',                          'thread', 'time', 'psycopg', 'MySQLdb'))    default_on = on.pop("all",None)    for k in on.iterkeys():        if k not in accepted_args:            raise TypeError("monkey_patch() got an unexpected "\                                "keyword argument %r" % k)    if default_on is None:        default_on = not (True in on.values())    for modname in accepted_args:        if modname == 'MySQLdb':            # MySQLdb is only on when explicitly patched for the moment            on.setdefault(modname, False)        on.setdefault(modname, default_on)            modules_to_patch = []    patched_thread = False    if on['os'] and not already_patched.get('os'):        modules_to_patch += _green_os_modules()        already_patched['os'] = True    if on['select'] and not already_patched.get('select'):        modules_to_patch += _green_select_modules()        already_patched['select'] = True    if on['socket'] and not already_patched.get('socket'):        modules_to_patch += _green_socket_modules()        already_patched['socket'] = True    if on['thread'] and not already_patched.get('thread'):        patched_thread = True        modules_to_patch += _green_thread_modules()        already_patched['thread'] = True    if on['time'] and not already_patched.get('time'):        modules_to_patch += _green_time_modules()        already_patched['time'] = True    if on.get('MySQLdb') and not already_patched.get('MySQLdb'):        modules_to_patch += _green_MySQLdb()        already_patched['MySQLdb'] = True    if on['psycopg'] and not already_patched.get('psycopg'):        try:            from eventlet.support import psycopg2_patcher            psycopg2_patcher.make_psycopg_green()            already_patched['psycopg'] = True        except ImportError:            # note that if we get an importerror from trying to            # monkeypatch psycopg, we will continually retry it            # whenever monkey_patch is called; this should not be a            # performance problem but it allows is_monkey_patched to            # tell us whether or not we succeeded            pass    imp.acquire_lock()    try:        for name, mod in modules_to_patch:            orig_mod = sys.modules.get(name)            if orig_mod is None:                orig_mod = __import__(name)            for attr_name in mod.__patched__:                patched_attr = getattr(mod, attr_name, None)                if patched_attr is not None:                    setattr(orig_mod, attr_name, patched_attr)        # hacks ahead; this is necessary to prevent a KeyError on program exit        if patched_thread:            _patch_main_thread(sys.modules['threading'])    finally:        imp.release_lock()view rawgistfile1.py hosted with ❤ by GitHub이렇게 바꿔치기된 eventlet.green안의 모듈들은 I/O에 의해 블럭되는 경우 다른 코루틴에 제어권을 넘기는 식으로 지연을 방지합니다.다른 대안들사실 이러한 목적으로 사용되는 라이브러리는 eventlet만 있는 것은 아닙니다. gevent는 eventlet에서 영향을 받았지만, libevent를 기반으로 하여 더욱 나은 성능과 성숙한 인터페이스를 갖추고 있습니다. 저희처럼 libevent의 설치에 제한이 있는 환경이 아니라면 이쪽을 살펴보셔도 좋습니다.만약 이벤트 주도적 프로그래밍(Event-Driven Programming)에 흥미가 있으신 분은 Twisted역시 좋은 대안이 될 수 있습니다.#스포카 #개발 #개발자 #인사이트 #꿀팁

8월 18일에 입사하여 글을 쓰는 오늘까지 4개월이란 시간이 흘렀다. 트레바리는 4개월을 한 시즌으로 묶어 운영하는 멤버십 서비스이기 때문에 트레바리에서 4개월을 일했다는 건 한 시즌에 필요한 모든 시기를 거쳤다는 의미이다. 4개월을 함께 해야지만 비로소 트레바리를 한 번 했다고 말할 수 있게 된다. 나는 이제서야 트레바리에서 한 번 일했다.트레바리에서의 한 번을 보내며 나는 그동안 무엇을 했는지 정리해보려고 한다. 할 말이 많다 보니 이번 글에서는 기능적으로 무엇을 했는지만 이야기할 예정이다. 어떻게 일했는지, 잘했던 점은 무엇이었는지, 아쉬웠던 점은 얼마나 많았는지에 대한 건 아쉽지만 다음 글에 담기로 했다. 4개월 동안 내가 진행한 일 중 큰 단위의 작업 위주로 살펴보고자 한다.4개월 동안 내가 한 일은 크게 두 가지다. 첫 번째는 기존의 웹 서비스를 개선하는 일. 두 번째는 노가다로 했던 일들에 IT를 끼얹는 일. 두 가지 일에 대한 요구 사항들은 모두 추상적인 문장으로 주어졌고, 나의 역할은 그 추상적인 요구들을 정리하여 실질적인 기능으로 정의하고 구현하는 것이었다. 그동안 어떤 요구 사항들이 있었고 그에 대해 어떤 결과물을 내었는지 정리해보았다.1. 독후감을 활성화되게 만들어주세요.입사 후 최우선으로 개선이 요구됐던 부분은 독후감이었다. 독후감은 트레바리 서비스가 독특하다는 평가를 듣는 이유 중 하나이다. 아무리 돈을 내고 온 멤버일지라도 우리가 내어준 400자의 독후감이라는 숙제를 해오지 않으면 독서 모임에 참가하지 못한다. 우리 크루들은 독후감을 통해 자신의 생각을 한번 정리하고 참가한 독서 모임이 아무런 준비 없이 맞닥뜨리는 독서 모임보다 더 풍성해짐을 안다. 그렇기에 멤버들이 트레바리 홈페이지에서 더 열심히 독후감을 쓰고, 더 많이 다른 사람들의 독후감을 읽고, 더 다양하게 대화할 수 있도록 만들어야 했다.디자인 개선[이전 디자인]일을 시작하자마자 가장 먼저 갈아치우기 시작한 건 디자인이었다. 페이지에 보이는 정보들의 가독성이 나빴다. 독후감 정보와 관련 없는 이미지 배경을 가지고 있었고, 모바일에서는 본문을 포함하여 모든 요소들의 배열이 일정하지 않았다. 가장 문제였던 점은 좋아요 기능이 있음에도 불구하고 유저들이 좋아요 버튼이 있는지를 몰라 활성화가 되지 않는 것이었다.(대표님 얼굴과 우왕이라는 글자가 떡하니 자리 잡은 곳이 좋아요 버튼이다.) 답댓글 없이 한 줄로만 나열된 댓글도 불편했다.[변경한 디자인]전반적으로 컨텐츠가 더 잘 보일 수 있도록 변경했다. 불필요한 배경 이미지를 빼고 책 정보를 추가했다. 좋아요 버튼도 보다 쉽게 인지할 수 있도록 보편적인 모양의 하트로 바꾸었다. 한 줄로만 나왔던 댓글에는 대화하는 듯한 느낌의 UI로 변경하고 답댓글 기능을 추가했다. 특히 모바일에서 더 편하게 쓸 수 있도록 각 요소들을 일정하게 배열했고, 이미지로는 보이지 않겠지만 독후감을 읽고 목록으로 다시 갈 때마다 다른 모임 정보가 뜨는 이상한 시나리오도 개선했다.넛지 만들기더 나은 디자인만으로는 부족했다. 멤버들이 실제로 더 많이 좋아요를 누르고 댓글을 달고 싶게 만들어주는 넛지가 필요했다. 좋아요 수에 따라 재밌는 워딩이 나오고, 댓글 입력 창의 워딩이 항상 다르고 등의 디테일한 요소들을 살렸다. 페이스북 공유하기 기능도 추가했으며 우리 모임에 놀러 오는 멤버들을 보여주는 UI도 추가하는 등의 작업을 진행했다. 하지만 결정적인 한 방이 필요했고 그 한 방은 이달의 독후감 기능이었다.이달의 독후감 선정 기능홈페이지 밖의 운영에서 돌아가던 이달의 독후감이라는 시스템이 있었다. 매 모임마다 가장 좋았던 독후감을 선정하는 것이었는데 잘 알지 못하는 멤버들이 많아 좋아요 수 자체가 적었고, 선정된 독후감을 찾아보기 어려워 활성화가 되지 못했었다. 그래서 이달의 독후감 시스템을 홈페이지에 어워드 형태로 옮겨오면 동기부여와 동시에 별도의 안내 없이도 이달의 독후감 시스템을 학습시킬 수 있겠다고 생각했다.그래서 결과는?결과는 데이터로 나타났다. 디자인과 기능 개선 후 독후감 한 개 당 평균 좋아요/댓글 수가 대략 150% 증가했다. 크루들이 매번 이달의 독후감을 선정하고 하이라이트 구문을 뽑는 오퍼레이션도 줄일 수 있었다. 변경 후 독후감 쓰는 것이 더 즐거워졌다는 멤버 피드백도 종종 들을 수 있었다.2. 멤버십 신청 페이지를 개선해주세요.멤버십 신청 페이지는 트레바리 멤버가 아닌 유저들이 가장 많이 보게 되는 페이지다. 트레바리가 어떤 곳인지 어필하고 결제까지 진행하게 하는 가장 중요한 역할을 하고 있다. 흔히들 말하는 판매 페이지로 트레바리에서 가장 중요한 서비스인 독서 모임을 파는 곳이다. 그 중요성에 비해 디자인과 기능이 모두 엄청나게 부실했고 개선해야 했다.디자인 개선[이전 디자인]대체 트레바리가 어떤 곳인지 알 수 있는 부분이 하나도 없었다. 독서 모임에 대한 설명마저 줄글이 전부였다. 내가 트레바리 독서 모임에 가면 어떤 분위기를 즐길 수 있고 만나는 사람들은 어떨지 상상하기 어려웠다. 모바일에서는 특히 불편했고 필수적인 정보들만 보이는 곳에 불과했다.[변경한 디자인]각 독서 모임에 대한 소개가 풍성하지만 편하도록 변경했다. 이전과 다르게 사진을 많이 활용하여 트레바리 독서 모임이 어떤 분위기인지 보여주고 싶었다. 설명 글도 더 잘 읽힐 수 있도록 배치를 중점적으로 신경 썼고 포인트 컬러를 틈틈이 사용했다. 같은 모임이지만 다양한 시간과 장소가 있는 독서 모임인 경우에는 한 페이지에서 한 번에 볼 수 있도록 구성했다. 모바일 접속자가 압도적으로 많은 만큼 모바일 UI에 많은 시간을 들였다.결제 기능 추가멤버십 신청 페이지에서 가장 큰 문제는 결제였다. 실시간 결제가 아닌 계좌 이체로만 가능하게 되어있다 보니 엄청나게 불편했다. 유저들도 수동으로 이체를 해야 했고, 담당하는 대표님도 24시간 잠도 못자며 휴대폰을 붙잡고 있다가 계좌 이체 알림이 올때마다 등록 처리를 해주어야 했다.(매 시즌 대표님 혼자 몇천 명의 계좌 이체를 확인하고 등록해주셨다. 그래서 멤버십 신청 기간 때에는 제대로 자보신 적이 없다고...)그런데 트레바리는 작은 회사에다 무형의 서비스를 팔고 있다 보니 PG사를 통한 결제를 붙이는 게 어려웠다. PG를 제외한 편하게 결제할 방법을 찾다가 토스 결제를 찾아보게 되었다. 찾자마자 바로 미팅을 진행했고 토스 측에서도 트레바리의 가치를 잘 봐주셔서 미팅부터 결제 연동까지 빠르게 진행하여 구현했다.사랑해요 토스그래서 결과는?막상 개선하여 배포하니 예상보다 저조한 유저 반응이 나타났다. 물론 지난 시즌보다는 훨씬 더 많은 유저분들이 등록하시기는 하였으나 기대했던 목표치에는 못 미쳤다. 디자인이 좋아지고 이용하기 편해지면 당연히 등록 효율이 몇 배로 높아질 거라고 생각했으나 생각처럼 되지 않았다. 신청 기간 내내 저조한 이유에 대한 가설을 세우고, 변경하고, 데이터 보기를 반복했다. 그 과정에서 몇몇 유저분들과 인터뷰를 진행했고 막판에 등록에 영향을 미치는 것은 의외로 홈페이지 사용성이 아닌 다른 곳에 있음을 발견했다. 아쉽게도 늦게 원인을 찾아 더 많은 것을 해보기 전에 신청 기간이 끝나버렸지만, 다음 시즌에는 이번 시즌보다 뾰족하고 탁월하게 개선할 수 있겠다고 생각했다. 영훈님과 함께 공부도 시작해보기로 했다.결제 부분에서는 자세한 데이터를 공개할 수는 없지만 많은 유저들이 토스를 통해 결제를 진행했다. 원래도 트레바리는 N빵 할 일이 많아 토스 송금을 이용하는 유저들이 많았지만 이번 결제 연동을 덕분에 새로 쓰게 된 분도 많아진 것 같았다. 핀테크에 대한 막연한 불안감 때문에 쓰지 않았다는 유저들도 있었지만 막상 써보니 엄청나게 편해서 놀랐다는 피드백도 많이 받았다. 아마도 트레바리에서는 앞으로 계속 토스 송금/결제를 활발하게 사용할 것 같다.3. 트레바리가 어떤 곳인지 보여줍시다.위에서 말한 등록에 영향을 미치는 것은 서비스에 대한 설득이었다. 그동안 트레바리는 지인의 소개로 오는 유저들이 많았고, 기사를 보고 오는 유저들이 많았고, 소문을 듣고 오는 유저들이 많았다. 그래서 따로 트레바리가 어떤 곳인지 잘 설명할 필요성이 적었던 것 같다. 이제는 유저들이 점점 많아지면서 트레바리가 어떤 곳인지 적극적으로 보여줄 필요가 있었고 방치되어 있던 랜딩페이지를 끄집어냈다.[이전 랜딩페이지]이곳만 봐서는 트레바리가 어떤 곳인지 알 수 없었다. 트레바리가 얼마나 매력적인지 어필이 되지 않았고 어떤 활동을 할 수 있는지도 알기 어려웠다.[변경한 랜딩페이지]트레바리가 지향하는 가치들을 더 많이 설명했다. 중간중간 트레바리 사용설명서 영상을 볼 수 있는 곳을 추가했고 실제 멤버들의 후기도 담았다. 트레바리는 독서 모임을 제공하는 서비스이므로 대표적인 독서 모임이 무엇이 있는지도 보여주고 싶었다. 각종 미디어에서 이야기하는 트레바리와 멤버들만을 위한 혜택도 정리해두었다.그래서 결과는?급하게 만드느라 트레바리의 매력을 아직 반의반도 못담았다고 생각한다. 랜딩페이지만 봐도 트레바리가 어떤 곳이고 트레바리를 통해 당신이 얼마나 더 멋있어질 수 있는지를 보여주고 싶다. 랜딩페이지는 꾸준히 만지고 다듬어야 할 과제로 남겨두었다.4. 손에 잡히는 무언가를 주기(일명 손잡무)한 시즌을 끝낸 멤버들에게 각자가 한 시즌 동안 무엇을 해왔는지 쥐여주고 싶었다. 그래서 시즌 말 약 1700명의 멤버들 모두에게 개개인이 이뤄온 활동 데이터를 이미지로 재밌게 엮어 나눠주었다. 기발한 워딩과 이미지는 이 방면에 재능이 있는 세희님과 지현님이 함께해주셨다.[1705 시즌 손잡무][1709 시즌 손잡무]1700명 모두에게 개인화된 이미지를 노가다로 만들어주는 것은 불가능했다. 자동화를 하기 위해서 SQL 쿼리를 통해 필요한 로우 데이터를 추출하고, 스케치라는 디자인 툴을 활용해 이미지 생성을 자동화했다. 덕분에 모든 멤버들의 이미지를 한땀한땀 만드는 노가다를 피하면서도 개인화된 컨텐츠를 제작할 수 있었다. 이 방법은 이다윗님의 코드로 100명 이상의 네임택 한 번에 디자인하기 글을 보고 영감을 받아 가능했다.그래서 결과는?성공적이었다. 인스타그램에 #트레바리를 검색하면 손잡무를 나눠준 시점에 많은 멤버분들이 공유해주신걸 볼 수 있다.(개근상 받으신 분들이 제일 많이 공유해주셨다.) 이미지를 공유해주시면서 4개월 동안 얼마나 즐거웠고 많이 배웠는지에 대한 후기도 소상히 적혀있는 경우도 많아 더욱 뿌듯한 결과물이었다.5. 그 외 각종 버그/개선 요구 사항 해결도 해주세요.각종 UI 및 사용성 개선여러 페이지들의 UI를 개선하고 기능을 개선하여 배포하였다. 자잘한 기능 추가부터 페이지 통째로 갈아엎기까지 손을 댈 수 있는 리소스만큼 건들여보고 개선했다. 이 과정에서는 우선순위를 정하는 일이 중요했는데 우선순위에 대한 이야기는 후에 다시 해볼 예정이다.각종 버그/요구 사항 해결 + 그에 따른 CS내가 만든 것도 많았지만(…) 그거말고도 도대체 개발자가 없을땐 홈페이지가 어떻게 굴러갔지 싶을 정도로 버그가 많았다. 버그도 많고 요구되는 개선 사항도 많았다. 줄어들고는 있지만 아직까지도 버그 및 요구 사항에 응대하는 시간이 하루에 한 시간씩은 꼬박꼬박 들고 있다. 더 많이 줄여나가는 것을 목표로 하고 있다.자동화독서 모임을 이끄는 크루들이 노가다를 하느라 고생하는 시간이 많다. 위에서 이야기 했던 계좌 이체 확인이 가장 큰 사례이다. 그 외에도 개설되는 클럽 데이터 입력을 어드민에서 며칠동안 노가다로 진행해야하는 등의 낭비가 많았다. 이런 부분에서 IT를 끼얹어 공수를 덜 들이고 빠르게 끝낼 수 있도록 엑셀 import 등의 기능을 구현했다.트레바리의 한 번을 끝마치며 나는 그동안 무엇을 했는지 정리해보았다. 쓰다보니 만족스러운 것보다 아쉬운 것들이 눈에 더 많이 들어온다. 무엇이 아쉬웠나 하면 할말이 너무나도 많아 다른 글에 써보기로 하고 이번 글은 기능적인 이야기로만 마무리했다.돌이켜 생각해보면 트레바리에서 쓰이는 기술 스택인 루비도 레일스도, 서버 인프라도 하나 모르는 나를 믿고 이 모든걸 배우고 익힐때까지 기다려준 크루들이 새삼 대단하다고 느낀다. 그 과정에서 실수로 인한 버그도 엄청 많았고 그 버그 때문에 불필요하게 운영 코스트가 늘어났을 때도 있었지만 나무란 적 한 번 없이 격려와 함께 기다려주고 믿어주었다. 그래서 더 열심히 달릴 수 있었던 것 같다.아쉬움과 감사함 때문에라도 다음 4개월에는 일을 더 '잘'하는 사람이 되어야겠다고 다짐했다. 앞으로도 계속 성공하고 실패하고, 배우고 성장한 일들을 꾸준히 기록해나가며 일을 더 잘하는 사람이 되고 싶다. 다음 4개월은 지난 4개월보다 보다 더 실질적이고 큰 변화들을 만들 수 있는 사람이 되어야 겠다. 걱정반 기대반이지만 설레는 마음으로 새로운 시즌을 맞이하며 글을 끝맺으려 한다.어떻게 하면 더 잘할지 고뇌하는 모습의 크루들#트레바리 #기업문화 #조직문화 #CTO #스타트업CTO #CTO의일상 #인사이트

필자가 재직 중인 일정 데이터 스타트업 히든트랙(린더)은 현재 SKT NUGU, Google Assistant에서 '아이돌 캘린더'라는 이름의 일정 검색/구독 서비스를 운영 중이며, 삼성 빅스비와 협업을 통해 내년 상반기 전시/공연 일정 검색/구독 서비스 상용화를 앞두고 있다.세계적으로도 아직 음성 관련 서비스 사례가 많지 않은 상황에서 VUI 기반 서비스 개발에 도움이 될만한 자료를 국내에서 찾기는 더더욱 쉽지 않았고, 향후 음성 기반 서비스를 준비하는 다른 이들이 우리가 겪었던 시행착오를 줄일 수 있기를 바라는 마음으로 간단하게 5부작 형태의 글로 우리가 고민해온 과정을 준비해보았다.1편: 음성 기반 인터페이스의 등장2편: 음성 기반 인터페이스와 TPO3편: 음성 기반 인터페이스와 페르소나4편: 음성 기반 인터페이스 vs GUI5편: 국내 음성 기반 인터페이스 현황1편의 말미에서 언급한 바와 같이 이미 다수의 메이저 업체들이 수년간 경험과 데이터를 기반으로 다양한 VUX 가이드라인을 제시하고 있다. 그리고 그 가이드라인에서 공통적으로 제안하는 VUX 디자인 첫 번째 단계 중 하나는 바로 '구체적인 사용자 환경의 설정'이다.VUX 디자인의 첫 번째 단계는 제공하고자 하는 서비스의 타겟 사용자와 사용자의 상황을 분석하고, 제공할 주요 기능을 목록으로 정의하는 단계입니다. 즉, 이 서비스를 어떤 사용자가 어떤 환경에서 주로 이용할 것인지를 고려하여 제공할 기능 범위를 정의합니다.SKT NUGU VUX가이드라인 중'사용자의 환경'을 구성하는 요소는 매우 복합적이지만 여러 요소들 중에서도 가장 큰 비중을 차지하는 것은 바로 TPO, 즉 시간(Time), 장소(Place), 상황(Occasion)이다.시간과 장소가 동일하더라도 상황이 다를 수 있으며 장소와 상황이 동일하더라도 시간에 따라 사용자의 경험이 달라질 수 있다. 마찬가지로 시간과 상황이 동일하더라도 발화가 이루어지는 장소에 따라 완전히 다른 사용자 경험을 구성하게 된다.몇년 전부터 스피커 등 VUX 서비스를 운영하고 있는 협력사들의 누적된 발화 데이터를 통해 발견할 수 있었던 흥미로웠던 점은 각 TPO에 따라 사용자들이 디바이스, 즉 AI를 대하는 태도가 현저히 상이하다는 점이었다. 일례로 침대 머리맡에 놓여있는 같은 스피커에게 하는 말도 출근 전과 퇴근 후의 요청사항 및 표현 방식이 다르고, 같은 스마트폰에게 하는 요청사항과 표현도 사적인 공간에 있는지, 공적인 공간이 있는지에 따라 확연히 달라진다는 것이다.사용자 경험은 단순히 사용자가 디바이스를 대하는 태도와 요청사항뿐만 아니라 디바이스가 가진 특성에 따라서도 달라질 수 있는데, 각 디바이스가 가진 여러 특이사항 중에서도 가장 중점적으로 살펴볼 부분은 바로 시각적 정보를 전달하는 디스플레이의 존재 여부다.TPO를 구분하는 방법은 여러가지가 있지만 이번 글에서는 구글에서 안내하는 어시스턴트의 4가지 주요 환경을 바탕으로 사용 환경의 차이를 알아보고자 한다.https://assistant.google.com/intl/ko_kr/휴대전화(스마트폰)에서스마트폰은 가장 개인적이고 친밀한 디바이스인 동시에 대표적인 On-the-Go, 즉 언제 어디에서든 사용되는 디바이스다. 사용자가 다수로 지정될 수 있는 스피커와는 달리 개인 1인 당 1대의 디바이스가 할당되기 때문에 사적인 정보를 스스럼없이 털어놓을 수 있게 된다.특성상 사용 시간대와 장소는 어느 한 시점에 국한되지 않으며 메신저, 캘린더 등 일상적인 정보를 가장 가까이서 제공할 수 있는 장점이 있다. 스피커와는 달리 디스플레이가 제공되기 때문에 시각 콘텐츠에 대한 접근이 용이하며, 현재 아이폰 시리와 삼성 빅스비에서 주로 많이 사용되는 기능들로는 기상 알람 세팅, 뉴스/날씨 읽어주기, 메시지 읽어주기, 맛집 검색 등이 있다.집에서집에서 제공되는 VUX 경험은 거주와 생활 형태에 따라 크게 두 가지로 나뉠 수 있다. 크게 개인이 혼자서 디바이스를 활용하게 되는 1인 1 디바이스 형태와 가족들이 함께 하나의 디바이스를 활용하는 다가구 1 디바이스 형태로 나뉘며, 개인이 디바이스를 소유하는 경우 스피커는 주로 사용자가 수면을 취하거나 가장 많은 시간을 보내는 개인 침대 인근 책상 또는 선반에, 가족이 함께 사용하는 디바이스의 경우 거실, 부엌 등의 공용공간에 위치하게 된다.위 언급된 두 시나리오 모두 음악, 뉴스, 날씨 등 청각 콘텐츠를 제공하지만 1인 1 디바이스의 경우에서 디바이스와 보다 높은 친밀도가 형성되는 것을 확인할 수 있으며, 이러한 사용자 시나리오를 카카오 미니의 카톡 읽어주기, 네이버 클로바 연애상담 등의  기능들이 조금씩 추가되고 있다.TV에서현재 KT와 SKT는 기기자니2와 NUGU Btv를 통해 셋톱박스 기능을 탑재하고 있는 스피커를 제공하고 있다. 구글 홈, 네이버 클로바, 카카오 미니 등도 TV와의 연동을 통해 기본적인 채널 변경, 음량 조절 등을 제공하지만 콘텐츠 검색 등 TV 디스플레이의 장점을 100% 활용하기 위해서는 결국 셋톱박스의 역할을 할 수 있어야 한다(구글의 경우 크롬 캐스트 활용이 가능하지만 국내 활용도가 높지 않다). 주로 TV 옆, 또는 TV 자체로 디바이스 역할을 하게 되며 평균적으로 개인 소유 디바이스 중 가장 큰 디스플레이를 제공하는 TV의 특성상 다양한 시각 콘텐츠 검색 및 소비가 가능하다. 1인 1 디바이스에서 주로 위치하는 침대 인근 책상/선반과는 달리 TV의 경우 다가구 1 디바이스의 상황이 자주 발생하며, 구글 등 주요 업체는 사용자 별 목소리 구분 기술을 통해 다가구 1 디바이스 활용 사례에 대비하고 있다.자동차에서우리가 광고를 통해 '자동차에서'의 음성 인터페이스 시나리오를 자주 접하게 되는 이유는 '자동차'라는 환경이 음성 기반 인터페이스의 장점이 극대화되는 공간이기 때문이다. 한 겨울에 거리에서 메시지를 보내는 경우처럼 분명히 음성 인터페이스가 용이할 수 있는 상황에서도 우리가 공공장소에서 음성 인터페이스를 자주 활용하지 않는 이유 중 하나는 '소리 내어 주목을 끌지 않고 싶기 때문'으로 볼 수 있다.결과적으로는 운전 중 수동 조작이 어렵다는 환경의 특성과 더불어 발화 내용이 외부에 노출되지 않는 매우 개인적인 공간이라는 특성 덕분에 광고를 넘어 실제로도 음성 인터페이스가 가장 활발하게 활용되는 사용자 시나리오 중 하나로 꼽히고 있으며, 차 내에서의 킬러 앱인 내비게이션의 음성 인터페이스 연동 여부가 가장 중요한 포인트라 할 수 있다.개인적으로는 내비게이션 VUI 서비스 중 SKT의 T-MAPxNUGU가 사용자 환경과 시나리오를 바탕으로 세계에서도 상당히 높은 수준의 서비스를 구현해낸 서비스라 생각된다(무엇보다 GUI와 VUI의 적절한 배합이 인상적이다).모든 서비스가 모든 환경에서 최적의 경험을 제공할 수는 없다. 공용 공간에서 메신저/캘린더 등의 개인 정보와 연동된 개인적인 경험을 누리기는 어렵고, 시각 디스플레이가 없는 상황에서 맛집이나 옷을 검색하고 구매하는 경험을 누리기는 어렵다.  아침 기상 후에 필요로 되는 서비스와 운전 시에 필요로 되는 서비스, 취침 전에 필요로 되는 서비스는 각기 다르며 VUI 디자인을 시작하기 위해서는 각 TPO에 맞는 기획이 필요하다.  결과적으로 사용자가 AI의 어떤 '성격'을 원할지 (친근한 친구 같은 AI vs 딱딱한 비서 같은 AI)는 TPO에 따라 상이할 수 있으며, TPO 설정 시 사용자와 서비스에 대한 페르소나 설정이 동시에 진행 되어야만 한다.3편: 음성 기반 인터페이스와 페르소나에서 계속.#히든트랙 #음성기반기술 #음성기반UX/UI디자인 #스타트업인사이트 #경험공유

어플리케이션 성능 분야에서 평균 응답 시간은 어플리케이션 서버가 사용자에게 요청 결과를 반환하는 데 걸리는 시간을 말합니다. 어플리케이션 서버의 응답시간은 일반적으로 밀리세컨드에 가깝지만 부하량에 따라 많은 시간이 걸리기도 합니다. 고객이 기다리는 시간 3초인터넷 초창기인 1999년 전자 상거래 사이트의 최적로드 시간은 8초 였습니다. 2006년도에 들어서는 4초까지 줄어들었습니다. 그리고 지금은 3초를 고객을 떠나게 만드는 시간으로 이야기 합니다. 구글 이 운영하는 더블클릭(https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/)은 모바일 페이지가 로드되는데 3초가 지나면 사용자의 절반 이상이 서비스를 포기한다고 조사결과를 발표했습니다. 3초라는 시간 속에는 웹페이지의 렌더링 시간과 네트웍이 사용하는 시간등이 포함되어 있기 때문에 웹 어플리케이션이 소모해야 하는 시간은 실제로 밀리세컨드에 가깝습니다. 하지만 실제 서비스의 장애가 발생하면서 웹 어플리케이션의 평균 응답시간은 점점 길어지게 됩니다. 성능분석에서 평균 응답시간부하가 늘어나면서 임계치가 넘어가면 초당 처리량은 더이상 증가하지 않게 됩니다. 논리적으로 생각 해보면 초당 처리량이 더이상 증가하지 않은 상태에서 사용자만 늘어나면 TPS와 인지시간이 상수처럼 동작하므로 응답시간이 사용자에 비례하여 늘어나게 됩니다. [응답시간(Respons Time) = [동시사용자수 / 초당 요청수(TPS)] - 인지시간(Think Time)하지만 일반적인 상황에서 응답시간은 밀리세컨드 단위의 값이데 비해 인지시간은 3초에서 10초 이상의 값을 가지고 됩니다. 그럼 이번에는 성능을 분석하는 스토리를 만들어 보겠습니다. 우리가 영어 문장을 한글로 번역하는 웹 서비스를 만든다고 해 보겠습니다. 우리는 동시 사용자 100명을 예상하고 서비스를 만들고 있습니다. 여기서 서비스 특성상 사용자가 한번 번역을 요청하고 다음번 요청을 보내는데 평균 30초의 시간이 걸립니다. 마지막으로 최대 응답시간은 0.5초를 넘지 않도록 설계하려고 합니다. 이런 경우 우리가 목표로 하는 초당 요청수는 서비스를 동시에 사용하는 사람들의 요청을 시간으로 나누므로 계산식은 동시사용자수(100명)/(응답시간(0.5초) + 인지시간(30초)) 이고 결과값은 약 3.27이 됩니다.     초당 요청수(TPS) = 동시사용자수 / [응답시간(Respons Time) + 인지시간(Think Time)]이렇게 성능을 계산하는 과정에서 서비스의 처리시간 즉 응답시간은 인지시간에 비해 매우 적기 때문에 인지시간이 커지면 커질수록 TPS에 관여하는 비율이 0에 수렴하게 됩니다. 결론적으로 성능을 설계하는 시점에서 응답시간은 별로 중요한 이슈가 아니게 됩니다. 대신 인지시간이 중요해 집니다.인지시간(Think Time)이란?웹 서비스를 사용하는 사용자는 자신의 요청을 확인하는 시간이 필요합니다. 이렇게 이전 요청과 다음 요청 사이의 시간을 인지 시간이라고 합니다. 인지 시간은 사용자나 서비스 유형에 따라 다릅니다. 예를 들어 시스템 간 상호 작용은 사람이 관여하는 웹 서비스 상호작용에 비해 매우 낮은 인지 시간을 포함합니다. 또는 블로그 서비스에 비해 사전검색 서비스의 인지시간은 매우 짧을 것입니다. 서비스의 도메인을 분석하여 인지 시간을 결정하는 것은 매우 중요합니다. 인지시간을 사용하여 분당 완료해야 하는 요청 수는 물론 시스템에서 지원할 수 있는 동시 사용자 수를 계산할 수 있습니다. 튜닝 지표로서의 평균 응답시간현실에서 웹 서비스의 응답시간은 수식과 다르게 나타나게 됩니다. 그래서 많은 성능 분석 도구가 평균 응답시간을 보여주고 있습니다. 실제 성능 분석 도구들이 알려 주는 평균 응답시간은 수집 주기 동안에 수집된 트랜잭션의 응답 시간을 합산하여 평균한 값입니다.와탭의 서비스는 5초 간격으로 트랜잭션의 평균 응답시간을 계산합니다. 응답시간이 성능 지표보다 튜닝지표로서의 의미를 가집니다. 예를 들어 사용자가 적은 밤 시간에 배치잡과 같은 일부 응답시간이 길어짐으로써 사용자가 많은 낮보다 평균 응답시간이 더 길수도 있습니다. 하지만 실제 성능을 올리기 지표로써 응답시간은 매우 직접적입니다. TPS와 상관없이 평균 응답시간이 길어지는 요소가 있다면 주변 요소와 함께 평균 응답시간을 살펴봐야 합니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

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

 이 포스트는 제가 개발팀에게 했던 세미나를 정리한 것입니다. 개발자와 기획자, 개발자와 디자이너 사이에 의사소통에 대해서 얘기하는 글이 너무나 많습니다. 디자이너(기획자)가 개발자와 일하기 위해 알아야하는 최소한의 개발 용어, 기획자와 개발자가 절대 하지 말아야 할 말들 등등 재밌는 포스트들이 인터넷에 떠돌고 여러 담당자들의 공감과 비판을 사고 있지요. 언제 이야기해도 농담을 주고 받으며 할 수 있는 좋은 주제인 것 같습니다. 그러나 그런 글들은 해당 개발자 또는 기획자가 쓴 글이기 때문에 바이어스가 걸리기 마련이지요. 우스갯소리로 넘기기에는 껄끄럽고 진지하게 받아들이기에도 껄끄럽죠. 왜 이런 말들이 이렇게 많이 나올까요? 왜냐하면 실제로 그들이 대화하는 방식이 너무나 다르고 서로가 하는 일을 이해하기 힘들기 때문입니다. 서로간에 말이 정말 잘 통했다면 그럴 일이 없겠지요. 심지어 화성에서 온 개발자 금성에서 온 기획자라는 말이 한 때 많이 나돌아 다녔지요.UI/UX도 모르면서...결국 게시판 만들라는 거잖아요이런걸 기획서라고 써오다니...아니 그걸 다 된다고 하면 어떡해요이거 하나 바꾸는게 그렇게 어려운가요?언제까지 가능한지만 얘기해주세요여기서는 되는데 우리는 왜 안되나요?개발 공부 할거에요! 공감 하시나요? 저는 개발자이지만 한번 기획자의 입장에서 왜 그렇게 할 수 밖에 없었는지 핑계를 대보겠습니다. 도대체 기획자는 저딴 방구인지 말인지 모를 말들을 할까요? 와이컴비네이터의 폴 그래햄의 유명한 에세에인 Do things that don’t scale의 한국어 요약본입니다. 영어가 싫고 1분1초가 아까운 여러분을 위해서 준비했습니다 :) 읽어보시면 스타트업에서 처음부터 규모가 큰 작업을 하거나 그것을 자동화하는 일이 얼마나 위험한 일인지 간접적으로 느끼실 수 있을것 같아요. 그 중에 일부만 발췌하여 말씀드리면1. 모집 : 사람들은 많은 선택권을 가지고 있기 때문에 우리 제품을 써야할 필요가 없음그들을 선택하려면 빠른 프로토타입이 필요하고 요구사항에 맞춰 변화할 필요가 있음2. 황홀감 : 모든 유저들에게 황홀한 수준의 경험을 제공해야하는데 엔지니어 교육과정중에 유저 만족에 기울어야한다는 내용이 없어서 생각하기 힘듬3. Meraki : 하드웨어 벤처의 경우 수동으로 기계를 생산/조립하면서 기존에는 알지못했던 핵심 요인들을 발견할 수 있음4. 수동 : 초기에는 소프트웨어가 할일을 사람이 직접하는게 좋을 수도 있음.수동으로 해결하다가 해결책을 자동화하는 것은 확실한 고객을 확보할 수 있지만, 처음부터 자동화된 해결책으로 아무런 문제도 해결하지 못한다면 확실한 실패로 이어짐5. 대형 : 처음부터 큰 스케일로 일을 벌인다고해서 성공으로 이어지는 건 아님. 수동을 싫어하기 때문에 크게 일을 벌리는 것은 큰 실패로 이어짐.큰 버그가 아니고 시장 진입 타이밍이 중요하다면 바로 출시할 수도 있다 이 중에서도 저는 4번의 수동이라는 덕목을 가장 중요하게 생각합니다. 개발자라는 족속들이 수동을 굉장히 싫어하는 경우가 많습니다. 수동은 쿨하지 않거든요. 그래서 모든 것을 자동화시키려고 하죠. 자동은 쿨하니까요. 어떤 포털사이트의 랜딩 페이지를 개발해야하는 프로젝트가 생겼다고 예를 들어봅시다. 개발자는 생각합니다.매일매일 갱신되는 랜딩페이지를 만들자. 좋아요와 댓글이 많은 글들을 최신순으로 정렬하여 보여주는데 매일 자정에 랜딩 페이지가 새로운 내용으로 갱신되는게 좋겠다. 이미 한번 게시되었던 글은 다시는 게시되지 않도록 구성해야겠군. 좋아요와 댓글의 가중치는 1:2 정도가 좋겠지? 이렇게 랜딩 페이지를 하나 구성하는데 엄청난 노력과 시간을 투자합니다. 기획자 또는 마케터는 왜 이렇게 일이 오래걸리는지 답답해하죠. 빨리 출시해서 고객들의 반응을 보고 싶은데 개발이 늦어지니까요. 사실 고객들은 포털 사이트의 메인 컨텐츠가 자동으로 구성되던 수동으로 구성되던 관심이 없어요. 그건 기획자 또한 마찬가지지요. 그들에게 어떤 컨텐츠를 보여줘야 좋아할까 고민하지요. 심지어 그전에 랜딩 페이지라는 기능이 유효한지 증명되지도 않았지요. 실제로 이전에 제가 만들었던 시크릿차트라는 서비스에서 병원의 랭킹을 계산하여 유저들에게 보여주는 기능을 만들 때도 비슷한 일이 있었습니다. 병원 랭킹 기능이란 각 병원이 언급된 블로그와 카페 글을 스크레이핑하여 몇 개인지 세고 데이터베이스를 쌓고 블로그와 카페 글이 많은 순서대로 정렬하여 보여주는 기능입니다. 처음에 저도 욕심이 생기는 겁니다. 검색 포털의 API를 이용하여 스크레이핑 봇을 만들고 데이터베이스를 구축해주는 프로그램을 만들고 싶었습니다. 그 프로그램을 만드는데는 테스팅까지 약 1주일이라는 시간이 꼬박 들겠지요. 그래도 굉장히 쿨하고 재밌어 보였습니다. 그러나 그 욕망을 꾹 참고 수동으로 세서 데이터베이스를 구축하기로 결심합니다. 검색 포털에서 검색하여 나온 숫자를 눈으로 직접 보고 데이터베이스에 직접 접근하여 수동으로 입력하는 방식입니다. 저는 기획자와 다른 개발자에게도 입력하는 것을 도와달라고 협조를 요청했습니다. 그렇게 2일만에 우리는 데이터베이스를 구축했고 빠르게 배포하여 고객의 반응을 살폈습니다. 고객의 반응을 살펴보던 기획자들은 그 기능이 정말 잘 작동하고 고객들이 좋아한다는 것을 증명해냈고 저는 그제서야 API를 이용하여 모든 것을 자동화했지요. 우리는 자동화의 욕심을 버려야합니다. 물론 시간과 비용, 효율을 따져서 해야겠지요. 효율을 따지는 것은 여러분이 더욱 능숙하실거라고 생각합니다. 우선은 간단한 예로 비개발자들이 왜 요상한 말과 행동을 하는지 알아보았습니다. 그러면 개발자인 우리는 그들에게 어떻게 이야기해야할까요? 어떻게 해야 싸우지 않고 일할 수 있을까요? 애자일 개발방법론 중에 하나인 익스트림 프로그래밍에서도 이야기하듯이 지식 섬 현상(Islands of Knowledge)은 굉장히 위험한 요소입니다. 서로가 이해하는 것이 다르기때문에 계속적인 커뮤니케이션을 통해 지식 섬을 없애야합니다. 저는 그 지식섬을 없애기 위한 실질적인 방법을 소개하려고 해요.조카에게 설명하듯이1. 훈민정음 아시겠지만 개발 용어는 절대 금지입니다. 정말로 필요한 경우가 아니면 절대 개발 용어를 쓰지마세요.2. ABC 제목만 보면 훈민정음 룰과 반대되는 내용인 것 같죠? 예를 들어서 설명할게요. 태그 기능을 만든다고 합시다. 그런데 거기서 기획서에 나오지 않은 허점을 우리는 발견했습니다. 손가락을 이리저리써가며 태그가 여러개가 되었을 때 꼬이는 현상을 설명하려 하지마세요. 태그A, 태그B, 태그C 이렇게 설명하세요, 또는 "가나다"도 좋겠군요.3. 연필 & 종이 미팅을 할때 무조건 연필과 종이를 챙겨가세요. 그리고 말보다는 그림을 그려가며 설명하세요. 종이를 아끼지 말고 최대한 자세하게요. 또는 미리 정리한 문서를 준비해가세요. 문서를 보면서 설명하면 빼먹지않고 더 잘 설명할 수 있지요.4. 메타포를 사용하라 익스트림 프로그래밍에도 나오듯이 시스템 전체 또는 기능 전체를 하나의 메타포로 정의하여 설명하는 방법입니다. 현재 제가 만들고있는 IoT 관제 솔루션의 뒷면에는 기획자 또는 디자이너가 절대 이해하지 못할 프로토콜이라고 불리는 부분이 있습니다. 우리는 프로토콜을 어떻게 개발자가 아닌 사람에게 설명해야 할까요? 저는 커피머신을 메타포로 사용하여 설명하겠습니다. 우리는 제품으로부터 raw data라는 가공되지 않은 커피빈을 받습니다. 그냥 겉으로만 보면 어떤 유용한 데이터를 가지고 있는지 전혀 모르죠. 커피빈을 볶고 갈아서 사람이 마실만한 에스프레소를 만듭니다. 거기에 우유, 크림, 초콜릿 등을 더해서 다른 사용자가 좋아할 만한 또다른 커피도 만들 수 있겠죠. 데이터베이스를 모르는 사람들이 보는 깔끔한 그래프가 나오는 화면은 아메리카노, 라떼 등으로 비유할 수 있겠군요. 정말 조카에게 설명하듯이 쉽게 친절하게 설명하시면 됩니다. 그럼 다음으로 여기서 한발짝 더 나아가서 심화학습을 해보죠. 우리는 개발자로서 비개발자인 그들에게 어떻게 해주면 더 좋을까요?1. 기획의도를 이해하기 왜 이렇게 기획했는지 이해하면 좋습니다. 유저의 요구사항이 무엇이고 왜 그런 요구를 했는지 Back-log를 알면 개발이 더 쉬울 뿐만 아니라 빠르게 배포할 수 있을지도 모릅니다. 예를 들어 배포 30분전에 버그가 발견되었습니다. 개발자는 "헉, 버그다."이러면서 열심히 고치겠지요. 그러면서 기획자에게 배포를 내일해도 되냐고 물어봅니다. 기획자는 안된다고 하고 또 싸우겠죠. 만약 기획의도를 이해한다면 이 싸움이 필요하지 않을지도 모릅니다. 해당 기능을 작동시키는데 있어서 크리티컬한 것이 아니면 서비스를 우선 배포하고 이 후에 고쳐도 되겠지요. 또는, 마케팅이나 시장은 타이밍이 중요하기 때문에 기능 구현의 우선순위를 기획자가 잡아줄 수도 있습니다.2. 프로토타입을 빠르게 개발자는 코드로 이야기합니다. 그러나 비개발자는 이해 못합니다. 움직이는 프로토타입은 고객뿐만 아니라 동료의 이해도를 드라마틱하게 높일 수 있지요.3. 계속해서 점검받기 점검받는다고 그들의 아래에 있는 것이 아닙니다. 우리는 프로젝트를 완수하기 위해 각자 다른 역할을 수행하고 있는 동등한 존재임을 잊지맙시다. 개발자는 비개발자에게 계속해서 움직이는 프로토타입을 보여주고 피드백 받으면서 지식의 섬을 없애나가야 합니다. 고객들이 원하는대로, 기획자들이 기획한대로, 디자이너 디자인한대로 구현하는 것이 프로젝트에서는 무엇보다도 중요하니까요.4. 데드라인은 꼭 지키기 데드라인을 지키는 것은 개발자와 비개발자간에 신뢰관계를 높이는 방법 중에 개발자가 할 수 있는 가장 효과적인 방법입니다. 또한 고객과도 마찬가지죠. 약속을 지키지 못하는 회사의 제품을 사가는 사람은 없습니다.  우리는 서로에 대해 너무 조금만을 알고 있습니다. 그래서 서로의 입장을 모르고 문제가 생기기 마련이지요. 당연히 서로에 대해 자세히 알 필요는 없지요. 우리팀에서 프로젝트를 망치고 싶어하는 사람은 없습니다. 그러나 상황이, 그리고 오해가 프로젝트를 망치게 하지요. 그리고 누구나 똥을 쌉니다. 서로 부족한 점이 있으니 부족한 점을 욕하기보다는 부족한 부분을 채우기위해 영역을 넓혀가는 건 어떨까요? 저건 내 일이 아니니 알아서 되겠지라는 태도보다는 다 같이 고민하며 빈 공간을 채우는 편이 좋다고 생각합니다. 서로를 비난하면서 프로젝트를 할 것인가, 서로를 이해하는 마음가짐으로 즐겁게 프로젝트를 할 것인가... 선택은 당신의 손에 달렸지요.#비주얼캠프 #인사이트 #경험공유 #조언 #개발자 #개발팀 #협업 #팀워크

세상에 나쁜 개발자는 없다. 나쁜 개발 습관만 있을 뿐나쁜 개발자란 누구를 지칭하는 것일까? 코드가 별로인 개발자? 커뮤니케이션이 안되는 개발자? 나쁜 개발자로 지칭될 수 있는 사람들은 굉장히 많다. 하지만, 세상에는 나쁜 개발자는 없다고 생각한다. 단지, 나쁜 개발 습관만 존재할 뿐. 즉, 누구든지 나쁜 습관을 버리고 좋은 습관을 갖는다면 언제든지 좋은 개발자가 될 수 있다는 것이다. 좋은 개발자, 나쁜 개발자. 이것은 칭호가 아니라 속성일 뿐이다. 언제든지 바뀔 수 있는 속성 말이다.이것이 속성인 이유는 누구든지 좋은 개발자와 나쁜 개발자의 속성들을 가지고 있기 때문이다. 단지 그 속성의 비율의 차이가 그 사람이 어떤 개발자인지 결정할 뿐이다. 흔히, 좋은 개발자라고 불리는 사람도 나쁜 개발 습관이 있을 수 있다. 또, 나쁜 개발자라고 욕을 먹는 사람도 좋은 개발 습관이 있을 수 있다.우리는 이 글에서 나쁜 개발 습관(혹은 속성)들을 알아보고 왜 그것이 나쁜지 그리고 그것을 어떻게 피하는지에 대해 이야기할 것이다. 좋은 습관이 아니라 나쁜 습관들을 이야기하는 이유가 있다. 좋은 습관은 습득하기 어렵다. 하지만, 나쁜 습관을 버리는 것은 더더욱 어렵다. 나쁜 습관을 피하는 것이 때로는 좋은 개발자가 되기 위한 요건일 수도 있다. 아래의 습관들을 보면서 자신을 진단해 보자.(아래의 습관들 중 습관인 것들도 있고 단순히 사고방식이나 경향인 것들이 있다. 여기서 습관은 사고방식이나 행동의 양식 등 총체적인 행동 방식 등을 의미한다.)습관 1: 코드 리뷰가 없다.지난번에 같이 해보니까 험악만 말만 나오고, 분위기만 안 좋아졌다. 후배들에게 코드 지적받는 것도 자존심 상하고... 그리고 대부분 시니어들이 지적하고 주니어들은 고개만 끄덕이는 자리 아닌가? 코드 리뷰 할 시간에 코드 한 줄이라도 더 짜서 프로젝트 마감일이나 지키는 게 낫지. 솔직히, 프로라면 자기 코드는 자기가 책임져야 하는 거 아닌가?습관 2: 문서화를 하지 않는다.아니 개발할 시간도 부족한데 무슨 문서화인가. 개발자가 개발하는 사람이지 문서 만드는 사람인가? 인수인계받을 사람 오면 직접 알려주면서 일주일이면 끝날 텐데 말이다. 그리고 이때까지 만든 문서들 만들고 나서 본적이나 있나? 그냥 보여주기식 파일이지 뭐.습관 3: 커뮤니케이션 향상에 관심이 없다.지금도 말 잘하고 대화 잘 통하는데 더 향상시킬게 있나? 그리고 개발자의 핵심은 커뮤니케이션이 아니라 코딩인데 말이야. 컴퓨터랑만 잘 소통하면 되지. 어차피 다른 부서에 있는 사람들은 개발 기술에 대해서 잘 알지도 못하고... 커뮤니케이션 스킬은 그런 사람들이 향상시켜야 한다고 생각한다.습관 4: 업무 공유가 되지 않는다. 자신의 일에 대해 알고 있는 사람이 없다. 데드라인 잘 지키고, 주어진 일을 잘 해내면 된다고 생각한다. 보고를 하기 전까지 굳이 보고하지 않고, 동료나 후배들과 업무 공유를 잘 하지 않는다. 어차피 내가 하는 일에 별로 관심도 없는데 공유해봤자 무슨 소용인가?습관 5: 코드의 복붙(복사 후 붙여넣기)가 '일상화'되어 있다.직접 만드는 것보다 이미 만들어진 코드들을 찾아서 Ctrl +c,v하는게 더 빠르고 생산성 있다고 생각한다. 동료 개발자랑 공통 모듈을 만들어 사용할 수 있겠지만 그렇게 하기에는 너무 많은 리소스가 낭비된다고 생각한다. 잘 돌아가기만 하면 되지 않나?습관 6: 자신의 부족한 점을 드러내지 않는다.부족한 점에 대해 동료들과 터놓고 얘기하지 않는다. 괜히 부끄럽고 껄끄럽기도 하고 자신의 부족한 점이 드러나는 것이 두렵다. 동료들이 조언을 해주려고 해도 방어적으로 나오거나 피한다. 동료의 진솔한 피드백이 없으니 한 번 단점을 만들면 끝까지 내 것으로 가져간다.습관 7: 새로운 기술을 익히는데 시간을 투자하지 않는다.세상은 정말 빠르게 변하고 있다. 그리고 그 변화의 중심은 기술이고 기술 중에서도 IT 기술이 정점에 있다고 봐도 무방하다. 새로운 기술은 새로운 기술자들이 익히는 것이라 생각한다. 지금 하고 있는 일만으로도 벅차다. 그리고 지금 쓰는 기술이 시대의 주류인데 쉽게 바뀔까?습관 8: 자신의 개발 환경에서 벗어나지 않는다.개발자 모임이나 개발 커뮤니티에 시간을 쓰는 것은 낭비라고 생각한다. 개발에 대해 새로운 시도를 하지 않는다. 새로운 프레임워크나 협업 툴들이 나와도 기존의 환경을 고집한다. 왜냐하면 지금 개발 환경이 너무 편하고 익숙하니까.습관 9: 자신이 맡은 개발과 관련된 비즈니스를 이해하지 않는다.개발자는 개발에만 신경 쓰면 된다고 생각한다. 지금 개발하고 있는 서비스의 비즈니스적 관점은 생각해 본 적 없다. 어차피 기획자나 마케터, 프로덕트 매니저가 신경 써야 할 일이라고 생각한다. 개발만으로도 바쁜데 그것까지 신경 쓰면 정말 골치 아파진다.습관 10: 개발에 대한 지신만의 장기적인 목표가 없다.어떤 개발자가 되어야 하는지에 대한 목표가 없다. 주어진 프로젝트 외에 자신이 하고 싶은 프로젝트를 하면서 개발을 발전시키지 않는다. 그냥 개발의 메인 스트림을 따라만 간다. 커리어나 다른 생활에 대한 걱정은 종종 하지만, 개발 자체에 대한 고민은 하지 않는다.습관 11: 자신의 나쁜 개발 습관에 관심이 없다.(습관은 아니지만....)내가 나쁜 개발자라고...? 내가 하고 있는 것들이 나쁜 습관들이라고??? 글쎄..... 그냥저냥 잘 하고 있는 거 같은데.... 라고 생각하는 당신! 아무리 좋은 개발자라도 나쁜 습관은 존재하기 마련이다. 좋은 개발자는 좋은 습관들을 가지고 있는 개발자기도 하지만, 나쁜 습관들이 많지 않은 개발자이기도 하다.나쁜 환경은 나쁜 개발자를 만든다.당신이 만약 스스로를 나쁜 개발자라고 생각한다면 아마 '나쁜' 환경에서 개발을 했을 가능성이 크다. 혹은 선배가 나쁜 개발자여서 그 습관을 그대로 보고 배웠다든지, 아니면 좋은 개발자에 대한 고민 없이 흘러가듯 개발을 배웠을 것이다. 예를 들어, 코드 리뷰를 하지 않았던 것은 회사에서 코드 리뷰를 안 했을 가능성이 크다. 혹은 문서화를 안 하는 경우, 그 회사에서 그것에 대해 크게 신경 쓰기 있지 않을 가능성이 크다.Bad developers are not born, but created.위에서도 언급했듯이 나쁜 개발자는 없다. 나쁜 습관들이 있을 뿐. 당신이 지금 위의 습관에서 많은 부분들이 해당된다 하더라도, 그 습관들을 바꾸면 된다. 다른 개발자들에게 있는 좋은 습관들을 보고 배우면서 자신에게 해당되는 나쁜 습관들을 하나씩 바꿔나가는 것이다.환경이 바뀐다고 자신이 바뀌지는 않겠지만, 나쁜 환경이 나쁜 개발자를 만드는 것처럼, 좋은 환경은 좋은 개발자를 만든다. 좋은 환경을 찾아가라! 직장이 그걸 주지 못한다면 다른 곳에서라도 찾아라. 좋은 개발자는 나쁜 습관들을 하나씩 바꿔나갈 때 될 수 있을 것이다. 다음 포스팅에서는 좋은 개발자가 되기 위해 필요한 정보들을 압축적으로 모아 포스팅할 것이다.

지난 2018년 3월, 고용노동부는 10월부터 발효되는 '감정노동자 보호법 개정안'을 통과시켰다. 해당 개정안은 고객의 폭언이나 폭력으로부터 스트레스를 받는 감정노동자의 인권과 업무의 질을 개선시킬 사업주 조치를 의무화하는 내용을 담고 있다. 감정노동이란, 고객을 응대하며 자신의 본래 감정과는 상관없이, 업무상 정해진 감정 표현을 연기하는 것을 일상적으로 수행하는 노동을 말한다. 예로 콜센터, 백화점 안내, 텔레마케터 등이 있다.< 감정노동자 보호를 위한 5개 금융업법 개정안 주요 내용, 출처: 동아닷컴 >이제 정부는 감정노동자의 '적응 장애'와 '우울증' 등을 업무상 질병으로 인정한다. 세계보건기구(WHO)에서 정의한 건강은 '육체적, 정신적, 사회적, 영적으로 안녕한 상태'다. 즉, 감정노동자들은 육체뿐만 아니라 정신적, 사회적으로 고통받을 수 있다는 것이다. 그들은 자동으로 저장된 말을 내뱉는 음성 안내기가 아니고, 일반 사람들처럼 똑같이 울고 웃는 사람이다. 그렇지만, 아직까지 국내에서 심리상담에 대한 정서적인 장벽은 높고, 상담 받을 수 있는 인프라도 잘 갖춰지지 않다. 감정노동자들이 실질적인 상담 도움을 받기는 어렵다는 의미다.감정노동 소식 뒤, 국내 인공지능 기술 업체 중 한 곳이 심리상담 서비스를 출시했다는 기사를 접했다. 전문 심리 상담사들이 축적한 수많은 상담 시나리오 데이터를 수집하고 구축해, 개별적이고 정확한 서비스를 제공한다는 것이 취지다. 또한, 통화 목소리를 기반으로 이를 감정 데이터로 변환시켜 정신 건강에 대한 정보와 스트레스 관리 등을 위한 맞춤형 콘텐츠를 제공하는 것이 목적이다. 정확도는 알 수 없지만, 인공지능이 인간의 감정을 인지하고 생활에 도움을 줄 수 있다는 사실만으로도 큰 의미가 있다고 생각한다.사실 필자는 몇 년 전까지 매 순간 변하는 복잡한 인간의 감정은, 인간 고유의 것이라고 생각했다. 인간은 자신의 감정을 알지 못할 때도 있고, 긍정적인 감정과 부정적인 감정을 주체하지 못하기도 한다. 아직 우리 스스로 감정에 대해 확실하게 정의할 수 없고, 통제할 수 없다. 하지만, 그럼에도 불구하고, (앞서 언급한) 심리상담 서비스처럼 여러 분야에서 기계가 인간의 감정을 이해하고, 심지어 감정 표현을 돕는 연구는 거듭되고 있다.기계와 감정의 접목은 2000년대 이전부터 시작되었다. 1995년 MIT의 피카드(Rosalind Picard) 박사가 처음으로 감성컴퓨팅이라는 용어를 사용하며, 인간의 감성을 분석하고 해석하는 기술 개발을 시작했다. 감성 컴퓨팅은 인간이 느끼는 바를 인지, 해석, 처리할 수 있는 시스템을 설계하기 위한 인공지능 기술을 연구하고 개발하는 분야다. 감정 인식은 상상 이상으로 복잡하고, 아직까지 정확하게 구현하기 힘든 어려운 기술이지만, 조금씩 그 영역을 확장하며 다양한 분야에서 사용되고 있다.아무래도 사람의 감정을 드러내는 표면적인 수단 중 가장 눈에 띄는 것이 표정일 것이다. 얼굴에 드러나는 인간의 감정은 안면 근육의 움직임을 통해 여러 표정으로 나타나기 때문이다. 여기에 영상 처리 기술을 활용하면, 기계가 인간의 감정을 분류할 수 있다. 이를 기반으로 한 감정인식은 다음의 과정으로 이루어진다.먼저 영상이나 이미지 안에서 얼굴 영역을 찾는다. 일반적으로 스마트폰 카메라 앱에서 많이 볼 수 있듯, 네모 박스 형태로 얼굴을 인식한다. 그리고 해당 박스 안에서 눈, 코, 입 등 랜드마크라고 불리는 특징점들을 찾는다. 이어서 각 특징점을 바탕으로 각각의 위치나 배치를 파악하는 프로세스를 거친다. 마지막으로 학습을 거쳐 사람의 표정을 인식할 수 있다.일반적으로 감정 쪽을 연구하고 기술을 개발하는 업체 대다수는 이러한 딥러닝 방식을 적용한다. 그리고 미리 지정한 각각의 감정 메트릭에 사용자의 표정을 맵핑하는 식으로 결과값을 도출한다. 하나 주의해야 할 점은 표정과 비교하는 감정이라는 결과값을 '확률(%)'로 산출한다. 예를 들어, 눈썹을 찌푸리고 눈이 커지면서 입을 벌리고 있으면, 감정은 '화남 95%, 놀람 20%, 슬픔 5%...' 등으로 표현하는 방식이다.< EMOTION>이외에도 톤, 크기, 템포 등 감정 변화에 따라 변하는 목소리를 분석하는 음성 인식 기술이나 몸의 특정 움직임을 분석해 감정 상태를 인지하는 동작 인식 기술 등이 있다. 특히, 음성 인식은 CS(고객 응대) 영역에서 빛을 발할 수 있다. 실시간으로 고객의 감정을 분석해 소통방식을 바꾸거나, 그들의 구매 패턴을 예측하는 데 도움을 준다.최근에는 페퍼를 비롯한 가정용 휴머노이드 로봇이 여럿 출시되면서, 감정인식 기술의 적용사례를 쉽게 찾아볼 수 있다. 이들 로봇들은 인간과 대화할 때 억양이나 표정을 인식하며, 심지어 때로는 인간의 감정을 예측하고 묻기도 한다. 물론, 아직까지 우리의 머리 속에는 기계라는 생각 때문에 상호간 자연스러운 대화나 감정을 전달하기 어렵다. 하지만 문자, 음성, 시각 등 현재도 여러 영역에서 인공지능 기술은 발전을 거듭하고 있다.< 핸슨로보틱스(hansonrobotics)의 휴머노이드 로봇 소피아(Sopjia), 출처: 핸슨로보틱스 >인간의 감정이라는 것은 하나의 영적인 매개체가 아닌, 복합적인 것이다. 결국 각 영역별 인공지능 기술이 고도화될수록 감정 인식에 적용할 수 있는 기술 또한 정교해진다는 것을 의미한다. 언젠가는 기계가 인간의 말상대가 되어주고, 함께 어려운 문제에 대해 의논할 수 있는 단계까지 이르지 않을까? 감정 노동자의 마음을 어르고 달래는 로봇이 등장할지도 모를 일이다.이호진, 스켈터랩스 마케팅 매니저조원규 전 구글코리아 R&D총괄 사장을 주축으로 구글, 삼성, 카이스트 AI 랩 출신들로 구성된 인공지능 기술 기업 스켈터랩스에서 마케팅을 담당하고 있다#스켈터랩스 #기업문화 #인사이트 #경험공유 #조직문화 #인공지능기업 #기술기업

IT 서비스는 더욱 복잡해지고 어플리케이션과 인프라의 경계도 클라우드 환경과 함께 허물어지고 있습니다. 많은 기업들이 가상화를 넘어 컨테이너로 가고 있으며 서버리스도 더이상 낮설지 않습니다. 인프라의 변화와 함께 아키텍처의 변화도 다양하게 만들어져 가고 있습니다. 복잡성이 아무리 높아져도 우리는 서비스의 성능을 보장해야 합니다. 서비스의 성능을 보장하기 위해 우리가 체크해야 할 중요 요소들을 알아보려고 합니다. 1. 인프라스트럭처와 클라우드서비스의 성능은 코드 밖에서도 만들어집니다. 그중에서도 인프라스트럭처는 매우 중요한 요소입니다. 국내에서 인프라스트럭쳐 분야는 클라우드로 전환하는 과도기적인 상황에 있습니다. SMB 시장에서 클라우드는 익숙한 환경이지만 국내 엔터프라이즈 기업의 클라우드 도입 비율은 20%가 되지 않습니다. 특히 클라우드를 도입하려는 엔터프라이즈 기업들은 데이터 센터, 퍼블릭 클라우드, 프라이빗 클라우드를 모두 사용하는 상황으로 넘어가면서 클라우드에 대한 모니터링 체계를 구성하는데 많은 어려움을 겪고 있습니다. 특히 기존의 자원 사용량을 설계하고 운영하던 방식에서 스케일의 변화를 통해 서비스의 성능을 실시간으로 조절하는 클라우드 서비스 운영 방법은 조직의 구조 변화를 동반하기 때문에 더욱 어려운 작업이기도 합니다. 이렇듯 클라우드의 전환은 최근 웹 서비스의 성능에 많은 영향을 미치고 있으며 데이터독이나 뉴렐릭 그리고 와탭 같은 성능 분석 서비스들은 클라우드 기반의 인프라 모니터링 기능들을 강화하고 있습니다. 2. 데이터베이스어플리케이션 성능 이슈의 80% 이상이 데이터베이스 레이어에서 발생합니다. 대부분의 엔터프라이즈 기업들은 자사의 어플리케이션을 성능 분석을 위해 DBA 포지션을 마련하거나 필요에 의해 컨설팅을 받고 있지만 아쉽게도 스타트업은 DBA포지션을 마련하는 경우가 거의 없습니다. 웹 서비스의 규모가 커지기 시작하면 데이터베이스로 인한 지연 장애가 매우 심각해 지기 시작합니다. 레거시로 인한 이슈까지 추가되면 서비스의 성능은 지속적으로 낮아지게 되므로 데이터베이스는 꾸준히 관리해야 하는 요소입니다.데이터베이스의 비중이 높다보니 어플리케이션 분석 서비스 중에서도 데이터베이스만 집중적으로 분석하는 도구들이 있습니다. 국내에서는 엑셈과 티맥스에서 데이터베이스 분석 솔루션을 제공하고 있습니다.  3. 오픈 소스와 써드파티 소프트웨어최근 두가지 형태의 트렌드가 서비스 성능에 영향을 주고 있습니다. 하나는 오픈 소스이고 다른 하나는 써드 파티 소프트웨어 입니다. 안정화 된 오픈 소스를 사용하더라도 설정 이슈 또는 사용 환경 이슈로 성능에 영향을 주는 상황이 많이 발생합니다. 위젯, 광고플랫폼, 플러그인등의 써드파티 또한 웹 서비스의 성능에 영향을 주는 요소입니다. 최근 써드 파티의 사용은 점점 늘어나는 추세로 인해 장애 발생에 대한 위험도는 더욱 높아가고 있습니다. 특히 써드 파티는 시간이 흐르면서 성능에 조금씩 부하를 누적시키기도 하므로 충분히 주의를 기울여야 합니다. 이런 환경에서도 서비스의 성능을 유지하기 위한 방법으로 통계 기반의 메소드 분석 기법 모니터링의 중요한 요소가 되어 가고 있습니다. 와탭의 Java 모니터링이 메소드 분석 서비스를 제공하고 있습니다. 4. 모바일구글 이 운영하는 더블클릭(https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/)에 따르면 북미에서 3G에서의 모바일 페이지 로딩까지 소요되는 시간은 평균 19초입니다. 한국은 이미 4G를 넘어가고 있기도 하고 모바일 기기의 성능도 매우 높아서 북미와 상황이 다르지만 모바일 기반의 웹 서비스 성능을 분석할 수 있는 방안의 필요성은 높아져 가고 있습니다. 이와 함께 다양한 환경을 지원하는 end-to-end 모니터링의 중요성이 점점 대두되고 있는 상황입니다.  5. 컨테이너최근 인프라스트럭처의 새로운 흐름은 컨테이너 입니다. 한국은 리눅스 기반의 서비스 구축 시스템이 잘 발달한 덕분에 클라우드 도입이 다른 나라보다 늦은 편입니다. 하지만 최근 국내에 컨테이너 기반의 인프라스트럭처 도입 기업들이 많아지고 있습니다. 우리나라는 가상화를 건너뛰고 컨테이너부터 활성화 될수도 있을 거라 생각됩니다. 컨테이너 환경은 가상화보다 더 많은 인프라를 더 유동적으로 사용하게 되므로 기존의 규모를 뛰어 넘는 관리 체계를 만들어 나가야 합니다. 데이터독과 뉴렐릭 같은 SaaS 기반의 모니터링 서비스들은 이미 컨테이너의 대한 지원을 하고 있으며 와탭 또한 단순 지원을 넘어 컨테이너 전용 서비스를 준비중에 있습니다. 6. 마이크로 서비스많은 기업들이 클라우드와 함께 Micro Service Arichtecture를 도입하고 있기 때문에 독립적인 어플리케이션을 기반으로 하는 서비스 구조는 계속 발전해 나갈 것입니다. 마이크로 서비스와 클라우드의 조합은 커져가는 서비스의 규모를 독립적인 작은 단위로 나눌 수 있어서 매력적이긴 하지만 과거와 다른 운영 조직과 프로세스를 만들어야 하는 숙제를 만들었습니다. 예를 들면 기존에는 하나의 임계치를 사용하여 서비스의 위험도를 관리했다면 이젠 독립적으로 동작하는 서비스들의 임계치를 각각 어떻게 설정하고 관리할 것인지 고민해야 합니다. 독립된 마이크로 서비스의 성능 이슈가 전체 서비스 성능 이슈로 확대되지 않더라도 작게 발생하는 이슈들을 관리하지 못한다면 지속적으로 발전해야 하는 서비스의 미래도 흔들리게 될 것입니다. 7. 서버사이드 코드정상적인 상황이라면 서버사이드 코드에서 발생되는 지연시간은 찰나에 가깝지만 장애 상황에서의 지연은 서버사이드에서 발생하는 경우가 많습니다. 특히 방어가 되어 있지 않은 코드들은 물리적 요소의 작은 변화에 대처하지 못하고 웹 서비스 전체에 영향을 미치게 됩니다. 스타트업의 경우 개발팀이 운영을 함께 맡고 있는 경우가 많기 때문에 서버사이드의 코드를 직접 분석하곤 합니다. 하지만 서비스의 성능이 느려지는 상황 자체를 파악하지 못하는 경우가 많습니다. 서버 사이드에서 평균 응답시간을 체크하는 경우 10초 평균 응답시간이 0.5초를 넘는 경우는 거의 없습니다. 하지만 0.5초의 평균 응답시간을 같는 서비스라 할지라도 하루 동안 10초이상 걸린 고객의 숫자는 규모에 따라 1,000명이 넘을 수도 있습니다. 서비스에 규모가 있다면 꼭 APM을 사용해야 합니다.8. 네트워크 지연네트워크의 지연으로 인한 고객 불만은 예상외로 많이 발생합니다. 인프라스트럭처 이슈로 볼 수도 있겠지만 서비스를 운영한다면 항상 체크하고 있어야 하는 요소입니다. 해당 이슈를 확인 하려면 웹서비스 모니터링을 사용하시면 됩니다. 웹서비스 모니터링을 통해 네트웍상태를 포함한 서비스의 응답시간을 체크해 볼수 있습니다. 와탭의 경우 내부적으로 웹서비스 모니터링을 개발하여 사용하고 있지만 아직 서비스 하고 있지는 않습니다.  9. 자원 사용률자원 사용률은 최근 새로 떠오르는 이슈입니다. 이전에는 인프라스트럭쳐가 고정값이였기 때문에 자원 사용률이 모자라는 경우 서비스 성능을 포기하고 초과되는 고객의 요청을 앞단에서 버리거나 대기시키는 기법들을 사용해왔습니다. 클라우드 환경에서는 자원 사용량의 임계치가 넘어가면 자동으로 스케일을 조정하는 환경이 마련되면서 성능을 유지하는 것이 가능합니다.  클라우드 환경에서 과부하 상태에 접근하면 자동으로 인프라의 규모가 확장되고 과부하 상태는 정상으로 돌아갑니다. 이렇게 환경이 바뀌면서 자원 사용률의 중요 이슈가 성능에서 비용으로 전환되고 있습니다. 부하에 따른 스케일링 정책을 어떻게 정하는지에 따라서 성능과 비용 모두가 영향을 받기 때문에 Auto Scale에 대한 모니터닝이 관심을 받고 있습니다.  마무리웹 서비스의 성능에 영향을 주는 요소는 정말 많습니다. 와탭랩스 IT 기업의 어플리케이션을 모니터링 하기 때문에 기업의 IT 어플리케이션 성능 문제에 대해 항상 고민하고 있습니다. 해당 내용은 매달 또는 분기별로 트렌드를 반영하여 업데이트하고 할 생각입니다. 많은 분들에게 도움이 되었으면 좋겠습니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

barogo바로고사 내 소 식대한민국#배송 #배달바로고가 함께 달립니다.뼈가 되고 살이 되는외부인사 초청 강연Scalable team with DevOps바로고 복지의 일환으로스타트업 엔지니어 박훈 님을 모시고외부인사 초청 강연이 진행되었습니다.박훈 님의 강연이 시작되었습니다.2018년 1월 31일에 진행된바로고 외부 인사 초청 강연의 생생한 현장을 소개합니다.박훈 님을 모시고 진행된 이번 초청 강연은미니 세미나 형식으로 진행되었습니다.데브옵스(DeOp) 전략을 통해소프트웨어 개발 과정을 좀 더 지속적이고 민첩하게 진행하며개발담당자와 운영담당자가 함께 소통하며협력하는 자리가 되길 기대합니다.뼈가 되고 살이 되는 시간개발자의 고민1. 우리 팀은 사람은 많은데 왜 이렇게 느릴까?2. 왜 사람들은 테스트를 덜 작성할까?3. 왜 API 호환성이 자꾸 고장(incompatubel) 나는 걸까?4. 배포 하나 하기가 왜 이렇게 힘들까?5. 데이터에 기반을 둬 결정을 내리려면 뭐가 더 필요할까?6. 왜 에러는 우리팀보다 사용자가 먼저 찾아낼까?평소 박훈 님께서 개발을 하시며고민하던 부분은 함께 공유하며문제를 해결하고자 다양한 이야기를 나누는 시간이 되었습니다.배고픔을 잊은 그대들의 열정에 박수를 _짝짝짝DevOps를 실제로 사내에서 어떻게 적용하고 있는지열정적으로 발표해주시는 박훈 님경험과 노하우를 공유하며함께 솔루션을 찾아가는 과정이정말 뼈가 되고 살이 되는 시간이 되었습니다.그가 스타트업 정글에서 살아남은 방법(중략)단순히 개발뿐만 아니라지식의 전달, 배포, 문서화 등모든 측면에 있어서scalable 한 팀이 되어야만 한다_!우리의 소통은 계속 됩니다.발표가 끝난 뒤보다 집중적으로 사례를 분석했습니다.DevOps가 잘 정착되면보다 고객에 집중할 수 있다는 점을 강조하였습니다.Solution = System + Culture1. 새로운 것을 좋아하는 사람도 있지만, 싫어하는 사람도 있을 수 있다. 2. 도구가 아니라 풀려는 문제에 집중하자.3. 도구뿐만 아니라 문화(CULTURE)를 가져오자.박훈님_ 수고하셨습니다_!항상 발전하고 진화하는 소프트웨어의 흐름데브옵스를 통해 개발자와 정보 기술 전문가 간의소통과 협업을 통해더 나은 개발 환경, 문화를 만들어가길기대합니다_!바로고 x 본도시락세미나를 마치고 즐거운 점심시간런치앤런의 진짜 시작이라고 할까요?^_*너무나 열띤 토론으로 인해우리는 배가 고팠습니다.런치앤런선정 메뉴를바로고가 배달하는 '본도시락'[바로고 x 본도시락]https://blog.naver.com/barogo_info/2211915027002018년 첫 외부인사 초청 강연박훈님께 감사드립니다.다음에도뼈가 되고 살이 되는알찬 내용으로 찾아가는 런치앤런이 되겠습니다.감사합니다.^___^배송의 가치를 만들어가는바로고barogo-[바로고 공식 홈페이지]https://goo.gl/jKB7LA

이 글에서는 데일리호텔이 왜 png에서 svg로 갈아탔는지, 그리고 간단한 svg 실무 적용 팁에 대해 알려드리고자 합니다.01 SVG란 무엇인가?SVG는 “ Scalable Vector Graphics”의 약자입니다.JPEG, PNG 처럼 SVG도 그래픽 포맷(Graphic format) 중 하나입니다. SVG는 벡터 기반이기 때문에 리사이징이 되어도 전혀 깨지지 않습니다. 모든 해상도에서 자유자재로 활용할 수 있기 때문에 특정 해상도에 제한되어있지 않다는 게 핵심 포인트라고 할 수 있습니다.02 SVG가 왜 좋은가?다른 그래픽 포맷보다 SVG가 좋은 이유는 참으로도 다양합니다. 필자가 생각했을 때의 핵심 장점들은 이러합니다.1. 특정 사이즈에 구애를 받지 않습니다.즉 어느 해상도에서든 pixelate 되지 않습니다. 요새 디자이너들이 자주 사용하는 디자인 프로그램인 스케치로 따지면 아트보드와 비슷한 것 같습니다. 아트보드 안에 만든 레이어, 요소들은 다 벡터 기반입니다. 아트보드를 리사이징 해도 안에 요소들은 깨지지 않고 그 모습 그대로를 가지고 있습니다. 같은 원리로 SVG도 어떤 사이즈로든 그 모습 그대로가 유지됩니다. 그렇기 때문에 사이즈별로 아이콘을 일일이 생성해서 개발자에게 넘겨줄 필요가 없습니다. SVG 파일 하나면 모든 해상도를 대응할 수 있습니다.2. 작은 파일 사이즈비트맵 이미지들(PNG, JPEG) 같은 경우 파일 크기를 결정하는 주요 요소는 바로 ‘해상도’입니다. 예를 들어 5000x5000 픽셀 이미지는 항상 500x500보다 파일 사이즈가 큽니다.반면, SVG 그래픽 같은 경우 파일 크기를 결정하는 주요 요소는 바로 ‘복잡도’입니다. Path가 비교적 적은 간단한 이미지는 PNG, JPEG 보다 파일 사이즈가 적을 수도 있지만 이미지를 구성하는 요소의 복잡도(레이어가 많다든지 특정 효과가 많다든지)에 따라 파일 사이즈가 커집니다.하지만 이런 용량 문제는 SVG Optimizing을 하게 되면 나름 해결됩니다. 필자 같은 경우 업무적으로 스케치를 사용하고 있기 때문에 스케치에서 제공해주는 SVGO Compressor 플러그인을 활용하고 있습니다.https://github.com/BohemianCoding/svgo-compressorBohemianCoding/svgo-compressorsvgo-compressor - A Plugin that compresses SVG assets using SVGO, right when you export them. This Plugin requires Sketch 3.8.github.com 작은 파일 사이즈로 인해 로딩 시간도 훨씬 더 줄어든다는 장점 또한 있습니다.여기서 잠깐!혹시나 Bitmap과 SVG의 구성요소에 대해 잘 모르실 분들을 위하여 간단한 비교 해드리겠습니다.비트맵 그래픽: Raster Graphics (픽셀 기반)대표적인 포맷은 JPEG, PNG입니다. 이들은 픽셀로 구성되어 있습니다. 예를 들어 2x2 픽셀인 비트맵 이미지는 총 4px로 구성되어 있습니다. 개개인에 대한 픽셀들은 자유자재로 바꿀 수가 없고 움직일 수도 없습니다. 그렇기 때문에 100% 이상으로 이미지를 확대하면 Pixelate가 됩니다.SVG 그래픽: 벡터 기반픽셀로 구성되어 있지 않고 작업하고 있는 그래픽에 대한 정보로 구성되어 있습니다. 그렇기 때문에 어떤 사이즈로든 자유자재로 늘어나는 것이 가능합니다. 이러한 이유들로 인해 코드로 쉽게 적용된 스타일을 수정할 수 있습니다. 예를 들어 동그라미의 보더 값을 6에서 8로 바꾼다 / 색상을 그레이에서 블랙으로 바꾼다 / 사이즈를 40x40에서 80x80을 바꾼다 등스케치로 작업할 때도 쉽게 두 개의 차이점을 확인해볼 수 있습니다. 스케치에서 Export를 할 경우 비트맵 이미지는 하나의 압축된 레이어로 Export 됩니다. 반면 SVG는 레이어 그대로 눈에 보이지 않는 그래픽을 구성하는 정보들이 같이 저장된 채 Export가 됩니다.SVG를 구성하는 눈에 보이지 않는 정보들03 스케치가 SVG 이미지를 Export하는 방식다른 그래픽 포맷보다 SVG가 좋은 이유는 참으로도 다양합니다. 제가 생각했을 때의 핵심 장점들은 이러합니다.Sketch Export 기능스케치 하단 오른쪽 패널을 보면 Export 버튼이 있습니다. 여기서 Format을 SVG로 바꾸고 Export하면 금방 쉽게 끝나겠지 라고 생각할 수 있는데 여기서 조심해야 할 점은 본인이 어떻게 이미지를 작업했냐에 따라 옳지 않게 SVG가 내보내질 수 있습니다. 옳지 않게 SVG가 내보내 지게 되면 나중에 두 번 일을 작업하는 일이 발생할 수도 있습니다.쉽게 이해하실 수 있도록 이미지를 제작해 보았습니다. 아래 이미지는 같은 디자인인데 만들어진 방식이 각각 다릅니다.같은 아이콘이지만 구성하는 방식이 다름1. Two Shape2. One Shape3. Border and Shape Mix위 3가지 방법들은 옳고 그름이 없습니다. 다만 어떻게 이 아이콘을 나중에 활용할 것인가에 따라 만드는 방법이 달라지겠죠. 만약에 자동차 아이콘 안에 헤드라이트 색상을 바꾸고 싶다고 하면 위 방법 중 1번을 선택하면 될 것이고 선의 두께를 따로 조정하고 싶다 하면 3번 방식을 택하면 됩니다.SVG에 대해 잘 알지 못할 때는 프로그램 탓을 했었습니다. ‘왜 프로그램이 알아서 잘 못해주지?’라는 질문을 던졌지만… 슬프게도 이건 프로그램 잘못이 아닌 작업자 잘못입니다 �스케치 프로그램이든 아도비 일러스트레이터든 이 프로그램들은 디자이너가 만든 그래픽을 있는 그대로 svg 레이어로 번역하도록 프로그램이 되어 있습니다. 디자이너가 어떻게 작업했냐에 따라 그 정보 그대로 인식해서 svg로 만들어줍니다.04 SVG 아이콘이 제대로 적용 안될 경우다른 그래픽 포맷보다 SVG가 좋은 이유는 참으로도 다양합니다. 필자가 생각했을 때의 핵심 장점들은 이러합니다.헐 이건 도대체 왜….?!!!어느 날 SVG를 적용하기로 마음먹고 데일리호텔 앱 내 편의시설 아이콘 중 수영장 SVG 파일을 개발자에게 넘겼습니다. 근데 구멍이 뚫려야 할 곳이 채워져서 나오는데 원인을 모르고 헤매던 시절이 있었습니다. 미디엄에서 이 문제를 해결해줄 좋은 글을 발견하게 되었는데 난생처음 보는 단어가 2개 있었습니다.Even-Odd, Non-Zero…여기서 Even-Odd, Non-Zero의 차이점을 자세히 언급하기에는 너무 길어서 제가 참고한 미디엄 블로그 링크를 공유해드릴 테니 가서 보시면 이해하실 수 있을 것 같습니다. 작업하기에 앞서 꼭 읽어보시기를 권장합니다.https://medium.com/sketch-app-sources/preparing-and-exporting-svg-icons-in-sketch-1a3d65b239bbPreparing and Exporting SVG Icons in Sketch – Design + Sketch – MediumThis article is going to assume that you already understand the fundamentals of icon design. And focus on how to prepare and export them…medium.com 그래도 가볍게 필요한 내용만 공유드리자면 안드로이드에서는 fill-rule:evenodd를 제대로 지원하지 않고 fill-rule:nonzero만 지원한다고 보시면 됩니다. Even Odd는 특정 앱에서 호환이 안된다는 뜻입니다. (안드로이드 API 24 이상에서만 evenodd가 지원됨)근데 우리가 사용하고 있는 스케치 프로그램에서는 default값이 fill-rule:evenodd로 설정이 되어있고 여러 Path가 겹치는 아이콘 같은 경우 그대로 svg export를 하게 되면 위에서 제가 경험하였던 아이콘이 다 채워진 현상을 겪을 수 있게 되는 것입니다.1. Fills 섹션에서 Even-Odd를 Non-Zero로Fills 섹션에 가면 설정 아이콘이 있습니다. 클릭 시 Even-Odd가 디폴트 값인 것을 확인할 수 있습니다.스케치 Fill Default 값 = Even-OddNon-Zero로 설정값을 바꾸면 수영장 사다리 부분이 가득 채워진 채로 나오게 되는 것을 확인할 수 있습니다. 실제로 이 파일을 개발자에게 넘기게 되면 이렇게 채워진 채로 아이콘이 노출이 됩니다.Non-Zero 설정 / 모든 shape이 다 칠해짐이렇게 나가면 안 될 테니 수정하는 법을 알려드리겠습니다.2. Paths > Reverse Order 적용원래 뚫려 있어야 하는 Path를 Layer 패널에서 찾으면 됩니다. 빨간색으로 칠한 부분이 뚫려있어야 하는 부분들입니다.레이어 패널에서 path 확인하기Path가 선택된 채로 Layers > Paths > Reverse Order을 클릭합니다.Paths > Reverse OrderReverse Order을 클릭한 후 원래 뚫려있어야 하는 부분이 뚫리게 됩니다. 이 상태로 svg로 export하시고 개발자에게 전달을 하면 됩니다.마치며개인적으로 SVG에 대한 장점이 너무나도 크다고 생각하여 굳이 갈아타지 않을 이유가 없다고 생각합니다. 특히 Web 디자인을 할 때도 SVG를 저는 적극적으로 사용하시라고 권장하고 싶습니다. � 안드로이드 개발자에게 넘기기 전에 SVG 파일이 문제가 있는지 가볍게 확인하고 싶은 경우 아래와 같은 사이트를 추천해드립니다.http://inloop.github.io/svg2android/위에 문제가 되었던 수영장 아이콘을 이 사이트에 올려서 보게 되면 이런 화면이 뜹니다. Warning하고 노란색 경고 박스가 뜨게 되는데 fills-rule:evenodd에 대해서 언급을 하더라구요. 정말 유용한 사이트인 것 같습니다.아울러..많은 디자이너들이 SVG 적용을 해보시길 바라며 주변에 이 글도 많이 공유해주시면 감사하겠습니다. (ㅎㅎ)또한 데일리호텔 Tech, UI/UX 등의 정보를 얻어보고자 하시는 분은 https://dailyhotel.io/ 를 읽어 보시길 권장합니다.그럼 다음에도 좋은 정보로 찾아뵙겠습니다!원문 링크 : https://dailyhotel.io/디자인-안드로이드-앱-svg-아이콘-적용기-왜-svg로-갈아탔는가-99c57cd84240작성자 : Product팀 Rachel Kim#데일리 #데일리호텔 #개발자 #개발팀 #업무환경 #개발환경 #SVN