[Bridge 01] 나의 첫번째 브릿지를 기록하며,

앞선 프로젝트를 끝내고 첫번째 브릿지 기간을 가지게 되었다.

브릿지에 앞서서 프로젝트 팀원들과 회고를 나누는 시간을 가졌고, 배움에 대하여 돌아보는 시간을 가졌다.

 

앞선 회고에서 내가 답을 찾고싶은 문제 중에 '배우고 익히지 말고 익히면서 배워요'라는 문장이 있다고 이야기 했었다. 여기에 의문을 가졌던 이유는 나의 과거 경험에서 익히면서 배우는 것에 궁극적으로 두려움을 느꼈기 때문이라고 이야기 했었다. 오늘도 멘토가 해당 문장과 발생할 수 있는 문제점(?)인 두려움에 대한 키워드를 이야기 했고,  내가 지금까지 가져왔던 고민에 대한 답을 찾을 수 있을 것 같은 느낌에 속전속결로 30분 뒤에 커피챗을 요청했다. 우리의 대화 내용을 정리해보면 다음과 같다.

 

[나의 문제정의]

'배우고 익히지 말고 익히면서 배워요'를 경험하면서 나는 궁극적으로 두려움에 도달하게 되었고, 그 두려움은 2개로 나눠진다.

 

첫째, 프로젝트와 공부를 하면서

배우고 -> 익히고 -> 다음 기술을 공부하면 또 까먹고, 모든 것들을 완벽하게 기억하지 못하는 것이 인간이라면 거스를 수 없는 것일까?

비동기를 하기 위해서 dispatchQueue로 시작해서 async/await까지 왔는데, 나에게는 Rxswift, Combine + α가 생기는 것처럼 새로운 것들이 계속 생겨나는 무한의 굴레에서 벗어나는 때는 오기는 하는 것인가?

나는 이 굴레에서 고립되는 것이 아닐까? 라는 생각이 두려웠던 것 같다.

 

(멘토) 배우고 익히는 것과, 익히면서 배우는 것의 차이는 그 범위를 어디로 두느냐에 따라 다른 것 같다. 익히면서 배운다고 하더라도 내가 지금 익혀야하는 그 기술 하나를 익히는데 집중해보면, 기술에 대한 문서를 읽어보고 -> 코드에 적용해보고 하는 과정안에 또 배우는 것이 들어간다.

IT분야는 새로운 기술이 매년, 매달, 매일 나온다. WWDC의 경우에도 1년에 약 270개의 신기술이 출시되는데 하루에 1개씩 적용하고 배워도 끝이 없는 상황에서 모든 기술을 익히고 개발을 할 수는 없다. 따라서 처음 문장의 의미는 내가 사용해야하는 기술에 집중을 해서 배우는 것을 의미하는 '(내가 지금 필요한 기술을)익히면서 배우는 것'이다.

 

둘째, 회사에서 업무를 하면서

기업에서 개발 업무를 수행하면서 한번도 듣지도 못해본 기술들을 사용해야 하는 경우가 생겼을 때가 있었다. 이런 상황에서 "언제 마감가능한가요? 어떻게 구현하실건가요? 구현 할 수 있을까요?"라는 대답에 대해서 대답을 하기 어려웠고, 힘들었고, 곤란했던 적은 평생에 처음이였다. 나는 나의 말과 행동에는 책임을 져야 한다고 생각했고, 가능한 말과 행동만 하는 사람이고 싶었다. 앞으로도 이런 상황이 발생한다면 책임을 질 수 없는데 무조건 답을 해야하는 물음이 두려움 그 자체였던 것 같다.

 

(멘토) 기업에서 같은 분야에서 년차가 어느정도 쌓이면 새로움이라는 느낌이 거의 사라질까?

(나) 3년?

(멘토) 정답. 3년차와 10년차 특히 IT분야의 경우 항상 새로운 것들을 배워야 하지만 3년차 이상이 되면 더 이상 엄청나게 새로움을 배우는 느낌을 얻지 못한다. 그 이후에는 기존 기술에서 약간 변화가 있다 정도로 느끼게 될 것이다. (본인 및 주변의 경험 기반으로) 따라서 3년은 해봐야 두려움이 사라진다. 그 전까지는 모든 것들이 새롭기 때문에 모두 같은 마음이다.

 

나는 이 이야기를 나누고 지금까지 가지고 있었던 두려움에 대한 고민의 대부분이 해소되었다. 내가 배움에 있어서 끝이 오지 않을 것 같은 두려움을 느꼈다면 그것은 내가 성장의 마지막을 확인하지 못한 것이 맞는 것 같다. 개발을 해봤다고 해봤자 졸업프로젝트와 회사에서 인턴으로 몇 개월, 그리고 대외활동 6개월이 전부인데 이것도 몰입했다고 할 수 없기에 나는 경험이 전혀 없다고 생각하고 지금부터 3년간은 새로운 것들을 받아들이고 몰입해보기로 마음을 다잡게 되었다. 3년 뒤에 이와 연결된 또 다른 고민과 숙제가 생기게 될 수도 있지만 현재의 상황에서 가장 현실적인 답변이라고 생각하기에 이제는 고민을 잠시 내려두고 나아가보자.

---

이번 브릿지 기간 중 회고와 기록에 대해 관심이 많은 러너들과 함께 이야기를 나눌 수 있는 시간이 있었다. 나는 러너들에게 본인이 시도해보니 의미있거나 좋았던 회고 내용이 무엇인지 물어봤고, 답변받은 내용들을 회고에 반영하면 좋을 것 같다고 생각했다.

•  돌이켜보니 내 생각을 적은 부분이 가장 중요한 것 같다. 개발은 깃허브에 있으니까 나의 생각에 대해 적는게 중요하다고 생각함
• 문제가 무엇인지? 어떤 방식을 찾았는지? 어떻게 해결했는지?
• TIL보다는 어떤걸 느꼈고, 어떻게 헤쳐나갔고, 나만의 서사가중요하다.
• 본인의 의사결정 과정을 기록으로 남기는게 중요하다.
• KPT(Keep, Problem, Try) 방식을 사용해보기

프로젝트와 협업을 진행하면서 협업을 하는 방식에 대한 이야기를 나누었다. 정리는 필요한데 서기를 만들기에는 서기가 본인의 생각을 발언할 기회가 적어지고 원하지 않을 수도 있다는 문제점들에 대다수 공감을 하고 있는 것 같았다. 다른 팀에서 좋은 의견들이 나와서 다음 프로젝트부터는 나도 사용을 해보고싶다고 생각한 내용들을 정리한다.

• 서기를 정하더라도 프로젝트 회의(세션시간)가 마무리된 뒤에 돌아가면서 정리하기
• 회의 중에 작성이 필요하다면 서기가 작성하는 시간동안 기다려 주기
• 프로젝트 회의나 단체 논의가 끝나고 당일 한 일을 일일 회고하기 -> KPT를 통해서 빠르고 짧게 논의하고 개선하는 방법도 괜찮을 것 같다는 생각이 들었다.