CSV

컴퓨터 용어로, 표 형태의 데이터를 저장하는 파일 형식이다. 주로 쓰이는 확장자는 .csv이며 MIME 형식은 text/csv이다. 한글로 '씨에스브이'라고 읽는다.

한 줄이 한 개의 행에 해당하며, 열 사이에는 쉼표(,)를 넣어 구분한다.

예를 들어 학생기록부에 아래와 같은 데이터가 있다고 하자.

위의 데이터를 CSV 형식으로 저장하면 아래와 같은 형태가 된다.

이름,생년,월,일,국어 점수,영어 점수,수학 점수
홍길동,1992,7,17,100,90,70
희동이,1992,4,3,90,100,100

줄 바꿈 문자는 라인 피드(LF) 또는 캐리지 리턴-라인 피드(CRLF)를 사용한다.

표의 형태를 직관적으로 나타내는 간단한 형식이라 이해하기 쉬우며, 소프트웨어로 처리하는 것도 쉽다. 텍스트 기반 형식이라 사람이 직접 읽고 수정하는 것도 가능하다. XML과 같은 다른 텍스트 기반 형식에 비해 간결해서 차지하는 용량도 적다. 이런 표현이 익숙하지 않은 사람들을 위해, CSV를 표 기반으로 바꿔서 보여주는 툴도 많은 편이다.

단점은 데이터에 쉼표가 포함된 내용을 취급하기 곤란하다는 것. 예를 들어 천 단위마다 쉼표를 찍어 놓은 금액 데이터(100,000)를 CSV에 직접 집어넣으면 나중에 해석할 때 서로 다른 열로 취급되므로 문제가 된다. 해결책은 쉼표가 포함된 문자열을 따옴표로 감싸거나,[1] 쉼표 대신 탭 문자(\t)를 구분자로 사용하는 것이다. 후자의 경우 Tab-Separated Values(TSV)라고 부른다.

사실 CSV라는 데이터 구조 자체에 무슨 표준이 있는 것은 아니라서 구분자를 뭘로 쓰든 데이터를 주고받는 사이에 약속만 지키면 된다. CSV에서 사용하는 특수 문자는 필드 구분자와 레코드 구분자 둘 뿐이고 인용이나 이스케이프 문자는 선택 사양이다. 일반적으로 데이터 생산자가 CSV데이터의 성격을 보고 필드 안에 들어갈 확률이 가장 적은 문자를 필드 구분자로 정한다. 레코드 구분자 역시 필드에 줄바꿈이 자주 쓰일 경우 라인 피드 대신 널 문자(NULL)를 쓰기도 한다.[2]

일반적으로 CSV파일의 무결성을 검증할 때는 한 줄의 콤마 수를 센다. 모든 줄의 콤마 수는 다 같아야 하며 더 적거나 더 많은 줄이 발견되면 오류로 판단해 걸러내는 등의 적절한 처리를 할 필요가 있다. 가장 일반적으로 발견되는 오류는 다음과 같다.

최악은 CSV의 필드 안에 게시판 본문 데이터를 그냥 담는 것이다. 게시글 본문에는 쉼표, 따옴표, 줄바꿈문자가 모두 들어가기 때문에 데이터가 어떻게 깨졌는지, 심지어는 이게 깨진 레코드인지조차 모를 수도 있다. 예를 들어 게시글 본문 내용 자체가 CSV데이터일 경우 존재하지도 않는 유령 게시글이 하나 등록될 수 있다. CSV Injection 이 경우에는 아예 CSV 자체를 안 쓰는 게 정신건강에 좋다. 참고로 게시판 본문 데이터가 HTML일 경우가 끝판왕으로 XML을 써도 힘들다.[3][4]

테이블 덤프 등의 이유로 무조건 CSV를 써야 한다면 아예 게시판 본문 데이터 전체를 URI Encode하고 무조건 따옴표로 인용하면 데이터 크기가 커지고 편집기로 직접 못 읽지만 어쨌든 문제를 회피할 수 있다. 자바스크립트 사용자라면 encodeURI가 아닌 encodeURIComponent함수를 써야 제대로 이스케이프 처리된다.

보다시피 데이터 오염에 대단히 취약한 포맷이다 보니 본격적인 데이터 교환 포맷으로는 XML과 JSON을 쓴다. 둘 중 XML이 상대적으로 데이터 오염에 더 잘 견딘다. 하지만 CSV는 2017년 현재도 IT 및 산업계에서 널리 사용중인데 가장 결정적인 이유는 데이터의 크기가 작기 때문이다. JSON만 돼도 CSV대비 2배에서 3배 이상 데이터의 크기가 커지기 일쑤인데다 CSV 파서(parser)는 대단히 간단해서 인용 및 이스케이프 처리를 하지 않는 CSV 파서는 대부분의 프로그래밍 언어에서 코드 한 줄로 가능하다. 게다가 파일 일부에 문제가 생겨도 CSV의 오류는 보통 레코드 단위로 재동기화가 가능하다. JSON은 따옴표나 중괄호 같은 게 하나라도 누락되면 전체 JSON파일의 로드에 실패하는 치명적인 문제가 있다. XML의 경우에는 보통 문제가 생긴 엘리먼트의 부모 엘리먼트에까지만 오류가 전파되므로 CSV보다 더 강한 내결함성이 있지만 JSON보다도 더 데이터의 크기가 커져버린다. 만약 로드하려는 데이터가 기가바이트 단위를 바라본다면 몇 퍼센트의 데이터 오버헤드도 무시할 수 없는 문제가 되는데 이런 분야에서 CSV가 활약하는 것이다. 덤으로 CSV는 압축도 잘 되고 스트림 압축이 가능해서 데이터의 일부만 수신된 상태에서도 데이터 적재 작업을 시작할 수 있다.[5]

Creating Shared Values

하버드의 경영학자인 Michael Porter에 의해 처음 제안된 개념으로, CSR에서 한 단계 나아간 형태의 기업 운영 방식이다. 해당 용어 자체를 제목으로 한 "Creating Shared Values"라는 에세이에 등장하였으며, 기업에게 사회적 책임을 묻는 시대에 현실적인 해결안을 내놓은 방안으로 평가받는다.

해당 개념은 현대 기업이 사회의 요구와 본인의 목적 사이의 갈등을 해결하기 위한 방법론적 측면에서 등장한 개념이다. 시대가 나아갈수록 기업에게 사회적 책임을 요구하는 목소리는 점점 커지지만, 기업이란 애초에 돈을 버는 것에만 집중하게끔 만들어진 집단이므로 이러한 일을 해내는 것에 있어서 어려움을 겪는데, 이러한 문제를 해결하기 위해 등장한 것.

기업은 돈을 버는 일을 가장 잘 하는 집단이므로, 별도로 착한일을 만들어서 하기보다는, 기업 차원에서 사회와 공유하는 가치를 창출하여 이를 기업의 핵심 자산으로 삼고 발전시켜 나가면 돈을 벌려는 기업의 속성과 사회적 가치를 실천하라는 사회의 목소리를 동시에 충족시킬 수 있다는 내용이다.

기존의 CSR과 비교해서 이해하면 좀 더 빠르게 이해할 수 있는데, 기존의 CSR은 그저 단순히 사회에 필요하고 좋은 일을 해주는 것에 머물러 있었다면, CSV는 기업의 핵심 역량과 결부된 사회적 가치를 만들어서 이를 키워나가는 방식으로 기업을 성장시키면서도 사회에게 좋은 일을 해주는 방식이란 점에서 차이가 난다.

예컨대, 삼성전자라는 기업은 전자회사이기 때문에, 어려운 이웃을 돕기 위해 기부를 하거나, 임직원이 연탄을 나르거나, 자연보호를 위해 나무를 심는 일 따위는 CSR 차원에서는 긍정적인 일이지만, 까놓고 보면 삼성전자가 하기에는 별로 잘하지도 않는 일이고, 기업 자체에도 그닥 도움이 되지 못한다.

Closed System Vaporizor 참조.