일단 기존 서비스들은 전자결재라는 걸 어떻게 구현했는지를 전체적으로 보시면 좋을 거 같고요.

'전자결재 웹 구현'을 생각하시니까 감이 안 오는 겁니다.
'웹'을 빼고 '전자'를 빼고 생각해 봅시다.

애초에 "결재"라는 건 어떻게 실현하나요?

1. 기안문 양식이 있어야 함.
2. 기안문 양식의 핵심으로서 결재선이 있어야 함. "위 순서대로 임직원들이 도장을 찍기 전까지 이 문서는 무효이다"라는 규약.
3. 그러자면 임직원이 있어야 함.
4. 그리고 각 임직원의 도장이 있어야 함. (서명으로 하면 되지 않나 싶으시겠지만 여기서는 좀 쉽고 단순하게만 생각합시다.)
5. 그리고 임직원이 도장을 찍는다는 게 정확히 뭔지가 규명되어야 함. (도장 그까짓거 찍으면 되지 싶으시겠지만 잠시 기다려 주세요.)
6. 기타 이 기안문에 관한 규약이 정립되어야 함. (처음에 기안 작성은 어떻게 하면 되는지, 결재판을 돌리는 건 누가 어떻게 해야 하는지 등등)
7. 예쁜 결재판을 하나 사와서 정해진 규칙을 준수함. 끝.

이제 여기에 '웹'과 '전자'를 넣어서 생각해 봅시다.

1. 웹에서 기안문 양식은 뭘까? 일종의 DB 테이블 자료일까?
2. 웹에서 구현한 기안문의 결재선은 어떻게 구현될까? 기안문 테이블과 일대다로 JOIN되는 '결재해야 할 임직원 및 순서' 자료들일까?
3. 웹에서 '임직원'을 만들고 관리하려면 어떡해야 할까? 로그인 시스템이 도입돼야 하나?
4. 웹에서 임직원의 '도장'은 무엇일까? 특정 테이블의 approved_at 컬럼에 현재 시각을 입력하는 방식으로 하면 되려나?
5. 웹에서 '임직원이 기안서에 도장을 찍는다'는 건 뭘까? 특정 기안문 자료와 일대다로 JOIN되는 결재승인 이력 자료의 INSERT일까?
6. 웹에서 '기안문 결재판을 돌린다'는 건 뭘까? 특정 기안문이 가진 결재선 자료와 지금까지 INSERT된 결재승인 이력의 비교를 통해서 지금 로그인한 사용자가 하필 다음 결재자일 경우 결재 폼을 보여주는 방식일까?
7. 열심히 상상하고 고민하고 코딩해서 구현하고 이때 기안문 스타일링을 반응형으로 만듦. 끝.

자! 생각을 합시다. 이런 일은 손가락으로 시작하시면 안 되고 눈과 귀와 머리로 시작해야 합니다. 웹에서 결재라는 건 뭘까요? 애초에 결재란 건 뭘까요? 해결해야 할 문제를 현실 상황과의 대조를 중심으로 연구한 뒤, 모델을 수립하고 가용 수단을 확보하여 구체화해 보셔요.

PS. 어느 정도 사태 파악이 되고 나면 '두 사람이 서로 주고받는 결재'의 구현 자체는 본질적으로 '결재선' 구현에 종속된다는 것을 아실 수 있을 겁니다. 어떤 기안의 결재선을 "특정 회원 → 기안 작성자 → 아까 그 회원 → 기안 작성자" 순서로 정의하면 되는 거거든요. 이게 이해가 되신다면, 그 시점에서는 '어떤 언어로 개발해야 되는지' 같은 건 별 문제가 아닐 겁니다.