시니어 개발자의 무기는 무엇일까?

 

시니어 개발자

 

나는 이제 갓 5개월 된 신입 개발자다. 어려운 시기에 취직한 게 다행이라고 해야 할지, 공백기가 조금 있었음에도 운이 좋게 어느 정도 규모가 있는 회사에 들어갈 수 있었다.

 

지금은 일하는 모든 것이 새롭고, 지금까지는 일하는 것이 즐겁다. 일하면서 다른 팀 사람들과 상호작용하는 것과, 나에게는 뜬구름같았던 '현업 코드'가 무엇인지, 요구에 따라 만들어진 스파게티 코드를 읽으면서 분석하는 것도 재미있다.

 

그중에서도 내가 일하면서 가장 좋아하는 지점은 다른 개발자들이 어떻게 일하는지 보고 배울 수 있다는 점이다. 어떻게 요구를 관리하고, 기획서를 어떻게 해석하며, 기능 적용에 대해서 어떻게 구현할지를 생각하는 선배 개발자들을 보면서 배우고 있다.

 

그중에서 최근 가장 인상깊었던 경험이라고 하면 우리 파트의 상무님과 함께 일했던 경험이다.

 

미들급 개발자들에게 구현방법이나 회사 코드에 대해서 질문하고 답변을 받으면 '내가 모르는 부분'에 대해서 정말 잘 알고 빠르다는 인상을 받는다.

 

시니어 개발자인 상무님과 일을 할 때는 일 자체를 단순화한다는 느낌을 정말 많이 받았다.

 

투자와 서비스 모니터링을 다루는 회사 도메인 특성상 하나의 기능에도 여러 팀이 엮인다.
서비스 신청, 모니터링, 계약, 청구, 정산, 계좌연동, 보안까지 연결되다 보니 ‘이걸 도대체 어떻게 접근해야 하지?’ 막막할 때가 많았다.

 

상무님과 일을 할 때는 이 복잡한 과정을 왜 기능이 필요한지 확인하고, 기능 실행 시점을 단순하게 정의해 모듈의 위치를 잡고, 기능은 최대한 단순화해 일을 받는 입장에서도 쉽게 풀어갈 수 있게 해준다.

 

최근에 마케팅팀, 서비스팀, PO팀, 실무팀이 모두 엮인 일에 대해서 서비스 페이지 기능과 백오피스 기능을 만들어야 하는 경우가 있었다.

 

나는 한참 고민하고 있었다.

 

- 이렇게 바뀌면 기존 프로세스는 어떻게 하지?

기존에 존재하던 기능에서 프로세스 자체가 변경되는데다, 여러 개의 서비스에 한번에 올라가야 하는 상황에 실무팀이 기존에 일하던 방식과 내가 이번에 구현해야 하는 내용이 어떻게 반영되어야 하는지에 대해 고민이 많았다. 유저에게 보여지는 시점과 마케팅팀이 일을 처리하는 시점, 실무팀이 일을 처리하는 시점에 대해서 고민했다.

 

- 가깝게 엮인 기능은 어떻게 하지?

사이드이펙트로 오류를 한번 터트렸던 뒤라, 관련 기능이 엮였을 때 어떻게 해야 할지 코드를 읽으면서 고민했었다. 

 

- 백오피스를 다룰 때 실무자가 어떻게 오류가 덜 생기게 하지?

오류가 날 수 있는 케이스를 어떻게 막아야 되는지, 실수가 일어날 수 있는 지점이 어디인지에 대해서 고민했었다.

 

위 이유들을 회의와 코드 읽기를 오고가면서 빙빙 돌고 있었는데, 상무님이 기능과 실행 시점을 깔끔하게 정리해주고 나서 하신 말씀이 이 글을 쓰게 했다.

 

'뭐 그렇게 복잡하게 생각해? 업무 프로세스는 개발자가 그렇게까지 신경 쓸 영역이 아니지. 실무자가 책임을 가지는 영역이야.'

 

상무님은 이미 업무 프로세스에 대해서 많은 부분을 이해하고 계시니 하실 수 있는 말씀이긴 했지만, 개발자가 다른 팀 책임까지 모두 안고 갈 필요는 없다는 이야기처럼 들렸다.

 

사실 상무님이 개발팀과 일하는 방식도 크게 다르지 않았다. 특정 기능영역을 정확하게 알고 있지 않더라도, 책임을 가지고 있는 인원에게 디테일한 영역을 물어보고 확인하며, 그에 대한 책임은 그 인원이 가지고 있었다.

 

신입 개발자는 보통 모든 예외 상황과 프로세스를 머릿속에 넣고 구현하려고 한다. 나 역시 “이 경우는?”, “저 팀은?”, “기존 흐름은?”을 계속 고민하면서 점점 복잡하게 생각하고 있었다.

 

그런데 시니어는 오히려 책임의 경계를 먼저 나눈다고 느꼈다. 누가 결정하고, 누가 검증하고, 어디까지를 시스템이 책임질지를 정한 뒤 기능 자체를 단순하게 만든다.

 

지금 와서 생각해보면, 기술 자체보다도 복잡함을 관리하는 방식이 더 큰 차이를 만든다는 생각이 든다.