기억하기 위한 개발노트

[마소콘 2018] 빚을 탕감하기 위해 없애야 할 3가지(서버, 융통성, 그리고..) 강연내용 후기.

18 Dec 2018 | MASOCON 마소콘 기술부채 Serverless 융통성 Surprise

다음 강연은 빚을 탕감하기 위해 없애야 할 3가지 방안을 소개하였다.

여기서 빚을 탕감하기위해 없애야 할 3가지란..?

  1. 서버.
  2. 융통성..
  3. 그리고…

실제 코스모체인 기반의 파일럿 서비스를 짧은 시간내에 개발, 운영하면서 생긴 기술부채를 어떻게 갚아 나갔는지에 대한 내용이었다.

다음은 없애야 할 3가지에 대한 설명 및 이유이다.

1. 서버

Serverless로 개발한 이유.

  • 기획이 구체적이지 않고 기획이 짧을땐 간단한게 좋다라고 판단.

Serverless를 통해 기술부채를 감소한 부분.

  1. Serverless : 클라우드 서비스(AWS) 사용. 매니징할 서버가 없다는 의미.
  2. 클라우드 프론트, API Gateway, Lambda, DynamoDB 를 주로 사용하여 개발. (EC2 사용안함. 로드밸런싱 등등 따로 설정 필요 X. )
  3. 빚은 애초에 덜 지는게 좋다고 생각. 우리는 언제? 급할 때 진다. 기술부채라고 다르지 않음.
  4. Serverless 일 경우 스팩변경 부담 감소.
    • 의존성 관리 생각보다 큰일 (패키지 버전업.. 모듈 업데이트 마다 연관된 패키지가 많음. 큰 패치라도 있으면 큰 맘먹고 하는일이 되어버림.)
    • 람다 기반의 서버리스 펑셔널 기반의 구조: input/output 명확.
  5. 각 Function은 독립된 프로세스로 동작 (기존 동작을 보장한다.)
  6. 연관된 모든 모듈의 개발 및 테스트가 완료될 때 까지 기다리지 않고 순차적으로 적용 가능.
  7. 간편한 배포 : 오류가 많았으나… 배포가 간단하여서 빨리 해결하고 배포 하는데 무리가 없었음. 무중단 배포는 덤.
  8. 적재적소로 최적의 spec 구성가능. Spec 변경의 부담 감소.
  9. 오토스케일링.

위 장점을 공유하며 빠른 피드백을 요구하는 서비스엔 Serverless 라고 강조하였다.

2. 융통성

서비스 개발이나 일정에 융통성, 예외 사항을 두지 않기.

EX ) 우리는 왜 빚을 질까

  • 갚을능력되면 빚을 짐.
  • 시장 선점.
  • 비즈니스 성장.
  • 일단 동작하게 만듬.
  • 당장 App 사용에 문제가 있으니 융통성을 발휘하여 error 부터 막음.

그러나 빚쟁이한텐 자비가 없고 기술부채도 마찬가지이다.

Twil 소개 (This week I Learned) : 한 주간 개발자가 공부한 내용을 공유하는 자리.

  1. 데일리 미팅 후 5~15분
  2. 기술블로그 발행 ( engineering.huiseoul.com)
  3. 많이 모인김에 컨퍼런스도 열어봄
  4. 특징 : 노 융통성! -> 서비스 오픈날에도 함.

Twil을 하면서 사람들은 뭘 공부할까 궁금하여 통계를 내봄.

  1. 기본적으로 궁금한것들을 공부 함.
  2. 5월에 Lambda에 빠짐. 람다 기본개볌 핸들러 로컬테스트
    • 람다와 관련한 프레임워크 apex, aped up…
  3. 잘하고 싶은것 공부 (찜찜한것)
    • 반영한지 오래되서 다시보고 싶은 코드 구조.
    • 기능 추가/개선이 까다로운 코드 구조.
    • 똥이되는것.
  4. 자산으로 남기고 싶은것
    • 시행착오
    • 구글에 안나오는것.

제품과 직접적인 관련 있는것들이 77%
결국엔 개발자들의 업무 능력 향상으로 기술 부채 상환이 이루어짐.

마지막으로..

3. Surprise

  • Surprise는 놀라게 하다. 경악하게 하다의 뜻…

개발자가 많이하는 Surprise.

  1. 로컬에 몰래 따놓은 브랜치. 고독한 실험. 예고없이 올라온 PR
  2. 프로젝트 방향성과 조금 다른 개발
    • ex) 기획에 없는 개발…
  3. 최최최최신기술, 핫핫핫핫한기술
    • 검증 불가.

Surprise 시엔 미리 동료들에게 공유 할 것을 요청하였다.

갑툭튀 노노…

번외로 팀으로 일해서 좋은 이유를 설명하였다.

  1. 내 프로그램 X : 책임이 분담되고 혼자서는 못 이뤄낼 결과물이며 동료의 재능을 이용 할 수 있다는 점. 생각지 못한 아이디어를 줄 것이라고 하였다.
  2. 혼자서 다 하지 않아도 됨. -> 규모가 크거나 팀에 필요한 일이라면 분담하게 될 것.

결론 : 빚도 자산이다.
갚아나가는 과정에서 기술 노하우도 쌓고 팀원들하고도 가까워질 수도 있다~!

Q & A

  1. 팀웤다지는방법?
    • 데일리미팅 (10시 정각에 만남, 컨디션, 오늘 무슨일했는지, 내일 무슨일했는지.. 실제는 목소리를 듣는것이 목적.)
    • 리뷰 (깃랩사용. 껄그러운 일이 없도록 치열하게 리뷰를 함. 하지만 나쁜소리만 할 수는 없으니 칭찬도 곁들인다.)
  2. 서버리스 불편한점.. 문제점.?
    • 불편한점은 러닝코스트 필요.. 컴퓨팅을 대신해주는걸 지는 대신에 AWS 계속 알아야 하는 단점.
    • 생태계가 많이 올라오지 않음. 레퍼런스
  3. 람다쓰시면서 마이크로서비스를 올리면.. 비용차이면에선?
    • 람다가 차지하는 비율이 전체에서 20%밖에 안듬. 하지만 서비스에 따라 다르므로 검토가 필요.

느낀점

강연자분이 매우 명확한 3가지의 방법을 제시해주었다.
실제로 기술공유에 대한 부분이나 갑툭튀 개발을 하는 경우에 대한 부분에 대하여 많은 공감을 하였다. 서버리스에 대한 부분은 들으면서 .. “아 저렇게도 할 수 있겠구나.” 라는 생각이 들어 서비스가 그렇게 크지 않을 경우 시도해 볼만 하다는 생각이 들었다.
(다른것 보다 부하에 대해 신경을 조금 덜 써도 된다는 기대가 좀 들긴했다., 최근에 맡은 서비스가 종종 트래픽이 몰려오는 서비스라..)
일단 공부차원에서 먼저 저 구성에 대하여 찾아봐야겠다. (사실 클라우드 프론트랑.. 람다만 조금 써봤다..)

관련자료

  • https://www.imaso.co.kr/archives/4481
  • http://it.chosun.com/site/data/html_dir/2018/12/15/2018121500760.html

Related Posts

Comments