R 프로덕트의 개발과 배포

김대영

RUCK 2017

R 프로덕트의 개발과 배포

김대영

인생 첫 복리효과

RUCK 2017

“복리야말로 인간의 가장 위대한 발명”

“세상의 8번째 불가사의”

2

1. 혼자 버둥거리는 이야기

~ 2014 / 8 산업 및 시스템 공학

feat. 전기및전자공학

R알못

전문연구요원

2014 / 8 ~

•R알못 + MATLAB (X) + 시급한 비즈니스 지원

•엑셀로 데이터 분석 & 시각화

•분석은 많은 반복 과정 필요

•비효율적인 작업

•극복을 위해 R을 틈틈히 학습

입사 후 첫 번째 고난 : 도구 없이 시작

도구 장착: R•기본적인 문법은 비교적 수월

•첫 번째 고민

•직접 짜야할까? 이미 구현된 걸 찾아서 써야할까?

•‘찾느니 그 시간에 짰겠다’ 생각이 새로운 도구 학습 속도 제한

•(게을러서) 더 좋은 도구 틈틈히 계속 찾음

•활용도가 높은 패키지를 중심으로 학습 성공

작업을 처리하는 도구: 스크립트

패키지 로딩

데이터 import

데이터 정제/변환

분석

결과 export

<이 당시의 코드 형태>

작업 A

배포

개발

작업 B

배포

개발

<이 당시의 개발과 배포의 범위>

특정 작업에만 유용‘키위 깎는 용도의 칼’

시간

일하는 나

작업 요구

도구

산출물

일하는 나

작업 요구

도구

산출물

복리의�비밀�-�김창준

http://agile.egloos.com/2854698

전체적인 작업의 흐름

외부의 요구를 그때 그때

현재의 생산성 -> 미래의 생산성 (x)

R vs Excel .. ?

핵심은 재활용!

•또 다시 ‘high 게으름 low 참을성’이 열일

•현재 시점/환경만을 고려한 개발/배포(결과적으로 나는 이득이 없고, 요구자만 이득)

•미래 시점/환경까지 고려하는 개발/배포(나도, 요구자도 이득)

•다시 쓸 가능성이 있도록 작업 방식을 바꿔보자! (미래의 나를 가엾게 여기기 + 미래의 요구자도 혜택)

-> 넓은 배포: 혜택을 입는 대상/수준 증가

-> 좁은 배포: 혜택을 입는 대상/수준 한정적

배포 범위를 넓히기 첫 시도: 함수 만들기

•프로그래밍 교육에서 매우 강조하는 개념(많은 사람들이 시도하고 활용)

•대표적인 효과는 반복을 제거(20줄 짜리 코드를 함수로 정의한 상황, 해당 함수 기능이 필요한 작업마다 근 20줄 코드만큼의 반복이 제거되는 효과)

•그러나 모든 ‘함수화’가 유용한 것은 아님(쓰이지 않는 형태로 함수화하면 무용함)(예: 스크립트 전체를 함수로 정의하면 함수를 만들었어도 배포 범위는 동일)

‘함수 만들기’가 낳는 또 다른 고민들•재사용 되지 않으면 함수 만들기의 유용성은 제한적

(예: 스크립트 전체를 함수로 정의하면 함수를 만들었어도 배포 범위는 동일)

•함수 로딩 방법의 비효율성

•함수가 다른 함수를 활용할 때의 의존성

의존성 해결

더 유용한 함수를 위한 더 좋은 추상화‘소프트웨어 공학’의 고민들!

…의존성 최소화

Package로 ‘소프트웨어 공학’의 고민을 다루기

•더 나은 방법을 추구하는 과정에서 파생된 문제들 -> ‘소프트웨어 공학’의 고민

•R의 Package는 R에 존재하는 ‘소프트웨어 공학’의 고민을 효과적으로 해결하기 위한 핵심 도구 (Package는 기존 단계의 향상 시도에서 발생하는 복잡성 비용이 복리로 증가하지 않도록 막는 역할)

•Package 활용이 숙련됐을 때, R의 첫 복리효과를 체험 (까다로울 수 있지만, 이후 모든 복리효과의 기반이기 때문에, 충분한 가치가 있음)

복리의�비밀�-�김창준

http://agile.egloos.com/2854698

Package 활용 이후, 작업의 흐름

일하는 나

도구

일하는 나

도구

산출물

도구

일하는 나

도구

도구

도구

산출물

산출물

- 새롭게 만들어지는 도구는 다음 작업을 하는 나의 일부로 더해짐

- 산출물의 결과는 증가하는 ‘나’의 능력에의해 가속도를 얻어 ‘지수적’으로 증가

혼자 바둥거리던 R알못

지속적으로 불편을 느끼고 더 나은 방향을 찾는것

스스로 능력을 점진적으로 가속하는 방향

같은 자원하에 실현할 수 있는 범위/속도 확대

2. 곱하기 팀에 대한 이야기

팀의 초기 모습: 더하기 팀

각자 분배된 일을 독립적으로 처리

낮은 협업 수준

서로가 서로의 도구를공유하지 못함

개인이 생산성을 올려도 그 효과는 개인에 국한다른 팀원의 성장이나의 능력 증대로 이어지지 않음

1 + 1.5 1 x 1.5 + 1.5 x1

vs

개인 성장은 같을 때 팀의 생산성

두 명 중 한 명이 50%의 생산성 향상을 보였을때

2.5

더하기 팀 vs 곱하기 팀

3.0

도구를 누가 만들었나 상관 없이 자유롭게 조합해 (= 곱해) 활용하는 형태

곱하기 팀으로 변화하는 시작은 도구의 공유였다

•도구의 공유는 패키지를 통해 촉진됨

•개인 차원에서의 복리효과를 만든 패키지가, 팀 차원에서의 복리효과도 만듬(복리효과는 예상 범위를 넘어 또 다른 복리효과를 만듬)

•패키지가 공유에 유용했던 이유: 의존성을 자체에 포함할 수 있기 때문 (도구만 받을 때 vs 도구가 완전하게 동작할 수 있는 부품 목록을 함께 받을때)

‘패키지’가 낳는 또 다른 고민들

1. 패키지를 ‘어떻게’ 배포하고 받을 것인가

2. 지속적으로 업데이트 되는 패키지의 이력을 어떻게 관리할 것인가

3. 함께 설치해야하는 의존 패키지들을 어떻게 설치할 것인가

Git/GitHub을 활용한 내부 패키지 배포

1. 패키지를 ‘어떻게’ 배포하고 받을 것인가-> GitHub의 클라우드 저장소를 활용-> 인터넷 연결이 가능한 모든 머신에서 push/pull 가능해짐

2. 지속적으로 업데이트 되는 패키지의 이력을 어떻게 관리할 것인가-> Git

3. 함께 설치해야하는 의존 패키지들을 어떻게 설치할 것인가-> devtools, remotes 패키지 활용

복리효과에 대한 복리효과

‘함수의 고민들’을 해결한 ‘패키지’

개인의 생산성 향상

도구 공유에 대한 필요성 발견

도구 공유 과정 촉진

여유 (slack)

2가지 이야기

R 코드를 개발하고 배포하는 궁극적인 목표가 뭘까?

나와 더 많은 사람들이 지속적으로 더 높은 생산성을 목표로 하는

복리 효과가 아닐까?

•지금 내가 노력한 작업의 결과물을,

•나의 다음 작업에서,

•또는 누군가의 다음 작업에서 활용할 수 있게함

지속적인 향상을 추구하는 과정에서 발견한 R 코드의 개발과 배포의 변화

언제나 더 나은 방법이 존재한다는 믿음

두 이야기를 설명하는 하나의 이야기

스스로를 가엾게 여기고, 더 나은 방법을 찾길 주저하지 마세요

감사합니다