본문으로 건너뛰기

일을 만드는 시간

· 약 9분
Minhyeok Kang
Product Engineer @ flex

처음 개발자 커리어를 시작했을 때, 데일리 스크럼에서 누군가가 "어제는 회의가 너무 많아서, 일 할 시간이 없었습니다." 라고 자신의 일의 진행상황을 팀에 공유했다. 그 워딩 자체를 듣고 바로 들었던 생각은 "회의는 일이 아닌가?" 라는 생각이었다.

물론 그가 이야기하는 말의 의도는 충분히 이해가 된다. 그는 "해야할 일이 명확하게 정해진 Task가 주어져있고, 회의가 많다보니 이 Task들을 수행할 물리적인 시간 자체가 부족했다는 뜻"으로 그렇게 말했을 것이라 짐작해볼 수 있다. 이렇게 이해하면 무엇을 이야기하고 싶었는지 충분히 이해할 수 있었다.

특히 개발자의 경우는 보통은 주어진 스펙을 '구현'하는게 가장 메인이 되는 일이라서, '구현' 과 '일'을 동치하는 경향이 있을 수 있다.

그런데 한편으로는 나는 위 상황을 표현하는 워딩에서 스치듯 무엇인가 불편함을 느끼고 있었다. 내가 느꼈던 불편함은, 스크럼에서 자신의 진행상황을 공유하던 누군가가 마감기한내에 Task를 끝내지 못해서는 아니었다. 그게 어떤 불편함인지 알기까지는 생각보다 오랜 시간이 필요했다.

시간이 꽤 지나고 돌아봤을 때, 내가 느꼈던 그 찝찝한 불편함은 회의를 대하는 그의 관점이었던 것 같다. 회의 때문에 자신이 Task를 수행해야하는 시간을 '빼앗겼고', 이 때문에 '일을 할 시간이 없었다'는 표현으로써 그의 관점이 드러났다고 생각했다. 그가 만약 "회의가 많았고 이 때문에 주어진 Task를 수행할 시간이 부족했습니다." 라고 팩트만 전달했다면, 크게 불편함은 없었을 것 같았다.

나를 불편하게 하는 트리거를 발견하고서는, 나는 '왜 그의 관점이 나에게 있어서 불편함을 느끼게 했을까?' 라는 식으로 생각을 이어나가봤다. 그 사유의 과정을 거치며 하나의 이정표로서, 일에 대한 어떤 개념 하나를 내 나름대로 정리해보려고 한다.

일을 만들어나가는 시간

내가 일하는 곳에서는 '스펙 문서'의 형태로 해야할 일이 정의된다. 보통 개발자들은 여기서 '스펙'이라 불리는 요소들을 '구현'한다.

그럼 이 스펙은 어떻게 만들어지는가?

스펙 문서는 PO(Product Owner)와 PD(Product Designer)가 작성한다. 개발자들은 Kick-off 미팅에서 이 스펙 문서와 피그마로 작성된 화면을 전달받으면서 스펙에 대해 설명을 듣는다. 그리고 그것을 구현한다.

이게 전부면 일이 참 쉽겠다. 위 플로우에는 몇가지 단계들이 생략되어있다.

이 스펙 문서의 최초의 시작은 어디서 오는가를 먼저 생각해보자. 제품에서 쏟아져나오는 데이터로부터 제품의 문제를 찾을 수도 있고, 사업팀의 요구사항에서 시작된 기능일 수도 있다. 그리고 단순히 어떤 아이디어에서 출발한 신기능이 스펙 문서에 담기기도 한다.

여기서 알게모르게 개발자들은 이런저런 요구사항을 받고 이 과정에 참여하게 된다. 문제를 정의하기 위해 필요한 지표 데이터가 적절히 수집되고 있는지, 만약 그렇지 않다면 해당 지표 데이터를 수집할 수 있도록 지원해야한다.

또, 사업팀의 요구사항이 실제로 구현 가능한 레벨인지 아닌지, 만약 가능하다면 얼마나 공수가 들어가는지에 대한 개발자의 의견을 전달해야한다. 보통 이때는 작업의 크기에 따라서 진행 여부와 우선순위가 결정되는 경우도 많아서, 대략적으로라도 실제와 거의 유사한 예상 소요시간을 전달해주어야 한다. 아니면, 더 좋은 방법이 생각이 나서 역으로 다른 솔루션을 제안해볼 수도 있다.

그다음은 어찌됐건 그 일을 '하겠다'라고 결정을 했다면, 어떻게 할지에 대한 고민이 시작된다. 마찬가지로 여기서도 개발자들은 디자이너에게 질문을 받기도, 하기도 하면서 무엇을 어떻게 구현해야할지에 대한 세부 내용을 구체화해나간다. 그리고 이렇게 구체화된 '스펙'을 여러 플랫폼의 개발자들끼리의 논의를 거쳐서 API를 정의한다.

보통 위 단계를 거쳐서, 이제부터는 실질적으로 코드를 짜는 '일'이 시작된다. 나는 이렇게 코드를 짜기 전까지의 단계들을 '일을 만드는 시간'이라고 스스로 정의했다.

나는 이렇게 일을 만드는 시간을 밀도있게 활용해야 한다고 생각한다. 한번 구체화가 끝나서 일에 들어간 순간부터는 어떤 변경사항이 발생했을 때, 그에 대한 코스트가 일을 만드는 단계에서보다 훨씬 커진다. 그리고 경험상 잘 만든 일은, 중간에 변경이 적고 일의 목표가 명확한 편이다. 그래서 빠르고 정확하게 수행할 수 있고, 성과도 좋다.

그래서 일을 만들어나가는 시간에 나는 개발자로서 할 수 있는 최선을 다하려 노력한다.

요즘 AI가 발전하면서 개발자가 직접 코드를 타이핑하는 시간은 점점 줄어들고 있다. 만약 개발자의 일이 단순히 코드를 짜는 것 뿐이라면, 이 직업은 수명이 얼마남지 않음이 확실하다. 그런데 나는 코드를 짜는 것은 개발자의 업무 중 일부에 불과하다고 본다. 오히려 앞으로는 코드를 짜는 것보다 더 중요한 일들을 잘할 수 있어야 하지 않을까 싶다.