전부 알지 못해도, 일은 굴러간다
회사에 들어온 지 시간이 꽤 흘렀을 때였다.
회의에서 나오는 말들이 어느 정도 이해가 되었고, 질문도 어느 정도는 정리해서 할 수 있게 됐다. 그런데도 마음 한편은 계속 불편했다. 아직도 잘 모르겠다는 느낌이 계속 남아 있었기 때문이다.
그래서 더 공부하려고 했다.
회의에서 나온 기술을 찾아보고, 관련 논문도 읽어봤다. 그런데 논문을 펼치면 가장 먼저 눈에 들어오는 건 수식이었다. 미분 기호 같은 것들이 줄줄이 나오는데, 이걸 어디서부터 어떻게 봐야 하는지 알 수가 없었다. 수식이 무슨 뜻인지는커녕, 왜 이 수식이 여기 있는지도 잘 모르겠다는 생각이 들었다.
몇 장을 넘기다 보면 이런 기분이 들었다.
읽고 있기는 한데, 머릿속에 남는 게 없다는 느낌. 이게 어떤 구조인지, 실제로 어떻게 쓰이는 건지 감이 오지 않았다. 오히려 답답해지고, 이해를 못 하는 나 자신에게 화가 나기 시작했다.
그때, 이걸 정말 다 이해해야만 일을 할 수 있는 걸까?라는 생각을 하게 되었다.
처음에는 그렇다고 생각했다.
기술을 제대로 이해하지 못하면 회의에 제대로 참여할 수 없고, 판단도 할 수 없다고 믿었다. 그래서 이해가 안 되면 불안했고, 그 불안을 공부로 메우려고 했다. 하지만 시간이 지날수록 한계가 느껴졌다. 기술은 너무 깊고, 내가 따라갈 수 있는 속도에는 분명한 한계가 있었다.
그러다 생각이 조금 바뀌었다.
모든 기술을 전부 이해하지 못해도 회의는 계속 진행되고 있었고, 프로젝트도 멈추지 않고 돌아가고 있었다. 중요한 건 누가 모든 걸 다 아느냐가 아니라, 각자 맡은 역할을 하고 있느냐라는 생각이 들었다.
그때부터 내 역할을 다시 생각하게 됐다.
나는 개발자가 아니었다. 코드를 이해하려 애썼지만, 직접 만들 사람은 아니었다. 대신 사업을 관리하는 입장에서 이 기술 개발이 일정 안에 가능한지, 지금 선택이 나중에 리스크로 돌아오지는 않는지, 사업 전체 흐름에서 감당할 수 있는 결정인지를 확인하는 사람이었다.
그렇게 생각하니, 내가 이해해야 할 기준도 달라졌다.
수식을 하나하나 이해하는 것보다, 이 기술이 어디에 쓰이는지, 어떤 상황에서 문제가 생길 수 있는지, 그리고 이 선택이 사업적으로 어떤 의미를 가지는지를 아는 게 더 중요해졌다.
회의를 바라보는 시선도 달라졌다.
기술 설명이 길어질수록 이런 생각들이 먼저 떠올랐다.
이 기술을 지금과는 다른 방식으로 활용할 수 있는 산업은 어디까지일까.
다른 방법으로 바꾼다면, 추가로 감당해야 할 비용과 시간은 어느 정도일까.
프로젝트 일정 안에서 가능한 선택인지, 혹시 놓치고 있는 리스크는 없는지도 함께 봐야 했다.
이 질문들은 기술을 대신하지는 않는다.
하지만 기술이 어디까지 확장될 수 있는지, 또 어디서 한계가 생길지를 생각하는 데는 충분했다. 그 역할은 모든 걸 다 아는 사람이 아니라, 기술과 일 사이에 서 있는 사람이 할 수 있는 일이었다.
물론 그렇다고 공부를 아예 안 하는 건 아니다.
여전히 논문도 보고, 모르는 개념은 찾아본다. 다만 예전처럼 전부 이해하려고 애쓰지는 않는다. 수식에 매달리기보다는, 이 기술이 어떤 방식으로 문제를 해결하려는 건지 큰 그림을 보려고 한다.
나에게 ‘이해했다’는 말은,
이 기술이 왜 선택됐는지 설명할 수 있고,
어디에서 문제가 생길 수 있는지 짐작할 수 있으며,
다음 단계에서 어떤 판단이 필요할지 생각해 볼 수 있는 상태를 뜻한다.
그 정도면, 일은 굴러간다.
그리고 대부분의 조직에서는, 그 정도의 이해를 가진 사람이 꼭 필요하다.