RT:FM, 나는프로그래머다 컨퍼런스2016 참석 후기

지난 금요일 RT:FM, 나는 프로그래머다 컨퍼런스 2016 가 개최되어 휴가를 내고 다녀왔습니다. 

내용 전문은 추후 한빛 미디어에서 영상본을 올려주실 것 같은데, 일단 제가 듣고 느낀 내용은 기록 차원에서 올려둡니다. (강연 동영상 보기)

 

-----------------

1.서버리스 미디어 개발기, 삼성SDS AgileCore Team 

*서버리스 아키텍처로 구현.  

-Serverless = github, AWS 등 서버를 따로 운영하지 않는 서비스 환경을serverless라고 칭함

*애자일로 프로젝트를 할 수 있도록 crossfunctional 팀으로 구성된 조직. 50여명이 있고, 개발자, 디자이너, 기획자, PM이 한 팀 소속으로 일함. 

*팀 단체 톡방에서는 많은 대화가 오가서 뉴스를 공유하면 흘러가버리는 점이 아쉬웠다. 그래서 팀 내에 뉴스나 새소식, 세미나 등의 정보를 공유할 수 있는 앱을 구현하고자 시작.  

*안드로이드 개발자라 안드로이드 앱으로 먼저 개발했는데, 팀원 중 1/3만 쓰고 있었다. 왜 안쓰는지 봤더니 팀 내에 아이폰 유저가 많았음. 그래서 iOS로도 개발하고자 팀 내에 도움을 요청했고, iOS 개발자가 붙으면서 web도 함께 구현하기 시작. 이 과정에서 서버리스로 개발하게 됨. 

*React의 jest로 tdd가 가능했다. 

*7 days project at GitHub처럼브랜치 7개 만들어 두고, 매일매일 새로운 브랜치에 유저 스토리 하나씩 구현해서 추가되는 과정을 올렸다. 

느낀점) 
* 스토리 단위로 일을 쪼갤 수 있어야 하고, 업무를 진행해 나간 히스토리가 보인다. 이는 내가 어떻게 했는지 복기도 쉽다는 뜻. 더불어 깃 브랜치 관리도 할 줄 알아야 한다. 

* 이 세션을 들으면서 느낀건, 자발적으로 뭔가를 만들어보길 시도하는 사람들이 새로운 툴이나 기술을 접하게되는 것 같음. 시도하는 과정에서 요즘 트렌드가 어떤지, 더 빠르고 쉽게 만들 수 있는 방법을 찾으면서 새로운 시도를 하게 되는 것 같다. 반대로 말하면 하던 일만 계속하면 쓰던 툴이나 방법에서 벗어나기 어렵다는 뜻이기도 하다. 

2.라쿠텐 (http://global.rakuten.com/en/)

*라쿠텐의 아키텍트 커미티 소속

*Rakuten Travel 로 서비스를 확장할 때 searchplatform을 구성하며 고려했던 것에 관한 이야기. 

*Verification에 대한 부분이 인상적이었음.(verification-서비스를 론칭할 때 최소한의 요구사항으로 검증요건이자 설계할 때 고려해야하는 부분)  

*유저 엑세스 시간에 대하여response 를 주기까지 정확한 리밋 타임을 갖고있음. 유저가 쿼리를 날리면 시스템에서 DB 엑세스 해서 다시 유저에게 response하기 까지 최대 이만큼이란 값을 검증 요건으로 둠. 

*각 검증 요건(시스템 최소 요구 조건)에서 고려했던 기술들과, 각 요건에서 어떤 기술이 가장 적절했는지를 별 하나씩 메김. 몇달동안 전체 검증요건에서 가능한 기술을 다 검토하고 나서 별이 가장 많은 것 선택. 

-만약 신기술인데 내부에 바로 대응할 수 있는 팀이 있다면 그것이 별점을 맞기도 함. 

-비용 측면으로 비교해서 비슷한 수준의 기능을 지원하나 노력과 비용이 적은 것. 

-노가다가 심한 것은 개발팀의 의견을 받아 제외하기도. 

*기술을 선택한 후의 이슈는 어떻게 싱크하고 시스템을 만들어갈지 였음. 설계하다보니 이슈가 드러남. 

-처음 설계했던 것 대비 구현하면서 우선순위가 바뀐다던지, 

-네트웍 상에서 데이터 큐에 도달하는 순서가 바뀌는 문제라던지. 실제 구현에서 나오는 이슈들…. 

-어쨌든 데이터 싱크에서 발생했던 문제는 모두 해결해서 론칭함. 

*하지만 이슈 잡았다고 바로 프로덕션 서버로 반영할 순 없으니 몇 달간 검증작업을 거침. 

*mongo db, reddis 

느낀점) 

* 웹서비스 회사 사람들 대부분 애자일 워터폴로 각 프로젝트마다 다르단 얘길 하는데 그게 가능한 이유가 뭘까? 포트폴리오 레벨의 요구사항이 잘 정리돼서? 오히려 자신들이 하는게 너무 당연해서 흔히 말하는 애자일의 일부라는걸 모를수도 있을 것 같다. 이미 그만큼 웹서비스 쪽에선 애자일이 너무나도 당연한 것이 되어 새롭게 이야기 되지 않는 경향이 있음.

3.Makeus, 장애없는 서비스를 위한 서버리스 개발 (https://makeus.com/)

*지난 지진 때 서버가 다운된 곳이 많았다. 카카오톡, 국민안전처, 7시간... 

-이유?? 갑자기 트래픽이 몰려서 스케일업이 어려웠음. 스케일러가 없었나? 

*그래서 까봤다. 그 당시 request102개, 용량 800k

*도대체 왜 다운됐을까? 

-Bandwidth. 10명이면 8M. 

-I/O load error

-unknown error …

*그 때 전문가 왈, “클라우드로 이전했으면 해결됐을 것이다.”라고 했다. 근데 정말일까? 

-No. 클라우드는 그저 편하기 위해서일 뿐. 만병통치약이 아님. 

*모든 서버는 대체로 cpu 점유율 10% 미만으로 운영됨. 거기서 나온게 클라우드, 서버리스 아키텍쳐로 확장. Docker.

*유저 스트레스에 따라 자동 스케일이 가능하다고 aws,azure가 말함..

*그럼 리스크가 뭐지?? 

-docker가 올라올 때까지 응답이 느리거나, 응답이 없음. 첫 로딩이 느리다. 

*클라우드 서비스들이 SLA라는걸 둔다. (SLA : 서비스품질에 대한 게런티. 99.9% 이런거)

-구글 99.9%,azure는 99.95%.‘한달에 24분은 다운될 수 있다’는 뜻. 근데 AWS엔 SLA가 없음. 

-SLA는 클라우드 공급자가 서비스를 얼마나 인정시켰는지 보여주는 척도. 클라우드 업체에서 최소한 이건 지키겠다는 안정 기준. 

*서버리스 아키텍처는 재난상황에서 스탠바이 스케일업이 가능하긴 함. 

*그렇다면 국민안전처 홈페이지 뭐부터 바꿀까? CDN. 

-AKAMAI 100%

-KT CDN 100%. (해외는 AKAMAI를 쓰니까 국내 기준을 거기에 맞춰야 해서 KT CDN도 100%) 

-CloudFront 99.9%

*이렇게 0.05% 정도는 다운될 수 있는데, 그럼에도 불구하고 왜 서버리스를 써야하나? 

-클라우드의 발전 방향 때문. 

-과거 SE가 하던 일이 지금은 개발자에게로 이전됨 = DevOps

-지구 온난화... (고작 CPU 10% 돌리려고 켜두는 수많은 컴퓨터를 꺼서 CO2 발생을 줄이자…) 

*앞으로 올 클라우드 기술은? 

-그림자 노동과 노가다를 줄여주는 쪽으로. 개발자가 개발만 할 수 있게..

4.스타트업 1인 개발 극복기, 스위처, 아이오 (https://www.switcher.kr/)

*발표 주제

-작은 스타텁에서 함수형 언어를 도입하기 위해 하고있는 것들

-작은 스타텁에 중간에 조인하면서 겪은 일들

*함수형언어 시작 계기

-내가 생각한 문장을 그대로 코드로 옮길 수 있다. 직관적

-비즈니스 로직과 더 유사한 코드로 바꿀 수 있다. 

*그럼 자바스크립트를 그냥 함수형 언어처럼 써도 되지 않냐? 

-함수형 언어의 철학은 sideeffect 없는 프로그래밍을 지원하고 장려하는 것.  

-그래서 스칼라? 스칼라는 언어 차원에서 sideeffect 없는걸 지원하고 장려하는 언어라서 함수형 언어라는 세상으로의 다리 역할을 하는 언어라고 생각한다고. 

*스타트업 1인 개발 극복기

-신생 스타텁에서 자신이 했던 일들을 '복기'하여 공유하기 위해 발행했던 슬라이드가 힛트침. 

-1,2차 신청 때 문제없었음. 3차 신청 때 서버 문제가 생김. 문제의 조기 발견은 좋은 상황이라고 봄. 

-3차 때 발생한 서버 이슈를 계기로 개선할 일 리스트업. 여러가지 중 Step 1에서 할 일은 ‘사용자의 불만'만' 없애자.’로 선택하고 그것을 개선하는 것에만 집중. 

-재개발은 (1) 고객들이 '진짜로' 사용하고 있는 기능, (2) CS 문의가 많은 기능. 궁극적으로 성공. 

-2차 목표는 수작업이 많았던 멤버들에 집중. 많이 개선함. 

-2차 목표 달성으로 현재 5000명 달성!! 

질문) 개선할 일 중 프로세스 개선이 있었는데 어케했는지? 

-내가 생각했던 프로세스는 의사결정과 배포 프로세스에 대한 것. 

-이전엔 개발자가 하고 싶은 걸 먼저 하고 있었음. 각자 알아서 배포하고 형상관리도 안되는 상황. 

-팀원들이 모두 빨리, 쉽게 실천할 수 있도록 새로운 룰은 가장 심플하게 정했다. 깃 브랜치 잡고, 배포 프로세스를 잡음. 

질문2) OOP에 익숙한 개발자들을 함수형으로 어떻게 설득했는지

-일단, 우린 tdd를 강요하는 문화라서 모두가 tdd를 해야 함.

-매주 sw세미나에서 함수형 프로그래밍을 소개했을 때 sideeffect 제거한다는 부분에서 팀원들이 호기심을 갖게 됨. 그 당시 문제를 갖고 있던 개발자가 있었기에 더 관심을 가지게 됐고, 함께 실천할 수 있었음.