오늘의 이야기는 Orthogonal Persistence입니다. 예전에 한국 썬에서 JDO에 관한 글을 보니 persistence를 지속성으로 번역해놨던데, 조금 어색하더군요. persistence는 의미상 지속된다는 뜻이 있지만 이 경우에는 파일 시스템이나 데이터베이스에 영구저장이라는 의미가 강하니깐요. 합당한 번역어를 찾기 힘들 때는 원어를 살려쓴다는 원칙을 따라 persistence로 부르겠습니다.

일반적으로 프로그램은 하드 디스크에 저장된 기계어로 된 코드를 말하고, 프로세스는 이런 프로그램을 컴퓨터의 메모리로 로드하여 실행시킨 상태를 말합니다. 따라서 갑자기 전원을 꺼버리면 프로세스는 모두 날라가버리지만 프로그램이나 프로그램이 파일 시스템에 저장한 데이터만 남아있게 되는거죠. 여기서 어떤 데이터를 영속시킬 것인가하는 것은 전적으로 프로그램에게 달려있습니다.

요즘이야 일부 PDA나 스마트폰처럼 메인 메모리를 플래시(flash) 메모리로 사용하는 경우 전원이 나가도 현재 프로세스들이 그대로 보존되기도 하지만, 원래 전원이 나가면 메인 메모리에 로드된 데이터는 모두 날라가게 되죠.

orthogonal persistence는 프로그래밍 언어나 운영체제가 persistence를 보장해주는 경우를 말합니다. 전원이 갑자기 꺼지더라도 운영체제를 다시 부팅하면 원래 상태로 돌아가게 되는거죠. 이런 기능을 구현한 대표적인 운영체제로 존스 홉킨스 대학에서 리서치 프로젝트로 만든 OS인 EROS가 있습니다.

EROS 프로젝트를 처음 접한 것은 메릴랜드 교환학생 때 운영체제 수업을 들으면서였는데, 그 때 교수님이 이렇게 묻더군요. "파일 시스템이라는 게 꼭 필요한가?", "모든 운영체제는 파일 시스템이 있는가?", "파일 시스템의 목표가 일부 데이터를 영속적으로 저장하기 위한 것이라면 절대 데이터가 날라가지고 않고 껐다켜더라도 모든 데이터가 그대로 보존되어 있다면 굳이 파일 시스템에 저장할 필요가 있는가?"

우리는 파일 시스템의 존재를 당연히 여기지만 실제로 EROS는 파일 시스템이 없습니다. 정확히 말하자면 필요가 없습니다. 프로세스가 사용한 모든 데이터는 별도로 파일 시스템을 통해 저장하지 않더라도 OS가 자동으로 저장해주기 때문이죠. 원리를 간략히 요약하면 OS는 메인 메모리를 캐쉬처럼 쓰고 하드 디스크를 메인 메모리처럼 쓰는 것입니다.

상업적으로 널리 성공한 MS 윈도, 리눅스와 같은 기존 운영체제와는 달리, 기존의 관습을 무시하고 순순한 엔지니어링 관점에서 운영체제를 다시 디자인한다면 그 모습은 지금의 OS와는 상당히 다를지도 모르겠습니다.

S사에 면접 갔다가 회사 조직에 관한 설명을 들을 때 매트릭스 조직이라는 용어를 들었습니다. 정확히 어떤 용어인지 [백진원 기자의 경제 플러스]에서 찾아보니,


S사도 지역(한국 지사)라는 하나의 축과 제품이라는 또 하나의 축으로 구성된 매트릭스 조직이더군요.

장점으로는



물론 2명의 상사에게 보고하고 통제를 받는 이중적인 구조이기 때문에 관리자들과 구성원들 모두 원할하게 의사소통할 수 있고 정보와 권한 공유되어야 한다는 선결 조건이 있습니다.

S사의 경우도 한국 지사라는 지역 뿐만 아니라 제품을 기반으로 러시아, 이스라엘, 미국, 한국의 엔지니어가 유기적으로 묶여 있더군요. 덕분에 면접도 서울에서 1차 면접이 있었고, 2차로 이스라엘에서 전화가 걸려온답니다. 매트릭스 조직이라는 게 장단점이 있겠지만, 한국이라는 좁은 지역에서 일하면서 여러 나라에 분포된 직원들과 일한다는 것이 기대되기도 합니다.

이명헌의 경영스쿨에 가보니 조직행동론에 매트릭스 조직을 소개해놨는데, 끝맺음에 다음과 같이 나오더군요.



다 좋을 수는 없나봅니다.

방학동안 일했던 M사와 일을 어떻게 끝맺어야할지 모르겠군요. 계약서에 구체적으로 어떤 범위를 언제까지 구현할지 종료 조건은 무엇인지 명시하지 않은 게 화근이 되고 있습니다. 그냥 두루뭉술하게 프로젝트 해주겠다고 해놓았으니 요구사항이 바뀌거나 원래 없던 내용을 해달라고 해도 할 말이 없고, 기간이 명시되어 있지 않으니 한 없이 수정해달라고 해도 할 말이 없고 큰일이네요.

소프트웨어공학 시간에 대충 흘려들었던 내용이 이렇게 중요한 것인줄 이제서야 알았습니다. M사의 경우 외주 관리를 전혀 못하고 있는 게, 소프트웨어 개발을 맡겨놓고 진행상황도 전혀 묻지 않고, 테스트하고 싶다는데 환경 구축을 안 해줫 2-3주씩 일이 밀리고 하네요. 방학 끝으로 작업 시간을 못박아놨아야 하는데 실수입니다. M사 잘못으로 일정이 밀렸는데 이제 학교 다니면서 작업을 해줘야하는 상황이 되어버렸습니다.

이럴 경우엔 어떻게 해야 하는 걸까요?