개발자를 존중하는 회사 (feat. 역할별 책임)

흔히들 말한다. "우리는 개발자를 존중합니다. (그러니 오세요.)"

나는 개발자를 존중하는 회사에서 일하고 싶다. 사실 기획자든, PM이든, 디자이너든지 본인의 역할과 그에 따른 책임이 존중되는 회사에서 일하고 싶은 것은 당연하다.

서비스는 다양한 역할의 사람들이 협력을 하며 만들어지는 것이다.

서비스를 만들어가는 과정에서 각 역할은 모든 과정에 참여한다. 단지 각 역할의 책임이 다르기 때문에 서비스를 만들어가는 단계에 따라 역할별 중요성이 크고 작다는 차이가 있을 뿐이다.

각 역할을 존중한다는 것은 각자의 책임을 수행하기 위해 주도적으로 의견을 냈을 때, 그것을 긍정적으로 검토하되 그에 대한 사이드 이팩트, 혹은 추가로 고려해야 할 사항에 대해 논의하는 것이라고 생각한다.

즉, 모두 본인의 책임과 다른 역할들의 책임에 대해 이해를 하고 있어야한다.

그렇다면 개발자의 책임은 과연 무엇일까! 서비스 구현 과정에서 개발자의 책임에 대해 알아보도록 하겠다.

---

서비스 구현하는 과정

어떤 서비스를 만들기 위해 프로젝트가 아래와 같은 작업을 반복한다. 과정은 조금씩 다를 수 있다.

• 기획

    - 요구사항 정의
    - 요구사항 우선순위 정의
    - 작업 완료 예정일(프로젝트 기한) 설정

• 디자인

• 개발

    - 설계
    - 개발
    - 단위테스트

• 통합 테스트

• 배포 및 운영

서비스 구현에서 개발자의 책임

• 작업의 소요 시간을 산정 (= 설계)

    요구사항이나 요구사항별 우선순위는 기획자(혹은 PM)이 정하는 것이다.
    하지만 요구사항의 우선순의를 정하기 위해서는 각 요구사항별로 '작업 시간'을 알아야한다.
    작업의 소요 시간은 개발자만 알 수 있는데, 이걸을 파악하는 과정 자체가 시스템을 분석하고 설계를 하는 것과 다름이 없다.
    개발자가 소요 시간을 바로 말해주는 경우는 과거에 비슷한 경험을 했기 때문이다.
  
    아마 아래 부분에서 기획자(혹은 PM)과 오해가 많이 생기지 않나 싶다.
    - 새로운 기능이라 고려해야하는 사항이 무엇인지 모르기 때문에 자료조사부터 해야하는 경우
  
    - 비슷한 기능인데도 소요시간을 모르겠다고 하는 경우
    기획자 입장에서는 비슷한 기능인데도, 시스템 내부 로직은 완전 다를 수 있다
  
    - 개발자가 말했던 소요시간을 지키지 못하는 경우 (이 이유는 여러가지다)
    1. 개발자 능력 부족. 본인이 그 기간 내에 할 수 있을 것이라 생각
    2. 요구사항이 명확하지 않아 작업 소요 시간을 도출을 정확하게 하지 못함(아래 설계 설명 참고)
    '회원 탈퇴 기능을 만들어줘'와
    '회원 탈퇴 시 재가입은 14일 내에 가능, 탈퇴한 로그인ID는 재사용 불가능, 탈퇴 회원 정보는 5년 보관해줘'는 다르다.
  
    예를 들어 개발자가 재가입이 불가능할 것이라고 가정하고 기능 구현을 했는데
    뒤늦게 새로운 세부사항들이 생긴다면 DB 설계부터 다시 해야 한다. 
    물론 처음 했던 것 만큼 시간이 걸리지 않지만, 처음부터 설계를 해야한다는 것은 변함 없다...
    DB설계 다시 한다는 건 논문 목차의 순서와 제목을 수정한 후,
    각 제목에 맞게 내용을 변경하는 작업이나 다름없다.
    이미 토대가 있으니 새로 작성하는 것 만큼 오래 걸리지는 않지만,
    더 꼼꼼히 확인하고 어디 빠트린 게 없는지 점검해야한다.

• 설계 (대화 그리고 대화)

    이 단계에서 개발자는 주어진 요구사항의 진정한 목적을 파악하고,
    해당 요구사항을 시스템에 반영이 가능하기 위해 필요한 추가적인 요건들을 의사결정자에게 요청한다.
    의사결정자와 많은 대화를 통해 개발자는 요구사항을 이해하고 시스템에 반영할 수 있도록 논리적으로 구체화하는 단계이다.
  
    예를 들어, '회원을 탈퇴하는 기능'을 만들라고 했을 때
    개발자에게는 아래와 같은 것들을 의사결정자에게 다시 질문해야한다.
    최초 요구사항이 명확할 수록 개발 기간이 짧아지고 재개발을 해야하는 불상사가 줄어들기 때문에 개발자는 설계에 많은 신경을 쏟는다.
    - 회원 탈퇴 후 동일한 ID로 재가입은 가능한지?
    - 재가입이 가능할 경우 기한은 얼마나 둘 지? (14일 내 탈퇴 취소 시 동일 ID 사용 가능)
    - 회원 탈퇴 후 개인 정보는 몇 년을 보관하는지?

• 비즈니스 요구사항 개발

    회원 관리, 결제 등과 같은 비즈니스 요구사항을 시스템으로 구현한다.
    개발 과정에서 요구사항이 생각했보다 기능의 기술적 복잡도가 높거나
    생각보다 시간을 많이 투자해야하는 경우에는
    혹시 정책으로 해결이 가능한 지(요구사항을 조금 변경해도 되는 지) 의사결정자에게 물어볼 수 있다.
  
    - 기술적으로 풀기에는 복잡도가 높은 경우
    음 지금 생각이 나지 않는데 정책으로 푸는 것이 오히려 사용자의 편의와 시스템 복잡도를 낮출 때가 있다.
  
    - 시간이 부족한 경우
    서버 개발자인 '김개발자'는 관리자 웹을 만들기 위해 리액트를 공부하며 개발을 하게 됐다.
    요구사항은 명확하다고 가정하겠다.
    기획자 : 게시판의 카테고리를 관리할 수 있는 기능을 만들어주세요.
    개발자 : 넵, 반나절이면 되겠네요!
    기획자 : 카테고리는 드래그&드롭으로 순서도 바꾸고 하위 카테고리도 변경할 수 있게 가능할까요?
    개발자 : 아... 제가 리액트는 처음이라 감은 안잡히지만 2-3일 정도면 울면서 공부하면 개발할 수 있을 것도 같은데...
    정말정말 관리자 웹에 드래그&드롭이 필요할까요?
    기획자 : 그렇게 중요한 부분은 아니니 편한 대로 해주세요.
  

• 시스템이 존재하기 위해 필요한 것들을 개발 (로그, 캐싱 등)

    생각보다 비즈니스 요구사항을 구현하는 것 이외에 것들을 개발하는 데에 시간이 많이 든다.
    특히 신규 프로젝트일 때 그렇다.
    이런 것들은 타 역할의 사람들이 보기에는 숨겨진 업무이기 때문에, JIRA 등 업무 일정을 관리하는 곳에 명시적으로 표현하자.

• 시스템 운영에 필요한 문서를 작성 (API 설계서, 서버별 적용된 기술 등)

• 구현된 시스템이 요구사항을 모두 충족하는 지 테스트

• 이것저것...

존중하고, 존중 받으면서 일하기

개발자 입장에서 글을 쓰기는 했지만, 회사에서 누군가를 존중한다는 것은 그 사람의 역할을 이해하고, 본인이 맡은 책임을 성실하게 수행한다고 신뢰하는 것이라고 생각한다.

나도 동료들의 책임을 이해하고 싶고, 개발자의 책임을 이해하는 동료들과 함께 일하고 싶다.