Developer 로서 문제정의?

Outline

Software Engineer로서 문제를 어떻게 바라보고, 확장하고, 정의하는지 고민해본다.

 

Contents

문제정의란, 인터넷에 많은 정의가 있지만 결국은 정상적이지 않은 상황을 인지하고, 이를 객관적으로 표현하는 것이다.

그리고, Developer로서 해당 문제를 해결할 수 있는 방법들을 수립하고, 방법을 선택 후 그 방법이 문제를 해결하는데 적합한지 확인해야한다. 그리고 최종적으로는 정상적인 상황으로 해결하는 것이라고 생각한다.

 

문제정의를 하는 방법에 대해서는 모두가 다르다고 생각한다.

회사의 상황(정책, 금전적, 비즈니스 모델)과 조직의 규모 그리고 팀장의 매니징에 대한 관점에 따라서 다를 것이고, 이 문제를 어느 관점에서 해결해야하는 가에 대한 입장에 따라서도 다를 것이다.

 

그러나, 결국의 문제정의와 해결에 있어서 공통되는 부분이 무엇일까 라는 생각을 했다.

• 기업은 수익을 내거나, 비용을 절감 하거나
• 다른 팀과의 협업에 도움이 되는 가?
• 문제 재발 방지 혹은 해당 문제의 감지가 편리해 졌는 가?
• 다른 사람이 정의 한 문제이든, 내가 정의한 문제이든 이 문제가 근본적인 문제인가?
• 이 문제의 목적은?
• 이 문제점을 나만이 인지 가능한 것인가?

위에 적힌 목록에 내가 정의한 문제를 대입해봄으로써 내가 정말 문제정의를 잘 한 것일까? 라는 고민을 해보면 좋을 것 같다. 결국은 문제를 해결함으로써 직접적이든 간접적이든 내가 속한 조직에 대해서 이익을 주거나 비용을 절감하거나 이 2가지의 일이 일어나야하며, 그 관점에서 이 문제가 진짜 문제인지, 아니면 수면 위로 떠오르지 않은 다른 근본적인 문제가 있는지 판단을 해야한다.

 

Developer로서 자칫 개발자의 입장에서만 생각하게 되는 것이 있다. 이게 잘못 된 것은 아니다. 본인의 입장에서 문제를 정의하는 것은 당연하면서도 잘할 수 있는 일이다.

 

예를 들어 다른 부서나 다른 개발자가(혹은 팀내의 개발자라도) "특정 로직이 문제 있는 것 같아요. 스케줄링이 잘 되고 있는지 확인해주세요" 라고 한다면, 말 그대로 "특정 로직의 동작여부 확인" 을 문제로 설정하고, 해당 로직이 스케줄링이 잘 돌고 있는지, 그리고 그 로직을 잘 동작함으로써 생산되는 결과물에 대해서 이상이 없는지 확인 할 것이다. 그리고 이상이 있는지 없는지에 대해서 답변을 할 것이다. (채팅이든, 보고서든)

이건, 어떻게 보면, 이 문제를 해결할 수 있는 이 개발자에게만 국한된 일이면서도, 근본적인 문제 해결이 아닐 수도 있다.

 

이게 다른 부서와 다른 개발자들도 알아서 파악을 해야하는 일이라고 생각 한다면, 문제의 정의는 "다른 사람이 특정 로직이 잘 스케줄링 되고 있는지 확인하지 못하며, 결과물이 이상이 없는지도 파악할 수 있는 방법이 없다"가 될 수 있다.

그러면, 운영 관점에서 필요한 일이라면, 그것을 조회 할 수 있는 방법을 마련해야한다. 그렇게 하면, 특정 개발자의 의존성도 벗어나면서, 앞으로 해당 질문을 하는 다른 부서 사람이나 다른 개발자들도 줄어들거나 없어질 것이다.

 

나의 리소스, 조직의 구성원 모두가 회사의 이익을 위해 움직이는 사람들로서 그 구성원의 리소스가 덜 든다는 것은 결국 회사의 비용을 절감한 것이나 다름 없다.

 

조금의 차이일 수는 있어도, 해야 할 일은 바뀌었다.

 

추가적으로, 해당 요구사항을 해결하기 위해서 How를 고민한다면, 그 Task를 잘게 쪼개보는 방법도 중요하다.

Task가 잘게 쪼개지지 않는 다면, 아직 그 문제를 제대로 인지하지 못하고 있는 것일 수도 있다.