데이터베이스 병행제어 실패 현상의 표준 표현

다수의 사람이 동시에 이용하는 데이터베이스에서 일관성을 유지하기 위해선 병행제어 기법이 필수이다. 하지만 수많은 경우의 수 속에서 완벽한 병행제어란 쉬운 것이 아니다. 병행제어를 나이브하게 하면 데이터의 일관성이 유지되지 않는 등 오류가 발생할 수 있고 너무  엄격하게 하려고 하면 속도가 느려지거나 지연시간이 길어지는 불편함을 겪게 된다.

그래서 흔히 사용되는 고신뢰 기업용 데이터베이스(Oracle, PostgreSQL 등)도 완벽한 병행제어를 제공하진 않는다. 옵션으로 제공하긴 하지만 대부분의 default 값은 조금 완화된 수준이다.
 
그렇다면 병행제어를 좀 덜 엄격하게 하면 발생되는 현상이 무엇일까? 예를 들면 한 트랜잭션 내에서 데이터를 여러번 읽는데 값이 바뀐다던가 하는 문제가 생길 수 있는데, 이런 현상들을 가리키는 말이 여러가지라는 것이 문제이다. 내가 예로 든 현상은 누군가는 Dirty Read라고 하고 누군가는 Uncommitted Dependency라고 하고 누군가는 Inconsistency라고 한다. 구글에 3가지로 모두 검색해도 유사한 내용이 나온다.

이런 혼란 속에서 우리는 '표준'을 참고할 수 있다. 이에 대해 정의된 대표적인 표준으로 ANSI/ISO SQL 92가 있다. 우리가 흔히 사용하는 SQL에 대한 오래된 표준인데, 여기서 '트랜잭션 고립화 수준(Transaction Isolation Level)'을 다룬다. 그리고 그 파트에 병행제어 실패 현상에 대해 아래 3가지로 정의하고 있다.

P1. Dirty Read

P2. Non-Repeatable Read

P3. Phantom

 

1) P1 ("Dirty read"): SQL-transaction T1 modifies a row. SQL- transaction T2 then reads that row before T1 performs a COMMIT. If T1 then performs a ROLLBACK, T2 will have read a row that was never committed and that may thus be considered to have never existed.

2) P2 ("Non-repeatable read"): SQL-transaction T1 reads a row. SQL- transaction T2 then modifies or deletes that row and performs a COMMIT. If T1 then attempts to reread the row, it may receive the modified value or discover that the row has been deleted.

3) P3 ("Phantom"): SQL-transaction T1 reads the set of rows N that satisfy some <search condition>. SQL-transaction T2 then executes SQL-statements that generate one or more rows that satisfy the <search condition> used by SQL-transaction T1. If SQL-transaction T1 then repeats the initial read with the same <search condition>, it obtains a different collection of rows.

 

이 3가지에 대한 설명은 IT위키 - 데이터베이스 병행제어에 잘 정리되어 있다.

나도 정말 여러가지 표현을 보았지만, 국제 표준은 괜히 국제 표준이 아니다. 저 3가지의 케이스면 병행제어 실패 현상이 거의 깔끔하게 설명이 된다. 물론 가장 낮은 수준의 병행제어 실패 현상인 Dirty Write가 정의되지 않았다는 비판이 있긴 하다. <A Critique of ANSI SQL Isolation Level>라는 Microsoft의 논문에서는 Dirty Write를 아래와 같이 정의한다.

 

P0 ("Dirty Write"): Transaction T1 modifies a data item. Another transaction T2 then further modifies that data item before T1 performs a COMMIT or ROLLBACK. If T1 or T2 then performs a ROLLBACK, it is unclear what the correct data value should be. The broad interpretation of this is:

P0: w1[x]...w2[x]...((c1 or a1) and (c2 or a2) in any order)

 

이렇게 3가지 또는 4가지 표현으로 정리가 되고 인용이된지 20년이 넘었지만, 너무 오래되어서 업데이트가 된 것인지, 잊혀진 것인지, 아니면 국내에서 20년동안 국제 표준에 너무 무관심했던 탓인지 여러 블로그나 DB교재 등에선 아직 다양한 표현들이 쓰인다.

대표적으로 국내 정보처리기사에선  갱신 분실(Lost Update), 비완료 의존성(Uncommitted Dependency), 모순성(Inconsistency) 이라는 표현이 쓰이고

 

국내 정보관리기술사·컴퓨터시스템응용기술사 학원과 수험서에서는 갱신 분실, 현황파악오류, 모순성, 연쇄 복귀의 앞을자를 따 '갱현모연'이 거의 FM처럼 인용된다. (누군가는 답안지에 국제 표준식 용어를 썼다가, 학원에서 갱.현.모.연.으로 제대로 외우고 쓰라고 지적을 받았다는 이야기도 있다.)

 

물론 어느 표현도 틀린 말은 아니지만, 표준화된 표현은 아니다. 각 수험 교재에서 쓰이는 표현들을 개별적으로 검색하면 교재에서 설명된 내용대로 검색이 된다. 하지만 이를 한번에 모아서 검색해보면 그렇게 모아서 정리한 내용은 검색되지 않는다. 즉 데이터베이스 병행제어 현상을 갱.현.모.연으로 정리한 것은 표준화된 내용은 아닌 것이다. 분명 시험 문제나 DB 교재를 작성한 누군가가 본인이 쓰는 용어를 기준으로 어딘가에 기술했고, 그게 인용되다 보니 굳어지게 된 것이리라.

 

내가 파악한 바로는 아래와 같이 대응된다. (혹시 잘못된 파악한 내용이 있으면 댓글을 부탁드립니다.)

P0. Dirty Write - Lost Update - 갱신 분실
P1. Dirty Read - Uncommitted Dependency - 비완료 의존성
 * 여기서 미완료 의존성은 Phantom Read를 포함하는 개념으로 볼 수도 있다.
P2. Non-Repeatable Read - Inconsistency - 모순성
P3. Phantom - 국내 교재에선 Phantom를 잘 다루지 않는다.

그리고 아래는 국내 교재에 등장하는 말이지만, 트랜잭션 고립화 수준에선 다루지 않는 내용이다.
Cascade Rollback, Unrecoverable

이는 병행제어 수준의 기준이 되기 보단 Dirty Write의 후속 문제로 볼 수 있는 부분이기도 하다.

 

누가 어떤 표현을 쓰더라도 누가 뭐라 할 순 없다. ISO가 국제 표준이지만, 표준 하나 20만원씩 받고 사야 되는거 안지켰다고 누가 뭐라 하겠는가. 나도 1992년 표준인 ANSI/ISO SQL 92 보다 더 업데이트된 SQL 표준들을 확인하고 싶었지만 가격 부담으로 그러지 못하였다. (혹시 2016년 이후 버전 가지고 계신분 있으시면 확인 부탁드립니다.)

 

하지만 적어도 학원이나 교재를 출판하는 출판사, 문제를 출제하는 출제위 측에선 글로벌에서 소통을 해야 되는 한국 IT 인재들을 위해 이런 용어들을 좀 통일해보겠다고 하는 의지가 있었으면 하는 마음에 포스팅을 한다.

 

참고로 정보관리기술사 제121회에선 아래와 같은 문제가 나와서 무척이나 반가웠다.

 

2. DBMS 병행수행(Concurrency)제어가 되지 않는 경우 발생할 수 있는 3가지 문제와 그 해결 방법에 대하여 예시를 들어 각각 설명하시오.

 

기술사 학원에서 흔히 가르치는 4가지가 아니라 국제 표준의 3가지를 묻는 질문이다! 정말 명확한 질문임에도 이 문제를 해설하는 모 학원에서는 '갱.현.모.연' 중 어떤 걸 빼야 하는지에 대해서 갸우뚱 하면서 왜 3가지로 냈을까에 대한 의문을 가졌다는 후문이 있어서 좀 안타깝기도 했다.