지원서와 공고의 과정 순서를 관리하는 효율적인 방법❗️

[Seongwon97]

지원 공고/지원서 별 진행과정의 순서를 관리하는 것은 우리 서비스에서 풀어나가야 할 가장 중요한 과제 중 하나라 생각합니다.

해당 기능에서 발생할 수 있는 요구사항을 정리하고 방법을 생각해봤습니다.

요구사항

1. 데이터베이스로는 RDB를 사용한다.
2. 채용 과정은 0개 이상이 존재한다.
3. 채용 과정은 중간에 추가될 수도 삭제될 수도 있다.

🌧 기존의 방법

기존의 방법은 Order를 Auto_increment 방식으로 연속된 수의 값을 사용했습니다.

예를 들어 서류, 코테, 1차면접, 2차 면접 과정을 등록할 경우, 각각의 과정이 갖는 순서(order)는 1,2,3,4가 됩니다.

하지만 이러한 방법의 경우, 요구사항 3번인 채용 과정의 추가,삭제로부터 유연하지 못하게 됩니다.

예를 들어 코테와 1차면접 사이에 새로운 과정이 추가될 경우 1차면접 이후 과정의 order는 모두 업데이트 되어야하는 문제가 있습니다.

☀️ 생각한 방법

해당 방법의 핵심은 위와 같이 3번 과정이 발생하였을 때, 과정이 갖는 Order 데이터의 업데이트를 하는 과정을 최소화하는 방법입니다.

방법은 Order값을 Auto_increment의 방법으로 1,2,3,4,5와 같은 값을 주는 것이 아닌 100정도의 Gap을 주어 Order를 할당하는 방법입니다. 그리고 과정 사이에 새로운 과정을 추가할 경우, 각 과정의 Order사이의 중간 값을 할당하는 것입니다. 예를 들어 두번째, 세번째 과정 사이에 과정을 추가할 경우 200~300사이의 중간 값인 250을 할당해주는 것입니다.

즉, 200~300사이에 넣었다면 250, 225, 212, 206, 203, 201 등의 순서로 Order를 할당해주는 것입니다. 해당 예시는 최악의 예시로 기존의 과정과 새로 만든 과정 사이에 과정을 추가했을 때의 예시이고 새로 만들어진 과정들 사이에 추가를 하게 된다면 250과 300사이, 225와 250사이 등 각각의 Gap사이에 새로운 order를 할당할 수 있습니다.

만약 이러한 과정들을 거치면서도 할당할 order가 부족하다면 그때 전반적인 order 재할당을 해주면 될 것으로 생각됩니다. (100단위의 Gap을 갖도록)

Current Process는 어떻게?

CurrentProcess도 해당 방법을 사용하면 해결할 수 있을 것이라 생가됩니다.

기존 방법의 경우 중간에 process가 추가되었을 때, currentProcess의 값에도 영향을 줄 수 있다는 문제가 있었습니다.

하지만 해당 방법을 사용할 경우 각각의 Process가 갖는 order값을 currentProcess가 갖도록 하면 문제는 어느정도 해결할 수 있을 것이라 생각됩니다.

[shindong96]

좋은 방법인거 같아요! 예전에 학교에서 알고리즘같은 과목을 수강할 때 들어봤던거 같기도 하구요! order 재할당쪽을 고려해봐야겠네요 👍

그런데 저는 여기서 한 가지 드는 생각이 있습니다. 저희가 LinkedList와 ArrayList를 고민할 때 ArrayList를 선택했던 이유는 서비스 사용자들이 기존에 있던 전형의 중간에 전형을 추가하기 보다 기존 전형을 따라가거나 뒷 쪽에 추가해가며 서비스를 사용할 상황이 많을 것이라는 생각 떄문이었습니다.
따라서 저는 칸반 보드끼리의 순서를 정하고 각 보드내에서는 뒷쪽에만 전형을 추가해나갈 수 있는 정책적인 방법으로도 해결할 수 있지 않을까 싶은 생각이 듭니다 .

예를 들어, 칸반에서 서류전형'과 면접 전형에 하나씩 있었다고 하였을때 만약 다른 보드인 과제 및 테스트로 drag앤 drop을 한다면 새로만드는 전형의 순서를 지정할 수 없다는 문젠 여전히 존재하게 됩니다. 물론 사용자에게 순서를 지정하게 하는 과정을 시나리오에 넣으면 되지만 그렇게 된다면 서비스를 간편하게 사용할 수 없게 될 것 같습니다.

order사이의 간격을 넓혀서 추가에 좀 더 용이하게 하는 방법으로는 너무 좋아요! 정책적인 부분이 끝난다면 충분히 사용할 수 있을 거 같습니다.

[Seongwon97]

• "만약 다른 보드인 과제 및 테스트로 drag앤 drop을 한다면 새로만드는 전형의 순서를 지정할 수 없다는 문젠 여전히 존재하게 됩니다."
  • 예시로 주신 문제가 발생하는 이유에 대해 이해하지 못하겠습니다.. 예시로 주신 내용에서 서류전형이 order 100을 부여받고 면접 전형이 200을 부여받았다면 과제 및 테스트 과정에 새로 추가되는 것은 중간 값인 250이 할당받으면 전형 순서가 해결되지 않을까요? 혹시 언급해주신 예시에서 제가 잘못 이해한 부분이 있을까요..??
  • 전형별 순서 또한 각 과정별로 order값의 순서로 정렬하면 해결할 수 있지 않을까 합니다.
• "용자에게 순서를 지정하게 하는 과정을 시나리오에 넣으면 되지만 그렇게 된다면 서비스를 간편하게 사용할 수 없게 될 것 같습니다."
  • 사용자가 순서를 지정하는 것이 서비스의 편의성을 저해한다는 것 또한 개인적으로는 다른 생각을 갖고 있습니다. 우선 일전에 제안해주신 내용 또한 순서를 없애는 것이 아니라 전체 순서를 과정 유형별 순서로 제한하자는 것이었습니다. 지정해야하는 범위가 제한된 범위인지 전반적인 범위인지의 차이일 뿐이라면 전형 과정이 아무리 많아도 10개 이하인 지원 도메인 특성상 서비스의 간편성이 향상된다고 생각되지는 않습니다ㅠ 오히려 사용자의 자유도를 제한하는게 아닐까?하는 생각이 드는 것 같습니다.

아직 정책적인 부분에서 채용 과정 유형(ProcessType) 순서를 우리가 정해둔 대로 고정해둘지, 아닐지에 대해 확실히 정해지지 않았지만 빠른 시일내에 정했으면 좋겠습니다..!

[kyukong]

전 매우 좋다고 생각합니다! 순서가 있는 데이터를 다룰 때엔 어쩔 수 없이 순서 정보를 직접 관리해야 하는 상황이 오는것 같습니다ㅠ

다만, 동석님의 의견도 좋은 관점이라고 생각합니다. 칸반에서도 왼쪽에서 오른쪽으로 대단위 전형들의 순서가 고정되어 있기 때문에 지원서 상세 페이지에서만 순서가 자유롭다면 오히려 혼란스러울거라고 생각합니다.

따라서 저는 동석님의 의견 또는 동석님 의견 + 성원님 의견을 통합하면 어떨까 합니다.

1. 대단위 전형 고정 + 세부 전형의 마지막에만 추가 가능
2. 대단위 전형 고정 + 세부 전형 순서의 갭을 두어, 자유롭게 추가 가능

[Byeongju-Kong]

order의 값을 0 -> 1 -> 2 -> 3가 아닌 0 -> 10 -> 20 -> 30 등의 범위로 잡아가는 것은 좋은 것 같네요! Process가 순서들이 변경되었을 때, update를 최소화할 수 있는 장점이 있는 것 같습니다~!

저도 개인적으로 전형의 마지막에만 과정을 추가하는 것이 좋을 것 같아요!
중간에도 넣을 수 있다고 가정하면, 추가 할 내용 + 어디에 넣을지 까지 한 플로우에 사용자가 결정을 해야하는데,
그것보다는 2개의 플로우로 나누는게 낫지 않을까? 라는 UX(?) 측면에서의 개인적인 생각입니다! 물론, API가 두 개로 나눠지긴 해야하지만요!
그렇다면 새로운 전형 추가 + 전형 간의 순서 변경 의 두 개의 행위로 나눌 텐데, 전형 간의 순서 변경의 UI, UX가 편하게 나와야할 것 같긴하네요..! 예를 들어, 드래그만으로 순서를 수정할 수 있는 등의 방식으로요!

사실 이건, 개발보다는 정책/기획적인 이야기고 개인 차이라고 생각을 해서요! 프론트, 디자이너 팀원들과 함께 이야기 해보는게 좋을 것 같아요!