회사생활 두번째 일기 ( 백엔드 시니어와 마찰 )

회사에 입사한 후, 이사님은 직원들의 배려를 최우선으로 두셨다. 자율근무와 당일 연차는 물론, 양재에서 인천까지 통근하는 나를 위해 특별히 시차 출근까지 허락해 주셨다.

좋은 동료들, 경영진, 탄탄한 BM과 본사의 자본력까지 모든 것이 순조로웠고, 이직이 성공적인 선택이었다는 확신을 가졌다.

하지만 문제는 따로 있었다. 바로 기술 면접 과정이 없었던 점이었다.

 

의견 충돌에 대한 개인적인 생각

사실 기술 면접이 없다고 하더라도 개발 구성원 전체가 같은 동레벨에 같은 뜻을 갖고 있다면 문제는 크지 않다고 생각한다.

 

구성원들이 true고 false고 키값이 어떻게 오고 이런걸 문제 삼지 않는 프론트엔드 개발자와 백엔드 개발자이며,

그게 더 익숙한 개발자끼리 모였다면 어찌되었던 일이 수월하게 잘 수행이 되니까.

 

예를 들어서 자바스크립트를 쓰던 타입스크립트를 쓰던 결과물에 문제가 없으면 된다.

하지만, 나는 주니어 개발자로써 조금 더 성장 할 여지가 남아있는데 이제와서 기술스택을 자바스크립트로 쓰는것도 개인적으로 안좋다.

그리고, 결과적으로 타입스크립트를 많이 쓰는 이유가 있다.

개발하면서 수많은 에러를 IDE 단에서 잡아준다거나, 코드를 짤 때 좀 더 설계적인 관점을 갖게 된다거나,

코드적 데이터의 문서화 등 수많은 이점으로 타입스크립트가 유행하고 있다.

 구성원이 타입스크립트를 배울 생각이 없고 나만 타입스크립트를 사용한다고 하면 팀을 위해서라면

자바스크립트를 사용하는게 더 효율적일 것이고 그렇다면 자바스크립트를 사용해도 상관없다고 생각한다.

첫 프로젝트와 불편함의 시작

본격적인 기획과 디자인이 나오고 개발을 시작하면서, 프론트엔드 팀은 나와 신입 개발자 단 두 명으로 이루어졌다.

하지만 개발을 시작하면서부터 점점 불편한 점이 생겼다. 예를 들어, boolean 값을 "Y", "N"으로 받는다거나, 키 값으로 id와 idx가 혼용되어 사용되거나 _s 같은 터무니 없는 키값이 오는 등 문제점들이 드러나기 시작했다.

이때부터 나는 점점 화가 나기 시작했다.

이전 회사에서 생기 습관인 '내가 옳다면 강하게 말해도 된다'는 태도가 나도 모르게 나왔고, 상대방의 기분을 배려하기보다는 "왜 이렇게 개발하면 안 되는지를 모르나요?" 같은 직설적인 말들이 튀어나왔다.

문제 해결과 불편한 관계의 시작

내가 맞다고 생각하는 방식을 주장하며 몇 가지 문제를 해결해 나갔다. 예를 들어, 백엔드와의 대화에서 boolean 값 대신 "Y"와 "N"을 사용하는 것에 대해 개선을 요청했고, 프론트엔드의 입장을 설명하며 설득을 시도했다.

이 대화는 잘 마무리되었지만, 이후 시니어백엔드와 기획자가 내 얘기를 뒤에서 한다는 소문이 들려왔다.

1년이 지난 지금에서야 그 당시에 나도 나름대로 상대방의 입장을 충분히 고려하지 않았음을 깨달았다.

20년 차 백엔드 개발자에게, 3년 차 프론트엔드 개발자인 내가 공개적으로 지적한 것이 상대방 입장에선 불쾌했을 수 있다는 것을 뒤늦게 이해했다.

회의실을 이용한다던가, Slack 을 이용해서 비공개적으로 대화 할 수 있었다. 충분히 논란이 될 만한 주제라고 판단 할 수 있다고 생각한다.

내게는 단순한 논의였지만, 그에겐 불필요한 자존심 싸움으로 비춰졌을지도 모른다.

사실, 더 배려할 여지가 있었지만 그것을 충분히 행하지 못했던 것 같다.

배려와 대화 방식의 성찰

결과적으로 나는 일 처리를 우선시했으나 상대방의 감정을 놓쳤다.

모든 예외 상황을 예상하고 대응하려 하면 일이 진행되지 않듯이, 모든 대화에서 예외를 고려하는 것은 어렵다는 사실을 깨달았다. 하지만 앞으로는 조금 더 배려하며 대화하고, 경력을 쌓으며 자연스럽게 더 나은 대화 방식으로 발전해 가야겠다고 다짐한다.

결국 이 작은 불편들이 쌓여 서로 냉담하게 일하는 관계가 1년 넘게 이어졌지만,

앞으로는 더 성숙하게 대화를 이끌어갈 것이다.

 

 

사실 백엔드 개발자와의 마찰은 큰 이슈가 아니었고 다음 일기에서는 8년차 프론트엔드 개발자와의 마찰을 기록해봐야겠다.