결정은 유예했어도 자아는 확실하게 갈아끼워야 하니까 !
스타트업에서 내가 가진 지위명은 '(협력)연구원'이다. 동시에, '매뉴얼을 만들어내는' 일도 하고 있다. 둘이 별개도 아닌 것이..스타트업이고, 서비스를 론칭하는 거니까. 다시 말해 세상에 유사한 건 많아도 내가 가진 것과 동일한 서비스는 없다는 거고 나는 그걸 세상에 내놓는 거니까.
그 기나긴 여정에서, 나름대로 대표님이 주셨던 조언들, 내가 일하면서 생각했던 것들을 하나씩 기록해본다. 어떤 결정을 하더라도 더 잘할 수 있어야 하니까.
1. task별로, 지침과 방침을 명확히 할 것.
대표님이 주신 조언이다. 내가 처음에 멘토링 과정의 멘티로서 이 회사의 기술을 처음 이해하기 시작했을 때 멘토님(=대표님)께서 반복적으로 설명해주셨고 , 본격적으로 V&V 등의 task를 맡기 시작한 이후로는 뭔가 기술보고서가 되었든, 절차서가 되었든 그 결과물을 만들 때 지침과 방침을 기준으로 전개하라 하셨다.
그렇다면 지침은 뭐고 방침은 뭘까. 지침은 쉽게 말해, task에 대한 정의(그 task가 뭐고, 왜 해야 하는지)다. 방침은 이렇게 이해된 task에 대해, 어떻게 수행할 것인지(how & process)와 그래서 그 결과물(산출물, what)이 무엇인지, 지침과 부합하는지, 를 통칭한다.
처음엔 정말 적응이 안 됐다. 나는 두괄식으로 전개하는 것까지는 꽤나 경험이 많았던 데 비해 절차서, 결과보고서, 매뉴얼, guideline 등의 산출물 구분도, 또 지/방침 기반 전개도 해본 적이 아예 없었기 때문이다. 여담이지만 학교 수업에서도 배운 적이 없었다.
그러나 LLM에게 task를 부탁하더라도 이를 기반으로 전개하라고 하면 훨씬 효율적으로 일이 진행되는 것을 확인할 수 있었다. Gemini든 Claude든 GPT든, 구체적으로 지침을 적어줄수록 일을 잘 도와줬다 ! 여전히 이런 전개 방식이 익숙하진 않지만, 경험을 쌓아가고 있다.
2. 자신의 의견은 명확하게 할 것
뒷북을 치지 말라는 거다. 내가 의도한 게 아니더라도, 잘못 이해한 상태에서, 지침을 심지어 잘 이해했는데 방침 전개 시 매우 괴랄하게 전개할 수도 있다. 대표님 피셜 '삽질'.
하지만 회사라는 영리 집단 특성상 그 삽질을 받아줄 수 있는 건 한계가 있다. 때문에 이해가 안 될 경우 차라리 카톡이든, 출근해서든 직접 빠르게 여쭤보는 게 맞다. 내가 어떤 맥락에서 이렇게 이해를 했고 그래서 어떤 식으로 코드를 짜서 어떤 식으로 validation을 해둔 상태다, 라고. 그러면 맥락이 수정되든 task가 수정되든 놓친 지침을 알게 되든 하겠지.
만약 그렇게 수정된 피드백이 생긴다면 방침도 재전개해야 할 것이다. 그렇다면 그 방침이 맞는지에 대해서는 방침을 결정하는 대로 컨펌 요청 넘겨야 한다 .그래야 수행 마일스톤이 잡힌다.
3. Ownership과 마일스톤
2024 멘토링 과정의 멘티들 중 현재도 이 회사와 연을 맺는 건 나 하나다. 뭐, 팀플이라는 게 항상 그렇듯 잘 되는 팀플이 거의 없다^_^..그런데 의무도 아니라면 당연히... 그렇겠지. 다만, 나는 이 회사의 기술에서 가능성을 봐서 대표님의 협업연구제안을 받아들였고, 그래서 대학원 진학하면서 '그만둔다'가 아니라 교수님께 이러한 포인트에서 협력이 가능해 보이는데 어떻게 생각하시는지를 여쭤보았다.
내가 내 무덤 팠다는 사람도 많았다. 하지만 내 생각은, '즐기면서' 해야 한다는 거다. 그래서 나름대로의 비전을 그려나가며, 어떤 식으로 내 전공을 회사 일과 접목할지, 거꾸로 회사 기술이 서비스/제품 형태로 론칭되었을 때 내 연구분야와는 어떻게 접목할 수 있을지를 계속하여 그렸다. 막 엄청난 건 아니더라도 그 스케치를 그리는 과정이, 조금은 버거워도 일이 스트레스가 되지는 않는다. 아침 출근길이 피곤해도, 막상 얘기하다 보면 시간은 금방 흘러갈 만큼.
그리고 이 Ownership을 만드는 데는 학원일이 참 큰 기여를 했다고 생각한다. 내가 막 엄청난 1타강사인 건 아니지만 일할 때 애들한테 이거 이렇게 설명하면 좀 더 이해가 잘 되지 않을까, 하고 몇 십번씩 설명 시뮬레이션을 돌려보던 경험은 나만의 '가르치는 자아'를 발전시키는 데 큰 공을 세웠지 않나 싶다. 주1회 클리닉 알바만 할 때도 이랬고, 지금도 그렇다. 어떤 형태로든 도움을 줘야 한다,는 생각 속에 있다 보니 다른 일을 할 때도 '즐기면서' 대신 '너의 일처럼' , 그러니까 회사 일이 아니라 '나의 일처럼' 생각할 필요는 있다는 걸 습관화했던 것 같다.
* 그렇다고 회사랑 본인을 동일시하란 건 아니다. 이건 내 경험 기반으로 어떻게 일할지에 대한 기록일 뿐이다.
4. 정답은 없다.
그래서 기대감을 더 심어서는 안 되고 더 꼼꼼해야 한다. 특히 이건 researcher 입장에선 더 중요한 것이, 새로운 것을 만들던 조사하던 구현하던 간에, 정답이라고 할 것이 없다.
내가 가는 길이 정답인 대신, 조건이 붙는다. 그 길이 낭떠러지인지 잘못된 길인지도 알 수 없어서, 한 걸음 내딛을 때 단단한 지반 위의 지역이 확실한지 보아야 한다는 조건. 그래서 한 줄 한 줄 시각화하고 EDA를 하고 V&V가 시작되면 같은 실험을 몇 십번도 하는 것 같다. 대표님 피셜 이 정도면, 양반이라고 하셨다 그리고, 그렇게 확실하게 해야 하기에 한 번의 결과가 좋다고 떠벌려서는 안 되는 것도 맞다.
한번은 결과보고서에, 내가 원하던 정규성 검정 결과가 나와서 그 내용과 코드를 떡하니 집어넣었다. 그런데 validation용 데이터셋을 새로 집어넣으니 곧바로 결과가 우그러졌다. 하하하.....덕택에 창피함과 괜히 떠벌렸다, 하는 부끄러움이 몰려들었다. 경험담이란 얘기다 ^_^...
+) 생색을 낼 필요는 없지만(겸손이 기본이다), 내서는 '안 되는' 건 아니다. 자신 있게 어떤 일을 했다, 혹은 하고 있다,고 말할 준비는 언제든 되어 있어야 한다. 그리고 뭔가 성과가 확실하게 나왔다면(기대를 주는 게 아니라, 확실할 때!) 그때는 돌려서 내가 뭘 했다~ 정도는 말할 수 있어야 한다.
어쩌면 이 포스트는 계속 업데이트될 수도 나만의 메모장에서 끄적거림에 멈출 수도 있다. 어떨진 모른다. 다만 이 포스트를 다시 보게 될 그때는 지금 준비 중인 모든 게 세상에 나온 다음이길 바란다. 새로운 정체성 후보로서의 일이 업뎃되면 좋겠다.