비동기 프로그래밍 관점 에서 의 Akka 
 21 Jun 2018 • Java • Akka • Async • Actor • Pararell 
 Akka 란 Actor 기반 시스템 의 한 구현 체이 다 . 메시지 를 주 고 받 을 수 있 는 단위 를 Actor 로 놓 고 , Actor 간 의 통신 을 메시지 수신 으로써 처리 하 는 개념 이 다 . 
 Win 32 에서 의 메시지 기반 프로그래밍 의 수신자 를 여러 개 두 는 개념 이 라고 봐도 무방 하 다 . 프로세스 내 에서 의 메시지 단위 통신 이 라고 할까 ? 
 지켜야 할 것 은 다른 Actor 간 의 메소드 직접 호출 이 있 어선 안 된다는 점 이 다 . Life - cycle 이 유지 되 고 있 는 Actor 에 대한 메소드 호출 은 동기 화 가 깨진다 . 
 Akka 는 메소드 직접 호출 보다 는 느리 지만 , 메시지 큐 를 통한 접근 스레드 를 하나 만 유지 함 으로써 , 멀티 스레드 동기 화 이슈 를 우회 하 는 접근 이 다 . 
 싱글 스레드 구조 에서 , 요청 에 대한 위임 , 그 에 대한 응답 을 메시지 큐 를 통해서 처리 하 는 WIN 32 메시지 기반 프로그래밍 이나 Node . js 방식 과 차별 화 된 요소 는 바로 이 점 이 다 . 
 이 경우 의 핵심 고려 요소 는 메시징 시스템 자체 는 멀티 스레드 기반 하 에 동작 시키 게끔 구현 되 어야 하 며 , 메시징 시스템 의 성능 이 크 게 영향 을 주 므로 , 뛰어난 성능 이 보장 되 어야 한다 . 
 또한 Actor 에 대한 Life - Cycle 관리 가 아주 중요 하 다 . 
 이런 몇 가지 고려 요소 에 대해 신경 쓴다면 , 그만큼 얻 을 수 있 는 이득 은 크 다 . 
 가장 중요 한 것 은 멀티 프로세스 보다 성능 이 좋 은 멀티 스레드 비동기 병렬 프로그래밍 로직 을 적 은 고민 으로 구현 해낼 수 있 다는 점 이 다 . 
 Akka 는 인 프로세스 메시징 큐 를 사용 하 는 것 보다 좀 더 고차원 적 인 병렬 처리 와 fail - over , persistence 등 을 지원 한다 . 
 내 가 Akka 를 쓰 면서 놀라웠 던 것 은 , 몇 가지 쉬운 원칙 만 지키 면 멀티 스레드 로직 프로그래밍 보다 안 전하 면서 도 높 은 성능 ( through - put ) 의 시스템 을 구축 할 수 있 었 다는 점 이 다 . 
 멀티 스레드 로직 프로그래밍 은 조금 만 삐끗 나 도 lock 이 길 어 지 거나 , spin - lock 이 발생 하 거나 , 경합 , 데드 락 이 발생 하 기 쉽 상 인데 그런 측면 에서 의 우려 가 적 으면서 도 성능 도 우수 했으며 scale out 에 도 유연 했 다 . 
 즉 직접 네트워크 라이브러리 를 구현 하 는 사람 ( Netty , SuperSocket , Asio 등등 ) 이 아니 라면 난이도 도 높 고 , 막상 멀티 스레드 로직 을 직접 구현 할 것 이 아니 라 Akka 와 같 은 비동기 메시징 시스템 을 사용 하 는 것 이 좋 다고 본다 . 
 함수 형 프로그래밍 도 내부 적 상태 를 갖 지 않 는 함수 들 만 으로 구현 함 으로써 , 가변 데이터 로 인해 생기 는 데이터 안정 성 과 병렬 처리 의 어려움 에 대해서 회피 하 고자 다시금 주목 받 은 측면 이 크 다 . 
 함수 형 프로그래밍 의 이질감 과 비 직관 성 에 대한 적응 이 , 멀티 스레드 로직 프로그래밍 이 가진 높 은 복잡도 와 제약 들 보다 낫 다는 결론 이 한쪽 진영 에서 있 었 다고 생각 한다 . 
 그걸 감안 한다면 Akka 와 같 은 Actor 기반 프로그래밍 은 또 하나 의 좋 은 대안 이 고 , 많이 선택 되 어 왔 다 . 
 사실 Akka 는 함수 형 프로그래밍 과 멀티 스레드 로직 구현 과 의 중간 점 에 존재 하 는 느낌 도 강하 다 . 
 Akka 를 통해 상태 기반 프로그래밍 도 가능 하 지만 이 는 몇 가지 대안 과 함께 하 지 않 으면 fail - over 를 어렵 게 만드 는 리스크 가 되 기 도 하 고 , 함수 형 으로 시스템 을 완성 할 수 있 으면 굳이 Akka 를 쓰 지 않 아도 되 기 때문 인 측면 이 있 기 때문 이 다 . 
 하지만 상황 에 따라선 상태 기반 프로그래밍 을 써야 할 때 가 있 다 . 또한 , 캐 싱 을 통해 크래시 가 발생 했 을 때 의 리스크 를 줄이 는 접근 을 통해 리스크 최소화 를 하 는 접근 도 납득 할 만 하 다 . 
 여러 가지 측면 에서 봤 을 때 , 함수 형 프로그래밍 이 좀 더 지지 를 받 고 있 는 상황 임 에 도 , Akka 와 같 은 Actor 기반 프로그래밍 도 현재 로썬 적절 한 병렬 처리 선택지 중 하나 아닐까 싶 다 . 
 도구 의 중요 성 
 01 Jun 2018 • 도구 
 명필 은 붓 을 가리 지 않 는다 . 
 이 말 이 와전 된 말 이 라는 것 은 , 이젠 꽤 나 많 은 사람 들 이 알 게 됐 다 . 
 ‘ 명필 이 붙 을 안 가린다 ’ 라지만 사실 은 붓 을 가린다 . - http : / / yopangyopang . tistory . com / 296 
 개발 도구 도 똑같 다 . 
 툴 마다 어마어마 하 게 큰 생산 성 차이 를 낸다 . 중요 한 것 은 절대 적 툴 차원 에서 의 지원 의 차이 도 물론 존재 하 지만 자신 에게 익숙 한 툴 인가 도 매우 중요 하 다 . ( 특히 단축키 ) 
 너무나 당연 한 얘기 지만 중요 하 게 여기 는 포인트 는 , 내 가 원 하 는 기능 들 이 온전히 제공 되 는 가이다 . 
 intellisense , open declaration , open implement , formatting , checkstyle , debugging ( watch , stacktrace , step into , step out , recompile and continue 등 ) , performance , package manager interlocked 같 은 다양 한 관점 에서 얼마나 만족도 가 높 은 가이 다 . 
 다양 한 관점 의 만족도 가 전반 적 유료 툴 들 이 높 은 편 이 지만 , 비용 은 현실 적 인 문제 니 검토 대상 에 포함 될 수 밖 에 없 다 . 
 나 는 Visual Studio 를 오래 써 왔었 고 , 자바 를 처음 사용 할 때 도 IntelliJ IDEA 를 써서 못 느꼈 는데 Eclipse 는 큰 확장 성 에 비해서 너무 느렸 다 . 
 Visual Studio 는 완벽 에 가까운 개발 툴 이 다 . 현재 는 Community 버전 으로 개인 프로젝트 단위 는 무료 사용 가능 하 다는 큰 장점 이 있 다 . 
 JetBrains 의 명성 을 널리 알리 기 시작 한 시발점 이 된 Java IDE . Key Set 과 Color Theme 만 바꿔 도 딱히 손 댈 게 없 을 만큼 기능 지원 이 우수 하 다 . 
 오랜 기간 명맥 을 유지 해 온 무료 IDE . Java 전용 이 아님 에 도 Java 진영 에서 의 오랜 선택 을 받 아 온 지라 그런 이미지 가 있 다 . Plugin 설치 로 기능 확장 이 여러 가지 면 에서 가능 하나 대 다수 의 기능 설정 을 개인 이 해야 하 며 , 성능 이슈 가 존재 하 는 아쉬움 이 있 다 . 
 Eclipse 를 사용 하 고 있 던 팀 에 합류 했 다 보 니 , 나 도 자연스레 Eclipse 로 환경 설정 을 하 게 됐 고 , 기능 적 으로 는 부족 함 이 없 었 음 에 도 , 플러그인 으로 구현 되 면서 문제 로 보여 지 는 많 은 파일 을 잡 고 있 는 문제 ( runtime 이 아닐 때 에 도 pom . xml 을 통해 참조 되 는 maven jar 를 모두 잡 고 있 었 고 , UI 갱신 속도 도 무척 이나 느렸 다 . 아마도 보안 프로그램 과 의 충돌 이 원인 인 상황 ) 였 는데 , 테스트 삼 아 설치 해 본 IntelliJ IDEA 의 trial 버전 은 이런 문제 가 전혀 없 었 다 . 
 그리고 그것 이 IntelliJ IDEA 구매 요청 하 게 된 계기 가 됐 다 . 
 보안 프로그램 과 의 충돌 의 가능 성 이 높 은 것 은 , 파일 억 세 스 를 통한 기능 확보 방식 으로 구현 된 기능 들 이 문제 였 다 . 
 이 는 쉽 게 개선 되 기 어려운 문제 이 기 도 하 고 , 무료 툴 에서 덜 관심 을 가지 는 성능 이슈 에 대한 아쉬움 이 기 도 했 다 . 
 그 에 비해 Eclipse 와 같 은 무료 툴 이 며 , 범용 툴 인 Atom 이나 VS Code 는 plugin 설치 로 인한 실행 속도 감소 가 매우 적 었 다 . 다만 플러그인 을 통한 기능 지원 도 제한 적 이 긴 했 다 . 
 Github 에서 만든 Text Editor 이 자 , IDE . Plugin 방식 으로 기능 이 확장 되 는 구조 다 . 
 최근 내 가 사용 하 고 있 는 툴 . Atom 기반 이나 단축키 가 Visual Studio 키 셋 과 동일 하 며 , Plguin 개발 이 활발 해 매우 다양 한 언어 개발 용도 나 , Text Editor 용도 로써 의 사용 에 도 매우 편리 하 다 . 
 가볍 게 사용 했 을 때 는 문제 가 없 었 지만 , 특정 언어 나 프레임워크 에 종속 적 인 설정 파일 관리 / 편집 기능 , linter , formatter 설정 에서 아쉬움 이 존재 했 다 . 
 Notepad ++ 같 은 순수 Text Editor 보다 는 구동 시간 이 느리 지만 , IDE 들 보다 는 훨씬 빠른 구동 시간 은 장점 이 다 . 
 요약 하 자면 , 자신 이 툴 종속 적 인 기능 을 잘 활용 하 고 , 그 에 대한 메리트 를 느낀다면 전용 툴 , 유료 툴 을 적극 검토 해야 한다는 의미 다 . 
 내 경우 에 는 사용 해야 하 는 툴 의 종류 로 IDE , Database Tool , SSH Tool , REST API Test Tool , Text Editor 등 의 툴 들 이 필요 하 다 . 
 여기 에 사용 해야 되 는 프로그래밍 언어 , DB 종류 가 늘어난다면 사용 해야 될 툴 이 늘어날 수 도 있 다 . 
 사용 해야 되 는 툴 이 늘어난다면 , 툴 의 특화 기능 도 , 단축키 도 , 암묵 적 인 룰 도 학습 해야 하 며 , 태 스 크 전 환시 부담 이 될 수 있 다 . 
 도구 가 내 손 에 딱 맞 았 을 때 의 생산 성 은 매우 높 다 . 반면 도구 에 익숙 하 지 않 은 상태 에선 한번 더 생각 하 거나 , 어떤 메뉴 나 단축키 로 설정 된 기능 인지 생각 해야 될 때 의 생산 성 은 매우 낮 다 . 
 내 경우 에 는 Visual Studio 로 개발 을 시작 했으므로 , 여러 개 의 툴 을 사용 할 시 에 도 Visual Studio key Set 으로 모두 맞추 어서 적응 코스트 를 낮춘다 . 
 내 가 필요 한 기능 이 해당 툴 선정 조건 에 포함 되 었 으므로 , 당연히 툴 사용 에 불편 함 은 없 다 . 
 이 와 관련 해 나 는 집 , 노트북 , 회사 PC 의 환경 을 최대한 일치 시키 려 하 는데 , 이 는 작업 시 의 적응 비용 을 최소 화 하 기 위한 노력 이 다 . 
 애초 에 환경 을 최대한 유사 하 게 세팅 해둔다면 , 불시 에 작업 을 해야 되 거나 , 머릿속 의 생각 을 구현 하 기 위해 바로 코딩 을 하 려 했 을 때 환경 구성 에 대한 시간 소요 없이 즉시 작업 에 돌입 할 수 있 기 때문 이 다 . 
 자신 이 최상 의 퍼포먼스 를 내 는 환경 이 무엇 인지 떠올려 보 고 , 그런 환경 에 최대한 근접 하 게 하 기 위한 노력 이 필요 하 고 , 그 중 에서 도 내 손 에 맞 는 도구 는 매우 중요도 가 높 다 . 
 자신 이 효율 성 에 대해 고민 하 는 사람 이 라면 , 도구 의 중요 성 도 고민 선상 에 두 는 것 은 어떨까 ? 
 01 Jun 2018 • 실수 • 실패 
 누구 나 실수 를 한다 . 
 더 나아가 누구 나 버그 를 만든 다 . 
 구글 도 , MS 도 , 애플 도 넷플릭스 도 아마존 도 버그 를 만든 다 . 
 버그 없 는 소프트웨어 는 존재 하 지 않 는다 . 
 사용자 입장 으로 가정 하 면 , 정말로 버그 없 는 소프트웨어 는 존재 할 수 없 다 . 
 조금 은 억울 한 이야기 는 하드웨어 오류 로 인한 버그 마저 소프트웨어 에 대한 불신 으로 이어질 수 있 고 , 사용 자 에겐 그것 은 어떤 티어 의 문제 였 건 간 에 버그 다 . 불편 한 사용 성 , 하드웨어 fault 로 인한 오류 , 네트워크 응답 속도 로 인한 오류 마저 버그 로 간주 될 수 있 기 때문 이 다 . 
 위 상황 마저 , 개발자 가 커버 해야 된다는 얘기 냐고 ? 오히려 그 반대 에 가깝 다 . 
 소프트웨어 기업 이 라면 개발자 의 실수 가 어떻게 받아들여 지 느냐 에 따라 그 기업 의 성 장력 에 차이 를 낸다 . 
 과감 해야 할 때 와 그렇 지 않 아야 할 때 , 많 은 코스트 를 들 여서라도 새로운 시도 를 해야 할 때 , 보수 적 으로 접근 해야 할 때 를 엄격히 구분 하 고 , 그 에 대한 판단 과 책임 은 회사 가 져야 한다 . 
 개인 이 지나치 게 부족 한 역량 과 , 지나친 월 권 으로 안정 성 을 해치 고 있 는 케이스 는 물론 개인 의 책임 이 다 . 이 사람 이 변화 에 적절 한 상태 인지 , 얼마나 합리 적 인 결론 을 낼 수 있 는지 에 대한 판단 은 회사 의 몫 이 다 . 
 대다수 의 과감 한 시도 로 인한 리스크 마저 개인 이 떠안 아야 한다면 , 어느 누구 과감 한 선택 과 도전 을 하 려 할까 ? 
 새로운 시도 , 노력 없이 성장 할 수 있 는 소프트웨어 는 없 다 . 심지어 보수 적 인 선택 으로 기존 기술 을 선택 한다 하 더라도 , 안정 성 은 보장 할 수 없 다 . 
 심지어 코드 한 줄 작성 안 하 고 운용 하 는 소프트웨어 라 할지라도 , 그 에 대한 대처 가 되 어 있 지 않 은 환경 에선 사고 가 날 가능 성 은 존재 한다 . 심지어 그 확률 마저 꽤 나 높 다 . 변화 를 기피 하 는 보수 적 인 선택 이 안정 성 에 대한 해결책 이 라 여기 는 분 들 입장 에선 슬픈 이야기 겠 지만 말 이 다 . 
 결국 엔 얼마나 변화 와 안정 성 , 디테일 간 의 밸런스 를 맞출 수 있 느냐 에 문제 다 . 
 그 과정 에서 한 번 에 완벽 하 게 변화 할 순 없 기에 그 과정 을 두려워하 지 않 게 만들 어 주 어야 한다 . 
 두려움 을 느낀다면 , 마지못한 도전 을 할 것 이 고 , 가능 한 한 보수 적 인 접근 으로 적 은 실수 를 혹은 실수 를 하 지 않 게끔 행동 할 것 이 다 . 
 당연 하 게 도 그 과정 에서 얻 는 경험 과 통찰 등 실수 로 인해 얻 을 수 있 는 소득 은 줄어들 것 이 다 . 
 실패 로 , 실수 로 인해 배우 는 것 은 너무나 도 크 다 . 
 실패 를 적 게 한 사람 은 실패 로부터 배우 는 방법 마저 모른다 . 
 그 방법 을 알 수 있 게 , 더 많 은 걸 실패 로 부 터 배울 수 있 게 지원 해야 하 며 , 과감 함 속 에서 성장 하 고 , 그 성장 을 밑바탕 으로 삼 을 수 있 는 고민 과 문화 를 만들 어야 한다 . 
 발전 하 고 싶 다면 말 이 다 . 
 경험 과 인사이트 
 01 May 2018 • 주절 주절 • 경험 • 인사이트 
 누군가 가 말 한다 . 경험 이 전부 라고 . 
 또 다른 누군가 는 말 한다 . 경험 보다 재능 이 라고 . 
 사실 은 두 가지 모두 중요 한 요소 다 . 내 경험 상 서류 와 수치 로 증명 가능 한 재직 경력 , 좋 은 회사 재직 자 , 좋 은 학교 졸업 자 같 은 것 들 이 무 의미 하 다는 것 은 아니 지만 그것 이 전부 라 보 기 어렵 다 . 
 그런 서류 나 수치 적 인 것 들 을 뛰 어 넘 는 루 키 들 은 업계 에 나 있 어 왔 지만 그 수 가 많 지 않 았 고 , 경력 자 라고 해서 실력 을 보장 해 주 지 않 는다 . 
 특히 각종 커뮤니티 에서 , 우리 업계 출신 프로그래머 가 더 잘 해 같 은 부심 이 오 고 가 는 것 을 보 면 , 꽤 나 많 은 사람 들 이 경험 의 기간 보다 , 경험 의 종류 의 차이 를 좀 더 높 게 평가 하 는 듯 하 다 . 
 재능 이 있 는 사람 은 경험 도 뛰어넘 는다 . 그렇지만 그 경험 이 경험 의 종류 나 , 경험 의 기간 을 뛰 어 넘 는 것 이 대부분 이 었 다 . 
 그렇 다면 흔히 말 하 는 인사이트 란 무엇 인가 ? 
 insight 미국 · 영국 [ ɪ nsa ɪ t ] 영국 식 중요 
 이해 , 간파 
 사전 적 의미 로 통찰력 이 다 . 바로 어떠 한 일 의 본질 과 , 상황 의 핵심 을 꿰뚫 는 능력 , 무엇 이 더 중요 한지 이해 하 는 능력 등 의 넓 은 시야 로 상황 을 파악 하 는 능력 이 라고 볼 수 있 다 . 
 통찰력 의 근간 은 유추 능력 이 다 . 
 경험 이나 학습 , 관찰 , 독서 등 의 다양 한 방법 으로 접하 게 되 는 정보 들 을 연관 짓 고 , 연관 성 을 바탕 으로 솔루션 을 얻 는 것 을 통찰력 이 라고 할 수 있 다 . 
 창의력 은 참신 한 것 을 발상 하 는 능력 이 라고 봤 을 때 , 통찰력 은 참신 할 필요 는 없 다 . 문제 의 본질 을 파악 하 고 , 적합 한 솔루션 을 선택 하 는 능력 이 필요 하 다 . 
 이런 능력 을 어느 정도 타고난 사람 들 이 분명히 존재 한다 . 위 에 언급 한 능력 들 과 창의력 이 더 해져서 통찰력 으로 표출 되 는 경우 가 있 지만 , 이 는 흔치 않 는 케이스 였 다 . 
 대 다수 는 정보 가 많 거나 , 유사 혹은 동일 한 경험 에서 교훈 을 얻 었 던 것 들 사이 의 연관 성 과 , 현재 상황 과 의 매칭 을 통해서 해결책 을 떠올리 는 케이스 가 다수 라 할 수 있 다 . 
 경험 이 다양 하 다는 전재 로 , 이 사람 이 합리 적 이 고 논리 적 인 사람 이 라면 반드시 통찰력 을 갖추 고 있 을 것 이 라고 가정 하 기 에 , 주로 경험 이 많 은 ( 경력 이 많 은 ) 사람 을 시니어 프로그래머 부르 며 선호 하 는 것 이 다 . 
 나 역시 주어진 주제 에 대해서 통찰력 과 , 고찰 을 통해 좋 은 솔루션 을 가진 사람 이 여러 논란 이 있 는 시니어 프로그래머 에 어울리 는 사람 이 라고 생각 하 지만 이 는 경력 과 비례 하 지 않 기에 ( 그래서 각종 채용 논란 이 있 는 것 이 지만 ) , 그 사람 이 진지 하 게 개발 을 해온 경험 이 있 고 , 그 경험 을 진지 하 게 마주 해 왔 다면 , 너무나 당연 하 게 도 시니어 프로그래머 라는 명칭 이 아깝 지 않 은 사람 일 거 라고 믿 는다 . 
 그리고 난 시니어 프로그래머 라는 명칭 은 경력 이 아닌 , 이 사람 의 통찰력 에 대해서 주 어 져야 하 는 것 이 라고 생각 한다 . 
 그만큼 프로그래머 의 문제 해결 능력 은 중요 하 고 , 그 만큼 통찰력 이 그 프로그래머 의 경쟁력 이 고 아주 중요 한 능력 중 하나 다 . 
 그 능력 을 개발 하 기 위해선 , 진지 한 개발 태도 가 중요 하 다 . 그럭저럭 나쁘 지 않 은 결과물 을 만들 려는 태도 와 회고 와 반성 을 게을리 하 는 사람 에겐 통찰력 을 비롯 한 발전 은 아주 더딜 것 이 다 . 그리고 그런 사람 이 내 는 결과물 은 당연 하 게 도 퀄리티 가 좋 을 리 없 다 . 
 그런 사람 은 통찰력 을 가진 척 할 수 있 을 뿐 이 다 . 진짜 통찰력 을 갖 기 위해서 는 다양 한 경험 과 시각 을 가지 고 진지 하 게 결론 지 을 줄 알 아야 한다 . 
 그리고 그 결론 을 가지 고 다양 한 사람 과 나누 다 보 면 진짜 통찰력 에 가까워질 수 있 을 것 이 다 . 그리고 그런 사람 들 이 더 많 은 팀 이 , 더 많 은 회사 가 효율 적 으로 더 뛰어난 퀄리티 의 결과물 에 도달 할 거 라 믿 는다 . 
 오픈 소스 기여 하 기 
 30 Apr 2018 • 주절 주절 • 오픈 소스 • Github 
 내 가 프로그래밍 을 처음 공부 하 던 시기 였 던 97 년 즈음 에 자료 를 구할 곳 이 라고 는 책 과 PC 통신 ( 하이텔 , 나우누리 ) , 인터넷 ( 넷츠고 를 통한 ) 이 다 였 다 . 
 그 즈음 해서 , 자료 를 구하 기 한 쉬운 문제 가 아니 었 고 , 그 자료 도 소수 의 훌륭 한 개발 자 분 들 이 공개 해 주 신 자료 에 근거 했 고 , 꽤 나 다수 는 대학교 교제 의 틀 을 크 게 벗어나 지 못했 다 . 
 공개 되 는 자료 에 온전 한 모듈 이나 , 완성 된 프로그램 으로써 의 자료 는 극히 드물 었 으며 , 다양 한 기능 에 대한 코드 를 많이 보유 하 고 있 는 것 이 개인 의 경쟁력 으로 여겨 지 던 시기 라고 도 할 수 있 었 다 . 
 꽤 나 다수 의 기능 은 습작 이나 , 샘플 코드 에 다름 이 없 었 음 에 도 그 교류 는 흔치 않 았 는데 , 남 들 도 공유 하 지 않 는데 공유 하 면 나 만 손해 라는 생각 이 어느 정도 국내 개발자 사이 에서 형성 되 었 던 것 은 아닌가 싶 다 . 
 해외 로 눈 을 돌리 면 애초 에 리눅스 가 오픈 소스 였 기 에 , 관련 코드 다수 는 공개 되 어 있 었 고 , sourceforge 등지 에서 의 코드 공유 는 이루어지 고 있 었 으나 , 국내 에서 자유 롭 게 접근 하 고 사용 할 정도 는 아니 었 다 . 특히 나 국내 개발자 들 에게 공감대 가 크 지 않 았 으므로 , 가져와서 사용 하 는 경우 는 존재 했어도 오픈 소스 라이선스 에 맞 게 변형 한 코드 를 재 공개 해야 되 는 케이스 에서 마저 , 그렇 지 않 은 경우 도 종종 봤 다 . 
 이 는 저작 권 의식 부족 과 , 코드 공유 는 손해 라는 인식 이 합쳐진 문제 였 다는 생각 이 든다 . 
 정확히 언제 쯤 인지 는 모르 겠 으나 , 국내 에서 도 github 를 기반 으로 한 코드 공유 움직임 이 커졌 다 . 
 웹 쪽 에서 특히 spring 이나 rails , django , node . js 같 은 오픈 소스 기반 웹 프레임워크 와 그 프레임워크 들 에서 의 패키지 가 github 에 공개 되 어 있 는 만큼 오픈 소스 로 접하 게 되 는 모듈 들 에 고마움 을 느끼 면서 그 에 대한 보은 ( ? ) 하 려는 움직임 으로 변한 걸 지도 모르 겠 다는 생각 이 들 만큼 , 지금 은 꽤 나 많 은 개발 자 분 들 이 github 를 이용 하 고 있 음 을 느낄 수 있 다 . 
 바퀴 를 재 발명 하 는 것 이 합리 적 이 지 않 고 , 잘 돌아가 고 뛰어난 스펙 의 자동차 를 혼자 만드 는 일 은 즐겁 기 보 다는 고통 과 인고 의 시간 이 라는 것 을 모두 가 알 고 있 는 것 처럼 , 다른 사람 이 작성 한 기능 을 니즈 에 맞 게 가져다 쓰 면서 , 자신 이 필요 한 커스텀 로직 에 집중 해 구현 함 으로써 차별 화 와 목적 달성 을 동시 에 이루 는 것 . 그것 이 합리 적 이 라는 공감대 가 형성 된 것 이 라고 본다 . 
 오픈 소스 로 큰 모듈 이나 차별 화 된 기능 , 프로덕트 로써 만드 는 모든 코드 를 공개 하 는 것 은 당연히 어렵 다 . 
 하지만 개인 적 인 연구 주제 나 , 공부 하 는 자료 , 또는 다른 오픈 소스 에서 의 작 은 아쉬움 을 개선 한 코드 는 공유 했 을 때 에 얻 는 것 도 많 다고 생각 한다 . 
 Pull request 가 받아들여 졌 을 때 의 짜릿 함 , 내 프로젝트 에 별 이 많이 늘어났 을 때 의 짜릿 함 은 개발자 로서 의 자기 증명 의 수단 중 하나 라고 생각 한다 . 
 이런 저런 이유 로 파이썬 보급 률 이 국내 에 크 게 높 아 진 걸 느낄 수 있 다 . 그리하여 , 여러 유틸리티 성 프로젝트 나 , 개인 의 고찰 이 묻어나 는 습작 들 을 다수 접할 수 있 는데 , 꽤 나 많 은 인사이트 도 얻 을 수 있 었 고 , 배울 것 도 많 았 다 . 
 직접 코드 를 공개 하 는 것 이 아직 두렵 다면 시작 은 오픈 소스 코드 읽 고 배우 기 부터 라도 시작 하 는 것 은 어떨까 싶 다 . 그렇게 시작 하 고 나 면 , Pull Request 를 통한 기여 , 작 은 샘플 코드 공개 를 통한 기여 , 많 은 이 에게 보탬 이 될 모듈 개발 을 통한 기여 로 이어질 수 있 게 되 고 , 그 를 통해 많 은 프로그래머 들 에게 도움 이 되 는 개발자 가 될 수 있 을 것 이 다 .