개발자의 영역

10/08

 

(영역 전개 얘기 아님)

 

개발자가 해야 하는 것은 어디까지일까?
아마 회사마다 부서마다 다 다를 테지만, 지인 중에서는 사업 제안서까지 직접 쓰는 개발자도 있다고 하고..
저건 확실히 아닌 것 같긴 하지만, 그래도 영역을 나누려면 어디까지일까 고민이 되어서.

최근 일하며 든 의문을 의식의 흐름 순으로 정리해보려고 한다.
장문의 회고..?

---

처음에는 그냥 기술 문의긴 했다.
업무를 하면서 외부 파트너나 사업 부서에서 나에게 직접 연락하는 일이 늘었다.

“이 빌드로 테스트해도 되나요?”
“이 오류는 어떤 문제인가요?”
“이 설정에는 어떤 값을 넣어야 하나요?”

이 정도는 자연스럽다고 생각했다. 내가 담당하는 영역이고, 내가 답하는 게 가장 빠르기도 하니까.
그런데 어느 순간부터 질문의 종류가 조금씩 달라졌다.

“다음 업데이트에 넣을 수 있을까요?”
“이 요구사항은 어떤 방식으로 대응해야 하나요?”

기술적인 확인을 넘어 일정이나 요구사항, 대응 방향에 관한 질문까지 들어오기 시작했다.
내가 바로 답할 수 없는 내용도 있었다.
그러면 다시 내부의 기획, PM, QA 담당자를 찾아가 확인하고, 받은 답을 외부에 전달했다.
질문이 더 오면 다시 확인하러 갔다.

처음에는 하나씩 해결하면 되는 일이었는데, 이게 반복되니 조금 애매해졌다.
점점 문의에 대응하려면, 다른 사람, 다른 팀의 업무와 일정까지 확인해야 하는게.. 어느 순간 위화감이 들었던 것이 우선.

 

---

문제는 내가 어디까지 판단해도 되는지였다.

최근에는, 기존 대응 방식이 외부 심사에서 반려되면서 새로운 대응이 필요해졌다. 그런데 조작 방식이나 UI/UX, 대응 범위가 정해지기 전에 먼저 일정 질문이 들어왔다.

“다음 업데이트까지 대응할 수 있을까요?”

개발자 입장에서는 답할 수 없었다.
구현 자체는 가능할 수 있다. 하지만 무엇을 구현할지 아직 정해지지 않았고, 기획이나 QA에 얼마나 시간이 필요한지도 모른다. 다른 작업의 우선순위를 바꿔야 하는지도 확인해야 한다.

구현 가능 여부 / 공수를 판단하는 것과, 다음 업데이트에 넣겠다고 확답하는 것은, 범위와 책임 소재가 다르다고 생각했다.

불만이 조금 생겼던 지점은,
요구사항을 확인하고, 여러 부서의 일정을 조율하는 것까지 내가 해야 하나 싶었다. 이런 일은 PM이나 기획 쪽의 역할에 가깝다고 생각했기 때문에, 작업자는 일감과 기획을 받아 구현을 잘 해주는 것이 역할 아닌가.. 라는 생각에.
괜히 이것저것 잘 답해주고 알아봐주다 보니 모든 질문이 나에게 오는 건가 싶기도 했다.

그렇다고 내가 주어진 일감만 구현하고 싶었던 것은 아니다.
내가 맡은 영역의 기술적인 방향은 직접 판단하고 싶었고, 어느 정도 의사결정권도 가지고 싶었다. 외부와 직접 이야기해서 문제를 해결하는 경험도 나쁘지 않았다.
그리고 이해가 되는 지점은, 간단한 기술 문의까지 PM을 거쳐 전달하면 오히려 돌아가는 경우도 많다. 내가 몇 마디로 해결할 수 있는 일을 굳이 여러 사람을 거치게 할 필요는 없다.

결국 내가 확인하고 싶었던 것은 두 가지였다.
- 내가 직접 판단해도 되는 범위는 어디까지인가
- 다른 담당자나 리더의 결정이 필요한 시점은 언제인가

 

---

 

그래서 팀장님과 이 문제를 이야기했다.

외부에서 직접 요청하는 일이 늘었고, 기술 문의뿐 아니라 대응 방향이나 일정 확인, 내부 조율까지 처리하는 경우가 생기고 있다고 설명했다.
내가 맡은 작업의 구현 가능 여부나 공수는 직접 판단해 결정하고, 대응하는게 맞다고 생각한다. 다만 기획이나 전체 일정에 영향을 주는 내용까지 어디까지 답해도 되는지 기준을 알기 어렵다는 내용으로.

팀장님도 요구사항 관리나 조직 간 일정 조율은 원칙적으로 PM 쪽의 역할에 가까운 게 맞다고 긍정하셨다. 실제 업무에서 역할 사이에 빈틈이 생기는 부분도 알고 계셨고.

다만, 그럼에도 불구하고, 내가 판단할 수 있는 일을 직접 처리하고, 필요한 협의를 하는 것 자체는 괜찮다고 했다.
그러면서, 연차와 직급이 높아질수록, 자연스럽게 이런 일이 늘어난다는 이야기를 해주셨다.

요구사항을 그대로 받아도 되는지, 지금 처리할 일인지, 다른 방식으로 해결할 수 있는지 판단하고, 요청과 조율하는 것.
낮은 연차의 개발자에게 이런 커뮤니케이션을 많이 맡기지 않는 이유도 같았다. 제품과 코드베이스의 맥락을 충분히 파악하지 않으면, 애초에 이런 판단을 제대로 할 수 없기 때문에.

반대로 내가 맡은 영역을 이해하고 판단할 수 있다면, 조금씩 경험해봐도 된다는 이야기였다.
AI가 이미 코드 작성은 대체해버린 상황에서, 앞으로 개발자에게 있어 이런 커뮤니케이션과 결정 역량이 더 중요해질 수 있다는 말씀도 하셨다.

그래서 농담처럼, 언젠가 해야 할 일이 조금 빨리 온 거네요. 라고 했는데ㅋㅋㅋ 팀장님도 그렇다고 했다.

 

---

 

또 의외였던 것은, 팀장님이 내가 하는 논의와 업무를 이미 상당 부분 보고 있었다는 점이었다.
나는 여태 별다른 말씀이 없어서, 그리고 작업 전중후로 공유 드려도 그냥 확인했다는 이모지만 달고 마셔서ㅋㅋㅋ 어디까지 알고 계신지 확신하지 못했다.
내가 알아서 처리하고 있으니 그냥 넘어가는 건가... 싶기도.

그런데 내가 외부와 어떤 건을 조율하는지, 내가 어떤 판단을 하고 있는지 대부분 보고 있었고, 특별히 문제가 없어 보여 개입하지 않았다고 말씀하셨다.

내가 직접 판단하고 조율해보고 싶어 하는 것도 알고 있었다.
판단에 문제가 있어 보이거나, 사업적인 결정이 필요하면 개입할 생각이었고, 내가 애매하다고 느끼는 순간에는 언제든 태그해도 된다고 했다.
이전에도, 개인 면담에서, 신생 팀이다보니 책임 소재가 필요한 것들은 전부 이름 대면 해결해줄테니까, 하고싶은대로 할 수 있는걸 다 해 보라고 하시기도 했고.

별말이 없었던 건 문제가 없었기 때문입니다. 지금 잘 하고 있어요.
라고 직접 들으니 뭔가 인정받은 것 같아서 기쁘기도 했고, 상황을 정리할 수 있었다.

내가 직접 처리하는 범위가 어느 정도 허용되어 있었고, 필요할 때 도움을 요청할 수 있는 상태였다. 다만 그 기준을 내가 확실히 모르고 있어서 혼자 전전긍긍 하고 있었던 것.

 

---

 

그리고 면담에서 가장 실용적이었던 조언은 따로 있었다.
어떤 일이 들어왔을 때, ‘내 업무인가 아닌가’만으로 판단하지 않고, 회사나 팀에 주는 효과와, 내가 처리하는 비용을 같이 보라는 것.

예를 들어,
다른 팀에서는 꼭 필요한 정보인데 내가 몇 분만 쓰면 답할 수 있다면, 빠르게 처리하는 편이 낫다.
내가 짧게 답해서 다른 사람의 작업이 바로 진행될 수 있다면 충분히 가치가 있다. 역할을 확인하는 데 더 많은 시간을 쓸 필요도 없다.
그럴 때는 해결해주고, 내가 기여한 부분도 자연스럽게 드러내면 된다.

반대로, 효과는 크지 않은데 내가 들여야 할 비용이 크다면 그대로 받아들일 이유가 없다.
몇 주짜리 개발이 필요하거나, 중요한 작업을 미뤄야 하거나, 여러 조직을 계속 찾아다니며 조율해야 한다면 그 비용을 설명해야 한다. 필요하면 우선순위를 다시 정하거나 거절할 수도 있어야 한다.
이때의 비용에는 작업 시간뿐 아니라, 진행하던 일을 멈추고 스위칭하는 비용도 포함.

결국 요청을 받았을 때는 이런 것을 같이 봐야 한다.

• 이 일을 처리하면 회사나 팀에 어떤 효과가 있는가
• 내가 쓰는 시간과 놓치는 다른 일은 얼마나 되는가
• 내가 직접 처리하면 전체 진행이 얼마나 빨라지는가
• 다른 담당자의 판단이나 조율이 필요한가
• 내가 얻을 수 있는 경험은 무엇인가

 

 

한 가지 구분해야 할 점.

판단과 조율을 경험하는 것과, 모든 질문을 대신 전달하는 사람이 되는 것은 다르다.
질문이 올 때마다 다른 팀을 찾아가고, 답을 받아 돌아오고, 추가 질문이 생기면 다시 찾아가는 일이 반복된다면 그건 결국 소모만 될 뿐이다. 받아들이지 않아야 하는 영역.
그 과정에서 내가 판단은 필요하지 않은데, 시간만 계속 쓰게 될 수도 있다.

그래서 앞으로 잡을 기준

• 기술적으로 내가 판단할 수 있고, 적은 비용으로 진행을 앞당길 수 있는 일은 직접 처리(원래하던거)
• 내가 맡은 영역의 구현 가능 여부와 공수는 직접 판단(원래하던거)
• 기획 방향이나 여러 팀의 일정을 확정해야 하는 일은 담당자와 함께 결정(원래하던거)
• 사업적인 판단이 필요하거나 내 권한이 애매한 일은 팀장님에게 올린다(원래하던거)
• 단순 전달이 반복되는 일은 관련 담당자들이 직접 논의할 수 있도록 연결(NEW)

내가 답할 수 있는 부분은 답하고, 다른 사람의 결정이 필요한 부분은 그 자리에서 구분해주는 게 맞을 것 같다.

 

---

정리

이번 일을 겪으면서 개발 업무의 범위를 조금 다시 생각하게 됐다.
내 업무 영역이 아닌 일이 계속 들어오는 것처럼 느꼈고, 직접 판단해볼 수 있는 범위와 도움을 요청해야 하는 기준을 설정했다.

그렇다고 커뮤니케이션이 갑자기 덜 번거로워진 것은 아니다. 실제로 비용이 큰 요청은 앞으로도 조정해야 한다.
내가 처리해서 진행을 앞당길 수 있는 일은 처리하고, 다른 사람의 결정이 필요한 일은 적절한 담당자에게 연결한다. 비용이 너무 크면 그 이유를 설명한다.

일을 맡으면서 판단할 수 있는 범위를 넓히되, 어디서 도움을 요청해야 하는지도 같이 익혀가는 쪽으로.
그게 앞으로 더 좋은 개발자가 되기 위한 과정이라면야.

내가 처음 일을 시작했을 때(그때는 개발자가 아니었지만) 세웠던 기준, 같이 일하고 싶은 사람이 되자. 계속 발전 중.