[Start up] 스타트업 개발자의 허심탄회한 이야기 (우선순위)

10. 무엇을 먼저 개발해야 할까요?

초기 스타트업의 특징 중 가장 큰 부분은 아직 체계가 잡혀있지 않다는 점이다. 이 부분은 매우 큰 장점이자 단점으로 작용할 수 있는 데, 장점은 체계가 없으므로 모두가 자유롭게 자신의 능력을 펼칠 수 있다는 점이고, 단점은 업무의 비효율성이 증가할 수 있다는 점이다.

모든 스타트업들, 더 나아가서 모든 기업들이 모두 같은 기업 문화를 가지고 있지 않다는 사실은 자명한 사실이다. 그 이유는 각 기업들이 성장하면서 자신들에게 맞는 최적의 방법으로 체계를 확립해나갔기 때문이라고 필자는 생각한다.

그렇다면 이 체계를 만들어가는 것은 얼마나 중요할까?

나는 개발자이기 때문에 모두의 관점으로 바라볼 순 없으나 초기 스타트업부터의 경험을 토대로 글을 작성해보겠다.

내가 경험한 가장 큰 문제점은 모두가 개발자에게 무엇을 우선순위 없이 요구한다는 것이다. 이는 개발자에게는 참 난감한 상황이다. 모두가 자신이 제시한 의견이 중요하고 빠르게 실행됐으면 좋겠다고 생각하지만 실제로 개발할 수 있는 인원은 적은 게 현실이다.

우선순위가 정해지지 않은 상태에서 개발자들은 A라는 업무를 하는 도중 B라는 업무를 하다가 다시 A라는 업무를 하다가 C라는 업무를 하는 경우가 생긴다. (경험담이다...) 이는 개발자들에게 단지 지금하는 일을 멈췄다가 다시 시작하는 것을 넘어서서 매우 불편한 일이다.

---

[여기서 잠깐👋🏻] Context Switching 이란? (비개발자용)

• 책을 읽다가 책갈피를 꽂아놓고 시간이 지난 후 다시 읽을 때, 지난 내용들의 흐름을 다시 이해하기 위해 조금 전 글 혹은 조금 전 페이지로 돌아가서 다시 읽기 시작했던 경험 다들 있으시죠?
• 코딩에서도 마찬가지로 해당 기능을 완전히 개발하지 않고, 마무리 짓지 못한 채로 놔두게 되면 완전히 개발했을 때보다 오히려 코드를 다시 이해하는 시간이 오래 걸려 유지 보수 혹은 기능 개발 시간이 길어지는 오버헤드가 발생하게 됩니다.

---

개발적인 용어를 쓰자면 'Context Switching'이 너무 자주 발생하게 되면 이는 업무의 부하를 일으켜 속도가 느려지게 된다. 물론, 할 일을 세분화하고 커밋을 잘게 쪼갠다면 이 부분도 어느 정도 해소할 수는 있지만, 하던 일을 마무리짓지 않고 다른 일을 하다가 다시 돌아오는 일은 최소화시키는 것이 중요하다.

이를 해결하기 위해 다른 기업들에서는 pm이 우선순위를 선정한다. 우리도 이런 문제점 해결을 위해 Jira를 사용한 우선순위 정하기를 시작했다. (물론, 후에 Trello로 변경했지만 이는 뒤에서 이야기해보도록 하자.)

11. 아... 또 바뀌었나요?

다른 개발자들은 어떨지 모르겠지만... 이 부분에 대한 생각은 모두 비슷할거라 생각한다. 개발하는 도중 기획 또는 디자인이 변경되는 경우는 모두가 싫어할거라고 생각한다.

이런 문제들은 여러 가지 이유로 생겨날 수 있다.

1. 기획에 고려하지 못한 부분이 존재할 때
2. 디자인이 기존과 일관적이지 않을 때
3. 개발적으로 불가능하거나 더 좋은 방법이 존재할 때
4. 개발 전까지는 잘 될거라 예상했지만 시장이 급변했을 때
5. 기타 등등...

외부적인 요인으로 어쩔 수 없이 변하게 된 기획들은 어쩔 수 없다는 것을 모두가 알고 있다. 하지만 내부적인 요인으로 혹은 실수로 인해서 개발 중간에 무언가 바뀌는 것은 생각보다 큰 문제를 야기할 수 있다.

유지 보수 혹은 기능 개선 등의 기획들은 이미 짜여진 틀 안에서 이루어지는 경우가 많지만, 여러 가지를 시도해보는 스타트업에서는 신규 기능에 대한 기획이 많다. 이러한 경우 신규 기능을 개발하기 위해 개발자들은 전체 구조를 짜고 개발을 시작한다. 어떤 경우는 구조를 짜는 데 더 오랜 시간이 들기도 한다. 더 좋은 구조는 없는 지, 확장 가능한 구조인지 등등 상황에 따라 고려할 점이 조금씩은 달라지지만 대부분 큰 틀을 잡는 작업을 진행한다.

기획이 바뀌는 부분에 따라 다르긴 하지만 어떤 경우는 구조 자체가 변경되는 경우가 생긴다. 이러한 경우는 생각보다 큰 타격이 생긴다... 대부분 기한이 정해져 있는 상태인데 변경사항을 적용해도 기한은 늘어나지 않거나 며칠 정도 늘어나는 경우가 대부분이다.(회사의 일정은 크게 변할 수 없기 때문에)

그때부터 개발자들의 지옥의 야근이 시작되는 것이다.

우리는 이러한 점을 해결하기 위해 개발 전 회의를 여러 번 잡는 방법을 선택했다.

1. 미리 기획자가 기획 파일들을 디자이너와 개발자에게 공유한다.
2. 디자이너는 와이어 프레임을 준비하고, 개발자들은 해당 기능 개발에 필요한 기술들을 찾아보고 선택한다.
3. 기획자, 디자이너, 개발자가 회의를 진행한다.
4. 개선 사항을 서로 공유한다.
5. 기획이 변경된 경우 위의 1~4를 반복한다.
6. 기획이 완성된다.

이러한 진행으로 개발 도중 기획, 디자인 변경을 최소화했고, 이는 생각보다 많은 효율을 가져왔다. 가까이서보면 비극, 멀리서보면 희극이라는 말이 있듯이 '이걸 왜 처음부터 안했지?'라고 생각하시는 분들이 많을 수 있다고 생각한다. 하지만 정말 서로 바쁜 상황에서 체계가 잡혀있지 않다보면 시간을 두고 개선 방향을 잡기가 쉽지만은 않다. 다른 분들은 여러 가지 상황에 미리 대비할 수 있는 현명한 사람이 됐으면 한다.

다음 이야기

언제 그렇게 정해졌다고요...? 라는 질문으로 다음 이야기를 이어가보자.