스토리 홈

인터뷰

피드

뉴스

조회수 3080

국내 스타트업 개발자들도 저녁이 있는 삶을 산다.

[대화 1]친구 A: 남편은 무슨일 해?아내: 어, IT회사 다녀.친구 A: 거기서 무슨일 하는데?아내: 개발자에요.친구 A: 아 그래? 그럼 퇴근 제때 못할텐데, 애들 키우기 힘들겠네.…[대화2]아내: 아니 그렇게(반바지) 입고 회사 가려고?필자: 음... 요즘 판교 쪽에서는 패피들은 반바지에 샌들 정도 신어줘야 인정받아..아내: 우리(금융회사)는 반바지 입는 사람은 생수 배달하는 사람 뿐인데. 갈아입고 가.금융기관에서 일하는 필자 아내와의 일상 대화 중 일부입니다. 대화는 짧지만 많은 의미가 함축되어있습니다. 우리 사회에서 금융권 직원이라 하면 말끔한 수트를 차려입고 아침부터 아메리카노 한잔 하면서 뭔가 중요한 딜을 성사시킬 것 같은 느낌이라면, IT개발자라 하면 그 금융권에서 사용하는 시스템 개발을 하위 위해 파견온 협력회사 직원과 그 회사에서 고용한, 소위 을, 병, 정 프리랜서들로 반바지에 좀 헝크러진 머리를 하고 밤늦게까지 그리고 주말에도 코딩하느라 제대로 씻지도 못하고 다니는 사람을 먼저 떠올립니다. 최근에 국내 유수의 게임 회사 한 곳에서만 세 명이 과로사하거나 업무 부담으로 회사에서 자살했다고 하니 그런 인식이 전혀 틀리지만은 않은 듯 합니다.미국에서는 개발자들이 대접은 잘 받지만 업무 난이도와 강도는 정말 높다고 합니다. 미국에서는 소프트웨어 개발자라고 하면 엄지손가락을 치켜 세우며 ‘6 digits’이냐고 물어보고들 합니다. 연봉이 $100,000 즉  1억 1,200만원 이상이냐고 묻는 것입니다. 연봉 10만 달러는 미국에서도 높은 편이지만, 소프트웨어 개발자들은 일반적으로 이를 상회합니다. 실리콘밸리에서는 개발자 대졸 초임이 10만 달러 정도 된다고 합니다.시가총액 상위 기업 대부분이 ICT 기업들이고 미국에서도 소프트웨어 개발 인력은 공급이 상당히 부족하니 그럴 수 밖에 없습니다. 공대중에서 최고라 하는 스탠포드와 MIT에서 최고 인기 전공은 단연 컴퓨터 사이언스라고 하는데, 대한민국에서는 인재들이 소프트웨어 분야를 기피하고, 이 분야가 더 열악해지는 악순환이 계속되고 있습니다. 자율주행 시스템, 암진단을 인간 의사보다 잘한다는 IBM 왓슨, 자산관리 로봇까지 가지 않더라도 뱅킹, 콜센터, 주차 정산, 음식 주문, 모바일 게임 등 우리 일상 생활을 소프트웨어 개발자들이 책임지고 있는데, 만성적인 개발 인력 부족으로 우리 ICT 산업의 경쟁력이 갈수록 떨어지지 않을까 걱정입니다.어제 오늘의 이야기도 아니고, 해결책이 과연 있는가?고무적인 것은 과거보다는 소프트웨어 개발자의 근무 환경에 더 관심을 가지고 야근 문화를 없애나가려고 노력하는 기업들이 많아지고 있다는 점입니다.핀테크 기업 핀다도 접근 방법은 다소 다르지만 이런 긍정적인 문화를 확산시키는 데 노력하고 있습니다. 그로 인해 우수한 인력이 한명이라도 더 핀다를 선택하고, 대한민국 젊은이 몇명이라도 더 공시생이 되기보다는 소프트웨어 개발자로 진로를 선택하기를 기대합니다.업무 환경이 중요하다.핀다의 개발자는 공유오피스 위워크(Wework) 을지로점 내의 사무실 및 라운지 등에서 자유롭게 근무합니다. 근무중에 사무실 내의 탁구장에서 함께 탁구를 치기도 하고 다트 게임을 하기도 합니다. 위워크 다른 층 라운지 쇼파에서 탁트인 전망을 보며 일하기도 합니다.물론 업무가 몰리고 데드라인에 쫓기면 야근을 하기도 하고 주말에 집에서 일하기도 하지만 이를 권장하기 보다는 지양하고 더 줄여나가려고 합니다. 저녁이 있는 삶을 보장하기 위해 지속적으로 노력할 것입니다.Wework 16층 회의실 겸 탁구장에서 열심히 탁구치는 우리 개발자. Le Viet Hoang‘월화수목금금금’ 일해도 일정 맞추기 어려운데 무슨 배부른 소리인가?소프트웨어 개발은 집중력을 요하는데, 사람이 하루 8시간도 집중해서 일하기는 쉽지 않습니다. 집중하지 못한 상황에서 작성한 낮은 품질의 코드로 더 많은 오류를 일으키고 이를 해결하기 위해 더 많은 시간을 일해야 하는 악순환이 발생합니다. 해당 직원의 행복지수도, 건강도, 로열티도 떨어지고 퇴사할 가능성이 높아집니다. 결국 회사는 잃는 것이 더 많아지게 됩니다. 하지만, 단지 초과 근무로 인해 생산성이 떨어지므로 이를 지양해야 한다고 하기에는 현실은 일반적으로 너무 열악하고 다급합니다. 초과 근무를 대신할 다른 혁신적인 방안이 있어야 기업의 관리자를 설득할 수 있을 것입니다.핀다 개발팀은 다릅니다. 개발 환경을 소개합니다.1. 이슈관리 시스템 Jira를 이용하여 태스크, 오류 등 모든 이슈를 관리합니다.      위키 시스템 Confluence를 통해 회사 및 프로젝트의 날리지를 관리합니다.  위키에 프로젝트별로 이와 같이 스페이스를 만들고 트리 구조로 페이지를 생성합니다.그림 상의 페이지에는 Jira에서 생성한 이슈들을 나열한 것을 볼 수 있습니다. 이런 방식으로 회사의 모든 지식은 체계적으로 정리되고 공유됩니다.2.  Git을 이용하여 소스코드 뿐 아니라 디자인 프로젝트까지 관리합니다.동시에 여러 버전의 소스를 유지하고, 여러 사람이 협업하기 위해 위와 같은 Git flow를 준수합니다.소스 변경(커밋) 시에는 그림과 같이 관련 이슈 번호를 넣어서 커밋과 이슈를 연동합니다.상용 배포 버전에는 그림과 같이 버전을 태그로 달아두고 버전별로 릴리즈 노트를 작성합니다.3. Jenkins를 이용하여 시스템 빌드 및 배포를 자동화하고 있습니다. 각 빌드에도 버전을 태그로 붙이고 있습니다.4. 객체지향 프로그래밍 방식을 철저히 준수합니다.시스템을 모듈로 나누고 각 모듈 간의 의존도는 최소화합니다. 논리적으로 관련된 코드는 한 패키지, 클래스 등에 모아서 응집도를 최대화합니다. 데이터와 데이터 처리 코드는 한 클래스에 모읍니다. 중복된 코드는 피할 수 있다면 한 줄이라도 허용하지 않고, 상속, 함수화, 오버로딩 등을 최대한 활용하여 코드 사이즈를 줄입니다.5. 이해하기 쉬운, 설명이 필요 없는 코드와 문서를 작성합니다.소프트웨어는 본질적으로 복잡합니다. 복잡한 문제를 최대한 쉽게 풀어내는 것이 소프트웨어 개발자의 능력의 핵심 중 하나입니다. 문제를 더 복잡하게 만들어서 다른 사람이 이해하기 어려워 하는 것을 본인의 능력이 뛰어나서라고 자만하거나, 주석을 달거나 문서화를 하지 않고서 다른 사람이 코드를 보고 이해하면 된다는 식의 생각은 아마추어리즘일 뿐입니다.핀다의 소프트웨어 프로젝트는 경험이 부족한 신입 개발자라도 30분 내에 구조와 흐름을 파악할 수 있도록 하고 있습니다.6.  웹, 안드로이드, 아이폰 앱은 철저히 통일된 MVC 구조로 구현합니다.모델(M) 부분은 서버로부터 데이터를 받아오는 모듈, 데이터의 세부사항을  처리하는 모듈, 데이터의 보존과 공급을 담당하는 모듈로 철저히 분리하여 구현합니다.화면의 부분을 담당하는 뷰(V)는 주어진 데이터로 화면을 그리는 것만 담당합니다.화면을 구성하기 위해서는 뷰를 배치하고 모델로부터 데이터를 받아서, 뷰에 전달해야 합니다. 이는 컨트롤러(C)가 담당하는데 컨트롤러는 철저히 컨트롤만 하고 세부적인 사항을 처리하지 않습니다.핀다의 웹, 안드로이드, 아이폰 앱은 모두 동일한 폴더, 클래스 구조를 가지도록 설계하고 있습니다. 이로 인해 다른 분야를 접해보지 못한 개발자라도 하루 내에 파악하여 코드 수정까지 할 수 있어서 누구나 쉽게 풀스택 개발자가 될 수 있습니다.종합해보면, 핀다 개발팀은 나만의 스타일로 코드를 작성할 자유가 없고, 프로그래밍 컨벤션을 따라 최적의 간결한 코드를 작성해야 합니다. 타이트한 프로세스를 따라야 합니다. 구글이나 마이크로소프트 보다 더 높은 수준의 클린 코드를 작성해야 합니다. 다소 타이트해보일 수 있지만, 유능한 핀다의 개발자들은 적극적으로 이를 준수하고 오히려 더 나은 개선 방안을 내놓고 있습니다. 결국 핀다의 개발자는 저녁이 있는 삶 뿐 아니라 신나고 발전적인 직장생활까지 누리게 될 것입니다.핀다의 미래가 밝아 보이나요? 아니면 너무 타이트해 보이나요?핀다는 핀다의 미래가 밝아 보인다고 느끼는 개발자에게 문을 활짝 열어놓고 있습니다.많은 기업이 핀다 방식 혹은 더 나은 방식을 도입하여 행복하게 일하는 개발자들이 더 많아지기를 기대해봅니다.#핀다 #개발 #개발팀 #개발자 #저녁이있는삶 #기업문화 #조직문화 #사내복지
조회수 1738

HBase 설정 최적화하기

커플 필수 앱 비트윈은 여러 종류의 오픈 소스를 기반으로 이루어져 있습니다. 그 중 하나는 HBase라는 NoSQL 데이터베이스입니다. VCNC에서는 HBase를 비트윈 서비스의 메인 데이터베이스로써 사용하고 있으며, 또한 데이터 분석을 위한 DW 서버로도 사용하고 있습니다.그동안 두 개의 HBase Cluster 모두 최적화를 위해서 여러 가지 설정을 테스트했고 노하우를 공유해 보고자 합니다. 아랫은 저희가 HBase를 실제로 저희 서비스에 적용하여 운영하면서 최적화한 시스템 구성과 설정들을 정리한 것입니다. HBase를 OLTP/OLAP 목적으로 사용하고자 하는 분들에게 도움이 되었으면 좋겠습니다. 아래 구성을 최적화하기 위해서 했던 오랜 기간의 삽질기는 언젠가 따로 포스팅 하도록 하겠습니다.HBaseHBase는 Google이 2006년에 발표한 BigTable이라는 NoSQL 데이터베이스의 아키텍처를 그대로 따르고 있습니다. HBase는 뛰어난 Horizontal Scalability를 가지는 Distributed DB로써, Column-oriented store model을 가지고 있습니다. 사용량이 늘어남에 따라서 Regionserver만 추가해주면 자연스럽게 Scale-out이 되는 구조를 가지고 있습니다. 또한, Hadoop 특유의 Sequential read/write를 최대한 활용해서 Random access를 줄임으로 Disk를 효율적으로 사용한다는 점을 특징으로 합니다. 이 때문에 HBase는 보통의 RDBMS와는 다르게 Disk IO가 병목이 되기보다는 CPU나 RAM 용량이 병목이 되는 경우가 많습니다.HBase는 많은 회사가 데이터 분석을 하는 데 활용하고 있으며, NHN Line과 Facebook messenger 등의 메신저 서비스에서 Storage로 사용하고 있습니다.시스템 구성저희는 Cloudera에서 제공하는 HBase 0.92.1-cdh4.1.2 release를 사용하고 있으며, Storage layer로 Hadoop 2.0.0-cdh4.1.2를 사용하고 있습니다. 또한, Between의 데이터베이스로 사용하기 위해서 여러 대의 AWS EC2의 m2.4xlarge 인스턴스에 HDFS Datanode / HBase Regionserver를 deploy 하였습니다. 이는 m2.4xlarge의 큰 메모리(68.4GB)를 최대한 활용해서 Disk IO를 회피하고 많은 Cache hit이 나게 하기 위함입니다.또한 Highly-Available를 위해서 Quorum Journaling node를 활용한 Active-standby namenode를 구성했으며, Zookeeper Cluster와 HBase Master도 여러 대로 구성하여 Datastore layer에서 SPOF를 전부 제거하였습니다. HA cluster를 구성하는 과정도 후에 포스팅 하도록 하겠습니다.HDFS 최적화 설정dfs.datanode.handler.countHDFS에서 외부 요청을 처리하는 데 사용할 Thread의 개수를 정하기 위한 설정입니다. 기본값은 3인데 저희는 100으로 해 놓고 사용하고 있습니다.dfs.replicationHDFS 레벨에서 각각의 데이터가 몇 개의 독립된 인스턴스에 복사될 것 인가를 나타내는 값입니다. 저희는 이 값을 기본값인 3으로 해 놓고 있습니다. 이 값을 높이면 Redundancy가 높아져서 데이터 손실에 대해서 더 안전해지지만, Write 속도가 떨어지게 됩니다.dfs.datanode.max.transfer.threads하나의 Datanode에서 동시에 서비스 가능한 block 개수 제한을 나타냅니다.과거에는 dfs.datanode.max.xcievers라는 이름의 설정이었습니다.기본값은 256인데, 저희는 4096으로 바꿨습니다.ipc.server.tcpnodelay / ipc.client.tcpnodelaytcpnodelay 설정입니다. tcp no delay 설정은 TCP/IP network에서 작은 크기의 패킷들을 모아서 보냄으로써 TCP 패킷의 overhead를 절약하고자 하는 Nagle's algorithm을 끄는 것을 의미합니다. 기본으로 두 값이 모두 false로 설정되어 있어 Nagle's algorithm이 활성화되어 있습니다. Latency가 중요한 OLTP 용도로 HBase를 사용하시면 true로 바꿔서 tcpnodelay 설정을 켜는 것이 유리합니다.HBase 최적화 설정hbase.regionserver.handler.countRegionserver에서 외부로부터 오는 요청을 처리하기 위해서 사용할 Thread의 개수를 정의하기 위한 설정입니다. 기본값은 10인데 보통 너무 작은 값입니다. HBase 설정 사이트에서는 너무 큰 값이면 좋지 않다고 얘기하고 있지만, 테스트 결과 m2.4xlarge (26ECU) 에서 200개 Thread까지는 성능 하락이 없는 것으로 나타났습니다. (더 큰 값에 관해서 확인해 보지는 않았습니다.)저희는 이 값을 10에서 100으로 올린 후에 약 2배의 Throughput 향상을 얻을 수 있었습니다.hfile.block.cache.sizeHBase 의 block 들을 cache 하는데 전체 Heap 영역의 얼마를 할당한 것인지를 나타냅니다. 저희 서비스는 Read가 Write보다 훨씬 많아서 (Write가 전체의 약 3%) Cache hit ratio가 전체 성능에 큰 영향을 미칩니다.HBase 에서는 5분에 한 번 log 파일에 LruBlockCache (HBase 의 Read Cache) 가 얼마 만큼의 메모리를 사용하고 있고, Cache hit ratio가 얼마인지 표시를 해줍니다. 이 값을 참조하셔서 최적화에 사용하실 수 있습니다.저희는 이 값을 0.5로 설정해 놓고 사용하고 있습니다. (50%)hbase.regionserver.global.memstore.lowerLimit / hbase.regionserver.global.memstore.upperLimit이 두 개의 설정은 HBase에서 Write 한 값들을 메모리에 캐쉬하고 있는 memstore가 Heap 영역의 얼마만큼을 할당받을지를 나타냅니다. 이 값이 너무 작으면 메모리에 들고 있을 수 있는 Write의 양이 한정되기 때문에 디스크로 잦은 flush가 일어나게 됩니다. 반대로 너무 크면 GC에 문제가 있을 수 있으며 Read Cache로 할당할 수 있는 메모리를 낭비하는 것이기 때문에 좋지 않습니다.lowerLimit와 upperLimit의 두 가지 설정이 있는데, 두 개의 설정이 약간 다른 뜻입니다.만약 memstore 크기의 합이 lowerLimit에 도달하게 되면, Regionserver에서는 memstore들에 대해서 'soft'하게 flush 명령을 내리게 됩니다. 크기가 큰 memstore 부터 디스크에 쓰이게 되며, 이 작업이 일어나는 동안 새로운 Write가 memstore에 쓰일 수 있습니다.하지만 memstore 크기의 합이 upperLimit에 도달하게 되면, Regionserver는 memstore들에 대한 추가적인 Write를 막는 'hard'한 flush 명령을 내리게 됩니다. 즉, 해당 Regionserver이 잠시 동안 Write 요청을 거부하게 되는 것입니다. 보통 lowerLimit에 도달하면 memstore의 크기가 줄어들기 때문에 upperLimit까지 도달하는 경우는 잘 없지만, write-heavy 환경에서 Regionserver가 OOM으로 죽는 경우를 방지하기 위해서 hard limit가 존재하는 것으로 보입니다.hfile.block.cache.size와 hbase.regionserver.global.memstore.upperLimit의 합이 0.8 (80%)를 넘을 수 없게 되어 있습니다. 이는 아마 read cache 와 memstore의 크기의 합이 전체 Heap 영역 중 대부분을 차지해 버리면 HBase의 다른 구성 요소들이 충분한 메모리를 할당받을 수 없기 때문인 듯합니다.저희는 이 두 개의 설정 값을 각각 0.2, 0.3으로 해 놓았습니다. (20%, 30%)ipc.client.tcpnodelay / ipc.server.tcpnodelay / hbase.ipc.client.tcpnodelayHDFS의 tcpnodelay 와 비슷한 설정입니다. 기본값은 전부 false입니다.이 설정을 true로 하기 전에는 Get/Put 99%, 99.9% Latency가 40ms 와 80ms 근처에 모이는 현상을 발견할 수 있었습니다. 전체 요청의 매우 작은 부분이었지만, 평균 Get Latency가 1~2ms 내외이기 때문에 99%, 99.9% tail이 평균 Latency에 큰 영향을 미쳤습니다.이 설정을 전부 true로 바꾼 후에 평균 Latency가 절반으로 하락했습니다.Heap memory / GC 설정저희는 m2.4xlarge가 제공하는 메모리 (68.4GB)의 상당 부분을 HBase의 Read/Write cache에 할당하였습니다. 이는 보통 사용하는 Java Heap 공간보다 훨씬 큰 크기이며 심각한 Stop-the-world GC 문제를 일으킬 수 있기 때문에, 저희는 이 문제를 피하고자 여러 가지 설정을 실험하였습니다.STW GC time을 줄이기 위해서 Concurrent-Mark-and-sweep GC를 사용했습니다.HBase 0.92에서부터 기본값으로 설정된 Memstore-Local Allocation Buffer (MSLAB) 을 사용했습니다.hbase.hregion.memstore.mslab.enabled = true #(default)hbase-env.sh 파일을 다음과 같이 설정했습니다.HBASE_HEAPSIZE = 61440 #(60GB)HBASE_OPTS = "-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps"GC log를 Python script로 Parsing해서 STW GC 시간을 관찰하고 있습니다. 지금까지 0.2초 이상의 STW GC는 한 번도 발생하지 않았습니다.그 밖에 도움이 될 만한 설정들hbase.hregion.majorcompactionHBase는 하나의 Region에 대해서 여러 개의 StoreFile을 가질 수 있습니다. 그리고 주기적으로 성능 향상을 위해서 이 파일들을 모아서 하나의 더 큰 파일로 합치는 과정을 진행하게 됩니다. 그리고 이 과정은 많은 CPU usage와 Disk IO를 동반합니다. 그리고 이때 반응 속도가 다소 떨어지게 됩니다. 따라서 반응 속도가 중요한 경우에는, 이 Major compaction을 off-peak 시간대를 정해서 manual 하게 진행하시는 것이 좋습니다.저희는 사용자의 수가 상대적으로 적은 새벽 시간대에 crontab 이 실행시키는 script가 돌면서 전체 Region에 대해서 하나하나 Major Compaction이 진행되도록 하였습니다.기본값은 86,400,000 (ms)로 되어 있는데, 이 값을 0으로 바꾸시면 주기적인 Major Compaction이 돌지 않게 할 수 있습니다.hbase.hregion.max.filesizeHBase는 하나의 Region이 크기가 특정 값 이상이 되면 자동으로 2개의 Region으로 split을 시킵니다. Region의 개수가 많지 않을 때는 큰 문제가 없지만, 계속해서 데이터가 쌓이게 되면 필요 이상으로 Region 수가 많아지는 문제를 나을 수 있습니다. Region 수가 너무 많아지면 지나친 Disk IO가 생기는 문제를 비롯한 여러 가지 안 좋은 점이 있을 수 있기 때문에, split 역시 manual 하게 하는 것이 좋습니다. 그렇다고 Table의 Region 수가 너무 적으면 Write 속도가 떨어지거나 Hot Region 문제가 생길 수 있기 때문에 좋지 않습니다.HBase 0.92.1 에서는 기본값이 1073741824(1GB)로 되어 있는데, 저희는 이 값을 10737418240(10GB)로 늘인 후에 manual 하게 split을 하여 Region의 개수를 조정하고 있습니다.hbase.hregion.memstore.block.multipliermemstore의 전체 크기가 multiplier * flush size보다 크면 추가적인 Write를 막고 flush가 끝날때까지 해당 memstore는 block 됩니다.기본값은 2인데, 저희는 8로 늘려놓고 사용하고 있습니다.dfs.datanode.balance.bandwidthPerSec부수적인 설정이지만, HDFS의 Datanode간의 load balancing이 일어나는 속도를 제한하는 설정입니다. 기본값은 1MB/sec로 되어 있지만, 계속해서 Datanode를 추가하거나 제거하는 경우에는 기본값으로는 너무 느릴 때가 있습니다. 저희는 10MB/sec 정도로 늘려서 사용하고 있습니다.dfs.namenode.heartbeat.recheck-intervalHDFS namenode에만 해당되는 설정입니다.Datanode가 응답이 없는 경우에 얼마 후에 Hadoop cluster로부터 제거할 것인지를 나타내는 값입니다.실제로 응답이 없는 Datanode가 떨어져 나가기까지는 10번의 heartbeat가 연속해서 실패하고 2번의 recheck역시 실패해야 합니다. Heartbeat interval이 기본값인 3초라고 하면, 30초 + 2 * recheck-interval 후에 문제가 있는 Datanode가 제거되는 것입니다.기본값이 5분으로 되어 있는데, fail-over가 늦어지기 때문에 사용하기에는 너무 큰 값입니다. 저희는 문제가 있는 Datanode가 1분 후에 떨어져 나갈 수 있도록 이 값을 15,000 (ms) 으로 잡았습니다.Read short-circuitRegionServer가 로컬 Datanode로부터 block을 읽어올 때 Datanode를 통하지 않고 Disk로부터 바로 읽어올 수 있게 하는 설정입니다.데이터의 양이 많아서 Cache hit이 낮아 데이터 대부분을 디스크에서 읽어와야 할 때 효율적입니다. Cache hit에 실패하는 Read의 Throughput이 대략 2배로 좋아지는 것을 확인할 수 있습니다. OLAP용 HBase에는 매우 중요한 설정이 될 수 있습니다.하지만 HBase 0.92.1-cdh4.0.1까지는 일부 Region이 checksum에 실패하면서 Major compaction이 되지 않는 버그가 있었습니다. 현재 이 문제가 해결되었는지 확실하지 않기 때문에 확인되기 전에는 쓰는 것을 추천하지는 않습니다.설정하는 방법은 다음과 같습니다. dfs.client.read.shortcircuit = true #(hdfs-site.xml) dfs.block.local-path-access.user = hbase #(hdfs-site.xml) dfs.datanode.data.dir.perm = 775 #(hdfs-site.xml) dfs.client.read.shortcircuit = true #(hbase-site.xml)Bloom filterBloom filter의 작동방식에 대해 시각적으로 잘 표현된 데모 페이지HBase는 Log-structured-merge tree를 사용하는데, 하나의 Region에 대해서 여러 개의 파일에 서로 다른 version의 값들이 저장되어 있을 수 있습니다. Bloom filter는 이때 모든 파일을 디스크에서 읽어들이지 않고 원하는 값이 저장된 파일만 읽어들일 수 있게 함으로써 Read 속도를 빠르게 만들 수 있습니다.Table 단위로 Bloom filter를 설정해줄 수 있습니다.ROW와 ROWCOL의 두 가지 옵션이 있는데, 전자는 Row key로만 filter를 만드는 것이고, 후자는 Row+Column key로 filter를 만드는 것입니다. Table Schema에 따라 더 적합한 설정이 다를 수 있습니다.저희는 데이터 대부분이 메모리에 Cache 되고 하나의 Region에 대해서 여러 개의 StoreFile이 생기기 전에 compaction을 통해서 하나의 큰 파일로 합치는 작업을 진행하기 때문에, 해당 설정을 사용하지 않고 있습니다.결론지금까지 저희가 비트윈을 운영하면서 얻은 경험을 토대로 HBase 최적화 설정법을 정리하였습니다. 하지만 위의 구성은 어디까지나 비트윈 서비스에 최적화되어 있는 설정이며, HBase의 사용 목적에 따라서 달라질 수 있음을 말씀드리고 싶습니다. 그래서 단순히 설정값을 나열하기보다는 해당 설정이 어떤 기능을 하는 것인지 저희가 아는 한도 내에서 설명드리려고 하였습니다. 위의 글에서 궁금한 점이나 잘못된 부분이 있으면 언제든지 답글로 달아주시길 바랍니다. 감사합니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!
조회수 1139

테이블이냐, 컬렉션이냐, 그것이 문제로다!(KOR)

편집자 주 외래어 표기법에 따르면 ‘원어에서 띄어 쓴 말은 띄어 쓴 대로 한글 표기를 하되, 붙여 쓸 수도 있다.’고 규정하고 있다.(제3장 제1절 영어의 표기, 제10항과, 컴퓨터 전문어, 전기 전문어 등) 즉 ‘원칙’과 ‘허용’이 모두 가능하다는 의미다. 이를 바탕으로 여러 표기 용례를 참고한 결과, TableView는 ‘테이블뷰(원칙)’로 표기해야 하나, 본문에서는 독자의 가독성을 높이기 위해 ‘테이블 뷰(허용)’로 표기한다. 응용하여, CollectionView는 ‘컬렉션 뷰’로, TableViewCell은 ‘테이블 뷰 셀’ 등으로 띄어 쓴다. Overview앱에서 데이터를 사용자에게 보여줄 땐 여러 가지의 모습으로 나타납니다. 설정 앱처럼 목록으로 보여줄 때도 있고, 사진 앱처럼 그리드(grid) 형식으로 보여줄 때도 있습니다. 이처럼 데이터를 보여줄 때 많이 사용되는 뷰는 테이블 뷰(UITableView) 또는 컬렉션 뷰(UICollectionView)입니다. 각자 특징이 있기 때문에 앱의 성격에 따라 적절한 뷰를 사용해야 합니다. 왜냐하면 목록을 보여주는 디자인을 바꿀 때, 다시 개발해야 하는 수고를 덜 수 있기 때문입니다. 이번 글에선 각각의 뷰를 간략하게 알아보겠습니다. 목록 형식의 설정 앱과 그리드 형식의 사진 앱 스크린샷테이블 뷰(UITableView)단일 열에 배열된 행을 사용해 데이터를 표시하는 뷰입니다. 수직 스크롤만 가능하며, 테이블의 개별 항목을 구성하는 셀은 테이블 뷰 셀(UITableViewCell) 객체입니다. 테이블 뷰는 이 객체들을 이용해 테이블에 표시되는 행을 그립니다. 여러 행은 하나의 섹션 안에 구성될 수 있으며, 각 섹션은 헤더(header)와 푸터(footer)를 가질 수 있습니다. 섹션과 행은 인덱스 번호로 구별하는데, 번호는 0부터 시작합니다. 테이블 뷰는 plain과 grouped 스타일 중 한 가지의 스타일을 가질 수 있습니다. Plain 스타일은 보통 목록 스타일입니다. 섹션의 헤더와 푸터는 섹션 분리기(inline separators)로 표시되고 스크롤을 할 때 해당 섹션 안에 있는 콘텐츠 위에 나타납니다. Grouped 스타일은 시각적으로 뚜렷한 행 그룹을 표시하는 섹션이 있습니다. 섹션의 헤더와 푸터는 콘텐츠 위에 나타나지 않습니다. 아래와 같은 사진을 보시면 확연히 차이를 볼 수 있습니다. plain 스타일의 연락처 앱과 grouped 스타일의 설정 앱테이블 뷰의 많은 메소드들은 인덱스패스(NSIndexPath) 객체를 매개변수 또는 리턴 값으로 사용합니다. 테이블 뷰는 해당하는 행의 색인 인덱스와 섹션 인덱스 값을 가져올 수 있게 인덱스패스의 범주를 선언합니다. 또한 색인 인덱스와 섹션 인덱스 값을 가지고 인덱스패스를 만들 수 있습니다. 특히 여러 섹션이 있는 테이블 뷰는 섹션 인덱스 값이 반드시 있어야 행의 인덱스 번호로 구별할 수 있습니다.override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> AttractionTableViewCell {         // Table view cells are reused and should be dequeued using a cell identifier.         let cellIdentifier = "AttractionTableViewCell"              guard let cell = tableView.dequeueReusableCell(withIdentifier: cellIdentifier, for: indexPath) as? AttractionTableViewCell else {             fatalError("The dequeued cell is not an instance of AttractionTableViewCell.")         }                 let attraction = attractions[indexPath.row]                 cell.attractionLabel.text = "\(indexPath.row). \(attraction.nameWithDescription)"         cell.attractionImage.image = attraction.photo                 cell.attractionImage.tag = indexPath.row                 attraction.indexPath = indexPath                 ...                 return cell     } 위의 코드는 데이터 소스(data source) 메소드로, 테이블 뷰의 특정한 위치에 셀을 추가합니다. 다시 말해, 이 메소드는 테이블 뷰가 ‘표시할 새로운 셀이 필요할 때마다’ 특정 행에 노출할 정보가 있는 셀을 만들고 리턴하는 걸 말합니다. 매개변수로 필요한 셀 객체의 행을 가리키는 indexPath 값을 전달합니다. 그리고 indexPath의 row 값을 이용해서 attraction이라는 배열 인덱스로 활용하고, 셀에 표시할 정보들을 설정합니다. 여기서 attraction 배열은 관광 명소들의 정보들이 담고 있는 배열인데, 1행은 첫 번째로 저장한 관광 명소, 2행은 두 번째로 저장한 관광 명소 등 순서대로 설정하도록 indexPath.row 값을 이용하는 것입니다. indexPath의 row 값과 배열의 인덱스 값은 0부터 시작하기 때문입니다. 해당 예제는 섹션이 1인 경우이기 때문에 섹션 인덱스 값이 없지만, 섹션이 여러 개 있다면 반드시 섹션 인덱스 값을 이용해서 설정해야 합니다.테이블 뷰 객체는 데이터 소스(data source)와 델리게이트(delegate)가 필요합니다. 데이터 소스는 UITableViewDataSource 프로토콜을 구현해야 하고, 델리게이트는 UITableViewDelegate 프로토콜을 구현해야합니다. 데이터 소스는 테이블 뷰가 테이블을 만들 때 필요한 정보를 제공하고 테이블의 행이 추가, 삭제 또는 재정렬할 때 데이터 모델을 관리합니다. 델리게이트는 화면에 보이는 모습과 행동을 담당합니다. 예를 들어 표시할 행의 수, 사용자가 특정 행을 터치했을 때, 행의 재정렬 등과 같은 것입니다.override func numberOfSections(in tableView: UITableView) -> Int {         // #warning Incomplete implementation, return the number of sections         return 1     }      override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {         // #warning Incomplete implementation, return the number of rows         return attractions.count     } 위의 두 소스는 데이터 소스가 필수적으로 구현해야 하는 메소드입니다. 하나는 섹션의 개수를 리턴하고, 또 하나는 한 섹션 안에 있는 행의 개수를 리턴합니다.테이블 뷰는 수정 모드에서 행을 추가, 삭제, 재정렬할 수 있습니다. 각 행은 테이블 뷰 셀에 연관된 editingStyle에 따라서 추가, 삭제, 재정렬을 할 수 있는데, 예를 들어 editingStyle이 insert라면 추가하는 메소드를 실행하고, delete면 삭제하는 메소드를 실행합니다. 행의 showsReorderControl 속성이 true라면, 재정렬하는 메소드를 실행할 수 있습니다.// Override to support editing the table view.     override func tableView(_ tableView: UITableView, commit editingStyle: UITableViewCellEditingStyle, forRowAt indexPath: IndexPath) {         if editingStyle == .delete {             // Delete the row from the data source             ...                 // delete rows and attractions and reload datas             attractions.remove(at: indexPath.row)             tableView.deleteRows(at: [indexPath], with: .middle)             tableView.reloadData()         } else if editingStyle == .insert {             // Create a new instance of the appropriate class, insert it into the array, and add a new row to the table view         }     } 위 소스는 editingStyle이 delete일 때 셀을 삭제하고 테이블 뷰를 다시 로드하는 기능을 구현한 것입니다.테이블 뷰를 만드는 가장 쉽고 권장하는 방법은 바로 스토리보드에서 테이블뷰컨트롤러(UITableViewController)를 이용해서 만드는 겁니다. 런타임에 테이블뷰컨트롤러는 테이블 뷰를 만들고 델리게이트와 데이터 소스를 자기 자신으로 할당합니다.컬렉션 뷰(UICollectionView)컬렉션 뷰는 테이블 뷰에서 할 수 있는 모든 것을 할 수 있습니다. 섹션을 가질 수 있고, 인덱스패스 값을 이용해서 셀을 구별합니다. 이 셀들은 컬렉션 뷰 셀(UICollectionViewCell)의 서브 클래스이며 데이터 소스(UICollectionViewDataSource)와 델리게이트(UICollectionViewDelegate)가 필요합니다. 셀을 추가, 삭제, 재정렬하는 기능도 구현할 수 있습니다. 그렇다면 컬렉션 뷰와 테이블 뷰를 구분하는 특징은 무엇일까요? 바로 레이아웃입니다. 컬렉션 뷰는 여러 개의 열과 행으로 셀을 표현할 수 있습니다. 예를 들어, 그리드(grid) 형태로 아이템의 목록을 보여줄 수 있습니다. 그래서 수직 스크롤뿐만 아니라 수평 스크롤도 할 수 있습니다.스토리보드에서 디자인한 테이블 뷰 셀과 컬렉션 뷰 셀위 스크린샷에서 테이블 뷰와 컬렉션 뷰의 가장 큰 차이는 바로 셀입니다. 테이블 뷰에서는 하나의 열에 여러 행을 표시하는 형식이기 때문에, 셀의 모습을 행에 맞춰서 디자인합니다. 하지만 컬렉션 뷰는 열과 행을 만들 수 있기 때문에, 꼭 행의 모습이 아니더라도 다양한 모습으로 셀을 디자인할 수 있습니다. 컬렉션 뷰 셀의 가장 큰 특징이기도 하죠. 위처럼 셀을 디자인하고 앱을 실행하면 아래의 화면이 나타납니다.테이블 뷰와 컬렉션 뷰의 앱 화면 차이또한 컬렉션 뷰는 레이아웃 객체가 있습니다. 기존에 제공하는 flow layout을 사용해도 괜찮지만, 본인이 원하는 레이아웃 모양을 custom layout을 만들어서 사용합니다. 이를 담당하는 프로토콜은 UICollectionViewDelegateFlowLayout 입니다.func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize {         let fullWidth = collectionView.frame.size.width - (self.CGFLOAT_INSET_WIDTH * 3) - (self.CGFLOAT_ITEMSPACING * 3)         let width = fullWidth/3         return CGSize(width: width, height: width + self.CGFLOAT_HEIGHT_ATTRACTIONCELL_DEFAULT)     }         func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, insetForSectionAt section: Int) -> UIEdgeInsets {         return UIEdgeInsetsMake(self.CGFLOAT_LINESPACING_VERTICAL, self.CGFLOAT_INSET_WIDTH, self.CGFLOAT_LINESPACING_VERTICAL, self.CGFLOAT_INSET_WIDTH)     } 위 소스에서 collectionView(:layout:sizeForItemAt:) 메소드는 해당하는 셀의 사이즈를 설정하고, collectionView(:layout:insetForSectionAt:) 메소드는 섹션 안에 margin을 설정합니다.여러 모양의 셀을 이루어 하나의 뷰 화면을 구현할 수도 있습니다. 섹션마다 셀을 만들어 각각 다른 모습의 셀을 설정하고, 한 화면에 다양한 모습의 셀을 가진 뷰를 만드는 것입니다. 예를 들어, 헤더, 메뉴, 본문, 푸터 각각 셀을 만들어서 원하는 모양으로 만들고, 하나의 뷰 컨트롤러에 셀을 조합해서 한 화면에 나타나게 할 수 있습니다. 이 방법을 사용하면 자주 사용하는 셀을 재활용할 수 있습니다. 똑같은 헤더와 푸터 셀을 여러 번 만들지 않고 기존의 셀을 재활용하면 시간도 절약하고, 훨씬 깔끔한 소스를 만들 수 있을 겁니다.브랜디 앱 스크린샷 일부위의 스크린샷처럼 여러 화면에서 보여줘야 할 똑같은 뷰가 있을 때, 셀 xib 파일을 만들고 컬렉션 뷰에서 셀을 섹션별로 설정 및 사용하면 재활용하기 좋습니다.Conclusion지금까지 테이블 뷰와 컬렉션 뷰의 특징들을 살펴봤습니다. 한마디로 정리하면 테이블 뷰는 가장 간단한 목록을 만들 수 있습니다. 컬렉션 뷰는 다양한 모습의 목록으로 커스터마이징(Customizing)할 수 있습니다.그렇다면 우리는 어떤 것을 선택해야 할까요? 구현할 목록이 얼마나 복잡한지에 따라 선택은 달라집니다. 테이블 뷰는 간단하고 보편적인 목록을 만듭니다. 반면에 컬렉션 뷰는 특정한 모습의 목록을 만들 수 있습니다. 그래서 테이블 뷰는 목록이 간단하고 디자인 변경이 없을 때만 사용하길 권장합니다. 하지만 나중에 디자인이 바뀔 수도 있다면 컬렉션 뷰를 사용하는게 더 좋겠죠.Simple is the best! 간단하게 구현할 수 있는 건 테이블 뷰를 사용합시다. 테이블 뷰에서 구현하기 힘들다면 컬렉션 뷰를 이용해 개성 있는 목록을 마음껏 만들어봅시다!참고UITableView - UIKit | Apple Developer DocumentationUICollectionView - UIKit | Apple Developer Documentation 글김주희 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 545

성장하려면 완벽한 바퀴보단 조잡한 자전거를.

2017년부터 현재까지 엘리스와 함께 다양하고 유익한 프로그래밍 수업을 만들어오고 계신 김건우 선생님을 만났습니다! 학생의 성장에 강력한 동기부여를 받고, 그 누구보다도 사람에 대해서 깊이 생각하는 개발자가 되고 싶다는 멋진 건우님의 이야기를 함께 들어봐요. :)김건우 님모빌리티 플랫폼 타다 개발자엘리스 프로그래밍 선생님• 도전! 디버깅 입문• 본격! 프로그래밍• 파이썬 실전 데이터 분석• 코딩학교 II - 파이썬• 코딩학교 I - 파이썬• 코딩학교 : 도전 20문제 - 파이썬KAIST 전산학부Q. 선생님 안녕하세요! 자기소개 부탁드려요.안녕하세요. 저는 모빌리티 서비스인 타다에서 모바일 클라이언트 개발을 하고 있는 김건우라고 합니다. 타다의 iOS와 안드로이드 앱을 만들고 있습니다. 엘리스에서는 지금까지 6번 정도 강의를 해왔구요, 주로 코딩을 갓 시작하신 분들이 그다음 레벨로 넘어가기 전에 코딩에 익숙해지기 위한 수업들을 진행해 왔습니다.Q. 2017년부터 꾸준히 강의를 해오셨어요. 강의를 계속하신 이유가 무엇인가요?그전에도 학생들을 오프라인으로 가르쳐본 적은 있었는데 온라인으로 가르치는 건 되게 다른 경험이었어요. 완전히 다른 일을 하는 느낌이었고 그게 재밌어서 자연스레 계속하게 된 것 같아요.무엇보다도 다음 강의를 계속하게 되었던 원동력은 학생들이 성장한다라는 느낌을 받을 때였던 것 같아요. 입에 발린 말처럼 들릴 수도 있겠지만 진짜 그런 걸 느끼거든요. 학생들의 얼굴을 직접 보지는 못하지만 질문 수준들이 확 올라온다는 걸 느낄 때가 있어요. 1,2주 차와 3,4주 차가 다를 때 특히. 그럴 때 '아 좀 더 하고 싶다'는 마음이 드는 것 같아요.Q. 강의할 때의 애로사항이나 어려움은 무엇이었나요?저도 그렇고 제 주변에 강의를 하시는 다른 분들을 봤을 때 영향력을 가지고 싶다는 욕구가 강의를 하는 이유 중 하나인 것 같아요. 그런데 오히려 여기에서 오는 부담도 있어요. 제가 생각하기에는 크게 중요하지 않아서 적당히 설명하고 넘어갔는데, 나중에 보면 단단히 잘못 이해하고 있는 분들도 있는 거예요. 수강생 분들은 내가 훨씬 많은 것을 안다고 생각하고 그렇기 때문에 큰 비판 없이 수용할 수 있는데 내가 이렇게 해도 되는 걸까에 대한 고민을 한 경우가 많았어요. 이것 때문에 스트레스를 많이 받았고요. 그래서 사실 준비할 시간이 충분히 없다고 느껴지면 강의 제안에 거절을 많이 했어요. 급하게 준비해도 물론 강의를 낼 수야 있겠지만 죄책감이 많이 들더라고요.Q. 강의 제작에 있어 어떤 것을 많이 고려하셨나요?어떻게 하면 재미를 느낄 수 있을까라는 고민을 많이 했어요. 저는 배우면서 제일 중요한 거는 흥미라고 생각하고, 그 흥미를 위해서는 강의가 제공하는 콘텐츠와 그것을 전달하는 방식이 중요하거든요. 그래서 첫 번째로는 이제 막 파이썬 문법 정도를 뗀 사람들이 '뭐가 제일 궁금할까?'를 많이 고민했구요. 그다음에는 그들이 '이걸 배워서 뭘 하고 싶을까'를 고민했죠. 시쳇말로 저는 코딩으로 밥 벌어먹고 사는 사람인데 이게 본업이 아니거나, 혹은 코딩을 처음 배우기 시작하는 분들이 무엇을 원할지 많이 생각했던 것 같아요.Q. 그래서 얻은 답은 무엇이었나요?세상에서 존재하는, 남이 하는 걸 본 적 있는 어떤 일을 내가 비슷하게나마 해보는 것. 그게 되게 클 거라고 생각했구요. 예를 들면 트럼프 대통령이 연설에서 제일 많이 쓴 단어가 뭘까? 뉴스를 보다 보면 쉽게 접할 법한 자료들이 있잖아요. 평소에는 그냥 '이렇게 조사를 했나 보네' 하고 넘어갈 텐데 내가 직접 그 연설문을 가지고 그 단어를 직접 찾아보는 거는 다른 경험일 거라고 생각해요. 그리고 그렇게 어딘가에서 본 적 있는 결과물을 직접 만들어 낼 때 학생들이 더 많은 흥미를 느낄 거라고 생각을 했어요.파이썬 실전 데이터 분석 실습 화면Q. 라이브 수업에서부터 녹화 수업까지 엘리스의 변천사와 함께 하셨는데 가장 기억에 남는 일화가 있다면요?라이브에 사람들이 되게 많이 들어왔을 때가 기억에 남아요. 무료로 강의를 공개했을 때가 한번 있잖아요? 그때 몇천 명의 학생들이 수강 신청을 했어요. '아 진짜 큰일 났다 라이브.'라고 생각했죠. 그런데 다행히 수천 명의 학생들이 들어오진 않았어요. 그래도 나중에 돌이켜보니 꽤 많이 들어온 건데? 싶더라고요.확실히 녹화형으로 가면서 마음은 많이 편해졌어요. 라이브가 재미는 있는데 되게 큰 부담이 돼요. 말실수 내지는 제가 완벽하게 흐름을 꿰고 있지 않으면 헤매는 걸 모두가 다 보게 되잖아요. 오타 하나 때문에 오류가 계속 나는 경우도 많거든요. 라이브 때는 항상 컴퓨터 2대로 진행하는데 그레이더가 잘못되어 있어서 '아 여러분 잠시만요'하고 한쪽에서 계속 고친다든지 이런 돌발 상황들이 많이 있었던 게 기억나네요.라이브 수업 당시 강의 화면Q. 여러 과목 중 특히 추천해주고 싶은 과목이 있으신가요?파이썬 실전 데이터 분석이요. 문제 설계에서부터 시작해서 실습 문제, 프로젝트까지 제가 공을 가장 많이 들인 과목이거든요. 프로젝트 설계도 신경을 많이 썼구요. 말씀드렸던 ‘학생들이 뭘 하고 싶을까’에 대한 고민을 가장 많이 했고 콘텐츠에 그대로 반영된 과목이라고 생각해요.Q. 어떤 학생들에게 어떤 도움이 되는 과목인가요?‘파이썬은 배웠지만 이걸로 뭘 하지’를 고민하는 학생들에게 ‘데이터만 있으면 파이썬으로 아주 쉽게 원하는 것을 뽑아내고 인사이트를 얻을 수 있다’는 걸 알려주는 과목이에요. 라이브러리를 최대한 덜 쓰고 파이썬 기본 문법만 가지고도 할 수 있도록 만들었어요. 대단한 개발자만 이런 걸 할 수 있는 게 아니라는 것을 알려주고 싶었어요. 파이썬에서 기본적으로 배웠던 string 다루는 법, list 이런 것만 가지고도 가능하다는 걸 학생들에게 알려주고 싶었고 자신감을 갖게 해주고 싶었어요.Q. 다음에는 어떤 강의를 만들고 싶으신가요?지금 하고 있는 일이 앱 개발이라서 관련 강의를 생각하고 있어요. 앱 개발을 하다 보면 특히 세팅에 많은 시간이 들어요. 다른 개발보다 더더욱이요. 엘리스는 세팅을 하지 않고 코딩을 시작할 수 있다는 게 되게 큰 장점이잖아요. 오히려 파이썬 기본 코딩 같은 것은 일반 컴퓨터에서도 세팅이 아주 간단한 편이에요. 그런데 앱 개발 같은 경우에는 진짜 많이 필요하거든요. 그래서 앱 개발에 대한 강의를 한다면 엘리스의 장점을 훨씬 더 많이 발휘할 수 있는 분야인 것 같고 제가 지금 하고 있는 일이기도 하고요.Q. 코딩 초급 단계의 학습자가 가장 어려워하는 것과 성취도를 높이기 위해 중요한 건 뭘까요?학생분들이 에러가 뜨면 일단 패닉을 하세요. 사실 코딩을 하다 보면 10년 차이든 신입이든 에러 내는 건 똑같거든요. 당연히 사람은 완벽할 수가 없고 에러 내는 것은 어쩔 수 없는 건데. '어 큰일 났다'라고 일단 생각을 하시는 것 같아요. 그런데 다음 스텝으로 넘어가려면 그 에러 코드를 읽어야 하거든요. 그래서 저는 디버깅 수업이 재미는 별로 없었을지라도 학생들에게 실질적으로 도움이 되게 많이 될 거라고 생각해요. 그리고 그 스텝을 넘어가면 그래도 내가 성장할 수 있는 발판이 열린다고 생각을 하고요.질문에서도 수준의 차이가 난다고 느낄 때가 있어요. “어 왠지 모르겠는데 안돼요”와 “내가 어떤 걸 해보니까 이런 에러가 났는데 이것도 해봤는데 안되더라 그래서 질문을 했다”라고 콘텍스트 설명을 충분히 하는 학생분들이 계세요. 후자가 더 도와주고 싶기도 하고, 도와줄 수 있기도 하고요. 학생들이 좀 더 에러를 두려워하지 않고, 또 잘 질문하는 법을 배우면 성장할 수 있을 것이라고 생각해요.도전! 디버깅 입문 수업 화면Q. 코드 질문을 잘하는 팁이 있다면요?질문에 포함되어야 할 것은 세 가지가 있어요. 가장 먼저 제일 중요한 것은 ‘내가 얻고 싶은 결과’ 예요. 그리고 ‘지금의 상황’과 ‘시도해본 것’. 한 문장으로 말하면 ‘내가 얻고 싶은 결과가 무엇인데, 지금의 상황은 이렇고, 어떤 것을 시도해보았지만 여전히 안 된다.’라고 할 수 있을 것 같아요.개발자끼리 일을 할 때도 그런 경우가 많아요. 제가 a가 안 된다라고 열심히 설명을 하고 있었는데 사실 제가 얻고 싶은 결과는 애초에 a를 안 해도 되는 거였어요. 그런데 내가 잘 질문하지 않으면 옆사람은 a 되는 법만 열심히 가르쳐주게 되는 거죠. 사실 내가 진짜 하고 싶은 걸 더 잘 이룰 수 있는 방법인 b가 있고, 또 b가 더 쉬울 수도 있는 거거든요. 그래서 질문을 잘하는 게 중요합니다.Q. 프로그래밍을 하면서 슬럼프는 없었나요?사실 재미를 잃은 적은 별로 없었어요. 잘 안 된 적은 많이 있지만 재미는 계속 있었던 것 같아요. 잘 안 될 때는 그냥 다른 분야를 좀 보다 오고 그랬어요. 뭔가 잘 안 되는 대부분의 경우는 내가 당연히 겪어야 하는 일인데 그걸 힘들게 느끼는 거라고 생각해요. 그럴 땐 다른 걸 보면서 리프레쉬하거나 쉬었다가 다시 했던 것 같아요. 그런데 사실 저는 제가 덕업일치라고 생각하거든요. 복 받은 것 같아요.Q. 프로그래밍 실력을 키우려는 사람에게 해줄 조언이 있나요?첫 번째는 알고리즘 문제를 푸는 능력이에요. 두 가지 방법이 있다고 생각해요. 다시 태어나거나, 그래도 문제를 많이 풀어보거나. 사실 알고리즘 문제는 제가 되게 취약한 분야예요. 알고리즘을 진짜 잘하는 사람들이 있어요. 중고등학교 때부터 트레이닝을 잘해놓고, 머리도 좋고요. 그런 사람들은 정말 내가 생각하지도 못한 풀이를 내놓거든요. 그래서 저는 알고리즘은 지금 열심히 한다고 해서 잘 안 되는 것일 수 있다, 그냥 못하지 않을 정도로 중간만 가자라고 생각을 해요. 많이 풀어보면 중간은 갈 수 있어요. 그리고 그런 문제들이 굉장히 많고요.두 번째로는 읽기 쉬운 프로그램을 짜는 것이에요. 협업할 때 소통하기 좋은 프로그램을 짜는 게 되게 중요해요. 사실 대부분의 코딩 면접에서도 이걸 본다고 생각하고요. 쉽게 말해서 변수 이름을 하나 정할 때도 사람 이름을 저장하는 변수명을 ‘a’라고 지으면 아무도 이해 못하잖아요. 코드를 적기 전에 이걸 보는 사람은 어떻게 생각할지 고민을 좀 더 하면서 코드를 적는 연습을 하고 좋은 코드를 많이 보다 보면 늘 수 있다고 생각해요.마지막 세 번째는 프로그램을 설계하는 능력인데요. 이것은 진짜로 일을 해봐야 한다고 생각합니다. 회사에서 일을 하거나 개인 프로젝트를 하거나. 어쨌든 사람들이 쓰는 무언가를 만들어봐야만 느는 거라고 생각을 합니다.Q. 많은 분들이 학교에서 배우는 것과 실무의 간극이 큰 것 같아 어떻게 대비하면 좋을지 궁금해하세요.컴퓨터 사이언스는 그래도 가장 그 간극이 적은 분야라고 생각해요. 저는 굉장히 놀랐어요. “아 이렇게까지 많이 쓰는구나”했죠. 학교 공부를 잘한다고 개발을 잘하는 건 아니지만 좋은 개발을 하고 좋은 프로그램의 동작 방식을 설계하는 데에는 학교에서 배우는 것이 관련성이 크다고 생각해요. 사실 스타트업일수록 더 그렇거든요. 제가 만약 큰 회사에 갔다면 정말 피처 하나만 개발하겠지만 스타트업일수록 더 많은 일을 하고 설계에도 참여를 하게 되는데 그런 설계를 하기 위해서는 학교에서 배우는 과목들이 정말로 중요해요. 저는 그래서 간극이 크다는 건 잘못된 표현인 것 같고, 단지 내가 이걸 배워서 어디에 쓸지를 모르는 것뿐이라고 생각해요.Q. 개발자로서 좋은 태도가 있다면 무엇이라고 생각하시나요?끊임없이 배워야 해요. 예를 들어 아이폰 새로운 게 나왔다, 하면 그 아이폰에서 어떤 기능을 지원하는지 새로 나온 건 뭔지 내가 지금까지 짰던 프로그램이 그 폰에서 돌아가지 않으면 어떻게 하지, 이런 걸 다 고민해야 해요. 기술이 너무 빨리 변하고 있고 사람들의 기준도 높아져요. “당연히 그거 되어야 하는 거 아니야?”라고 생각하는데 실제로는 그게 되게 당연하지 않은데도 불구하고요.Q. 향후 5년, 10년 후에 어떤 일을 하고 싶으신지 궁금해요.대학 입학할 때는 사실 디자이너가 하고 싶었어요. 그래서 산업디자인과를 가야겠다고 생각했죠. 그런데 이것저것 하다 보니까 코딩이 재미있고 또 디자인보다 조금 덜 힘들 것 같다고 생각했어요. 쉽게 말해 취업도 잘 될 것 같았고, 디자인은 처음부터 시작해야 하는데 프로그래밍은 해본 경험이 있었구요. 지금 남들보다 조금 더 잘하기 때문에 성취감을 빨리 느낄 수 있어서 치고 나갈 수 있을 거라고 생각을 해서 전산학과를 택했어요.그런데 결국에는 사람이 자기가 원래 하고 싶었던 걸 보게 되는 것 같아요. 그래서 저는 사람들을 연구하는 개발자가 되고 싶어요. 사람들이 제가 만든 프로그램을 어떻게 쓸지, 뭘 원하고 어떤 생각을 하며 사용할지, 그럼 나는 어떻게 만들어야 할까, 이런 걸 고민하는 사람이 되고 싶어요. 요즘에는 UX엔지니어라고 많이 부르더라고요. 사람들과 가장 가까운 개발자, 디자인에도 많은 이해를 하고 있는 그런 개발자가 되고 싶어요.Q. 수강생 분들에게 한 말씀 부탁드려요!일단 뭘 만들어보셨으면 좋겠어요. 공부도 당연히 중요하지만 공부하는 건 만드는 게 아니거든요. 제가 되게 좋아하는 그림이 있어요.Illustration by Henrik Kniberg내가 성장할 때는 아주 조잡하더라도 작동하는 무언가를 만들고 점점 더 낫게 만드는 게 좋다는 의미예요. 제가 이 그림을 되게 좋아하거든요. 그래서 저는 이론 공부도 해야 하지만 직접 무언가를 만들어 보라고 말해주고 싶어요.Q. 건우님에게 엘리스란?가르치는 즐거움을 제대로 알게 해 준 곳.의미 있는 프로그래밍 교육 경험을 만들고,강의 제작 지원을 받으며 부수입을 얻고 싶은 분이라면엘리스 교육자에 주저없이 지원해주세요. :)▶ 교육자 지원하기
조회수 989

비트윈 시스템 아키텍처

VCNC는 커플을 위한 모바일 앱 비트윈을 서비스하고 있습니다. 비트윈은 사진, 메모, 채팅, 기념일 등 다양한 기능을 제공하며, 오픈 베타 테스트를 시작한 2011년 11월부터 현재까지 연인 간의 소통을 돕고 있습니다. 그동안 비트윈 시스템 아키텍처에는 많은 변화가 있었으며 다양한 결정을 하였습니다. 비트윈 아키텍처를 발전시키면서 배우게 된 여러 가지 노하우를 정리하여 공유해보고자 합니다. 그리고 저희가 앞으로 나아갈 방향을 소개하려 합니다.소프트웨어 스택Java: 비트윈 API서버는 Java로 작성되어 있습니다. 이는 처음 비트윈 서버를 만들기 시작할 때, 서버 개발자가 가장 빨리 개발해낼 수 있는 언어로 프로그래밍을 시작했기 때문입니다. 지금도 자바를 가장 잘 다루는 서버 개발자가 많으므로 여전히 유효한 선택입니다.Netty: 대부분의 API는 HTTP로 호출되며, 채팅은 모바일 네트워크상에서의 전송 속도를 위해 TCP상에서 프로토콜을 구현했습니다. 두 가지 모두 Netty를 통해 사용자 요청을 처리합니다. Netty를 선택한 것은 뛰어난 성능과 서비스 구현 시 Thrift 서비스를 통해 HTTP와 TCP 프로토콜을 한 번에 구현하기 쉽다는 점 때문이었습니다.Thrift: API서버의 모든 서비스는 Thrift 서비스로 구현됩니다. 따라서 TCP뿐만 아니라 HTTP 또한 Thrift 인터페이스를 사용합니다. HTTP를 굳이 Thrift서비스로 구현한 이유는, TCP로 메세징 전송 시 똑같은 서비스를 그대로 사용하기 위함이었습니다. 덕분에 빠른 채팅 구현 시, 이미 구현된 서비스들을 그대로 사용할 수 있었습니다. 또한, 채팅 패킷들은 패킷 경량화를 위해 snappy로 압축하여 송수신합니다. 모바일 네트워크상에서는 패킷이 작아질수록 속도 향상에 크게 도움이 됩니다.HBase: 비트윈의 대부분 트랜젝션은 채팅에서 일어납니다. 수많은 메시지 트랜젝션을 처리하기 위해 HBase를 선택했으며, 당시 서버 개발자가 가장 익숙한 데이터베이스가 HBase였습니다. 서비스 초기부터 확장성을 고려했어야 했는데, RDBMS에서 확장성에 대해 생각하는 것보다는 당장 익숙한 HBase를 선택하고 운영하면서 나오는 문제들은 차차 해결하였습니다.ZooKeeper: 커플들을 여러 서버에 밸런싱하고 이 정보를 여러 서버에서 공유하기 위해 ZooKeeper를 이용합니다. Netflix에서 공개한 오픈 소스인 Curator를 이용하여 접근합니다.AWS비트윈은 AWS의 Tokyo리전에서 운영되고 있습니다. 처음에는 네트워크 및 성능상의 이유로 국내 IDC를 고려하기도 했으나 개발자들이 IDC 운영 경험이 거의 없는 것과, IDC의 실질적인 TCO가 높다는 문제로 클라우드 서비스를 이용하기로 하였습니다. 당시 클라우드 서비스 중에 가장 안정적이라고 생각했던 AWS 를 사용하기로 결정했었고, 지금도 계속 사용하고 있습니다.EC2: 비트윈의 여러 부가적인 서비스를 위해 다양한 종류의 인스턴스를 사용 중이지만, 메인 서비스를 운용하기 위해서는 c1.xlarge와 m2.4xlarge 인스턴스를 여러 대 사용하고 있습니다.API 서버: HTTP 파싱이나 이미지 리시아징등의 연산이 이 서버에서 일어납니다. 이 연산들은 CPU 가 가장 중요한 리소스이기 때문에, c1.xlarge를 사용하기로 했습니다.Database 서버: HDFS 데이터 노드와 HBase 리전 서버들이 떠있습니다. 여러 번의 테스트를 통해 IO가 병목임을 확인하였고, 따라서 모든 데이터를 최대한 메모리에 올리는 것이 가장 저렴한 설정이라는 것을 확인하였습니다. 이런 이유 때문에 68.4GB의 메모리를 가진 m2.4xlarge를 Database 서버로 사용하고 있습니다.EBS: 처음에는 HBase상 데이터를 모두 EBS에 저장하였습니다. 하지만 일정 시간 동안 EBS의 Latency가 갑자기 증가하는 등의 불안정한 경우가 자주 발생하여 개선 방법이 필요했는데, 데이터를 ephemeral storage에만 저장하기에는 안정성이 확인되지 않은 상태였습니다. 위의 두 가지 문제를 동시에 해결하기 위해서 HDFS multiple-rack 설정을 통해서 두 개의 복제본은 ephemeral storage에 저장하고 다른 하나의 복제본은 PIOPS EBS에 저장되도록 구성하여 EBS의 문제점들로부터의 영향을 최소화하였습니다.S3: 사용자들이 올리는 사진들은 s3에 저장됩니다. 사진의 s3키는 추측이 불가능하도록 랜덤하게 만들어집니다. 어차피 하나의 사진은 두 명밖에 받아가지 않고 클라이언트 로컬에 캐싱되기 때문에 CloudFront를 사용하지는 않습니다.ELB: HTTP는 사용자 요청의 분산과 SSL적용을 위해 ELB를 사용합니다. TCP는 TLS를 위해 ELB를 사용합니다. SSL/TLS 부분은 모두 AWS의 ELB를 이용하는데, 이는 API서버의 SSL/TLS처리에 대한 부담을 덜어주기 위함입니다.CloudWatch: 각 통신사와 리전에서 비트윈 서버로의 네트워크 상태와 서버 내의 요청 처리 시간 등의 메트릭을 CloudWatch로 모니터링 하고 있습니다. 따라서 네트워크 상태나 서버에 문제가 생긴 경우, 이메일 등을 통해 즉각 알게 되어, 문제 상황에 바로 대응하고 있습니다. Netflix의 Servo를 이용하여 모니터링 됩니다.현재의 아키텍처처음 클로즈드 베타 테스트때에는 사용자 수가 정해져 있었기 때문에 하나의 인스턴스로 운영되었습니다. 하지만 처음부터 인스턴스 숫자를 늘리는 것만으로도 서비스 규모를 쉽게 확장할 수 있는 아키텍쳐를 만들기 위한 고민을 하였습니다. 오픈 베타 이후에는 발생하는 트래픽에 필요한 만큼 여러 대의 유연하게 서버를 운영하였고, 현재 채팅은 TCP 위에서 구현한 프로토콜을 이용하여 서비스하고 있습니다.HTTP 요청은 하나의 ELB를 통해 여러 서버로 분산됩니다. 일반적인 ELB+HTTP 아키텍처와 동일합니다.채팅은 TCP 연결을 맺게 되는데, 각 커플은 특정 API 서버로 샤딩되어 특정 커플에 대한 요청을 하나의 서버가 담당합니다. 비트윈에서는 커플이 샤딩의 단위가 됩니다.이를 통해, 채팅 대화 내용 입력 중인지 여부와 같이 굉장히 빈번하게 값이 바뀌는 정보를 인메모리 캐싱할 수 있게 됩니다. 이런 정보는 휘발성이고 매우 자주 바뀌는 정보이므로, HBase에 저장하는 것은 매우 비효율적입니다.Consistent Hashing을 이용하여 커플을 각 서버에 샤딩합니다. 이는 서버가 추가되거나 줄어들 때, 리밸런싱되면서 서버간 이동되는 커플들의 수를 최소화 하기 위함입니다.클라이언트는 샤딩 정보를 바탕으로 특정 서버로 TCP연결을 맺게 되는데, 이를 위해 각 서버에 ELB가 하나씩 붙습니다. 어떤 서버로 연결을 맺어야 할지는 HTTP 혹은 TCP 프로토콜을 통해 알게 됩니다.Consistent Hashing을 위한 정보는 ZooKeeper를 통해 여러 서버간 공유됩니다. 이를 통해 서버의 수가 늘어나거나 줄어들게 되는 경우, 각 서버는 자신이 담당해야 하는 샤딩에 대한 변경 정보에 대해 즉각 알게 됩니다.이런 아키텍처의 단점은 다음과 같습니다.클라이언트가 자신이 어떤 서버로 붙어야 하는지 알아야 하기 때문에 프로토콜 및 아키텍처 복잡성이 높습니다.서버가 늘어나는 경우, 순식간에 많은 사용자 연결이 맺어지게 됩니다. 따라서 새로 추가되는 ELB는 Warm-up이 필요로 하며 이 때문에 Auto-Scale이 쉽지 않습니다.HBase에 Write연산시, 여러 서버로 복제가 일어나기 때문에, HA을 위한 Multi-AZ 구성을 하기가 어렵습니다.한정된 자원으로 동작 가능한 서버를 빨리 만들어내기 위해 이처럼 디자인하였습니다.미래의 아키텍처현재 아키텍처에 단점을 보완하기 위한 해결 방법을 생각해보았습니다.Haeinsa는 HBase상에서 트렌젝션을 제공하기 위해 개발 중인 프로젝트입니다. 구현 완료 후, 기능 테스트를 통과하였고, 퍼포먼스 테스트를 진행하고 있습니다. HBase상에서 트렌젝션이 가능하게 되면, 좀 더 복잡한 기능들을 빠르게 개발할 수 있습니다. 서비스에 곧 적용될 예정입니다.Multitier Architecture를 통해 클라이언트와 서버 간에 프로토콜을 단순화시킬 수 있습니다. 이 부분은 개발 초기부터 생각하던 부분인데, 그동안 개발을 하지 못하고 있다가, 지금은 구현을 시작하고 있습니다. 커플은 특정 Application 서버에서 담당하게 되므로, 인메모리 캐싱이 가능하게 됩니다. 클라이언트는 무조건 하나의 ELB만 바라보고 요청을 보내게 되고, Presentation 서버가 사용자 요청을 올바른 Application 서버로 릴레이 하게 됩니다.Multitier Architecture를 도입하면, 더 이상 ELB Warm-up이 필요하지 않게 되므로, Auto-Scale이 가능하게 되며, 좀 더 쉬운 배포가 가능하게 됩니다.Rocky는 API 서버의 Auto-Failover와 커플에 대한 샤딩을 직접 처리하는 기능을 가진 프로젝트입니다. 현재 설계가 어느 정도 진행되어 개발 중에 있습니다. 알람이 왔을 때 서버 팀이 마음을 놓고 편히 잠을 잘 수 있는 역할을 합니다.기본적인 것은 위에서 언급한 구조와 동일하지만 몇 가지 기능이 설정을 추가하면 Multi-AZ 구성이 가능합니다.특정 커플에 대한 모든 정보는 하나의 HBase Row에 담기게 됩니다.HBase의 특정 리전에 문제가 생긴 경우, 일정 시간이 지나면 자동으로 복구되긴 하지만 잠시 동안 시스템 전체에 문제가 생기가 됩니다. 이에 대해 Pinterest에서 Clustering보다는 Sharding이 더 낫다는 글을 쓰기도 했습니다. 이에 대한 해결책은 다음과 같습니다.원래는 Consistent Hashing을 사용하여 커플들을 Application 서버에 샤딩하였습니다. 하지만 이제는 HBase에서 Row를 각 리전에 수동으로 할당하고, 같은 리전에 할당된 Row에 저장된 커플들은 같은 Application 서버에 할당하도록 합니다.이 경우에, 같은 커플들을 담당하는 Application 서버와 HBase 리전 서버는 물리적으로 같은 머신에 둡니다.이렇게 구성 하는 경우, 특정 HBase 리전이나 Application 서버에 대한 장애는 특정 샤드에 국한되게 됩니다. 이와 같이 하나의 머신에 APP과 DB를 같이 두는 구성은 구글에서도 사용하는 방법입니다.이와 같이 구성하는 경우, Multi-AZ 구성이 가능하게 됩니다.AWS에서 같은 리전에서 서로 다른 Zone간 통신은 대략 2~3ms 정도 걸린다고 합니다.Presentation의 경우, 비동기식으로 동작하기 때문에 다른 리전으로 요청을 보내도 부담이 되지 않습니다.HBase에서 Write가 일어나면 여러 복제본을 만들게 됩니다. 하나의 사용자 요청에 대해 Write가 여러번 일어나기 때문에 HBase연산의 경우에는 서로 다른 Zone간 Latency가 부담으로 작용됩니다. Haeinsa가 적용되면, 한 트렌젝션에 대해서 연산을 Batch로 전송하기 때문에 AZ간 Latency 부담이 적습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!
조회수 1724

Mong 3.0과 프론트엔드개발자 쿤!, 반응형 웹에 도전하다!!

안녕하세요 크몽 개발팀입니다.작년 12월 크몽파티때 기억나시나요? 프론트엔드개발자인 저 쿤이 그날 반응형웹을 1~2월달까지 시전하겠다! 라고 호언장담했었는데요.. 저도 그때당시에는 무조건 해보자라는 생각으로 얘길했던건데.. 팀원들의 반응이...이랬었더랬죠... 그때의 저의 심정은 가슴이 바운스바운스 두근대~... 넵 그랬었습니다...하지만!!! 1월달에 잠시했던 공부와 2월달에 잠시얻은 잉여로움을 발판삼아 전부는 아니지만 메인페이지만 해내었습니다. 처음의 도전은 험난하디 험난했습니다.여러 문서들을 보던가운데 반응형웹을 잘 소화하고 계시는 기업블로그의 포스팅을보게 되었는데요..출처: S사 기업블로그한마디로 이해가 쏙쏙되는 포스팅이었습니다.여기에 감명받은 저 쿤은 바로 연습에 들어갔더랬죠..하지만.. 각각 디바이스에대해 설정값을 넣어줘야하는반응형 웹은 쉽게 다가갈 수 없는 미저리같은 그런 녀석이었습니다아..그래도.. 다시 심기일전하는 마음으로 처음부터 모크업을 진행을 하였답니다. 처음 모크업은 이러하였어요...메인화면 소개를 거치면 짠하고 크몽홈페이지가뜨는!!!!그런 이미지였답니다. 하지만 여러분들도 알다시피 계획한일들이 안될경우도 있잖아유....저도 그러하였어요..물론 처음시작할때에만 하더라두 이것들을 다끝내겠어란활활 불타오르는 열정으로 시작했었죠!!처음작업을해서 뽑아낸 아이들의 사진이에요. 상단바를 각 디바이스크기에 맞게 하는 작업을 먼저 했었는데요..이 녀석이 은근 골치 아픈 녀석이었답니다.각 위치마다 고정폭이 정해져있어고 그녀석들을 반응형에 맞출려고 얼마나 고생했는지.. 가뜩이나 수학도 못하는데 퍼센트 계산만 했엇답니다.. 저에게 퍼센트도 이러했답니다.. 하.....수학공부를 열심히해야겠어요..그래도 꿋꿋이 계산하고 넣어보고 계산하고 넣어보고 계산하고 넣어보고 즐기고~그러다 보니 점점 하나하나씩 되기 시작했어요!!머리는 점점 잘 돌아가고 재능목록들이 자기자리로 돌아가고!!!!노력의 기적이 어떤것인지 보았습니다.. 이리하여 결국에는..이러한 결과를 낳았더랬죠!! 실은 작업한지 꽤나됬고 릴리즈된지도 꽤나되었지만..아마두.. 모르시는 분들이 많을거에요지금 여러분들이 가지고 계신 폰으로 크몽의 반응형메인을 만나실 수 있답니다~!!한번 보시고 따끔한 충고를 답글에 남겨주세요. 따끔하게 맞고 고칠 수 있는부분은 한번씩 잉여로울때 작업을 하도록하겠습니다. -----------------------------------------------------------------------그럼 지금부터는..제가 이번작업을 하면서 느꼇던 몇가지를 적어볼까합니다.바로바로바로 당신이 반응형웹을 하고싶다면!!  따단!!그 첫번째 규칙!! 절대 고정폭을 주지말아라-이것이 반응형웹할때는 가장 중요한 거십니다.반응형웹이라도 픽셀은 PC와 노트북에서 여러분의 눈에 보이는것과 마찬가지로 적용된다는점!!!만약에 고정폭으로 1200px를 주게되었다면 데스크탑이나 노트북에서는 보기좋게 보이지만모바일환경에서는 엄청확대되어보인다는 사실 아셨나요??! 그럼 "고정폭대신 CSS에 뭘 줘야되는건가요?"라고 묻는 당신께 퍼센트(%)를 바칩니다.. CSS에 픽셀(px)대신 퍼센트(%)를 넣으면 여러분이 브라우저크기를 낮출때마다화면이 가변적으로 늘어난답니다. 물론 퍼센트는 백분율이라 화면의 크기에 맞게크기를 지정해주면 된답니다.그 두번째 규칙!! 미디어쿼리를 활용하랏!!!-미디어쿼리... 과연 그거슨 무엇인것인가!!!쉽게 설명해드리겠습니다. 미디어쿼리란 여러분의 브라우저크기를 컴퓨터가 인식해그 크기에맡게 보여주는 그런 녀석입니다.여러분들이 딱히 할게 별거없어요..그냥 미디어쿼리를 CSS에 설정해주고 그 크기에맡게 어떻게 보여줄것인가에 대해작성해주시면 되는겁니다. 참 쉽죠오?? 으앗!!음.. 일단 자세한 내용은 저의 스승블로그의 포스팅을 보시면 쉬울거에요..http://readme.skplanet.com/?p=9739#s5반응형 웹 기술 이해 | READMEreadme.skplanet.com그 세번째 규칙!! 같은줄에 있는 컨텐츠가 다들어가기엔 모바일화면이 너무작다면 밑으로 내리여!!!-분명 여러분들의 홈페이지를 작업할때에 보면 PC사항에서 잘 자리잡혀 있던것이 모바일환경에선 왠지 좁아 터질 것같다라고생각이 드실수 있습니다. 그렇다면.. 밑쪽으로 내리는 것을 저는 추우천을 드립니다!!그렇담 그 컨텐츠가 내려간다면 배치는 어떻게 해야 이쁜가에대한 저의 답변은 "그건 디자이너님 너의 맘이야 God bless you"입니다. 그 네번째 규칙!! 부트스트랩 같은 녀석들을 사용하랏~!!!!-아마 직접 CSS와 js를 조작하라고해도 못하시는 분들이 있으실거에요..그런분들을 위해 태나났습니다아~!!!! 바로바로바로 부트스트랩과같은 것들인데요.이 녀석들은 자기들이 설정해놓은 CSS집단인 컴포넌트로 웹개발자들을위협(?)하는 그런 녀석이랍니다.이 뇬석들을 사용하면 반응형웹이고뭐고 멋진표던뭐던 다 뚝딱뚝딱 만들어내죠..저도 애용하고있는 아이들이랍니다.(실은.. 상단바작업은 제가 CSS로했고 컨텐츠들은 부트스트랩이란 도구로 작업을 하였는데요.. 그시간차이가 우와 할정도에요..)그 정도로 좋은 녀석이랍니다. 그 녀석을 찾으실려면 구글검색창에 "부트스트랩"이라고 쳐보세요.CSS무지식개발자라도 쓰실수있게 패키지가 구성되어있답니다. 아무 클래스나 골라담아요 골라담아~!!-----------------------------------------------------------------------음음.. 뭐 별거없었지만 제가 올린 포스팅글 잘보셨는지 궁금하네요..꼭 반응형웹에 도전하시는 분들이 봤을때 좋은 내용이었으면 좋겠다는 작은 바램이 생기네요그럼 저는 크몽에서 프론트엔드 개발자를 맡고있는 Kun이었구요.다음번에 더 좋은 포스팅으로 만나뵈요. 제발~#크몽 #개발자 #개발팀 #팀원소개 #인사이트 #스택도입 #일지
조회수 2155

프로세스 마이닝과 AI를 통한 프로세스 혁신

지난해 이세돌과 알파고의 대결 이후에 인공 지능 (AI)과 기계 학습은 국내에서 많은 대중들의 관심을 얻어 중요한 추진력을 얻었으며, 모든 산업 분야의 기업들이 해당 기술을 빠른 속도로 계속 적용하여 사용하는 비중이 더욱 높아졌습니다. 실제로 Gartner는 2022년까지 스마트 머신과 로봇이 고학년 전문직 분야를 대체할 수 있을 것으로 내다봤으며, 심지어는 인공지능이 경영자 CEO도 대체 가능할 것인지에 대한 논의도 일어나고 있습니다. 이것은 사람이 과거 경험에 의해서 의사 결정을 내리 듯이 인공 지능도 확보한 데이터를 기반으로 의사 결정 모델을 만들 수 있다는 유사성에 기반합니다.  인공 지능에 의한 의사 결정은 사람한테 종종 있을 수 있는 감정이나 개인적 이해관계 및 관례에 의해 불합리한 판단에서 벗어나 데이터의 의한 객관적 판단을 할 수 있다는 장점이 있습니다.여기서 중요한 것은 인공지능이 학습하기 위한 “데이터”입니다.  지금까지 머신러닝이 막대한 이미지, 음성, 영상 데이터를 축적한 후 해당 데이터의 특징을 추출하여 패턴을 학습하여 자연어 처리 등을 통해 사람처럼 인식하여 분류하거나 상황을 판단하였듯이 기업 내 여러 가지 업무 활동에 머신 러닝을 적용하기 위해서는 이와 마찬가지로 관련 데이터가 필요합니다.제조 분야의 공정 관리, 공공 서비스, 물류 공급망 관리 등 전통적인 기업 내 업무 프로세스는 인공 지능에 의한 자동화과 효율화를 통해 혁신이 필요한 분야입니다. 기존에 외부 협력 업체로부터의 납기 예측, 소요되는 자재 인력 등 리소스 산정, 생산 스케줄, 장비 파라미터 입력값 등은 사람에 의해 수작업으로 진행 시 몇 주에서 수개월 소요되었지만, 인공 지능과 기계 학습 기반의 솔루션 도움으로 정확하게 지속적인 추세를 인식하고 인간의 개입 없이 데이터 중심의 결정이 가능해집니다.지금까지 기업 내 축적된 엄청난 양의 데이터를 활용하여 여러 산업 분야에서 숨겨진 패턴과 상관관계, 이상 징후 및 불량 탐지, 고객 수요 예측 등이 시도되었습니다. 하지만 이러한 시도들은 기업 내 문제 요인을 파악하여 우선적으로 어떤 부분에 초점을 맞추어 개선을 해야 하는지 알아야 하므로, 기업 경영 활동 전반에 걸쳐 돌아가는 판세를 읽는 노력이 필요합니다. 하지만, 기업 내에서 이뤄지고 있는 프로세스는 충분히 복잡하여, 개별 단위 작업의 전문가들은 존재하겠지만, 각 개별 부서, 구성원, 시스템 간에서 발생하는 다양한 상호작용과 이에 따른 예외 상황이 존재하여 이를 파악하기가 쉽지 않습니다.프로세스 마이닝은 데이터 기반의 프로세스 분석을 통해 문제 부분을 파악하여, 실제 인공 지능이나 머신 러닝을 적용하여 개선할 부분을 찾을 수 있도록 도와줍니다. 그리고, 프로세스 개선을 위해 머신러닝을 적용하기 위해서는 앞서 말한 것처럼 “데이터”가 학습될 수 있는 형태의 기반을 제공합니다.아래 그림과 같이 이벤트 로그를 기반으로 프로세스 모델을 생성하고, 수집된 패턴들과 각 분기 단계에서의 주요 성과 지표들을 디지털화하여 인공지능이 이해할 수 있는 형태로 축적합니다 이렇게 축적된 프로세스 패턴 데이터를 가지고 알파고가 최적화된 다음의 한 수를 예측하듯이 프로세스 마이닝은 인공 지능 기술과 결합하여 과거 프로세스에 대한 이해뿐만 아니라, 현재 시점에서 앞으로의 프로세스를 예측하여 합리적인 의사 결정을 도와줄 것입니다.#퍼즐데이터 #개발팀 #개발자 #개발후기 #인사이트
조회수 2635

8퍼센트 Test case 작성 가이드

8퍼센트에서 Python Django 코드에 대한 Test case 작성시 사용하는 가이드를 공유해보려고 합니다.클래스명일반적으로 TestCase 를 상속 받는 클래스일 경우 class 명의 마지막에 TestCase 를 붙입니다.예제: SimpleTestCase(TestCase)함수명테스트 함수명의 경우 test_ 로만 시작하면 동작하는데 문제가 없고 테스트 코드에까지 주석을 다는 것은 번거로우므로 함수명의 test_ 뒷부분을 한글로 하여 설명을 대신하도록 합니다.class IUPaginationMethodTestCase(TestCase): @classmethod def setUpTestData(cls): cls.request = Mock() cls.request.GET = {'page': 1, 'items_per_page': 1} cls.pagination = IUPagination(cls.request) def test_page_url_기본(self): expected = '?{}=1'.format(self.pagination.page_key) self.assertEqual(self.pagination.page_url(), expected) def test_page_url_쿼리스트링_없는경우_물음표_붙인다(self): expected = '/?{}=1'.format(self.pagination.page_key) self.pagination.url_prefix = '/' self.assertEqual(self.pagination.page_url(), expected) def test_page_url_쿼리스트링_있는경우_엠퍼센드로_붙인다(self): expected = '{}&{}=1'.format( self.pagination.url_prefix, self.pagination.page_key )) self.pagination.url_prefix = '?utm=source' self.assertEqual(self.pagination.page_url(), expected) factory_boyfixture 를 대신해서 가급적 factory_boy 를 사용합니다.signals 끄기factory boy로 모델 객체 생성시 signal 이 호출되는데 signal에 대한 테스트가 아니라면 대부분 실행할 필요가 없습니다.이 때 factory.django.mute_signals를 사용해서 끄면 됩니다.decorator, context manager 둘 다 사용 가능합니다.decorator@mute_signals(signals.post_save) def test_some_code(self): some = SomeFactory() context managerwith mute_signals(signals.post_save): some = SomeFactory() 참고 링크factory_boyDisabling signalssetUpTestData vs setUpfixture를 사용하면 fixture로 정의한 모델 객체가 모든 테스트 시작 전에 생성이 되는데 유사하게 setUp 에서 factory 생성을 하게 되면 매번 객체 생성을 하게 되므로 느립니다.테스트에서 read only 로만 사용하는 객체의 경우 class method인 setUpTestData 에서 생성하면 1번만 생성이 되므로 빨라집니다.가급적 setUp 에서 매번 객체를 생성하는 것을 지양하고 테스트 함수 내에서 필요한 객체만 생성하는 것이 효율적이고 빠릅니다.method mock메소드를 mock 하는 경우 unittest.mock.patch() 를 사용합니다.decorator보통 테스트 메소드에 대한 decorator 로 사용합니다.직접 호출class 내의 여러 테스트 메소드 혹은 모든 테스트 메소드에서 동일한 함수를 mock 하는 경우에는 start, stop 을 활용하면 편합니다.예제 코드from unittest import mock class MyTest(TestCase): def setUp(self): self.mock_method1 = mock.patch('package.module.method1').start() self.mock_method1 = mock.patch('package.module.method2').start() def tearDown(self): mock.patch.stopall() def test_something(self): something() self.assertTrue(self.mock_method1.called) 참고 링크: patch methods start and stoptimezonedatetime.datetime.now() datetime.datetime.strptime() 등을 사용해서 naive datetime 객체를 django 모델의 DateTimeField 에 할당할 필요가 있는 경우 반드시 django.utils.timezone.make_aware() 를 사용해서 time-zone-aware datetime 객체로 변환한 후에 합니다.참고 링크: Django timezone 문제 파헤치기freezegun특정 시점에서의 테스트가 필요한 경우 freezegun 을 사용해서 현재 시간값을 고정합니다.가급적 decorator 나 context manager 를 사용해서 특정 클래스나 메소드, 혹은 코드 블럭에만 적용하도록 하는 것이 좋습니다.decorator 예제from freezegun import freeze_time import datetime import unittest @freeze_time("2012-01-14") def test(): assert datetime.datetime.now() == datetime.datetime(2012, 1, 14) context manager 예제from freezegun import freeze_time def test(): assert datetime.datetime.now() != datetime.datetime(2012, 1, 14) with freeze_time("2012-01-14"): assert datetime.datetime.now() == datetime.datetime(2012, 1, 14) assert datetime.datetime.now() != datetime.datetime(2012, 1, 14) 특정 테스트 케이스 전체에 적용을 하기 위해 start(), stop() 메소드를 사용하기도 하는데 이 경우 반드시 stop() 을 해주어야 다른 테스트 케이스의 시간 값에 영향을 주지 않습니다.예제from django.test import TestCase from freezegun import freeze_time class SomeTestCase(TestCase): def setUp(self): self.freezer = freeze_time("2016-01-05 00:00:00") self.freezer.start() def tearDown(self): self.freezer.stop() 참고 링크: freezegun맺음말Python Django 개발시 Test case 작성을 잘 하기 위한 8퍼센트 개발팀의 가이드를 공유해 보았습니다. Python Django 개발자들이 Test case 작성을 효율적으로 잘 해서 서비스의 안정성을 높이는데 도움이 되기를 기대해 봅니다.#8퍼센트 #에잇퍼센트 #Django #Python #장고 #파이썬 #개발 #개발자 #가이드 #꿀팁 #인사이트
조회수 1300

Android Wear 개발하기 - VCNC Engineering Blog

비트윈 팀은 지난달 비트윈에 Android Wear 앱 기능을 릴리즈했습니다. 즐거운 개발 경험이었지만, 힘들었던 점도 많았습니다. 어떤 과정을 통해서 개발하게 되었고, 내부 구조는 어떻게 되어 있는지, 신경 쓰거나 조심해야 할 점은 어떤 것들이 있는지 저희의 경험을 공유해보려고 합니다. 이 글을 통해 Android Wear 앱 제작을 고민하는 개발자나 팀이 더 나은 선택을 하는 데 도움이 되고자 합니다.Android Wear에 대해Android Wear는 최근 발표된 구글의 새 웨어러블 플랫폼입니다. 공개된 지 얼마 되지 않았음에도 불구하고 완성도 있는 디바이스들이 출시된 상태이며, 기존의 웨어러블 기기보다 기능과 가격이 매력 있다는 평가를 받고 있습니다. 또한, 2014 Google I/O에서 크게 소개되고 시계를 참가자들에게 나눠주는 등, 구글에서 강하게 밀어주고 있기 때문에 상당히 기대되는 플랫폼입니다.Android Wear의 알림 기능은 연결된 mobile1 기기와 연동됩니다. 예를 들어 메시지를 받았을 때 mobile과 wear에서 모두 알림을 받아볼 수 있고, Google Now와 연동하여 교통, 날씨 등 상황에 맞는 알림을 제공합니다.또, 여러 가지 앱들의 다양한 기능을 음성으로 제어하도록 하여 사용자에게 기존의 시계와는 완전히 다른 경험을 주고 있습니다.한국에서는 Google Play Store의 기기 섹션에서 구매가 가능합니다.Android Wear 개발하기Android Wear는 Android 플랫폼을 거의 그대로 사용하기 때문에, Android 개발 경험이 있는 개발자라면 아주 쉽게 개발을 시작할 수 있습니다. 비트윈에서는 구글의 80:20 프로젝트를 패러디한 100+20 프로젝트를 통해 개발을 진행하게 되었습니다. (하던 일을 다 해내면서 시간을 내어 진행한다는 의미로 100+20 프로젝트입니다. 하지만 가끔은 '20' 부분에 너무 몰입하여 0+20이 되기도 한다는 게 함정입니다...)Activity, Service 등 Android의 기본 component들을 모두 그대로 사용 가능하며, 손목에 찰 수 있는 크기의 화면에서 유용하게 사용할 수 있는 WearableListView, GridViewPager 같은 새 widget들이 추가되었습니다. 구글 개발자 사이트의 wearable training 섹션에서 자세한 안내를 볼 수 있습니다.비트윈의 아이디어비트윈 Android Wear 기능의 컨셉은, 항상 몸에 착용하는 Wear의 특징을 살려, '커플이 떨어져 있더라도, 항상 함께 있는 느낌을 주기' 였습니다. 그래서 아래와 같은 기능들이 기획되었습니다.Feel His/Her Heart (그대의 심장박동 느끼기): 상대방의 심장박동을 진동으로 재현해주기Where He/She Is (그/그녀는 어느 방향에 있을까?): 상대방의 위치를 나침반과 같은 형태로 보여주기 (안심하세요. 여러분. 방향만 알려주고 정확한 위치는 알려주지 않습니다!)Feel Memories (메모리박스): 언제든 추억을 떠올릴 수 있도록 비트윈의 기존 기능인 메모리박스(추억상자)를 Android Wear에서 구현하지만 이 아이디어들은 하루 만에 망하게 됩니다.메인 아이디어였던 심장박동 느끼기는 사용자가 요청하면 상대방의 시계에서 심장박동이 측정되어 사용자에게 상대방의 심장박동을 진동으로 재현해주는 멋진 기능이었습니다. 하지만 이 아이디어를 낼 때 심박센서가 탑재된 Android Wear 기기가 없었던 게 함정이었습니다.다음날 Android Wear Bootcamp에 참가하여 심박센서가 작동하는 삼성 Gear Live 기기를 사용해 볼 수 있었습니다. 결과는 충격이었습니다. 생각과는 달리 심박박동 측정 결과가 나오는데 10~20초가 걸리고, 그나마도 측정되는 동안은 올바른 위치에 시계를 차고 가만히 있어야 했습니다. 결국, 이러한 제약 때문에 사용자들이 실제로 유용하게 사용할 수 있는 기능이 될 수 없었습니다.그래서 계획을 수정하여 현실적으로 구현 가능한 기능들을 먼저 만들어 보기로 했습니다.목소리로 답변하기: 상대방에게 온 메시지에 Android Wear Framework에서 제공하는 음성인식을 이용하여 목소리를 텍스트로 바꾸어서 답장하기이모티콘 답변하기: 이모티콘을 사용자가 선택하여 이모티콘으로 답장하기비트윈 메모리박스: 비트윈의 기존 기능인 메모리박스(추억상자)를 Android Wear에서 구현처음의 원대한 계획에서 뭔가 많이 변경된 것 같지만, 기분 탓일 겁니다.내부 구현비트윈 Android Wear 앱은 크게 두 가지 기능을 가지고 있습니다. 하나는 상대방에게 메시지를 받았을 때, 메시지 내용을 확인하고 여러 가지 형태로 답장할 수 있는 Notification 기능이고, 다른 하나는 Wear에서 원래 Application의 일부 기능을 시작 메뉴를 통하거나 목소리로 실행시킬 수 있게 해주는 Micro App입니다. 해당 기능들의 스크린샷과 함께 내부 구조를 설명하겠습니다.우선 Notification 부분입니다. 앱 개발사에서 아무 작업도 하지 않더라도, 기본적으로 Android Wear Framework이 스크린샷 윗줄 첫 번째, 네 번째 화면과 같이 예쁜 알림화면과 Open on phone 버튼을 만들어 줍니다. 여기에 추가적인 기능을 붙이기 위하여 WearableExtender를 이용하여 목소리로 답장하기, 이모티콘 보내기 버튼을 덧붙였습니다.비트윈 Android Wear 스크린샷 - Notification둘째로는 Micro App 부분입니다. 여기에는 이모티콘 전송과 메모리박스를 넣었습니다. 이 부분은 일반적인 Android 앱을 만들듯이 작업할 수 있습니다비트윈 Android Wear 스크린샷 - Micro App화면을 보면 무척 단순해 보이지만 내부 구조는 간단하지가 않습니다. 연결된 화면들을 만들어내는 코드가 한곳에 모여있지 않고, 각기 다른 곳에 있는 코드들을 연결하여야 하기 때문입니다. Notification 하나를 만들 때에 Framework에서 만들어주는 1, 4번째 화면, Notification에 WearableExtender를 이용하여 덧붙이는 2, 3번째 화면, 그리고 다시 Framework에서 만들어주는 목소리로 답장하기 화면, 그리고 Wear 쪽의 Micro App을 통해 구동되는 이모티콘 선택 화면과 같이 여러 군데에 나누어 존재하는 코드가 연결됩니다.하나의 앱처럼 느껴지는 화면이지만 각각 다른 곳에 코드가 쓰여있습니다.그러면 이번에는 각 화면이 어떻게 연결되는지 알아보겠습니다.사용자가 상대방으로부터 받은 메시지를 Android Wear의 Notification으로 확인하고, 답장으로 이모티콘을 보내고자 하는 상황을 가정해 봅시다. 사용자가 Send Emoticon 버튼을 눌렀을 때 이모티콘 선택화면을 보여주고 싶은데, 이 행동에 대한 pending intent를 wear 쪽의 micro app이 아닌, mobile 쪽에서 받게 되어 있습니다. 이 때문에 아래의 표와 같이 mobile 쪽에서 pending intent를 받은 뒤 다시 wear 쪽으로 이모티콘 선택 화면을 보여주라는 메시지를 전송해줘야 합니다.이모티콘 전송 과정이번에는 메모리박스를 보겠습니다. 메모리박스도 단순한 화면이지만 mobile 쪽과 통신하여 내용을 불러와야 하므로 생각보다 해야 하는 일이 많습니다. Android Wear Message API와 Data API를 이용하여 데이터를 주고받아 사진을 화면에 보여줍니다.메모리박스를 보여주는 과정개발 시 신경 써야 하는 점개발하면서 주의 깊게 신경 써야 하는 점들이 있습니다.첫 번째로 코드 퀄리티입니다.Android Wear는 아직 성숙하지 않은 플랫폼이기 때문에 많은 사람이 받아들인 정형화된 패턴이 없습니다. 앞서 살펴보았듯이, 간단한 기능을 구현하려고 해도 상당히 복잡한 구조를 가진 앱을 만들게 되기에, 코드 퀄리티를 높게 유지하기 어려웠습니다비트윈 팀에서는 EventBus를 활용하여 코드를 깔끔하게 유지하려고 노력하였습니다. 이러한 문제를 해결할 수 있는 Guava의 Concurrent 패키지나, RxJava 등의 도구들이 있으니 익숙한 도구를 선택하여 진행하는 것을 추천합니다. 또한, 구글의 Android Wear 코드랩 튜토리얼의 내용이 매우 좋으니, 한번 처음부터 수행해 보면 좋은 코드를 만들 수 있는 아이디어가 많이 나올 것입니다.두 번째로는 원형 디바이스 지원 및 에러 처리입니다.처음부터 원형 디바이스를 신경 쓰지 않으면 마무리 작업 시 상당한 고통을 받게 됩니다. 원형 디바이스에 대한 대응법은 Android 개발자 트레이닝 사이트의 wearable layout 섹션에 자세히 나와 있습니다. 현재는 원형 디바이스를 처리하는 프레임웍에 약간 버그가 있지만, 곧 수정될 것으로 생각합니다.사용자 입력이 있을 때, 그리고 에러가 났을 때 적절하게 처리해주는 것은 제품의 완성도에 있어 중요한 부분입니다. Android Wear Framework에서 제공하는 ConfirmationActivity등을 활용하여 처리하면 됩니다.마지막으로 패키징입니다.자동 설치 패키징은 비트윈 팀에서도 가장 고생했던 부분입니다. Android Wear는 본체 앱을 설치하면 자동으로 함께 설치되는데, 앱이 정상작동하기 위해서는 몇 가지 까다로운 조건이 있습니다.build.gradle 의 applicationId 를 wear와 mobile 양쪽 모두 똑같이 맞춰야 합니다.Wear app의 AndroidManifest에 새롭게 선언한 permission이 있다면 mobile 쪽에도 포함해 주어야 합니다.기본적으로, 똑같은 key로 서명합니다. 다른 key로 sign 하는 경우는 문서를 참고해서 신경 써서 합니다.위 항목들은 아주 중요한 내용이지만 아직 문서화가 완벽하지 않으니 주의 깊게 진행해야 합니다.후기개발 과정에서 여러 가지 어려움이 있었지만, 무척 즐거웠던 프로젝트였습니다!우선 새로운 플랫폼에서 새로운 제품의 아이디어를 내고 만들어내는 과정이 많은 영감과 즐거움을 주었습니다.두 번째로는 Android Wear를 포함한 버전 출시 이후 구글플레이의 Android Wear 섹션 및 추천 앱 섹션에 올라가게 되어 홍보 효과도 얻을 수 있었습니다. 또한, 구글의 신기술을 적극적으로 사용하고자 하는 팀에게는 구글 쪽에서도 많은 지원을 해주기 때문에 도움도 많이 받았습니다.세 번째로는 기존의 Android 개발과 비슷하여 접근하기 쉬우면서도, 원하는 것을 구현하려면 상당히 도전적이어서 재미있었습니다.다만 조심해야 할 점은, 구글에서 적극적으로 밀고 있는 프로젝트라고 해서 다 성공하는 것은 아니라는 점입니다. 얼마만큼의 시간과 자원을 투자할지는 신중하게 생각하면 좋겠습니다.정리Android Wear는 새로운 기술과 플랫폼에 관심이 많은 개발자, 혹은 팀이라면 시간을 투자해서 해볼 만한 재미있는 프로젝트입니다. 하지만 완성도 있는 좋은 제품을 만들기 위해서는 생각보다 할 일이 많으니 이를 신중하게 고려하여 결정해야 합니다.끝으로 2014 GDG Korea Android Conference에서 같은 주제로 발표하였던 슬라이드를 첨부합니다.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/a1415af04644013234cf7a3f7c519e69?" 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;">구글의 튜토리얼 등에서 지칭하는 것과 마찬가지로, 이 글에서도 Android Wear와 연결된 휴대폰을 mobile이라 하겠습니다.↩
조회수 1846

덕질도 신박하게! R을 활용한 텍스트 마이닝 도전기

Overview대학원에서 소프트웨어 공학을 전공하고 있습니다. 이번 학기엔 ‘빅데이터 분석’ 과 ‘대용량데이터베이스관리론’ 과목을 수강하면서 생애 처음으로 R Studio 프로그램을 설치해봤는데요. 머신 러닝을 다뤄본 적도, 자연언어처리 분야를 개발한 적도 없지만 어느 날 텍스트 마이닝 관련 강의에서 불현듯 이런 생각이 떠올랐습니다. “내가 좋아하는 가수로 텍스트 마이닝을 하면 어떤 결과가 나올까?”머릿속으로 생각하는 것과 내가 직접 구현을 해보는 것은 절대 다른 법! 일단 도전해보기로 했습니다. 개발 3년과 덕질 10년의 실력을 쏟아 부을 겁니다.지금까지 예쁜 디자인이라고만 알고 있었던 WordCloudStep1. 트위터 Developer 에서 인증키 받기트위터 Developer (Twitter Developer Platform — Twitter Developers) 에 접속해서 개인 계정으로 로그인하고, 오른쪽 위의 Apply를 클릭합니다.Twitter standard APIs > Get started with standard access를 클릭합니다.등록된 개발자 앱이 없으면 Create an app의 apps.twitter.com을 클릭합니다.Create New App을 클릭합니다.각 항목을 입력합니다. 저는 Website 가 없기 때문에 로컬 호스트를 기재했습니다.약관에 동의한 후 Create your Twitter application을 클릭합니다.만약 어플리케이션 이름이 중복된다면 위와 같은 에러 메세지가 나올 겁니다. 정상적으로 어플리케이션이 등록되면 위의 화면과 함께 API Key를 발급받을 수 있습니다. Consumer Key (API Key) 옆의 내용 (캡쳐화면에는 비공개)을 클릭하면 API Key 뿐만 아니라 API Secret, Access Token 등 세부 내용을 관리할 수도 있습니다.Step2. R Studio 설치하기 (Mac OS 기준)구글에서 R for macOS를 검색을 하면 맨 위에 설치 페이지가 보입니다. 1)먼저 R 패키지를 설치해야, 나중에 R Studio를 설치했을 때 실행이 가능합니다.R Studio 홈페이지에서 R Studio를 다운받습니다. 다운로드 링크는 여기를 클릭하세요.RStudio가 정상적으로 실행이 된다면, 이제 준비는 끝났습니다! Step 3. 필요한 패키지를 먼저 설치하기따로 설치가 필요한 패키지는 RStudio에서 명령어로 설치할 수 있습니다.—한 개씩 설치하는 법install.packages(“packageName”)—여러 개의 패키지를 한 번에 설치하고 싶을 땐 위와 같이 설치할 수 있습니다.—여러 개를 한꺼번에 설치하는 법install.packages(c(“package1”, “package2”,”package3”))—설치를 했다고 해서 바로 사용할 수는 없습니다. 이 패키지를 사용하겠다는 명령어를 다시 입력해야 합니다.—설치한 패키지를 사용하기library(“packageName”)—이번 글에서는 아래와 같은 패키지들이 필요합니다.twitteRROAuthbase64enchttpuvtmSnowballCwordcloudRColorBrewerStep 4. 트위터 api와 연동하여 WordCloud 생성하기먼저 각자 API 관련 Key 들로 객체를 생성해주고, setup_twitter_oauth() 메소드를 사용하여 Twitter API에 접근합니다.searchTwitter 4) 라는 함수를 사용하면, 트위터 API 를 통해 관련 트윗 내용을 추출할 수 있는데요. 좋아하는 일본 아이돌 가수인 “아라시”를 키워드로 추출하려고 첫 번째 파라미터에 “Arashi”를 넣었습니다. 그 뒤의 내용은 영문으로 작성된 최근(Recent) 트윗을 최대 1500개까지 리턴 받겠다는 의미입니다. resultType에는 popular를 넣으면 가장 인기있는 트윗을 받을 수도 있습니다.데이터를 가져오면, 위와 같이 데이터가 추출된 것을 확인할 수 있습니다.이제 matchTweets에 있는 내용으로 분석가가 되어 마음대로 데이터를 가공할 수 있습니다. class 등으로 구조와 클래스를 확인할 수 있을 뿐만 아니라, nchar() 를 이용해 트윗당 문자 수를 계산할 수도 있습니다. 이번 글에서는 위와 같이 트윗을 20개 추출했습니다.각각의 트윗을 보면, 이상한 코드나 슬래시 등 필요 없는 데이터들이 포함되어 내려온 것을 확인할 수 있습니다. 이 부분들을 제거해 깔끔한 데이터로 가공해보겠습니다. 그리고 텍스트 집합이라고 볼 수 있는 Corpus를 생성한 후, WordCloud 까지 생성해볼게요.데이터를 Corpus 로 만들 때는 Corpus() 를 사용하면 됩니다. 저는 VectorSource 라는 명령어를 사용해 단어들을 Vector로 바꿔주었고, 데이터가 잘 들어갔는지 확인하기 위해 inspect() 를 사용했습니다.사람이 읽기 불편한 단어들을 제거하는 건 tm_map 함수 하나면 충분합니다.위의 이미지를 보면, 각 행마다 특정 특수문자들을 제거하기 위한 명령어가 있습니다. 중간 부분엔 stopwords 라는 단어가 있는데, 영어 문장에 들어가는 i.e 나 etc 같은 표현들을 제거할 수 있는 겁니다. 그 외에도 대문자를 소문자로 바꾸거나 번호를 제거하는 등의 옵션들이 이미 R에서는 제공되고 있기 때문에, 우리는 입맛에 맞게 가져다 쓰기만 하면 됩니다.이제 대망의 WordCloud를 만들 차례입니다.max.words는 최대 N개의 단어를 고르는 옵션이며, min.freq는 최소 N번 이상 나온 단어, random.order = FALSE는 제일 많이 나온 단어가 먼저 나오도록 지정하는 옵션입니다. colors는 지정하지 않으면 검정색으로만 나오지만, 알록달록 예쁘게 표현하고 싶다면 여러 옵션을 지정해서 Frequency 에 따라 다른 색이 나오도록 할 수도 있습니다. 5) 첫 번째 이미지가 이번 글의 예제로 얻은 결과인데요. 추출 언어를 영어로만 한정했더니 일본어 발음을 영문으로 표현한 데이터가 많았습니다. 기타 설정을 변경하여 다시 추출한 게 바로 두 번째 이미지입니다. 큼직큼직하게 나온 단어들을 보면 DVD 나 블루레이 출시와 관련된 트윗이 대다수인 것을 볼 수 있는데요, 검색 결과 최근 2017-2018 라이브 투어 ‘Untitled’가 출시된 것을 확인할 수 있었습니다. 기타 작게 표현된 단어들을 보면 아라시의 노래 제목들도 확인 가능한데, 이 노래들이 인기있다는 것도 예측할 수 있습니다.Conclusion지금까지 R을 이용해 트위터 API 와 연동한 텍스트 마이닝을 했습니다. 데이터를 WordCloud로 생성하는 것도 해봤고요. 이번 글에서는 기본적인 예제를 다뤘지만 텍스트 마이닝의 세계는 아주 깊고 넓습니다. 만약 이 글로 텍스트 마이닝에 조금이라도 흥미가 생겼다면 일단 도전해보세요! 좋아하는 것과 연관 지어서 따라 하다 보면 꽤 즐거운 시간이 될 겁니다.참고1) 18년 6월 6일 기준이다.2) Twitter Sentiment Analysis Tutorial3) Text mining: Twitter extraction and stepwise guide to generate a word cloud4) R 함수 관련 설명은 R Documentation 사이트에서 확인할 수 있다. 5) 색상 옵션이 궁금하다면 여기에서 참고할 수 있다. 6) 머신러닝 언어처리 - R로 WordCloud 만들어보기 - 데이터 사이언스 랩글김우경 대리 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #R #텍스트마이닝
조회수 3045

챗봇과 인공지능 머신러닝 ㅡ Part 1/2

스타워즈를 보신 분이라면 거기에 나오는 난쟁이 로봇 R2D2와 키다리 로봇 C3P0를 아실 것이다. 친근한 R2D2는 전자음을 조정해 인간과 대화를 하며 주로 말 잘하고 박식한 로봇인 C3P0가 통역을 해준다.이런 충실하면서 똑똑한 친구들이 옆에서 항상 나를 도와준다면 어떨까? 정말 좋을 것이다. 만약 매일 보는 스마트폰 안에서도 나의 질문에 답해주는 이런 고마운 친구들이 있다면 얼마나 좋을까? 이런 저런 생각을 하다보면 우리는 대화형 로봇의 필요성을 느낀다.챗봇(Chatbot)이란?챗봇의 정의는 “대화형 인터페이스 상에서 규칙 또는 지능으로 유저와 소통하는 서비스”이다. 이 말을 하나하나 풀어보자.먼저, 대화형 인터페이스란 뭐지? 어렵다. 쉽게 설명해 보자. 인터페이스는 사람과 컴퓨터를 연결하는 장치라고 한다. 역시 어렵다. 아! 그냥 스마트폰 앱으로 보면 된다. 그럼 소통한다는 말은 대화한다는 것이므로 스마트폰 앱에서 일방향이 아닌 양방향이 가능하다는 얘기다. 어! 이상하다. 양방향이라면 나의 말에 응대하는 로봇은 뭐로 움직이는 거지? 궁금하다. 누가 일정한 규칙으로 만들어 논건지 아니면 우리처럼 지능이 있는 건지. 지능이 있다면 그런 지능은 뭐지? 점차 우리는 자연스럽게 인공지능에 다가간다.인공지능(Artificial Intelligence)이라는 용어는 1956년 미국 다트머스의 한 학회에서 존 매카시가 처음 사용했다고 한다. 원래 인공지능은 소프트웨어인 정신을 말하고 로봇은 하드웨어인 육체를 말하는 것이지만 정신없이 육체가 존재할 수 없는 것처럼 로봇을 얘기하면 당연히 인공지능은 따라간다.학자들은 인공지능을 강(强)인공지능과 약(弱)인공지능으로 구분한다. 간단히 얘기하면 강인공지능이란 자의식이 있는 인간에 가까운 지능이고 약인공지능은 자의식이 없다. 자아가 없으며, 명령받은 일만을 수행한다. IBM의 왓슨(Watson), 작년에 인공지능의 붐을 가져온 구글의 알파고(Alpha-GO) 등은 모두 약인공지능이다. 이런 인공지능을 구현하는 기술은 무엇인가? 바로 기계한테 학습을 시키는 머신러닝(Machine Learning)이다.1959년 아서 사무엘은 머신러닝을 "기계가 일일이 코드로 명시하지 않은 동작을 데이터로 부터 학습하여 실행할 수 있도록 하는 알고리즘을 개발하는 연구 분야"라고 정의했다. 여기서 학습이란, 입력 값을 받아 결과 값을 내는 모델을 만드는 표현과 표현을 통해 주어진 업무가 얼마나 잘 수행됐는지 알아보는 평가, 그리고 평가에서 설정한 기준을 찾는 최적화로 구성된 일련의 과정을 말한다. 중요한건 우리가 시키지 않은 일도 학습에 의해 자율적으로 처리한다는 것이다. 정말 신기하지 않은가?이제 챗봇이 뭔지 감이 잡힌다. 스마트폰 앱상에 존재하는 로봇인데, 물론 육체는 화면의 아이콘으로 밖엔 안보이지만 인공지능을 가지고 머신러닝에 의해 동작을 하면서 우리와 대화를 하는 그분. 그렇다면 이제 남은 건 이분의 지능이 어느 정도인지 또 얼마나 일을 잘하는 지로 판가름 난다.우리는 평생 공부를 한다. 이제는 학교를 졸업하고 나서도 항상 배워야 한다. 학습이 없다면 지능도 없다. 학습은 일일이 지도받는 지도학습과 알아서 공부하는 자율학습이 있다. 알아서 공부하려면 먼저 머리에 지식이 많아야 한다. 역시 기계도 사람과 비슷하게 배운다.  다음시간엔 챗봇에게 학습을 시켜 지능을 가지게 하는 방법에 대해 알아본다.> Part 2에서 계속
조회수 1343

스타트업 개발팀에서 일한다는 것

 대부분의 정보통신 분야, 특히 소프트웨어를 제작하는 "개발 조직"의 구성은개발,  디자인, 기획(또는 PM), QA가 팀으로서 분리되어있고, 규모 있는 회사들의 경우, 업무에 관련된 직군 간의 갈등 상황이나 문제가 생길 시, 파트장 또는 팀장님들(이하 중간관리자)이 중재를 하고 의사를 결정하는 정해져 있는 프로세스가 되어 있습니다. 그러나, 작은 규모의 스타트업이나, 업무에 책임을 지고 있는 인원이 단 한두명일 경우, 중간관리자들의 부재 때문에 개인 간 생기는 갈등 상황을 피할 수 없습니다. 그래서 오늘은 지금까지 제가 느낀 "정확하고 빠른 업무 진행을 위해 각 직군 간 인원들이 챙겨야 할 덕목들."을 말씀드리려 합니다. 그렇다면 무엇보다도, 왜 갈등 상황이 생기게 되는 걸까요?저는 "각 직군 간 종사자의 업무를 진행하는 과정과 목표가 다름에도, 이해보단 자신의 기준에서만 업무를 바라보는 경향"이 가장 큰 원인이라고 생각합니다. 저의 글(라고 적고 깨알 홍보라 읽는다...)에서 말씀드렸듯, 개발자, 디자이너, 기획자 들은 서로 일을 하는 방식도 다르고(심지어 개인차도 있지요), 각 직군마다 지향하는 부분들이 다르기 때문에 같은 방향을 보고 가더라도 서로가 서로 간에 집중하지 못하는 부분들이 분명히 존재합니다. 그리고 그런 부분들을 줄이기 위해선 업무 중 서로가 서로를 이해할 수 있도록 한 번씩 자신을 돌아보는 것들이 중요합니다. 그래서 아직 많이 부족하지만 각 직군에 종사하는 분들 그리고 공통적으로 업무 중에 한 번씩만 더 생각해 주셨으면 하는 것들과, 이유를 적어보려 합니다.기획 (또는 프로젝트 매니지먼트)1. 스펙 산정은 다 같이큰 회사라면 잘 모르겠지만, 작은 개발팀의 장점은 "많은 인원들이 비교적 짧은 시간 안에 많은 생각을 나누고 지향점을 찾아가는 과정을 같이 할 수 있는 것."이라고 생각합니다. 분명 기획자가 생각하고 만들어 내야 하는 스펙들이 있겠지만, 독단적으로 "이건 무조건 해야 하니 들어."라는 태도는 작은 팀일수록 업무의 동기를  꺾어버리는 일이 생길 수 있으니 항상 조심해야 합니다.2. 혼자서 "뭐... 개발이든 디자인이든 되겠지." 하는 추측은 절대 금물개발자 출신, 또는 디자이너 출신 또한 마찬가지라고 생각합니다. 몇 가지 예를 들자면, 1. 지금 개발자 또는 디자이너가 부딪힌 상황에 있지 않고, 2. 해당 직군에서 새롭게 화두 되는 트렌드에 덜 민감하고, 3. 각 개발자, 또는 디자이너가 생각하고 있는  스펙이나 디자인을 알지 못하고, 4. 어떤 라이브러리, 어떤 테마를 기반으로 작업할 지에 대한 기본적인 이해가 없으면서"이건 이렇게 되니깐 당연히 금방 될 거야."라는 생각은 절대 금물이라고 생각합니다.(디자이너나 개발자 분들이 그냥 "이거 간단하게 뭐 메뉴 만들어서 대충 어디 집어넣으면 되지 뭘 그리 어렵게 생각해?"라고 하면 피꺼솟 하는 거랑 마찬가지입니다ㅎㅎ) 3. 삼초 안에 정해진 내용도 항상 문서화 작은 개발팀일수록, 내용 저장과 공유, 그리고 의사 판단의 근거들이 약할 때도 있고, "우리 왜 이거 이렇게 가게 됐지?"라고 생각할 때가 많습니다. 적어도 "몇 월 며칠날 어떤 주제에 관해서 어떤 이유 때문에 어떤 방식으로 처리하기로 한다." 정도라도 항상 적어둘 필요가 있습니다. 디자이너1. 레퍼런스 자료 준비에 시간을 아끼지 말자 원하는 인터렉션, 원하는 디자인의 방향이 있다면, "왜 원하는지, 왜 이런 방향으로 개발을 해주었으면 하는지."에 대한 판단의 근거가 필요합니다. "이쁘잖아."는 상당히 설득력이 있지만 개발자 또는 기획자를 완전히 설득시킬 순 없어요... 특히 아직 개발이나 기획에 대한 로직을 잘 모르시는 디자이너 분들의 경우, 레퍼런스 자료를 찾을 때 드리블(Dribbble)이나 핀터레스트(Pinterest)도 좋지만, 스스로 프로토 타이핑 구현이 불가능하다면, 반드시 구동되고 있는 애플리케이션을 찾아보고 어떻게 작동하는지에 대해 면밀하게 파악해 주세요.2. 작은 부분이라도 시안에 변경이 있다면 반드시 공유하기 처음 팀 단위로 일을 하다 보면, "요거 내가 생각해보고 금방 슉 바꿔놔야지."라는 생각에 조용히 디자인을 바꿀 수 있습니다... 아? 아니에요 절대 안 됩니다.....  다 같이 협업하는 일을 하다 보면, 버전 관리와 변경내역 공유가 제작보다 더 중요한 상황이 올 수 있습니다. "내가 어디 부분을 변경했고, 변경한 이유는 이것 때문이다." 라는것 없이 홀로 조용히 변경한 디자인은 엄청나게 큰 갈등 상황을 부를 수 있어요!개발자1. 장애 발견 시 어디가 어떻게 안될 거 같은지에 대해서 설명하기 가장 힘든 줄 알지만, 할 수 있다면 가장 강점인 부분일 것 같아요. "개발하는 과정에서 이러한 부분은 지금 서비스에서는 이런 식으로 동작하는데, 원하시는 이런 부분은 이런 게 다르기 때문에 동작하는데 장애가 있을 수 있어요."를 설명해 줄 수 있는 개발자와 일한다는 것은 정말 같이 일하는 다른 직군들에게는 큰 축복이라고 할 수 있죠. "내가 백번 말해도 모르실 거예요."라고 말하는 건 결국, 무엇이 문제인지도 모르고, "다른데선 되는데 왜 우린 안돼?"라고 생각하는 다른 직군의 동료들에게 질타를 받을 수밖에 없습니다. 개발자는 소통이 잘 안 되는 사람이라는 고정관념을 깨고, 오래 걸려도 좋고, 다른 직군의 사람들이 당장 무슨 이야기를 하시는지 이해 못해도 좋아요. 같은 선상에서 고민한다는 것을 알려주는 것만으로도 큰 도움이 됩니다.전반적으로모든 작업의 종료는 내 결과물 발표가 아닌 다음 작업자의 업무 최적화입니다.기획자는 "문서 완료했을 때"디자이너는 "디자인 가이드 또는 산출물 나왔을 때"개발자는 "시킨 개발 다 했을 때"가 아니라,기획자는 "다음에 문서를 읽을 디자이너, 개발자가 스펙이 이해가 안돼서 업무를 진행하지 못하는 일이 없도록"디자이너는 "개발 중에 필요한 자료가 없어 업무를 진행하지 못하는 일이 없도록 "개발자는 "QA 중 개발에서 요구한 스펙에 미달되는 부분이 있어 업무를 진행하지 못하는 일이 없도록"하는 게 업무의 궁극적인 틀입니다. 결국, 일의 최종점은 결과물이 온전하게 나왔을 때 의미있는 것이기 때문에 최종 결과물이 나오는 과정에서 내 역할을 마지막까지 충실히 하는것이 업무의 종료라고 생각합니다. 분명, 모든 것들을 한 번에 모두 다 알고, 또는 모든 것들을 다 계산하면서 할 수는 없어요. 항상 실수는 할 수 있죠. 하지만, 실수가 아니라 이런 부분들을 알면서, 또는 이러한 고려를 하지 않고 업무를 지금까지 진행하셨다면, 말씀드린 부분은 분명히 한 번씩은 생각해 보아야 될 부분이라고 생각합니다. 굉장히 오랜만에 글을 쓰는 것 같네요! 다들 건강하게 잘 지내고 계시죠? 저는 마지막 글 이후 한 번의 이직과 다른 이런저런 일들에 치여 이제야 글을 쓰게 되네요. 이번글을 시작으로, 직군별로 하나하나 더 디테일하게 설명드리도록 할게요! 그리고 앞으로는 기획 업무 관련 뿐만이 아니라, 이번 글과 같이 각 직군 간의 이해관계나 업무를 진행하며 느끼는 것들에 대해 공유드리고, 서비스 기획 관련해서도 조금 더 자주 글 쓸 예정입니다. 앞으로도 자주자주 들러주세요, 감사합니다! :)#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트

기업문화 엿볼 때, 더팀스

로그인

/