스토리 홈

인터뷰

피드

뉴스

조회수 1450

비트윈이 사용자를 분석하는 방법

빅데이터분석이 최근 이슈가 되면서 관심이 많으실 것 같습니다. 비트윈팀도 데이터 분석 참 좋아하는데요, 저희도 한번 해보았습니다. 이번 포스팅에서는 비트윈팀의 데이터 분석 노하우를 아낌없이 공유해드립니다.왜 사용자의 데이터를 분석해야하는가요?비트윈같은 서비스는 초기 단계에는 앱을 기획하고 만들어낸 팀에 아이디어에 의해 계속해서 발전하고, 유지됩니다. 하지만 기능이 점점 다양해지고 사용자가 점점 많아지면서 사용자들의 앱 사용패턴을 점점 예측하기 어려워집니다. 게다가 비트윈은 해외 진출을 구상 중이었는데, 개인 혹은 팀의 아이디어만으로 해외에서의 사용패턴을 정확히 알기는 어려웠습니다.이런 시점에 필요한 것이 사용자 분석입니다.사용자들의 사용패턴을 분석해 보는 방법은 여러 가지가 있습니다. 초기에 해볼 수 있는 가장 직관적이고 쉬운 것은 비트윈을 사용하는 자기 자신의 사용 패턴을 돌아보고 분석해보는 것입니다. 또 친구들이나 익명 사용자들의 사용패턴을 물어보거나, 관찰하는 방법들이 있습니다. 이런 방법은 매우 효과적이고 많은 아이디어를 주지만 여러 가지 한계점이 있습니다. 지역적, 시간적인 한계 등이 그것입니다.그래서 택할 수 있는 방법이 실제로 사용자들의 행동을 컴퓨터로 수집해서 분석하는 것입니다. 말 그대로 '데이터 분석'을 하게 되는 것입니다.무엇을 분석할지 알아야 합니다데이터로 분석할 수 있는 것은 무궁무진합니다만, 먼저 데이터가 있어야합니다. 비트윈과 같이 서버와 통신하는 앱은 사용자들이 서버에 요청을 할 때마다 엑세스 로그를 남기게 됩니다. 이 엑세스 로그는 사용자들의 사용패턴을 고스란히 담고 있어, 소중한 데이터가 됩니다.엑세스 로그 분석은 전혀 어렵지 않습니다. 엑세스 로그에서 특정 행동에 해당하는 내용을 세는 것만으로도 여러 가지 유의미한 값을 얻어낼 수 있습니다. 하루 동안의 로그를 한줄씩 읽어서 메시지에 관련된 로그를 카운트하면 그날의 메시지 전송 건수를 얻을 수 있는 것입니다. (참 쉽죠?)엑세스로그에서 가입, 메시지, 사진, 메모 등 기본적인 내용에 해당하는 것들을 카운트하는 것만으로도 꽤 자세하게 앱 전체 사용자들의 전반적인 사용통계를 얻어낼 수 있습니다. 이제 해당 데이터를 엑셀에 넣어서 차트를 그려보면, 사용 통계에 대한 그럴싸한 차트가 그려집니다.엑세스 로그 분석에 성공했다면 좀 더 다양한 분석을 해볼 수 있을 텐데요, 사용자별 행동패턴 분석이나, 나라별, 혹은 아이폰, 안드로이드 디바이스별 분석 등 다양한 분석을 시도해볼 수 있습니다. 분석을 하기 전에 중요한 것은 무엇이 궁금한지, 어떻게 궁금한 데이터를 모을지 아이디어를 먼저 내는 것입니다. 여러 예제들을 찾아보며 공부해보면, 금방 좋은 아이디어를 얻으실 수 있을 겁니다.물론 여기서 중요한것은 개인정보나 사생활의 보호입니다. 로그가 유출되었을때의 보안 문제 뿐 아니라, 데이터 분석팀에게조차 개인정보가 노출된다면 곤란합니다. 이 문제에 저희가 어떻게 대처하고 있는지는 글 뒷부분에 자세히 알려드리겠습니다.특정 기술에 구애받지 말고 다양하게 구현해봅시다처음에는 로그 파일을 돌며 간단한 string을 검사하는 스크립트와 엑셀로도 충분했지만, 점점 복잡한 분석을 할수록 다양한 기술이 필요해집니다. 비트윈 사용자 분석도 점점 다양해지고 복잡해지면서 여러 가지 기술들을 사용하고 있습니다.비트윈 사용자 분석은 처음에는 6줄짜리 간단한 shell script에서 시작되었습니다.cat 2011-10-31.log | grep /messages | grep POST | wc -lcat 2011-10-31.log | grep /photos | grep POST | wc -lcat 2011-10-31.log | grep /memos | grep POST | wc -lcat 2011-10-31.log | grep /like | grep POST | wc -lcat 2011-10-31.log | grep SIGN | wc -lcat 2011-10-31.log | grep REL | grep POST | wc -l이런 스크립트를 만들어서 결과를 이메일로 공유하거나, 엑셀로 만들어 놓곤 했습니다.여기에 비트윈 분석은 조금 더 발전하여, 로그파일을 쿼리하여 Map Reduce 작업이 가능한 Hive를 사용하고, PHP로 통계 웹사이트를 만들어 차트를 그리기 시작했습니다. 이 방식은 처음에는 매우 편리했지만 차츰 쿼리만으로 원하는 결과를 얻기가 힘든 다소 복잡한 분석이 필요해지기 시작했습니다.현재는 모든 로그를 분산 데이터베이스인 HBase에 Date Key와 User Key로 넣고, 코드 생산성이 좋은 Scala로 직접 Map Reduce코드를 작성해서 데이터들을 분석하고 있습니다. 그래서 충분히 scalable하면서도 꽤 편리하게 이용할 수 있는 데이터베이스를 활용하고, Scala의 좋은 expression을 활용하여 짧고 유지보수나 확장이 쉬운 코드로 분석을 수행하면서도 Java와 호환되는 Scala의 특성을 이용하여 Map Reduce 코드 작성을 효과적으로 하고 있습니다. 이렇게 분석한 데이터는 MySQL에 넣어서 2차로 가공하고, Scala Web Framework인 Play Framework을 이용하여 분석 사이트를 구축하고 D3 Chart를 이용해서 Visualize하고 있습니다. 이렇게 함으로써 편리한 MySQL 쿼리 사용의 장점을 취하고 멋진 차트를 효과적으로 그려낼 수 있습니다.좋은 Visualization은 멋질 뿐만 아니라 손쉽게 아이디어를 공유할 수 있게 해줍니다.앞으로는 더 빠른 성능을 위해 Hive를 더 잘 사용해보거나, Elastic Search같은 index engine들을 사용해 볼 계획도 가지고 있습니다. 또한 End point들에서 직접 성능을 측정하여 중앙으로 모아서 분석해보려는 생각도 가지고 있습니다.기술을 선택함에 있어서 정답은 없는 거 같습니다. 널리쓰이는 MySQL같이 scalability가 좀 떨어지지만, 다양한 쿼리로 높은 생산성을 낼 수 있는 데이터베이스도 있고, HBase같이 scalability가 좋지만, 데이터를 저장하는 형태에 제한이 있어 생산성이 조금 떨어지는 데이터베이스도 있습니다. 저희는 앞서 소개드렸듯이 이 두 가지를 모두 혼용하여 사용하고 있습니다. 각자가 마주한 상황에 맞게, 또 각자가 익숙한 기술에 맞게 설계하고, 사용해보면 됩니다.개인정보 보호는 철저하게빅데이터 분석이 개인정보를 침해하는 빅 브라더가 될 수 있다는 우려들이 나오고 있습니다. 300만이 넘는 커플들의 비밀스러운 일기를 담고 있는 비트윈 서비스는 당연하게도 모든 업무를 진행하는 데 있어 보안과 개인정보를 최우선으로 하고 있습니다. 데이터 분석에서도 분석할 수 있는 내용을 상당히 제한받더라도, 예외 없이 그 원칙을 지키고 있습니다.비트윈의 API서버는 AWS클라우드에서 운영되고 있는데, 사용료가 상당히 비싸기 때문에 큰 컴퓨팅 파워를 사용해야 하는 데이터분석까지 AWS에서 하기엔 좀 부담이 되었습니다. 그래서 PC급 컴퓨터 여러 대를 구입하여 사무실 구석에 쌓아놓고 사용하고 있습니다.하지만 문제는 보안이었습니다. AWS의 비트윈 API서버는 다중으로 보안이 유지되고 있지만, 사무실에 있는 서버에 사용자들의 개인정보를 담아둘 수는 없는 일이었습니다. SECO*이 사무실을 지켜주고 있긴 하지만 보안회사에 고객들의 소중한 개인정보를 맡기고 안심할 수는 없으니까요. 그리고 설사 보안 문제가 잘 해결된다고 해도, 분석을 수행하는 비트윈 데이터분석팀원에 개인정보 혹은 사생활이 노출된다면 그 또한 문제라고 생각하였습니다.그래서 저희가 생각해낸 방법은 '익명화'입니다. Access Log들을 저장할 때 사용자의 아이디를 전부 단방향 salted-hash하여 누구인지 알 수 없게 만들었습니다. (물론 salt key는 데이터 분석팀은 알 수 없습니다.) 그리고 애초에 Access Log에는 '어떤 사람'이 '50글자짜리 메시지를 보냈다' 라던가, '사진을 올렸다' 정도만 기록이 되기 때문에, 이를 통계적으로 분석하는 것은 유의미하지만, 사적인 정보를 담고 있지는 않습니다.익명화되어 처리되고 있는 로그는 개인정보는 거의 담고 있지 않으면서도, 유익한 분석 결과를 만들어줍니다.이런식으로 운영을 한다면 데이터 분석팀에서도 사적인 정보(예: 메시지 내용)에 대해서는 접근할 수 없기 때문에, 회원들의 소중한 개인정보와 사생활을 지킬 수 있습니다. 어떤 분석을 수행할 때 언제나 비트윈팀은 언제나 보안과 사생활 보호의 원칙을 지킬 수 있는 범위에서만 진행하고 있습니다.아이디어의 공유, 그리고 액션아이템이 무엇보다도 중요합니다데이터 분석의 목표가 무엇인지, 왜 해야 하는지 생각해보면, 무엇을 해야 하는지 알 수 있습니다. 바로 분석으로부터 얻은 아이디어를 공유하고 액션아이템을 정하고 실천하는 것입니다.데이터를 visualization하는것이 중요한 이유가 여기에 있습니다. 보기 좋은 떡이 먹기도 좋다는 말이 있듯이, 데이터도 먹기 좋아야 합니다. 여러 사람이 쉽게 이해할 수 있어야 아이디어를 공유하고 의사결정을 내리기가 수월하기 때문입니다.민트&베리 사용량 분석. 연인들이 쓰는 앱이라 사랑표현이 인기가 많군요. 디자인팀이 이런 자료를 참고하여 이후 디자인 아이디어를 내는 데 도움이 되면 좋겠죠?비트윈팀은 매번 데이터 분석 미팅을 진행하고 나면 액션아이템을 정하고 실천합니다. 저희가 어떤 식으로 의사결정을 내리고 행동하는지에 대해서는 비트윈 팀블로그의 VCNC는 데이터분석에 기반해 어떤 결정을 내렸나 포스팅을 보시면 도움이 되실 것 같네요.맺으며이번 포스팅에서는 비트윈팀이 어떻게 무엇을 분석하는지 간단하게 다뤄봤습니다. 의견이나 참견 모두 환영이니 댓글 많이 남겨주세요! 다음번 포스팅엔 기술적인 부분에 대해 좀 더 자세하게 다뤄보도록 하겠습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!
조회수 1816

서비스 중단 없이 Amazon EKS로 옮긴 이야기 - VCNC Engineering Blog

Amazon EKS는 AWS의 관리형 Kubernetes 서비스입니다. 2017년 11월 AWS re:Invent에서 프리뷰 버전이 출시되었고, 2018년 6월에 상용(GA) 버전이 미국 리전에만 출시되었습니다. 그래서 서울 리전을 사용해야 했던 타다 프로젝트에서는 Kubernetes 클러스터를 직접 kops로 설치하여 운영할 수 밖에 없었습니다.2019년 1월, 오랜 기다림 끝에 드디어 서울 리전에 EKS가 출시되어 기쁜 마음으로 EKS로 옮겨가게 되었습니다. 이 글에서는 직접 구축한 클러스터 대비 EKS의 특징에는 어떤 것이 있는지 살펴보고, 서비스 중단 없이 EKS로 옮기기 위한 전략을 공유하고자 합니다.EKS 서울 리전 출시를 염원하던 한국인(?)들EKS는 뭐가 다른가요?AWS에서 마스터 노드를 관리해줍니다.Kubernetes 클러스터는 마스터 노드와 워커 노드로 구성되어 있습니다. EKS는 이 중에서 마스터 노드를 직접 EC2로 띄울 필요 없이 AWS에서 관리해주는 서비스입니다. RDS를 사용할 때 직접 DB 인스턴스를 생성하지 않는 것과 비슷합니다. 별도의 설정 없이도 알아서 여러 가용 영역에 마스터 노드를 실행하여 HA(고가용성) 구성을 해주고, 비정상 마스터 노드를 자동으로 감지하고 교체합니다. 또한 자동화된 버전 업그레이드 및 패치를 지원합니다. EKS를 사용하더라도 워커 노드는 직접 EC2 인스턴스를 생성·관리해야 합니다.EKS 클러스터의 요금은 2019년 2월 현재 시간당 $0.20입니다. 타다에서는 기존에 t2.medium 3대를 마스터 노드로 사용하고 있었기 때문에 관리를 직접 하지 않는 대신 비용이 약간 증가하게 되었습니다.AWS IAM 기반 인증을 사용합니다.VCNC에서는 기존에 Kubernetes API에 접속할 때 가장 간단한 basic auth 인증 방식을 사용했습니다. 그 대신 외부 네트워크에서 접근할 수 없게 해두고 필요한 경우 Bastion 호스트를 통해 SSH 터널링하여 접속했습니다.EKS의 API 서버는 인터넷에 노출되어 있으며, 별도로 네트워크 접근 제한 설정을 할 수 없고 AWS IAM으로 사용자를 인증합니다. (물론 공개망에 노출되어 있으면 Kubernetes API 서버에 보안 취약점이 발견되는 경우 안전하지 않을 수 있는 단점이 있습니다. 앞으로 PrivateLink가 지원되면 해결될 것입니다.)IAM은 인증에만 사용되고, 특정 작업을 할 수 있는 권한은 Kubernetes 기본 RBAC로 관리됩니다. IAM 사용자나 역할을 RBAC 그룹에 매핑할 수 있습니다.EKS 인증 흐름도워커 노드 당 Pod 개수 제한이 있습니다.예를 들어 c5.large 인스턴스에는 29개의 Pod을 띄울 수 있습니다. (표 참고) 그러므로 기존 클러스터에서 노드 당 Pod이 몇 개나 되는지 미리 확인할 필요가 있습니다. 왜 이런 제약이 있을까요?Kubernetes에서는 네트워킹 플러그인으로 Pod 사이에 네트워크 통신하는 방식을 다양하게 설정할 수 있습니다. EKS는 기본적으로 amazon-vpc-cni-k8s를 사용합니다. 이 네트워킹 플러그인은 VPC 상에서 유효한 실제 IP를 Pod에 할당합니다.그러기 위해서는 하나의 EC2 인스턴스에서 여러 개의 IP를 받아와야 하고, 이를 위해 추가적인 네트워크 인터페이스(ENI)를 붙입니다. 그런데 인스턴스 타입에 따라 추가할 수 있는 ENI 수와 ENI 당 IP 수에 제한이 있습니다. 따라서 이 제한이 워커 노드 하나에 띄울 수 있는 Pod 개수 제한이 됩니다.flannel 등 오버레이 네트워크 기반의 다른 네트워크 플러그인을 사용하면 이러한 제약을 피할 수 있습니다. 하지만 EKS에서 기본 제공하는 방법을 그대로 사용하는 것이 좋고, Pod을 엄청나게 많이 띄워야 하는 상황이 아니어서 시도하지 않았습니다.EKS로 중단 없이 넘어가기개요타다의 Kubernetes 클러스터에서 돌아가는 서비스들은 모두 영속적인(persistent) 상태를 가지고 있지 않습니다. 따라서 EKS 클러스터 위에 동일한 서비스를 띄우고 외부 트래픽을 옮겨주기만 하면 특별히 데이터를 옮기지 않고도 이전이 가능했습니다. 또한 거의 대부분의 Kubernetes 리소스는 Helm 차트로 생성한 것이기 때문에 새로운 클러스터에 동일한 서비스를 띄우는 작업도 쉽게 할 수 있었습니다.이전 작업은 다음과 같은 순서로 진행했습니다.EKS 클러스터를 만들고 워커 노드를 생성모든 서비스 다시 설치트래픽을 새 클러스터로 보내기이전 클러스터 제거EKS 클러스터를 만들고 워커 노드를 생성타다의 AWS 환경은 거의 모두 Terraform으로 정의되어 관리되고 있습니다. EKS 클러스터와 워커 노드도 HashiCorp Learn의 문서를 참고해서 Terraform으로 생성했습니다. 해당 문서에 설명이 잘 되어 있어서 거의 그대로 따라할 수 있었습니다.EKS 클러스터 설정은 재사용 가능하도록 Terraform 모듈로 만들었습니다. 덕분에 테스트용 클러스터와 실서비스용 클러스터를 동일한 모듈로 변수만 바꿔서 설정할 수 있었습니다.모든 서비스 다시 설치타다의 Kubernetes 리소스는 Helm 차트로 관리되고 있어서 기존 차트를 거의 그대로 설치할 수 있었습니다. 사용자에게 직접적인 영향을 덜 주는 워커 서비스를 먼저 설치해서 제대로 동작하는 것을 확인한 뒤, 마지막으로 프론트엔드 서비스를 설치하였습니다.트래픽을 새 클러스터로 보내기타다의 모든 트래픽은 NLB로 들어온 뒤 NGINX를 거쳐 다시 적절한 Pod에 라우팅됩니다. 그러므로 타다의 모든 도메인은 NLB를 가리키고 있습니다.타다는 Route 53을 DNS 서버로 사용합니다. Route 53에는 가중치 기반 DNS 레코드를 설정할 수 있습니다. 이를 이용하여 일부 트래픽만 새 클러스터의 NLB로 보낼 수 있습니다. 처음에는 아주 적은 트래픽만 새 클러스터로 보내다가 문제 없이 작동하는 것을 확인한 다음 조금씩 트래픽을 늘려나갔습니다.DNS 가중치 설정으로 일부 트래픽만 새 클러스터의 NLB로 보낼 수 있습니다.DNS 설정에서 이전 클러스터로 가는 레코드를 완전히 제거한 뒤에도, DNS 캐시 등의 이유로 일부 클라이언트가 이전 클러스터에 접속할 수도 있습니다. 따라서, 이전 클러스터 NLB에 새 클러스터의 노드들을 붙여서 아직 DNS를 따라오지 못한 클라이언트들의 요청을 처리하였습니다.이전 클러스터 제거가장 신나면서 조심해야 하는 작업입니다. 먼저 이전 클러스터로 트래픽이 전혀 들어오지 않는 것을 확인하였습니다. 그 다음에는 Terraform에서 이전 클러스터 리소스에 대한 참조를 제거한 뒤, terraform destroy 명령으로 이전 클러스터와 관련된 리소스를 한번에 삭제할 수 있었습니다.맺음말Kubernetes는 깔끔한 추상화를 통해 컨테이너 기반 배포를 간단하게 만들어주지만, 직접 클러스터를 관리해야 하는 부담이 있었습니다. Amazon EKS는 이러한 부담을 많이 덜어주는 좋은 서비스입니다. 앞으로 EKS의 무궁한 발전을 기원합니다.VCNC에는 오랫동안 쌓아온 AWS 인프라 운영 경험이 있습니다. 타다에서는 그동안의 경험과 비교적 최근에 시작한 프로젝트의 이점을 살려 컨테이너, Infrastructure as Code 등 업계 표준의 인프라 관리 방법론을 적극 도입하려고 노력하고 있습니다. 앞으로도 이에 관해 기술 블로그에 더 자세히 공유할 계획이니 기대해주세요. 또한 저희와 함께 안정적인 서비스를 만들어나갈 좋은 분들을 기다리고 있으니 VCNC 채용에도 많은 관심 부탁드립니다.
조회수 1652

공용 계정용 OTP 관리방법

제대로 된 기업용 서비스라면 의례 다중 계정과 권한 제어 기능을 함께 제공하기 마련이다. 그래서 공용 계정을 굳이 만들 이유가 하나도 없다. 하지만 일부 서비스(그리고 대부분의 한국의 기업 서비스)는 단일 계정만 지원하는데다 AWS 같은 서비스도 root 계정이 따로 있어서 계정 관리 이슈가 불거지기 마련이다. 계정 아이디와 암호의 경우는 LastPass 같은 기업용 계정 관리 서비스를 사용하거나 팀 공용 계정 비밀번호 관리하기에서 소개된 방식과 같이 약간은 불편하지만 비용이 들지 않는 수단을 도입하여 관리하면 된다. 그런데 MFA 또는 2FA(2-Step Verification)라고도 부르는 OTP로 계정을 보호할 때는 OTP 정보를 공유하기가 쉽지 않다. 일반적으로 MFA 계정은 Google Authenticator 같은 앱을 설치해 관리한다. OTP 정보와 계정 암호를 한 계정에서 관리하지 않아야 한쪽이 노출되어도 보안을 유지할 수 있기 때문이다. 문제는 Google Authenticator와 Authy 같은 도구를 특정 휴대폰에 설치하면 여러 사람이 OTP 정보를 공유하기 힘들다는 것이다. 그래서 몇가지 솔루션을 찾아보았는데 “이거다!” 싶은 건 없어도 gauth라는 명령줄 기반 도구에 안착하게 되었다.gauth.csv라는 파일에 OTP 정보를 아래와 같이 입력하고AWS: ABCDEFGHIJKLMNOPQRSTUVWXYZ234567ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 Airbnb:abcd efgh ijkl mnop Google:a2b3c4d5e6f7g8h9 Github:234567qrstuvwxyzgauth를 실행하면 아래와 같이 OTP 토큰을 확인할 수 있다.$ gauth prev curr next AWS 315306 135387 483601 Airbnb 563728 339206 904549 Google 453564 477615 356846 Github 911264 548790 784099 [======= ]이제 gauth.csv 파일만 라스트패스 등으로 제한된 사용자에게 안전하게 공유하면 된다.개선 사항DailyHotel/gauth는 pcarrier/gauth를 개선한 tuxmartin/gauth를 Docker 이미지로 감쌌다. 그래서 Golang 개발환경을 갖추고 소스코드를 빌드하지 않아도 바로 사용할 수 있다. 자세한 사용법은 README 문서에 적어두었다.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #인사이트 #꿀팁
조회수 1271

MySQL에서 RDS(Aurora) 로 이관하기

안녕하세요. 스티비팀 서버 개발자 이학진 입니다. 저희는 최근 서비스에서 사용 중이던 MySQL DB를 RDS로 이관하는 작업을 진행하였습니다. 무엇 때문에 이관을 결정하게 되었는지와 어떻게 이관을 진행하였는지에 대해 글을 써보도록 하겠습니다.배경stibee.com은 작년 11월에 정식 오픈한 새내기 이메일 마케팅 서비스 입니다. 사실 오픈 초기부터 얼마전까지만 해도 AWS EC2의 m4.large 인스턴스 하나로 운영되던 서비스였습니다.(사실 웹+API 서버 1대, 메일발송서버 1대)그리고 이 싱글 인스턴스에 무려 6개의 서버, mysql 1개, kafka 1개, redis 1개가 돌고 있었습니다. 그럼에도 불구하고 cpu사용률은 20%를 넘지 않았습니다.하지만 최근 사용자도 점점 늘어났고, 네이버에서 메일 수신정책을 변경하면서 메일발송서버에 대한 요청이 급증했습니다.스티비에서 네이버로 대량메일을 발송했을 때 해당 메일의 본문 링크를 자동검사하는 것을 발견했는데요, 따라서 네이버로부터 비정상적으로 많은 요청이 들어오고 있었습니다. (어떤 기준으로 이런 검사를 하는 것인지 정확한 정책은 아직 모릅니다. 담당자분 이 글을 보신다면 연락주세요. 친하게 지냈으면 합니다#슬로워크 #스티비 #개발 #서버개발 #개발환경 #MySQL #인사이트
조회수 1821

[Buzzvil Career] 좋은 데이터 애널리스트는 어떤 사람일까?

모바일 잠금화면 미디어 플랫폼 사업자 버즈빌은 어떠한 인재를 찾는지 지원자에게 잘 알리려고 노력합니다. 그럼 지원자도 버즈빌이 자신에게 맞는 기업인지 알 수 있을 테니까요. Buzzvil Career에서는 각 직무에 대해 더욱 심도 있는 정보를 제공합니다. 현재 채용에 관련한 자세한 내용은 여기에서도 확인 가능합니다. 이 게시물은 데이터 애널리스트 Elia와의 인터뷰를 담고 있습니다. 그는 좋은 데이터 애널리스트는 어떤 사람인지에 대해 이야기합니다. 데이터를 좋아하고 데이터에 기반한 기업 성장에 기여하고 싶다면 이 글에 주목해주세요.업무에 대해 설명해주세요.안녕하세요. 버즈빌의 데이터 애널리스트 Elia입니다. 팀에서 일한 지 어느덧 4년이라는 세월이 흘렀네요. 데이터 분석을 위한 툴을 세팅하고 많은 양의 가공된 데이터를 공유하고 있습니다. 데이터로 무엇을 하고 어떻게 활용할지 고민하는 것이 제 일입니다. 또 저는 올바른 결정을 내리고 효율적으로 업무를 수행할 수 있도록 A/B 테스팅과 다양한 연구를 수행하고 있습니다. 마지막으로 SQL 세션을 열어서 사람들이 데이터에 유연하게 접근하고 잘 사용할 수 있도록 합니다.왜 버즈빌을 선택 했나요?가까운 지인이 이 회사를 추천해줬습니다. 분위기가 친근했고 한국에도 이런 곳이 있다는 게 놀라웠습니다. 그리고 버즈빌은 석촌 호수 바로 앞에 있어서 전망이 훌륭한데 특히 봄이 되면 벚꽃을 볼 수 있습니다. 그리고 무엇보다 사무실은 저희 집과 가깝습니다. 그러니 제가 거절할 이유가 없었죠.버즈빌은 어떤 곳인가요?버즈빌은 데이터 애널리스트로서 성장할 수 있는 곳입니다. 팀 규모가 그렇게 크지 않아서 유연합니다. 많은 사람과 이야기를 할 수 있고 사람들을 어떻게 도울 수 있을지, 어떤 일을 이루어야 하는지 스스로 고민할 수 있기 때문에 컨설턴트 같은 존재입니다. 그만큼 특정 역할에 고정되지 않습니다. 데이터 분석은 새로운 분야입니다. 그래서 회사가 그것을 어떻게 생각하는지에 따라 담당자가 할 수 있는 일이 달라집니다. 다행히 버즈빌리언은 새로운 아이디어와 제안에 개방적인 태도를 보입니다. 버즈빌처럼 새로운 분야를 배우는 걸 좋아하는 집단도 없을 겁니다. 그래서 담당자가 얼마나 능동적인지에 따라 할 수 있는 일이 많아집니다. 정말 독특한 문화를 가졌죠.팀 분위기는 어떤가요?여기서는 다양한 프로젝트에 대해 데이터를 조사하고 돌파구를 찾아야 합니다. 초집중해야 하며 테스트를 수행하고 데이터를 분석하는 방법을 발견해야만 합니다. 올바른 의사 결정을 내리는 것은 쉬운 일이 아니기 때문에 데이터 애널리스트가 필요하죠. 이 역할이 왜 필요한지 사람들이 알 수 있도록 자신을 잘 표지셔닝을 해야 합니다. 그래야 새로운 프로젝트에 참여할 수 있는 기회가 더 많아지고 기업 성장에 더욱 직접적으로 기여할 수 있죠.좋은 데이터 애널리스트는 어떤 사람일까요?# 커뮤니케이션 데이터 애널리스트는 효과적으로 딱 필요한 말만 잘 전달하는 커뮤니케이터가 되어야 합니다. 같은 말을 반복하거나 요점에서 자꾸 벗어나면 안 되죠. 버즈빌에서 데이터 분석가로 일하려면 다양한 팀과 일하기 때문에 소통을 효과적으로 잘해야만 합니다. 그래야 데이터 연구 결과가 정확할 수 있기 때문이죠. 이는 더 나은 비즈니스 의사 결정으로 이어지죠.#적극성 데이터 애널리스트는 능동적일수록 더 성장할 것입니다. 당신의 역량이 향상될 것이고 되고 직장에서 다양한 사람들과 상호작용하는 요령을 익힐 수 있습니다. 버즈빌은 데이터 애널리스트가 다양한 연구를 수행하기 좋은 인프라를 갖추고 있는데 이것은 데이터 분석이 새로운 분야라는 점에서 매우 플러스입니다. 따라서 버즈빌은 새로운 기회를 얼마든지 제공할 수 있기 때문에 탐험을 즐기는 사람을 찾고 있습니다.*버즈빌은 현재 채용 중입니다. (전문연구 요원 포함) 자세한 내용은 아래 버튼을 눌러주세요!모바일 잠금화면 미디어 플랫폼 사업자 버즈빌은 어떠한 인재를 찾는지 지원자에게 잘 알리려고 노력합니다. 그럼 지원자도 버즈빌이 자신에게 맞는 기업인지 알 수 있을 테니까요. Buzzvil Career에서는 각 직무에 대해 더욱 심도 있는 정보를 제공합니다. 현재 채용에 관련한 자세한 내용은 여기에서도 확인 가능합니다. 이 게시물은 데이터 애널리스트 Elia와의 인터뷰를 담고 있습니다. 그는 좋은 데이터 애널리스트는 어떤 사람인지에 대해 이야기합니다. 데이터를 좋아하고 데이터에 기반한 기업 성장에 기여하고 싶다면 이 글에 주목해주세요.업무에 대해 설명해주세요.안녕하세요. 버즈빌의 데이터 애널리스트 Elia입니다. 팀에서 일한 지 어느덧 4년이라는 세월이 흘렀네요. 데이터 분석을 위한 툴을 세팅하고 많은 양의 가공된 데이터를 공유하고 있습니다. 데이터로 무엇을 하고 어떻게 활용할지 고민하는 것이 제 일입니다. 또 저는 올바른 결정을 내리고 효율적으로 업무를 수행할 수 있도록 A/B 테스팅과 다양한 연구를 수행하고 있습니다. 마지막으로 SQL 세션을 열어서 사람들이 데이터에 유연하게 접근하고 잘 사용할 수 있도록 합니다.왜 버즈빌을 선택 했나요?가까운 지인이 이 회사를 추천해줬습니다. 분위기가 친근했고 한국에도 이런 곳이 있다는 게 놀라웠습니다. 그리고 버즈빌은 석촌 호수 바로 앞에 있어서 전망이 훌륭한데 특히 봄이 되면 벚꽃을 볼 수 있습니다. 그리고 무엇보다 사무실은 저희 집과 가깝습니다. 그러니 제가 거절할 이유가 없었죠.버즈빌은 어떤 곳인가요?버즈빌은 데이터 애널리스트로서 성장할 수 있는 곳입니다. 팀 규모가 그렇게 크지 않아서 유연합니다. 많은 사람과 이야기를 할 수 있고 사람들을 어떻게 도울 수 있을지, 어떤 일을 이루어야 하는지 스스로 고민할 수 있기 때문에 컨설턴트 같은 존재입니다. 그만큼 특정 역할에 고정되지 않습니다. 데이터 분석은 새로운 분야입니다. 그래서 회사가 그것을 어떻게 생각하는지에 따라 담당자가 할 수 있는 일이 달라집니다. 다행히 버즈빌리언은 새로운 아이디어와 제안에 개방적인 태도를 보입니다. 버즈빌처럼 새로운 분야를 배우는 걸 좋아하는 집단도 없을 겁니다. 그래서 담당자가 얼마나 능동적인지에 따라 할 수 있는 일이 많아집니다. 정말 독특한 문화를 가졌죠.팀 분위기는 어떤가요?여기서는 다양한 프로젝트에 대해 데이터를 조사하고 돌파구를 찾아야 합니다. 초집중해야 하며 테스트를 수행하고 데이터를 분석하는 방법을 발견해야만 합니다. 올바른 의사 결정을 내리는 것은 쉬운 일이 아니기 때문에 데이터 애널리스트가 필요하죠. 이 역할이 왜 필요한지 사람들이 알 수 있도록 자신을 잘 표지셔닝을 해야 합니다. 그래야 새로운 프로젝트에 참여할 수 있는 기회가 더 많아지고 기업 성장에 더욱 직접적으로 기여할 수 있죠.좋은 데이터 애널리스트는 어떤 사람일까요?# 커뮤니케이션 데이터 애널리스트는 효과적으로 딱 필요한 말만 잘 전달하는 커뮤니케이터가 되어야 합니다. 같은 말을 반복하거나 요점에서 자꾸 벗어나면 안 되죠. 버즈빌에서 데이터 분석가로 일하려면 다양한 팀과 일하기 때문에 소통을 효과적으로 잘해야만 합니다. 그래야 데이터 연구 결과가 정확할 수 있기 때문이죠. 이는 더 나은 비즈니스 의사 결정으로 이어지죠.#적극성 데이터 애널리스트는 능동적일수록 더 성장할 것입니다. 당신의 역량이 향상될 것이고 되고 직장에서 다양한 사람들과 상호작용하는 요령을 익힐 수 있습니다. 버즈빌은 데이터 애널리스트가 다양한 연구를 수행하기 좋은 인프라를 갖추고 있는데 이것은 데이터 분석이 새로운 분야라는 점에서 매우 플러스입니다. 따라서 버즈빌은 새로운 기회를 얼마든지 제공할 수 있기 때문에 탐험을 즐기는 사람을 찾고 있습니다.*버즈빌은 현재 채용 중입니다. (전문연구 요원 포함) 자세한 내용은 아래 버튼을 눌러주세요!버즈빌과 함께하고 싶은 분은 지금 바로 지원 해주세요! (전문연구요원 포함)
조회수 880

프로그래밍에는 왜 창의성이 필요하다고 할까요?

왜 프로그래밍에는 창의성이 필요하다고 할까요? 실제로 프로그래밍을 하다 보면 복잡한 문법을 이해하고, 암호 같은 에러를 차분히 해결해야 하니, 오히려 수학적이며 논리적인 사고가 더 필요해 보입니다. 그런데도 프로그래밍이 창의적이어야 하는 이유는 하나의 프로그램을 만드는 답이 여럿이기 때문입니다.답이 하나여도 가르치기 어려운데, 다양한 방법을 어떻게 가르쳐야 하는 걸까요? 또, 기상천외한 학생들의 코드를 보며 이해하고 교육하는 것이 얼마나 긴 시간이 필요하며 어려운 일인가요? 어디서부터 해결해나가야 할지 막막합니다.Elice 리서치 팀에서 하는 일 중 하나는 학생들의 수많은 코드 중 비슷한 타입들을 추려내는 것입니다. 코드를 몇 가지 타입으로 추려내고 나면, 선생님은 학생 하나하나의 코드를 보고 교육하는 것이 아니라, 비슷한 형태의 코드를 작성한 학생 그룹 전체에게 적절한 피드백을 줄 수 있습니다. 이렇게 그룹 전체에게 피드백을 준다면 선생님은 같은 시간에 더 많은 학생을 교육할 수 있을 것입니다.그럼 이제, 비슷한 코드를 어떻게 찾아내서 분류할지 이전 연구를 보며 알아봅시다. (현기증이 날 수 있으며, 다 이해할 수 없어도 괜찮으니 걱정하지 마세요!)지프의 법칙과 숙제 제출 패턴자연어 처리(Natural Language Processing;NLP)를 배울 때 자주 거론되는 사람이 있습니다. 바로 미국의 언어학자인 조지 킹슬리 지프George Kingsley Zipf인데, 이 사람이 만든 지프의 법칙은 자연적으로 일어나거나 생성되는 특정 정보들이 일정하게 나타내는 경향을 나타낸 것입니다. 지프는 영어로 된 텍스트를 분석하던 도중, 자주 쓰이는 단어를 순서대로 나열하면 각 단어의 빈도는 그 단어의 출현 순위에 반비례함을 찾아냈습니다. 영어에서 가장 많이 사용되는 단어 1~3위가 “the”, “of”, “and” 인데, “the”는 “of”의 약 두 배, “and”의 약 세 배의 빈도를 보입니다.이것을 수학적으로 표현하면, 일정 크기 이상의 영어 말뭉치(corpus)에 들어 있는 단어들의 개수를 전부 세서 그 단어들을 가장 많이 쓰이는 것부터 순위를 1위부터 나열했을 때, 특정 단어의 순위가 k 라면 (즉 전체에서 k번째로 많이 쓰인 단어라면) 그 단어가 말뭉치에서 쓰인 개수는 1/k에 비례한다는 것입니다. 이것을 그래프로 그려보면 다음과 같습니다. 재미있는 사실은, 여기에서 x축과 y축에 log를 씌워 보면 (이것을 log-log scale로 변환한다고 합니다.) 다음과 같은 직선 형태로 변환된다는 것입니다.이것이 도대체 숙제 제출과 무슨 관계가 있길래 이렇게 장황한 설명을 한 것일까요? 위에서 나온 지프의 법칙을 기억하시나요? 학생이 낸 숙제를 채점하다 보면 꽤 많은 학생이 비슷한 방식으로 숙제를 푸는데, 제출된 풀이 방식들을 비슷한 것끼리 묶어 분석해 보니, 이것 또한 지프의 법칙을 따른다는 것이 발견되었습니다. 예를 들어 가장 인기 있었던 풀이 방식으로 100명이 숙제를 제출했다면, 두 번째로 인기 있는 풀이 방식으로는 약 50명이 숙제를 제출했다는 뜻입니다.여기서 우리가 찾아낼 수 있는 인사이트는 무엇일까요? 첫째, 학생들의 숙제들을 비슷한 것끼리 묶을 수 있다면, 그리고 이 분류를 컴퓨터로 자동으로 할 수 있다면 조교가 채점하거나 코멘트를 할 때 써야 할 시간이 상당히 줄어들 것입니다. 둘째, 방법 서너 개에 대해서만 어떻게 채점할지 혹은 어떻게 코멘트할지에 대해 준비를 해놓으면, 그걸로 숙제 대부분을 채점/코멘트할 수 있을 것입니다. 대다수의 숙제는 몇 가지 인기 있는 풀이방식으로 만들어졌을 것이기 때문입니다.그러면 이제 다음 문제는, ‘비슷한 풀이 방식으로 푼 프로그램 코드’를 어떻게 찾아낼 것인가? 를 고민해봅니다. MIT의 Elena Glassman은 이에 대한 해법으로 Overcode를 제시했습니다.Overcode뉴스 기사나 책, 블로그 글 등 자연어로 이루어진 텍스트 데이터를 분석하고, 여기에 어떤 주제가 들어있는지 밝혀내는 연구는 많이 진행 됐습니다. 이를 위한 머신러닝 알고리즘 중 하나가 토픽 모델, Topic model 입니다(토픽 모델에 대해서는 다른 글에서 자세히 다룰 예정입니다). 그러나 토픽 모델링을 프로그래밍 문제에 실제로 적용하기는 쉽지 않습니다. 코드에 사용되는 문법이나 키워드가 자연어와 1:1로 매칭되지 않기 때문에, 기존에 자연어에서 사용되던 모델을 그대로 사용할 수 없기 때문입니다. 가령, 슬쩍 보면 무척 달라 보이는 아래 두 파이썬 코드는 사실 완전히 같게 동작합니다. 이 두 코드를 (사람들이 일상생활에서 사용하는) 자연어를 분석하는 모델로 분석한다면 제대로 된 결과를 낼 수 없는 건 당연합니다.def fibonacci(): parents, babies = (1, 1) while babies < 100 xss=removed>fibonacci()def fib(parents, babies): ‘’’ parents = 1 babies = 1 ‘’’ while True: print ‘This generation has {0} babies’.format(babies) parents = babies # set parents as babies babies = parents + babies # recursively add number of babies if babies >= 100: break fib(1, 1)Elena Glassman이 제시한 Overcode의 목적은 비슷한 로직으로 만들어진 프로그래밍 코드들을 모으는 것입니다. 이제 Overode가 어떻게 작동하는지 간단하게 소개하도록 하겠습니다. 가장 먼저 수행되어야 하는 것은 서로 다른 형식으로 쓰인 소스 코드들을 정리하는 것입니다. 소스코드 정리에는 주석 제거, 줄 및 공백/들여쓰기를 일정하게 맞추는 작업 등이 포함됩니다.Image from Overcode하지만 이 작업만으로는 충분하지 않습니다. 거의 같아 보이는 코드도 실제로 프로그램을 실행하기 전까지는 같은지 알 수 없고, 꽤 달라 보이는 코드도 실제로는 완전히 같게 동작할 수 있기 때문입니다 (여기서 같게 동작한다 함은, 결과를 같게 내는 것 이상으로 결과를 내는 중간과정이 완전히 같다는 것을 의미합니다). 다시 위로 돌아가, fibonacci() 함수와 fib(parents, babies) 함수를 살펴봅시다. 위 두 코드는 기존의 자연어 처리 기법에 따르면 완전히 다른 프로그램일 것입니다. 변수명이 달라서가 가장 큰 이유일 텐데, 사실 컴퓨터의 입장에서 변수는 어떤 값을 할당하는 공간에 불과하며, 그 공간에 어떤 이름을 붙이느냐는 중요하지 않습니다. 코드를 작성하는 것이 사람이기 때문에 공간에 편하게 이름을 붙이는 것뿐입니다. 서로 다른 프로그램에서 어떤 변수가 서로 같은 역할을 하는지, 컴퓨터가 알아내려면 어떻게 해야 할까요? (컴퓨터는 창의적이지 않습니다!)Image from OvercodeElena가 제시한 방법은 프로그램을 실행하면서 변수의 값이 어떻게 바뀌는지를 추적한 것입니다. 아래 두 코드를 보고, 한번 머릿속으로 프로그램을 실행해 봅시다. 학생 B의 코드는 for문으로 5의 3승을 계산했고, 학생 C의 코드는 while문으로 5의 3승을 계산한 것입니다. 학생 B의 코드가 실행됨에 따라 r이라는 변수가 어떻게 변하는지, 학생 C의 코드에서 result가 어떻게 변하는지 확인해보면 둘 다 1 → 5 → 25 → 125 의 값을 가지게 됩니다. 그렇다면 컴퓨터는 이렇게 판단할 수 있습니다. “B의 코드에서의 변수 r과 C의 코드에서의 result가 완전히 같은 방식으로 변하니, 같은 의미로 사용된 것이다.”Image from Overcode이제 같은 의미를 가지는 변수들을 알아냈다면, 컴퓨터는 쉽게 가장 “흔한” 이름으로 변수의 이름을 바꿔치기 합니다. 그러면 처음에 서로 다르게 보였던 코드들도 이제 같아질 것입니다.물론 이것이 다는 아닙니다. 예를 들어, 간단한 테스트 케이스들을 통해 결과를 비교함으로써 변수를 분석하기 전에 먼저 거르는 방법, 너무 흔한 변수들을 처리하는 방법 (예를 들어 완전히 다르게 동작하는 코드들에서도 반복문에서 사용되는 인덱싱 변수들은 같이 변화할 것입니다), 한 변수가 다른 의미론적으로 두 번 사용되는 경우 처리하는 방법… 등이 논문에는 더욱 자세히 적혀있습니다. 궁금한 독자들은 한번 논문을 읽어보도록 합시다.남은 문제들Elena가 제시한 방법은 위에서 보여준 예제와 같은 간단한 코드에서 꽤 잘 동작합니다. 예를 들어, 다음과 같은 문제들이 있습니다.a의 b승을 구해서 리턴하는 프로그램N번째 피보나치 숫자를 리턴하는 프로그램다항식의 미분 결과를 리턴하는 프로그램하지만 대학교에서 1학년만 넘어가더라도 이런 간단한 프로그램 과제는 내지 않습니다. 예를 들어 Elice에서 교육 중인 기초 프로그래밍/ 프로그래밍 유치원 수업을 듣는 학생들은 매우 많은 실습문제를 풉니다. 여기에서 푸는 과제들은 초반 몇 주가 지나면 이 정도의 간단한 프로그래밍 수준을 뛰어넘기 때문에, 코드가 꽤 길어지고 다양성이 생기게 되는데 이런 경우 이 방법은 잘 동작하지 않습니다.또 다른 문제는, 이 방법이 “동작하는” 코드에서만 작동한다는 것입니다. 예를 들어, 수강생들이 아직 기초 문법을 배우고 있다면? 제대로 실행도 되지 않는 코드를 만들었을 때, 비슷한 실수를 한 사람들끼리 묶어주고 싶다면? 아쉽게도 Elena가 제시한 방법은 이렇게 에러가 나는 코드에서는 동작하지 않습니다. 코드가 실행되지 않는다면 변수의 값의 변화를 추적할 수 없기 때문입니다.마치며이번 포스트에서는 학생의 제출 코드를 비슷한 것끼리 묶는(Clustering하는) 방법에 대해 간단하게 살펴 보았습니다. 학생이 낸 비슷한 답안을 모아주는 솔루션은 수학 문제 같은 단답식 문제, 혹은 영어 에세이같은 자연어에 대해서는 이미 상용화가 되어 있습니다. 영어 에세이의 경우 여러분들이 가장 친숙할 만한 상용화된 솔루션은 아마 copy detector일 것입니다.하지만 프로그래밍 코드의 클러스터링은 연구가 계속 진행되고 있습니다. 앞서 말했듯 코드에서 한 글자 한 글자가 가지는 의미가 자연어에서 가지는 알파벳과는 완전히 다르기 때문이기도 하고, 정말 실행을 해 보기 전까지는 어떻게 동작하는지 예측하는 것이 매우 어렵기 때문이기도 합니다. Elice 리서치 팀에서도 프로그래밍 코드에 대한 분석을 자동으로 수행하는 머신러닝 연구를 수행하고 있습니다. 이러한 기술을 통해 선생님이나 조교가 학생을 더욱 효율적으로 지도하고, 컴퓨터의 도움으로 지도에 아낀 시간을 한 단계 더 개인화된 도움을 주도록 하는 것이 Elice의 목표 중 하나 입니다.글쓴이김수인: KAIST 전산학부 박사과정 / Research Lead, Elice김재원: KAIST 전산학부 박사과정 / The Lead, Elice배휘동: KAIST 전산학부 박사과정 / Frontend Lead, Elice#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개
조회수 3187

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

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

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

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

'구루급' 개발자란...

'구루'라는 단어는 이제 '수준급'을 넘어선 분들에게 부여되는 의미 있는 호칭이다. 특히, 개발자 사회에서는 비공식적으로 '구루급'이라고 불리는 개발자들이 있다. 이 정의에 대해서 누가 명확하게 옳다고 이야기할 수 있는 것은 아니다.다만, 30년 동안 소프트웨어 개발자로 살아오면서 만난 수많은 개발자들과 해외 유수의 개발자들과 만나고 소통하면서 느낀 개인적인 경험을 바탕으로 '구루급'에 대해서 정의를 해보겠다.매우 당연하게 이 정의는 전적으로 객관화된 것이 아닌, 매우 주관적인 기준이다.보통, '구루'급 개발자라고 불리는 분들을 보면, 오픈소스로 한 획을 그었거나, 그의 뜻을 따르는 후배들이 많거나, 특정 분야의 경험이 매우 풍부한 분들을 대상으로 이야기한다.다만, 이 기준에 '돈'을 많이 벌었거나, 특정 제품이나 게임, 서비스를 잘 만들었다는 식의 기준은 들어가는 것은 일부 논외로 하겠다. 이것은 전적으로 개인적인 기준이다. 이런 분들은 '구루급'개발자가 되기보다는, 산업적이거나 경제적으로 크게 성공한 기준이 더 높기 때문이며, 금전적으로 성공한 분들이 '후배'들에게 개발자로서의 영향력을 주는 것이 사실상 어렵기도 하거니와, 이미 비즈니스의 단계로 넘어간 분들이기 때문에 '구루급'개발자라고 이야기하기에는 모호하다고 개인적으로 이야기한다.그렇다면, 내가 생각하는 구루급 개발자의 최소한의 필요조건을 나열해 보자. 전적으로 개인적인 기준이니 너무 주관적이라고 비판하지 마시기를... 그 이유는 정말 주관적이기 때문이다.하나. 하나의 소프트웨어나 도메인을 10년 이상 장기간 개발 및 연구하고 있는가?둘. 자신만의 개발 문화에 대한 철학과 그 기준을 가지고 실행하고 있는가?셋. 자신이 소유하거나 만들어낸 개발 도구나 방법, 기술에 대해서 후배 개발자들에게 전파하고 있는가?넷. 후배 개발자들에게 존경받는 개발자로서의 기본적인 성품을 가지고 있는가?다섯. 후배 개발자들에게 자신의 롤을 양보하거나, 팀과 조직을 위해서 자신의 자리를 포기할 줄 아는가?여섯. 자신의 먹을거리를 위해서 비용을 싸게 부르지 않고, 후배들도 대우를 받을 수 있도록 너무 싸게 일하지 않아야 한다는 것을 실천하는가?제가 생각하는 '구루급'개발자의 조건입니다.분명, 이렇게 활동하는 '구루급'개발자들이 주변에 존재하고 있으며, 이를 위해서 개발자의 처우에 대해서 노력하기도 하고, 불합리한 경영자들과 논쟁을 벌이기도 합니다. 자신의 개인적인 이익만을 위해서 움직이지도 않는 그들이야말로 '구루급'개발자 아닐까요?그리고.대부분의 구루급개발자들은 충분한 대우와 보수를 받고 일하고 있습니다.그것이, 후배 개발자들의 처우와 미래를 위해서 매우 필요하다고 생각하고 있기 때문이죠.저는 '구루급'개발자를 그렇게 생각합니다.ps.최고의 개발자, 슈퍼개발자 등에 대한 호칭도 있을 수 있습니다. 제가 생각하는 '구루'급 개발자는 후배들에게 존경을 받고, 후배들의 처우나 개발자들의 미래에 대해서도 고민하고 실천하는 분들에 대해서 정의해 본것입니다.
조회수 859

[Tech Blog] Keep Principles in Mind

원칙(Principle)은 중요합니다. “난 원칙대로 살지 않겠어!” 라고 외치고 싶더라도, 원칙이 있고 원칙을 충분히 이해하고 있지 않다면 그저 사춘기 소년/소녀의 이유 없는 반항 정도로 밖에 들리지 않을테니까요. 사실 대부분의 이런 경우 원칙 보다는 “규칙(Rule)대로 살지 않겠다”에 가깝지만, 여기에서는 그냥 넘어가도록 하죠. 소프트웨어 개발에도 다양한 원칙들이 존재합니다. 학부 수업에서 잠깐 들었거나 이런 저런 글들을 읽다가 접해 봤을 이런 원칙들은 실제 서비스를 만들면서 바쁘게 기능을 추가하고 버그를 수정 하느라 어느새 기억 속에서 잊혀지곤 하죠. 정신없이 기능을 구현하다가 문득 코드를 돌아봤을 때 ‘이게 왜 여기에 있지’ 라는 의문이 든다면 한 번쯤 원칙을 되새겨 보라는 신호가 아닐까요? 이 글에서는 Clean Architecture 와 Clean Code 등의 저자로 유명한 Uncle Bob(Robert C. Martin)이 얘기하는 S.O.L.I.D Principles 에 대해 얘기해 보려고 합니다. SOLID 원칙은 밥 아저씨가 2000년도 자신의 논문 Design Principle and Design Patterns 에서 OOD(Object-Oriented Design)를 위해서 제안한 5가지 원칙의 앞 글자만 떼서 붙여졌습니다. Object-Oriented Design 을 대상으로 제안된 원칙이지만 Agile 개발 등의 개발 방법론 핵심 철학에도 적용될 수 있는 개념들 입니다. S.O.L.I.D Principles Single Responsibility Principle Class 는 오직 한 가지의 책임이 주어져야 하고, 오직 한 가지 이유에서만 변경되어야 합니다. 보고서를 편집하고 출력하는 모듈에 대해서 생각해 볼까요. 해당 모듈은 두 가지의 이유로 변경될 가능성이 있습니다. 보고서의 내용이 바뀌었을 때도 변경되어야 하고, 보고서의 형식이 바뀌었을 때도 변경되어야 합니다. 편집 과정 때문에 모듈을 변경하다 보면 해당 변경 사항이 출력 부분에도 영향을 미칠 가능성이 상당히 높습니다. 이 경우 내용을 편집하는 모듈(i.e 내용을 담당하는 모듈)과 출력하는 모듈(i.e 형식을 담당하는 모듈) 두 가지로 나뉘어야 합니다. “할 수 있다고 해서 해야 한다는 뜻은 아닙니다.” Open / Closed Principle Class, Module, Function 등의 소프트웨어 구성 요소는 확장(extension)에 대해 열려 있어야 하며, 변경(modification)에 대해 닫혀 있어야 합니다. 어떤 모듈이 Data Structure 에 필드를 추가하거나 함수를 추가하는 등 확장이 가능하다면 그 모듈은 확장에 대해 열려 있다고 표현합니다. 반면에 어떤 모듈이 수정 없이 다른 모듈에 의해 사용될 수 있다면 그 모듈은 닫혀 있다고 표현합니다.  public class CreditCard {     private int cardType;       public int getCardType() { return cardType; }       public void setCardType(int cardType) { this.cardType = cardType; }          public double getDiscount(double monthlyCost){          if (cardType == 1) {              return monthlyCost * 0.02;          } else {              return monthlyCost * 0.01;          }     } }  위 CreditCard class 에 새로운 카드 타입을 추가하려고 하면 getDiscount 함수를 변경할 수 밖에 없습니다. 이 경우 Open/Closed Principle 을 위반된다고 볼 수 있습니다. “코트를 입기 위해서 개복 수술을 할 필요는 없으니까요.” Liskov Substitution Principle 프로그램 상의 Object 들은 프로그램의 정확성을 해치지 않으면서 하위 타입의 Instance 로 변경 가능해야 합니다. 하위 타입 함수 인자의 반공변성(Contravariance), 하위 타입 함수 반환 타입의 공변성(Covariance), 상위 타입의 예외를 상속하지 않는 추가적인 예외 발생 금지 등의 요구 사항이 있습니다. OOP 에서 상속 개념을 배울 때 이해를 돕기 위해 주어진 몇 가지 예시들이 있었을텐데, 우습게도 우리가 생각하기에 타당한 상속에 관한 예시들 중 의외로 원칙을 위배하는 경우가 많습니다. Liskov Substitution Principle 을 위반하는 대표적인 예시는 정사각형과 직사각형입니다. 정사각형은 직사각형의 일종이니 Square가 Rectangle을 상속받는 것이 충분이 타당한 것으로 보입니다. 정말 그럴까요? Rectangle 의 넓이를 구하는 함수의 테스트를 구성해 봅시다.  Rectangle rect = new Rectangle(); rect.setWidth(10); rect.setHeight(20); assertEquals(200, rect.getArea());  여기에 new Rectangle() 대신에 new Square()가 rect 에 할당되면 어떻게 될까요? 넓이는 400 을 반환하기 때문에 테스트는 실패하겠죠. 정사각형이 직사각형을 상속 받으면 Liskov Subsitution Principle 을 위반한다고 볼 수 있습니다. 상속은 문제를 해결하는데 있어서 상당히 유혹적인 방법입니다. 하지만 상당히 많은 경우에 상속을 오용할 가능성이 높습니다. “오리처럼 생기고 오리처럼 꽥꽥 거리더라도, 배터리가 필요하다면 오리가 아닙니다.” Interface Segregation Principle 많은 것을 아우르고 일반적으로 사용 가능한 하나의 interface 보다 특정 클라이언트를 위한 여러 개의 interface 가 낫습니다. Xerox는 Stapling(프린터기가!?), Fax 등의 다양한 기능이 포함된 신규 프린터 소프트웨어를 개발 도중, 더이상 개발이 불가능할 정도로 프로그램이 번잡 해졌다는 것을 인정하고 밥 아저씨에게 도움을 요청합니다. 문제는 Job Class 하나가 모든 기능을 다 구현하고 있다는데 있었습니다. 이 비대한 Class 는 Client 입장에서 사용되지도 않을 모든 함수를 알 수 있게 구성 되어 있었죠. 이 문제에 대해 밥 아저씨는 Interface Segregation Principle 을 적용하여 각 Client 입장에서 사용해야 하는 함수 만을 가지고 있는 각 interface 들을 따로 만들었습니다. 그리고는 다음에 나올 Principle 인 Dependency Inversion Principle 을 통해서 해당 기능을 구현하게 함으로써 문제를 해결했습니다. Dependency Inversion Principle “추상화에 의존해야지, 구체화에 의존하면 안됩니다.” 상위 계층의 모듈은 하위 계층의 구현이 아니라 추상화에 의존해야 합니다. 상위 계층이 하위 계층의 구현에 의존하던 전통적인 의존 관계를 역전 시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있습니다. 예를 들어 Dependency Injection 은 이 원칙을 따르는 방법 중 하나 입니다. Conclusion 세상에 나쁜 프로그램은 있습니다. 당장 눈에 보이는 기능이 똑같다고 같은 프로그램인 것은 아닙니다. 생각보다 많은 코드들이 ‘그 곳에 넣을 수 있기 때문에’, ‘그 곳에 넣어도 돌아가기 때문에’ 깊은 고민 없이 그 곳에 정착합니다. 당장 좀 더 빠르게 기능을 추가해서 주변 사람들의 박수를 받을 수도 있습니다. 허나 이것들이 쌓이면 더이상 손댈 수 없는 코드가 되고, 문제를 느끼고는 Refactoring을 하자고 다짐하고, 모두 엎은 다음 또 다시 같은 코드를 만들게 되겠죠. 쉬운 코드가 가장 만들기 어려운 코드이고, 그런 좋은 코드는 좋은 원칙으로 부터 나옵니다. 변화에 적응할 수 있는 프로그램, 의도가 쉽게 읽히는 프로그램, 문제 발생 가능성이 적은 프로그램, 쉽게 확장할 수 있는 프로그램 등 좋은 프로그램을 만드는 것은 우리가 실제로 목표하는 것을 달성하기 위해서 정말 중요합니다. 이는 그저 경험이나, Tweak 만으로 이루어지지 않습니다. 다양한 신규 기술들과 Framework 들을 두루 섭렵하면서 활동 반경을 넓히고 경험을 쌓았다면, 가끔은 잠시 서서 원칙에 대해 되돌아 보는 것은 어떨까요?   *버즈빌에서 활기찬 개발자를 채용 중입니다. (전문연구요원 포함)작가소개 Whale, Chief Architect “Keep calm and dream on.”
조회수 1200

안드로이드 개발자의 고민 Fragment (2)

이전 글 보기: 안드로이드 개발자의 고민: Fragment이번 글에서는 Fragment stack 관리와 Fragment 데이터 Lifecycle 관리 이슈를 줄일 수 있는 해결 방법을 찾아보겠습니다. 이전 글에서는  Fragment를 하나의 View로 관리하는 오픈소스를 검토했었습니다.하지만 검토하는 중에 기존 오픈 소스의 변경과 버전업 관리 이슈의 문제를 그냥 넘어갈 수는 없었습니다. 상용 소스에 바로 적용하기에는 리스크가 크다고 판단해 좀 더 신뢰할 수 있는 방법을 선택하기로 했는데요.요즘은 작년 6월에 Google IO 에 발표한 AndroidX의 내용을 다시 검토하고 있습니다. Deeplink를 통한 목적 화면과 Fragment 스택 관리가 중요한데, 이 기능을 도와주는 것이 AndroidX Navigation이기 때문입니다. 화면 전환을 UI 기반으로 사용하여 화면 관리를 용이하게 만들었습니다. 물론 코드 기반에 익숙한 저는 적용하는데 시간이 걸렸죠.기존의 Fragment 관리는 FragmentManager를 통하여 개발자가 직접 코드 상에서 관리했습니다. 하지만 Navigation의 경우에는 아래와 같이 직관적으로 설정할 수 있습니다.firstFragment -> secondFragment -> thirdFragment 로 화면 간의 흐름을 설정합니다. 하나의 Navigation 파일은 하나 이상의 Activity 에서 사용할 수 있습니다.이 방식은 오히려 현재 사용하는 브랜디 소스와 비슷합니다. 하나의 Activity에 ActivityFragment를 만들어서 1:1 매핑으로 화면을 Fragment를 관리하는 방식과 유사합니다. Navigation 의 세부내용은 Google Developers에서 확인할 수 있습니다.Deeplink 를 통한 Fragment Stack 관리도 간단합니다.Notification 또는 Serice 등에서 PendingIntent를 사용하여 테스트할 수 있습니다. Navigation Fragment stack 순서대로 화면을 쌓은 다음 최종 destination Fragment 로 도착합니다. 이와 같은 방법으로 Push를 통한 화면 관리를 쉽게 할 수 있습니다. 이 내용은 여기에서 자세히 확인할 수 있습니다.신속한 마무리기존 Android 에서 화면 관리가 불편했다면 Navigation으로 직관적이고 쉽게 화면을 관리할 수 있을 겁니다. 브랜디는 아직 적용할 준비 중이지만, 꼭 kotlin과 Navigation을 적용해보려 합니다. 그럼 다시 개발의 숲으로 들어가보겠습니다.글고재성 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만
조회수 2686

React + Decorator + HOC = Fantastic!!

React + Decorator + HOC = Fantastic!!지난 포스팅에서는 ES7의 Decorator 문법을 이용해 선언된 클래스와 그 프로퍼티들을 디자인 시간에 변경하는 법을 알아보았습니다. 그렇다면 리액트 컴포넌트와 Decorator가 만나면 어떤 시너지가 발생할까요?만약 ES7의 Decorator에 대해 모르신다면 지난 포스팅을 읽고 오시는 걸 권장합니다. 이 포스팅은 독자들이 Decorator에 대해 이미 알고 있다고 가정하고 작성됐습니다.Higher Order Component리액트 공식 문서를 보면 Higher Order Component(이하 HOC)를 다음과 같이 설명하고 있습니다.리액트 컴포넌트 로직을 재활용할 수 있는 고급 기법리액트에서 공식적으로 제공하는 API가 아니라 단순히 아키텍쳐이 설명으로는 HOC가 어떤 역할을 하는지 이해하기는 역부족이기 때문에 간단한 예제를 통해 HOC를 어떻게 작성하는지 알아보겠습니다.function withSay(WrappedComponent) {     return class extends React.Component {     say() {       return 'hello'     } render() {       return (                   {...this.props}           say={this.say} />       )     }   } } withSay 함수는 WrappedComponent를 인자로 받아 원하는 속성들을 결합해 새로운 컴포넌트를 반환합니다. 이렇게 만들어진 withSay 함수는 아래와 같이 사용 가능합니다.@withSay class withOutSay extends React.Component {     render() {     return (               {this.props.say()}           )   } } withOutSay 컴포넌트는 say 메소드를 가지고 있지 않습니다. 하지만 withSay 함수를 사용하니 say 메소드를 사용할 수 있게 됐습니다. 이처럼 컴포넌트를 인자로 받아 입맛에 맞게 바꾼 뒤 새로운 컴포넌트로 반환하는 기법을 HOC라고 부릅니다.그렇다면 HOC는 리액트에서 어떻게 사용을 해야 효율적일까요?Cross Cutting Concerns개발을 하다 보면 다음과 같은 상황에 직면하는 경우가 종종 있습니다.개발 전반에 걸쳐 반복해서 등장하는 로직그럼에도 불구하고 모듈화가 쉽지 않은 로직예를 들어 방명록 작성, 게시글 작성, 게시글 스크랩을 하는 컴포넌트들에서 유저 인증과 에러 처리의 과정이 필요하다고 했을 때 어떻게 코드를 디자인해야 할까요? 컴포넌트와 직접적으로 연관이 없는 기능들이 컴포넌트와의 결합이 너무 강해 쉽게 모듈화를 시키지 못합니다.그림 1. Cross Cutting Concerns의 예시이렇듯 코드 디자인적인 측면에서 공통적으로 발생하지만 쉽게 분리를 시키지 못하는 문제를 Cross Cutting Concerns라고 합니다. 이 문제를 끌어안고 가면 프로젝트의 코드는 쉽게 스파게티가 되고 나중에는 유지 보수를 하기 힘들어집니다.하지만 우리게에는 HOC와 Decorator가 있고 이를 이용해 이 문제를 쉽게 해결할 수 있습니다.유저 인증 문제를 HOC로 해결아래는 인증이 안된 유저에게 다른 페이지를 보여주는 코드입니다.class TeamChat extends React.Component {     constructor() {     super()     this.state = {       unAuthenticated: false     }   } componentWillMount() {     if (!this.props.user) {       this.setState({ unAuthenticated: true })     }   } render() {     if (this.state.unAuthenticated) {       return     }     return I'm TeamChat   } } 유저 인증을 전통적인 if-else 구문으로 구현했습니다. 당장 이 컴포넌트를 본다면 문제가 없어 보입니다. 어떻게 보면 정답처럼 보이기도 합니다. 하지만 유저 인증이 필요한 컴포넌트가 많아지면 상황이 달라집니다.100개의 컴포넌트에서 위와 같은 방식으로 유저 인증을 하고 있는데 유저 인증을 하는 로직이 변경된 상황을 생각해 봅시다. 100개의 컴포넌트 모두 유저 인증 코드를 바꿔야 하는 상황에 직면하게 됩니다. 전부 다 바꾸는 것도 일이지만 실수로 몇 개의 컴포넌트를 수정하지 않을 확률이 농후합니다. 당장에는 간단하지만 잠재적 위험을 안고 있는 위 코드는 아래와 같이 수정되어야 합니다.function mustToAuthenticated(WrappedComponent) {     return class extends React.Component {     constructor() {       super()       this.state = {         unAuthenticated: false       }      } componentWillMount() {       if (!this.props.user) {         this.setState({ unAuthenticated: true })       }     } render() {       if (this.state.unAuthenticated) {         return       }       return     }    } } HOC를 이용해 확장이 용이한 유저 인증 로직이 탄생했습니다!! 이렇게 만들어진 HOC는 아래와 같이 적용이 가능합니다.@mustToAuthenticated class TeamChat extends React.Component {     render() {     return I'm TeamChat   } } @mustToAuthenticated class UserChat extends React.Component {     render() {     return I'm UserChat   } } 기존의 코드와 비교했을 때 코드가 훨씬 간단해진 것을 확인할 수 있습니다. 비단 코드만 간단해진 것뿐만 아니라 아래와 같은 추가 효과를 기대할 수 있습니다.유저 인증 로직이 컴포넌트와 분리가 되어 자신이 맡은 역할에만 집중할 수 있습니다.유저 인증 로직이 바뀌어도 코드를 수정해야 할 곳은 하나의 컴포넌트뿐입니다.예시로 작성한 HOC는 최소한의 코드로만 작성된 예시입니다. 실제 제품에서 사용되기 위해서는 몇 가지 고려해야 할 사항이 있는데 이는 리액트 공식 문서를 참고해주세요.i18n 컴포넌트를 HOC로 작성채널 서비스는 한국어, 영어, 일본어를 지원하기 때문에 번역 기능이 필요했습니다. 초기에는 번역 서비스를 아래와 같이 구현했습니다.@connect(state => ({   locale: getLocale(state) }) class Channel extends React.Component {     render() {     const local = this.props.locale     const translate = TranslateService.get(locale)     return (               {translate.title}         {translate.description}           )   } } 처음에는 위와 같은 방식으로 번역 서비스를 구현하는 것이 괜찮았습니다. 하지만 번역을 제공해야 하는 컴포넌트가 많아지면 많아질수록 중복되는 코드가 많아지는 것을 보고 아래과 같이 HOC를 이용해 코드의 중복을 제거했습니다.function withTranslate(WrappedComponent) { @connect(state => ({     locale: getLocale(state)   }))   class DecoratedComponent extends React.Component {     render() {       const locale = this.props.locale       const translate = TranslateService.get(locale) return (                   {...this.props}           translate={translate} />       )    }   } } 이렇게 작성된 HOC는 아래와 같이 사용이 가능합니다.@withTranslate class Channel extends React.Component {     render() {     const translate = this.props.translate     return (               {translate.title}         {translate.description}           )   } } HOC의 작성 방법은 예시로 작성한 두 개의 HOC에서 크게 벗어나지 않습니다. 이를 응용해 자신의 프로젝트에 맞는 코드를 작성해보세요.중첩 가능한 HOCHOC는 여러 개를 중첩해서 사용할 수 있습니다.. 예를 들어 유저 인증과 i18n 서비스를 동시에 제공하고 싶을 때 두 HOC를 중첩해서 사용하면 됩니다.@mustToAuthenticated @withTranslate class Channel extends React.Component {     render() {     return (               {`Hello!! ${this.props.user.name}`         {translate.title}         {translate.description}           )   } } 마무리이상으로 리액트에서 HOC를 사용할 수 있는 상황과 작성 방법을 알아보았습니다. 본 포스팅에서 다루지는 않았지만 만능처럼 소개한 HOC에도 몇 가지 단점은 존재합니다.Component Unit Test를 할 때 문제가 있을 수 있습니다.HOC를 몇 개 중첩하면 디버깅이 힘들 수 있습니다.WrappedComponent에 직접적으로 ref를 달 수 없어 우회 방법을 사용해야 합니다.비동기 작업과 같이 사용하다 보면 예상치 못한 결과를 만날 수 있습니다.하지만 이러한 단점에도 불구하고 상속을 제공하지 않은 리액트에서 HOC는 많은 문제를 효율적으로 해결해주는 단비와 같은 존재입니다. 유명한 리액트 라이브러리들(react-redux, redux-form 등)은 이미 예전부터 HOC를 사용해 사용자들에게 편의를 제공해 왔습니다. 이러한 라이브러리들과 자신의 프로젝트가 직면하고 있는 문제에 맞는 HOC를 작성해 같이 사용한다면 우아하고 아름다운 설계에 한층 더 다가간 프로젝트를 발견할 수 있습니다.마지막으로 한 문장을 남기고 본 포스팅을 마치도록 하겠습니다.React + Decorator + HOC = Fantastic!!본 포스팅은 2017 리액트 서울에서 발표한 내용입니다. 발표 자료와 발표 영상을 확인해보세요.#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지

기업문화 엿볼 때, 더팀스

로그인

/