cleanUrl: /opinion/participate-wwdc-lab

WWDC에 참석한 분들 중 의외로 랩에 참여하신 분들이 적더라고요. 이유는 알 수 있을 것 같습니다. 사실 저도 “뭘 물어봐야하지?” 라는 문제에 꽤 오래 부딪혔었거든요. 지금 당장 겪고 있는 심각한 문제가 있다면야 얘기가 쉬워지지만, 그렇지 않다면 “굳이 랩 까지 가서 물어 볼 필요가 있을까? 나 혼자서도 잘 해결 할 수 있는데” 라는 생각을 할 수도 있을 것 같습니다.

하지만 저는 다음 여러 이유 때문에, 랩에 참석하는게 생각보다 훨씬 뜻깊을 수 있다고 생각합니다.

1. 물어볼 것을 억지로 끌어내는 과정은, 소프트웨어 품질에 대해 더 깊게 고민을 하게 되는 계기가 됩니다.

“뭘 물어보지?” 라는 마음가짐으로 우리 앱을 들여다보면, 그 전에 보이지 않았던 문제들이 드러납니다. 예를 들어서, 플리토에서는 릴리즈 단위로 앱 런칭시간을 기록하고 있습니다. 하지만 앱 런칭시간을 기록하는 것은 생각보다 어려운 일입니다. 일단 릴리즈 빌드로 빌드해야 하고, (그러니 오래 걸리고), 앱을 완전히 지웠던 상태에서 기록해야 하며, 여러 플래그도 기본값으로 설정해야 하고 등등…

그래서 그 전에는 그냥 “런칭시간 기록은 어려운 일이구나”정도로 생각했는데, “뭘 물어보지?” 모드로 개발을 하다보니“생각해보니까 이건 좀 자동화 할 수 있어야 하는 부분이 아닌가?” 라는 생각이 들었습니다. 그래서 여러 랩에서 관련 질문을 했고, 몇 가지 답변을 얻을 수 있었습니다.

예를 들어, Xcode OpenHour에서 “이걸 자동화 하는 방법이 Xcode에 혹시 있을까요?”라고 물어봤을 때는, 그 부분은 본인들도 생각해보지 못했던 부분이지만, 새로 나온 Performance관련 API들이 도움이 될지도 모르겠다는 피드백을 들었습니다. 나아가 이는 분명히 Xcode에서 지원이 되어야 하는 부분이라고 공감 해주며, 팀 전체에 제 의견을 전달하겠다는 피드백도 들었습니다.

Performance 랩에서는, “혹시 애플에서는 이런 작업을 어떻게 하고 있나요?”라고 물어봤고, “애플 내부의 작업과정을 상세히 알려줄 수는 없다. 다만, 간단히 조언 해줄 수 있는 것은, 런칭시간을 잴 때는, ‘***앱을 끄고 최소 30초 이상 있었다가 실행해야 한다’*는 점이다. 방금 전까지 많은 작업을 하던 상태의 핸드폰은 온도가 올라가 있는 상태기이고, 그 상태의 핸드폰은 전반적인 동작이 느려지기 때문에 앱 실행시간이 느려질 수 있다. 따라서 정확한 데이터를 얻기 위해서는 최소 30초 정도는 핸드폰이 Cool Down 되도록 한 다음에 측정해야 한다”는 피드백을 얻었습니다.

2. 줄을 서면서, 같이 줄서는 사람들이 어떤 질문을 들고 왔는지 물어보는 것도 도움이 됩니다.

랩에 있다 보면 줄 설 일이 생기고, 꽤 오래 기다려야 하는 경우도 생깁니다. 그 때 그냥 기다리거나 핸드폰을 보지 말고, 앞 사람이나 뒷 사람에게 인사하고, “May I ask you what kind of question did you bring here?”라고 물어보세요. 아마 대부분 흔쾌히 그 분들의 질문에 대해 얘기해 줄 겁니다. 당연히 이 과정에서 제가 생각 해 보지도 못했던 많은 Edge케이스에 대해서 들어볼 수 있었고, 또한 자연스레 저의 질문에 대해 상대방에게 얘기 해주는 과정에서 저의 질문을 더 elaborate할 수 있게 되기도 했습니다. 이를테면 애플 엔지니어에게 물어보기 전에 약간의 예행연습으로 생각 할 수도 있겠습니다.

또 당연히 그 과정에서 운이 좋으면 같이 줄을 섰던 분들과 친해질 수도 있고, 연락처를 교환할 수도 있습니다.

3. Lab의 엔지니어들은 정말 성심성의껏 대답 해줍니다.

저는 랩에서 질문을 해 봤자, 10분 쯤지나면, “10분이 지났다. 이제 다음 사람 차례다. 더 이상 도와줄 수 없어서 미안하다. 잘 가라” 같은 상황을 만날 꺼라 생각했습니다. 하지만 많은 경우, 애플 엔지니어들은 한 사람 한 사람의 문제를 정말 깊게 고민해 주었습니다. 그 문제가 정말로 해결되거나, 혹은 해결 할 수 있는 실마리가 보일 때 까지, 그들은 대화를 끝내지 않았습니다. 혹시나 “랩에서 얼마나 성의 있는 피드백을 들을 수 있겠어?” 라는 의심을 가지고 있었다면, 그런 의심을 거두시기 바랍니다.

물론 경우에 따라 “미안, 이건 나도 잘 몰라” 같은 답변을 듣게 될 때도 있습니다. 하지만 그럴 때 거기에서 끝내지 마세요. 다른 랩에서 같은 질문을 다시 하면 훨씬 더 좋은 답변을 얻을 수도 있습니다.

예컨대, 위에서 언급한 App LauchTime Measuring에 관련해서, 저는 Xcod Open Hour에서도 질문하고, Testing관련 랩에서도 질문하고, Performance관련 랩에서도 질문했습니다. 결과로 얻은 피드백은 각 랩마다 모두 달랐습니다. 각 랩에 있는 사람들의 백그라운드에 따라 더 다양한 내용을 알려 주기도 했고, 또는 다른 랩의 엔지니어를 연결시켜 주기도 했습니다.

예컨대, UIKit랩에 딱 맞는 질문은 많지 않을겁니다. 그 질문의 핵심이 UIKit과 관련 된 것일 수도 있지만, Swift언어와 관련된 것일 수도 있고, 혹은 경우에 따라 AuthentificationService같은 프레임워크와 연결된 문제일 수도 있습니다. 한 랩에서 시원찮은 답변을 얻었다고 포기하지 마시고, 다양한 랩에서 그 질문을 던져 보세요. 기대한 것 보다 훨씬 많은 소득을 얻을 수 있을 겁니다.

4. AppStore Lab은 질문을 들고 갈 필요도 없습니다.

Lab에는 여러 종류가 있습니다. TechLab도 있지만, Design Lab도 있고, AppStore랩도 있지요. 특히 AppStoreLab에서는 “Expanding to China”, “Expanding to Middle East”같은 랩이 진행되는데, 여기서는 한 명의 담당자와 1:1로 얘기하는 것이 아니라, 관련된 주제로 한 테이블에 사람들이 둘러 앉아, 애플 직원을 중심으로 이야기가 진행되는 형태입니다. 안내를 받을 때도, “Ask that Person”이라고 하지 않고, “Join the Conversation with those People”이라고 안내를 받았습니다.

이런 곳에 가서, 다른 사람들이 어떤 질문을 던지는지 가만히 듣고 있는 것도 많은 도움이 됩니다. 특히 영어가 부족해서 직접 외국인과의 대화가 꺼려지는 분 들이라면, 이런 세션에 참여하셔서 귀를 기울인다면, “사람들이 뭔가를 질문 할 때 많이 쓰이는 표현이나 단어” 같은 것을 캐치 할 수도 있을 겁니다.

마치며