Sungeun Blog

프로젝트 관리계획서는 모든 보조적인 계획서를 정의하고, 작성 및 조율을 통해 하나의 종합적인 관리계획서로 통합하는 프로세스 

1. 입력물 (Input) 상세내용

① 프로젝트 헌장 ((Project Charter)

- 프로젝트 헌장(Charter)은 프로젝트 자원, 예산, 목표를 부여하기 위해 권한을 가진 관리 자로부터 승인 받은 문서

- 프로젝트 헌장은 프로젝트의 상위 레벨에서 정의하기 때문에, 프로젝트 관리자는 프로젝트 착수 프로세스 에서 프로젝트 헌장을 시작점으로 사용한다. 

② 다른 프로세스 산출물 (Outputs from other processes)

프로젝트 보조 관리 계획서들이 프로젝트 관리계획서를 만들기 위하여 통합됨  

1) 의사소통 관리 계획서

2) 원가관리 계획서 

3) 인적자원 관리 계획서 

4) 구매관리 계획서 

5) 프로세스 개선 계획서

6) 품질관리 계획서 

7) 요구사항 관리 계획서

8) 위험관리 계획서

9) 일정관리 계획서 

10) 범위관리 계획서 

11) 이해관계자 관리 계획서

12) 원가 기준선

13) 일정 기준선

14) 범위 기준선

15) 프로젝트 관리 계획서 갱신

2. 도구 및 기법 (Tool & Technique) 상세내용

① 전문가 판단 (Expert judgment)

② 자료 수집 (Data Gathering)

 2.1) 브레인 스토밍 : 프로젝트팀과 SME 조직이 참석하여 아이디어와 해결책 수집 

 2.2) 체크 리스트 : PMO 조직이 사전에 만들어 놓은 체크리스트를 통해 프로젝트 관리 계획서 검토 

 2.3) 핵심 전문가 그룹 : 프로젝트 관리 계획서를 위한 선별된 전문가 집단으로 이해관계자와 대화식 토론 

 2.4) 인터뷰 : 이해관계자와 인터뷰 수행, 프로젝트 관리 계획서 작성을 위한 수집 

③ 대인관계와 팀 기술 (Interpersonal and Team skills)
 3.1) 갈등 관리(Conflict Management) : 프로젝트 목적 달성에 따른 많은 이해관계자들이 각자 본인의 Concern을 해결 및 조정하는 활동 
 3.2) 촉진 (Facilitation) : 결론 도출 유도 및 환경 조정 기법  
 3.3) 미팅 관리(Meeting Management) : 미팅을 진행하기 위한 주제(Agenda)준비 및 배포 회의시간 확인, 참여자 초대, 이슈 정리, 책임자 기록 

※ 착수 회의 (Kick-off) 미팅 

1) 소규모 프로젝트팀

- 프로젝트 착수 후에 계획 프로세스의 끝에서 수행함

2) 대규모 프로젝트팀 

- 프로젝트 관리팀이 계획(Planning)을 수행하고, 잔여팀들이 실행 및 구축을 하므로, 착수회의는 실행 프로세스 그룹(초반)에 수행된다.

3. 산출물 (Output) 상세내용 

프로젝트 관리계획서 (Project Management Plan)

Q: 본인확인기관이 주민등록번호를 변환한 연계정보(CI)가 개인정보에 해당하나요 ? 

참고) CI (Connection Information)란? 

NICE와 같은 신용정보 업체에서 인증 받으면 발급되는 키 값으로 주민등록번호 대체 값으로 사용된다. 

CI는 본인확인기관이 주민등록번호를 단방향 암호화한 정보로서 복원이 불가능하고 그 자체로는 특정 개인을 알아볼 수 없으나 특정 개인에 고유하게 생성 및 귀속되어 유일성을 가지며 정보통신서비스 제공자의 온·오프라인 서비스 연계를 위해 활용되므로 다른 정보와 쉽게 결합하여 특정 개인을 알아볼 수 있어 개인정보에 해당합니다(개인정보보호위원회 결정 제2020-103-007호).

※ 개인정보란 살아 있는 개인에 관한 정보로서 성명, 주민등록번호 및 영상 등을 통하여 개인을 알아볼 수 있는 정보이며, 해당 정보만으로는 특정 개인을 알아볼 수 없더라도 다른 정보와 쉽게 결합하여 알 아볼 수 있는 경우도 포함됩니다(보호법 제2조 제1호).

- 출처: 개인정보 보호법 해설 사례집 1.0 (한국인터넷진흥원)

Q 48: 회원가입에 필요한 개인정보를 동의 없이 수집해도 되나요?

네, 회원가입에 필요한 개인정보를 수집하는 것은 정보주체의 요청에 따른 회원가입 이용계약을 체결하기 위한 것이므로, 정보주체로부터 동의 없이 개인정보를 수집할 수 있습니다.

회사(개인정보처리자)는 정보주체와 체결한 계약을 이행하거나 계약을 체결하는 과정에서 정보주체의 요청에 따른 조치를 이행하기 위하여 필요한 경우 정보주체의 별도의 동의 없이 개인정보를 수집할 수 있으나(보호법 제15조 제1항 제4호), - 이 경우 그 목적에 필요한 최소한의 개인정보를 수집하여야 하므로, 회사가 수집하는 개인정보는 회원가입을 위하여 필요한 최소한의 정보여야 합니다(보호법 제16조 제1항)

- 출처: 개인정보 보호법 해설 사례집 1.0 (한국인터넷진흥원)

프로젝트 작업 지시와 관리는 프로젝트 목표를 달성하기 위하여, 프로젝트 관리 계획과 승인된 변경을 이행하고, 프로젝트 작업을 지도 및 수행하는 프로세스이다.

• 프로젝트 작업 지시 및 관리  ITO

1. 입력물 (Input) 상세내용

① 프로젝트 관리 계획서(Project Management Plan)

프로젝트 관리 계획서 (Project Management Plan)는 프로젝트를 계획, 실행, 통제 및 감리, 종료하는 
방법을 명시한, 여러 개의 보조 관리 계획서를 통합한 프로젝트 관리 계획 문서이다. 
범위관리 계획, 요구사항관리 계획, 일정관리 계획, 원가관리 계획, 이해관계자 관리 계획 등을 포함하고 있다. 

② 프로젝트 문서 (Project Documents)

인도물을 생성하면서, 관련된 프로젝트 문서들을 참조할 수 있다.

③ 승인된 변경 요청 (Approved Change Request)

승인된 변경 요청은 프로젝트의 변경통제위원회(Change Control Board)에 의해 구현을 목적으로 프로젝트 팀에 검토 및 승인되고, 통합 변경 통제 프로세스에 의해 수행된 산출물이다.
시정조치, 예방조치, 결함수정의 변경요청 3가지 중의 1개 일 수 있으며, 승인된 변경 사항은 구현해야 하는 작업이 된다.

2. 도구 및 기법 (Tool & Technique) 상세내용

① 전문가 판단 (Expert Judgment)

프로젝트 작업 지시 및 관리하는 입력물을 평가하는 기법으로 전문가 판단이 필요하다. 
다음 사항들이 기술적인 검토 및 평가를 위해 도움이 된다.

②  프로젝트 관리 정보시스템(Project Management Information System)

프로젝트 관리 정보시스템은 프로젝트 작업을 수행 가능하도록 일정관리, 자원관리, 작업 진행 정보 수집 및 분배가 가능한 시스템

3. 산출물 (Output) 상세내용 

① 인도물 (Deliverables)

프로젝트 인도물은 프로젝트를 완료하기 위해서, 프로젝트팀에서 작업하고 산출해야 하는 고유하고도 검증이 가능한 제품 및 결과물을 말한다. 대상으로는 제품, 서비스, 프로세스, 계획, 수행 능력까지 포함된다. (Deliverables is any unique product, Result)

② 작업 성과 데이터(Work Performance Data)

작업 성과 데이터는 프로젝트의 작업을 수행하면서 수행된 활동 등의 측정된 진행률, 활동 시작일 및 종료일, 결함 수, 실제 투입된 원가 및 기간 등을 말한다. 작업 성과 데이터는 각 프로세스의 통제 프로세스의 입력물이 된다.
예) 프로젝트 진행률, 프로젝트 측정치, 결함 수, AC(실제 원가) 등

③ 이슈 로그 (Issue Log)

프로젝트 이슈를 기록하고, 추적하고, 감시하기 위한 문서 (Document)
- 문제(Problem), 차이(Gaps), 불일치(Inconsistencies), 충돌(conflicts) 항목들을 관리 
이 항목들은 프로젝트 성과에 영향을 주지 않도록 조치를 요구하는 사항임

④ 변경 요청(서) (Change Requests)

프로젝트 범위의 확장이나 축소, 정책, 프로세스, 계획 또는 절차의 수정, 원가 또는 예산의 수정, 일정 변경 등을 공식적으로 요청하는 조치이다.

⑤ 프로젝트 관리 계획서 갱신(Project management plan updates)

프로젝트 관리 계획서와 관련된 여러 개의 보조 관리 계획서를 갱신한다.

대표적으로 범위관리계획서, 요구사항관리계획서, 일정관리계획서, 원가관리계획서 문서 등을 갱신한다.

⑥ 프로젝트 문서 갱신(Project documents updates)

프로젝트 문서 – 요구사항 문서, 프로젝트 관리대장, 프로젝트 이슈, 위험 사항, 이해관계자 목록 등을 갱신한다.

이전에 OO기업 1차 실무 면접 시, 렌터카 시스템 흐름 및 구성도에 대하여 자유롭세 작성하여 제출하는 과제가 있었다.

아래 그림은 해당 과제에서 제출했던 구성도 자료이며, 열심히 고민하고 설계했었기에  블로그 기록으로 남겨놓으려 한다.

우리는 프로젝트 진행을 위하여 회사 or 조직의 공식적인 승인 과정이 필요한데, 그 승인을 위한 가장 기본적인 문서/과정을 프로젝트 헌장 (Project Charter) 혹은 프로젝트 승인서, 품의서 라고 부른다. 

프로젝트 헌장(Chaerter)은 프로젝트 자원, 예산, 목표를 부여하기 위해 권한을 가진 관리자로 부터 승인 받은 문서이며, 이 문서의 승인을 통하여 프로젝트 관리자는 조직의 자원과 프로젝트 활동을 수행할 권한이 공식적으로 프로젝트 관리자(PM)에게 주어진다. 

• 프로젝트 헌장 개발 (Develop Project Charter) ITO 

프로젝트 헌장 개발을 위하여 입력물에 대하여 도구 및 기법을 통해 산출물로서 프로젝트 헌장을 만들어 낸다. 

1. 입력물 (Input) 상세내용

① 비즈니스 문서 (Business Documents) 

  1) 비즈니스 문서는 프로젝트 관리 계획서 작성 이전에 작성, 개발 된다. 

  2) 비즈니스 케이스 (Business Case) : Cost-benefit analysis 가 포함된 승인된 비즈니스 문서 

   - 결과물 (Outcome) 투자를 위한 프로젝트 정당성 (Justify) 여부 판별하는데 필요한 정보 

   - 투자 할 가치가 있는지 프로젝트의 진행여부를 결정하기 위한 필요한 정보를 기술

  3) 편익 관리 계획서 (Benefit Management Plan)

    가) 편익에 대한 분석 문서, 편익이 수행되는 방법과 시기 설명 

    나) 목표 편익 (가치, 재무적가치, NPV로 표시)

② 협약서 (Agreements) 

 1) 고객(갑)과 서비스 제공업체(을) 간의 협정 사항 및 공식 문서 

 2)  조달 수행 프로세스의 산출물(Output) 이며, 계약서, 양해각서(MOU), 의향서(Letter of intent, LOI),구두 합의, 이메일까지 모두 해당됨 

③ 기업환경요인 (Enterprise Enviromental Factors) 

 - 프로젝트 헌장 개발 및 진행에 영향을 주는 제약사항 및 시장 환경 요인

 - 정부 기준, 정책, 기술분야 표준, 규제, 조직의 관습, 시장분야의 조건 등이 해당 됨 (법률, 법령, 시행 규칙 등) 

④ 조직 프로세스 자산 (Organization Process Assets)

 - 프로젝트 헌장 작성을 위해 프로젝트 관리에 사용하는 프로세스와 관련된 조직 자산  

 - 조직의 프로세스, 템플릿, 선례정보 등이 해당 됨 

2. 도구 및 기법 (Tool & Technique) 상세내용

① 전문가 판단 (Expert judgment) 

 -  프로젝트 승인에 판단을 할 수 있는 전문가 및 내/외부 인원의 의사 판단

 - 조직 내 전문가, 컨설턴트, 학자, 교수, 기술협회, 산업 단체 등 분야별 전문가 (SEM : Subject Matter Experts) 

② 데이터 수집 (Data Gathering) 

 1) 프로젝트 헌장을 만들이 위한 자료 수집 기법들이다. 

 2) 브레인스토밍 : 아이디어 식별 기법

 3) 포커스 그룹 (Focus Group) : 전문가 집단으로 대화식 토론으로 자료 수집

 4) 인터뷰 : 이해관계자와 인터뷰 수행 

③ 대인관계와 팀 기술 

 1) 대인관계와 팀 관리 기법에 대한 세부 기법 목록들이다. 

 2) 갈등관리 (Conflict Management) : 프로젝트 목적 달성에 따른 많은 이해관계자들이 각자 Concern을 바라보는 문제점들을 해결 및 조정하는 활동 => 프로젝트 헌장의 공감을 조율 

 3) 촉진기법 (Facilitation) : 결론 도출 유도 및 환경 조성 기법 

 4) 미팅관리 (Meeting Management) : 미팅을 진행하기 위한 주제(Agenda) 준비 및 배포, 회의시간 확인, 참여자 초대, 이슈 정리, 책임자 기록 등 

④ 미팅(Meetings) : 프로젝트 헌장을 개발하기 위한 프로젝트의 목표, 주요한 성공 기준, 주요 인도물, 상위 수준과 중요한 요구사항 정리, 마일스톤 등을 중요 이해관계자들과 미팅을 수행한다. 

3. 산출물 (Output) 상세내용 

① 프로젝트 헌장 (Project Charter) 

 가) 프로젝트 자원, 예산, 목표를 부여하기 위해 권한을 가진 관리자로 부터 승인 받은 문서 

 나) 이 문서를 통하여 PM은 조직의 자원과 프로젝트 활동을 수행할 권한이 공식적으로(Formally) 주어짐

② 가정사항 로그 (Assumption Log)

 - 프로젝트 헌장에 프로젝트 생명주기 동안의 전략과 운영상의 제약 조건이 기록 된다. 

• 프로젝트 헌장에 들어가는 공통 구성요소

PMP 7판에서는 예측적 프로젝트 관리 프로세스를 상세히 다루지 않지만, 사실 6판의 예측적 프로젝트 관리 프로세를 이해해야만 7판과 나아가 Agile 까지 완벽히 이해할수 있다고 생각한다. 

따라서, 예측적 프로젝트 관리 프로세스 그룹 (49개 서브 프로세스)를 정리하고 주요 사항을 알아 보도록 하겠다. 

• 프로젝트 통합 관리 - Key Concepts 

1. 2번~10번까지의 지식 영역은 전문가가 있을 수 있지만, 통합관리는 PM의 특별한 관리 영역이다.

2. 따라서, 다른 사람에게 양도하거나, 이관 할 수 없다. 

3. PM은 프로젝트에 대한 책임을 진다. 

4. 주요 확인 및 관리 활동들은 다음과 같다. 

• 프로젝트 통합 관리의 Trend & Emerging Practices (동향 및 신규 실행사례) 

프로젝트 통합 관리는 나머지 9개의 모든 지식 영역관리의 결과물을 조합한다. 

• 프로젝트 통합 관리의 조정에 대한 고려사항 (Tailoring) 

프로젝트의 '유일성'으로 인해, PM은 프로젝트 관리 프로세스를 조정할 수 있다.

최근에 수행된 프로젝트 또는 신규 시스템들은 Operation 모드 돌입 시  Source Version Control Tool 로서 대부분 Git을 많이 사용한다. 하지만 Git은 의외로 진입장벽이 높다. 한가지 예로, SVN만 사용한 개발자 분들은 Git Flow에 대해 이해하지 못하는 경우를 많이 봤다. 현재 Git을 사용하고 계신 분들은 이해를 못 할 수도 있지만, Git을 처음 사용할 때의 기억을 더듬어 본다면 어느정도 공감 할 수 있을 것이다. 

때문에, 어떤 프로젝트에서는 Git을 도입하기는 했지만 개발팀의 Learning Curve 너무 길어 SVN처럼 사용하는 Site도 많이 보았다. 내가 투입된 Site도 마찬가지 였다. Git의 사상을 이해하지 못하여 SVN 처럼 사용하고 이에 따라 배포(=Deploy) 부분에 많은 문제점이 있었으며 그 결과 많은 장애가 유발되고 있었다. 

상세내용은 아래와 같다. 

1. Deploy Issue 사항

 - k8s Container Image 배포 관련 휴먼(배포정책) Error 다수 발생 

 - 사유: 개발 Project 1개를 여러 업무 Scrum에서 개발 및 배포하는 과정에서 소스 연계성 불일치로 인한 서버 Error 발생 

2. 주요 원인 

 - CI/CD Flow 를 점검하였을 때, Jenkins Pipeline 설계 부분에서 문제가 될 수 있는 부분을 발견함  

 - 1개의 Git Master 에서 QA서버 / Live서버 Image를 생성하여 배포하는 것이 가장 큰 문제점으로 진단함

 - 위 그림과 같이, k8s Image 배포 시 Git Master 에서 Image를 생성하여 QA와 Live 서버에 동일하게 배포 하고 있었음

 - 상세 Flow 분석시 아래와 같은 문제점 발견

  1) A개발자가 Git Master 에서 소스를 Pull 받은 후 개발 내역을 Push 함

  2) QA Test를 위하여 Git Master를 빌드하여 Image를 생성 후 QA서버에 배포함 

  3) A개발자가 배포한 내역 중 결함이 발견되어 소스를 다시 수정해야하는 상황 발생 

  4) 동시에 B개발자는 자신이 맡은 개발과 TEST를 모두 완료하여 Live 서버 배포가 필요함

  5) B개발자는 Git Master 를 빌드하여 Image를 생성 후 Live 서버에 배포함 

  6) 이 때,  A개발자의 소스가 함께 배포되어 의도치 않은 서버 Error 발생 (*)

3. 개선 방안

 1) Master는 Image 생성 시 Live서버로만 배포 진행 

 2) QA Branch의 Image 생성 시 QA서버로만 배포 진행

 위와 같이 Pipeline를 이원화하여 관리하여 문제점 해결 

4.  개선된 Git Flow 상세 

  1) Git Master 로 부터 Feature Branch 생성 

  2) 개발진행 

  3) 개발완료 시 DEV Branch 소스 Merge 진행 (개발자)

  4) DEV 배포 진행 (개발자)

  5) DEV 단위 Test 수행

  6) QA Branch 소스 Merge 진행 (개발자)

  7) QA 배포 진행 (개발자) 

  8) QA 통합 Test 수행

  9) 정기 배포일날 배포자가 Git Master 로 부터 Feature Branch 생성

 10) 배포 Feature Branch에 소스 Merge (개발자) 

 11) 배포 Feature Branch 를 Master로 소스 Merge 수행

 12) Master 빌드 및 Image 생성 후 Live 서버 배포 수행 

위와 같은 Git Flow로 개발을 진행 했을 경우, Issue를 해결 할 수 있었다. 

Git Flow의 경우 각 프로젝트 성격 및 상황에 맞게 구성할 수 있다. 

 ′12년도 부터 IT Career를 이어오면서 많은 Project를 경험했고 팀원으로서 수행 뿐 아니라 PM으로 Leading도 해보았다.

′23년도 12월에 문뜩 나는 Project Management 전문가인가? 스스로 물었을 때, 경험에 의존적일 뿐 공식적인 방법으로 증명할 수 없었다. 때문에, 그 동안의 Project 경험과 전문지식을 정리 할 겸 PMP 자격증을 취득하기로 마음먹었고 ′24년 4월에 Project Management Professional (PMP)®, PMP 자격증을 취득하였다. 

Project의 궁극적인 목표는 Value(가치) 창출이다. 여기서 Value란, 보통 재무적인 효과/이점을 뜻한다. 물론, 정량적인 Cost 효과가 아닌 정성적인 면도 존재하지만 이 부분도 결국엔 재무적 가치로 환산 되어야 한다. 재무효과에 대해서는 다음 번에 상세히 다뤄보도록 하겠다. 

PMP 작격증은 PMBOK 7판으로 취득하였고, 전체적인 로드맵은 아래 그림과 같다. 

[PMBOK 7판 Road Map]

1. 회사는 일반적으로 가치 창출을 위하여 내부적으로 포트폴리오를 관리하고 있으며, 하위 그룹으로 프로그램, 프로젝트가 존재한다. 프로젝트를 통해 포트폴리오 가치를 창출해 나간다. 

2. Project Manager (PM) 는 책임/존중/공정성/정직을 기반으로 Project를 Leading 한다. 

3. 프로젝트 12개의 원칙을 기반으로 조정 작업을 통해 프로젝트를 어떻게 성공적으로 이끌지 기획한다. 

 이 글을 읽으면서, 너무 이론적이고 이런 부분이 Project 성공에 도움이 될까?라고 생각할 수도 있다. 하지만 가치 창출을 이해하고 가치 창출을 위해 무엇에 기반을 둬야 하는지 살펴보면 도움이 된다는 것을 알게 될 것이다. 사실 여기서 가치 창출에 대해서만 이해하여도 큰 성과라고 생각한다. 

프로젝트 관리의 전체적인 로드맵을 이번 글에서 소개하였고, 각 세부사항은 다음글에서 상세히 알아보도록 하겠다. 

이전에 국내 유통사 기업 內 System Managemnet 업무를 하였을 때, Oracle DB Link와 관련된 트러블 슈팅 하나를 공유하고자 한다.

Legacy System의 경우, 유관 시스템 연계 (Interface) 필요시 DB Link를 사용한 경우가 많았다. 최근에 구축 된 시스템에서는 정보보안 취약점으로 인해 해당 부분을 지양하지만, 이전 Project 현장에서는 유관 시스템 연계가 필요할 시, 빠르고 간편하게 구현이 가능하다는 장점으로 DB Link를 종종 사용하였다. 하지만 해당 부분은 매우 Risk 하다. 

Oracle DB Link를 통해 아주 중요한 업무에 해당 되는 Interface를 구현하여 운영하였는데, 갑자기 DB Link 가 동작하지 않는 장애가 발생하였다. 원인은 Oracle SCN Bump-up Issue 였다. 

Oracle DB는 System Change Number 라는 SCN을 내부적으로 관리하며 동작된다. 해당 부분은 Oracle Version 별로 수치 영역이 달라질 수 있으며, 단독으로 사용할때는 특이사항이 없지만 DB Link에서는 아주 중요한 요소로 사용된다. 

해당 격차가 심할 경우 (SCN 범위) DB 간 DB Link Connection Reject가 발생 할 수 있다. 

SCN Bump-up 으로 인해 DB Link Connection Reject가 발생했다면, 방법은 하나 뿐이다. 최신 Patch를 통해 SCN 영역을 맞춰주는 방법 뿐이 없다. 

정리하면 다음과 같다.

1. Oracle DB Link 가 갑자기 Connection Reject 되었다면, SCN을 확인할것 

2. SCN Bump-up으로 인해 Connection Reject 부분이 확인되었다면, Oracle Patch를 통해 양 시스템 간 SCN 영역을 맞춰줄 것 

3. 장애 재발 방지를 위하여 DB Link는 지양하고, 기존에 DB Link로 구현된 Interface 부분은 개선하여 운영 할 것

SI/SM 업무를 진행하다 보면 시스템 구축을 성공적으로 하였더라도, Operation DML작업은 빈번하게 발생한다. Biz가 복잡하고 시스템 규모가 클수록 DML 작업은 신중하게 진행 해야한다. 휴먼 Error 또는 예상치 못한 상황으로 장애가 발생 할 수 있기 때문이다. 또한, DML작업 후 일정 기간이 지난 후에 Issue가 발견되는 경우도 종종 있기에 작업 이력 부분도 철저히 관리해야 한다. 

많은 프로젝트를 진행하며, 아래와 같이 DML 작업을 진행 했을 때 비교적 휴먼 Error를 많이 줄일 수 있었다.  

우선, ITSM 솔루션이나 변경관리 도구가 있다면 SR(Service Request)을 통해 작업 이력을 관리하는 것이 좋다. 작업 이력을 관리하면 좋은점은 2가지 정도가 있다.

첫번째, DML작업 또한 IT운영팀 內 지식관리로 활용 될 수 있다. 향후 유사한 작업이 발생한다면 과거 이력을 확인하여 작업을 계획 할 수 있으며, 이러한 활동은 휴먼 Error를 감소시키는 효과가 있다.

두 번째, DML 작업을 집계하여 지표로 활용 할 수 있다. DML작업은 운영과정에서 반드시일어나는 과정이기는 하나 그 작업 빈도수가 많다면 시스템상 Risk가 될 수 있다고 판단되며 해당 부분은 시스템을 개선하여 DML 작업 부분을 감소시킬 필요가 있다. 

실제 DML 작업은 다음과 같이 진행하는 것이 안전한다. 

1. 데이터 Backup, DML 작업 이후 작업 이전으로 되돌리는 작업은 쉽지 않다. 이러한 사유로 작업 대상 데이터를 미리 Backup 해두는 것이 안전한다. 

2. 데이터 트랜잭션 차단 확인, 안정적인 DML작업을 위해서는 User 혹은 시스템 I/F를 통한 트랜잭션이 일어나지 않는 것이 좋다. 작업 부분과 트랜잭션이 겹치게 되면 의도치 않은 결과가 나오기 때문이다.

 3. 데이터 작업

 4. 데이터 작업 검증, 데이터 작업 이후에는 반드시 검증을 진행해야 한다. 대상 범위 외 작업이 되었거나 대상임에도 불구하고 범위에서 제외되었다면 이러한 부분이 장애로 이어질 수 있기 때문인다. 

 5. Commit

위와 같은 단계로 DML 작업을 진행한다면 휴먼 Error를 줄일 수 있을 것이라고 생각된다.