모처럼 SQL문을 이용한 Quiz를 풀었다.
그런데 오랜만에 그래서인지 너무 어려웠다.-.-..

문제는 다음과 같다.

COL1	COL2
A	10
C	20
D	30
B	10

위의 테이블을 이용해서 다음과 같은 결과를 만들어 내는 거다.

COL1	COL2	누계
A	10	10
C	20	30
D	30	60
B	10	70

정답은? 다음 Query...

Select b.col1, b.col2, sum(a.col2) as "누계" From quiz_table a, quiz_table b Where a.rowid <= b.rowid Group by b.rowid

정말 간만에 땀을 좀 뺐네..ㅠ.ㅠ

현기증이 난다는 마님.

한동안 몸이 굉장히 피곤하고 무기력하고 어지럽다는 이야기를 듣고는 병원에 다녀오라고 했다. 특별히 내가 하루 휴가도 내고.

하루 동안 예람이는 어린이집에 가고, 예린이와 함께 있으면서 설거지, 빨래, 청소...를 하다보니 하루가 어찌 지나가는지도 모르게 지나가버린다.

애들을 8시면 재우라고 나한테 맡기고 밤 10시까지 예람이 유치원 교육인지 뭔지 때문에 나갔다. 애들을 재우려고 7시부터 누웠는데 내내 애들이 하는 얘기.

'엄마 보고 싶다.'
'엄마 빨리 오세요.'
'엄마는 언제 와?'

이런 애들을 어떻게 8시까지 재우라고 하는지..
도대체 무슨 애들 유치원에 대한 설명회를 몇시간씩 하는지..

아, 정말 스트레스 만땅이다.

그런데 우리 마님.
내가 이런 얘기를 하면 아마도 이렇게 얘기할 게 뻔하다.

'이제 육아의 힘든 것을 알겠지?'

에이. 애들이라도 빨리 잠을 잤으면 좋겠다. 이런 썩을.

아이들에게는 어딘가로 여행을 떠나 자연을 마음껏 경험하게 하는 것이 좋다.
사람들이 하는 말도 그렇고, 나도 그렇게 생각한다.

지난 주말에는 아이들을 데리고 서울대공원에 다녀왔다.
계속이 있는 곳이 자리 펴고 계곡 물에 몸도 담그게 했다.
여러 동물들도 보고, 물개-돌고래 쇼도 보았다.

그런데 아이들에게는 가장 즐거운 기억이 '코끼리 열차'를 탄 것이었나 보다.
집에 와서 하는 얘기가 온통 '코끼리 열차'를 또 타자는 것인 걸 보니....

그런데 요즘 아내도 그렇고, 나도 그렇고...
몸의 피로가 쉽게 풀리지 않는다.

안 그래도 요즘 몸이 안 좋다며 병원에서 진찰을 받아야 하는가를 고민하고 있는
아내에게는 나도 몸이 안 좋고 피로가 안 풀린다고 말할 수도 없고...

운동을 안해서 그런가?

아내에게만 운동 부족이라고 말할 것이 아니라 나도 이제 운동을 해야겠다.

피로를 이기는 체력!
그리고 체력을 이기는 정신력.
이 모두를 아우르는 영력까지.

그러자면.. 기도부터 하는 것이 옳다는 결론이 내려지는구만...^.^

방법론 엑소더스, 그리고 기민함의 시대로

방법론이란 소프트웨어를 만들어 내기 위해 행하는 모는 것을 의미하며
우리가 속한 그룹이 동의한 약속이다.
따라서 적절한 방법론을 가지고 있다면
체계적인 절차와 적합한 도구 및 기법을 사용하여
효율적으로 소프트웨어를 개발할 수 있게 된다.

그러나 방법론이 모든 문제를 해결하려고 시도하는 순간 자기 모순에 빠지게 된다.
그동안 우리는 모든 개발 문제를 해결해 줄 수 있는
보편적인 개발 방법론이 존재할 수 있으리라는 어리석은 생각에 빠지고 말았다.
방법론을 모든 질병을 치료해줄 만병 통치약으로 착각했던 것이다.

애석하게도 이것은 불가능하다.
다시 말해 방법론이 일반화되면 될수록 그 가치는 더욱 하락한다는 뜻이다.
모든 문제를 해결하기 위한 방법론이 만약 있다면,
역설적이게도 그 방법론은 구체적이고 특수한 문제를 해결하는 데에는
거의 도움을 주지 못할 것이다.

"애자일 동맹 선언"의 핵심은 다음의 4가지 문장으로 압축된다.

- 개인과 상호작용이 프로세스와 툴보다 우선이다.
- 동작하는 소프트웨어가 포괄적인 문서보다 우선이다.
- 고객 협력이 계약 협력보다 우선이다.
- 변화에 대한 반응이 계획을 따르는 것보다 우선이다.

변화의 수용과 즉각적인 피드백이 애자일의 모토로 자리잡으면서
개발 방법 역시 많은 변화를 겪게 되었다.

통합 시 실패에 대한 피드백을 받을 수 있는 방법은 무엇인가?
지속적인 통합(Continuous Integration)을 적용하라.

고객에게 원하는 가치를 제공하고 있는지에 대한
피드백을 받을 수 있는 방법은 무엇인가?
최대한 빨리 배포하고 반복(iteration) 주기를 통해 주기적으로 배포하라.

피드백 주기가 길어지는 사전 설계(Big Up-front Design)대신
피드백 주기가 짧은 TDD(Test-Driven Development)를 적용하라.

그리고 리팩토링(Refactoring)을 통해 설계와 코드를 지속적으로 개선함으로써
코드를 항상 최상의 상태로 유지하라.
점진적인 설계 사이클을 도입함으로써
설계와 구현을 독립적인 활동이 아닌 상호 영향을 주고 받는
유기적인 절차로 바라볼 수 있게 되었다.
따라서 경험을 기반으로 한 지속적인 리팩토링을 통해
최적의 소프트웨어의 설계를 얻을 수 있다.

애자일에서 강조하는 또 하나의 핵심 주제는 문서를 통한 의사소통을
가능하면 배제하고 이해관계자 간의 직접적인 대면과 대화를 통해
의사소통의 효율성을 촉진시키라는 것이다.

이것은 DDD를 지탱하는 두 가지 축 중 하나인 UBIQUITOUS LANGUAGE를 구축하기 위한 핵심 조건이다.

분석과 설계의 근본적인 차이는 분석이란 도메인을 이해하는 것인 반면,
설계는 도메인을 지원하는 소프트웨어를 이해하는 것이라는 점이다.
명확하게 이 두 가지는 밀접하게 연결되어 있으며 둘 사이의 경계가 매우 모호해질 때가 많다.
그러나 경계가 뚜렷할 필요는 없다. 유용성보다 순수성을 강조해서는 안 된다.
이론적으로는 분석인 동시에 설계의 특성을 가지는 하이브리드 모델이
절대로 좋은 것이 아니지만 이런 하이브리드한 특징이 가장 좋은 모델을 만든다고 믿는다.

분석 모델과 설계 모델의 하이브리드한 특징이 가장 좋은 모델을 낳는 토양이라면
프로그래밍 언어를 사용하여 구현한 코드가
이 모델을 최대한 반영하는 것이 가장 이상적일 것이다.

만약 설계 모델의 일부가 적용 기술 내에서 구현 불가능하다면 설계 모델을 변경해야 한다.
프로그래밍 과정 동안 설계의 실현 가능성과 정확성이 검증되고 테스트되며
그 결과 잘못된 설계가 수정되거나 새로운 설계로 대체된다.
따라서 프로그래밍은 설계의 한 과정이며 설계는 프로그래밍을 통해 개선된다.

분석/설계/구현이 별개의 것이 아닌 단일 행위라는 사상은
DDD를 지탱하는 두 가지 축 중 하나인 MODLE-DRIVEN DESIGN을 지지하는 핵심 사상이다.
이러한 분석/설계/구현에 대한 시각의 변화는
새로운 주류의 방법론이 출현할 수 있는 토양을 만들어 주었다.

애자일 진영이 바로 그것이다.