어쨌건간에 흘러가는 者

Once

(어쨌건간에) — Sun, 27 Jul 2008 01:49:56 +0900

제일 먼저 느낀 것. '역시 균형이 중요해'.

나 자신의 인성적 균형에 관한 말이다. 어떤 이유로건 간에 근 몇 년 동안을, 말라버린 '감수성' 언저리에서, 기껏해야 모니터 속 작은 화면을 통한 영화와 어쩌다 한 번씩 찾는 극장, 귀에 달라붙은 MP3를 통해서만 힘겹게 보충하고 있는 상태이다. 고상하게 표현하자면, 감수성을 보충하는 주된 행동은 소위 '가상화된' 무엇일 뿐이라는 뜻. 본 영화 Once는 어느덧 잊혀간 감수성에 관한 '실제'의 무엇을, 필요성을 상기시킨 무엇인데... 가만 생각해보니, 요즘 우리나라 돌아가는 꼬락서니를 봐선 내게 그러한 여유가 있다 하더라도 그 여유를 감수성에 관계된 무엇에 투자하기란 쉽지 않겠다는 생각이 스치네. '쥐새끼가 만들어가는 공안정국' 땜시.

Once

거리의 실력 있는 음악가, 하지만 생업은 수리공. 우연찮이 그를 지나치는 묘령의 이쁘장한 여인, 하지만 애가 딸린, 남편과 별거 중인 유부녀. 불쑥 이야기가 오가더니만 순 십간에 깊은 대화를 나누더니 함께 노래까지 부르네? 어느새 음악가와 여인은 음반 제작을 기획하고 순십간에 돈을 마련함과 동시에 session man과 스튜디오, PD까지 한방에 섭외 및 제작. 둘이 사랑에 빠지는가 싶더니만, 음악가의 구애에 여인은 아주 쿨~하게 빠이빠이. 이 모든 일련의 유별난 사건이 발생한 기간은 겨우 2주 정도?

어찌보면 황당하기 짝이 없는, 전혀 현실성 없어 보이는 이와 같은 진행을 영화 엔딩 크래딧이 올라가는 순간까지 눈치 채지 못하고 빠져 있었던 내 자신이 놀랍다. 근데 문제는 우리나라가 아닌 영국에서는, 유럽에서는 충분히 개연성 있는 사건이 될지도 모른다는 생각이 더욱 강하게 밀려온다는 사실. 플롯 외적인 부분에서 보여주는 참신함, 세련됨과 내내 흘러나오는 그들의 아름다운 노랫소리를 고려했을 때 영화의 기본이 되는 '개연성'을 무시했을 리는 만무하다.

이와 같은 이야기가 충분히 현실성 있는 그들의 분위기. 아니, 그러한 일련의 사건이 충분히 개연성 있어 보이는 그들의 분위기, 문화 또는 사회적 성숙도. 이는 바로 우리가 진정 원하던, 내가 진정 원하던 바로 그 것이 아니었을까? 본 영화에서 나타난 로맨스 또는 음악적 교감이 아니라 말이다. 얼마 전 스웨덴에서 교환 학생 갔다 돌아온 동생이 이야기한 한마디가 생각난다. 그들의 선진 된 사회의 가장 큰 특징은 '높은 도덕성'이었다고.

짭... 감수성에 관한 이야기를 하려다, 힘들게나마 영화에 대한 감성적 느낌을 이야기하려다 어느새 관념론으로 흘러버렸네.

'인성적 균형'으로 시작했으니 '인성적 균형'으로 끝맺으려 한다. 오늘 본 영화를 보게 된 원동력은 '나태함'이 아닌, 끊임없이 극단적 '지성'만을 요구하는 요즘의 내 상황에서의 인성적 균형을 맞추려는 내 몸땡이의 본능, 균형추에 기인한 것이다.

p.s
움... 균형이고 감수성이고 나발이고 간에, 날이 갈수록 내 자신에 대한 합리화가 교묘해 가고 있구만, 짭.

촛불 시위 관련. 제 블로그를 찾으신 모든 분께.

(어쨌건간에) — Tue, 27 May 2008 21:50:21 +0900

쥐새끼는 쥐새끼에 걸맞는 자리에 있어야 하는데, 어쩌다가 대가리 노릇을 하다보니 애꿎은 국민이 고생하고 있습니다. 하긴, 그 왕초 쥐새끼를 앞세워 뒷구린 짓거리를 이어가는 여의도 등지의 쥐때들... 그간 보여주었던 그들의 놀라운 생존력을 감안한다면, '어쩌다가'라는 표현은 뭔가 좀 어색하기도 합니다.

날마다 뉴스를 접하면서 제 입에서는 쌍시옷 소리가 끊이지 않는데, 본 블로그에는 그런 모습이 전혀~ 안보입니다. 오로지 앞으로 먹고 살기 위한 포스팅만이 끊이지 않을 뿐. 뭐 이미지 관리 차원에서 그랬던 것은 아닙니다. 걍 어쩌다가 보니 그랬던 것일 뿐이죠.

하지만, 요즘 심하게 갈등 때리고 있습니다. 난 입만 살아있는 것인가.. 나 역시 쥐새끼같은 행동을 하는 건 아닌가... 하고 말입니다.
역사를 장식하는 주요한 순간마다 놀라운 통찰력을 보여주었던 10대들의 의기에 찬 모습들. 이와 함께한 일반 국민들... 이러한 분들의 노고 덕분에 현재의 '대한민국', 그 안의 풍요로운 '나'가 있음은 의심할 여지가 없습니다. 이에 대한 보답은 저 역시 그들과 함께 함이라는 것을 잘 알고 있으면서도 아직까지도 제대로 참여해본 바가 없다는데 심히 부끄러움을 느낍니다.

시위에 참여하신 모든 분들에게 감사하다는 말씀 드리면서, 저 역시 조만간 참여할 것임을 다짐합니다.

그 쥐새끼가 쥐가 되어버린 건, 어쩌면 미국을 넘 좋아해 미국 쇠고기를 먹다, 머리에 구멍 뚤려 뇌의 무게가 쥐의 그것으로 되었기 때문인지도 모른다... 라고 억지로 상상해보았습니다. ㅋ

여하간, 저도 한마디 외칩니다.

너 하나로 족하다! 국민마저 쥐대가리로 만들려 하지 말라! 쥐새끼 타도!

신속 소프트웨어 개발(Rapid S/W development) 3/3

(어쨌건간에) — Wed, 07 May 2008 05:12:48 +0900

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

12. Rapid application development(RAD)
- 데이터에 집중된 비즈니스 응용(application), 즉 DB로부터의 정보를 표현하는 응용에 주로 사용
- RAD 환경 도구 : DB 프로그래밍 언어, Interface 생성기, 오피스 응용 프로그램과의 연결, 리포트 생성기, 대화식 개발에 알맞는 Visual programming 도구

13. Visual development
- 단위가 작은 재사용 가능 S/W 컴포넌트의 통합에 의존하는 RAD 기법
- Visual Basic같은 스크립트 언어를 사용
- 대규모 컴포넌트가 기정의, 기구현되어 있음
- 특정 응용 요구사항에 맞도록 재구성될(tailored) 수도
- COTS(Commercial Off-the-Shelf; 상용 기성품) 기반 개발이라 부르기도. 기성품을 재구성(configure)하고 연결
- 복합 문서(Compound documents)
1) 사용자 조작(computation)이 가능한 능동 요소(active element)가 내장된 문서. 복합 문서 자체는 각기 다른 응용을 통합하는 역할
2) 각각의 능동 요소는 특정 응용과 연결되어 해당 요소 선택시 활성화됨
- 문제점
1) 팀 기반 개발에 알맞지 않음
2) 명시적 시스템 아키텍처가 없음
3) 프로그램 부위간 복잡한 의존성이 유지보수 문제를 일으킬 수도

14. S/W 프로토타이핑(Prototyping)
- 개념을 보여주고(demonstrate), 설계 선택사항(option)을 시험해보기 위한 개발할 시스템의 초기 버전
- 용도는,
1) 요구공학 프로세스 : 요구사항 추출 및 검증을 위해
2) 설계 프로세스 : 선택사항 시험 및 UI 설계 개발을 위해
3) 테스트 프로세스 : back-to-back 테스트 수행을 위해
- 장점
1) 시스템 사용성 향상
2) 사용자의 실제 필요에 더욱 근접
3) 설계 품질 향상
4) 유지보수성 향상
5) 개발 노력(effort)의 절감
6) back-to-back 테스트가 가능해짐

back-to-back 테스트(동일 결과면 OK, 다르면 결함 존재)

프로토타이핑 프로세스

15. 폐기용 프로토타입(Throw-away prototypes)
- 프로토타입은 개발 후 폐기되어야 : 제조 시스템(production system)을 위한 적절한 기반이 되지 못하기 때문에
1) (보안성, 신뢰성 등의) 비기능적 요구사항을 만족시키기 위해 프로토타입을 손질할(tune) 수 없음
2) 일반적으로 프로토타입에 대한 문서는 없음
3) 프로토타입의 구조는 보통 많은 변경으로 인해 낙후됨(degraded)
4) 프로토타입은 조직의 품질 기준(표준)에 미치지 못하는 경우가 다반사

신속 소프트웨어 개발(Rapid S/W development) 2/3

(어쨌건간에) — Tue, 06 May 2008 06:24:35 +0900

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

7. 애자일 기법(Agile Methods)
- 기존의 개발 접근법에 대한 불만,즉 계획 수립, 설계, 문서화에 대한 부하(overhead)에 대한 반기로 시작
- 설계와 문서화보다는 S/W 자체(특히 코드)에 초점을 두도록
- 점증적 접근법에 기반
- 빠르게 변화, 진화해가는 요구사항에 대한 신속한 S/W의 배포
- 주로 소/중규모 비즈니스 시스템이나 PC 제품이 알맞음
- XP는 가장 잘 알려진 애자일 기법 중 하나

8. 애자일의 원칙
- 고객 참여(Customer involvement) : 고객은 요구사항 개발 및 운선순위 결정, 시스템의 반복(iteration)을 평가
- 점증적 인도(Incremental delivery) : 고객이 지정한 요구사항이 포함된 점증 단계를 기반으로 s/w가 개발되고 인도됨
- 사람은 프로세스가 아님(People not process) : 기정의된 프로세스를 강요하지 않음. 개발자 및 개발팀 만의 방식, 그들의 기술을 인정
- 변화를 포용(Embrace change) : 요구사항의 변화를 받아들이고 ,변화 수용 가능한 시스템을 설계
- 단순성 유지(Maintain simplicity) : S/W 및 개발 프로세스 모두에서 단순성에 초점을. 수시로 시스템에 남겨진 복잡성을 제거하도록

9. 애자일의 문제점
- 고객은 전적으로, 계속하여 프로세스에 참여하기 어려움
- 개발팀 구성원이 집중적인 참여를 요구하는 애자일의 특성에 맞지 않을 수도
- 다수의 이해관계자(stackholder)가 있을 경우 우선순위 변경이 어려워짐
- 단순성 유지는 추가적 작업을 요구
- 내재화된 점증적 명세화 작업으로 인해, 명사가 포함된 계약서 작성이 난해. 따라서 타 외부 개발 조직과의 co-work이 어려워질 수도

10. Extreme Programming(XP)
- 가장 잘 알려지고, 가장 많이 사용되는 애자일 기법
- 반복적 개발과 같은 좋은 실무 관행과 고객 참여을 극한(extreme)까지 밀고 나감
1) 새로운 버전이 하루에도 몇 번씩 빌드될 수 있음
2) 매 2주마다 각 점증적 단계가 고객에게 인도
3) 매 빌드마다 모든 테스트가 수행되고 테스트에 성공했을 때만 해당 빌드를 인정

XP 릴리즈(release) 사이클

11. Extreme programming Practices
- 점증적 계획(Incremental planning) : 시토리 카드를 이용, 작업으로 분할. 이들 작업은 스케줄링과 비용 산정의 근간. 시간을 고려하여 우선순위 결정
- 소규모 릴리즈(Small releases) : 비즈니스 가치를 제공하는 최소한의 유용한 기능을 먼저 개발. 릴리즈를 자주, 점증적으로 수행
- 단순한 설계(Simple design) : 현재의 요구사항을 충족하는 충분한 설계를
- 테스트 주도 개발(Test driven development): 구현 이전에 자동화된 단위 테스트 프레임워크를 통해 테스트 킷을 먼저 작성
- 리팩토링(Refactoring) : 계속적으로, 최대한 많이 코드를 리팩토링. 단순성, 유지보수성 증가
- 짝 프로그래밍(Pair programming) : 짝으로 팀을 이뤄 함께 개발. 서로가 상대의 작업을 검사(checking)하도록. 비공식적 검토(Informal review)가 자연스럽게 이루어짐
- 집단적 소유(Collective ownership) : 짝이 시스템의 모든 영역을 맡음으로 고립된 비 개발 영역이 없도록. 누구든지 변경 코드 변경 가능
- 계속적 통합(Continuous integration) : 작업이 완료되자마자 전체 시스템에 통합되도록. 이후 모든 단위 테스트를 통과해야
- 유지 가능한 속도(Sustainable pace) : 초과 근무는 낮은 품질, 보통의 생산성 만을 양성할 뿐
- 현장의 고객(On-site customer) : 고객은 개발팀의 일원. 전적으로 개발에 시간을 할당하여 시스템 요구사항을 전달할 책임이 고객에게 존재

신속 소프트웨어 개발(Rapid S/W development) 1/3

(어쨌건간에) — Mon, 05 May 2008 23:31:00 +0900

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. 신속 S/W 개발(Rapid S/W development)
- 비즈니스 환경의 빠른 변화, 비즈니스는 새로운 기회와 도전에 신속히 응답해야. Time-to-market
- 이 경우, 신속한 개발과 인도는 종종 S/W 시스템에 관한 가장 중요한 요구사항
- 위와 같은 배경 기반의 비즈니스 영역에서는 주요 기능이 정상적으로 동작하기만 하면 빠른 인도의 장점이 낮은 품질이란 단점을 상쇄
- 요구사항
1) 환경의 변화로 인해 안정적이고 일관적인 시스템 요구사항에 도달하기가 매우 어려움
2) 따라서 waterfall 모델은 비현실적, 오직 반복적(iterative) 명세와 인도에 기반을 둔 개발 방법론만이 S/W를 신속하게 인도하는 유일한 방법

2. RAD 프로세스의 특성
- 명세, 설계, 구현 프로세스가 동시에 이루어짐. 상세 명세는 없으며 설계 문서는 최소화됨
- 시스템은 일련은 점증적 단계(증분; increment)를 통해 개발됨. 최종 사용자는 개발에 참여하여 각 점증 단계를 평가하며, 이후 점증 단계를 위한 제안을 함
- 시스템 UI는 일반적으로 반복적 개발 시스템을 이용하여 개발됨

점증적 개발 프로세스

3. 점증적 개발(Incremental development)의 장점
- 고객 서비스의 신속한 인도(accelerated delivery of customer services) : 각 점증 단계(증분; increment)는 고객의 가장 높은 우선순위의 기능을 인도
- 시스템에 대한 사용자의 참여 : 사용자는 개발에 참여하여 시스템이 좀더 그들의 요구에 다가서고, 사용자는 시스템에 대해 더 나은 만족을 얻을 수 있음

4. 점증적 개발의 문제점
- 관리 문제(Management problem) : 문서가 없으므로 상황 파악이 어려움
- 계약 문제(Contractual problem) : 명세가 없으므로 명세 이외의 타 형식의 문서를 사용해야
- 검증 문제(Validation problem) : 명세가 없으면, 어떤 기준으로 시스템을 테스트할 것인가
- 유지보수 문제(Maintenance problem) : 계속적인 변경은 S/W 구조에 문제를 일으키고(corrupt), 이로써 S/W는 새로운 요구에 대한 변경과 진화가 어려워짐

5. 프로토타이핑(Prototyping)
- 일부 대규모 시스템에서는 점증적 반복 개발과 인도는 비현실적. 특히 다수의 팀이 각가 다른 위치에서 일할 경우
- 실험적 시스템을 개발하는 프로토타이핑을 통해 요구사항의 타당성(실제 사용할만한지 여부 판단) 체계화(formulate)를 위한 기반을 세울 수 있음. 시스템 명세가 만들어지면(agreed) 프로토타입은 폐기됨(throw away)

6. 점증적 개발과 프로토타이핑
- 점증적 개발의 목적은 최종 사용자에게 실제 동작하는(working) 시스템을 인도함에 있음. 개발은 가장 잘 이해된 요구사항을 바탕으로 시작됨.
- 프로토타이핑의 목적은 시스템 요구사항의 검증 또는 추출임. 프로토타이핑 프로세스는 잘 이해되지 않은 이해사항에서 시작.

점증적 개발과 프로토타이핑의 목적