전부 이해하지 않아도, 역할은 분명해야 했다
어느 순간부터였다.
회의에서 질문을 던지는 게 예전만큼 부담스럽지 않게 느껴졌다. 처음에는 질문 하나를 던지기까지 머릿속에서 수십 번을 돌려봤다면, 이제는 그 정도는 아니었다. 그렇다고 질문이 쉬워진 건 아니었다. 오히려 질문의 무게가 다르게 느껴지기 시작했다.
질문을 많이 던진다고 해서 회의가 좋아지는 건 아니었다. 어떤 질문은 회의를 앞으로 나아가게 했고, 어떤 질문은 흐름만 잠깐 끊어놓고 끝났다. 그 차이를 몇 번 겪고 나니, 나도 모르게 질문을 고르게 되었다.
처음에는 정말 아무 생각 없이 물었다.
“이게 뭐예요?”
“왜 이렇게 해요?”
그 시기에는 그 질문들만으로도 충분했다. 내가 이해하지 못하고 있다는 사실을 드러내는 것 자체가 중요했기 때문이다. 하지만 시간이 지나자 한계를 느꼈다. 같은 질문을 반복하면 설명은 들을 수 있었지만, 회의는 깊어지지 않았다. 나 역시 계속 ‘기초적인 질문만 하는 사람’ 자리에 머무르는 느낌이었다.
그 무렵, 하나의 생각이 들었다.
모든 기술을 다 이해하면 좋겠지만, 내 역할은 개발자가 아니라는 사실이었다.
내가 이 회의에 앉아 있는 이유는 알고리즘을 설계하기 위해서도, 코드를 짜기 위해서도 아니었다. 사업의 방향성을 검토하고, 기술적으로 어떤 이슈가 있는지를 확인하고, 이 기술이 새로운 아이템으로 확장될 수 있는지를 보는 역할이었다. 그렇게 생각하니, 질문의 기준이 조금 달라졌다.
기술 그 자체를 묻기보다는,
그 기술이 어디에 쓰이는지,
그리고 무엇을 바꾸는지를 묻기 시작했다.
“이 처리 과정이 빠지면, 최종 산출물에는 어떤 영향이 있나요?”
“이 선택이 나중에 다시 바꾸기 어려운 지점은 어디인가요?”
“지금은 이 방식이 최선인데, 조건이 바뀌면 다른 선택지도 가능한가요?”
이 질문들은 정답을 요구하지 않았다. 대신 엔지니어들이 이미 알고 있지만, 굳이 말하지 않았던 전제들을 꺼내게 만들었다. 회의는 조금 느려졌지만, 대신 방향은 분명해졌다.
그제야 알게 됐다.
질문은 ‘얼마나 많이 하느냐’보다, 어디를 건드리느냐가 중요하다는 걸.
문과생인 나에게 기술적인 질문의 깊이에는 분명 한계가 있었다. 하지만 그 대신 내가 서 있을 수 있는 위치는 분명했다. 기술의 내부를 파고드는 사람이 아니라, 기술이 사업과 연결되는 지점을 확인하는 사람. 이 기술이 어떤 문제를 해결하는지, 어떤 선택을 전제로 하고 있는지, 그리고 이 선택이 향후 사업 확장에 어떤 영향을 주는지를 묻는 사람이었다.
질문에도 단계가 있다는 걸 그때 처음 체감했다.
처음에는 용어를 묻는 질문이었다.
그다음에는 맥락을 묻는 질문이 되었고,
조금 지나서는 영향과 선택을 묻는 질문으로 바뀌었다.
모든 질문이 다 필요한 건 아니었다. 오히려 질문을 덜 하게 되었다. 대신 한 번 질문할 때, 이 질문이 사업의 방향을 확인하는 데 필요한지, 아니면 단순한 호기심인지 스스로에게 먼저 물었다. 그 판단을 하기 시작하면서 질문의 타이밍도 중요해졌다.
질문을 참는 것도 전략이라는 걸 알게 된 건, 꽤 시간이 지난 뒤였다.
지금도 여전히 모르는 기술은 많다.
하지만 예전처럼 모든 걸 이해하려 애쓰지는 않는다. 대신, 이 기술이 현재 사업에 어떤 의미를 가지는지, 새로운 아이템으로 확장될 여지가 있는지, 지금 이 시점에서 짚고 넘어가야 할 리스크는 무엇인지에 집중한다.
문과생에게 질문은 단순한 궁금증이 아니다.
회의에 참여하는 방식이고, 역할을 분명히 하는 방법이다. 개발을 대신할 수는 없지만, 기술이 어디로 쓰일지를 묻는 역할은 할 수 있다. 그 질문들이 쌓이면서, 나도 모르게 회의 속에서 맡게 되는 자리가 생겼다.
지금도 나는 여전히 모르는 게 많다.
하지만 이제는 안다. 전부 이해하지 않아도 괜찮다는 걸. 중요한 건, 내가 이 회의에서 무엇을 확인해야 하는 사람인지 스스로 알고 있는 것이다.