첫 회사 회고 2

백오피스 API를 만들면서

백오피스 API를 만들면서, 백엔드 단이 먼저 개발이 되고 프론트 단이 늦게 개발이 되고 있는 상황이었다. 그래서 내가 생각한 에러와 데이터를 어떻게 보내줄지에 대한 소통이 부족해, 많은 수정을 했어야만 했다. 또한 한 api에 query를 받아 분기 처리를 하는것이 있어, 이 분기처리를 하는 것이 어느 페이지에서 api 요청을 보내는지에 대한 이해가 많이 부족했다. 그래서 수정할 것이 있어서, 건들이게 되었는데 다른 페이지에서 터지는 상황이 발생을 하였다.

소통의 부재

그때 프론트 엔드 개발자 분이 그 에러를 확인을 하고 api를 수정 부탁드린다고 요청을 했고, 사수에게 ‘api 수정을 조심히 해달라고 해주세요’ 라고 말을 하더라. 나는 그렇게 말한 것을 듣고 난처 했다. 프론트 엔드와 지금 함께 만드는 것도 아닌 상태이고, 따로 api의 query 분기 처리에 대해서 설명을 들은 것이 없었기 때문이다. 또한 프론트 코드와 사수가 작성한 코드를 pull 받아 달라는 말이 없어서 아직 바뀐게 없구나 하고 만들고 있었기 때문에 이러한 일이 일어난 것 같았다.

하지만 지금 생각해보면 소통의 부재가 원인이었던 것 같다. 지금 백오피스를 만들기 위해서 이 api를 분기 처리 하려고 한다 이 api에서 query를 A를 받았을 때, 이러한 용도로 쓰이게 된다. 이러한 설명을 해주었다면 이러한 일이 안 일어났을 것 같다. 또한 나도 프론트 코드와 사수가 만든 코드를 pull을 받아야 하는지, api에 대해 어느 페이지에서 호출 하고 있는지 이 부분을 건들이면 어느 페이지 까지 영향을 미치는지에 대한 것을 물어봤어야 했는데, 그러지 못했다.

지금 생각을 해보면 이래서 코드 리뷰가 중요하구나 라는 것을 느낀다. 내가 아무리 인턴이었어도, 지금 어떻게 개발이 되어가고 있는지 왜 이렇게 query를 받아 분기 처리를 해야하는지에 대한 것들을 리뷰를 하면 이러한 에러들을 간단하게 해결 할 수 있었지 않았을까 라는 생각을 한다.

커뮤니케이션 스킬

우리 회사는 주 마다 각자의 스프린트가 있고, 월요일엔 그 주의 스프린트에 대한 발표, 금요일엔 스프린트를 얼만큼 끝냈는지에 대한 회의를 한다. 이 회의를 참여해 내 스프린트에 대해 이야기를 하면서 느낀것이 있는데, 내 말이 너무 느리다는 것이다. 평소에 주위 사람들에게 말이 느리다는 말을 조금 듣긴 했지만 그렇게 느린 편인가? 라는 생각은 해본적이 없다. 하지만 회의를 하면서 내가 너무나 말을 느리게 하는 것을 느꼈다. 아무래도 말 주변이 없어서 긴장이 되고, 틀리지 않거나 말을 더듬지 않을려고 조심히 하는 버릇이 이렇게 된 것 같다. 말을 하기 전에 내가 말해야 할 핵심적인 요소를 빠르게 파악을 하고 정리하여 핵심 내용만 잘 전달 할 수 있게끔 노력을 해야겠다는 생각이 들었다.