2023년 12월 2주차 주간회고

 

 

   서론

  주간회고를 시작하기로 했다. 여태까지는 하루하루가 정신없이 지나가고 되돌아볼 여력이 없어서, 혹은 의지가 부족해서 작성할 엄두를 내지 못했다. 그런데 이렇게 그냥 매일을 흘려보내기만 하면 혼미하게 시간이 지나갈 뿐이라는 생각이 들었다. 나 스스로에게는 부끄럽지 않게 나름대로의 삶을 살아가고 있지만, 그럼에도 불구하고 문득 돌아봤을 때 내가 무얼 하며 그 시간들을 보내왔고 어떤 점이 힘들었으며 어떻게 해결했는지가 까맣게 지워져 기억나지 않는 부분은 아쉬웠다. 그래서 마음 먹었다, 이제 나도 기록을 하자! 

  회고라는 것을 하지 않던 사람이 매일매일의 회고를 하기는 쉽지 않고, 회고 자체에 많은 시간을 빼앗기는 것도 그다지 바람직하지 않다는 생각이 들어서 주기는 주간으로, 일주일을 마무리하며, 혹은 시작하며 그렇게 작성하는 것을 목표로 한다. 회고의 양식은 어떻게 작성하는 것이 좋을지에 대해서도 다소 고민을 했는데, 일단 이후에 바뀔 수도 있겠지만, 많은 사람이 사용하고 있는 것처럼 보이는 KPT 방식으로 작성해보기로 했다. 

 

※ KPT 회고법
( * 해당 내용은 🔗회고 작성법 블로그 글를 참고했다. )
- Keep : 잘한 것 / 좋았던 것
- Problem : 어려웠던 것 / 아쉬운 점 / 개선할 점 / 이슈사항
- Try : Problem을 해결한 방법 / 해결되지 않은 Problem에 대한 피드백
- 여기에 추가적으로 필요하다면 서론 또는 마무리글을 덧붙인다. 

 

   처음이니 뭘 써야할지 어떻게 써야할지 서툴지만 일단 대충이라도 적자!

 

 

 

  Keep

  1. 업무 순서가 꼬이지 않게 정리하여 처리

  업무의 우선순위는 잘 정해서 가고 있다고 생각한다. 업무적으로 사실 당장 시급하게 들어오는 유지보수 건들이나, 갑자기 수요부서가 원하는 도입시기가 당장 차주, 혹은 이번 달과 같은 식으로 급하게 기능개발 요청이 들어오는 경우가 있다. 그런 경우에 우선 순위에 따라 일을 잘 배분해서 하고 있다. 물론 워낙 일의 시기나 경중이 대중없이 들어오다보니 스스로 혼란스러운 부분은 있으나, 업무일지나 유지보수 기록물을 통해 최대한 순서와 내용을 정리하고 있다. 메모나 노트도 적극 활용하고 있으나, 이렇게 기록이 분산될 경우엔 그게 또 오히려 누락을 유발하는 경우가 있어 가급적 하나 혹은 많으면 세 개까지의 파일/매체 안에서 정리하고 업무를 처리하기 위해 노력하고 있다. 

  2. 새로운 팀원 인수인계 및 방향제시

  이번 주에 새로운 팀원이 들어왔는데, 그에 대해 나름대로 선임답게 일의 방향성을 이끌어주고 있다. 물론 당장 나도 일이 바쁘고 정신이 없어서 당연하지만 완벽하진 않았겠으나....... 새로운 팀원 분이 타팀(개발팀)에서 1년 이상 근무하신 상황이기 때문에, 이전의 팀원들보단 업무처리에 대한 지식이 있어서 그래도 비교적 빠르게 팀에 적응하고 계신 것으로 보인다. 유지보수 업무에서 가장 다들 적응을 어려워하는 부분이 전화업무인데, 그런 부분에서도 적절하게 대응하고 있는 것으로 보인다. 그럼에도 불구하고 판단이 어려운 부분에 대해 의견을 구해온다거나 하면 내 선에서 적합한 해결책을 제시하고 있다. 내 선에서 처리되지 않는 부분이나 시급한 부분은 빠르게 PM님에게 보고하기도 하고. 내가 어떤 방향을 제시해주는 식으로는 팀원 스스로 해결이 정 어렵겠다 싶은 부분은 내가 받아서 처리하기도 하면서 가급적 당장 첫 근무부터 크게 스트레스나 부담을 받지는 않게 노력하고 있다. 그러나 스스로 보완이 필요하다고 생각하는 부분이 있는데, 이건 아래 Problem에서.

 

  Problem

  1. 새로운 팀원 인수인계 및 방향제시

  몇 번 PM님에게도 얘기를 들은 부분이긴 한데, 뭔가 팀원이 스스로 해결책을 강구할 여지를 주기보단 내가 많은 부분을 먼저 얘기해버리는 점이 있다. 사실 팀원의 모든 부분을 내가 코치하거나 봐줄 수 없는데, A를 물어보면 그 이상 혹은 그 이후에 대한 얘기까지 늘어놓아서 오히려 혼란을 주거나 그가 정리할 시간이 없이 너무 많은 지시를 받는 것처럼 되어버리는 경우가 다수 있었던 것 같다. 변명같지만, 뒤돌아보자면 내 입장에서 얘기하자면 당연히 뒤따라오는 과정인데 그 사이에 많은 시간을 허비하는 것처럼 보여서 그 부분에서 도움을 주고 싶은 마음이었던 것 같다. 내가 말로 다 해버리니까 직접 데이터나 로직을 보지 못 했고, 여태까지의 처리경험이 나보다 적은 팀원 입장에서는 바로바로 이해하고 알아듣기가 힘든데, 결국 이걸 이해하는 과정이 필요한데 그걸 줄이려고 한 게 문제였던 것 같다.

  2. 개발사항에 대한 파악

  갑자기 다급하게 요청을 받아 가급적 이번 달 내에 처리하고자 작업 중이던 내용이 있다. 지급신청 중 하나인 A메뉴에서 신청된 내용이 B메뉴에서 담당자에 의해 새로운 신청서로 다시 이어지고, 이후에 C메뉴에 넘어가서 최종적인 완료가 이루어지는 프로세스인데 C메뉴로 넘어갔을 때 넘기는 데이터 형태가 알맞지 않다고 담당부서에게 얘기를 들어 해당 부분을 수정하고 있었다.

  그런데 이번 주 금요일, 그러니까 15일에 작업을 끝내려고 했는데 내가 생각한 개발 사항을 다 적용하고 나서 테스트를 해보자니 전혀 생각도 못 했던 부분에서 문제점이 발생했다. 발생해야 하는 집행내역 데이터가 발생하지 않는 문제였다. 그런데 이 데이터가 A메뉴 신청을 통해 발생한 데이터를 계속 가져가는 구조라서, 내가 지금 건드리고 있는 B메뉴와 C메뉴의 로직 수정만으로는 수정이 어렵다는 판단이 금요일에서야 들었다. 아, 애초에 그 부분을 미리 체크를 했어야 했는데, 돈과 관련된 로직을 수정 중이면서 그 부분을 확인하지 않았다니 다소 좌절감이 들었다. 사실 아예 그 부분을 안 본 것은 아니고, 내가 C메뉴 수정을 마치면 그 부분도 같이 수정될 거라고 (막연히, 근거없이) 생각했다. 늘 느끼는 거지만 안일하게 넘어간 부분은 꼭 돌아와 발등을 찍는다...

 

  Try

  1. 새로운 팀원 인수인계 및 방향제시

  해당 부분은 이제 팀원 분이 어떤 의견을 구하는 경우 딱 간결하게 내 의견을 제시하는 방식으로 해볼 생각이다. 어떤 파일 혹은 어떤 곳(사이트)에 가면 이전 이력이 있을 것으로 기억이 나니 참고를 하라던가, A에 대한 데이터를 먼저 보라던가, 딱 바로 지금의 스텝에 대한 얘기를 일단 하고 그 이후에 대한 상황을 장황하게 내가 가정해서 하지 않는 것으로 할 것. 그리고 혹시라도 유의할 상황이 있다면 미리 간단하게만 언질하는 방향으로 가야겠다. 일을 내가 가져오는 것도 문의자가 당장의 처리를 요청하는 상황이라거나 너무 일이 중요한 경우에 상황을 봐서 해야하는 거고, 괜히 내가 초조해하지 말 것. 유지보수 업무를 내가 오래 했다보니 당장 일이 쌓여있으면 내 일처럼 자꾸 신경쓰이는 부분이 있는데, 지금은 담당 업무가 변경되었으니(사실 변경된지는 오래 됐지만) 내가 일을 떼어낼 겸, 팀원 분이 일에 적응할 겸 터치하는 부분을 줄여야 할 것 같다.

  2. 개발사항에 대한 파악

  당장 벌어진 부분에 대해서는 일단 차주 월요일에 PM님과 논의하기로 했으니 방향을 다시 정해볼 예정이다. 일단 내가 파악한 부분만 생각했을 때는 그게 지금 수정이 가능한 부분인가 싶긴 하다... 지출/예산과 관련된 부분이다보니 성급히 변경했다가 다른 부분에 더 큰 오류를 발생시키는 것도 우려가 된다. 정 수정이 안 된다면 지금까지 내가 수정한 작업물도 모두 일단 롤백하고 수정 없이 현재의 시스템에서 이용을 하실 수 밖에 없는 상황인데, 그렇게 안내가 나가게 될 경우 얼마나 송구할지 생각하니 좀 막막하다. 그렇지만 안 되는 건 안 되는 거고, 내가 잘못한 거니 누굴 원망할 수도 없지... 다음부턴 현행을 꼼꼼하게 보고 확인해야 한다. 지출과 관련된 부분은 무조건 예산을 같이 생각해야 한다는 것도 잊지 말자.