소프트웨어 이야기

저희 팀에서는 Lego block과 같은 s/w의 단위를 module이라고 부릅니다.
alarm이라는 module을 작성하기로 하였죠.

alarm이란 매우 간단한 기능입니다.
예를 들어, 2009년 11월 11일 9시 00분 00초에 어떤 일을 하도록 하는 기능이죠.
구현하는 입장에서 보면
현재 시간을 계속 지켜 보다가 설정한 시간과 같으면 등록한 function을 불러주면 됩니다.

휴대폰에서 사용하는 알람 기능이나
Windows에서 사용하는 스케줄러 혹은 구글 캘린더에서 지원되는 흔한 기능입니다.
Linux/Solaris사용자라면 익숙하신 crontab의 기능과도 비슷하고요.

'하루면 끝낼 수 있겠다~' 하고 시작을 합니다.



작업을 하다 보니까, alarm의 기능이란 정확히 말해서는 반복 기능도 포함되더군요.
예를 들어 '매시 00분 00초에 무슨 일을 해라~' 와 같은 기능을 수행해야 합니다.

조금은 복잡해 보이지만, 이틀이면 끝낼 수 있을 것 같습니다.



조금 더 작업을 하다 보니, 반복에는 이런 기능도 필요하다는 것을 알게 되었습니다.
매달 말일에, 혹은 마지막 주의 금요일에 뭔가를 하라는 기능이죠.
정리를 해보니까, 매분, 매시, 매일, 매주, 매달, 매년 식의 기능이 필요하더군요.
이중에서도 매달의 경우에는 이런 방법도 됩니다.
매달 25일, 이건 쉽군요.
반면 요일을 사용하는 경우에는 조금 복잡해집니다.
매달 1번째 수요일, 매달 1번째 주일 (월-금), 매달 마지막 금요일 등과 같이 말입니다.
게다가 2주에 한번 과 같은 기능도 필요하고요.

구현 자체는 해 볼만 한데, 이것을 어떻게 API로 만들지가 고민입니다.
structure형태로 만들다 보니, 참으로 복잡해 지는 군요.
모든 기능을 추가해서 만들어 보니, '이 복잡한 것을 누가 쓸까?' 하는 생각이 듭니다.

게다가 1.1 버전에서 upgrade가 필요하게 되면,
backward compatibility를 지원하는 것이 힘들어 보입니다.



'backward compatibility를 지원하면서도,
쉽게 사용할 수 방법이 없을까?'

생각해낸 것은 시간을 string으로 표현하는 방법입니다.
예를 들어, 매 2주 간격으로 수요일 9시 00분 00초에 를 아래와 같이 표현하는 거죠.

"2 weekly wed 09:00:00"

string이기 때문에, 새로운 형태가 필요하면 쉽게 추가할 수 있습니다.
게다가 직관적이라서, 사용자는 행복할 것 같습니다.

그런데 개발자는 걱정이 태산입니다.
이미 일주일이 지나버렸고, "2 weekly wed 09:00:00" 과 같은 string을 처리하려면
parser도 작성을 해야 되기 때문이죠.

하루면 끝날 것 같았던 module이 1주일을 벌써 넘기고,
앞으로도 적어도 1~2주는 더 써야 할 것 같군요. 이것 참...



alarm 발생 부분의 동작부분은 간단합니다.
시간을 보면서 2009년 11월 11일 9시 00분 00초가 되면 alarm을 발생시키면 됩니다.
그런데 실제로 해보니, 8시 59분 59초에서 한번 돌고, 9시 00분 01초에 program이 도는 경우가
있더군요. 이런 CPU를 받지 못하는 starvation이 발생하기 때문에
시간이 같은지 만을 확인해서는 alarm을 발생시키지 못하는 버그가 발생합니다.

대신 시간을 비교해서, alarm 설정시간이 현재 시간보다 크거나 같으면 발생시켜야 합니다.
그런데, 시간을 비교하는 것이 생각만큼 간단하지 않습니다.
년,월,일,시,분,초를 모두 비교하다 보니,
time을 관리하는 module이 있으면 좋겠다는 생각이 듭니다.

마음이 급하지만, time module을 하나 더 만들기로 합니다.
이왕 하는 것, 2개의 time을 비교하거나, 더하거나, 빼거나 하는 기능도 만들기로 합니다.
현재의 시간을 읽는 interface도 추가를 하고요.

길어야 하루면 될 것 같습니다.



time module을 만든 후에 alarm에 적용을 하니,
CPU를 받지 못하는 starvation이 어느 정도 발생하여도 잘 동작합니다.
다행입니다.
하나의 alarm은 이제 잘 동작하니, 반복 alarm을 구현하고 시험합니다.

다행히, 반복기능의 구현은 쉬웠습니다.
그런데 시험을 하려고 하니, 막막합니다.

매분 alarm을 시험하려면 3~4분 기다리면 되지만,
매시 alarm을 시험하려면 3~4시간을 기다려야 합니다.
그 정도면 할만하지만 매주 alarm은 너무 길군요.
게다가 매월, 매년을 어떻게 시험합니까?
그렇다고 시험도 안 한 module에 완성이라는 도장을 찍을 수는 없고요.
이제 막바지인데, 마음이 답답해 지는 군요.



결국 생각해 낸 것은, '시간을 어떻게 빨리 흐르게 할 수 없을까?' 하는 것이었습니다.
alarm module은 현재시간을 time module로부터 얻기 때문에,
time module에서 현재 시간보다 조금 더 빠르게 시간을 넘겨주면
짧은 시간내에 시험이 가능할 것도 같았습니다.

결국 time module을 upgrade하여, 시간을 몇 배속으로 흐르게 하는 기능을 추가하였습니다.
10배, 100배, 1000배로 시간을 흐르게 하면서 시험을 하는 것이죠.
며칠 전에 time간에 빼거나 더하는 기능이 있어서 쉽게 구현을 했습니다.
시작한 시간에서 현재 시간을 뺀 다음, 여기에 몇 배를 곱한 후에, 다시 더하면 되더군요.

근데 적용을 해보니, alarm module의 시험에는 여러 가지 속도의 시간이 필요합니다.
매일은 10배라면, 매주는 100배, 매달은 1000배 이런 식이죠.
그러다 보니, 10배로 돌다가, 그 다음에 100배로 돌고 하는 연속 기능이 필요하더군요.

time module을 upgrade하는데 또 하루가 지나갑니다.



휴우~, 하루면 될 줄 알았는데, 벌써 한 달이 다되어 갑니다.
그나마 alarm module은 거의 완성이 되어 실제 프로젝트와 integration을 하였습니다.
예상대로 잘 동작합니다. 그렇게 시험을 했으니 잘 돌지 않을 이유가 없죠.

근데, alarm module사용자가 현재 설정된 alarm을 조회할 수 있는 기능을 원하더군요.
쉬운 기능이라고 하며 아래의 string의 list를 넘겨주었습니다.

"2 weekly wed 09:00:00"

사용자는 string을 받아 들고는 황당한 얼굴을 합니다.
UI 스케줄러에 표시를 해야 하는데, '제가 이걸 parsing해야 합니까?' 하는

결국 사용자는 structure 형태의 (XML이던, API던) data를 원했고,
설정은 string으로, 조회는 structure로 하는 일관성이 깨진 interface가 되어 버립니다.

일관성을 위해서는 structure로 설정과 조회를 하면 좋겠지만,
string이 사용하기 편하다는 이유로 그대로 놓아두고 맙니다.
사실 마음속 한구석에서는 이런 말을 하고 있는지도 모르겠습니다.
'parser를 작성하며 사용한 2주의 시간을 의미 없이 버릴 수는 없자나...'



간단해 보이는 alarm module하나도
가보지 않은 상태에서 그것을 예상하기란 참으로,
간단하지 않은 일 같습니다.

고맙습니다.

제임스 드림