데이터베이스는 왜 필요할까? 엑셀과 파일 저장의 한계

지난 글에서는 웹페이지가 화면에 나타나기까지 브라우저와 웹서버가 어떤 일을 하는지 살펴보았다. 주소 하나를 입력하고 기다리는 짧은 시간에도 브라우저는 필요한 자료를 요청하고, 서버는 그 요청에 맞는 내용을 찾아 다시 보내준다.

그런데 서버가 무엇인가를 찾아 보내려면 당연히 그 정보가 먼저 어딘가에 있어야 한다.

쇼핑몰에서 지난달 주문내역을 눌렀는데 내가 구입한 상품이 바로 나타난다. 은행에서는 몇 달 전 거래내역까지 확인할 수 있다. 회사의 업무시스템에서도 오래전에 등록한 장비나 계약, 업무기록을 다시 찾아볼 수 있다.

이런 자료는 화면을 열 때마다 새로 생기는 것이 아니다. 이전에 입력하고 처리한 정보가 계속 저장되어 있기 때문에 다시 꺼내볼 수 있다.

여기까지는 어렵지 않다. 컴퓨터에는 원래 파일을 저장할 수 있기 때문이다. 고객명단은 엑셀로 만들면 되고 업무내용은 문서로 남길 수도 있다. 그런데 실제 정보체계에서는 왜 파일만 사용하지 않고 데이터베이스를 따로 두는 것일까?

한줄 요약
파일도 정보를 저장하는 좋은 방법이다. 다만 같은 자료를 여러 사람이 사용하고 데이터가 계속 늘어나 서로 연결되기 시작하면, 저장보다 관리하고 찾아 쓰는 일이 더 어려워진다. 데이터베이스는 바로 이 지점에서 필요해진다.

엑셀 파일 하나로 충분한 일도 많다

직원 열 명의 이름과 전화번호를 관리한다고 해서 데이터베이스를 구축할 필요는 없다. 엑셀 파일 하나를 만들고 이름, 부서, 전화번호를 적어두는 편이 훨씬 간단하다.

자료가 많지 않고 한두 사람이 관리한다면 오히려 이쪽이 편하다. 필요한 내용을 바로 고칠 수 있고 다른 사람에게 파일을 보내기도 쉽다.

직원 이름과 전화번호만 있던 파일에 직급과 담당업무가 붙고, 교육이력과 프로젝트 참여현황까지 관리하기 시작하면 사정이 달라진다. 인사부서와 사업부서가 각자 필요한 자료를 만들다 보면 같은 직원의 이름과 소속이 여러 파일에 들어가는 일도 생긴다.

누군가 내용을 고쳐 메일이나 메신저로 보내면 다른 사람이 다시 수정한다. 파일 이름 뒤에 ‘수정’이 붙고, 다시 ‘최종’이 붙는다. 며칠 지나면 ‘최종수정’이나 ‘진짜최종’ 같은 파일이 나타나기도 한다.

실제 업무에서 이런 파일을 여러 번 접해봤다면 무엇이 불편한지 금방 알 수 있다. 파일이 많다는 것보다 어느 자료가 지금 맞는 자료인지 확인하는 데 시간이 든다.

직원이 다른 부서로 이동했는데 인사부서 파일에는 새로운 소속이 적혀 있고 사업부서 파일에는 예전 부서가 남아 있을 수도 있다. 전화번호 하나를 바꾸더라도 같은 정보가 들어 있는 파일을 찾아 하나씩 수정해야 한다.

물론 이것이 엑셀이나 파일의 문제라는 뜻은 아니다. 사진과 문서처럼 파일 자체로 보관하는 것이 자연스러운 자료도 많고, 규모가 작은 업무에서는 엑셀만큼 편한 도구도 드물다.

다만 같은 정보를 여러 곳에 반복해서 적기 시작하면 관리방법을 다시 생각해야 할 시점이 온다.

쇼핑몰의 주문을 파일로 관리해보면 더 복잡해진다

쇼핑몰에는 상품목록만 있는 것이 아니다. 회원이 가입하면 고객정보가 생기고 상품을 구입하면 주문기록이 남는다. 결제가 끝났는지 확인해야 하고 물건을 보냈다면 배송상태도 관리해야 한다.

한 사람이 여러 번 주문할 수 있고 한 번의 주문에 상품 여러 개가 들어갈 수도 있다. 같은 상품을 수천 명이 구입하는 일도 생긴다.

엑셀로 관리한다고 해서 처음부터 불가능한 것은 아니다. 고객 파일, 상품 파일, 주문 파일을 각각 만들어 사용할 수도 있다.

주문이 몇십 건일 때는 큰 문제가 없어 보인다. 몇만 건, 몇십만 건이 쌓이면 같은 방법으로 계속 관리하기가 쉽지 않다.

주문 파일에 고객 이름과 전화번호, 주소를 매번 적는다고 하면 같은 고객의 정보가 주문할 때마다 반복해서 들어간다. 고객이 이사해 주소를 바꾸었을 때 과거 주문에 적힌 주소까지 모두 새로운 주소로 바꾸어야 하는지도 애매해진다.

그래서 데이터베이스에서는 성격이 다른 정보를 나누어 관리하고 서로 필요한 부분을 연결하는 방식을 많이 사용한다.

고객에게 고유한 번호를 하나 부여해두면 주문을 기록할 때 고객의 모든 정보를 다시 적지 않고 그 번호를 연결할 수 있다. 주문을 한 사람이 누구인지 확인해야 할 때 연결된 고객정보를 찾아보면 된다.

이렇게 사용하기 시작하면 데이터베이스가 단순히 파일보다 큰 저장창고는 아니라는 점이 보인다.

실제 업무의 데이터는 서로 떨어져 있는 경우보다 연결되어 있는 경우가 많다. 직원은 조직에 속하고 장비에는 운용부서가 있다. 장비를 정비하면 정비기록이 남고 장애가 발생하면 장애이력이 쌓인다.

쇼핑몰의 고객과 주문이 연결되는 것처럼 정보체계 안의 데이터도 서로 관계를 가진 채 쌓인다. 데이터가 많아질수록 이 관계를 어떻게 관리할지가 중요해진다.

저장해 놓았는데 찾지 못하면 쓸 수 없는 정보가 된다

서류 열 장에서 필요한 문서를 찾는 일은 어렵지 않다. 백 장 정도라면 시간이 조금 걸려도 직접 넘겨볼 수 있다. 그 숫자가 백만 장이라면 같은 방법을 사용할 수 없다.

컴퓨터에 저장된 데이터도 마찬가지다.

쇼핑몰에서 지난해 구입한 상품 하나를 확인하기 위해 전체 고객의 주문기록을 처음부터 읽어 내려갈 수는 없다. 로그인한 사람이 누구인지 확인하고, 그 사람의 주문 가운데 원하는 기간의 기록만 찾아야 한다.

정보체계를 사용하는 현장에서는 이런 검색이 생각보다 중요하다. 장애가 발생한 장비의 과거 정비이력을 확인하려는데 담당자가 파일 수십 개를 열어봐야 한다면 전산화의 의미가 크게 줄어든다.

장비번호를 입력했을 때 해당 장비의 정보와 장애이력, 정비기록을 필요한 조건에 맞춰 확인할 수 있어야 실제 업무에서 쓸 만한 데이터가 된다.

데이터베이스에서는 조건을 이용해 필요한 자료를 골라낼 수 있다. 날짜를 기준으로 찾을 수도 있고 특정 사용자나 장비, 상품에 관련된 기록만 조회할 수도 있다. 여러 조건을 함께 적용하는 것도 가능하다.

데이터베이스를 배우다 보면 SQL이라는 말도 이쯤에서 자주 등장한다. SQL은 저장된 데이터를 조회하거나 새로운 내용을 입력하고 기존 자료를 수정할 때 널리 사용하는 언어다.

지금 단계에서 SQL 문법까지 들어갈 필요는 없다. 오히려 기억해둘 것은 따로 있다. 데이터가 많아지면 얼마나 많이 저장할 수 있는가 못지않게 필요한 내용을 얼마나 제대로 찾아 쓸 수 있는가가 중요해진다는 점이다.

혼자 쓰던 파일을 여러 사람이 함께 쓰기 시작하면

내 컴퓨터에 있는 엑셀 파일을 혼자 수정할 때는 누가 먼저 저장했는지 따질 일이 거의 없다.

은행이나 쇼핑몰, 회사의 업무시스템에서는 같은 시간에 많은 사람이 데이터를 사용한다.

쇼핑몰에 상품 하나가 남아 있는데 두 사람이 거의 동시에 주문할 수 있다. 재고는 하나인데 두 주문을 모두 정상으로 처리한다면 나중에 한 사람에게는 물건을 보내지 못하는 일이 생긴다.

은행의 계좌라면 훨씬 민감하다. 돈이 입금되는 순간 다른 곳에서는 출금이 이루어질 수 있다. 여러 거래가 동시에 진행되어도 마지막에 표시되는 잔액은 정확해야 한다.

회사에서도 한 사람이 자료를 수정하는 동안 다른 사람이 같은 내용을 변경할 수 있다. 먼저 저장한 사람의 작업이 사라지거나 서로 다른 내용이 뒤섞이면 업무자료를 믿기 어려워진다.

데이터베이스를 관리하는 소프트웨어에는 이런 상황을 처리하기 위한 기능이 들어 있다. 여러 사람이 같은 데이터를 사용하더라도 작업이 함부로 뒤엉키지 않도록 관리하는 것이다.

데이터베이스 이야기를 하다 보면 DBMS라는 말도 자주 만난다. 둘을 같은 의미처럼 사용하는 경우도 있지만 엄밀하게 보면 조금 다르다.

데이터베이스가 일정한 구조로 저장하고 관리하는 데이터의 집합이라면 DBMS는 그 데이터를 저장하고 조회하고 수정할 수 있도록 관리하는 소프트웨어다. Oracle Database, MySQL, PostgreSQL처럼 서버 환경에서 많이 접하는 이름들이 이 영역에 해당한다.

사용자가 이 과정을 직접 볼 일은 거의 없다. 주문 버튼을 누르면 주문이 접수되고 조회 버튼을 누르면 필요한 정보가 화면에 나타난다. 그 뒤에서 데이터가 어떤 순서로 처리되는지는 화면에 드러나지 않는다.

사용하는 사람이 이런 복잡한 과정을 신경 쓰지 않아도 된다는 것은 오히려 잘 만들어진 정보체계가 갖춰야 할 조건에 가깝다.

지난 글에서 본 웹페이지 뒤에도 데이터가 있었다

지난 글에서 살펴본 웹페이지로 다시 돌아가면 지금까지 따로 알아본 기술들이 어느 지점에서 만나는지 볼 수 있다.

쇼핑몰에서 주문내역을 눌렀을 때 브라우저는 서버에 요청을 보낸다. 서버에서는 로그인한 사람이 누구인지 확인하고 그 사람에게 보여줄 주문기록을 찾아야 한다.

데이터베이스에서 필요한 기록을 찾은 뒤 그 결과가 다시 네트워크를 건너와야 비로소 브라우저 화면에서 주문내역을 볼 수 있다.

사용자가 보는 것은 화면에 나타난 주문번호와 상품명, 주문날짜 정도다. 하지만 그 몇 줄을 보여주기 위해서도 앞에서 살펴본 네트워크와 서버, 데이터베이스가 함께 움직인다.

인터넷을 사용할 때 이런 구조를 매번 의식할 필요는 없다. 아무 생각 없이 주문내역을 열고 필요한 정보가 바로 나타나는 것이 오히려 자연스럽다.

정보체계를 오래 사용하다 보면 화면의 기능보다 그 뒤에 있는 데이터가 더 중요하게 느껴지는 순간이 있다.

메뉴의 위치나 버튼 모양은 고칠 수 있다. 화면 구성도 시간이 지나면 바뀐다. 하지만 같은 장비의 정보가 화면마다 다르게 나타나거나 과거 기록을 찾을 수 없다면 이야기가 달라진다.

군의 정보체계에서도 통신망을 통해 정보가 빠르게 들어오는 것만으로는 충분하지 않다. 들어온 정보가 어떤 기준으로 저장되고 서로 다른 체계와 자료 사이에서 같은 의미로 사용되는지도 중요하다.

필요한 정보를 찾지 못하면 빠른 통신망의 장점을 제대로 살리기 어렵다. 반대로 좋은 데이터를 가지고 있어도 필요한 곳에 제때 전달하지 못하면 활용하기 어렵다. 지금까지 따라온 통신의 이야기와 데이터의 이야기가 이 지점에서 자연스럽게 만난다.

짧은 생각
군에서 정보체계를 사용하다 보면 처음에는 화면에 보이는 기능에 관심이 간다. 하지만 오래 사용하다 보면 그 화면에 어떤 데이터가 들어오고, 그 데이터를 얼마나 믿을 수 있는지가 더 중요하게 느껴진다. 필요한 정보가 제대로 쌓이지 않으면 좋은 화면도 소용이 없고, 잘 저장된 정보라도 제때 꺼내 쓰지 못하면 마찬가지다.

데이터를 어디에 넣을지도 미리 정해야 한다

데이터베이스를 사용한다고 해서 자료를 한곳에 모아 넣기만 하면 되는 것은 아니다.

쇼핑몰이라면 고객 이름과 주소, 상품, 주문내역, 결제정보를 어떤 기준으로 나눌 것인지 정해야 한다. 서로 연결할 정보가 무엇인지도 생각해야 한다.

같은 내용을 여러 곳에 반복해서 저장하면 앞에서 보았던 파일 관리의 문제가 데이터베이스 안에서도 생길 수 있다.

그래서 실제로 데이터를 저장하기 전에는 구조를 먼저 설계한다. 무엇을 따로 관리하고 무엇을 서로 연결할지 정하는 작업이다.

데이터베이스를 처음 보면 엑셀과 비슷하다는 느낌을 받기도 한다. 가로와 세로로 칸이 나뉘어 있고 그 안에 이름이나 숫자 같은 값이 들어가기 때문이다.

‘결국 아주 큰 엑셀 아닌가?’라고 생각할 수도 있다.

겉모습만 놓고 보면 그렇게 느낄 만하다. 하지만 데이터를 다루는 방법까지 같은 것은 아니다.

다음 글에서는 데이터베이스의 테이블은 엑셀 표와 무엇이 다른지 살펴보려 한다. 테이블과 행, 열을 이해하고 나면 지금 이야기한 고객과 주문, 장비와 정비이력이 데이터베이스 안에서 어떻게 나뉘고 연결되는지도 조금 더 구체적으로 볼 수 있다.