Droidcon boston chiu ki chan header

안드로이드 전문가가 되는 법

소개

저는 Chiu-Ki라고 하며, 안드로이드 전문가가 되는 방법을 말씀드리겠습니다.

당신이 전문가라고 생각하는 사람을 한 번 떠올려 보세요. 그분이 전문가인지 어떻게 아셨나요? 안드로이드에 대해 많이 알 수도 있고, 그분이 안드로이드에 관해 쓴 책을 읽었을 수도 있겠죠. 안드로이드에 대한 강연을 들었거나 안드로이드에 대해 알려주는 비디오를 봤을 수도 있을 겁니다. 블로그 포스트나 Stack Overflow 답변을 읽었을 수도 있죠.

사전에서는 전문가를 특정 분야에서 포괄적이고 권위 있는 지식을 가진 사람이라고 합니다. 그 정의에 따르면 전문가는 존경과 숭배를 받기 위한 사람일 수도 있겠네요. 하지만 좀 더 사람다운 정의를 생각하면, 전문가는 자신의 지식을 공유하는 사람일 겁니다.

지식을 나눌 때 전문성을 얻게 되고, 더 많은 전문성을 얻으면 더 많이 공유할 수 있게 되죠. 멋진 선순환입니다. 뭔가 공유하려면 본인의 머리에서 지식을 꺼내야 합니다. 그리고 선형적인 공간에 정렬하려면 연속적으로 줄 세워야 하겠죠. 아직은 다른 사람에게 전달할 수 있는 두뇌 개념의 3D 매핑이 없으니까요. 또한, 뭔가 공유하기 위해서는 각기 다른 컨셉 간의 관계를 설명해야 합니다. 그 과정에서 더 많은 것을 배울 수 있고 개념 사이의 여백도 채울 수 있습니다. 이렇게 전문성을 높여갈 수 있습니다. 뭔가 설명하고 싶다면 논리적으로 정렬하기 전에 그것이 의미하는 바를 먼저 파악해야 합니다.

아리스토텔레스는 “심오한 지식을 유일하게 나타내는 것은 교육의 힘이다“라고 말했습니다. 고대 그리스 철학자가 안드로이드 개발에 대해 뭘 알겠냐고 생각한다면 왜 지식 공유가 전문성을 향상하는지 다른 방법으로 말씀드리겠습니다.

예를 들어 리스트뷰에 대해 설명한다고 생각해 보죠. “어댑터를 사용해야 하고 뷰 홀더들이 필요합니다. 스크롤 했을 때 뷰를 재활용하는 이유는 잘 이해하지 못했는데, 아.. RecyclerView라는 것을 들어보긴 했네요. 그래서 어댑터가 필요하고, 또 데이터가 필요하죠…” 이런 설명 과정으로 자신이 어떤 것을 이해하고 있고 어떤 것을 이해하지 못하는지 파악할 수 있습니다. 그리고 한 번 이 과정을 거치면 RecyclerView에 대해서 더 알아야 하고, 설명할 거리가 더 늘어납니다.

샘플 프로젝트

하지만 공유할 시간이 없는 사람은 어쩌죠? 좋은 점은 공유가 실제로 시간을 아껴준다는 것입니다. 저는 이 사실을 실수를 통해 발견했습니다.

위 그림이 제가 만든 앱의 아키텍처라고 해보겠습니다. 네 개의 사각형이 함께 작동하는 구성 요소를 나타냅니다. 그런데 아이스크림콘이라는 새로운 라이브러리에 대해 듣고 앱에 넣고 싶어졌습니다. 하지만 바로 플러그인할 수는 없고 이 특정 라이브러리와 앱의 다른 부분과의 인터페이스를 연결해야 합니다. 몇몇 클래스를 작성하고 코드를 만들어서 아이스크림콘 라이브러리와 앱을 연결하는 인터페이스를 만들고 전체 복잡하고 큰 앱에 맞도록 만들기 시작할 겁니다. 그 중간에 갑자기 이 아이스크림 라이브러리는 민트 맛이니까 초콜릿 맛으로 커스터마이징하고 싶다고 생각하면 어떨까요? 초콜릿을 좀 뿌리려다 잘못된 곳에 뿌려버리면 아무것도 작동하지 않을 겁니다. 잘못된 것은 연결 코드일까요? 아니면 제 프로젝트나 라이브러리 자체가 문제일까요? 이쯤 되면 모든 것이 엉망으로 연결돼 있고 어떻게 돌아가고 있는지 알 수 없어 당황스러울 겁니다.

이런 개발 뉴스를 더 만나보세요

공유에 대해 말하고 있으니 다른 방법으로 접근해 보겠습니다. 먼저, 샘플을 만듭니다. 라이브러리인 프로젝트는 보통 Hello World 정도 레벨의 샘플 프로젝트가 있어서 컴파일해볼 수 있죠. 메인 프로젝트가 아닌 외부에서 이 앱을 컴파일해서 이 부분이 작동하는 것을 검증합니다. 이제 그 샘플에서 초콜릿으로 커스터마이징해봅니다. 만약 작동하지 않는다면 검증했으니 라이브러리 때문이 아니고 커스터마이징이 잘못됐음을 알 수 있을 겁니다. 제 프로젝트로 연결할 준비가 될 때까지 차근차근 단계별로 인터페이스를 구축해 나갑니다. 이렇게 하면 이 새롭고 잘 알지 못하는 기술을 분리할 수 있어서 많은 시간을 절약할 수 있고 어떻게 프로젝트에 이를 적용할지 정확히 파악할 수 있으므로 프로젝트에 적용해서 작동하도록 할 수 있습니다. 이 방법은 공유과 관계없이 시간을 아껴주죠.

이미 이런 단계로 작업하고 있다면 또한, 이를 공유해야 합니다. 회사 기밀 소스 코드와는 관계 없는 샘플 프로젝트를 만들어 냈으니 GitHub에 올려도 괜찮습니다. 게다가 멋지게도 이제 오픈 소스 기여자가 될 수 있습니다. 많은 사람들이 오픈 소스에 기여하는 것이 엄청난 일이라고 생각하고 저 역시 좀 수줍게 느꼈습니다. 하지만 추가로 일할 필요 없이 자신의 프로젝트에 사용할 샘플 프로젝트를 커스터마이징하는 것만으로 오픈 소스 기여자가 될 수 있고 업무에도 바로 적용할 수 있습니다.

경험을 나누는 블로그 작성 공식

이제 샘플 프로젝트를 독립적으로 적용해보는 경험을 했으니 이 라이브러리를 사용하기 위해 이런 단계를 거쳐서 성공했다는 이야기를 블로그로 공유할 수 있습니다. 사실 Hello World 레벨의 여러 샘플 프로젝트를 보면 이런 제한된 상황에서는 그 라이브러리가 작동하겠지만 복잡한 상황에 적용해도 괜찮을지 의심이 들 수 있죠. 이 라이브러리를 사용하기 위해 다른 라이브러리도 사용해야 했었다는 여러분의 경험을 공유하면 다른 사람들이 그 경험을 토대로 배울 수 있습니다. 이를 통해 블로그를 작성하는 공식을 얻을 수 있습니다. 프로젝트를 단계별로 빌드하고 이를 GitHub에 올리고 과정에 대해 작성하는 것이죠.

스크린샷과 코드

프로젝트를 만드는 동안 저는 과정을 스크린샷으로 담습니다. 예를 들어 단계별로 RecyclerView를 만든다고 해보겠습니다. 여러 크기의 아이템을 만들고 헤더를 추가하겠죠. 그다음 코드 조각도 만들 겁니다. 특히 코드를 붙여넣기 할 수 있도록 보여주는 것이 보는 사람에게 편리합니다. 또한, 한 장의 스크린샷은 천 마디 말을 대신할 수 있습니다. 만약 다섯 장의 스크린샷과 다섯 묶음의 코드 조각이 있으면 블로그 포스팅에 적을 만 개의 단어를 대신할 수 있습니다. 이것이 바로 제가 블로그 포스팅을 작성하는 비법으로, 기나긴 산문을 작성하는 것이 블로그의 목적이 아니라는 점을 깨달은 결과죠. 스크린샷과 코드 조각을 만들고 사이사이에 약간의 설명을 추가하는 것만으로 매끄럽게 설명됩니다. 여러 사진을 보여주는 것이 독자에게 호소력이 높기도 하고요.

컨퍼러스 리포트

많은 사람들이 컨퍼런스에 배움을 목적으로 참석합니다. 하지만 이 중 얼마나 배운 바를 공유하고 있나요? 컨퍼런스 리포트에서 경험을 공유하는 것도 좋은 블로그 포스트가 됩니다.

먼저 컨퍼런스에 대한 소개를 작성합니다. 다음으로 보통은 컨퍼런스에 어떤 일이 있었는지 작성하게 되는데, 이보다 멋진 트릭을 말씀드리자면 Twitter의 140자를 활용하는 겁니다. 트윗을 블로그에 임베드하면 많은 공간을 차지하지 않으면서도 예쁘게 보여줄 수 있습니다.

트윗 임베드

예를 좀 들어보겠습니다. 컨퍼런스 중에 깨달은 것에 대해 트윗할 수도 있습니다. 뭔가 재미있는 일에 관해서도 쓸 수 있겠죠. 혹은 강연자를 인용해서 컨퍼런스에 참석하지 않는 사람들에게 정보를 줄 수도 있습니다. 좋은 강연을 해준 강연자에게 감사할 수도 있고, 아주 간단하게는 “Droidcon Boston 첫 날입니다. 멋져요!”라고 트윗할 수도 있습니다. 컨퍼런스 행사장에서 바로바로 트윗할 수 있는 것이죠.

이런 트윗에 #DroidConBos 라는 해시태그를 답니다. 트윗을 작성하는 동한 해시태그를 검색할 수 있고, 같은 태그로 다른 사람들이 어떤 트윗을 했는지도 알 수 있습니다. 또한, 많은 단어를 적는 것보다 더욱 풍성한 블로그를 만들 수 있습니다.

사진 추가

다음으로 할 수 있는 것은 사진을 추가하는 것입니다. 컨퍼런스에 참석한다면 카메라를 가져가서 새로운 것을 발견하면 사진을 찍겠죠? 이 사진을 블로그 포스트에 추가하면 블로그가 근사하게 보이고 적당한 공간을 차지합니다. 예를 들어 연단의 강연자를 사진 찍고 간단한 노트를 추가하거나, 음식이나 기념품, 사람들을 찍을 수도 있겠죠. 컨퍼런스에서 많은 사람들이 행사를 즐기고 있으니 기록을 남기는 편이 좋지 않겠습니까?

스케치노트 추가

스케치노트는 노트를 한 줄씩 써 내려가는 대신 한 장의 종이처럼 2D 캔버스에 작성하는 것입니다. 노트를 가지고 글자 크기를 다양하게 조정해가면서 위치시키고, 컨셉을 보여주거나 관계를 나타내는 화살표를 그리거나 도형을 추가할 수도 있습니다.

어떤 사람들은 “나는 그림을 못그려요.”라고 걱정하지만, 위 그림을 보면 단지 하트처럼 간단한 것을 그렸을 뿐입니다. 글자를 적고 말풍선을 그리는 것만으로도 일러스트가 됩니다. 이런 시각적인 노트 작성 방식으로 독자의 주의를 끌 수 있습니다. 여러분의 경험도 보다 나은 것으로 만들고 집에 와서 공유하면서, “이번에 참여한 강연은 이런 모습이었어.”라고 얘기할 수 있겠죠.

많은 사람들이 실제로 이번 컨퍼런스(Droidcon Boston)에서 스케치노트를 공유하고 있습니다. 꼭 귀엽거나 멋질 필요는 없습니다. Mr. Jenkins가 보이는데, 이렇게 실제 그림을 보고 따라 그리는 것도 연습이 됩니다. 어쨌든 스케치노트의 핵심은 한 줄 한 줄 쓰는 대신 어떤 일이 있었는지 요약해서 자유롭게 종이에 옮기는 것입니다.

저는 스케치노트를 이 년 전부터 시작했고 이 작업이 정말 즐겁습니다. 이런 스케치노트로 블로그 포스팅을 풍성하게 할 수 있습니다. 참, 블로그의 내용은 마지막으로 작은 결론으로 마무리 지을 수 있겠죠. 멋진 행사였으니 내년에도 가겠다고 결론을 적을 수도 있겠죠. 이렇게 완성된 포스트를 팀이나 상사에게 공유하면서 컨퍼런스에 참석해서 많은 것을 배웠으니 다음번에도 참석할 수 있게 해달라고 요청할 수도 있습니다.

강연

블로그에 대해 말씀드렸으니 다음 단계인 강연으로 넘어가겠습니다. 강연은 상호작용이 있으므로 이런 단계를 한층 더 높여야 합니다.

블로그를 작성하는 경우 글을 쓰고 올리면 사람들이 볼 수도 있고 보지 않을 수도 있습니다. 하지만 앞에 서서 강연한다면 청중들이 여러분의 말을 듣게 되죠. 당신이 강연자일 때 좋은 점은 사람들이 복도에서 강연 후 당신을 찾아와 강연 내용에 대해 말하고 싶어 하기 때문에 행사에서 네트워킹하기가 훨씬 쉬워진다는 것입니다. 당신에 대해 간단하게 소개하고 여러 흥미로운 점을 말할 수 있고, 여러 사람이 능동적으로 찾아오므로 네트워킹의 부담이 훨씬 적습니다. 제 경우 강연을 시작하고부터 컨퍼런스나 밋업에 참석하는 것이 훨씬 만족스러워졌습니다.

이의 제기 #1: “전 말할만한 것이 없습니다.”

어떤 사람들은 “하지만 전 강연할만한 것이 없는걸요.”라고 말합니다. 그래서 그런 분들을 위해 “전 말할만한 것이 없습니다.” 라는 제목으로 강연한 적도 있습니다.

여러분이 강연할만한 무언가를 발견하는데 사용할 수 있는 트릭을 바로 보여드리겠습니다. 제가 코드를 작성할 때는 언제나 완벽하게 되지는 않습니다. 제가 예상했던 것보다 오래 걸리는 작업을 직면하면 저는 그것에 대해 써둡니다. 블로그 포스트를 작성하거나 강연의 주제로 삼죠. 제가 작성한 코드가 엉망이라 그럴 수도 있고, appcompat-v7:24.2.0 라이브러리를 사용하다가 25.2.0으로 살짝 업데이트했는데 제대로 동작하지 않을 수도 있습니다.

바로 그때가 잘못을 포착하고 공유할 시점입니다. 다른 사람을 위해서일 뿐만 아니라 여러분 자신에게도 도움이 되죠. 제가 반년 전에 해냈던 것이 기억나지 않아서 제 블로그 포스트를 살펴보는 일도 아주 많습니다. 미래의 자신을 위한 노트인 셈이죠. 아무도 제 블로그를 읽지 않더라도 저는 제 블로그를 읽습니다.

제 친구인 Ellen이 트윗한 “저는 이 함정에 제일 먼저 빠진 바보이고 어떤 길이 어디로 통하는지 말씀드리겠습니다.” 와 같은 강연 스타일도 좋습니다. 만약 여러분이 3시간 이상 어떤 문제로 고통받고 있다가 문제의 해결책을 하나 추가해서 해결했다면 그 경험을 공유하고 다른 사람들을 고통에서 구원해주세요.

불만을 적은 책

저는 불만을 적는 것에서부터 시작했습니다. 뭔가 잘 작동되지 않으면 이에 대해 적었습니다. 이를 다시 읽으면 패턴을 찾을 수 있을테고 이를 블로그에 포스팅하거나 강연에서 말합니다.

이를 시작하고 나서부터 따로 적지 않아도 제 머리가 사람들에게 공유할 만한 흥미로운 것을 찾아내기 시작했습니다. 어느 아침에는 샤워 중에 좋은 블로그 소재가 될만한 것이 떠오르기도 했습니다.

이의 제기 #2: “아무도 제 말을 듣고 싶어하지 않습니다.”

또한, 다음으로 사람들은 “제 말을 누가 듣고 싶어하겠어요. 하루종일 불만을 말할 수도 있겠지만 저라는 사람은 하찮은걸요.”라고 말합니다.

얼마나 많은 사람들이 밋업에 참가할까요? 꽤 많은 분들이 참가하겠죠. 밋업의 강연자들이 어디서 왔다고 생각하시나요? 바로 당신이 속한 커뮤니티입니다. 지역 커뮤니티는 매달 한 명씩의 강연자가 필요하죠. 어떤 비밀 엘리트 집단이 있어서 항상 강연을 하고 있는 것이 아닙니다. 밋업 주최자에게 가서 강연하고 싶다고 하면 아마 대부분 “다음 달 강연자가 없어서 고민이었는데 너무 감사해요!”라고 말할 겁니다. 커뮤니티에 사람이 걸음 하지 않는다면 이를 채울 방법이 없기 때문입니다. 그리고 그 커뮤니티가 바로 여러분과 같은 분들로 이뤄지는 것이죠.

밋업에서 강연하는 것에 좋은 점은 40분을 꽉 채울 필요가 없다는 점입니다. 간단하게 보여주기나 라이트닝 토크로 시작해서 점점 여러분의 방식으로 발전할 수 있습니다. 청중은 친절하며 대부분 무료 행사이므로 여러분에게 와서 “참가비를 냈는데 얻은 게 없으니 환급해줘요.”라고 말할 사람도 없습니다. 대부분 아는 사람일 가능성이 높은 친숙한 밋업에 참가해서 경험을 공유해 보세요. 여러분의 말을 듣고 싶어 하지 않는다고 생각하면 잘못 생각하는 겁니다. 여러분이 속한 밋업은 여러분의 이야기를 듣고 싶어 합니다. 이런 과정을 거치고 나면 다음에는 컨퍼런스에서 강연할 수 있죠.

강연자

밋업에서와 강연과 컨퍼런스의 강연을 구분하는 것은 바로 강연자입니다.

예를 들어 이번 컨퍼런스에는 많은 강연자가 있습니다. 강연자가 되면 다른 강연자와 시간을 보낼 수 있는 파티 등의 행사가 있으므로 다른 강연자와 인맥을 만들 수 있습니다.

이 그룹의 사람들은 앞에 나가서 내 지식을 공유하고 싶어하는 사람들입니다. 이런 강연자들을 만나서 인맥을 만들면 단지 해당 컨퍼런스가 끝나는 것으로 헤어지는 것이 아닙니다. 트위터 등에서 서로를 팔로우해서 정보나 지식을 교환할 수 있습니다. 이것이 강연의 가장 큰 장점입니다. 무대에 올라서 락스타가 되는 것이 아니라 청중들, 연사들, 즉 사람들과 연결되는 것이죠. 당신이 하는 일과 당신이 속한 거대한 커뮤니티를 이루는 사람들을 아는 것은 정말 멋진 일입니다.

발표자 모집 (Call for Proposals, CFP)

컨퍼런스에서 강연하고 싶다면 발표자 모집(CFP)에 제안서를 보내야 합니다. 왜 이 주제가 흥미롭고, 이에 대해 강연하고 싶은지 설명하는 세 문단 정도의 짧은 글입니다.

왜 이 주제인가?

예제를 통해 제안서를 분석하는 방법을 설명하겠습니다. 보통 제안서는 같은 텍스트 형식을 취하므로 컨퍼런스 웹사이트에서 확인해보고 제안서 작성을 연습해볼 수 있습니다. 이번에는 “우리가 잘 알지 못하고 있는 Kotlin” 라는 제안서를 한 번 살펴보겠습니다.

먼저 어떤 것을 강연할지에 대해 정의합니다. 여기서는 “Kotlin”입니다. 다음으로는 어떤 것을 다룰지에 대한 디테일을 살릴 예시, 즉 키워드를 살펴봅니다. 여기서는 “데이터 클래스, 람다, 델리게이트를 살펴보겠습니다.”라고 적혀 있습니다. 마지막으로 어떤 점을 얻을 수 있는지 강조합니다. 여기서는 “이번 강연에 온다면 Kotlin에 대한 이해를 높이고 추후로도 사용할 수 있는 도구에 대한 지식을 얻어갈 수 있습니다.”라고 적혀있습니다. 좋은 제안서를 이루는 세 단계 요건이 모두 갖춰져 있습니다.

좋은 제안서를 다른 트릭을 공유하자면 청중 에 집중하라는 겁니다. 아마 “저는 이것을 어떻게 하는지 알려드리겠습니다, 저는 이런 것을 보여드리겠습니다.”라고 자신을 주어로 쓰고 싶겠지만 이렇게 쓰면 안됩니다. 청중에게 강연하는 내용이므로 “(여러분은) 이런 것을 배울 겁니다, (여러분은) 이런 내용을 파악할 겁니다.”라고 청중을 주어로 써야 합니다. 이렇게 하면 전달할 내용이 훨씬 명확해집니다.

왜 당신인가?

이 시점에서는 아마 몇몇 블로그 포스트를 작성해서 여러분의 뭔가를 보는 관점과 이에 관해 설명을 할 수 있는 능력이 있는지 사람들이 파악할 수 있을 겁니다. 또한, 밋업에서의 강연도 몇 번 있겠죠. 보통 밋업은 컨퍼런스처럼 전문적인 비디오 촬영을 할 예산이 없는 경우가 많지만 QuickTime이나 오픈 브로드캐스터 소프트웨어(OBS) 등을 통해 화면을 보여줄 수 있습니다. 여러분이 강연하는 목소리와 슬라이드를 녹화해서 보여주는 것은 밋업에서의 강의가 어땠는지 보여주기 좋습니다.

컨퍼런스의 강연자로 신청하면 이런 자료를 보고 컨퍼런스 주최자가 여러분에 대해 알 수 있습니다. QuickTime 등으로 화면을 녹화하는 방식을 공유하는 블로그 포스트도 있습니다.

제안서를 작성하는 방법에 대한 제 강연도 있으니 참고해 보세요. 또한, 컨퍼런스에 채택된 훌륭한 제안서들을 찾아서 왜 그것이 흥미로운지 살펴보는 방법도 다룹니다. 관심이 있다면 이 강연도 살펴보세요.

강연자로 선정됐습니다, 이제 뭘 해야 하죠?

컨퍼런스 강연자로 선정됐습니다. 이제 아주 짧았던 제안서를 바탕으로 강연에 대해 준비해야 시작하겠죠. 좋은 프리젠테이션과 제안서 개선, 강연 방법 등의 팁을 매 주 공유하는 기술적인 강연에 대한 영문 뉴스레터가 있으니 참고하면 많은 도움이 될 겁니다.

이제까지 공유와 블로그, 강연의 좋은 점을 말씀드렸는데, 다른 점도 말씀드리겠습니다. 뭔가 공유하면 사람들이 저를 전문가라고 생각할 텐데, 만약 전문가라고 생각하지 않거나 제가 사기꾼이라고 생각하면 어떻게 할까요? 저는 전문가가 아니고 뭘 하고 있는지도 잘 모르는데 만약 블로그에 악플이 달리면 어떻게 할까요? 컨퍼런스에서 강연하고 있는데 사람들이 제 말이 틀렸다고, 당신이 뭔데 그런 소리를 하느냐고 소리치면 어쩌죠?

블로그에 관해서는 좋은 점과 나쁜 점이 있습니다. 나쁜 점은 인터넷상에 뭔가 공유했는데 아무도 읽지 않는 상황, 즉 독자가 없을 수도 있습니다. 좋은 점은 그런 경우 실험을 맘껏 해도 된다는 점이죠. 아무도 글은 별로이고 맘에 들지 않는다고 하지 않으니 마음껏 쓰고 싶은 대로 써도 됩니다. 만약 악플이 걱정이라면 댓글을 순화시키려고 쓰는 제 방법을 사용해보세요. 기본적으로 비판적인 사람들이 저를 흠집 내려 할 수 있다고 생각하기 때문에 사실 저는 아무나 제 블로그에 댓글을 달 수 있도록 하지 않습니다. 흠집이라기보다는 많은 사람들이 “이 포스트가 훌륭하지만 제가 쓰는 클래스와는 다른데, 이 방법으로 하는 방법을 알려줘요.” 정도의 댓글을 달았었죠. 그래서 저는 “하나를 알려줬는데 열 가지를 더 알려달라고요? 자기 일은 직접 하세요.” 라는 생각으로 댓글을 제한하게 됐습니다. 여러분의 블로그이니 여러분 생각대로 운영하시면 됩니다.

앞서 말한 것처럼 강연은 상호작용적이기 때문에 좀 더 까다롭습니다. 주로 벌어지곤 하는 일이라면 강연 중간에는 알아차리지 못하다가 질의응답 시간에 어떤 사람이 “질문 있는데, 아니 사실 질문은 아니고, 제가 더 훌륭하다고 생각하니까 발언하겠습니다.“라고 말하는 것이죠. 이런 사람이 있다면 당신이 틀렸다고 말하지 않으면서 공개 질의응답 형식을 악용하기 때문에 성가십니다. 사실 질문을 받지 않아도 됩니다. 강연자가 강연을 하고 꼭 질문을 받아야 한다고 강제하는 사람은 없습니다. 저는 주로 “강연에 와주셔서 감사합니다. 공개 질문은 받지 않겠지만 논의할 것이 있다면 끝나고 찾아와 주세요.”라고 합니다. 이런 형식으로 해도 괜찮습니다.

공개 질의응답 시간을 갖는 경우 솔직한 것이 가장 좋습니다. 누군가 질문을 했는데 모르는 경우 그렇게 말해도 됩니다. 연단에 있다고 해서 모든 지식을 다 아는 백과사전과 같이 청중의 질문을 받아야 할 필요는 없습니다. 여러분은 단지 공유하고 싶은 특별한 경험이 있어 공유했을 뿐이고 이로써 책임은 다 마친 겁니다. 누군가 모르는 질문을 한다면 솔직하게 “모르겠네요, 아직 그런 경험이 없습니다.”라고 답하세요. 혹은 “제게 트윗을 주시거나 강연 후에 오시면 끝나고 계속 논의해볼 수도 있겠어요.”라고 할 수도 있을 겁니다.

제안 거절

컨퍼런스에 강연 제안서를 넣었는데 거절을 당하는 것은 종종 일어나는 일이고 기분이 상할 수 있습니다. 하지만 이건 누구에게나 일어나는 일입니다. 경험 많은 강연자들이 멋진 강연을 하곤 하지만 자신이 경험한 거절 사례에 대해서는 별로 공유하지 않죠.

제 경우 이 강연(Droidcon Boston)의 키노트로 뽑혔다는 얘기를 듣고 기뻐서 환호했고, 트위터에도 연사로 뽑혀서 정말 기쁘다고 남겼습니다. 하지만 4월에 있었던 다른 안드로이드 컨퍼런스인 Chicago Roboto에서 거절당한 일은 남기지 않았죠. 테스트에 관한 제안서를 넣었지만 거절당했습니다. 이유는 알 수 없었습니다. 또한, 거절 이유를 주최 측에서도 알 수 없는 경우도 많습니다. 제가 주최자로 있는 360 AnDev에서도 제안서에서 강연자의 정보를 가려서 제안서의 내용에만 집중할 수 있도록 하는 상태로 커뮤니티의 투표를 받은 다음 통과한 제안서를 다시 주최 측에서 보고 있습니다.

제안이 통과되지 않는 이유는 여러 가지가 있겠지만, 누구도 명확히 말해줄 수 없을 수 있습니다. 누구에게나 생길 수 있는 일입니다. 작년에 저는 지역 유명 인사의 제안서를 거절한 적도 있습니다. 하지만 거절이 두려워 제안을 그만두지는 마세요. 몇 번 계속 제안서를 넣다 보면 통과될 수 있을 것이고, 여러 군데의 컨퍼런스에서 같은 강연을 계속하게 될 수도 있습니다. 시작 지점에 설 때까지 계속 노력하다 보면 연단에서 자신의 경험을 나누는 자신을 발견할 수 있을 겁니다. 꾸준히 한다는 것은 어렵지만, 포기하지 마세요. 사람들은 여러분의 이야기를 듣기를 바랍니다.

여러분의 전문성을 공유하세요!

여기까지 보신 여러분이 블로그와 강연에 대해 흥미를 느끼게 되셨으면 좋겠습니다. 지식을 공유하고 전문성을 높이며 보다 큰 커뮤니티의 일원으로 서로에게서 배울 수 있게 되기를 바랍니다!

참고 자료

강연 슬라이드는 여기서 볼 수 있습니다.

블로그 작성 공식

블로그 & 강연

뉴스레터

Technically Speaking

다음: Realm Java의 새로운 기능을 만나 보세요!

General link arrow white

컨텐츠에 대하여

2017년 4월에 진행한 Droidcon Boston 행사의 강연입니다. 영상 녹화와 제작, 정리 글은 Realm에서 제공하며, 주최 측의 허가 하에 이곳에서 공유합니다.

Chiu-Ki Chan

Chiu-Ki는 강연과 교육에 열정적인 안드로이드 개발자입니다. 전세계 수많은 컨퍼런스에서 강연해 왔으며 안드로이드에 대한 광범한 지식으로 Google Developer Expert로 인정받았습니다. 그녀는 모바일 개발 회사를 운영하며 중국어를 학습할 수 있는 Monkey Write, 사진을 하트 모양으로 만들어주는 Heart Collage, 걸을 수록 활동적이 되는 Fit Cat 등의 앱을 제작했습니다.

4 design patterns for a RESTless mobile integration »

close