[끄적끄적] 3년차 개발자 2022년 회고

3년차 개발자 2022년 회고

시작하기 앞서, 나의 3년동안의 개발자로써 일을 하면서 느꼈던 점이며, 정리되지 않은 글 또는 한풀이가 될 수 있다. 계속 수정 예정이다.

💩하고 싶은말

3년동안 개발자로 일하면서, 느꼈던 점에 대해서 다뤄보고자 한다. 많은 미디어에서 각광받던 개발자의 현 모습을 민낯없이 느꼈을때, 나의 감정들을 글로 두서없이 적어보고 싶었다.

💻 의료 IT 개발자 ‘환상’

회사에 처음 입사할때 나는 의료 IT 개발자 ‘뽕’에 취해있었다. IT 직군 개발 중에서도 특화되었다고 생각하여 환상을 갖고 있었다. 회사 홈페이지에 기재되어 있는 신기술, 특허 등을 보면서 앞으로 내가 입사한 회사에서 중요한 중심축이 되어 홈페이지에 나와 있는 기술들을 만들겠지? 기대에 부풀었던 적도 있었다. 매일매일 재미있는 프로젝트와 배움의 연속이라고 생각하는 환상을 접어두었다.

배움은 ‘훔쳐먹는 것’이라고 생각한다. 다른 사람들이 가장 ‘최소한의 룰’만 알려줄 뿐 나머지는 본인이 개척해야 되는 부분이라고 생각한다. 경력자와 신입 사이의 격차는 여기서 발생한다고 생각한다. 최소한의 온보딩을 끝낸 이후, 얼마나 ‘알찬 질문’을 통해서 실제로 회사에 ‘기여’할 수 있을 정도의 역량을 키울 수 있는지가 관건이다.

🤷‍개발 능력보다 업무로직?

일을 하면서 업무로직과 개발능력 상관관계에 대해서 생각을 해보았다. 기본적으로 업무로직을 알아야 거기에 맞춰 개발을 한다. 하지만 어느정도 업무로직을 알고 난 이후에는 개발하는데에 ‘정체기’가 들어선다. 요구사항에 맞춰 ‘기능’을 찍어내고, 레퍼런스를 찾아 Copy and Past를 하면 되는 부분이 많기 때문이다. 과거에 기존에 있던 코드를 복붙하면서 실실대며 ‘돌아는 가네’라고 생각했던 나를 반성한다.

업무로직을 기본적으로 알고, 개발을 하면서 기존의 프로그램에 대해서 사용자의 요구사항, 최적화, 아이디어를 끝없이 생각하지 않는다면 ‘고인물’이 된다고 생각한다.

🗣 커뮤니케이션

커뮤니케이션은 ‘공감’이 중요하다고 생각한다. 상대 또는 단체의 리즈를 이해하고, 공과 사에서 가장 중요한 요소이기도 하다. 하지만 가장 어려운 부분이기도 하다. 서로의 ‘이해관계’가 맞물려 있고, 계산적으로 득실을 따지다보면, 소통이 아닌, 각자 ‘하고싶은 말’만 오고 갈 뿐이지 누구하나 듣고자 하는 사람들이 없을 수 있다.

수많은 시간을 들여가며, 회의를 해도 ‘끝맺음’이 안나는 경우가 있다. 돌고 돌아 원활한 소통으로 효율적으로 일을 하려고 했던 일들도 본질이 흐려진다. ‘우리는 회의를 많이해요!’ 등 회의 횟수나 시간을 많이 들여서 했다고 소통을 잘했다고 악수하며 좋아한다면, 과연 우리가 ‘소통’을 잘한건지 이해관계에 따라서 계산적으로 본인의 할말만 정리해서 내뱉은 건지, 돌아봐라 자 이제 우리가 소통을 하는건지 ‘떼를 쓰고 있는건지’

예를 들자면, 이와 같을 수 있다.

개발자vs개발자

개발자끼리와도 대화하다보면 소통이 안되는 경우가 있다. ~한 이유로 공수산정이나, 추후 유지보수나 서비스측면에서 어려움이 있을 것 같다. 라는 고민을 제시하면, 왜 이런것을 생각하지? 어렵게 꺼낸 이야기를 쉽게 함축해버리고, 별거 아니란 식으로 말할 때가 많다. (이 경우, 내가 많은 생각을 하고 있는 경우도 있었지만, 내가 참여하고, 현재 내가 만든 부분에 있어서 내가 제일 잘 알기 때문에, 닥쳐서야 어려움을 이해하는 경우가 많았다.)

이 때, 서로의 커뮤니케이션에 있어서 뭐가 문제인지 생각해본다면, 우리 개발자들이 우선순위 해야할 ‘일’들이 많고, 왜 문제인지 대해서 개발역량이 낮아 이해의 깊이를 모를 수 있고, 우선순위가 낮다고 생각(‘귀찮음’)이 들었던게 아닐까 생각한다.

개발자vs사용자

개발자는 사용자 요구사항을 만족하고, 더 나아가 사용자 요구하지 않더라도, 편하고 똑똑한 프로그램을 만들 의무가 있다고 생각한다. 서비스를 개척하고, 효율적으로 만들어서, 결국 사회의 공공재로써의 역할을 다하는 것이다. 하지만, 우리에게도 Deadline이 있으므로 마냥 프로그램을 개발하는데 세월아~네월아 할 수 없는 노릇이다. 이때, 개발자와 사용자의 소통을 통해 풀어야 하는 과제가 있다. 서로를 이해해 주는 ‘공감’이 중요하다.

소통과 ‘떼쓰기’는 다르다. 사용자가 요구사항만 무조건적으로 고집한다면, 개발자 입장에서는 난처할 수 있다. 반드시 되어야 하는 부분에 대해서 우선순위와 프로그램 인터페이스를 설명하면서, 의견을 조율해나가야 한다. 그럴때, 본인의 요구사항만 관철시키며, 이해를 못하냐는 식으로 공격적인 태도로 나온다면, 이때부터는 소통의 지옥을 경험하게 될 것이다.

미팅을 수십번 해도 ‘소통’이 시원하게 트이는 경우는 쉽지않다. 객관성있는 넓은 시야로 프로젝트의 전체적인 그림을 보려고 노력해야한다.