Extremely Agile

어떻게 어떻게 벌써 30회에 도달했군요. 그 동안 관심보여주신 여러분들 감사합니다. 올해 상반기 안에는 이 글이 어떻게든 끝날 것 같군요. ^^

[이전 글에서 계속...]

3.1. 네메아의 사자

"그래... 어쨌든 건강 잘 챙겨요. 몸에 안좋은 건 죄 끊는게 좋을거에요. 담배든 커피든... 녹차 같은 대체제도 활용해 보시구."

"그래야겠죠."

"그건 그렇고... 우리한테 떨어진 똥덩어리 이야기나 해 볼까요?"

그러자 유식이 웃으며 물었습니다.

"아까 팀장님이 일거리 주실 때 무슨 생각하셨어요?"

"글쎄...? 유식씨도 아시다시피 내가 생각이 많은 사람이 아니라서..."

헛 웃음을 웃어 보이자 그도 따라 웃었습니다.

"고객이 아무리 변심하더라도 절대로 바뀔 수 없는 요구사항들로는 어떤 것이 있다고 생각하세요?"

하지만 거푸 질문을 던지는 그의 표정은 사뭇 진지했습니다. 나는 대답했습니다.

"글쎄요. Scalability, Robustness, Availability 같은 것들이 그런 것 아닐까요? 그런 것들은 거의 대부분의 시스템에 요구되는 필수적 덕목이니까요."

그러자 유식이 고개를 끄덕였습니다.

"저도 그렇게 생각합니다. 그런 것들을 어떻게 보면 우리가 개발할 시스템이 갖추어야 할 플랫폼으로서의 속성이라고 부를 수도 있을 것 같은데요."

"플랫폼적 속성이라... 뭐 어차피 우리가 만들 시스템이 개발 플랫폼으로서의 역할을 하게 되니까, 그렇게 봐도 되겠군요."

그는 내 자리에 놓여 있던 자그마한 화이트보드에 마커로 그림을 그려 보였습니다.

"그러니까 이 자리에 우리 시스템이 있고, 이 자리에 우리 시스템 위에 놓일 비즈니스 로직들이 오고, 우리 시스템 아래쪽에 우리 시스템이 관리할 장비들이 놓이게 된다고 봤을 때, 결국 우리 시스템은 비즈니스 로직들이 요구하는 그런 불변조건들을 충족시켜야 된다는 건데요."

"그래서요?"

"그런 조건들을 만족시키는 작업이 우리가 가장 우선적으로 해야 할 일 아니냐 하는 것이죠."

그런데 나로선 그의 그런 말에 100% 동의할 수가 없었습니다.

"그런데 유식씨. 비즈니스 로직이 어떻게 작성될 지 잘 모르는 상태에서 확장성이나 가용성을 우리가 임의대로 설계해서 구현할 수 있을까요?"

"오대리님은 어렵다고 생각하세요?"

"비즈니스 로직이 어떻게 작성될 지를 모르잖아요. 그 말은, 우리가 방금 이야기했던 불변조건들이 그 로직에 어떤 형태로 제공될 지를 예측할 수 없다는 말도 되는 건데."

그러나 제 말에 100% 동의하지 않는 건 유식씨도 마찬가지였습니다.

"꼭 비즈니스 로직이 어떻게 작성될 지를 알아야 할까요?"

"그건 무슨 말?"

"이상적인 소프트웨어 플랫폼이라면, 개발자가 그런 불변조건들이 어떻게 만족되는지 모르도록 해야 할 것 같은데요. OLYMPUS 시스템을 놓고 보면, 비즈니스 로직이 놓여 실행될 수 있어야 하고, 장비와 통신이 가능해야 하고, 비즈니스 로직 간에도 통신이 가능해야 하고. 아주 단순하게 생각하자면 정도의 기능만 있으면 우선은 되는 것이거든요. 복잡한 부분은 오히려 그 위에 놓일 비즈니스 로직일 것 같구요. 오라클 같은 DBMS 쓸 때, 확장성이나 가용성 같은 조건이 어떻게 만족되는 지 생각해가면서 SQL 질의문 만드는 건 아니잖아요?"

"그러니까 유식씨 말은 기본적으로 OLYMPUS는 비즈니스 로직 및 관리 대상 장비 사이의 원활하고도 신뢰성있는 통신을 가능하게 하는 소프트웨어 플랫폼일 뿐이다?"

"네. 덤으로 DBMS 소프트웨어와의 통합도 간단히 지원하구요."

동의하지 않을 수 없었습니다. 그래서 우리는 함께 OLYMPUS가 반드시 갖추고 있어야 하는 '불변의 속성' 리스트를 만들기 시작했습니다. 그날 저녁때 쯤, 대략적인 윤곽이 드러났습니다. 대부분은 역할극 시간에 이미 살펴보았던 것들이더군요.

"이 중 가장 중요한 것은 무엇일까요?"

내 질문에 그가 고개를 갸웃거렸습니다.

"글쎄요..."

"우선 순위를 매기기 어렵다면 설계시 가장 기본적으로 고려되어야 하는 것 부터 따져 볼까요?"

"그러시죠. 오대리님 생각에는 뭐가 가장 기본인가요?"

기본이라... 그가 묻자 갑자기 옛날 생각들이 떠오르더군요. 프로젝트가 끝날 때 즈음 기다렸다는 듯이 밀어닥치던 버그들. 그리고 그 버그들을 교정하느라 하얗게 새버렸던 새벽들. 그 날들을 생각하니, 저는 한 가지 대답밖에는 할 수가 없더군요.

"동시성요."

"동시성이요?"

"네. 병행성(concurrency)이라고 해야 하나?"

"왜 그렇게 생각하시죠?"

"동시성을 고려하지 않고 설계되거나 개발된 소프트웨어는 비결정적(undeterministic) 버그를 만들어 내곤 하죠. 찾기도 어렵고, 찾아내더라도 언제 어느 순간에 시스템을 망가뜨리는 지 추적하기가 아주 곤란한 버그들."

그 말에 그가 반색하며 대답하더군요. 예전에 자기도 그런 문제 때문에 고생했던 적이 있었다는 거였습니다. 하긴 누군들 그런 경험이 없을까요.

"그런데 오대리님. 버그를 피하는 것이 소프트웨어 설계의 주된 목적이 되어서는 안될 것 같은데요."

"버그를 피하자는 것이 아니라, 설계 당시부터 그 점을 고려하지 않으면 견고한 시스템이 나올 수 없지 않겠느냐는 거죠. 소프트웨어의 모든 모듈을 무상태(stateless) 모듈로 만들 거라면 또 모를까..."

"하긴 그도 그렇군요. 그런데 동시성은 소프트웨어를 설계하는 출발점으로 잡기에는 지나치게 추상적이지 않나요? 어디 하나 구체적인 구석이 없으니...."

"확장성이나 가용성 같은 덕목들도 추상적이기는 마찬가지죠. 그런 면에서는 오히려 좀 더 구체적이라고 보는데..."

하지만 그렇게 이야기하는 나로서도 어떻게 첫 발걸음을 떼어 놓아야 할 지는 막막했습니다.

[다음 글에 계속...]