1. 시작하며

입사한지 막 1년이 지난 프론트엔드 동료와 1 on 1 미팅을 했다. 나도 이런 미팅이 처음이거니와 그에게 아쉬운 부분을 전달해 주어야 했기에 어떻게 이야기를 시작하고 이어가야할지 막막했다. 혹 상처를 받지는 않을지 내가 감정적으로 말하지 않을지 염려도 되었다. 그래도 말해주는게 그에게도 나에게도 좋겠다는 생각이 들어 잠시 얘기를 나누는 시간을 가졌다.

2. 아쉬운점

테스트

그는 장점이 분명했다. 어떤 스펙을 정의해주면 엄청난 속도로 개발이 진행되었다. 반면 아쉬운 점은 테스트에 대한 부분이었다. 사실 버그란 건 아주 훌륭한 개발자도 얼마든지 생산할 수 있으니 버그가 있는 코드를 만든다고 그 사람의 태도를 문제 삼지 않는다. 다만 ‘A 를 누르면 B 가 뜨게 해주세요’라는 스펙이 있는데 A 를 눌렀는데 B 가 안나오는 결과물을 가져오는 건 문제가 있다. 사실 이것 조차도 사람이 일하다보면 그럴 수 있다. 그러나 이런 일이 몇 번 반복되면 문제가 있다고 생각한다.

능동성

앞에서 말했지만 그는 스펙만 정의되면 개발 속도가 빨랐다. 종종 내가 업무를 할당해 주는 속도가 더 느릴때가 생기곤 했는데 그럴 때면 그냥 몇 일을 대기(?) 하고 있는 모습을 보였다. 한 번은 공부하고 싶은 것 없냐, 리팩토링 하고 싶은 것 없냐 물었는데 특별한 응답이 없었다. 제품이나 자신의 코드에 대한 오너쉽이 있다면 분명 이때다 싶어 개선하고 싶거나 학습하고 싶은 부분이 있을 거라 생각했는데 그런 모습이 보이지 않았다. (문득 그에게 아쉬운 점도 있지만 그가 오너쉽을 가질 수 있는 환경을 내가, 우리팀이 조성해 주었나란 질문을 글을 적다보니 나에게 던지게 된다)

탁월함

종종 그가 적당하게 구현한다는 느낌을 받는다. 이건 내 욕심일 수도 있지만 나는 동료가 탁월함을 추구하면 좋겠다. 조금더 고객에 대해 고민해서 불편한 것들을 개선하고, 편리한 것들을 녹여내는 노력을 해주면 좋겠다. 그에게 적당한 스펙대로 구현한 적당한 결과물을 자주 본다. 스펙이 적당하면 정확히 적당한 결과물이 항상 돌아오는 것 같아 아쉽다.

3. 피드백 주기

위에서 정리한 내가 아쉬워 하는 부분을 나는 당신에게 기대한다고 명시적으로 한 번도 말해준 적이 없었다. 그래서 내가 기대하는 바를 분명하게 말해주는 시간이 필요하다고 생각했다. 상처받지 않고 잘 받아들일 수 있게 말하는 방법이 필요하다고 생각했지만 잘 모르겠다. 일단 차근히 설명해 주었다.

테스트

누군가 어떤 기능을 개발해 달라고 부탁하는건 코드만 작성해 달라는게 아니라 정해진 요구사항을 코드가 만족하는지 기본적으로 테스트 하고 달라는 부탁을 포함한다고 전해 주었다.

능동성

개발자는 스펙을 구현할 수 있는 사람, 스펙 자체를 설계하고 정의할 수 있는 사람, 더 나아가 문제 자체를 스스로 찾는 사람이 있다고 설명해 주었다. 앞으로는 스펙 자체를 직접 정의해 보거나, 스스로 문제를 찾아서 해결할 수 있는 좀더 도전적인 과제를 풀어보자고 얘기했다. 주어진 스펙을 구현하는 일 70%, 스스로 문제를 찾아 해결해 보는 일 30% 정도로 점점 비중을 늘려보자고 얘기했다.

탁월함

어제 준 결과물에 대한 피드백을 주면서 주어진 스펙을 구현하면서 고객에 대해 조금더 고민하고 개선점을 찾아주면 좋겠다고 말해주었다.

4. 피드백 받기

그의 이야기를 많이 듣고 싶었는데 내가 질문을 잘못한 건지 특별한 말을 안해준다. 마지막에 나도 누군가에게 함께 일하면 편안한 사람이 되고 싶은데 나에게 불편한 점이 없는지 피드백을 받고 싶다고 했다. 그러나 말하기가 어려운 건지 특별한 답이 없다. 농담반 진담반 한 가지 말 안하면 여기서 못나간다고 얘기했더니 그제서야 말을 꺼낸다.

API 다 되었나요?

API 스펙을 정의해 주시는데, API 가 구현되었는지 안되었는지 명시적으로 알 수 없어서 불편하다고 말해주었다. 물어보면 빨리 해달라고 부담을 주는게 될까봐 말하지 않고 기다린다고 말해주었다. 아하! 우리는 API 스펙 문서를 먼저 정의하고 백엔드와 프론트엔드가 동시에 개발을 시작한다. 저 백엔드 개발자는 나인데, (변명을 좀 하자면) 나는 매니저 역할도 해야하고 스펙을 정의하기 위해 운영팀이나 하드웨어 제조사와도 많은 커뮤니케이션을 해야해서 조금더 바쁜 편이다. 그래서 대부분 API 가 더 늦게 개발되는 경우가 많았는데 그게 좀 어려웠나 보다. 앞으로는 API 스펙 문서 한 칸에 API 완성 여부를 체크해서 공유해 주기로 했다.

그래서 테스트가 힘들어요

그리고 위 문제 때문에 테스트가 어렵다고 했다. 음! 그랬구나! 사실 이 부분에서 내가 기대했던 바를 설명해 줬다. API 명세는 백엔드와 프론트엔드가 하는 약속이다. 그래서 프론트엔드는 API 명세대로 HTTP 요청이 잘 나가고 있는지 체크하면 약속을 잘 이행한 것이다. 나중에 궁긍적으로는 시스템을 통합해서 테스트가 되어야 겠지만 프론트엔드 단위 개발에서는 저 정도만 잘 확인해서 일단락해도 된다고 설명해 주었다. 나도 API 가 개발되었는데 프론트엔드 코드가 없으면 테스트 코드를 사용하거나 API 테스터 같은 것으로 약속한 요청을 보내보며 테스트 한다고 설명해 주었다. 프론트엔드 단에서도 API 없이도 자신의 코드를 테스트할 수 있는 방법을 계속 생각해 보라고 권해주었다.

5. 배운점

대화의 분위기가 어땟는지, 그가 어떤 느낌을 받았는지 알고 싶지만 당장 알 수는 없다. 조언을 주고 싶다고 말했지만 혼내는 느낌을 준것도 같아 한 편으로 미안하다. 그래도 1 on 1 미팅을 하면서 다음의 것들을 느끼고 배우게 된다. 좀더 성숙한 동료가 되고 싶다.

알거라는 가정

사실 1 on 1 미팅을 회고해 보기 전까지도 몰랐다. 그가 내 의도를 안다고 가정한 것들이 너무 많았던 것 같다. 사소한 대화를 많이해서 내 의도를 명시적으로 전달해 줄 필요가 있겠다.

나름의 사정

이 역시 회고하면서 느끼게 된다. 내가 문제라고 생각했던 상대의 모습에 내가 알지 못하는 나름의 사정이란 게 있구나. 듣는 것은 역시 중요하다.

단 번에 어렵다

한 번의 미팅을 통해 동료의 마음을 듣는 일은 쉽지 않았다. 약간은 진지하면서도 가벼운 대화가 자주 지속적으로 오가야 겠다는 생각이 든다.