MoscowJS 66에서 저는 10개가 넘는 질문을 했습니다. 그중 두 개가 “최고의 질문”으로 선정됐고, 결과적으로 상 두 개를 받았습니다.
가장 기억하기 쉬운 부분은 이 결과입니다. 하지만 제게 더 유용했던 건 Q&A를 “진짜” 발표가 끝난 뒤의 부가 시간으로 보지 않았다는 점이었습니다. 발표를 적극적으로 따라가면서 흥미롭거나 아직 불확실한 부분을 질문으로 구체화하려고 했습니다.
MoscowJS 66에서 실제로 다룬 내용
이 meetup은 2025년 7월 3일 모스크바의 School 21에서 열렸습니다. MoscowJS 66 공식 프로그램에는 Telegram 봇과 Web App, LangChain.js와 developer experience, 사이트 빌더 아키텍처, TypeScript 타입 테스트에 관한 네 개의 발표가 올라와 있습니다.
이렇게 설명하는 편이 단순히 “AI”나 “프런트엔드 아키텍처”라고 묶는 것보다 정확합니다. AI 관련 발표는 구체적으로 LangChain.js에 관한 것이었고, 아키텍처 발표는 사이트 빌더를 만드는 과정의 설계 결정과 유연성·단순성 사이의 trade-off에 초점을 맞췄습니다.
Q&A를 기술 콘텐츠의 일부로 들었습니다
행사 전체에서 저는 10개가 넘는 질문을 했습니다. 그러다 보니 발표를 듣는 방식도 달라졌습니다. 핵심 아이디어만 이해하는 것으로는 부족했고, 전제 조건, 경계 사례, 더 구체적인 설명이 필요한 부분까지 눈에 들어왔습니다.
결국 제 질문 두 개가 최고의 질문으로 선정되어 상 두 개를 받았습니다. 이 결과는 제 경험으로 확인할 수 있지만, “질문을 많이 하면 상을 받는다”는 일반 법칙으로 만들 생각은 없습니다.
제가 가져온 실용적인 교훈
제게 남은 결론은 더 단순합니다. 기술 meetup은 콘텐츠를 수동적으로 소비할 때보다 직접 참여할 때 더 유용해질 수 있습니다. 좋은 질문은 어떤 접근법의 한계를 드러내고, 발표에서 충분히 다루지 못한 trade-off를 끌어내며, 추상적인 아이디어를 구체적으로 만들 수 있습니다.
비슷하게 참여해 보고 싶다면 각 발표에서 아직 해결되지 않은 한 가지를 적어 두고, 답변할 수 있을 만큼의 맥락을 붙여 짧은 질문으로 바꾸는 방법이 실용적입니다. 목표는 질문 수를 늘리는 것이 아닙니다. 시작할 때보다 검증되지 않은 가정을 줄여서 돌아가는 것입니다.
MoscowJS 66의 발표자와 운영진께 감사드립니다. 발표를 들으러 갔고 Q&A에도 적극적으로 참여했으며, 결국 상 두 개와 함께 기술 발표를 더 능동적으로 듣는 방식까지 얻었습니다.