180709-180715

2018년 07월 09일 ~ 2018년 07월 15일 주간 회고


180709-180715 주간회고

Weekly Review

  • 이번 주 토요일에는 AWSKRUG Hands-on Lab 2018 : Container #3, Kubernetes on AWS Hands-on에 다녀왔다.
    • 쿠버네티스가 너무 궁금해서 다녀왔는데.. 생각보다 쉽지 않았다 ^^.. 더 열심히 공부해야지!
  • 퇴근 후 공부할 때 코딩보다는 기술 책을 읽는 시간이 대부분이였던 한주였다.
  • 책 읽는 시간이 많으니 효율적인 독서를 위하여 내가 어떻게 책을 읽는지 정리.
    • 책을 한 번 읽고 시간이 지나면 항상 잊어버리게 된다. 그렇다고 한 번 더 읽기에는 읽고 싶은 책이 너무 많고…
    • 독서법에는 여러 가지 방법이 있지만 나는 책을 읽은 뒤 덮고 머릿속으로 한번 정리한다. 그리고 TIL(GitHub repo)에 정리를 한다. 복습 시 검색하기 쉽고 다른 사람들에게 공유도 되니 일석이조다. 더 좋은 방법이 생긴다면 바뀌겠지만 당분간은 계속 이 방법을 유지할 계획이다.

학습

다음 주 목표 (꾸준히 읽고 정리하고 강의듣기)

이번 주에 읽었던 좋은 글(출퇴근지하철)

  • 람다, 모르고 쓰면 병이다  내부 로직을 어느 정도 이해하고 있어야 한다. 어설프게 이해하고 사용하다가는 독이 될 수도 있다.
    • cold start, warm start 상태에 따른 응답 속도 차이, 사용할 수 있는 메모리의 한계 등을 보았을 때 해당 function의 실행 시간이 5분 이상 넘어가고 메모리를 4GB(커널 포함) 이상 사용해야 한다면 람다가 아닌 다른 시스템을 고민해봐야 할 것이다.
    • 이전 글인 람다, 서버리스의 첫걸음도 한번 같이 읽어보면 좋다. 이해하기 쉽게 함수 생성해서 사용하는 방법을 알 수 있다.
  • 뽀모도로 기법과 시간관리에 대한 회고  이 글 작성자와 마찬가지로 나도 올해 초부터 뽀모도로를 이용해서 일과 공부를 하자…라고 생각했지만, 실천을 하지 못하였다. 다시 한번 시작해봐야겠다!
    • 오늘 해야 할 일들을 우선순위에 따라 리스트업한다.
    • 뽀모도로 타이머 앱을 키고 25분 집중 5분 휴식을 반복한다.
    • 한 뽀모도로 사이클엔 한 가지의 일에만 집중한다.
    • 4뽀모도로마다 20분을 쉰다.
    • 그리고 매일 저녁 그 날 몇 개의 뽀모도로를 했는지 기록하며 회고하고 개선할 점을 찾는다.
  • 좋은 개발자 / 유명한 개발자   글의 첫 문장이 “한국의 개발 문화와 커뮤니티의 성장을 저해시키는 요소 중의 하나는 특정 회사/스터디 출신들 중심의 닫힌 네트워크라고 생각한다.” 라고 임팩트 있게 시작한다.
    •  오래전부터 계속 생각해온 ‘좋은 개발자’의 덕목은 결국 기술로서 비즈니스의 성공을 도울 수 있는 사람이다.
    • 하고 싶은 이야기는, 역량이 떨어지는 사람을, 결과를 만들어내지 못하는 사람들을, 친분을 이유로, 같은 네트워크에 속해있다는 이유로 치켜세우거나 포장해주는 풍토가 개선되지 않는 이상, 한국에서 개발자에 대한 인식과 문화는 발전하기 어렵다는 것이다
    • 적어도 서비스를 위해 일하는 개발자라면, 기술적 욕심보다는 서비스의 성공에 모든 역량을 투자하자.
  • 번역, 왜 소프트웨어 테스팅이 DevOps의 핵심인가
    • 아직 대부분의 조직에서 DevOps의 업무를 품질과 관련해 생각하지 않는다. 이전에 비해 코드를 더 빨리 배포할 수는 있지만 코드 상태가 엉망인 경우가 많다. 품질이 전제되지 않는 ‘지속적인 배포’는 단지 고객에게 ‘지속적으로’ 버그 투성이 코드를 전달하는 것과 같다.
    • 넷플릭스, 아마존 그리고 엣시(Etsy)와 같이 최고의 DevOps 퍼포먼스를 수행한다고 알려진 조직에서는 소프트웨어의 품질을 보장하기 위해 리그레션 테스팅, 성능 테스팅, 부하 테스팅, 그리고 보안 테스팅을 자동화해 수행하고 있다. 또한 DevOps의 파이프라인 안에 이들 테스팅을 구현하고 모든 빌드를 대상으로 이 테스트를 수행한다.
    • 기존의 업무와 역량을 지렛대삼아 DevOps 파이프라인에 테스팅 자동화를 강화함으로써 소프트웨어 라이프사이클 후반에 특정 그룹에서 발생한 무제로 인해 배포가 중지되는 상황을 미연에 방지할 수 있다.
  • 8년째 같은 제품을 만들고 있습니다. 남현우
    • 하드웨어, CPU, 프로그램, 시스템 디자인들의 공통점은 복잡한 현실에서 살아남기 위해 조랍하기 방식을 선택했다는 것
    • 우리가 하는 일 : 요구사항을 체계적으로 제품에 반영하는 것.
      • (1)요구사항을 분해한다. (요구사항명세를 요구하게 된 문제들을 찾기)
      • (2)프로세스를 분해 (프로세스는 순서로 짜여진 단위 작업들, 단위 작업이 component.)
      • (3)작업자도 분해. 컴포넌트에 짜여진 누가(by whom)와 무엇을(what)을 분해
    • Quick & Dirty
      • 지저분하더라도 일단 빠르게 만든다.
      • Agile!
      • Learn!
      • MVP!
    • 조금 더렵혀도 되는 것 (나중에 치우기 쉬운 것)
      • 시각적인 일관성
      • 불친절한 UX
      • 코드 품질
      • 성능 및 안정성
    • 함부로 더럽히면 안되는 것 (시간이 지나도 수습이 안되는 것)
      • 문제 영역 (Domain)
        • 너무 넓은 문제를 푸는 것은 아닐까?
      • 재사용성(Composability)
        • 언젠가 조립될 수 있을까?
    • 도메인을 스파게티처럼 만들었으면, 뭘 해도 스파게티 코드만 나온다.
    • 재사용성을 관리하지 못하면, 장기적으로 빠르게 움직일 수 없다.
    • Automation(자동화)의 이면
      • 문제를 잘 푸는 것이 아닌, 빨리 푸는 것
      • 하지만 문제는 계속 변한다. (전략이 변하니까)
      • 효율적 != 효과적
      • 분해된 단위 작업을 결합하여 프로세스를 만드는 것
        • 컴포넌트가 짜여지고 있지는 않은지?
    • 가치 제안
      • 오래도록 진화하는 제품을 만들자
      • 프로그램을 짜지 말고 제품도 짜지 말자
      • 건강한 컴포넌트를 많이 만들고 잘 관리하자
      • 우리만 쓰지말자(API 등…)
  • 한 달 만원으로 스타트업 VPN 구축하기(SoftEther VPN, OpenLDAP, FreeRadius) AWS EC2 t2.micro를 이용해서 한 달 유지비 만원을 지불하고 사내에서 VPN을 사용할 수 있는 방법을 제공한다. 오픈소스 SoftEther VPN, OpenLDAP, FreeRadius 등이 여러 프로토콜들을 컨트롤해서 VPN을 구축할 수 있게끔 도와준다. 스타트업과 같은 작은 규모의 집단에서는 위와 같은 방법을 사용해도 크게 무리 없을 것으로 보인다.
  • 소프트웨어를 모르는 대한민국 기업의 위기 얼마 전 MS가 GitHub을 8조 원에 인수하게 되었는데 이런 깃헙과 같은 소프트웨어의 가치를 대한민국 기업에서는 아직 인지하고 있지 못한 것 같다는 현실을 말해주고 앞으로 회사의 성장을 위해서 소프트웨어를 개발하는 사람들이 있어야 할 것이라고 알리는 글이다.
  • 개발 방식의 변화를 위한 GS SHOP 고군분투기 -(1) 요청받고 납기일에 맞추는 정해진 방식에서 헤처모여식 사내커뮤니티 그룹에서 함께 가치를 빠르게 확인하는 방식으로 변화하고 있다. -(2) 개발 빠르게하기에는 우리의 레거시는 아주 복잡하고 너무 뚱뚱하다. 그래서 다이어트를 위해 API Gateway로 구멍을 뚫고 클라우드에서 인공위성 서비스를 띄워 개발하며 변화하고 있다. -(3) 개발은 엄청난 기술을 습득해서 빠르게 코딩하는 것이 중요한 것이라고 생각했었는데 실제 이런것들을 해보니 결과물을 빠르게 보여주고 판단할 수 있게 하는 것이 더 중요하는 것을 알고 변화하고 있다.

  • 우아한 형제들 CTO 김범준이 추천하는 개발 도서 10권 
    1. 실용주의 프로그래머 - 저자 : 앤드류 헌트, 데이비드 토머스
    2. THE C Programming Language - 저자 : Brain W. Kenighan, Dennis Ritche
    3. 리팩토링 - 저자 : 마틴 파울러
    4. 테스트 주도 개발 - 저자 : 켄트 백
    5. 피플웨어 - 저자 : 톰 드마르코, 티모시 리스터
    6. 익스트림 프로그래밍 - 저자 : 켄트 백, 신시아 안드레스
    7. 해커와 화가 - 저자 : 폴 그레이엄
    8. 소프트웨어 장인 - 저자 : 산드르 만쿠소
    9. 클린코드 - 저자 : 로버트 C 마틴
    10. Computer Systems - 저자 : Randal E. Bryant
  • 불가능하다던 ‘51% 공격’이 점점 늘어나는 이유  얼마 전 까지만 해도 51% 공격은 성공 가능성도 작고 설사 성공한다 해도 그 많은 돈을 다 빼 올 수도 없어서 51% 공격은 안 하느니만 못하다는, 그래서 결국 블록체인 네트워크는 51% 공격을 걱정하지 않아도 된다는 주장을 믿고 있었다. 하지만 최근 여러 코인들이 공격을 받고 피해를 입었다. 여러 전문가들은 소규모 코인들이 주로 공격 대상이 된다고 설명한다. 채굴자들이 적고, 그만큼 해쉬파워의 51%를 장악하는 데 드는 비용도 상대적으로 크지 않기 때문이다. 나 역시 비트코인, 이더리움 등의 큰 규모 코인들은 이런 일이 발생할 가능성이 낮아 보이긴 한다. 하지만 앞으로 어떠한 방식의 공격이 발생할지 모른다. 블록체인이 앞으로 어떻게 발전해 나갈지 너무 궁금해진다.
  • 알고리즘 학습에 대한 조언 왜 회사는 알고리즘 문제를 내는지, 어떻게 공부해야 하는지에 대한 레퍼런스를 제공하는 글이다.
  • 백기선 - 스프링 가이드, 토비의 스프링 그렇게 보지 마세요 
    • 스프링 학습 로드맵
      • 그런게 어딨음? 없음
      • 그럼 수 많은 책들은 뭐냐? 저자가 중요하다고 생각한 내용을 저자 마음대로 써둔 것 뿐
      • 제일 중요한건 바로 "너", "당신", "자신"
      • 스프링을 알고 싶은데 어디서 부터 어떻게 공부를 해야 할지 모르겠다 라고 하지만 질문에 아주 중요한 뭔가가 빠졋음
      • 얼마나 알고 싶은데?
      • 얼마나
        • 대충 뭔지는 암 – 중요한 개념 들은 알아 – [가성비] – 좀 깊게 알아 – [넘사벽] – 다 알아
    • 스프링의 “스”자도 몰랐을 때
      • 뭐에 쓰는지 코드를 보고 익히는게 좋다.
      • 객체 생성, 서블릿 안쓰고 웹 앱 개발? 이런게 잇구나~
      • 문제는 금방 까먹는다. 백견이불여일타
    • 오 좀 더 궁금한데?
      • 코드도 보고 이젠 렌퍼런스랑 책도 가.볍.게 봐야함
      • 핵심을 파악할 것
      • IOC 컨테이너, AOP, 추상화 계층(MVC, JDBC, Resource, O/X M, O/J M 등등)
      • 예제 코드 하나씩은 직접 짜볼 것.
      • 이거 이해하고 짜보는데 그 두꺼운 책이나 레어펀스를 다 읽을 필요가 있음?? 없음
      • 토비의 스프링보다가 조금 딥하다 생각하면 그냥 지나가라! (처음부터 끝까지 무식하게 보지마라!)
      • 감만 잡고 코딩할 수 있을 정도면 지나가도 된다.
    • 오 이제 좀 쓰는데 자신이 생기네…
      • 좀 더 공부하면 뜯어 고쳐서 뭔가 껴 넣을 수도 있을거 같은데?
      • 누가 물어보면 알려 줄 수도 있을 것 같아… 블로깅 해볼까?
    • 이정도 단계까지하면 애플리케이션 개발할 때 크게 문제는 없다. 
    • 사랑에 빠져 버렸어
      • 이젠 막 다 보기 시작한다.
      • 토비의 스프링 정독, 레퍼런스 꼼꼼히 읽기, 스프링 프레임워크 소스 코드 열어보기
      • 프레임워크의 구조나 설계에 관심을 가지게 된다.
      • 코드 기여를 하고 싶어질지도 모른다.
      • “현수.. 하고 싶은 거 해~”
        • 발표, 코드 기여, 블로깅, 강의 등
      • 하지만
        • 가성비 나오는 시점은 이미 넘었다는거.
        • 아마도 다른 기술에 투자해야할 시점인지도 모른다.
  • “스타트업 둘 중 하나는 블록체인 비즈니스 준비” 내가 블록체인 공부를 하고 있는 이유, 그래서 공감을 할 수밖에 없는 기사다.
    • 블록체인이 의미있는 비즈니스 플랫폼이 되려면 대중성을 갖춘 블록체인 기반 서비스, 이른바 디앱(Dapp)이 나와줘야 한다는데 토를 다는 이들은 없다. 사용자들에게 익숙하면서도 탈중앙화로 대표되는 블록체인 기술의 특성을 잘 살린 디앱이 많아져야 블록체인도 애플이나 안드로이드급의 서비스 생태계로 진화할 수 있다. 거물급 퍼블릭 블록체인들이 디앱 서비스 지원에 속도를 내고 있는 것도 이 때문이다.
  • NDC16 스매싱더배틀 1년간의 개발일지 자신만의 게임을 만들고자 퇴사 후 1년간 1인 개발을 했던 한대훈(한군)님의 이야기이다. 개발자들은 누구나 마음속에 자신이 만들고 싶은 무언가가 있을 것이다. 나 역시 생각은 많지만, 항상 “아직은 아니다, 아직은 실력이 부족하다, 시간이 없다” 등의 이유를 둘러대며 미루고 있었다. 이 슬라이드 자료를 보고 많은 것을 느꼈다. 하고자 하는 열정만 있다면 무엇이든지 가능하다는 것을… 한군님은 개발을 전문으로 해오셨던 분이 아닌데도 해냈다. 얼마나 큰 노력을 했는지 느낄 수 있는 부분이다.
facebook share twitter share
0%