인사 담당자가 통합 HRIS를 만든 두 달여

1. HRIS가 읽을 올바른 정보 찾기

같은 사람을 설명하는 자료가 여러 개라면, 어느 파일이 가장 최신인지 따지기보다 그 정보를 바꾸는 업무 사건을 먼저 확인합니다.

프로젝트를 시작하던 시기에 구성원 정보는 한곳에만 모여 있지 않았습니다. 채용 담당자는 입사 예정자의 이름과 입사일을 채용 자료에서 관리했고, 인사 담당자는 재직자의 소속과 역할을 구성원 표에서 확인했습니다. 조직 변경 내용은 승인된 발령 기록에 남아 있었고, 근태관리 도구와 휴가 도구에는 다른 자료에서 다시 복사해 온 이름과 소속이 저장되어 있었습니다. 전자계약에는 계약 당사자와 계약 상태가 별도로 표시되어 있었습니다. 각 자료는 그 자료를 사용하는 업무에 반드시 필요했지만, 서로 다른 시점에 갱신되면 같은 사람을 서로 다르게 설명했습니다.

인사 담당자는 자료를 한 파일에 붙여 넣기 전에 항목별로 질문을 정리했습니다. 입사일은 어느 업무에서 확정되는지, 소속은 누가 발령을 승인한 뒤에 바꾸는지, 휴대전화 번호를 본인이 수정하면 어느 화면이 먼저 바뀌는지, 근태 결과와 휴가 사용 기록은 어느 도구가 직접 계산하는지를 차례로 적었습니다. 그 결과 올바른 정보는 특정 문서 하나의 이름으로 정해지지 않고, 항목마다 그 값을 책임지는 업무 흐름으로 정의되었습니다.

조사표의 한 행에는 ‘정보 이름’, ‘처음 만들어지는 업무’, ‘수정할 수 있는 사람’, ‘효력이 시작되는 시점’, ‘이 정보를 읽는 화면’을 적었습니다. 예를 들어 소속 정보를 적은 행에는 채용 자료와 구성원 표를 모두 출처로 적지 않았습니다. 입사 전의 예정 소속과 입사 뒤의 공식 소속을 구분하고, 발령 승인이 끝난 시점부터 공식 기록을 사용하기로 정했습니다. 같은 이름을 가진 값이라도 업무 단계가 다르면 그 값이 맡는 역할도 다르다는 사실을, 표를 채우고 나서야 분명하게 확인할 수 있었습니다.

예를 들어 채용이 확정되면 채용 인테이크에서 입사 예정 정보가 만들어집니다. 입사 절차가 끝나면 HRIS의 구성원 정보가 재직 기간과 기본 역할을 관리합니다. 이후 소속과 역할이 바뀌면 승인된 발령을 새 이력으로 추가합니다. 근태관리와 휴가는 이 사람의 재직 기간을 읽어서 대상 여부를 판단하고, 전자계약은 계약 당사자와 처리 상태를 관리합니다. 한 시스템이 모든 계산을 대신하는 방식이 아니라, 각 업무가 같은 사람을 일관된 기준으로 찾도록 연결하는 구조입니다.

두 자료에 적힌 값이 서로 다를 때에도 한쪽을 곧바로 지우지는 않았습니다. 조직 발령에는 승인된 효력일이 있었고, 구성원 표에는 담당자가 업무 편의를 위해 미리 적어 둔 예정 값이 있을 수 있었습니다. 이런 경우에 화면에서 오늘 시점의 소속을 표시하려면 이미 효력이 시작된 발령을 사용해야 했고, 앞으로 있을 변경을 준비하려면 승인된 미래 발령을 별도로 표시해야 했습니다. 값이 서로 다른 이유를 확인하고 나니, 현재 정보와 예정 정보를 모두 보존하면서도 어떤 화면에서 무엇을 사용할지 정할 수 있었습니다.

정보 출처 조사표를 완성한 뒤에는 실제 화면 하나를 골라, 화면에 표시된 값에서 출발해 원래 업무까지 거슬러 올라가며 확인했습니다. 조직도에서 구성원 한 명을 선택하고, 화면에 표시된 소속과 역할이 어느 발령에서 비롯되었는지, 그 발령은 어느 승인 기록과 연결되는지, 구성원 기본 정보는 어느 단계에서 확정되었는지를 차례로 추적했습니다. 설명이 중간에서 이어지지 않으면, 그 항목은 아직 올바른 정보의 흐름을 정하지 못한 상태로 표시했습니다. 화면에 표시된 값 하나를 원래 업무까지 되짚을 수 있어야, 다른 기능의 화면도 믿고 사용할 수 있었습니다.

아래 사례는 실제 업무 흐름을 바탕으로 날짜와 명칭만 바꾸어 구성했습니다. 사건이 일어난 순서와 시스템이 답해야 했던 질문은 그대로 유지했습니다.

이 사례를 확인하려면 구성원 표만 읽어서는 부족했습니다. 승인된 발령에서 시작일과 추가 역할의 성격을 확인해야 했고, 현재 조직도에서 운영팀 역할이 그대로 유지되는지 살펴야 했으며, 과거 날짜를 기준으로 조직도를 다시 열어 볼 수 있어야 했습니다. 인원 리포트가 사람 수를 계산할 때에는 역할의 개수가 아니라 구성원 A 한 명을 기준으로 계산해야 했습니다. 올바른 정보를 찾는 일은 결국 여러 화면이 답해야 할 질문을 구체적으로 적어 두는 일이었습니다.

이 단계에서 만든 정보 출처 조사표는 이후 근태관리와 휴가, 전자계약에도 그대로 적용했습니다. 재직 시작일이 달라지면 근태 대상 기간과 휴가 신청 가능 기간이 달라질 수 있고, 계약 상태가 달라지면 전자계약 화면이 안내해야 할 다음 행동도 달라집니다. 회사마다 다른 정책을 하나로 묶지는 않았지만, 어느 업무가 어떤 정보를 책임지고 다른 업무는 무엇을 읽어서 사용하는지는 같은 방식으로 정리할 수 있었습니다.

내 업무에 적용할 질문 같은 정보가 여러 화면에 표시된다면, 어느 화면이 가장 최신인지 따지기 전에 누가 어떤 업무 사건에서 그 값을 처음 수정하는지 설명할 수 있는가?

2. 현재 값과 이력을 분리하기

구성원 A의 추가 역할은 현재 조직 한 칸을 바꾸는 문제가 아니라, 두 역할이 함께 유효한 기간을 표현하는 문제였습니다.

사람은 “운영팀 일을 계속하면서 신규사업 TF 역할도 맡는다”는 문장을 자연스럽게 이해합니다. 그러나 시스템은 이 문장에 들어 있는 ‘계속’, ‘하면서’, ‘추가’를 각각 판단 조건으로 바꾸어야 합니다. 본래 역할의 시작일과 종료일을 정해야 했고, 추가 역할의 시작일과 종료일도 정해야 했으며, 현재 화면에서 두 역할을 표시하는 순서와 과거 날짜를 조회할 때 적용할 기간까지 정해야 했습니다.

가장 간단해 보이는 구현 방법은 구성원 A의 현재 조직을 운영팀에서 신규사업 TF로 덮어쓰는 것이었습니다. 이렇게 하면 입력 화면도 한 칸으로 충분하고, 현재 목록에서도 새 값을 바로 확인할 수 있습니다. 하지만 이 선택은 실제 업무의 사실 관계와 다른 결과를 만듭니다. 구성원 A가 운영팀 역할을 그만둔 적이 없는데도 화면에서는 운영팀 목록에서 사라지고, 6월 9일의 조직도를 다시 열어도 나중에 입력한 TF 값이 표시될 수 있습니다.

인사 담당자는 본래의 재직 관계와 추가 역할을 별도로 관리하기로 선택했습니다. 구성원 A의 운영팀 역할은 기본 정보로 계속 유효하고, 신규사업 TF 역할에는 시작일을 따로 두었으며 필요한 경우에는 종료일도 따로 두었습니다. 현재 조직도는 오늘 유효한 두 역할을 함께 표시하고, 과거 조직도는 조회한 날짜에 유효했던 역할만 표시합니다. 인원 리포트는 본래의 재직 관계를 기준으로 한 사람을 한 번만 계산합니다.

날짜가 가지는 의미도 문장으로 명확하게 정해 두었습니다. 6월 10일 발령은 그날 조회한 시점부터 효력이 있고, 6월 9일 조회에는 영향을 주지 않습니다. 추가 역할의 종료일이 정해지면 종료일까지는 그 역할을 표시하고, 그다음 날부터는 현재 화면에서 제외합니다. 이렇게 시작과 끝을 정확하게 적어 두지 않으면 개발자는 날짜를 비교하는 방식을 임의로 선택하게 되고, 담당자는 월말이나 발령 당일에만 나타나는 오류를 뒤늦게 발견할 수 있습니다.

여기에서 데이터 구조는 기술자의 취향에 따라 정해지지 않았습니다. 인사 담당자가 조직도와 리포트에서 기대한 답이 구조를 선택하는 기준이 되었습니다. ‘현재 소속은 하나인가’, ‘추가 역할도 인원에 포함하는가’, ‘과거 시점의 조직을 다시 확인해야 하는가’라는 업무 질문에 답한 뒤에야, 어떤 정보를 나누어 저장할지 결정할 수 있었습니다.

질문을 정리할 때 모든 예외를 한꺼번에 다루지는 않았습니다. 먼저 구성원 A 사례에서 본래 역할과 추가 역할이 동시에 유효하다는 사실을 확정했습니다. 그다음에 추가 역할이 끝나는 경우와 추가 역할 두 개가 서로 겹치는 경우, 시작일과 종료일이 같은 경우를 각각 별도의 사례로 만들었습니다. 아직 확인하지 않은 상황은 이미 지원한다고 가정하지 않고, 검사 목록에 그대로 기록해 두었습니다.

인원 리포트에서는 ‘사람 수’와 ‘역할 수’를 서로 다른 값으로 정의했습니다. 구성원 A는 한 사람이므로 전체 인원에는 한 번만 포함되지만, 역할 목록에는 운영팀과 신규사업 TF가 각각 나타납니다. 조직별 역할 현황이 필요하면 두 역할을 모두 표시할 수 있고, 전체 재직 인원을 묻는 질문에는 한 명으로 계산해서 답합니다. 같은 데이터를 읽더라도 보고서가 묻는 질문에 따라 계산 단위가 달라진다는 점을 문서에 분명하게 적어 두었습니다.

같은 접근 방식은 휴가와 전자계약에도 유용했습니다. 휴가는 현재 잔여 일수만 저장하면 과거의 사용 내역과 조정 사유를 설명하기 어렵고, 전자계약은 현재 상태만 바꾸면 작성과 발송, 서명으로 이어지는 처리 순서를 확인하기 어렵습니다. 기능마다 세부 규칙은 다르지만, 현재 결과와 그 결과가 만들어진 이력을 분리해서 보는 질문은 모든 기능에 공통으로 적용할 수 있었습니다.

내 업무에 적용할 질문 현재 값 한 칸을 바꾸면 과거 조회와 다른 리포트의 의미까지 바뀌는가? 그렇다면 사건의 시작과 끝을 별도 이력으로 관리해야 하는가?

3. 입력에서 조직도와 리포트까지 만들기

작은 기능을 완료했다고 판단하는 기준은 화면 한 장이 아니라, 한 업무 사건의 입력부터 결과까지를 모두 확인했는지 여부였습니다.

처음에는 발령 입력 화면을 만들면 기능이 끝난 것처럼 보였습니다. 구성원과 역할, 조직, 시작일을 고르고 저장 버튼을 누를 수 있었기 때문입니다. 그러나 저장한 정보가 현재 조직도에 표시되지 않거나 과거 조회에서 잘못 표시되면, 인사 담당자는 업무를 완료할 수 없습니다. 인원 리포트가 구성원 A를 두 명으로 계산하는 경우에도 같은 문제가 발생합니다.

그래서 하나의 기능을 ‘입력 정보 → 업무 질문 → 선택한 규칙 → 확인 결과’라는 네 칸으로 정의했습니다. 네 칸 가운데 하나라도 설명할 수 없으면, 아직 작업 범위가 충분히 좁혀지지 않았다고 판단했습니다. 이 구조를 사용하면 개발 용어를 몰라도 인사 담당자가 원하는 결과를 구체적으로 검토할 수 있었습니다.

입력 정보에는 업무를 판단하는 데 필요한 최소 항목만 넣었습니다. 이름과 조직만으로는 시작 전과 시작 후를 구분할 수 없으므로, 효력 시작일이 반드시 필요했습니다. 반면에 전화번호나 계약 정보처럼 이 발령 규칙의 결과를 바꾸지 않는 값은 사례에서 제외했습니다. 개인정보를 더 많이 복사하지 않아도 역할이 겹치는 상황과 날짜 사이의 관계를 정확하게 검사할 수 있었습니다.

구현을 요청할 때에도 같은 네 칸을 사용했습니다. “겸직 기능을 만들어 달라”처럼 범위가 넓은 지시 대신, 구성원 A의 입력값과 기대하는 화면을 함께 제시했습니다. 자동화 도구가 다른 구조를 제안하더라도 세 가지 결과를 모두 만족하는지 비교할 수 있었고, 만족하지 못하는 경우에는 어느 질문을 다시 확인해야 하는지 쉽게 찾을 수 있었습니다.

화면을 검토할 때에는 저장 버튼을 누른 직후부터 확인 순서를 정해 두었습니다. 먼저 발령 상세에서 입력한 시작일과 역할을 읽고, 현재 조직도로 이동해 두 역할을 확인하고, 조회 날짜를 6월 9일로 바꾸어 TF 역할이 사라지는지 확인했습니다. 마지막에는 인원 리포트를 열어 사람 수가 늘어나지 않았는지 확인했습니다. 네 번의 확인이 하나의 점검 목록으로 정리되자, 담당자는 구현 방식의 내부 사정을 몰라도 같은 결과를 다시 재현할 수 있었습니다.

한 기능을 입력부터 결과까지 끝까지 완성하는 방식은 변경 범위도 작게 유지해 주었습니다. 발령 입력과 조직도 조회, 인원 리포트를 한 번에 모두 일반화하지 않고, 구성원 A 사례가 지나가는 최소 경로부터 연결했습니다. 현재 조직도가 틀리면 역할 조회 방식을 확인했고, 과거 조직도가 틀리면 날짜 조건을 확인했으며, 인원 수가 틀리면 사람과 역할의 계산 기준을 확인할 수 있었습니다.

한 번에 범위가 넓은 기능을 만들 때에는 어느 단계에서 문제가 생겼는지 찾기 어려웠습니다. 반면에 구성원 A의 입력과 세 가지 결과만 연결한 뒤에 검사하면, 실패한 지점을 좁은 범위에서 찾을 수 있었습니다. 입력 상세부터 틀리면 저장 단계를 확인했고, 현재와 과거가 함께 틀리면 역할 조회 방식을 확인했으며, 조직도는 맞지만 인원 수만 틀리면 리포트의 계산 기준을 확인했습니다. 업무 담당자가 화면을 읽는 순서가 곧 문제를 진단하는 순서가 되었습니다.

근태관리와 휴가, 전자계약 기능도 같은 방식으로 범위를 정했습니다. 입력 화면만 만드는 대신, 근태 기록이 월별 결과에 어떻게 표시되는지, 휴가 신청이 사용 이력과 잔여 일수에 어떻게 반영되는지, 전자계약의 상태 변경이 당사자 화면과 관리자 화면에 각각 어떻게 표시되는지까지 하나의 업무 결과로 묶었습니다. 확인할 결과가 구체적으로 정해져 있으니, 비개발자도 기능이 완료되었는지 직접 판단할 수 있었습니다.

여기에서 말하는 작은 기능은 코드가 짧다는 뜻이 아니었습니다. 담당자가 실제 업무 한 건의 시작과 끝을 직접 확인할 수 있는 크기를 뜻했습니다. 화면과 저장, 조회, 리포트가 서로 다른 기술 영역에 속해 있더라도, 구성원 A의 발령이라는 한 사건으로 묶으면 무엇을 함께 검사해야 하는지가 분명해졌습니다.

내 업무에 적용할 질문 새 화면을 만드는 대신 실제 업무 한 건을 고른다면, 어떤 입력에서 시작해 어느 결과 화면까지 확인해야 완료라고 말할 수 있는가?

4. 발령 전날과 종료 뒤까지 검사하기

현재 화면이 평범한 상황에서 맞는다는 사실만으로는 이력 기능을 검증할 수 없습니다. 날짜의 앞뒤 관계와 역할이 겹치는 상황을 따로 확인했습니다.

구성원 A의 추가 역할이 6월 10일에 시작한다면, 가장 먼저 확인할 결과는 그날 시점의 현재 조직도입니다. 하지만 날짜를 비교하는 방식이 정확한지는 6월 9일을 함께 확인해야 알 수 있습니다. 시작 전날에도 TF 역할이 표시된다면 시작일 조건이 잘못 적용된 것입니다. 추가 역할이 끝난 뒤에는 현재 화면에서 사라지고 과거 조회에서는 계속 표시되어야, 이력도 함께 보존됩니다.

인사 담당자는 사례를 많이 모으기보다, 서로 다른 실패를 찾아내는 네 가지 사례를 골랐습니다. 대표 사례에서는 평범한 시작을 확인했고, 경계 사례에서는 하루 차이를 확인했으며, 종료 사례에서는 현재와 과거의 분리를 확인했고, 예외 사례에서는 추가 역할이 여러 개인 상황을 확인했습니다. 각 사례에는 입력과 예상 결과를 먼저 적어 두었고, 시스템이 만든 결과는 나중에 별도로 대조했습니다.

검사용 사례에는 실명이나 실제 조직명이 필요하지 않았습니다. 역할 사이의 관계와 시작일과 조회일의 순서, 추가 역할의 개수처럼 결과를 바꾸는 정보만 있으면 충분했습니다. 구성원 A라는 표기와 설명을 위해 만든 조직명만으로도 날짜 조건과 인원 계산을 엄밀하게 검사할 수 있었습니다. 검증에 필요하지 않은 속성을 가져오지 않으니, 사례의 목적도 더 분명해졌습니다.

기대 결과를 적을 때에는 시스템이 만든 값을 그대로 복사하지 않았습니다. 인사 담당자가 업무 규칙을 기준으로 먼저 작성했고, 시스템은 같은 입력을 처리해 실제 결과를 만들었습니다. 두 결과가 서로 다르면 구현 오류인지, 기대 결과를 잘못 적은 것인지, 아직 결정하지 않은 업무 규칙이 남아 있는 것인지를 구분했습니다. 어느 경우든 숫자만 맞추려고 하기 전에 업무 질문으로 돌아갔습니다.

차이가 나타나는 형태도 원인을 알려 주었습니다. 6월 9일에 TF 역할이 표시되면 시작일 경계 조건을 의심했고, 6월 10일에 본래 역할이 사라지면 한 칸 덮어쓰기 방식이 다시 적용되었는지 확인했습니다. 조직도 두 화면은 맞는데 인원 수가 두 명으로 나오면, 리포트가 사람 대신 역할을 세고 있는지 살펴보았습니다. ‘틀렸다’는 한 단어보다, 입력과 예상 결과, 실제 결과를 나란히 적어 둔 표가 다음에 할 행동을 훨씬 구체적으로 정해 주었습니다.

검사표에는 아직 확인하지 못한 범위도 함께 기록했습니다. 추가 역할의 종료일이 비어 있는 경우는 확인했지만 시작일과 종료일이 같은 경우를 아직 확인하지 않았다면, 그 상황까지 지원한다고 표현하지 않았습니다. 새로운 사례가 생기면 기존의 네 사례를 지우지 않고, 어떤 빈칸을 추가로 확인하는지 표시했습니다. 이렇게 기록해야 일부 사례의 성공을 시스템 전체의 정확성으로 확대해 해석하지 않을 수 있습니다.

규칙을 수정한 뒤에는 문제가 발견된 한 사례만 다시 실행하지 않았습니다. 대표와 경계, 종료, 예외에 해당하는 네 행을 모두 다시 확인했습니다. 종료 처리 하나를 고치다가 시작일을 비교하는 방식이 달라질 수 있고, 역할 목록을 고치다가 인원 계산이 영향을 받을 수 있기 때문입니다. 작게 묶어 둔 사례 모음은 규칙을 수정할 때마다 같은 업무 결과를 다시 확인하게 해 주는 안전 장치가 되었습니다.

오류를 발견하면 조건이 많은 사례에서 조건을 하나씩 제거했습니다. 구성원 A에게 여러 발령이 함께 있다면, 그 가운데 하나를 제거해도 같은 문제가 발생하는지 확인했습니다. 마지막에 ‘조회일이 시작일보다 하루 빠른 경우’처럼 차이를 만들어 내는 조건 하나가 드러나면, 그 조건을 검사 항목으로 고정했습니다. 이후로는 구현을 바꿀 때마다 같은 경계 조건이 다시 잘못 처리되지 않는지 자동으로 확인했습니다.

이 원칙은 근태관리와 휴가에서도 똑같이 적용했습니다. 평범한 한 달만 확인하지 않고, 월이 바뀌는 날과 값이 비어 있는 날, 한 사건이 두 기간에 걸치는 경우를 따로 살펴보았습니다. 다만 실제 회사의 계산 방식이나 휴가 정책을 사례에 그대로 옮기지는 않았습니다. 공개용 설명에는 ‘경계 조건을 별도 사례로 확인했다’는 방법과 입력, 예상 결과, 실제 결과로 이어지는 구조만 사용했습니다.

내 업무에 적용할 질문 대표 사례가 맞는 것 외에 시작 직전, 종료 직후, 값이 비거나 사건이 겹치는 경우에는 어떤 결과가 나와야 하는가?

5. 자동화가 만든 미리보기를 사람이 승인하기

자동화가 맡은 역할은 승인 단계를 없애는 것이 아니라, 사람이 읽을 변경 내용을 정확하게 준비하는 것이었습니다.

구성원 A 사례가 검사를 통과했다고 해서 곧바로 실제 발령을 반영하지는 않았습니다. 검사에 사용한 사례와 실제 반영 대상은 서로 다르고, 실제로 반영하면 조직도와 인원 리포트를 비롯한 여러 화면이 함께 바뀔 수 있습니다. 인사 담당자는 실행하기 전에 어떤 사람이 어떤 역할을 언제부터 맡는지, 기존 역할은 그대로 유지되는지, 바뀌지 않아야 할 화면은 무엇인지를 미리보기로 확인했습니다.

미리보기는 “문제없음”이라는 한 줄짜리 문장이 아니었습니다. 반영 대상과 추가될 정보, 그대로 유지될 정보, 영향을 받는 결과, 취소 방법을 같은 화면에 함께 표시했습니다. 담당자는 원자료와 미리보기를 대조했고, 이해하지 못한 항목이 하나라도 있으면 실행을 보류했습니다. 반영한 뒤에는 같은 형식의 결과표를 다시 열어 예상 결과와 실제 결과를 비교했습니다.

대상을 확인할 때에는 이름만 사용하지 않았습니다. 같은 이름을 가진 사람이 있을 수 있으므로, 미리보기에서 현재 조직과 본래 역할, 적용할 발령의 종류를 함께 읽었습니다. 다만 공개용 설명에는 실제 사번이나 연락처를 사용하지 않았습니다. 중요한 점은 민감한 값을 그대로 표시하는 것이 아니라, 승인자가 서로 다른 사람이나 사건을 혼동하지 않을 만큼 업무 맥락을 충분히 제공하는 것이었습니다.

자동화에 맡긴 일은 반복할 수 있고 결과를 비교할 수 있는 일이었습니다. 자료의 항목을 정리하고, 발령 전후의 차이를 표로 만들고, 여러 날짜를 기준으로 조직도를 조회하고, 검사 명령을 반복해서 실행했습니다. 사람은 그 표가 실제 업무 사건을 제대로 설명하는지, 회사의 운영 판단과 맞는지, 실제 환경에 반영해도 되는지를 판단해서 결정했습니다.

승인이 필요한 경계는 사용하는 도구의 이름으로 정하지 않았습니다. 같은 자동화라도 검사용으로 만든 사례의 조직도를 생성하는 일은 되돌리기 쉽지만, 실제 구성원의 발령을 반영하는 일은 이후 업무에까지 영향을 줍니다. 근태관리 결과를 비교하는 일과 실제 근태 기록을 바꾸는 일도 영향의 크기가 다릅니다. 그래서 ‘실패하면 원래 상태로 돌릴 수 있는가’, ‘민감한 정보를 다루는가’, ‘제도에 관한 판단이 필요한가’를 먼저 확인했습니다.

실행한 뒤의 확인도 생략하지 않았습니다. 구성원 A의 현재 조직도에 두 역할이 모두 표시되는지, 6월 9일 조회 결과가 바뀌지 않았는지, 인원 리포트가 여전히 한 명으로 계산하는지를 다시 확인했습니다. 미리보기와 다른 항목이 하나라도 있으면, 실행 성공 메시지가 표시되었더라도 작업이 끝나지 않은 것으로 판단했습니다.

취소 절차도 미리보기와 함께 확인했습니다. 잘못 입력한 추가 역할을 취소할 때 구성원 A의 운영팀 역할까지 함께 삭제되어서는 안 되었고, 취소했다는 사실과 원래 발령 사이의 관계를 나중에도 확인할 수 있어야 했습니다. 되돌리는 방법을 실행한 뒤에 찾지 않고 승인하기 전에 미리 읽어 두자, 담당자는 변경이 미치는 영향을 이해한 상태에서 결정을 내릴 수 있었습니다.

여러 사람이 함께 작업할 때에는 업무의 의미를 설명하는 사람과 변경 범위를 준비하는 사람, 결과를 확인하는 사람의 관점을 서로 분리했습니다. 인원이 적어서 한 사람이 여러 역할을 맡더라도, 작성한 직후에 바로 승인하지 않고 원자료와 기대 결과를 다시 읽었습니다. 자동화의 범위가 넓어질수록 사람이 버튼을 누르는 시간보다 승인 기준을 만드는 시간이 더 중요해졌습니다.

여러 번 반복하면서 안전하다고 확인된 조회와 비교 작업은 자동화 범위를 더 넓힐 수 있었습니다. 반면에 처음 다루는 데이터와 민감한 정보, 취소하기 어려운 실행은 다시 사람이 직접 확인하는 대상으로 되돌렸습니다. 자동화 범위는 한 번 선언하고 고정하는 값이 아니라, 실제 영향과 검증 경험에 따라 계속 조정하는 값이었습니다.

내 업무에 적용할 질문 실제로 반영하기 전에 바뀌는 항목과 그대로 유지되어야 하는 항목, 실패했을 때의 취소 방법을 한 화면에서 설명할 수 있는가?

6. 같은 규칙을 다시 찾을 수 있게 기록하기

주고받은 대화가 많아지더라도, 다음 작업자는 현재 규칙과 선택한 이유, 아직 확인하지 못한 범위를 짧은 경로로 찾을 수 있어야 했습니다.

두 달여 동안 구성원 정보와 발령, 조직도, 인원 리포트, 전자계약, 근태관리와 휴가 기능이 차례로 늘어났습니다. 처음에는 이전 대화를 검색하면 필요한 답을 찾을 수 있었습니다. 그러나 같은 질문이 여러 시점에 반복되고 지난 계획과 현재 결과가 함께 검색되면서, 어느 설명이 지금도 유효한지를 매번 다시 판단해야 했습니다.

인사 담당자는 문서마다 한 가지 질문만 맡도록 역할을 나누었습니다. 길잡이 문서는 올바른 정보와 업무 규칙이 어디에 있는지를 연결했고, 현재 상태 문서는 지금 동작하는 화면과 검사 항목을 요약했습니다. 작업 대기열에는 아직 확인하지 못한 예외만 남겨 두었고, 결정과 검증을 적는 기록에는 선택한 이유와 검토한 대안, 사용한 사례와 결과를 적었습니다.

구성원 A의 추가 역할을 다시 수정해야 하는 작업자는 모든 대화를 처음부터 읽을 필요가 없었습니다. 길잡이 문서에서 발령 규칙을 찾고, 현재 상태 문서에서 그 규칙이 적용된 화면을 확인한 뒤, 결정 기록에서 한 칸 덮어쓰기 방식을 선택하지 않은 이유를 읽었습니다. 마지막으로 검사표에서 대표와 경계, 종료, 예외 가운데 어느 범위까지 확인되었는지를 살펴보았습니다.

결정 기록의 요약은 실제 업무 질문으로 시작했습니다. ‘본래 역할을 유지한 채 추가 역할을 어떻게 표현할 것인가’를 먼저 적고, 비교한 두 가지 안과 세 개의 결과 화면을 연결했습니다. 검증 기록에는 실행한 네 사례와 기대 결과, 실제 결과, 검사한 날짜 조건을 함께 적었습니다. 결론과 근거가 같은 문단에 섞이지 않으니, 새로 참여한 작업자는 필요한 정보만 골라서 읽을 수 있었습니다.

현재 상태 문서와 시간순 작업 기록을 분리한 것도 중요했습니다. 현재 상태 문서에는 오늘 유효한 기능과 제한만 적고, 지난 변화는 별도의 기록에 시간순으로 보존했습니다. 새로 참여한 작업자는 먼저 현재 상태를 읽고, 선택한 이유가 필요할 때에만 과거의 결정 기록으로 이동했습니다. 지난 기록을 모두 처음 읽는 경로에 쌓아 두지 않으니, 실제 작업을 시작하기까지 걸리는 시간이 짧아졌습니다.

결정 기록에는 결론만 적지 않았습니다. 어떤 문제가 있었는지, 한 칸 덮어쓰기 방식과 별도 이력 방식을 어떤 기준으로 비교했는지, 무엇을 선택했는지, 어떤 조건이 생기면 다시 검토할지를 함께 기록했습니다. 나중에 업무 조건이 바뀌면 지난 결론을 그대로 따르거나 무시하는 대신, 당시에 세운 전제가 지금도 유효한지 확인할 수 있었습니다.

검증 기록에는 확인에 성공한 범위와 아직 확인하지 못한 범위를 함께 적었습니다. 구성원 A의 네 사례가 통과했다는 사실은 추가 역할 규칙의 네 가지 조건을 확인했다는 뜻입니다. 다른 종류의 발령이나 회사 전체의 모든 예외까지 증명했다는 뜻은 아닙니다. 이런 한계를 함께 기록해 두면, 새로 추가하는 사례가 기존 검사를 무효로 만드는 것이 아니라 어느 빈칸을 채우는지 설명할 수 있습니다.

문서를 관리하는 일 자체도 검사 대상으로 삼았습니다. 새 규칙을 만들고 길잡이 문서에 연결하지 않았는지, 현재 상태 문서에 지난 이력이 계속 쌓이고 있는지, 이미 끝난 일이 작업 대기열에 남아 있는지, 내부 링크가 실제 문서를 정확하게 가리키는지를 자동으로 확인했습니다. 사람의 기억에 의존하지 않고, 문서 구조가 흐트러진 상태를 바로 발견할 수 있게 했습니다.

기록 구조가 실제 인수인계에 도움이 되는지도 시험해 보았습니다. 새로 참여한 사람에게 구성원 A 사례를 말로 먼저 설명하지 않고, ‘현재 조직도에서 두 역할이 표시되는 이유’와 ‘인원 리포트가 한 명으로 계산하는 이유’, ‘아직 확인하지 못한 조건’을 직접 찾아보게 했습니다. 찾아가는 경로가 중간에 끊기거나 서로 다른 문서가 서로 다른 답을 주면, 설명을 늘리기 전에 연결 위치와 현재 상태 문서를 먼저 수정했습니다.

기록을 추가하는 일만큼 줄이는 일도 중요했습니다. 이미 끝난 항목은 작업 대기열에서 제거했고, 같은 사실을 반복해서 설명하는 문장은 기준 문서 하나로 모았습니다. 오래된 기록은 삭제하지 않되, 처음 읽는 경로와는 분리해 두었습니다. 기록의 품질은 문서의 총량이 아니라, 현재의 판단에 필요한 근거를 얼마나 빨리 찾을 수 있는지를 기준으로 평가했습니다.

내 업무에 적용할 질문 새로 참여한 사람이 말로 하는 설명 없이도 현재 규칙과 선택한 이유, 검사 결과와 아직 확인하지 못한 범위를 순서대로 찾을 수 있는가?