대학원 한 연구실의 랩장(팀장)이 되기 전까지는 원래 듣기보다는 학부 및 외부 프로젝트 및 과제 모든 면에서 팀장을 많이 하다보니까 의견을 듣기 보다는 말하는 입장이었다. 하지만, 연구실에서 랩장이 되면서 내가 아는 사실은 팩트 기반으로 전달하기 위해서 누군가의 의견을 묻고, 이해해보려고했다. 현재 하나의 예시를 들어보고자 한다.
어느 순간부터 누군가의 의견을 접하는게 거부감이 없어졌고, 의견 충돌이 나는 두 사람 혹은 2~3 그룹의 내용을 종합하기 시작했다. 논문 성과 및 결과는 너무 드러나는 결과를 보여주기때문에 해당 내용에 대해서 의견 다툼 및 조율이 필요없었다. 다만, 우리 연구실 주제가 Software architecture기반으로 회의하는 경우가 많다. 그러다보니 더 많은 기술이 개발이 될때 이후 개발 과정 및 기능을 염두에 두고 회의를 해야하는 경우가 많았다. architecture 자체 개념을 알고 서로 생각하는 결론이 다르다는 사실은 우리가 결론을 내기까지 많은 시간을 소요하고있었다.
오늘은 이전 구축해두었던 architecture에 대한 개선 사항을 누군가 의견을 제출하였다. 좋은 과정이라고 생각했다. 왜냐하면, 처음부터 설계된 architecture가 100%라는 생각을 하진않았기 때문이다.
A그룹
-
기존 architecture는 해당 서비스(기능) 중 특정 기능이 AI로 real-time 능력에 부하를 걸 수 있기 때문에 서비스(기능)을 더 쪼개야한다.
=> 동의. 단, 근거는 충분한가? -
Yolo 라이센스 특성상 소스 자체를 Open-source로 만들어야하기때문에 이를 신중하게 설계해야한다.
=> 동의
B그룹
- 기존 architecture는 그걸 모두 고려해서 만든거다.
=> 동의
Q. 현재 설계된 architecture 구조에서 A그룹에서 제안한 방법으로 쪼갠다고 되는 문제인가? 쪼개는 것은 좋으나 기능을 재활용할 수 있어야한다. 그리고 현재 설명했던 구조또한 B그룹 즉, 이전에 설계한 기존 architecture와 다르다고 표현한 부분이 무엇인가?
A. 재활용을 하기 위해서 해당 방향으로 흘러가야한다.
B. 현재 우리 연구실이 사용하고 있는 플랫폼 자체를 알지못해서 하는 소리다.
A그룹의 의견에 대해서 더 추가적인 정보가 필요했다고 판단하여 그렇다면 설계하기 위해서 블럭 단위로 설명했는데 풀어서 말해달라고 추가 질문을 이어갔다.
A. 블럭은 결국 서비스(기능)들이 뭉쳐있는 상황이다.
현재까지 계속 언성이 높아지고있다고 판단이 들었고, 이말을 듣자마자 결단을 내렸다. real-time에 대해서 기존과는 다른게 없다. 다르게 그림을 그리고 설명을 하고자해서 생기는 문제이다. 다만, 기존에서 쪼개고 안쪼개는 내용은 논문을 좀더 찾아보자. 현재는 우리 머리속에 있는 말이 정답이라고 생각하기때문에 결론이 나지않거나 타협하고 지나갈 확률이 높다.
해당 말을 하고 상황에서 벗어날 수 있었다.
아쉬운 점
조금 더 그들이 중점적으로 말하고자하는 바를 먼저 말하게 하고, 정확한 정보 전달을 서로 하기위해서 안건을 제출하고 서로 준비할 시간을 주었으면 어땠을까?라는 생각이 든다. 물론 모든 순간이 그렇게 준비할 시간이 있을정도로 안될 수 있다. 그 경우에는 말하고자하는 바를 "현재의 부분은 ~~ 이렇다. 제안하고자 하는 방향은 이 부분에서 바꾸고자 한다." 라는 식으로 진행해보고자 한다.
