[DB/공부일지] File Processing System

MySQL, PostgreSQL, MariaDB, NoSQL 등 데이터를 효율적으로 관리하기 위해서 사람들이 많이 쓰는 DB들의 종류이다. 그렇다면 이러한 DB가 나오기 전에는 어떻게 데이터들을 관리하고 처리했는지 알아보도록 하자.

File Processing System

통칭 파일 처리 시스템은 1960년 대에 데이터를 관리하던 방식으로 파일을 이용해 데이터를 관리했다 라고 생각하면 된다.

예를 들어 인사 부서는 인사 파일을, 회계 부서는 회계 파일을, 영업 부서는 영업 파일을 각각 독립적으로 유지하는 방식이다.

이러한 방식은 초기에는 비교적 단순하고 이해하기 쉽다는 장점이 있었다. 각 부서가 자신의 업무에 맞게 프로그램을 개발하고 해당 프로그램이 사용할 데이터 파일을 직접 정의하여서 운영하였다. 

 

그러나 조직 규모가 커지고 업무가 복잡해질수록 파일 처리 시스템 방식의 한계가 등장하기 시작했다.

부서마다 개별적으로 따로 데이터를 관리하기에 동일한 데이터가 부서마다 있어도 중복된 데이터인지도 모르고 같은 데이터라도 형식이나 의미가 다르게 정의되기 시작했다. 이로 인해서 데이터의 일관성이 떨어지고 조직 차원에서 확장성이 많이 낮아졌다.

위 그림을 보면서 예시를 설명하겠다. 예를 들어 인사 팀과 회계 팀이 동시에 사용하는 정보가 있다고 하자. 그러나 두 시스템이 각각 독립된 정보를 유지한다면 한쪽만 수정되는 등의 경우들이 일어나 Data Inconsistency가 발생할지도 모른다.

 

또한 데이터 구조가 프로그램 내부에 정의되는 경우가 많을텐데 만약 파일의 형식이나 항목 구성이 바뀌면 프로그램도 수정해야한다는 말이다. 이것을 강한 결합이라고 하는데 새로운 요구사항에 대한 대응 속도가 많이 낮아진다.

 

 

파일 처리 시스템의 문제점들

1. Data Redunbancy

위에서 말한 문제점으로 데이터 중복이 가장 대표적인 문제이다. 동일한 데이터가 여러 프로그램, 즉 여러 부서에 반복 저장될 수도 있다. 이것은 조직 차원에서 너무 비효율적이며 데이터 수정과 관리의 복잡성 또한 증가시키게 한다.

2. Data Inconsistency

위 데이터 중복이 발생하면 이 Inconsistency가 자연스럽게 나올 수 있다. 인사 팀과 회계 팀이 직원의 월급을 담당하고 있다고 해보자. 만약 회계 팀과 급여 팀에서 한 사람의 월급이 다르다면 두 시스템이 충돌하게 될 것이다. 이것은 데이터에 대한 신뢰도를 떨어뜨리면서 큰 후폭풍으로 이어질 수도 있다. 

3. Program - Data Dependence

위에서 말한 강한 연결로 프로그램 안에 데이터 구조 등이 있다면 바뀌었을 때, 프로그램도 코딩을 다시해야한다는 문제점이다. 당연히 유지보수 비용이 증가되고 확장성이 많이 떨어질 것이다.

4. 데이터 공유의 어려움

각 부서별로 독립적으로 관리하고 있기 때문에 데이터 공유는 당연히 쉽지 않을 것이다. 이것은 조직 전체의 업무 흐름을 통합적으로 파악하기 어렵고 비효율적이다.

5. 데이터 접근성의 제한

파일 처리 시스템 환경에서는 사용자가 데이터를 직접 자유롭게 조회하기 어렵다. 그 프로그램을 통해서만 접근할 수 있기 때문에 또 조회용 프로그램을 별도 개발해야할 것이다. 

6. 유지보수 비용의 증가

위에서 말했던 단점들에서 나왔던 문제점으로 비효율적이기 때문에 당연히 유지보수 비용이 증가할 수 밖에 없다. 데이터 구조가 바뀌면 관련 프로그램들과 파일들을 다 점검하고 심지어 오류를 추적하는 것도 독립적인 특성 때문에 훨씬 오래 걸릴 것이다. 

 

그래서 이러한 파일 처리 시스템의 한계를 극복하기 위해 등장한 개념이 Database Approach이다. 

다음 시간에 알아보도록 하자

 

출처

https://wikidocs.net/333735

1.2. 파일 처리 시스템