연사들과의 자유 Q & A
안녕하세요. 2018년 2월 23일 그린팩토리에서 열렸던
제2회 네이버 오픈소스 세미나를 다녀왔습니다.
이번 세미나에서 박은정 님이 사회를 맡아주시고
권민재 님, 김희재 님, 변정훈 님이 연설을 맡아 주셨는데요.
연사들과의 자유 Q&A 시간에
기대 이상으로 피와 살이 되는 내용이 많아서 많은 분들에게 공유하고자 글을 남깁니다.
질문과 답변들을 메모해뒀다가 정리 해보았습니다.
문장이 깔끔하지 못한 부분도 있을거고
읽으시다가 이해가 안되는 부분도 있을거라 생각됩니다.
무엇보다 제가 올린 것들이 연사분들에게 누가 되지 않았으면 좋겠습니다.
관련용어를 제가 잘못 이해 했을 수도 있고
말씀하신 부분을 제가 잘못 적을 수 있다는 점 유의해서 봐주시면 감사하겠습니다.
Question 01.
오픈소스에 커밋(commit), 이슈(issue)를 영어로 작성하고 계시는데
영어 공부는 어떻게 하시는지 궁금합니다.
김희재 님 (네이버 FE플랫폼)
copy & paste 아시죠?
먼저, 구글번역기를 이용해 한글 문장을 영문으로 바꾸고, 다시 한국어로 돌려서 어색하지않는지 크로스 체크를 해요.
그렇게 해서 검색했을 때 내가 원하는게 나오는지 확인을 하죠.
이렇게 하다보면 개발자들이 많이 쓰는 용어들을 알아가게 되는 것 같아요.
Question 02.
테스트 코드(Test Code) 가 중요하다고 하셨는데
테스트 코드에 버그가 발생하면 어떻게 생각해야 하나요?
김희재 님 (네이버 FE플랫폼)
테스트에 버그가 있을수 있냐고 하셨잖아요.
테스트는 그 코드가 어떻게 동작해야 한다 라는 스펙같은 의미로 쓰고있어서..
2가지 종류가 있어요.
1번째 : 스펙버그
테스트가 결국 스펙이거든요.
우리가 스펙을 잘못 정의했구나. 스팩을 바꿔야하구나. 라고 생각해볼 수 있겠죠.
2번째 : 테스트를 잘못짬.
말그대로 테스트케이스를 잘못 짠거에요.
Question 03.
오픈소스 중에서 유용하게 참고하신 오픈소스가 있으신지 궁금합니다.
김희재 님 (네이버 FE플랫폼)
자기 분야에 관련된 Star가 많은 오픈소스를 참고하는게 좋다고 생각합니다.
저같은 경우는 Treejs, 구글의 vr view 등을 참고했어요.
Question 04.
제가 철도 회사에 근무중인데 오픈소스에 대해 폐쇄적이에요.
만약 산업을 다 떠나서 소프트웨어를 개발하는 회사라면..
특정 기술에 대해서 오픈소스로 공개해야 하는것이 맞는건지 궁금해요.
변정훈 님 (Outsider)
개인적으로 내놓아야 할 필요가 있다고 생각 해요. 사회에 기부 차원에서요. ㅎㅎ
강요를 할 순 없겠지만, 기부하는 공감대가 필요하다고 생각을 하고요.
그리고 오픈소스를 공개한다고 해서 회사에 있는게 밖으로 나가는게 아니에요. 말아들어 가는거지...
보통 이런 결정은 회사에서 경영진, 법무팀에서 내리는 경우가 많기 때문에...
개발자가 내리진 않거든요.
개발자는 오픈소스화 하는게 별거 아니라고 생각 하더라도,
위에서 " 이거 경쟁 상대한테 좋은거 아니냐 ? " 라고 생각할 수도 있잖아요?
이건 회사 내부에서 풀어나가야 할 문제 같네요.
Question 05.
네이버가 오픈소스 활동을 하고 있는데요. 모든 소스를 공개하시는 건지,
아니면 특정 기술에 대해서만 공개를 하시는건지 궁금합니다.
박은정 님 (Naver OpenSource manager)
만약 특허 같은게 같이 얽혀있는 서비스나 플랫폼이라면 그걸 분리하는 작업을 하죠.
사내에서 멀쩡히 잘 쓰고있는 소스를 공개 하려면 문서부터 리팩토링까지 다시 진행해야 해요.
개발자들의 업무가 갑자기 불어나는 거죠.
그리고 공개를 하면 끝나는 것이 아니라 공개를 하면 그 때가 시작입니다.
회사 입장에서는 공개 하는게 더 좋아요.
외부에서 소프트웨어 품질을 높여주기도 하고, 채용하기도 더 쉽죠.
컨트리뷰터들은 러닝커브 없이 금방 적응할 수 있으니까요.
소프트웨어 공개라는 것이 회사에서는 권장 하지만 개발자에게는 굉장히 많은 각오가 필요한 일입니다.
여러가지로 일들이 많아요. 이렇게 세미나하러 끌려 오시잖아요. ㅎㅎ
네이버에서는 개발팀이 의지를 보이면 서포팅을 해주고 있어요.
저는 회사 입장에서 반대할 이유는 전혀 없다고 봐요.
변정훈 님 (Outsider)
회사 입장에서 오픈소스는 마케팅 이라고 생각을 해요.
회사가 기술블로그나 오픈소스로 공개 하지 않으면
밖에서는 그 회사가 어떤 문화를 가진 회사인지 알 수가 없잖아요 ?
오픈소스 공개로 개발자에게 매력적으로 느끼게 하는거죠.
우리 개발팀이 정도로 좋아! 우리회사 마인드는 이런데, 우리회사 오고싶지?
2가지 장점이죠. 오픈소스를 하면서 홍보도 하는...
Question 06.
대학생인 저에게 오픈소스 한다는게 저에게는 낯설게 느껴집니다.
오픈소스 활동에 개발자의 역량이 중요한지 궁금합니다.(현재 어플 개발중)
권민재 님 (썬데이토즈)
앱을 개발하다가 특정 부분은 모듈화 할 수 있잖아요 ?
그런것들을 공유 해봐도 되고..
저는 오픈소스 활동에 개발자의 역량보다는 마인드가 중요하다고 생각해요.
자신의 코드를 공개하는 것을 꺼려하는 경우도 있을거고요.
공개했는데 다른사람이 내꺼 잘못 되었다고 이슈(issue)를 날렸을때 버틸수있는 멘탈도 중요한 것 같아요ㅎㅎ
Question 07.
오픈소스 활동을 위해 대학생들은 어떤 준비를 하면 좋을까요?
또, 오픈소스 활동이 취업에 어떻게 도움이 될지가 궁금합니다.
권민재 님 (썬데이토즈)
취업을 위한 오픈소스 활동 ? 그런건 잘 모르겠어요..
물론 이런 경우는 있어요.
어떤 회사에서 오픈소스 운영하는게 있는데 거기에 기여하면 당연히 메리트가 되겠죠?
예를들어 안드로이드 회사가 오픈소스로 내놓았는데 거기에 자신이 계속 기여를 해왔다면
회사 입장에서 굉장히 메리트있게 다가오겠죠?
그런 면에서는 취업에 도움이 될거 같습니다.
김희재 님 (네이버 FE플랫폼)
저도 취업관련해서 답변드리면요.ㅎㅎ
공채같은건 잘 모르겠지만, 이직도 똑같거든요.
만약 들어가고 싶은 팀이 있는데, 그 팀의 기술스택을 오픈소스로 공개를 했다면 거기에 컨트리뷰트하면 좋겠죠?
예를들어, 지도 라는 분야가 있고 그 분야에서 오픈소스 활동을 하면 입소문이나요. 직접 연락 올 때도 있고요.
변정훈 님 (Outsider)
저는 면접관 입장에서 답변을 해줄 수 있을 것 같아요. 물론 제 기준이지만요. ㅎㅎ
개발자의 핵심 역량은 호기심인것 같아요.
계속 궁금함???
신입분들에게 아쉬운것들 중 하나가..
신입분들은 경험이 없잔아요? 해본게 많지 않으니까요.
그래서 면접에서 자신의 성과 (전 이런 사이트 만들었어요!) 를 계속 보여주려고 하는 경향이 있는데요..
그런데, 면접관이 보는건 " 무엇을 만들었느냐 ? " 가 아니에요.
지원자가 스프링 프레임워크를 사용하여 개인 프로젝트를 했다고 가정해 볼게요.
면접관이 궁금한 건 이 친구가 프로젝트 하면서 라우팅쪽으론 궁금하지 않았을까?
어노테이션이 어떻게 돌아가는지는 궁금해하지 않았을까?
만들면서 뭔가 하나는 궁금했을 꺼 같은데....
만드는 것에만 관심이 있으면 안되는거죠.
실무에서 개발을 하다보면 파가아 햘 상황이 생기거든요.
내 버그가 아닌 것 같으면 내가 썼던 라이브러리를 확인을 해 보는거죠.
궁금하잖아요. 이게 맞는지 아닌지. 그런 호기심에 파다가 만약 라이브러리에서 잘못된 것을 찾았다면 ?
그 라이브러리에 컨트리뷰트 하는거죠..ㅎㅎ
결국 회사에서는 지금 엄청 잘하고 있진 않더라도, 열망이 있는 친구를 뽑게 되는 것 같아요.
갈증은 많은데 뭘 해야할지 잘 모르는 신입에게 방향을 잡아주는거죠.
그런 부분이 학생에게 중요하지않나 싶어요.
추가로, 프로젝트에 트렌디한 툴을 썼다면.. 우와 너 그런거에 관심이 있구나??
라고 생각 할 수도 있겠죠. 이런 것도 플러스 되는것 같습니다.
Question 08.
제가 볼 땐 오픈소스마다 커뮤니티가 있는 것 같더라고요.
어떻게 커뮤니티에 참여할 수 있을까요?
변정훈 님 (Outsider)
초반에는 여기저기 왔다갔다 하기 보다는 한 곳을 지정해서 얼굴을 자주 보이는 것이 커뮤니티에 들어가는데 좋지 않을까요?
그렇게 하다보면 너가 이슈정리만 좀 해줄래 ? 라고 할 수도 있고..
그렇게 커뮤니티 들어갈 수도 있는거죠.
프로젝트마다 메인테이너가 있을거잖아요?
이슈(issue)나 풀리퀘(pull request) 날렸는데 커밋 안해주고 나 안해! 이런 메인도 있고요.
반면에 친절하게 답변해주는 사람도 있어요.
이건 개발자 성향인 것 같아요.
만약 컨트리뷰션이 모잘라다면
컨트리뷰션이 모자라니까 노력하는 사람이 있고,
어짜피 안와 라면서 마이웨이 하는 사람도 있잖아요.
친절한 사람이랑 불친절한 사람 구분하는 팁을 드리자면
이슈에 라벨링(Labelling)이 잘 되있는 애들이 친절한 경우가 많았어요.
Question 09.
제 프로젝트에도 많은 개발자분들이 관심을 가져줬으면 좋겠는데요.
많은 관심을 받는 비결이 있을까요 ?
변정훈 님 (Outsider)
오픈소스도 경쟁시대라서요...
우리가 깃허브에서 자주 보는건 스타(star)도 많고 이슈(issue)도 많고 그렇잖아요 ?
그런데 그런 것들은 소수에 불과해요.
그래서 깃허브 안에서 컨트리뷰션이 많이 이루어지는것 처럼 보이는데, 실제로는 그렇지 않아요.
저같은 경우에도 랭귀지나 설정과 같은 컨트리뷰션은 오지만, 정작 코어쪽은 잘 안오거든요.
관심을 받는 팁을 드리자면..
영어로 문서 작업을 해놓으면 글로벌 적으로 노출 시킬 수 있겠죠.
아니면 자신의 SNS에 올리는 방법도 있겠고요.
스택오버플로우(Stack Overflow)나 레딧(reddit) 같은 커뮤니티에
자신의 프로젝트 관련된 질문이 있다면 거기에 답변으로 올리기도 하죠.
만약 거기서 유명한 애들이 내 링크를 뿌려준다면 거기서 뻥하고 뛰는겨죠.
그럼 그때부터 해피니스 해지는거죠. ㅎㅎ
Question 10.
오픈소스에 공식문서가 있어도 코드 읽는데 어려움이 있어요.
쉽게 읽을 수 있는 방법이 있을까요?
변정훈 님 (Outsider)
다른사람 코드를 리딩하는 것은 어렵고, 금방 느는 스킬도 아니죠. ㅎㅎ
하지만 꾸준히 한다면 실력을 축적하는데 독보적으로 좋다고 생각은 하고요.
오픈소스 중에 인기가 많은 것들은 읽기가 어려워요. 시간이 지나면서 추상화가 많이 됬거든요.
웹팩(WebPack) 같은건 읽어볼래도 엄청 어렵죠.
그래서 이런건 오픈소스의 초기버전을 보는 것을 추천드려요.
기능은 부족하겠지만 의도는 쉽게 파악할 수 있거든요.
물론, 지금은 초기버전과 엄청 달라졌을 수도 있다는 점은 감안해야 할 부분이고요.
김희재 님 (네이버 FE플랫폼)
저는 코드 볼 때 모듈들이 어떻게 나눠져있는지 구조를 파악합니다.
다이어그램을 그려보고 흐름파악이 가능하다면 세부구현은 쉬워지지 않나 생각합니다.
코드 읽다가 이 라인은 무슨 생각으로 짰는지 궁금하면 블레임(blame) 찍어봐요.
이 라인이 이렇게 되기 시작한 커밋을 찾아서 그게 이슈나 링커가 있나 찾아보고요.
히스토리 찾아보면서 코드를 읽으면 그냥 읽는것 보다 훨씬 대화하는 느낌도 나고 좋은거같아요.
여러분 블레임(blame) 쓰세요. ㅎㅎ
권민재 님 (썬데이토즈)
저같은 경우에는 작은 프로젝트를 많이 봤잖아요 ?
CLI(Command Line Interface) 같은 경우에는 엔트리 포인트가 정확하거든요.
그럼 일단 실행해 봐요. 실행하면서 코드와 같이 보면 플로우가 보이거든요.
그럼 어느 추상화 레벨에서 어느 코드로 들어가는지도 보여요.
CLI를 쓰신다면 이렇게 하시는것도 괜찮을 것 같습니다.
Question 11.
제 프로젝트가 어떤 오픈소스에 의존을 하고 있는데요.
스타(star) 수가 낮은데 그냥 놔둬도 괜찮을까요 ?
변정훈 님 (Outsider)
그 라이브러리에 버그라던가 기능개선이 필요할 수도 있을텐데,
메인테이너에게 이슈(issue)나 풀리퀘(full request) 날려서 반영(commit)을 요청해야겠죠.
만약 반영을 안해준다면 포크(pork)따서 프라이빗으로 기능 추가하거나 할순 있겠죠.
하지만 좋은 방법은 아니라고 생각하고요.
그 기능을 제공하는 다른 라이브러리를 찾아서 갈아끼우는 방법도 있어요.
기존 라이브러리가 사방에 퍼져 있다면 온 동네방네 수정을 해야겠죠 ?
인터페이스를 이렇게 짜면 기존소스에 영향을 안미치겠구나. 라고 느끼면서
그 코드를 몰아놓는거죠. 앞에 인터페이스로 감싸서 걔가 다 참조하고 있고...
이런 경험들로 실력을 올릴 수도 있겠죠.
김희재 님 (네이버 FE플랫폼)
저희 팀의 경우에는 아이스크롤 라이브러리를 수정 할 때가 많이 있는데요.
저희 팀원 중에 이 라이브러리에 컨트리뷰트를 계속 하셔서 커밋(commit)권한을 얻으신 분이 계세요.
포크(pork) 따는 것보다 오너한테 어필을 계속해서 커미터(committer) 권한을 달라고 메일을 보내면
호의적으로 답변이 올 때가 있어요.
이렇게 접근하는 방법도 괜찮은 것 같아요.
Question 12.
저도 제 프로젝트에 어떤 오픈소스를 사용하는데요.
그 오픈소스 사용에 대한 라이센스(license)가 궁금합니다.
변정훈 님 (Outsider)
오픈소스 사용은 라이센스 마다 다른데요. 여기서 참조했습니다 라는 표시는 아마 거의 다 해줘야 될거에요.
라이센스가 표시되어 있지 않다고 해서 그냥 막 써도 되는거네 라고 생각하시면 안되요.
오히려 내가 모든 권한을 가지고 있다는 걸로 되거든요. 그래서 라이센스가 안쓰여져 있으면 따로 연락을 취해야 되요.
만약 오픈소스 코드를 바꿔서 내가 거기서 가져온걸 모르게 하겠다 이거는 대부분 라이센스 위반이에요.
박은정 님 (Naver OpenSource manager)
라이센스부분은 복잡해서 여기서 바로 말씀드리기가 어려운 부분인데요.
불법다운로드 하지 맙시다 / mp3 파일 돈주고 삽시다 처럼
오픈소스도 그것을 개발한 개발자가 라이센스를 가지고 있거든요.
만약 저희가 이용하고 싶은 오픈소스가 있다면 그 오픈소스의 메인테이너에게 이메일을 보냅니다.
우리가 이걸 이어가고 싶다. 이유는 이러이러하다. fork해서 사용해도 되겠느냐?
이런식으로 메일을 보내요.
답이 없으면 2~3번 더 메일을 보내고, 그래도 답이 없을 땐 사용 시 출처를 적어놓는 편이에요.
이상입니다.
강연 후 설문조사를 하면 오픈소스 가이드 책자를 나누어 주셨는데, 네이버 오픈소스 가이드 에서도 보실 수 있습니다.
( 여기에 발표 ppt자료도 올라와있습니다!!)
