박규한

6 분 소요

다시 회고를 열심히 써보려고 한다.

지금은 오랜만에 써서 시간이 오래 걸리지만, 주간 회고를 주기적으로 하면 이 시간 또한 효율적으로 단축될거라 생각한다. 글을 잘쓰려고 하면 시간이 길어지고 안쓰게 되니까 일단 써보려고 한다.

해당 글에서는 인턴을 하면서 겪은 느낀점을 바탕으로 앞으로 어떻게 할 것인가 에 대한 생각들을 위주로 작성해보려고 한다.

내가 다시 회고를 작성하려는 목적은 다음과 같다.

  • 같은 실수를 반복하지 않기 위해
  • 문제를 명확하게 하기 위해
  • 내 감정이나 생각들을 기록하고 정리하기 위해
  • 지난 날들을 되돌아보고 앞으로 해야할 일을 생각하기 위해
  • Action Item을 통해 잘 해내지 못했던 부분을 개선하기 위해
  • 나중에 이 글을 읽었을 때 과거의 내가 한 생각들을 회상하기 위해

    • 그 동안 회고를 하지 못(안)한 이유

    사실 거창한 이유는 없다. 생활하면서 회고의 중요성이 낮아졌고 다른 일들에 의해 뒤로 밀려 안하게 되었다. 우테코할 때는 어떻게 2주/4주마다 회고를 작성했는지 모르겠을 정도로 요즘 회고를 잘 안하게 되었다. 그때 왜 잘했는지를 생각해보면 주변 사람들이 회고를 정말 열심히 했다. 교육 프로그램에서도 회고를 중요시하니 의도적으로 자신을 돌아보는 시간도 많았다.

    반대로 그동안 왜 회고를 못했는지를 생각해보면 뒤를 돌아보는 것보다 앞을 보기 바빴던 것 같다. 인턴이지만 이슈를 해결하는 스프린트 기한이 빠듯하고 이를 해결하기 위해선 시간을 많이 쏟아야 했다. 하지만 시간이 났을 때도 회고를 하지 못했는데, 회고로 엄청난 글을 써야겠다고 생각해서 오히려 부담감에 안쓰게 된 것 같다. 그때의 상황과 내 감정, 아쉬웠던 점, 개선할 점들을 간단하게 쓰면서 조금씩 확장해보려고 한다.


    다시 회고를 작성하려고 하는 이유

    회고의 중요성을 잠시 잊고 있었다. 내가 어디로 가고 있는지, 어떤 노력을 했는지 점검하는 단계가 필요했다. 그리고 내 생각들도 정리할 필요가 있었다. 너무 정신없이 달려가고 있고, 이번 기회가 없었다면 마음이 조금 무너졌을지도 모른다. 운이 좋게도 기회가 주어졌고, 이번 기회는 정말 잘 준비해가고 싶었다. 또, 입사까지 약간의 시간이 생겨 회고를 다시 한번 습관화해보려고 한다.

    일을 잘하는 개발자란 무엇일까?

    일을 잘하는 개발자란 무엇일까? 함께 일하고 싶은 사람이란 무엇일까?

    인턴 생활을 하고 나니 일을 잘하는 개발자에 대한 고민을 하게 되었다. 회사에서는 개발을 잘하는 사람이 아니라 일을 잘하는 사람을 원한다.

    개발을 잘하는 사람이 결국 일을 잘하는 것 아니냐는 반문을 할 수 있겠다. 하지만 구현 능력은 기본적으로 모두가 일정 이상 갖고 있고, AI로 어느 정도 커버가 가능하다. 따라서 일잘러가 되기 위해선 추가적인 노력이 필요하다. 인턴할 때 파트 리더들이 어떻게 일하는지, 나와 어떤 차이점이 있는지를 관찰해보았다. 이에 추가적으로 면담을 요청하여 얻은 인사이트들을 종합하여 작성해보았다. 추상적이였던 인재상들을 좀더 구체화할 수 있었다.

    주도적으로 일하는 사람

    나는 내가 주도적으로 개발한다고 생각한다. 동아리에서 프로젝트를 진행할 때는 개발을 좋아하고, 일을 만들어서 하고, 개선하고 리팩토링해왔다. 사용자 입장에서 UX를 개선하기 위해 디자이너에게 의견을 물어보고, 기획에게 기획 의도를 물어보며 구현 방향을 바꾸기도 하였다. 적극적으로 의견을 제시하고, 기존 방식을 바꿔보고, 아쉬웠던 점을 회고하는 과정을 거쳐왔다.


    일을 할 때까지도 내가 주도적으로 일한다고 생각했는데, 지금 와서 인턴 기간을 돌아보면 주도적으로 일하는 사람이 되지는 못했다. 정확히는 팀원들이 느낄만큼 내가 주도적으로 일하지 못했다.

    나는 내가 맡은 업무 내에서 필요한 커뮤니케이션이나 기술적인 이슈들을 알아서 처리하는 걸 주도적이라고 이해했다. 하지만 어떻게 보면 주어진 일만 해결한 사람이 되었다. 그 과정에서 이슈를 더 할당해달라고 하고, PD와 소통하여 해결하는 과정도 어떻게 보면 당연한거였다. 일을 잘한다고 느끼는 지점이 아니라는 것이다.


    그래서 이번에는 맡은 이슈에만 초점을 맞추는 게 아니라 개발 환경을 개선한다든지, 같은 문제를 겪을 동료를 위해 문서화를 하여 공유하는 등 이슈 외에도 팀의 생산성을 높이는 데 노력해보려고 한다.

    그리고 쉽지 않겠지만 서비스가 가지고 있는 문제를 분석하고, 해결방안까지 제시하고 싶다. 그러기 위해선 컨텍스트나 히스토리도 파악해야 하고, 코드 베이스도 파악하고 있어야 한다. 히스토리 파악은 시간을 많이 쏟는다고 한번에 파악되는 게 아니므로, 코드 베이스를 빠르게 파악하기 위해 따로 시간을 낼 것이다. 이전에는 이렇게 큰 프로젝트는 처음이라는 핑계 아닌 핑계로 거의 1~2달동안 헤맸다. 이제는 그런 일은 없게 하고 싶다.


    의견을 적극적으로 표출해주는 사람

    이 부분은 체감상 연차가 높으신 분들이 말씀해주셨다. 물론 회바회 사바사지만 적어도 서비스 기업에서는 이렇게 생각하는 분들이 많을 것 같다. 그렇게 생각한 이유는 연차가 쌓일수록 어쩔 수 없이 말의 무게가 달라진다. 같은 이야기라도 인턴인 내가 말하는 것과 10년차 리드분이 말하는 건 다르게 들릴 것이다. 정답이 없는데 정답이 되버린다고 하셨다.

    그걸 이겨내고 자신의 의견을 반박해주는 사람, 동의하더라도 다른 방법을 제시하는 사람이 좋다고 하셨다. 게다가 의견을 안내는 사람과 틀린 의견을 내는 사람이 있다면 틀린 의견을 내는 사람이 좋다라고 말씀해주셨다. 틀린 의견을 내면 알려주면 되는데, 의견을 안내면 고칠 방법이 없다.


    나도 함께 일하고 싶은 사람을 생각해보면 내 의견에 반박해주는 사람이 좋은 것 같다. 좀더 자세히 확인해준 것 같고, 내가 구현한 부분에 대해 질문해주면 다시 한번 생각하게 된다. 내가 한 게 정답이 아닌데, 그냥 넘어가면 찝찝한 느낌이 들기도 한다.


    이전에 왜 주도적으로 일하지 못했는지도 고민해보면 약간은 위축된 태도로 일을 진행했던 것 같다. “나보다 연차가 높으니까 더 잘 아실거야”, “내가 잘못 알고 있었구나” 라는 생각이 베이스에 깔렸던 것 같다. 그래서 의견을 말하다가도 상대방이 좀만 더 강하게 의견을 표출하면 수긍하게 되었다. 이를 의도적으로 인지하고 내가 생각했던 흐름과 논리를 계속해서 표현해보자.


    믿음을 주는 사람

    일을 맡겼을 때 어떻게든 해결해줄거라는 믿음을 주는 사람이다. 이런 믿음을 주는 사람들을 관찰해보면 문제 원인 파악을 잘하고, 이슈가 발생한 근본적인 원인 분석, 어떤 방향으로 해결할 수 있을지 의견 제시까지 한다. 또한, 도움을 줄 때도 자기 일이 아닌데도 적극적으로 확인해주고 같이 고민하며 문제를 해결하면 신뢰가 쌓인다.


    이것도 정말 어려운 부분이지만 문제를 해결할 수 있는 사람, 문제가 생겼을 때 도움을 청할 수 있는 사람이라는 게 드러나도록 일을 하고자 한다. 이게 되려면 질문을 받았을 때 답변을 잘해주거나 먼저 다른 사람을 도와줬을 때 그렇게 느껴지는 것 같다. 다른 사람이 불편함을 느끼는 부분을 먼저 나서서 개선해보자. 또는 도움을 요청했을 때 끝까지 해결하려는 모습을 보여주자. 믿음이 주는 사람이 되자.


    맺음말

    이 정도로 생각을 정리해볼 수 있을 것 같다. 운이 좋게도 좋은 기회를 얻어서, 고민한 방법들을 바탕으로 실제 업무에 적용해보고 회고할 것이다. 위에 작성한 것 외에도 시도해볼만한 Action Item을 나열해봤는데, 업무를 시작하고 적합한걸 찾아보자. 다음에는 주간 회고로 점검하면서 글을 시작할 것이다.

    [ Action Item 요약 ]

    • 의도적으로 내가 생각했던 흐름과 논리를 글이나 말로 표현하기
    • 이슈 해결에 적응하면 개발 환경 개선이나 문서화를 통한 정보 공유 등으로 팀의 생산성을 높이는 데 기여하기
      • 모두가 불편함을 느끼고 있지만, 시간이 없어서 또는 귀찮아서 안하고 있을지도 모른다.
      • 슬랙으로 다른 사람의 의견을 들어보고 내가 나서서 해보자.
    • 시간을 쏟아 코드 베이스를 빠르게 파악하기
      • 컴포넌트를 만든다고 생각했을 때 상수, 타입, 유틸, 훅, API 등이 어떻게 관리되고 있는지 파악해보자.
      • 범용적으로 사용되는 코드의 동작 방식을 이해하자.
    • 믿음을 주는 사람이 되기
      • 질문을 받았을 때 답변 잘하기 또는 끝까지 해결하려고 노력하기
      • 먼저 다른 사람을 도와주기 / 번거로운 일을 나서서 하기


    [ 추가적으로 고민해본 Action Item ]

    • 질문 잘하기
      • 문제 상황 파악 → 예상되는 문제 지점 → 시도해본 내용 → 궁금한 부분
      • 내가 질문했을 때 상대방이 어떤 게 궁금한지 파악하지 못한다면, 질문을 잘못한 걸지도 모른다.
      • 혼자 확인할 수 있는 것과 도움이 필요한 부분을 잘 구분해야 한다.
    • 어디서 시간을 많이 썼는지 돌아보기 (시간트래킹)
      • 하루 단위로 일지를 쓰긴 했는데, 정확히 어떤 부분에서 시간을 많이 썼는지 파악하기 어려웠다.
      • 내가 어떤 작업을 할 때 생각을 많이 하는지, 지연이 많이 되는지를 파악하자.
    • 어디서 QA가 많이 나왔는지 돌아보기
      • QA가 많이 나온다는 건 일을 2번한다는 것과 같다.
      • QA가 많이 나오는 이유는 해당 기능이 어떤 문제를 해결하는지 명확하게 파악하지 못해서다.
      • 단순히 이슈만 해결하다보니 부차적인 부분을 신경쓰지 못한다거나 사이드이펙트가 발생한다.
    • AI 툴을 활용하여 생산성 높이기
      • 반복적이거나 사람이 측정하기 번거로운 부분들을 해결해주는 도구를 찾아보자.
    • 백오피스에서만 경험해볼 수 있는 것 고민해보기
      • 프로덕트 개발과 다른 점을 명확하게 이해하기
    • 코드 리뷰가 활발하다면 내 의견을 적극적으로 드러내기
      • 이전 인턴에서는 더 잘 아시겠지라는 생각에 어느정도 수용하는 편이였던 것 같다.
      • 코드의 의도를 PR에 좀더 드러내서 공감을 받거나 피드백을 받아서 성장하자.
    • 주변 선배 개발자들이 어떻게 일하는지 관찰하기
      • 나와 어떤 부분에서 차이가 있는지, 일을 해결할 때 어떤 프로세스를 거치는지 등을 관찰하자.
      • 이전에 느낀점은 자신의 주관이 뚜렷하고 의견 표현이 확실한 사람이 리드로 많이 있었다.
      • 상사에게도 그렇게 의견 표현을 잘할 수 있는 이유는 그 부분에 대해 자신이 알고 있다는 확신이 있고, 틀리면 다시 알아가면 된다라는 자신감에서 나온다고 생각한다.
    • 일지 기록 형식에 대해 좀더 고민해보기
      • 일지를 매일 작성한다고 했는데 점점 기록을 위한 기록이 되기도 했다. 무슨 말이냐면 그냥 냅다 적어놓고 나중에 정리하자는 생각이다. 그래놓고 기록했다라 생각하면서 다시 열어볼 생각은 하지 않는다.
      • 다시 열어봐도 유의미하고, 다시 열어볼 정도로 정리가 잘 되려면 어떻게 해야할까?
      • 추가로 어떤 상황에서 냅다 적었었는지 돌아보자.
    • 그림으로 이슈 파악해보기
      • 돌아보면 이전 인턴할 때 그림을 그려서 해결한 적이 잘 없었던 것 같다.
      • 그러다보니 인과관계가 명확하지 않을 때가 있었는데, 그저 글로 해결하려고 했던 것 같다.
      • UI와 연관된 경우 그림을 그려서 플로우를 머릿속에 넣어보자.

    📘 reference

    댓글남기기

    참고