일벌백계

“비리 사학 일벌백계, 감사대상은 최소화” 

一罰百戒.

이는 예전의 어느 프로젝트에서 깨닫게 된 개발 방법론이다.

애플리케이션은 왜 존재하는가? 결국 사용자를 자유롭게 하기 위해 존재하는 것이다. 일을 더 잘할 수 있게 하기 위한 자유. 더 자유롭게 발상하고, 더 자유롭게 계산하고, 더 자유롭게 기획하고… 그러나 워드나 엑셀과 같은 범용 프로그램이 아닌 이상, 목적과 프로세스를 지닌 시스템이라면 사용자가 따라야 할 일종의 스토리보드와 가이드라인은 있게 마련이다.

여기에서 사용자에게 얼마만큼의 제약 조건을 둘지에 대한 논의가 생겨난다. 필드 입력 값의 제한, 또는 프로세스 변경의 제한, 또는 권한의 설정 등 사용자에게 얼마만큼의 자유를 부여할지에 대한 논의는 업무 분석의 주된 부분을 차지 한다.

그러나 당시 프로젝트에서 현업은 최대한의 자유도를 주장했다. 대신…
“누가 업무 가지고 장난쳐? 그럼 짤라 버려.”

일벌백계인 것이다.

지나치게 모든 조건을 미리 걸어 두려 한다면, 1) 변화에 적응이 느린 경직된 시스템이 되고, 2) 그 결과 업무가 유연하지 못할 때 그 업무 책임을 IT 부서의 탓으로 돌리는 폐해가 발생하고 만다. 즉, 최대한의 자유를 주되, 이를 악용한 경우에는 함부로 행사한 권한에 걸맞은 책임을 묻는 것이다.

그런데 IT에서는 일벌백계의 방법론으로 간다면, 오히려 감사를 강화하게 된다. 즉 Auditing을 적극적으로 걸어, 많은 로그를 수집하고 일벌백계를 위한 밑자료로 활용하게 되는 것이다.

“걸리면 죽는다”와 같은 네가티브의 접근일수도, “믿어도 알아서 잘한다”는 포지티브의 이미지일수도 있는 일벌백계의 방법론. 애플리케이션의 곳곳에 산재하던 micro-management적 개발 공수는 줄이고, 각종 미들웨어의 Log/Audit 기능을 살린다는 점에서 개인적으로는 찬성하는 편이다.

Comments

“일벌백계”의 1개의 생각

댓글 남기기