그 일 왜 하세요?

오예! 오늘도 직장에서 하나 배웠다. 

이 일을 왜 해야 하고 어떻게 해야 가장 좋은 방법으로 할 수 있는지 생각하는 일은 사실 벌써 10년 차 (맙소사!) 개발자가 된 나에게도 꽤나 도전적인 일이다. 도무지 어릴 때부터 이런 사고 능력이 계발, 훈련이 잘 안되어 있기 때문이다. 또한 그 부분이 내가 이 먼 곳까지 와서 3년을 열심히 버티려 하고 있는 이유이기도 하다. 내가 못하고 안 하는 것을 너무 자연스럽게 잘하는 사람들이 주위에 널려 있고 그들에게서 감동한다.

오늘 새로운 팀에서 첫 번째 업무를 진행과 관련해서 잠깐 회의한 내용을 복기해본다.

팀을 옮긴 첫날부터 task 가 주어졌다. 사실 매니저도 입사한 지 얼마 안 되어서 그 전 매니저가 넘겨준 일 아주 작은 일을 나에게 토스한 것이었다. 현재 회사 내부 전용으로 사용되는 페이지에서 호출 중인 지표 수집 API 가 deprecated 됐으니 새 API로 교체를 하라는 것이었다. API 주소를 바꾸고 코드 리뷰를 받으면 아마 될 거라고 했다. 

문제는 새로운 API와 기존 API 가 인증 방식이 다르다는데서 출발하였고 이런저런 이유로 요구 사항 충족을 위해서는 보안적인 측면에서 어처구니없는 형태로 개발을 해야 하는 상황이었다. 마치 sns 사이트를 만드는데 id와 password를 그냥 고정해 놓고 모든 사람이 한 계정을 사용해야 하는 상황이었다. task를 받을 때 한 가지 조건은 이 사이트는 금세 님이 (그러니깐 내가) 만들 신규 시스템으로 교체될 건데 현재 이 사이트에서 발생하는 지표들이 궁금하니 일단 바꿔서 신규 API로 지표들을 쌓으면서 교체 하자는 것이었다. 다행히 직원들을 대상으로 만들어진 회사 내부용 사이트였고 첫 번째 task를 얼른 해내고 싶은 마음 조금을 더 해 몇 가지 의문과 이상함을 뒤로한 채 코드 리뷰 하나를 만들어 옆 팀 동료에게 던졌다. 4줄짜리 코드 변경이었다. 

코드 리뷰에서 해당 부분의 보안상 문제를 지적하는 댓글이 바로 달렸고 리뷰어와 이야기를 시작했다. 나는 이거 데이터가 오랫동안 안 남아서 남기려고 해. 내부 전용 사이트고, 고객이랑 아무 상관없어서 최악의 경우에도 큰일은 아니고, 현재 이 방법밖에는 요구 사항 충족을 할 수 있는 방법이 없네. 정도의 방어를 하기 시작했고 그 친구도 많은 부분 나의 의견에 대해서 특히나 '이 방법밖에는 없네' 부분에서 동의하였다. 하지만 나 스스로도 마음에 들지 않았기에 결국 논의 끝에 매니저에게 escalation 해서 진행을 계속할지 하지 말지를 결정하자고 했다.

오늘 매니저와의 3자 회의에서 그 리뷰어는 자신의 생각을 좀 더 늘어놨는데. 아 이게 내가 여기 온 이유였지.라는 생각을 정확하게 할 수 있는 30분의 대화였다. 그 친구의 말을 요약하자면   

      일단 이 코드는 우리의 코드 퀄리티를 엄청나게 내리는 것이야.

      근데 이 시스템 오래전부터 고장 나 있었고 몇 달 후에 교체될 건데 왜 갑자기 보안상 문제를 만들어가면서 까지 고치는 거야?

      근데 이 메트릭을 남기는데 꼭 이 새로운 API 가 필요한 거야? 사실 단순한 메트릭 수집 용도로 사용하기에 신규 API는 너무 복잡하고 안 어울리는 거 아니니? 다른 더 적당한 시스템이 있는 거 아닐까?  

      근데 여기서 남기려는 메트릭들을 이용해서 뭘 하려는 거야? 이거 메트릭으로 어떤 (사내) 고객의 문제를 해결할 수 있는 거야?

      야 우리 working backward 해야 하잖아. 도대체 이 일은 고객의 어떤 부분을 해결하기 위해서 시작된 거야? 이거 메트릭 몇 개 남겨서 그 부분이 해결이 되긴 하는 거야?

      알겠지만 사실 임시방편으로 만들어 놓고 나서 제대로 고쳐지는 일은 잘 없어. 이거 기술 부채로 결국 남아서 나중에 문제가 될 거야.

      근데 이 시스템 사내 보안 리뷰는 통과해야 하는 거야? 이거 이러면 도저희 통과 못할걸  

      만약 비즈니스 요구사항을 정말 충족해서 이렇게 진행해야 한다면 이거 왜 이렇게 했는지, 최악의 경우 어떤 일이 발생할지, 어떤 계획으로 이 문제를 추후에 없앨지 문서 좀 남겨줄래?  

사실 위에서 하는 질문들은 기존에 있던 사람들이 원래 관습대로 일을 잘못 처리하려고 할 때 나 같이 경력이 있는 새 팀원이 딴지를 걸며 해야 하는 질문인데, 주어진 일을 끝내야겠다는 성급한 마음과 단방향 생각이 결국 이렇게 강력한 조언과 함께 저항을 불러일으켰다.

30분의 회의를 마치고 한 학기 수업을 들은 것 같은 기분이 들었다. 결국 회의 후 우리 매니저는 예전 API를 신규 API로 변경하는 일에서 벗어나 원래 비즈니스의 요구 사항이 무엇인지, 그 요구사항을 위해 무엇이 필요한지 또는 정말 이 몇 개 지표만 있으면 되는지, 그들이 신규 시스템을 기다릴 시간은 없는지 등의 질문을 개발자들의 우려 섞인 목소리로 전달하기로 했다.