<aside> 💡

Refs By Toss Slash 사견이 포함되어있으며 상황은 마다 다른 해결책이 존재 할 수 있습니다.

</aside>

• 토스는 업무 효율성 향상을 위한 별도의 백오피스 개발팀이 존재합니다.

  • 딥노이드는 현재 그러한 팀이 별도로 존재하지않고 다양한 협업 요청이 자주 들어오는 상태 입니다.
  • 그럼 우리는 어떻게 기존의 개발을 수행하면서 이러한 업무를 지원 할 수 있을까요?

• 요구사항의 구체화

  • 부서마다 다양한 요구사항이 있지만 요약하자면 다음과 같은 사항으로 조율 됩니다.
    • 데이터 추출, 정제, 관리 | 기존 시스템을 활용한 과제 → 프로토 타입 개발
  • 현재는 요구사항이 들어올때 마다 개별적으로 요구사항을 수행 하고 있습니다.
  • 이런 상황이 지속되면 어떻게 될까요?

• 개발 리소스가 분산되고 요구사항 마다 중복된 기능을 재개발 하는경우가 발생하는등의 리소스 소모가 늘어납니다.

  

• 만약 요구사항을 안들어 주면 어떻게 될까요?

  • 단기적으로는 편해지겠지만 장기적으로는 제품 고도화의 어려움 타 팀의 협조의 어려움 등이 수반 될 것입니다. [기존에 수행 해 주던것을 안한다고 선언했기 때문에]

• 그럼 요구사항을 계속 들어주면 어떻게 될까요?

  • 단기적으로는 힘들겠지만 장기적으로는 원활한 팀간의 협조와 사내에서 의존도가 높아지면서 주도적으로 업무를 수행 할수 있게됩니다. [더 편하고 원하는걸 유도 할 수있죠]

• 시작은 가볍게.

  • 자 요구사항을 들어준다고 가정합시다 매번 요청시마다 개별적으로 시간을 빼서 개발하는게 힘들것 같지만 우리가 이걸 플랫폼화 하고 하나의 코어로 만들어서 관리를 위임한다면 우리는 더욱 수준 높은 제품과 높은 유지보수성을 쟁취 할 수있습니다.
  • 뭔가 거대한걸 하는것 같지만 실제론 단순합니다 CRUD, 사용자화, 자동화 이 세 개만 해결 해주면 됩니다. 그리고 그걸 비개발자도 템플릿으로 만들게 해주면 됩니다. 즉 초기 기틀만 잡으면 중복되는 부분이 매우 많다는거죠
  • 우리는 이제 물고기를 낚아주는게 아니라 물고기 잡는법을 알려주는겁니다.

• 토스에서는 이러한 패턴을 발견하고 자동화 툴을 조사했으나 문제점이 있어 직접 만들기로 했다고 합니다.

  • 우리도 마찬가지겠죠? ㅎ.. (유료)
  • 주도적인 업무
    • 정: 원하는 대로 업무를 진행할수 있다
    • 건: 스스로 결정할수 있는, 스스로 진행할수 있는
    • 헌: 사용자의 니즈를 파악하고 만족시켜주는
    • 영: 일정을 지키고 A-Z 부터 스스로 진행 할 수 있는.

• Let’s Do It

  • Step 1. 사용자가 원하는 형태를 보관할수 있는 타입 만들어주기 (CRUD)
    • 사용자 마다 원하는 데이터의 형태가 다를겁니다 기존에는 이를 수작업으로 요청시 마다 만들어주거나, 공통된 테이블을 만들어서 사용했었죠
    • 하지만 동적으로 필드와 여러 값을 입력받아서 테이블을 자동으로 만들거나 문서 기반 데이터베이스를 사용한다면? → 사용자는 직접 데이터 형태를 정의해서 사용할수 있습니다
    • 이는 필요하다면 사용자가 직접 만들수 있다는 말이죠. → 리소스 감소로 이어집니다.
  • Step 2. 기본 템플릿을 만들어 선택하게 하기 (사용자화)
    • 그럼 이제 사용자가 원하는 데이터 형태를 만들었다면 이를 표현하는 형태만 제공하면 됩니다.
    • 이는 기본 형태를 만들어두고 필요 할때 마다 사용자가 선택한걸 조합해 반환하는 방식으로 하면 어떨까요?
    • 우리는 Server Driven UI를 생각 할 수 있네요!
  • Step 3. 자동화
    • 만약 필요한 기능이 있다면 이것도 여러 액션을 미리 정의해두고 선택해 단계별로 실행하게 하면 어떨까요?
    • 마치 객체 지향 같지 않나요!

• How Can We Apply It?

  • 제가 분석해 보았을때 사내에서 높은 요구사항 들은 다음과 같습니다.
    • 프로젝트 일정관리, 데이터 관리, 데이터 추출, 사업 관리
    • 이 키워드들을 보면 다음과 같은 공통점을 찾을수 있습니다 저장하고 공유한다.
    • 이는 업무공유가 잘 되지 않는 이유도 있습니다 ㅎㅎ.. 우리는 서로가 무엇을 하는지 물어보기 전까지는 잘 모르죠
    • 그럼 이런 데이터 들을 서로 편하게 확인 할 수 있고 필요하면 만들수 있게 하면 어떨까요?
  • 여기서 노션과 인터널 프로덕트의 차이가 발생합니다.
    • 노션은 커스텀이 어렵고 러닝 커브가 높습니다 → 사실상 특정 직원들만 쓰고 나머지는 그냥 문서 생성용이죠.
    • 인터널 프로덕트를 개발한다면? 여러가지 기능별 커스텀이 가능합니다.
      • 문서가 수정되면 관련 문서에 내용을 반영한다.
      • 업무 협조 요청이 발신되면 담당 팀 일정에 공유가 된다.
      • A를 하면 B를 실행해야한다.
  • 우리는 개발하고 관리는 사용자가 하게 됨으로써 전체적인 리소스 감소및 편의성 증가로 이어집니다.

• Effect?

  • 이런 생각이 들수 있습니다.
    • 기존에 존재하는 제품을 사용해도 가능한거 아닌가?
      • 물론이죠 당연합니다. 하지만 정보 취합을 위해서는 여러 제품을 돌아다녀야 할것 입니다.
      • 또한 각 팀별로 업무 공유도 새로운 문서를 생성해서 제공 해 드려야겠죠.
    • 결국 개발 하는데 많은 시간이 들거고 이걸 우리가 지속해서 할 수있을까요?
      • 단기간에 완성하자는 의도가 아닙니다. 목표를 달성하기 위한 과정입니다.
      • 하나씩 하나씩 해나가면 결과는 다를겁니다.
    • 사용자가 매번 다른 요청을 하면 어떻게 하나요? 그걸 다 들어주면 제품 개발과 뭐가 다르나요?
      • 엑셀 함수로 생각해볼까요? 우리는 엑셀 함수를 만들어주는겁니다 이를 활용해서 사용자가 어떤 데이터를 정제하고 사용할지는 사용자의 영역인거죠.
  • 그럼 만약 속는셈 치고 일주일에 하루씩 개발해서 이걸 완성하면 어떻게 될까요?
    • 통합된 시스템
      • 하나의 제품으로써의 완성도와 범용성이 높아집니다.
      • 파편화 된 시스템에 복잡해 할 필요 없습니다.
      • 우리는 어드민 기본기능을 제공하고 사용자가 커스텀 할수 있게만 해주면 됩니다.

• 목표 달성을 위해서 아자 아자잇~