logbook

[컨퍼런스] 20151007 TECH PLANET 2015

허니몬 2015. 10. 8. 09:59

1. 시럽페이로 풀어본 보안 이야기, 임형태(매니저, SK PALNET)


1.1. 시럽페이 소개

  • 간편결제
  • 비용지불이
  • 순수한 웹으로 구현된 시럽페이

1.2. 간편결제

핀테크와 다르다. - 핀테크: 은행권에서 사용하는 결제

  • Paypal과 같은 서비스 영역
    • 2015년 금융결제원에서 규제를 철폐하겠다는 발표를 하면서 10개의 서비스가 출현
    • 결제시장이 왜곡되고 불편했다.
  • 보안 > 사용자 권리
    • 획일화된 환경 요구
    • 보안!!

    '외부의 탈취와 훼손으로부터 보호'하는 것!!

  • 기존에 불편에 대한 생각을 다시 해보게 된다.
    • 불편한 것이 정말 보안을 위해 적절한 것인가?
  • 고민 & 과정
    • 키워드 중심의 보안 아키텍처(!?)
  • ‘해결 방법보다 숙제를 함께 풀고 싶습니다.’
    • 해결한 것보다, 해결하는 과정을 이야기하면서 숙제를 던진다.

    허니몬: 해결방법은 문제에 접근하는 사람과 관점에 따라 다양해질 수 있겠다.

1.3. 의사소통Communication

  • 사람과 사람, 컴퓨터와 컴퓨터, 컴퓨터와 사람
  • 의사소통 in 네트워크
    • Add WIFI
    • ‘모든 것은 네트워크를 위해 존재한다’
  • 불특정 다수의 네트워크

1.3.1. 인증Authentication, 누구냐 넌?

  • 식별을 하자.
  • 가맹점 and 사용자
    • 자원에 접근하고자 하는 모든 대상에 대해서는 인증해야 한다.

1.3.2. 가맹점 인증

  • OAUTH2
    • Client credentials
    • Grant 부여
    • ID/Secret token
  • Javascript Object Signing and Encryption
    • 무결성, 암호화를 위한 암호화 알고리즘, 알고리즘 데이터를 암호화해서 전달하고 이를 복화하여 사용하는거야?
  • http://jwt.io
  • 시럽페이의 가맹점 인증절차
    1. 사용자가 시럽페이 결제 선택
    2. 가맹점이 결제 데이터 구성 후 서명
    3. 시럽페이 서버로 전달
    4. 시럽페이 인증받고
  • 결제데이터 + 서명 = 가맹점 인증

1.3.3. 사용자 인증

  • 사용자 편의성
  • **Single Sign ON(SSO)**이 주는 이점
    • 패스워드에 대한 피로감을 줄여준다.
    • 토큰으로 인증을 대행한다.
  • Single Sign on 발급조건: 두가지
    • 자체 회원체계를 가진 신뢰된 가맹점
    • 해당 가맹점에서 접근에 대해 사용자의 명시적인 동의
  • 그외에는 ID/PASSWORD 방식 대응

1.3.4. 암호화 해시 함수

  • 단방향 암호화
    • 동일한 입력 = 동일한 출력
      • 인덱스, 성능
      • 암호화 취약성을 가져오게 된다.
      • **Dictionary(Rainbow Table) Attack
        = 구글 인터넷 검색을 통해서 처리
        = 고성능 기기를 이용한 처리
    • 빠른 처리 속도
      • Brute-Force Attack
  • 암호화 해시 함수 취약점 보완
    • Salt
      • **Dictionary(Rainbow Table) Attack 저항
      • 입력값에 대한 가변성을 줌
    • Key Stretching
      • Brute-Force Attack 저항
      • Strength를 부여
  • 패스워드 암호화 in 시럽페이
    • HMAC
    • PBKDF2: Password-Based Key Derivation Function2
    • Scrypt
    • Invidual Salt(32bits)
    • SHA256
    • 성능적인 문제가 걸릴 수 있지만, ID/PASSWORD 체계에서는 괜찮다.
    • 암호화에 대한 것은 개발팀에서 고려할 문제

1.4. 결제, 권한Authorization

  • 인증된 사용자가 얻은 권한
    • 접근 권한
    • 결제권한??
  • ID/PASSWORD 만으로는 결제에 대한 권한을 부여하기는 그렇다.
  • ID/PASSWORD + PIN
    • 결제 기능에 대한 접근권한을 얻기 위한 인증단계
  • 권한(AS OAUTH2) in 시럽페이
  • 권한을 위해서 인증이 필요하다.
    • 자원에 대한 접근을 하기 위한 수단
  • 적절한 인증을 거친 사용자에게 적절하지 못한 권한을 주었기 때문에 문제가 발생할 수 있다.
    • 보안: 인증Authentication과 권한Authorization의 적절한 정리가 필요함
  • 인증의 요소
    • KNOW(인증번호, 핀)
    • HAS(as SMS-OTP, ARS, OTP)
    • IS(as 생체인식)
      • 사용자가 쓰고 있는 컨텍스트
    • IN(Contextual, as FDS)
  • 결제수락

명시적으로 사용자가 결제를 하겠다는 의사를 취합

핀 번호 입력 == 카드를 긁고 사인을 하는 것과 유사함

  • 추가인증
    • 편리함 in 안전함
      • 결국은 인증과 권한의 균형 <- 제일 중요한 키워드군요.

1.5. 우리 둘만 아는 이야기, 의사소통(통신)

  • 불특정 다수로 이루어진 고통

  • 무결성과 암호화

    • 무결성: 정확성, 합리성
    • 암호화: 임의의 문자열로 부호화

  • TLS Transport Layer Security

    • 이런 것을 이용하는 훌륭한 체계가 있음
    • 그런데 왜 우리가 고민해야할까?
    • 현재 인증정보가 세션Current session state 에 저장하고, 이것이 없으면 TLS에서 사용할 수 없다.
    • 보호해야 하는 데이터의 생명주기가 TLS 세션 밖에서도 유지되어야 한다면 추가적인 무결성, 암호화 알고리즘 적용을 고려해야 한다. 시럽페이의 어느 개발자
    • TLS 안, TLS 밖

  • 암호화 알고리즘

    • JOSE JWA에 명시된 알고리즘을 사용
      = HS256
      = RS256
      = AI28CBC-HS256

1.6. 마치며

보안은 어렵습니다. ㅠㅠㅠ

  • 사슬의 약한 부분만큼 강하다.
    • 약한 부분에서 만큼의 강도를 가진다.
  • 굳이~ ActiveX, 보안모듈을 설치하지 않더라도 사용자에게 보안솔루션을 제공할 수 있는 서비스를 만들자.

1.7. 정리

  • 시럽페이 보안: 인증과 권한을 조화롭게 다루어 의사소통을 하도록 하여 결제를 편리하게 할 수 있도록 유도하는 것이 목표!!


비싼 점심. 맛있음. +_+)b


2. Fast and Beautiful: Serving High Quality Pohotos at Scale on Flickr, Hugo Haas



2.1. 플리커 고해상도 사진의 공유

2… 플리커의 사용자 경험 공유

  • 플리커, 훌륭한 컨텐츠: 멋진 사진들
    • 컨텐츠만으로즌 부족하다. 이것을 공유하기 위한 것이 필요하다.
  • 빠른 속도(쉽고! 짧고 분명한 가치) 문제
  • 높은 기술수준

2.3. 아름다움, WHhat does beautiful mean?

  • 주관적이지: 고양이 사진
  • Feature
  • 사용자가 사진을 맘에 들어할 지 그렇지 않을 지에 대한 기술적 접근

2.4. 빠름, What does fast mean?

  • API 응답성
  • 사진 제공
  • 스크린 스크롤 읽어오기
  • 화면비율
  • 여러가지 레벨로 적용가능
  • Server side -> User interaction

2.5. Challenge:

2.5.1. Designs are more immersive

  • 차이: 2009년도 vs 2015년도
    • 픽셀들이 이미지에 사용되어야 한다.

2.5.2. 해상도Resolution

  • 해상도, 사용자에게 제공하려고 하는 컨텐츠가 점점 거대해지고 있다.
  • 네트워크의 대역폭은 지역별로 차이가 크고 그렇게 높지 않다.
    • 아시아는 4Mbps 속도

2.6. 해결책

2.6.1. First things, Instrumentation!

  • 다양한 측정정보를 수집
    • 모든 계층에 대한 계측!!
      • 서버, 통신, 기기, 클릭

2.6.2. Analyze, Analyze, Analyze

  • 분석에 많은 시간이 소요됨
  • 최악,
  • 평균
  • 최선
  • 커넥션의 연결상태
  • 지리적인 부분
    • 한국
    • 싱가폴, 필리핀 등
  • 다운로드 속도, 렌더링 속도
  • 첫바이트, 라스트 바이트

2.6.3. 서버사이드 그리고 Latency

  • 서버사이드에서의 최적화!
  • 테스트 코드
    • 작성된 코드의 작성시기
    • 작성된 코드의 변경사항에 따라 속도의 영향을 끼친 것
    • 하드웨어의 변화
  • 하드웨어
  • 속도를 향상시키기 위해서 고려해야할 점들이 많다.
  • 속도에 대해 최대한 빠르게 파악하여 속도저하를 해결하려고 해야 한다.
  • 속도저하가 발생하는 것은 게으른 것이다.

클라이언트 - 서버, 160ms 차이

  • HTTP 통신
    • SSL Handshake
    • HTTP Request
      *** 500+ ms
    • Server-side Response
    • Data transmission
  • 최적화를 위한 포인트를 찾다.
    • 브라질에 있는 경우 15-40% 의 개선이 있었지만 실제로 느끼게 되는 것은 5-10% 향상효과밖에 없다.
    • 유저들에게 돌아가는 혜택이 줄어들 수밖에 없게 된다.

2.6.4. Where do we spend time when getting media?

  • connection && request + server processing + response transfer(Largest payload!!)
    • 전송 바이트를 줄일 수 있을까? Can we send less byte?
  • Encoding & compressing… with care
    • 사진을 더 압축!!
      • compressing!! noise
      • 600kb, 85kb 를 두고서 고객에게 이야기 했을 때 같다고 이야기할 것인가?
      • 노이즈를 줄이면서 압축효율을 높이고 싶다.

2.6.5. 노력을 통해 얻은 진전

  • 비슷한 화질을 50%의 사이즈로 전송할 수 있다. -> 비용이 높다.
    • 사이즈를 변경한다.
  • 원본사진을 가지고서 특정한 사이즈별로 만들어서 제공하게 되었다.
    • 원본 사이즈, 중간사이즈, 작은 사이즈
  • 오랜시간을 들여서 이미지의 크기를 줄이고 빠르게 전달할 수 있는 방법을 찾기 위해 노력했다.

2.6.6. 빈도?Latency

  • 360kb -> 3.7s, 120kb -> 2.9s
    • 작게 만들었지만 그보다 더 제한을 주는 요소가 있다.
  • 대역폭별 속도를 분석했다.
    • 특정시점에 이르러 비슷한 상황이 된다.
    • 클라이언트와 서버의 거리, 연결connection
    • 대역폭 vs 서버와의 거리
      • 서버와의 거리가 중요한 요인이다.

2.7. 문제점

2.7.1. Lowering the latency: bring content closer to the user

  • 페북과는 다른 플리커의 사용자와 친구 관계
    • 페북과는 다르게 플리커는 컨텐츠(풍경, 이미지)에 따라서 관심을 가진 대상들이 거리가 다양하게 된다.
    • 관심사의 거리
  • 15B 이미지를 다루는 것은 어렵다.
  • 이미지 카피를 사용자에 가까이 유지
    • user - Regional cache - Image store
    • 사용자가 만들어낸 컨텐츠를 제공하기 위한 다른 캐시를 도입

2.7.2. Regional cache & CDN to the rescure

  • 호주의 reginoal cache 로드타입 전후에 따른 속도차이
    • 컨텐츠를 유저 가까이 가져오면 큰 차이를 보이게 된다.

2.7.3. 시도

  • 서버의 속도를 향상
  • 이미지 사이즈 조절
  • 서버의 거리를 줄이기(Regional cache)를 통해서 사용자 가까이에 컨텐츠를 두었지.

서비스를 개선하기 위해 노력해왔지만, 이를 더 개선하기 위해서 더 할 수 있는 것들이 있을까?

  • 클라이언트가 속도를 향상시킬 수 있는 좋은 장소다.
    • Client is the best place to make things faster
    • 다음 장소, 이전 결과를 제공하여 사용자의 행동을 유도
    • 클라이언트가 사용자에 관한 컨텍스트를 가지고서 예측하여 먼저 제공한다.
  • 클라이언트를 스마트하게 만든다.
    • Make the client smart
    • Use local cache
    • 기회예측, 사용자 행동예측
    • But not too aggressively
      • 대역폭에 따른 사용공간의 변화
      • Prioritize request
    • 50~70% 예측
      • 이것은 치팅(눈속임?) 그렇다고 분노할 필요는 없지.

많은 시도!!!

2.8. 요약

  • 균형을 잡는 흥미로운 행위

    • 속도는 중요하다.

  • measure

  • Experiment

  • Look at all layers of the stack

  • 사용자client 측에서 시도할 수 있는 것들이 있을까??

    • 단축할 수 있는 것들이 많다.
    • 시도해볼 수 있는 것: 다각 사이즈 조절
    • 실제속도보다 빠르게 보이게 만들 수 있는 것

  • 캐시

    • 클라이언트를 제어한다.

  • 앱에서 어떤 것들을 제공할지를 결정하는 것이 중요하다.

  • jpeg, 포멧별로 접근, 요구사항이 다르다.

2.9. 정리

사용자에게 '쾌속’과 '아름다움’을 제공하기 위한 노력을 멈추지 마라. 속도를 저하시킬 수 있는 부분들을 찾고 찾아서 그것을 최적화를 시도하라. 그리고 최적화를 할 수 있는 적절한 공간은 사용자측 client 가 될 것이다. Cheatting!!

3. Sclable Network for the Next Generation Resource Scheduling: 공용준(아키텍트, 카카오: Andrew)



  • 아키텍트로 가는 길
    • 아키텍트는 슈퍼맨, 아키텍트가 가져야할 역량
  • 다음세대 자원관리를 위한 유연한 네트워크설계?

3.1. Term

3.1.1. Scale

  • Scale up vs Scale Out
  • 스케일을 키우는 방법은 두가지!!
  • Scale: 눈에 띄는 변화는 없어야 한다.

3.1.2. Network

3.1.3. Scale Network

  • 네트워크를 아무리 키워봐야 소프트웨어가 그대로면 별다른 변화는 없다?
    • 빵빵한 네트워크가 있다고 해도 그걸 활용할 수 없다면 슬프겠지…?
  • 2 by 4, 4명이서 2달해보고 잘되면 쉬자?
  • 개발자, Step(비개발자)들도 가상서버를 자유롭게 만들 수 있다.
  • 45000 krane, VM 서비스만으로 상당하나 규모를 사용하고 있다.
  • 오픈스택에 3000 VM을 가지고 있다.
    • 상당히 많은 것들이 구동되고 있으며,
    • 이를 AWS에 올렸으면 상당한 비용을 지불했어야 할 것이다.
    • 2, 3명이서 관리하고 있다.
    • 대부분의 시스템이 자동화되어 있기 때문에 적은 인원으로도 관리할 수 있게 되었다.

3.1.4. Scale growth -> 자원이 고갈되고 있다.

3.1.5. 개발자들의 욕심에 따라서 언젠간 자원은 고갈되게 된다.

  • CPU, Memory, Sotrage always experience shortage.
  • They hav skewness
  • IP is also Resource
    • IP 부족으로 서버를 생성할 수 없는 경우가 있었다.
    • IP는 까다로운 자원이다.
    • 서브넷을 나다는것은 게이트웨이가 분할되어 있고 게이트웨이는 지역성을 가지고 있다.
  • SDN without SDN: Openstack
    • 10.0.0.1/32 or IP 10.0.0.1 netmask 255.255.255.255
    • 유투브 조회수, Openstack foundation
  • SDN, Overlay 네트워크
  • VPN이 있는 회사가 좋은 회사?
    • 라우팅 테이블
    • private 네트워크를 겹치지 않도록 하는 경우가 많다.
    • 암호화
      • 암호화를 하기 위해서 CPU를 사용하면서 속도가 느려질 수 있어?
      • 암호화를 끌 수 있…
  • Calico, Cumulus linux
  • L2 네트워크 인스턴스의 단점
    • 뭔 이슈가 그리 많아!!
  • 라우터는 유연한 네트워크를 처리하기 위해 잘 갖춰져 있다.

3.2. Next Generation Resource

3.2.1. Container

  • 모든 리소스를 표준화
  • less mutable things
    • pips, gems, war, packages
  • 컨테이너만으로는 의미가 없다.
  • 컨테이너: 사이즈가 정해져 있다.
    • 해운업: 적재장이 정해져 있다.
  • IT 리소스가 표준화 되어 있다면 어떨까?!
  • 클라우드 서비스간에 인스턴스가 표준화 되어 있지 않다.
  • 서비스 제공자는 표준만 제공
  • 개발자가 아닌 곳에서 제공
    • 인프라도 힘들어 졌다.
    • 무조건 개발이다.

3.3. Nework Next generation Network Resource Scheduling

  • 프록시 의존적인 네트워크는 안정적이지 않다.
  • 네트워크
    • HTTP, CURL 을 통해서 접근하고 싶다.
  • Overlay 퍼포먼스가 좋지 않다.
    • tunnel == vpn
  • OPEN FLOW???, OVS???
  • multicast debugging…?

3.4. 컨테이너가 가지고 있는 네트워크의 속성을 변경해보자.

  • 컨테이너 내부 IP를 라우팅되는 IP로 변경해보자.
    • 제약사항들을 벗어던질 수 있다.
  • blog.midonet.org, using docker libnet
    • Container 를 위한 Dynamic 주소 처리가 가능해?
  • 조만간 이런 한계들이 개발될 가능성이 있다.

in this planet, we’re not alone.

3.4. 어려운 일 vs 시간이 오래 걸리는 일

3.5. 정리

제일 중요한 것은 한번 해보는 일이다.

KField network

컨테이너, IT 리소스 표준화, 네트워크 성능개선…

  • 도커Docker를 다뤄보자.

4. How to make your team successful with github(or Breaking silos), TAKAFUMI IKEDA(Sales engineer, Github) ikeike443



깃헙을 이용해서 성공적인 팀 만들기 저자

http://www.yes24.com/24/Goods/14725219?Acode=101


4.1. 성공으로 이끄는 팀 개발 실천기술 저술

  • github anna’s story

4.2. github universal 소개

  • 지금까지 소프트웨어를 사용하지 않았던 사람들이 자신의 문제를 해결하기 위해서 소프트웨어를 사용할 것이다.
    • 그래서 깃헙을 쓸거다.
  • NASA에서도 깃헙을 사용하고 있다.
  • PIXAR
    • 뛰어난 애니메이터와 엔지니어는 비슷한 점이 많다.
    • 이터레이션을 반복적으로 한다.
    • 팀웍이 중요하다.
    • 모든 팀원들이 훌륭한 애니메이터다.
  • GE
    • 이전까지 소프트웨어와 관련이 없다고 생각한 이들도 깃헙을 사용하고 있다.
  • 정부 기관의 정보를 깃헙에서 공개하고 여러사람들이 함께 만들어가고 있다.
  • 깃헙은 카페인을 좋아하는데, 알콜도 좋아한다.
  • Octoshop

4.3. Git LFS 1.0

  • Large File Storage 1.0
  • Integration Directory
  • YubiKey
    • 새로운 인증키

4.4. Agenda

  • Why do you need github

4.5. Why do you need github

4.5.1. Every company is a software company

  • 테크놀러지가 모두 소프트웨어와 서비스로 이동하고 있다.
  • 우버
    • 사람, 물건도 나나르고
  • 에어비앤비
  • 라인
    • 커뮤니케이션의 흐름을 바꾸고 있다.
  • 소프트웨어와 관계가 없다고 생각했던 기업들이 이동해가고 있다.

4.5.2. What’s happening in Dev world todays?

  • Needs
    • High velocity
    • good user experience & High Quality
    • Quck & innovation
  • Pain points
    • very slow & unreliable dev/deploy flow
    • no code review, no ci, too many regressions
    • No transparency, Reinvent the wheel, silos
      = 서로 만들고 있는 것을 몰라서 반복적으로 만드는 행위가 반복

4.6. Where software is built?

4.6.1. Github flow

4.6.2. Branching is quick and easy

  • Experimentation without risk
  • Branches should be shot lived
  • Github이 아니라 GIT이 가진 강점이지.

4.6.3. Collaborate with anyone on the Pull Request

  • 모든 사람들이 협업을 할 수 있게 되었다!?
  • Involve anyone to make it

4.6.4. Test it before merging

  • 머지하기 전에 테스트를 해서 검증하는 것이 중요하다.

4.6.5. Merge it! with any condition you prefer

  • Protected branches and required status
    • 깃헙 블로그에 보면 기능 나와있어…

4.6.6. Revert pull request

  • 풀리퀘스트 단위의 revert 기능을 제공
  • Pull request didn’t go as planned? revert!

4.6.7. Web Blame and Linked pull request information

4.6.8. Closing issue pull request

4.6.9. Global Issue and Pull Request

4.6.10. You can find everything here

  • Great talent, useful code are already here
  • 많은 것들을 찾아볼 수 있어.

4.6.11. Emoji

  • 코드리뷰 후 원활한 의사표시를 위해서!!

4.7. Wrap up, Breaking up your silos

  • 모든 정보가 한군데에 모인다.
  • 누구나 접근할 수 있다.
  • 변경하거나 협력하는 일에 대해서 겁내지 않아도 된다.
  • 사일로에 갇힐 필요가 없다.

4.8. 정리

  • 깃헙을 쓰세요.
  • 깃헙 말고 요비(http://yobi.io) 도 있어요.

5. 흔히 발견되는 자바 웹 애플리케이션 아키텍처 안티패턴(박성철, 본부장/SK PLANET)



  • 아키텍처 -> 애플리케이션 아키텍처 -> 구조적인 접근
  • 안티패턴
    • 좋지 않다는 감지.
  • 학습을 하다보면 정상치
    • 침체기를 겪게 된다.
  • 새로운 시도
    • 새로운 지식, 학습
    • 내가 가지고 있던 역량보다 낮아질 수 있게 된다.
    • 모험
  • 프로그래머들 스스로 하고 있는 일이 무엇인지 어떤 것인지 알지 못한다.
    • 그래서 그 다음 단계로 나아가지 못한다.
  • 87년생설

C/S 패턴

5.1. 연통가설

애플리케이션의 각 모듈이 독립적으로 개발되어 다른 모듈과 로직이나 데이터를 공유하지도 않고 상호작용하지도 않는다.

  • 중복이 발생할 수 있다.
  • 관심사에 따른 계층 설계
    • 관심사 분리 원칙에 따라 계층도 각 계츠으이 관심사에 따라 설계

5.2. 뒤범벅 아키텍처jumble architecture

무거운 서비스

  • 횡적인 요소들이 있다.

5.2.2. 해결책

  • 애플리케이션 서비스 계층 추가
  • 파이프 & 필터 패턴
    • ex) 서블릿 필터
  • AOP
    • 기능에 직교적인 횡적 관심사를 분리해 모듈화 수준을 높이는 기술

5.3. 긴 공개 메서드long method

  • 클래스에 공개 메서드 뿐이고 각 메서드의 크기도 너무 길다.
    • 미미한 기능 분화, 낮은 유지 보수성
    • 중복 다량 발생
    • 단일 책임 원칙 위반
    • 기능 분화로 재사용 코드 발견, 추상화의 기회
  • 클래스 추가 공포증

5.3.2. 해결법

5.4. 하는 놈 따로, 아는 놈 따로

5.4.1. 도메인 모델 도입

  • 모델링 -> DB 모델링

5.5. 낮은 응집도 높은 결합

5.6. 오염된 도메인

  • 도메인 영역의 모델만 가지고 도메인해야 한다.

5.7. 정리


시도하고 실패하고 경험을 쌓자.


6. Docket 클라우드 환경 구축 프로젝트 - d4, (황상철/SK PLANET)

… 못들음…

* 황상철님 발표자료: http://readme.skplanet.com/?p=11449

0. 정리

Tech planet의 강연은 만족스러웠다.

  • DEVIEW 2015 와 TECH PLANET 2015에 참가한 깃헙의 발표는 이제 듣지 않아도 될 것 같다.

깃을 기반으로 한 개발을 자연스럽게 하게 되면서, 굳이 깃헙 서비스를 중심으로 개발을 하지 않아도 충분히 개발과 관련된 버전관리를 할 수 있는 대안들이 많이 있는 상황이기 떄문이다. 어제 스쳐간 글들 중 드랍박스에서 구글 드라이브로 이주해가는 것에 대한 글들도 많이 나왔는데 개발 버전관리시스템도 그와 같다고 할까?
‘성공으로 이끄는 팀 개발 실천기술(http://www.yes24.com/24/Goods/14725219?Acode=101)’ 이 책의 저자가 왔었지만… 그다지 흥미롭지는 않았다. Git LFS(https://git-lfs.github.com/)에 대한 이야기를 해줬으면 흥미를 주었을지도 모르는데…

  • 한국 개발자들의 발표는 좋았다. 한국어기 때문인가!? +_+)
    전체적으로 한국 개발자들의 수준이 향상되었고 많은 노하우를 축적했기 때문이겠지.

  • 내년에도 필.참.하도록 하자.


저작자표시