오픈소스 개발자 이야기(19.06.29)

오픈소스 개발자 이야기(출처: OSS 개발자 포럼)

오픈소스 개발자 이야기(19.06.29)

개발에 관심있는 지방 대학생들을 위해 3박 4일 캠프를 준비 중이며, 이에 따른 운영비가 필요해서 오늘과 같은 오픈소스 세미나를 유료로 열고 있습니다. 참가비 2만원 중 만원은 세미나 운영비로, 나머지 만원은 대학생 캠프 운영비로 사용됩니다. 오늘 세미나는 오픈소스 개발을 어떻게 시작하는지와 오픈 소스 개발자들의 개발 경험을 공유하는 자리입니다.

오픈sw 컨트리뷰톤 소개

7월 19일 참가신청 마감. 8월 오픈예정. 참여문의 유우영. 자세한 정보는 페이스북 그룹에 링크가 올라갈 예정입니다.

오픈소스 보고, 응용하기, 권문범(Naver)

• 오픈소스는 회사 개발팀보다 많은 인원이 참여하는 프로젝트라서, 많은 토론을 함. 그래서 개발 트렌드가 최신을 유지하는 편이고, 프로젝트 퀄리티가 높다.
• 패키지 매너저와 디펜던시 매너저 등장으로 인해 예전보다 오픈소스를 손쉽게 사용할 수 있음. 그렇다면 우리는 오픈소스를 제대로 사용하고 있는가?
• 오픈소스 사용에만 집중하면, 스스로 실력에 제한을 두는 것과 마찬가지다. '이 오픈소스가 어떻게 만들어졌는가? 왜 사용하는가?'라는 질문을 스스로 던져야.
• 오픈소스를 통해서 영감을 얻을 수 있고, 새로운 공부 과제도 발견할 수 있다. 그리고 새로운 패러다임과 구조에 대해 발견을 할 수 있다.
• 오픈소스를 보는 법은 먼저 오픈소스 문서를 읽고, 소스를 통해 구조를 파악한다.
• 1단계는 문서에서 주요 개념을 파악하기. 왜 오픈소스를 만들게 됐는지, 어떤 문제를 해결할 수 있는지 캐치하기.
• 2단계는 소스 내부의 구조와 원리를 파악하기. 오픈소스가 오픈되어 있기 때문에 가능합니다. 그리고 문서에서 찾아낸 키워드를 활용해서 구조를 파악할 수 있습니다.
• 3단계는 스터디와 커뮤니티를 통해 공부하기. 혼자 공부하는 것은 한계가 있습니다. 오픈소스 언어 분석 스터디, 언어와 라이브러리 관련 커뮤니티 등이 있습니다.
• fun(람다) 스터디 사례 소개: 소스를 분석하고 알고리즘 풀이를 통해 오픈소스에 접근. 책을 이용해 공부한 내용을 발표. 오픈소스 구조를 활용해 새로운 소스를 개발. 실제 오픈소스에 기여.
• 다른 주변 개발자들을 보면, 맹목적 신봉보다 장단점을 분석해서 어떤 이점이 있는지 확인. 필요한 부분만 잘 골라서 도입. 오픈소스 이해와 분석이 많이 됐으면, 비슷한 부분은 직접 만들어보기. 도움이 많이 됨.
• 새로운 방식에 대한 무조건적인 찬양과 무조건적인 비판도 금지.
• 오픈소스를 가장 쉽게 구경할 수 있는 방법은 JDK를 열어서 API 내부를 확인. 알고리즘과 효율에 대해 배울 수 있다. 리눅스는 알고리즘과 구조의 끝판왕이다.
• 내 주변의 오픈소스는 java, swift, 리눅스, 크로미엄, 파이어폭스, 네트워크 와 데이터베이스 라이브러리 등. DB 관련 써드파티들은 데이터의 무결설을 보장하기 위해서 어마어마한 처리가 되어 있다.

국제화/번역과 함께 하는 오픈소스에 대한 경험 및 노하우, 최영락(MS korea Dev PMM)

• 오픈스택에서 번역자로 활동한 이야기.
• 서로 다른 번역 화경: 도구, 용어집, 언어
• 언어만 중요하다고 생각하는데, 거기에 더해서 더 중요한 점이 있다.

1. 다양한 번역 도구 : 개발도구(IDE) 종류가 정말 다양한 것처럼, 번역 도구도 여러가지가 있다.
   • GNU gettext: 소프트웨어 국제화에 대한 체계를 잘 정리한 소프트웨어 패키지.
   • PO 파일포맷으로 대부분 표준화가 되어 있다.
   • POEdit: Po라는 파일 형식을 쉽게 편집할 수 있음.
   • Transifex: 상용 번역 도구. 강력한 기능
2. 용어집 통일 필요
   • 쿠버네티스 한글화팀 용어집
   • 언어 코드에 대한 고민: ko, ko_KR, ko-kr, ko-KR
3. Docs like Code, 그리고 번역

회사원에서 오픈소스 개발자로 거듭나기(방진호 / 고병권 삼성전자 공동발표)

첫번째 이야기: 오픈소스를 통해 회사로부터 독립하기, 방진호

• 불만이 가득한 신입 개발자. 조직의 비전이 너무나도 불확실했음. 고용 불안. 돈을 적게 받았음. 당시에 관심 있던 기술 스택인 웹과는 멀었음.
• 그래서 도전한 이직과 잡포스팅. 결과는 실패.
• 내가 쓸만한 개발자라는 것을 보여주는 것은 어렵다고 느꼈다. 그래서 객관적인 능력 증명서가 필요하다고 생각했음. 여러 가지 방법이 있었지만, 2014년 오픈소스 개발자 이야기에서 '커미터가 되면 실력, 연봉, 이직확률이 높아진다'라는 말을 들었다. 그래서 오픈소스 커미터가 되면 회사로부터 독립할 수 있구나를 생각함.
• 커미터가 되기. 어떤 오픈소스에 기여해야 할까? 내가 선택한 것은 크로미움/블링크. 왜냐하면, 어렸을적부터 브라우저를 만들고 싶었기 때문에. 큰 프로젝트라 멋있어 보였고, 회사에서 하는 일과 교집합이 많기 때문.
• 어떻게 커미터가 될 수 있을까? 크로미움 커미터가 되는 법. 크로미움 페이지에 가면 알 수 있다. 20개 패치(Patch)를 하면 커미터가 될 수 있다. 어떻게 패치(Patch)를 할 수 있을까?
• 첫 시도는 오픈소스를 사용해보면서 결점을 발견하기. 어떤 오픈소스에 기여를 해보고 싶으면 먼저 열심히 사용해보기. 엄청 열심히 사용했는데 너무나도 완벽했던 크롬.
• 두번째 시도는 무작정 코드를 들여다보기. 코드가 너무 방대했음. 하지만 우연히 라디안과 디그리로 변환하는 기능에서 결점을 발견해서 우연히 패치 하나를 할 수 있었음.
• 세번째 시도는 FIXME. TODO 검색하기. 나중에 고치려고 남겨놓은 부분임. 검색하면 코멘트를 읽어볼 수 있음. 그러나 당장 해결이 어려운 것들이다. 초보자에겐 힘들다.
• 네번쨰 시도는 모든 이슈 다 들여댜보기. 쉬운 것들은 경쟁이 심하기 떄문에 계속 보면서 선점해야 함. 회사에서 일할 떄, 밥 먹을 떄, 화장실 갈 떄, 잠잘 떄도 이슈 업데이트되는 것을 모니터링했음.
• 지속적인 반복으로 어느정도 기여할 수 있었다. 꿀팁은 이슈가 너무 많이 자주 올라오기 떄문에, 초심자를 위한 GoodFirstBug 라벨이 있음. 초보자들은 쉬운 이슈를 찾아서 해결할 수 있음.
• Trivial 패치의 반복을 통해 개발 프로세스의 익숙해짐
• 빌드하는 방법. 테스트 돌리는 방법
• 이슈 트래커를 관리하는 방법
• 코드 리뷰 보내는 방법
• 테스트를 작성하는 방법
• 패치를 사냥하는 방법
• 그러나 커미터가 되려면 Non-trivial 패치 20개 이상이 필요했다. 처음에 잘못 알고 Trival 패치만 20개를 채웠다.
• 다섯번째 시도는 상호운용성이다. 다른 브라우저에는 있지만 크롬에만 없는 기능. 브라우저 파편화가 심한 것을 상호운용성이라 부른다. 사파리에는 캔버스가 있으면, 크롬에는 없어서 캔버스 관련 구현에 도전함. 첫번째는 이슈 리포팅 게시. 구현을 위해 웹 표준 스펙을 읽기 시작했음. 열심히 구현하여 코드 리뷰를 보냄. 관리자 구글 개발자가 리딩해주는 대로 따라감. 덕분에 첫 구현을 말할 수 있는 patch를 함. 꿀팁은 하다보면 구현을 해야할 것을 다른 사람이 알려줄 수도 있다.
• 위 과정을 반복하다보니 커미터가 되었다.

오픈소스에 기여하면서 어려웠던 점들

• 첫쨰도 영어. 둘쨰도 영어
• 도전한 패치의 실패
• 친절함 없는 일부 리뷰어들
• issue tracker 경쟁자들
• 패치 (도둑놈)

오픈소스 커미터가 된 후 회사에서 달라진 점들

• 블링크온을 비롯한 여러 관련 컨퍼런스에 참석할 수 있는 기회
• 근자감
• 잠시나마 회사 없무의 50프로 정도는 오픈소스에 기여를 할 수 있게됨
• 나의 모든 시간이 오픈소스를 중심을 돌아감

커미터가 끝이 아니다

• 많은 사람들이 커미터가 오픈소스의 끝이라고 생각하는 경향이 있다. 커미터가 되고 나서 많은 패치를 하지 못했다. 커미터 자체가 중요한 것이 아니라 꾸준한 기여를 통해 기회를 얻을 수 있다.
• 그보다 더 중요한 점은 개발자로서 크게 성장할 수 있었다는 것
• 남의 코드를 읽는 능력이 크게 향상
• 더불어 코드 리뷰 능력이 크게 향상
• 설계 및 구현 능력이 크게 향상
• 협업과
• 열정 재미 향상

주의해야할 것들

• 오픈소스 만능 주의: 우물 안 개구리이다. 오픈소스 개발이 최고다라는 생각 주의.
• 회사 업무와 병행한다면, 언제나 비중은 회사업무 > 오픈소스. 그래야 나중에 오픈소스를 할 떄 롱런 할 수 있음.
• 본인의 신체 건강( 각종 디스크류, 기타 등등): 몸을 혹사하게 됨.
• 본인의 정신건강(특히 번아웃 증후군)

오픈소스가 정답은 아닙니다. 그러나 누군가에게 모범답안일 수 있다.

두번째 이야기, 나는 뼛속까지 개발자는 아니다, 고병권

뼛속까지 일반인. 어느 순간, 나는 개발하고 있는 회사원이라는 자각이 됨. 회사원이 아닌 개발자가 되기로 함. 회사원과 개발자를 비교하자면, 개발자는 자신의 가치를 스스로 표현 가능. 예를 들면, 나는 어떤 플랫폼의 개발자이다.

회사원에서 개발자로 거듭나기 위해서는 무엇을 해야 할까? 회사에서 하는 개발 일은 밖에서 내가 무엇을 하는지 다른 사람이 알 수 없다. 그래서 오픈소스를 찾게 되었다. 크로미움을 선택했다. 경험이 있었고, 많은 사람들이 사용하는 SW, 다양한 분야를 경험할 수 있는 기회였기 때문.

도전하기.

시간이 나면 하는 것이 아닌, 꾸준함이 핵심. 꾸준함을 위한 나의 노력.

1. 컨퍼런스 세미나 꾸준한 참여.
2. 두번째: 강제성(벌금) 도입: 전체적인 과정에 익숙해짐. 좋인 계기. 빨리 많이 해야해서 기술적으로 깊이가 없어짐.
3. 세번째: 벼량 끝으로 Move. 제가 기여하고 있는 부분에 대해서 컨퍼런스 발표를 하겠다고 연락함. 3분짜리를 해보자. 많이 힘들지만, 성장에 도움이 많이 되었음.

도움됐던 점

1. 성장. 가장 큰 점은 코드리뷰였음. 게속해서 많은 리뷰어들간 의사 교환할 수 있었고 성장을 했음. 마지막에 LGTM(Looks Good To Me, 참잘했어요 도장 같은 것).
2. 발표 요청. 이젠 다른 사람에게 발표 요청이 들어옴. 하지만 발표는 어려움.
3. KOSSLA. 코리아 오픈소스 개발자센터. 오픈소스에 참여하는 분들을 지원하고 장려하는 기관. 오픈소스를 하고 있다면 코스랩에 지원해보면 좋을 것.
4. 잘 흔들리지 않는다. 이제는 프로그래머라고 소개할 수 있게 되었음.

앞으로는

• 영어 말하기
• 체력 기르기
• 오픈소스 프로젝트 만들기

마지막으로 꾸준하게 하세요. 여러분이 꾸준함을 할 수 있는 방법 찾아보기.

오픈소스로 어플리케이션 완성도를 높이기, 이경일(Naver)

어플리케이션 완성도란 무엇일까?

완성도로 인해 우리가 얻을 수 있는 건 어떤 것이 있을까요?

• 퇴근 후 전화가 오지 않는다는 마음의 건강
• 성취감
• 가장 큰 것은 한층 성장했다는 보람

오늘 할 이야기

• 버그 잡고 퍼포먼스를 올리기 위한 목적으로 오픈소스를 활용하는 이야기를 하고자 합니다.
• 버그 관련 이야기로 시작
• 특지 잠재적인 버그

버그란 개발자가 의도하지 않은 결과가 나오는 현상: 데이터의 불일치, 오류로 인한 의도하지 않은 코드 동작.

버그는 없을 수는 없다. 대비를 어떻게 잘 할 수 있을까?

제일 좋은 방법은 테스트케이스 작성이다. Junit을 많이 쓰지만 오늘은 Spock framework 소개. TDD가 아니라 BDD 기반의 테스트 케이스 라이브러리이다. 시나리오 기반. Behavior Driven Development. TDD는 제로케이스에서 완성하기 위한 방법. BDD는 어느정도 만들어놨고, 미리 짜 놓은 코드를 검증하는 과정에 가까움. 개발자가 아닌 사람이 테스트 코드를 봐도 이해가 쉽다. groovy로 작성해서 간결하다.

Spock 소개

테스트 케이스 작성 할 때. JUnit는 static import가 많아서 불편함. 스폭은 테스트 케이스에 대한 공부가 필요 없음. 스폭은 테스트 결과가 이쁘게 보여줌. 스폭은 private 메서드도 테스트가 가능하다. reflection 이용. 시나리오 뿐만 아니라 단위 테스트도 중요하다. 단위 테스트를 편하게 하기 위해 메서드를 명호가하게 좀 더 작게 나누면 본 소스코드가 가독성이 좋고 유지 보수가 편해짐. 메서드명에 And가 들어간 메서드는 잘게 나눠야 한다. 테스트 케이스 작성으로 품질이 올라감. 문제는 개발자가 본인이 의도한대로 테스트케이스를 작성한다. 개밥 먹기라는 테스트를 통해 해결. 개발자가 아닌 유저 입장에서 사용해보는 테스트 기법. 꾸준하게 개밥을 먹는 것이 중요하다. 테스트케이스에서 잡지 못한 버그를 발견할 수 있다.

오픈소스 호스팅 플랫폼. Github.

이전 버전과 변경된 점이 무엇인지 비교를 하고 다른 사람이 코멘트를 달 수 있다. 처음에 90프로는 컨벤션 이슈이다. 더 나은 로직을 제안 받을 수 있다. 먼저 삽질한 사람의 경험을 공짜로 받을 수 있다. 잠재적 버그를 발견할 가능성이 있다. 집단지성, 선구자의 도움으로 장애를 피할 수 있다. 코드 리뷰를 통해 상처를 받을 수 있다. 온라인상에는 감정이 전달되지 않기 떄문에, 이모티콘을 많이 사용. 코드 리뷰에 거부감을 보이는 개발자도 있으니 배려가 필요하다.

성능 테스트와 오픈소스 이야기.

성능 테스트 중요하다. 성능을 파악해 인프라를 미리 준비할 수 있다. 가장 중요한 잠재적 버그를 찾을 수 있다. 성능 테스트를 하기 위해 필요한 것은 운영환경과 동일한 사양의 서버 1대. 똑같은 것을 찾을 수 없으면, 기준 사양보다 줄여서 사용하고 계산해서 실제 사양 예측. APM 환경 설정 필요. Application performence mangerment. Naver PinPoint 추천. 핀포인트는 어플리케이션 상태를 한 번에 볼 수 있음. 실시간 응답 속도를 볼 수 있다. JVM 상태 디스크 상태 등을 볼 수 있음. 다음으로 부하를 발생시켜야 함. 이럴 때, Stress Test Tool을 사용한다. 네이버 nGrinder, 아파치 Jmeter, 아파트 웹서서버 밴치마크 툴.

NGrinder 성능 테스트 도구 소개

회사에 안되어잇으면 장비를 받아서 구축해보는 것도 좋음. 도커로 잘 되어있음. 운영환경과 비슷한 환경에서 테스트가 가능하다 . URL만 있어도 바로 테스트가 가능하다. 사용하기 편한 UI가 장점이다 .실시간 테스트 상황을 조회가 가능하다. 로그파일도 제공. 상세 정보 제공. 테스트 스크립트를 직접 작성이 가능하다. 파이썬, groovy 사용 가능. SVN 내장. 앱 서버 폴더 구조 중 리소스 폴더에 접근이 가능하다. 예를 들어 이미지 파일이 테스트할 때 필요하면 사용이 가능하다 .

성능 테스트와 오픈소스 사례 공유

메모리 이슈가 있었음. heap 메모리를 많이 쓰고 있었음. 개선할 수 있었던 것은 부하 테스트를 많이 해봤음. 250회 정도 일주일 간 테스트했음. 한 시간 정도 부하 테스트를 돌려보니 이상 징후 발생. 로그가 없이 서버가 다운됨. 이럴 떄는 oom killer를 의심해봐야 함. OS가 메모리가 부족해서 특정 프로세스를 강제로 종료시키는 것. 보통 VJM 을 죽인다. LINUX 는 리눅스 로그 저장소에 저장됨. OpenCV 과 Java 간의 브릿지에 문제가 있다고 추정했음. 그래서 자바 버전을 내리면서 테스트. 그리고 다시 NGrinder 테스트 돌려봄. 스프링 캠프 때 발표하였음. 참고. 부하 테스트를 하지 않고 그냥 테스트 했다면 어땠을까? 출시하자마자는 몰랐겠지만, 배포하고나서 시간이 지나면 장애가 생겼을 것. 출시 전에 빡시게 부하 테스트를 해보기를 추천드림. 핀포인트와 Nggliner를 사용해서 성능 테스트를 추천드림.

로깅과 오픈소스 사례 공유

어플리케이션에서 발생하는 모든 데이터 상황이 필요하다. 만약 상품이 잘못된 가격으로 팔렸을 떄, 직접 오류 부분을 찾고 수정해야 한다. 로깅설루션의 조건은 모든 데이터를 쉽게 수집했으면 좋겠다. 비지니스 로직에 침투적이지 않으면 좋겠다. 프로젝트 일루미나티를 만들게 직접 됐다. 제가 생각하는 조건을 만족한 툴. 이것을 적용해서 유저들의 사용행동을 추적을 할 수 있음.

왜 직접 만들었을까?

업무를 하다보면 필요성을 느낌. 유저 추적도 필요했었고, 때마침 회사에서 로그 통합 TF를 시작했음. 하지만 생각과 달랐음. 로그용 DTO를 비지니스 로직에 끼워넣어야 했었음. 제 기준에 만족을 못해서 직접 만들어서 소개했음. 동의를 해서 서비스에 적용했음. 혼자서 했던 TestBed에서 볼 수 없었던 것을 발견할 수 있었음. 선배 개발자들에게 코드 리뷰를 해달라고 계속 요청했음. 오픈소스를 직접 만들고 배포를 해보면 버그를 발견할 수 있다. 개발하는 오픈소스가 있으면, 인텔리제이를 무료로 사용할 수 있다.

오픈소스 기여하면 뭐가 좋을까?

현업을 하면서 모든 사람이 오픈소스 개발자가 될 순 없다. 적재적소에 잘 쓰는 것도 어플리케이션 완성도를 높일 수 있다. 오픈소스를 만들면 본인 프로젝트에 적용해보자. 도움이 된다.

키워드 정리

• 테스트 케이스 - Spock
• 코드 리뷰 - GitHub
• 성능 체크 - PinPint
• 안정성 테스트 - NGlinder

나는 어쩌다 오픈소스 프로젝트 맴버가 되었나, 권혁진(Databricks)

• 애자일, 실리콘밸리 스타일, 칼퇴 문화, 오픈소스 학습 분위기 등 현재 유행하는 것들을 첫 회사에서 배울 수 있었다.

• 유명한 오픈소스 프로젝트는 사람들이 많이 모이다보니, 이쁘게 잘 코드를 만든다.

• 개발툴과 테스트가 중요하다고 생각한다. 코드를 열어서 무조건 테스트를 돌려보고 그 다음부터 개발을 시작한다. 오픈소스에는 사용할 도구와 사용 방법들이 가이드로 나와있다. Jira를 사용했었음.

• 오픈소스를 기여하려면, 사람들이 고치고 있는 코드들을 파악한다. 여러 Patch들을 보면서 간단한 실수에 대해 바로바로 수정.

• 단계별 목표를 세움.

  1. 컨트리뷰터 100위 안에 들기.
  2. 둘째, 누가 나를 cc 해주기.
  3. 질문하기.
  4. 커미터와 PMC한테 칭찬듣기.

• 회사를 마치고 오픈소스를 하다보니, 하루에 3시간 정도 밖에 못 잠. 약간 뜰려고 하는 프로젝트 참여하면 좋음. 작은 프로젝트는 3~4달 정도 하면 커미터를 시켜줌. 할꺼면 마이너한 프로젝트를 하면 됨.

• 의견 충돌으로 감정과 시간을 소비하는 단점이 있음.

• 오픈소스를 한 후에는... 나의 능력치는 평범 혹은 그 이하이다. 코드는 최대한 이해하기 쉽게. 로직 작성 10%, 쉽게 다시 작성 50%, 테스트 50%. 아는 척 나대지 말자. 결국 탄로난다. 알아도 겸손. 중요한게 아니면 그냥 져줘도 된다. 작은건 그냥 넘어가라. 나는 평균 실력이라 생각하고 열심히 해야 한다. 작은건 그냥 넘어가라. 문제해결에만 집중하자. 구글에서 열어본 페이지 끝까지 정독하기. 프로젝트 별 규칙 및 방법론 준수하기. 익숙해질 때까지 코드 한 줄 한줄을 구글링. 일반적으로 받아드려지지는 최선의 코드를 손에 익혀놓기.

• 테스트 -> 코드 재작성 -> 쉽게 작성. 코드 한줄한줄 질문에 답을 할 수 있도록 정리.

• 일단 프로젝트 규칙에 무조건 따르기. 정 아니다 싶으면, 건의를 해서 바꾸자.

• 사람에 대해서 말하지 말고, 코드와 일 관점에서 이야기하기. (서로 마음 상하지 않도록 배려)

• 코딩 인터뷰를 잘 못한다면, 오픈소스 활동을 통해 내 실력을 증멸할 수 있다.

• 실리콘 벨리 회사에서, 애자일을 배우고 발표를 할 수 있었음. 오픈소스에서도 애자일 방법론을 따르고 있음.

• 오픈소스에 글로벌 스탠다드가 맞춰져 있음. 그래서 다른 회사에 가서도 적응이 빠름.

• 강약중강약이 중요함. 필요할 때는 정말 집중해서 한 두시간 자면서 하고. 쉴때는 확 쉬고. 정말 능숙하게 잘하는 사람이 잘하는 거군아. 집중햇는지 안했는지 체크. 그런 리듬을 잘 관리.

• 오픈소스 작업을 하면 이력을 따로 안 준비해도 됨.

• 그냥 눈으로 보는 것보다, 무조건 테스트를 해보는 것이 낫다.

오픈소스 스프린트: 기획부터 실행까지, 이서현/이희승(LINE)

스프린트 준비하기, 이서현

• 4일 동안 팀을 구성하여 하나의 오픈소스를 집중적으로 배우고 개발.
• 행사 준비 설명
• 발표자료에 예시와 자료들이 많이 있어 참고.

스프린트 실행하기, 이희승

contributing md

• build requirement: jdk 11, gradle.
• 개발 환경 설정 방법
• 코딩 스타일 가이드
• code of conduct
• cla ( contributor licnece agreement)

good first isssues

• why 왜 해결해야 하는가
• where 어디가 문제인가
• how 어떻게 해결해야하는가
• 스프린트를 사내에 적용해보는 것도 좋을것 같다. 지금은 사내 스프린트만 진행했었음. 앞으로 사외 스프린트 진행할 예정.
• 아르메니아

대담

• 컨트리뷰션하는 행사에 가서 열정적인 멘토를 찾기.
• 코드에 대한 피드백을 들을 때, 피드백의 대상이 자기자신으로 여기지 않기.
• 예의를 지키기. 예를 들어, 코멘트를 남겨주시면 고맙다고 코멘트 달기. 도움을 요청할 땐, 상대방을 배려해서 요청. 너무 늦은 시간에 연락을 하는 경우 등.
• 디자인패턴 남용 했었는데, 오픈소스를 사용하다보니 적절한 시점에 사용할 수 있게 됐다. 이렇게 된 것은 2년 이후부터.
• 오픈소스를 남용하지 말고, 꼭 필요한 것만 사용하자는 철학을 가지고 있다. 예를 들면, 요즘 자바로 되어있는 것을 코틀린으로 바꾸는 트렌드를 무조건 따라갈 필요가 없다. 필요에 따라 그만큼 적용하면 된다.
• 새로운 프로젝트나 기술을 사용해야 할 때, 어려움을 겪는다. 이럴 땐, 검색을 통해 어떤 키워드가 필요한 지 알아낸다. GitHub에 관련 샘플코드를 검색 구경. 한계에 부딪치면 한 템포 쉬면서 한다. 예를 들면, 여자친구에게 새벽에 전화를 한다.
• 프로그래밍을 하다보면, 수학을 사용해야 할 때가 있다. 모르는 것은 중학교 수학책 기초 책부터 하나씩 찾아본다. 안되는 것은 없다고 생각한다. 시간이 많이 걸릴 뿐이지. 스파크를 할 때 코드를 봐도 아무것도 몰랐을 때, 계속 보면 됐었다. 내가 생각한 한계는 한두발작 더 나가보면 한계가 없다는 것을 알게 된다.
• 회사에서 코딩을 한 줄도 하지 않는다면, 회사 업무 중에 자동화할 것을 찾고 코딩해보기.
• 지속적인 컨트리뷰션하기. 행사 진행. 문서화 작업. 등으로 관심을 돌려보기. 지속적인 컨트리뷰션을 그냥 정석대로 해야 한다. 마이너한 프로젝트는 이슈 보드에 대답을 잘 다는 것도 컨트리뷰션.
• 날코딩을 하는데 오픈소스 프로젝트 수준에 어떻게 맞출 수 잇을까? 남들이 한 패치(Patch)를 잘 읽고 그대로 따라해서 해보기. 처음에 고생했음. 따라가면서 적응해가기.
• 회사 상황이 그래도, 본인 의지가 중요하다. 하고 싶은 것은 야근 할 때 데모 프로젝트, 토이 프로젝트를 만들어서 계속 보여준다.
• 막상 해보면 별 꺼 아니다. 지속적인 노력이 필요하다. Pull Request가 거절당하는 상황이 많음. 테스트 실패해도 괜찮다. 다시 재작성을 하면 된다. 테스트가 존재하고 있기 때문에 괜찮다.
• 업무를 하다가 오픈소스를 사용하다가 개선해야할 점을 발견해서 오픈소스 기여를 시작하게 됐다.

참고

• 발표자료는 신청 사이트에 올릴 예정