검색결과 리스트
2009/02에 해당되는 글 25건
- 2009/02/27 애자일 프랙티스와 실용주의 적용 발표 준비 완료 (9)
- 2009/02/26 애자일 프랙티스와 실용주의 적용 발표 준비 (2)
- 2009/02/25 김수환 추기경이 남긴 글, 교회는 왜 사회 참여를 하였는가? 그리고 ...
- 2009/02/25 JCO 10회 컨퍼런스 Hands On Lab 안내(갱신) (3)
- 2009/02/24 FireFox 사용 개발자를 위한 검색 엔진 모음 (2)
- 2009/02/19 메모: Model-Driven Engineering (3)
- 2009/02/16 반복 관리자 번역 용어 선택 (10)
- 2009/02/14 Groovy in action (2)
- 2009/02/14 나는 언제 스스로를 아키텍트라고 소개할 수 있을까? (2009) (5)
- 2009/02/13 Xper 그룹스의 개발량 편차 좁히기에 대한 논의
- 2009/02/13 초보 선장 시절에 대한 반추 (2)
- 2009/02/12 Eager Read Derivation (3)
- 2009/02/11 거슬리는 플래시 광고 제거하기
- 2009/02/10 리팩토링에 익숙해지기 2
- 2009/02/09 리팩토링에 익숙해지기 (9)
- 2009/02/07 SpringSource의 직원 Michael Isvy와 만나실 분
- 2009/02/06 제10회 JCO 콘퍼런스 강의 구성
- 2009/02/05 Spring 공식 교육 5월 연기와 Michael Isvy의 제10회 JCO 콘퍼런스 발표
- 2009/02/04 자연의 섭리는 인간이 만든 체제에도 녹아 있을 터니
- 2009/02/04 고산자(古山子) 김정호식 정리
- 2009/02/03 Ron Jeffries가 말하는 스크럼 계획 절차
- 2009/02/02 공정 분리와 분업의 전제 (11)
- 2009/02/02 Java EE6에서 등장하는 Web Profiles (2)
- 2009/02/02 10번째 JCO 콘퍼런스 준비 상황 (6)
- 2009/02/02 워렌 버핏의 기업 인수 조건
글
애자일 프랙티스와 실용주의 적용 발표 준비 완료
2009 이야기
2009/02/27 00:39
낮에 Trac/Mylyn 데모를 위해 작업한 시간에 더하여 애자일 프랙티스와 실용주의 적용 발표 준비 즈음부터 대략 4시간이 걸렸다. 발표자료도 수정했으니 새로 올린다. 미리 받아가신 분들을 번거롭게 해 드리는 일이지만 더 나은 발표를 위해서 양해하시길
위키북스와 에이콘 출판사에서 관련 서적을 보내주기로 했다. 발표 주제와 관련한 책을 발표 중에 질문하시는 분에게 드릴 예정이다. 이젠 집에 가서 자야겠다. :)
Mustang-3v2.pdf위키북스와 에이콘 출판사에서 관련 서적을 보내주기로 했다. 발표 주제와 관련한 책을 발표 중에 질문하시는 분에게 드릴 예정이다. 이젠 집에 가서 자야겠다. :)
글
애자일 프랙티스와 실용주의 적용 발표 준비
2009 이야기
2009/02/26 21:37
지난번 프로젝트는 요구분석부터 구현까지 전담해서 우리 팀이 구현할 수 있는 첫 번째 기회였다. 프로젝트 관리자였으나 규모가 작은 터라 주로 참여했던 대규모 프로젝트의 PM과는 역할이 달랐다. 본질적으로 PM의 직무를 우선해서 수행했으나 PL 역할도 하고, 때론 QA도 하고, 간헐적으로는 아키텍트 역할도 했다. 경험은 고스란히 전달하기 어렵지만, 프로젝트를 마친 후에 간단한 기사를 기고하기도 했다.
프로젝트 관리자 관점에서 본 애자일 프랙티스(Agile Prcatices)의 적용 사례(상)
프로젝트 관리자 관점에서 본 애자일 프랙티스(Agile Prcatices)의 적용 사례(하)
성공적인 프로젝트 종료로 우리는 비슷한 성격의 프로젝트를 다시 수주했다. 팀 규모는 줄었지만 같은 고객, 같은 팀인 터라 또 많은 것을 배웠다. 나 자신도 거의 일 년에 걸친 경험 가운데에서 전달 가능한 부분을 정리하고 싶은 욕심이 있다. 그래서 인수인계를 앞둔 프로젝트 막바지에서 발표를 자청했다. 이런 이벤트가 없더라도 차분히 자신을 쌓아가는 든 사람이면 좋겠지만, 아직 나는 그렇지 못하다.
틈틈이 생각을 정리해두긴 했지만, 막상 주어진 짧은 시간 안에 발표자료를 만들어서 보냈다.
(발표 자료는 수정하여 다음 글에 넣었음)
하고 싶은 이야기의 화두만 올려두었지 실제 무슨 이야기를 할지 아직 확실치는 않다. JCO 특성상 다양한 눈높이와 관심사를 가진 청중이 있다. 대체로 프로젝트 경험과 환경 개선에 대한 고민이 있어야 공감할 수 있는 주제인 터라 도구나 기술에 대한 관심이 많은 분에게는 발표자료가 적절하지 않다. 그래서 향후 우리가 만든 제품을 인수인계 받아 잘 활용할 수 있도록 우리의 경험을 전달하는 과정에서 만든 산출물을 정리해서 이슈 트래커와 작업 관리 도구인 Trac/Mylyn 활용 팁을 추가했다. 데모 시연 시간을 줄이려고 화면 캡쳐를 하는데 스무 장이 넘는다. 적어도 20분은 걸리겠다.
블로그에 메모했던 내용을 모아봐야겠다. 그래야, 그때로 돌아가 경험을 꺼내올 수 있을 테니까.
2008년 프로젝트 로그
발표 순서에 맞게 해당 내용을 구분하고 섞어봐야겠다.
말에 갇히거나 가두지 말자
반복의 가치
협업의 가치
PM/팀장의 첫 경험
진화하는 시스템
애자일 개발 사례
개발자의 애자일
흠.. 이제 준비가 한결 수월할 듯 하다.
프로젝트 관리자 관점에서 본 애자일 프랙티스(Agile Prcatices)의 적용 사례(상)
프로젝트 관리자 관점에서 본 애자일 프랙티스(Agile Prcatices)의 적용 사례(하)
성공적인 프로젝트 종료로 우리는 비슷한 성격의 프로젝트를 다시 수주했다. 팀 규모는 줄었지만 같은 고객, 같은 팀인 터라 또 많은 것을 배웠다. 나 자신도 거의 일 년에 걸친 경험 가운데에서 전달 가능한 부분을 정리하고 싶은 욕심이 있다. 그래서 인수인계를 앞둔 프로젝트 막바지에서 발표를 자청했다. 이런 이벤트가 없더라도 차분히 자신을 쌓아가는 든 사람이면 좋겠지만, 아직 나는 그렇지 못하다.
틈틈이 생각을 정리해두긴 했지만, 막상 주어진 짧은 시간 안에 발표자료를 만들어서 보냈다.
(발표 자료는 수정하여 다음 글에 넣었음)
하고 싶은 이야기의 화두만 올려두었지 실제 무슨 이야기를 할지 아직 확실치는 않다. JCO 특성상 다양한 눈높이와 관심사를 가진 청중이 있다. 대체로 프로젝트 경험과 환경 개선에 대한 고민이 있어야 공감할 수 있는 주제인 터라 도구나 기술에 대한 관심이 많은 분에게는 발표자료가 적절하지 않다. 그래서 향후 우리가 만든 제품을 인수인계 받아 잘 활용할 수 있도록 우리의 경험을 전달하는 과정에서 만든 산출물을 정리해서 이슈 트래커와 작업 관리 도구인 Trac/Mylyn 활용 팁을 추가했다. 데모 시연 시간을 줄이려고 화면 캡쳐를 하는데 스무 장이 넘는다. 적어도 20분은 걸리겠다.
블로그에 메모했던 내용을 모아봐야겠다. 그래야, 그때로 돌아가 경험을 꺼내올 수 있을 테니까.
2008년 프로젝트 로그
발표 순서에 맞게 해당 내용을 구분하고 섞어봐야겠다.
말에 갇히거나 가두지 말자
반복의 가치
- SRS(Software Requirements Specification)를 작성할 때 유의할 점
- 프로세스의 필요성(a.k.a 매뉴얼의 필요성)
- 소프트웨어 엔지니어링이란?
- 이터레이션(Iteration)과 진화(Evolution)
- 반복의 중요성을 반복해서 거론하다
협업의 가치
- '이슈 트래커' 관련 글은 어디에...
- 이슈트래커(trac) 설정 + 마이린(Mylyn) 연결
- 이슈트래커(trac) + Mylyn의 효용성
- 꼬리에 꼬리를 무는 '쾌적한 프로젝트 수행 환경' 만들기
- 작업(Task) 관리 진화
- 팀 협업의 중요성
- 공동작업시 묵비권 행사를 자제해주세요
- 진정한 의미의 리비전?
- 한번쯤 정리해둘 내용
PM/팀장의 첫 경험
- 회의시간 절감을 위한 개발팀 회의 프로세스
- 회의에서의 의사진행 기법
- 지루한 회의? 효과적인 커뮤니케이션
- 회의 관리자?
- 비전문에 꼭 필요한 내용
- 뻔한 얘기 같으나
- 도와주세요! 팀장이 됐어요
- 회고(Retrospective)를 회고하기
- 이해관계자 네트워크
- 스크럼(Scrum) 적용 일지
- 계획의 어려움
- 누구를 위해 일하는지 기억하라
- 프로젝트 팀과 포메이션
진화하는 시스템
애자일 개발 사례
개발자의 애자일
흠.. 이제 준비가 한결 수월할 듯 하다.
글
김수환 추기경이 남긴 글, 교회는 왜 사회 참여를 하였는가? 그리고 ...
2009 이야기
2009/02/25 08:15
종교를 갖고 있지 않지만, 근대사를 아우르는 내용과 존경할만한 분의 가치관을 엿볼 수 있지 않을까 싶어 앞으로 일독을 위해 링크를 걸어둔다.
, <
>
출처:추기경과 두 역설
추기경과 두 역설도 읽어볼 만하다. 아래 내용에 특히 관심이 갔는데 밑줄 친 부분에 이르러서는 웃음을 짓지 않을 수 없었다.
웃기는 했지만 남의 일로 웃고 넘길 일은 아닌 듯하다. 업계에서 CBD, EA, SOA 등등 화두를 가지고 씨름하는 과정에서도 비슷한 모습이 보이지 않았나 싶어서다. 어떤 말로 정리할 수 있을까? 싶었는데 더 읽어보니 적절한 표현을 쉽게 찾을 수 있다.
굵게 표현한 문장에 외국헌법 대신에 화두로 떠오르는 기술을 대입하고, 종교적 쟁투 대신에 타이밍을 잘 포착하여 돈을 벌기 위한 임시방편의 조치로 읽는다면 지나친 곡해일까?
맥락을 만들어가고 진지한 논의를 하기. 결국, 해야 할 일은 분명해진다. 다만, 내 의지가 의심스러울 뿐이다. 추기경과 두 역설의 맺음말을 읽자 자문하게 된다. 그렇다면, 나는 왜 살아갈 것인가?1
, <
 교회는왜사회참여를하였는가.hwp |
출처:추기경과 두 역설
추기경과 두 역설도 읽어볼 만하다. 아래 내용에 특히 관심이 갔는데 밑줄 친 부분에 이르러서는 웃음을 짓지 않을 수 없었다.
원칙을 말하자면 종교는 가장 개인적일 때 가장 아름다운 것이다. 종교가 도덕을 말하는 것은 이미 오래전에 물건너간 고대시대의 이야기에 불과할 뿐이고, 역사는 개인화되지 않고 집단으로 결속된 모든 종교는 결국 타락한다고 말한다. 모든 제도화된 종교는 결국 타락하므로 정교분리는 일종의 안전장치라 생각해도 좋다. 문제는 그 역사적 맥락을 살펴보았을 때, 결국 교황과 국왕이 서로 권력을 나눠갖기 위해 타협한 것이라는 아이러니가 숨어 있다는 점이다. 유럽에서 시작된 정교분리의 원칙이 교황과 국왕이라는 신권정치의 틀을 단 한번도 가지지 못했던 땅의 헌법에 버젓이 들어 앉아 있는 꼴도 웃기는 것이지만, 그러한 헌법 조항이 제헌국회에서 어떤 연유로 삽입되었는지 도저히 알 수 없는 일이다.
코미디는 명백히 정교의 분리를 헌법으로 정한 마당에 일국의 초대 대통령이라는 자가 하나님께 감사를 드리며 대통령직을 시작했다는 것이다.
코미디는 명백히 정교의 분리를 헌법으로 정한 마당에 일국의 초대 대통령이라는 자가 하나님께 감사를 드리며 대통령직을 시작했다는 것이다.
웃기는 했지만 남의 일로 웃고 넘길 일은 아닌 듯하다. 업계에서 CBD, EA, SOA 등등 화두를 가지고 씨름하는 과정에서도 비슷한 모습이 보이지 않았나 싶어서다. 어떤 말로 정리할 수 있을까? 싶었는데 더 읽어보니 적절한 표현을 쉽게 찾을 수 있다.
정 교분리는 시작부터 느슨한 원칙이었고 이 땅의 맥락과는 도무지 맞지도 않는 외국헌법 짜집기의 조악한 수준을 보여주는 흔적이거나 혹은 제헌국회를 차지하고 있던 기독교, 천주교, 불교, 천도교 등의 종교적 쟁투를 막기 위한 임시방편의 조치였을지 모른다. 이유여하를 막론하고 이 땅은 정교분리 따위가 있었던 적도 없고, 있어야 할 역사적 맥락도 전혀 존재하지 않으며, 있어야 하는지에 대한 진지한 논의조차 없었던 터전인 것이다.
굵게 표현한 문장에 외국헌법 대신에 화두로 떠오르는 기술을 대입하고, 종교적 쟁투 대신에 타이밍을 잘 포착하여 돈을 벌기 위한 임시방편의 조치로 읽는다면 지나친 곡해일까?
맥락을 만들어가고 진지한 논의를 하기. 결국, 해야 할 일은 분명해진다. 다만, 내 의지가 의심스러울 뿐이다. 추기경과 두 역설의 맺음말을 읽자 자문하게 된다. 그렇다면, 나는 왜 살아갈 것인가?1
시대가 그러한 역사적 질곡을 만들었다 하더라도, 우리가 배워야 하는 것은 다시는 그러한 일이 일어나지 않을 사회를 만드는 것이며, 궁극적으로 종교가 그 맹목성을 사회에 침투시키지 못하게 하는 일이다. 그것이 내 꿈이고 시대적 고민 속에서 조심스레 사회참여를 결정한 김수환 추기경이 존경스러운 이유다. 시대적 요청속에서 정치판을 넘나들고 싶어하는 종교인들은 추기경의 조심스러움을 배울 일이다.
- 신기하게 여겨질 만큼 정말 오랫동안 잊어버리고 지낸 질문이다. [본문으로]
글
JCO 10회 컨퍼런스 Hands On Lab 안내(갱신)
2009 이야기
2009/02/25 00:56
JCO 홈페이지에서 관련 안내를 찾기 불편해 하는 분이 있어 이 곳에도 공지를 합니다. 아셈 강의는 모두 Hands-on-Lab 형태로 진행합니다. 그랜드볼룸 강의과 달리 실습 위주로 진행합니다. Hands-on-Lab 에 어울리는 주제와 강사를 준비했지만 기대한만큼의 성과가 있으려면 여러분의 사전에 준비가 필요합니다.
첫째, 강의 시간 변동이 있으니 착오 없으시길 바랍니다. 현장 인쇄물 시간표와 달리 아셈 강의는 모두 두 시간이 연속하여 진행합니다. 박찬욱님의 From JDBC to ORM과 이희승님의 자바 네트워킹 기초에서 응용까지 1, 2부는 10분 간격으로 진행한 후에 점심 시간을 갖습니다. 그랜드 볼룸과 달리 13:40분부터 15시까지 점심 시간입니다.
세션 당 약 100명 정도를 수용할 수 있습니다. 50%는 사전 접수한 분이 우선권을 갖습니다. 사전 접수는 이미 완료되었다 들었습니다. 현장에서 나머지 50석을 받을 예정입니다. 입장시에는 사전 등록한 분이 우선 입장하고, 뒤이어 현장 접수하신 분이 입장합니다. 따라서, 사전 등록하신 분은 바코드를 출력해오시기 바랍니다: ☞ 바코드 출력 페이지
강의 시간이 2시간, 정확하게는 쉬는 시간 포함 총 2시간 30분 ~ 40분입니다. 노트북/PC 지참은 물론 필수입니다. 충전을 위한 멀티탭을 제공하지만, 확인 결과 모두가 전원을 사용하시면 아셈 회의장 기본 전략 사용량을 넘어설 수 있다고 합니다. 따라서, 가능한 사전에 배터리를 충전해서 오시면 실습에 지장을 받지 않을 것입니다.
둘째, 강의 자료는 별도로 배포하지 않습니다. 현장에서 인터넷을 지원하지 않으니 파일이 필요하신 분은 미리 다운로드하시기 바랍니다.
실습을 하려면 사전에 설치해야 할 내용이 있습니다.
박찬욱님의 강의, From JDBC to Hibernate를 위해 필요한 내용입니다.
김태완님 강의, Standard DI and Context management를 위해필요한 내용입니다.
==========================================================
이희승님 강의, 자바 네트워킹 기초에서 응용까지를 위해 필요한 내용은 단지 Eclipse 3.4 구동 가능한 윈도우즈 또는 64비트 리눅스가 랩탑이랍니다. 노트북에 가니메데(이클립스 3.4)만 설치하면 되는군요.
정지웅님 강의, JRuby on Rails를 위해 필요한 내용입니다. 친절한 설명을 붙여주셨네요.
첫째, 강의 시간 변동이 있으니 착오 없으시길 바랍니다. 현장 인쇄물 시간표와 달리 아셈 강의는 모두 두 시간이 연속하여 진행합니다. 박찬욱님의 From JDBC to ORM과 이희승님의 자바 네트워킹 기초에서 응용까지 1, 2부는 10분 간격으로 진행한 후에 점심 시간을 갖습니다. 그랜드 볼룸과 달리 13:40분부터 15시까지 점심 시간입니다.
세션 당 약 100명 정도를 수용할 수 있습니다. 50%는 사전 접수한 분이 우선권을 갖습니다. 사전 접수는 이미 완료되었다 들었습니다. 현장에서 나머지 50석을 받을 예정입니다. 입장시에는 사전 등록한 분이 우선 입장하고, 뒤이어 현장 접수하신 분이 입장합니다. 따라서, 사전 등록하신 분은 바코드를 출력해오시기 바랍니다: ☞ 바코드 출력 페이지
강의 시간이 2시간, 정확하게는 쉬는 시간 포함 총 2시간 30분 ~ 40분입니다. 노트북/PC 지참은 물론 필수입니다. 충전을 위한 멀티탭을 제공하지만, 확인 결과 모두가 전원을 사용하시면 아셈 회의장 기본 전략 사용량을 넘어설 수 있다고 합니다. 따라서, 가능한 사전에 배터리를 충전해서 오시면 실습에 지장을 받지 않을 것입니다.
둘째, 강의 자료는 별도로 배포하지 않습니다. 현장에서 인터넷을 지원하지 않으니 파일이 필요하신 분은 미리 다운로드하시기 바랍니다.
| [2009, 10회] Chelsea-1 From JDBC to Hibernate | 박찬욱님 |
다운
|
||
| [2009, 10회] Chelsea-2 Standard DI and Context management | 김태완님 |
다운
|
||
| [2009, 10회] Sparkler-1 자바 네트워킹 기초에서 응용까지 | 이희승님 |
다운
|
||
| [2009, 10회] Sparkler-2 JRuby on Rails | 정지웅님 |
다운
|
||
실습을 하려면 사전에 설치해야 할 내용이 있습니다.
박찬욱님의 강의, From JDBC to Hibernate를 위해 필요한 내용입니다.
============== 안내문 =======================
본 랩을 참여하려면 몇 가지 준비물이 필요 합니다. 먼저 Oracle 10 XE가 필요합니다. 랩 진행 시 예제를 Oracle 10 XE의 HR 스키마로 진행하게 됩니다. 물론 기본적으로 JDK가 있어야 하며, 애노테이션 기반으로 설정하기 때문에 5 이상 버전이 설치되어 있어야 합니다. 마지막으로 Master-Detail 등의 예제는 화면 연동이 함께 필요하기 때문에, JDK 버전에 맞는 톰캣이 필요 합니다. 그럼 컨퍼런스 시간에 뵙죠. 감사합니다.
===========================================김태완님 강의, Standard DI and Context management를 위해필요한 내용입니다.
==========================================================
랩 참가자는 다음과 같은 환경을 사전에 준비해야 합니다.
1. JDK: Java SE 6.0
2. Ant: Ant 1.7.1
3. Eclipse: 3.4
4. WAS: JBoss AS 5.0
5. Web Bean RI: webbeans-1.0.0.ALPHA2
Web Bean RI를 제외한 구성 요소의 디렉토리 위치에 대한 제약 사항은 없습니다.
다만 ANT 관련 환경 변수가 적용되어 있으면 됩니다.
OS 환경 변수로 다음과 같은 변수가 등록되어 있어야 합니다.
* ANT_HOME=> Ant 홈 디렉터리 설정
* path => ant/bin 디렉터리 추가 (예: %ANT_HOME%/bin)
Web Bean RI 다운로드 및 설치
- http://www.seamframework.org/Download 에서 Web Beans 1.0 다운로드
- webbeans-1.0.0.ALPHA2.zip
- c:\wb-lab\에 압축 풀기
- 최종 디렉터리 구조
c:\wb-lab\webbeans-1.0.0.ALPHA2
--> doc
--> examples
--> jboss-as
--> lib
--> src
==========================================================
1. JDK: Java SE 6.0
2. Ant: Ant 1.7.1
3. Eclipse: 3.4
4. WAS: JBoss AS 5.0
5. Web Bean RI: webbeans-1.0.0.ALPHA2
Web Bean RI를 제외한 구성 요소의 디렉토리 위치에 대한 제약 사항은 없습니다.
다만 ANT 관련 환경 변수가 적용되어 있으면 됩니다.
OS 환경 변수로 다음과 같은 변수가 등록되어 있어야 합니다.
* ANT_HOME=> Ant 홈 디렉터리 설정
* path => ant/bin 디렉터리 추가 (예: %ANT_HOME%/bin)
Web Bean RI 다운로드 및 설치
- http://www.seamframework.org/
- webbeans-1.0.0.ALPHA2.zip
- c:\wb-lab\에 압축 풀기
- 최종 디렉터리 구조
c:\wb-lab\webbeans-1.0.0.
--> doc
--> examples
--> jboss-as
--> lib
--> src
==============================
이희승님 강의, 자바 네트워킹 기초에서 응용까지를 위해 필요한 내용은 단지 Eclipse 3.4 구동 가능한 윈도우즈 또는 64비트 리눅스가 랩탑이랍니다. 노트북에 가니메데(이클립스 3.4)만 설치하면 되는군요.
정지웅님 강의, JRuby on Rails를 위해 필요한 내용입니다. 친절한 설명을 붙여주셨네요.
jruby_installation.doc글
FireFox 사용 개발자를 위한 검색 엔진 모음
2009 이야기
2009/02/24 08:00
필수기능인 검색엔진이 먹통이라 파이어폭스를 다시 설치했다. 매번 다시 만들고 설치하는 검색엔진을 모아둔다.
searchplugins-20090223.zip검색 엔진 종류
글
메모: Model-Driven Engineering
2009 이야기
2009/02/19 08:40
Model-Driven Engineering 개요
Model-Driven Engineering에서 워크 벤치 개요
출처: Model Driven Engineering tools compared on user activities
글
반복 관리자 번역 용어 선택
2009 이야기
2009/02/16 07:00
이 글은 소트웍스 앤솔러지 : 소프트웨어 기술과 혁신에 관한 에세이 7장 반복 관리자에서 사용한 번역 용어 선택에 대한 근거입니다.
보너스로 좋은 리뷰가 있어 소개합니다.
- Iteration >반복
- 쓰임새: iteration, iteration manager, iteration schedule, iteration planning meeting
- 선정: 처음에는 "반복 주기" 선택. 주제가 iteration manager이다 보니 34번 등장한다. "반복 주기 관리자"로 표기해서 지면을 소비하고, 발음/읽기에 들어가는 시간을 추가할만한 이점이 보이지 않아 짧게 번역한다.
- agile > 애자일
- 쓰임새: agile, agile project, agile leader, agile team, component of agile, techniques agile offers
- 선정: 처음에는 "기민한"으로 했다. 그러나 agile project, agile leader, agile team 등에 적용하면, 독자가 각각에 대해 본래부터 기민한 성격의 프로젝트, 리더, 팀으로 오인할 소지가 있다. 특히 component of agile, techniques agile offers처럼 명백하게 명사로 쓰인 경우는 agile method/practices 등의 줄임말로 볼 수 있어 '애자일'이라고 음차표기한다.
- delivery team > 개발팀
- 사전을 찾아보면 delivery에 대응하는 단어는 배달, 인도, 납품, 출하 등이다. 그러나 이 글1에서는 프로젝트팀을 복수의 delivery team과 하나의 management team으로 구분하고 있다. 우리가 주로 쓰는 어휘를 고려하여 개발팀과 관리팀으로 각기 대응시켰다. 글을 성격상 굳이 인도팀, 납품팀, 출하팀이란 용어를 도입할 필요는 없다.
- delivery pace는 인도 속도로 번역한다.
- senior architect > 수석 아키텍트
- 출판사에서 지정
- story > 스토리
- 쓰임새: story, story's task, story completion, story point, story delivery, story estimate, story card (wall), story status
- 선정: 처음에는 일반적인 단어로 바꾸려고 했다. 이 글이 반드시 '스토리'를 채용한 프로젝트에서만 가치 있다고 보이지 않았기 때문이다. 그러나 작업이라고 표기하기엔 위에 기록한 다양한 쓰임새마다 일일이 일반화한 번역이 필요했다. 그 과정에서 오히려 오해를 낳을 수 있어 역시 음차표기한다.
- daily stand-up meeting > 일일 점검회의
- 처음에는 '일일 스탠드업 회의'로 번역했다. stand-up 부분의 음차표기를 피하려고 고민하다가 점검을 택했다. stand-up에서 중요한 의미는 서서 회의하는 데에 있지 않다. 어제의 진척과 오늘의 과업에 초점을 맞춰 짧게 진행하고, 별도 공간에서 회의를 따로 준비하는 번거로움을 줄이는 데 있다. 이런 근거로 점검을 적절한 단어라고 판단했다.
- technical lead > 선임 개발자
- '기술 리더'라고 했다가 구글링 해보니 8,000건 정도밖에 나오지 않았다. 'technical lead'로 위키피디아를 찾으면, Lead programmer 페이지로 간다. 영어권에서도 정립 중인 역할인지 유사어가 상당히 많다.
- Alternative titles include Development Lead, Technical Lead, Senior Software Engineer, Software Design Engineer Lead (SDE Lead), Software Manager, or Senior Applications Developer.
- '선임 개발자' 역시 구글링 결과는 미미하지만, 뚜렷한 대표어도 없어 주변에서 흔히 들어온 용어로 대치한다.
- lead business analyst > 선임 분석가
- '선도 업무 분석가', '선임 업무 분석가' 모두 구글 검색 결과가 없다. '선도 분석가'가 1건을 검색했지만 '선임 분석가'는 1,720건이다. 영문을 함께 적기 때문에 의미가 더 명확할 수 있는 '선임 업무 분석가' 대신 이미 쓰인 바 있는 '선임 분석가'를 쓴다.
- infrastructure > 기반구조
- '기반구조'와 '인프라' 사이에서 고민하다가 가능하면 외래어를 쓰지 않기로 결정.
- metrics > 측정지표
- 네이버/엠파스 영어 사전 모두 명사로는 뜻이 없거나 빈약했다. 위키피디아 설명은 다음과 같다.
- A metric is a standard unit of measure, such as meter or mile for length, or gram or ton for weight, or more generally, part of a system of parameters, or systems of measurement, or a set of ways of quantitatively and periodically measuring, assessing, controlling or selecting a person, process, event, or institution, along with the procedures to carry out measurements and the procedures for the interpretation of the assessment in the light of previous or comparable assessments.
- 꽤나 포괄적으로 사용함을 알 수 있다. 본문으로 돌아가서 주로 사용한 맥락이 수행 과정 및 결과에 대한 지표이기에 '측정지표'라고 번역한다. 위키피디아에서도 다음과 같은 설명을 찾을 수 있다.
- In business, they are sometimes referred to as key performance indicators,...
- just-in-time decision making > 적시 의사결정
- '적시'란 표현이 간결하면서 자연스럽고 구글링 결과도 적지 않다.
- Knowledge-Based Engineering > 지식기반공학
- Lean Development System > 린 개발 시스템
- Set-Based Concurrent Engineering > 집합기반 동시공학
 |
소트웍스 앤솔러지 : 소프트웨어 기술과 혁신에 관한 에세이 -  마틴 파울러 외 지음, 강규영 외 옮김/위키북스 |
보너스로 좋은 리뷰가 있어 소개합니다.
소트웍스 앤솔러지(ThoughtWorks Anthology) - 소프트웨어 기술과 혁신에 관한 에세이
- 반복 관리자란 무엇인가? [본문으로]
글
Groovy in action
2009 이야기
2009/02/14 00:47
인사이트에서 Groovy in action 번역서 출간을 준비 중이다. 추천사 부탁을 받아서 읽어보는 중이다.
1장에 나온 그림을 보면 Groovy가 무엇을 줄 수 있는지 대강의 윤곽을 확인할 수 있다. 먼저 읽은 독자평은 어떨까? 아마존 평점은 좋다.
프랑스의 스프링 개발자 Michael Isvy1가 친구라고 자랑했던 Guillaume Laforge가 공동 저자 중 한 명이다. Guillaume Laforge는 Groovy 프로젝트 관리자이다. Guillaume Laforge를 포함하여 3명의 Groovy 개발자(Guillaume Laforge, Dierk Koenig, Paul King)가 쓴 책이란 사실만으로도 Groovy 바이블로 간주할 수 있다.
전체 3부 중에서 2부 내용은 데이터베이스 연계, ORM, XML 처리와 셸(shell) 스크립팅, 스프링 연동까지 다양한 Groovy 라이브러리를 포괄적으로 다루고 있다. 실용적인 책 구성을 확인함과 동시에 Groovy가 자바와 비교하면 얼마나 배우기 수월한지 간접적으로 확인할 수 있다.
3부는 Groovy 개발자가 활용하는 좋은 기법을 짜임새 있게 소개한다. 가령, 단위 테스트를 다룬 장에서도 비단 GroovyTestCase 활용뿐 아니라, 다양한 이클립스 플러그인을 활용하는 방안을 알려준다. 사실 이는 선도적인 자바 개발자 사이에서 널리 쓰이는 기법이기도 하다. 3부에는 또한 COM/ActiveX 등 윈도우 기술에 기반을 둔 클라이언트 프로그램 개발이나 스크립트 자동화 등과 같이 당장 현장에서 효과를 발휘할 수 있는 기법을 소개하고 있으니 문법을 익히고 나서 원하는 기법부터 먼저 활용할 수도 있을 듯하다.
그 외에 눈에 띄는 사항
p.s. 한국어 맞춤법/문법 검사기 쓰기 5주 만에 처음으로 오타 없는 글을 썼다. :)
1장에 나온 그림을 보면 Groovy가 무엇을 줄 수 있는지 대강의 윤곽을 확인할 수 있다. 먼저 읽은 독자평은 어떨까? 아마존 평점은 좋다.
프랑스의 스프링 개발자 Michael Isvy1가 친구라고 자랑했던 Guillaume Laforge가 공동 저자 중 한 명이다. Guillaume Laforge는 Groovy 프로젝트 관리자이다. Guillaume Laforge를 포함하여 3명의 Groovy 개발자(Guillaume Laforge, Dierk Koenig, Paul King)가 쓴 책이란 사실만으로도 Groovy 바이블로 간주할 수 있다.
전체 3부 중에서 2부 내용은 데이터베이스 연계, ORM, XML 처리와 셸(shell) 스크립팅, 스프링 연동까지 다양한 Groovy 라이브러리를 포괄적으로 다루고 있다. 실용적인 책 구성을 확인함과 동시에 Groovy가 자바와 비교하면 얼마나 배우기 수월한지 간접적으로 확인할 수 있다.
3부는 Groovy 개발자가 활용하는 좋은 기법을 짜임새 있게 소개한다. 가령, 단위 테스트를 다룬 장에서도 비단 GroovyTestCase 활용뿐 아니라, 다양한 이클립스 플러그인을 활용하는 방안을 알려준다. 사실 이는 선도적인 자바 개발자 사이에서 널리 쓰이는 기법이기도 하다. 3부에는 또한 COM/ActiveX 등 윈도우 기술에 기반을 둔 클라이언트 프로그램 개발이나 스크립트 자동화 등과 같이 당장 현장에서 효과를 발휘할 수 있는 기법을 소개하고 있으니 문법을 익히고 나서 원하는 기법부터 먼저 활용할 수도 있을 듯하다.
그 외에 눈에 띄는 사항
- 한 장을 할당한 클로저(Closure)
- 역시 한 장을 할애한 단위 테스팅
- MarkupBuilder, Meta programming in Groovy
- 스크립트 자동화
- Scriptom
p.s. 한국어 맞춤법/문법 검사기 쓰기 5주 만에 처음으로 오타 없는 글을 썼다. :)
- 이번 JCO 컨퍼런스 유일한 외국인 발표자인 SpringSource 컨설턴트 [본문으로]
글
나는 언제 스스로를 아키텍트라고 소개할 수 있을까? (2009)
2008/소프트웨어 설계
2009/02/14 00:08
두 달쯤 전에 아래와 같은 가벼운 글을 썼다. 그런데 훌륭한 글을 발견해 소개하고자 한다.
코더(Coder), 프로그래머(Programmer), 소프트웨어 아키텍트(Software Architect), 그리고 구루(Guru)
이제 저는 비켜 드릴 테니 가서 보시라.
2008. 12. 18
많은 프로젝트에 아키텍트가 없어서 아키텍처 수립을 하곤 했지만, 스스로 아키텍트라고 하긴 낯이 간지럽다. 언제쯤 부끄럼없이 저는 아키텍트입니다라고... 할 수 있을까? 평소 궁금했는데 방금 InfoQ에 뜬 기사를 보니...
코더(Coder), 프로그래머(Programmer), 소프트웨어 아키텍트(Software Architect), 그리고 구루(Guru)
이제 저는 비켜 드릴 테니 가서 보시라.
2008. 12. 18
많은 프로젝트에 아키텍트가 없어서 아키텍처 수립을 하곤 했지만, 스스로 아키텍트라고 하긴 낯이 간지럽다. 언제쯤 부끄럼없이 저는 아키텍트입니다라고... 할 수 있을까? 평소 궁금했는데 방금 InfoQ에 뜬 기사를 보니...
현장의 요구에 따라서 이런 그림 한장 그려내고, 훌륭하게 개발팀을 지휘해서 결과를 실현할 수 있다면... 말할 수 있을 것 같다. 그런데.. 가만 생각해보니, 내 꿈이 아키텍트는 아닌 것 같다. ^^
글
Xper 그룹스의 개발량 편차 좁히기에 대한 논의
2009 이야기
2009/02/13 21:26
개발자의 개발량의 편차가 매우 큰 경우에 대한 논의가 뜨겁군요. 김창준님과 캐빈님 의견이 눈에 띄네요. 내용 자체보다는 관점이 분명하게 나뉜다는 사실에 더 관심이 갑니다. 김창준님의 글은 애자일 컨설턴트답습니다.
위와 같은 말로 시작해서 구체적인 방안을 설명하고 있습니다. 읽고 있자니 마치 글에서도 차분함이 느껴지는 듯합니다. 반면 프로세스/방법론을 주업으로 하는 캐빈님의 경우는 곳곳에 프로세스/방법론을 내포한 표현이 자주 보입니다.
찬찬히 다시 살펴보니 서로 가정한 문맥이 다를 뿐, 일면 비슷한 방식이 아닌가 헷갈리기도 합니다. 하지만, 사용하는 어휘에서 확연한 구분을 찾을 수 있습니다.
캐빈님이 성과(4회)나 보상(1회) 등의 대규모 조직을 떠올리게 하는 단어를 주로 사용했다면, 창준님은 대화(2회)나 욕구(2회) 등의 표현을 쓰셨습니다. 글 타래 전체를 놓고 찾아보면 더욱 흥미로운 사실을 알 수 있습니다.
성과는 변신철님(3회)과 주넥님(2회)이 함께 사용했고, 보상1은 주넥님(3회)이 함께 사용했네요. 원래 질문에는 없던 단어를 세 분 이서 활용하셨군요. 반면, 창준님이 쓴 두 단어는 최승준님도 함께 쓰고 있었습니다.(욕구 2회, 대회 1회)
관련 글:초보 선장 시절에 대한 반추
저라면 다음과 같은 작업들을 우선 해보겠습니다.
위와 같은 말로 시작해서 구체적인 방안을 설명하고 있습니다. 읽고 있자니 마치 글에서도 차분함이 느껴지는 듯합니다. 반면 프로세스/방법론을 주업으로 하는 캐빈님의 경우는 곳곳에 프로세스/방법론을 내포한 표현이 자주 보입니다.
협력이 성과로 연결되는 상황
성과목표로 부여하기, 자주 보상해 주기
성과목표로 부여하기, 자주 보상해 주기
찬찬히 다시 살펴보니 서로 가정한 문맥이 다를 뿐, 일면 비슷한 방식이 아닌가 헷갈리기도 합니다. 하지만, 사용하는 어휘에서 확연한 구분을 찾을 수 있습니다.
캐빈님이 성과(4회)나 보상(1회) 등의 대규모 조직을 떠올리게 하는 단어를 주로 사용했다면, 창준님은 대화(2회)나 욕구(2회) 등의 표현을 쓰셨습니다. 글 타래 전체를 놓고 찾아보면 더욱 흥미로운 사실을 알 수 있습니다.
성과는 변신철님(3회)과 주넥님(2회)이 함께 사용했고, 보상1은 주넥님(3회)이 함께 사용했네요. 원래 질문에는 없던 단어를 세 분 이서 활용하셨군요. 반면, 창준님이 쓴 두 단어는 최승준님도 함께 쓰고 있었습니다.(욕구 2회, 대회 1회)
관련 글:초보 선장 시절에 대한 반추
- incentive 포함 [본문으로]
글
초보 선장 시절에 대한 반추
2009 이야기
2009/02/13 08:10
개발자의 개발량의 편차가 매우 큰 경우라는 흥미로운 질문이 있다.
2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지
해결책을 이야기하려는 의도는 아니다. 처음 팀장을 맡았을 때가 생각나서 글을 쓴다. 무엇보다 가장 힘든 일은 팀원을 관리하는 일이었다. 관리라는 말이 적절한지는 의문이 있지만, 일단 그렇게 부르겠다. 나보다 나이가 많은 팀원이 우리 회사 직원도 아니라면 어찌 대해야 할까? 회사에서 지시해서 참여하고 싶지 않은 프로젝트에 들어온 팀원은? 빵과 드라마에 대해 주로 이야기하는 여자 개발자에게 어떠한 방법으로 동기를 부여할 수 있을까? 자기 의도를 거의 설명하지 못하는 개발자는? 설계를 해야 하는 친구가 검증도 없이 코드만 한참 짜 놓았다면? 몇 주 동안 작업한 내용이 무용지물이 될 만큼 자기 스타일 안에서 작업하는 친구는?
이미 오래전 이야기이다. 돌아보면 한편으로는 처음이라 잔뜩 경계하는 초보 팀장의 모습이고, 다른 한편으로는 머리로만 살아온 까칠한 팀장의 모습이다. 당시 우리는 인력 구성은 꽤나 훌륭했다. 다만, 팀장이 초행길을 나섰고, 아직 우리는 팀이 아니었다. 서로 모여 팀을 구성했지만, 아직 팀워크 즉 팀으로 작업을 진척하는 데는 익숙지 않았다.
이 시점에서 가장 좋아하는 만화인 원피스가 떠오른다. 각기 다른 이유를 갖고 있지만, 함께 항해하는 해적선(?). 가끔 빈번하게 드러나는 문제에 대해서 SI 혹은 소프트웨어 분야를 탓한다. 하지만, 어찌 여기만 그러하겠는가? 사실 위에서 제기한 문제는 소프트웨어 개발분야에 국한한 문제는 아니다. 유독 애자일 개발에서만 드러나는 고민 역시 아니다.
이렇게 바꿔보자.
1. 줄곧 일등만 하는 우리 아이가 우쭐해 하고 버릇없이 굴지 않게 하려면 어떻게 할까?
2. 항상 공부 잘하는 형 때문에 주눅들어하는 둘째 녀석에게 어떻게 하면 용기를 줄 수 있을까?
많은 부모님이 고민하는 위와 같은 문제는 완전히 다른 문제일까? 자칫 질문에 대한 부정으로 오해할까봐 노파심이 생겨서 말해두지만, 추억으로 데려가서 다양한 사고를 하게 해준 질문에 대해 감사한다.1
질문을 존중하는 태도로 돌아가서 현장의 상황을 정확히 알 수 없는 상황에서 어떠한 일반적인 조언을 해줄 수 있을까? 기법 관점에서는 자연스런 지식 교류와 동료 의식을 높일 수 있는 짝 프로그래밍이 어떨까 싶지만, 실전에서 해보지도 않는 기법을 추천할 순 없는데다가 질문하신 분이 이미 불가능한 상황을 전제했다. 기법은 포기하고 초보 팀장 시절에 막막한 상황을 타개한 방법은 무엇이었을까? 일시적인 짝 프로그래밍 시도, 팀원 취향을 고려한 개인 면담 등 다양한 방법을 시도했다. 더 좋은 방법을 찾으려고 회고도 시도하고, 다양한 조합, 다양한 형태로 리뷰를 했다.
하지만, 해결책은 팀원에 대한 믿음이 아니었나 싶다. 믿음이 주는 효과를 증명할 순 없어 단지 짐작일 뿐이지만, 내가 팀원을 믿는 순간 모두가 다르게 보였다. 각 개인의 능력 차를 부정할 수 없지만, 개발을 잘하는 팀원과 못하는 팀원으로 나누어 보는 순간은 점차 줄었다. 대신, 각 팀원의 성향에 대해서 더 잘 이해했다. 최대한 구체적으로 작업을 지시해주면 빠른 결과를 내는 친구, 자신감을 심어주면 확연하게 결과가 달라지는 친구, 더러는 그냥 둬도 짧은 회의와 진도 확인만으로도 자기 몫을 하는 친구도 있다. 개발을 잘 못하는 친구는 코드 검증이나 가이드 작성을 시킬 수도 있다. 설령 이전에는 자신보다 개발이 더딘 동료였을지 몰라도 어느 순간 모두의 짐을 단번에 덜어주는 조력자로 바뀌었다. 섣불리 이런 일화가 해결책이라고 말할 수는 없다. 책을 포함해서 다른 사람의 경험은 그저 영감을 전할 뿐이고, 답은 항상 현장에 있다.
2009.2.14
to 낭만거미의 생각.:
팀원에 대한 믿음은 그가 자기 몫을 해내리라는 믿음이다. 과거의 나처럼 막연히 팀원이 내 기대를 충족해줄 것을 기대하는 것은 믿음이 아니라 요행을 바라는 마음이다. 로또 당첨을 바라는 것과 무어가 다른가?
* 이미지 출처: http://i155.photobucket.com/albums/s307/Renjiro_Chiyo/One%20Piece/One_Piece_Crew.jpg
특정 개발자가 50 정도의 속도로 작업을 수행하고, 대부분의 팀은 20 정도의 일을 수행하고, 한 명은 10 정도의 속도를 가지고 있습니다. 쉽게 말해 속도가 느린 개발자와 빠른 개발자의 개발 량이 거의 5배의 차이가 나는거죠.
이슈는 두 가지인데요
2. 어떻게 10의 속도를 가진 개발자의 속도를 30 정도로 높일 수 있을지
해결책을 이야기하려는 의도는 아니다. 처음 팀장을 맡았을 때가 생각나서 글을 쓴다. 무엇보다 가장 힘든 일은 팀원을 관리하는 일이었다. 관리라는 말이 적절한지는 의문이 있지만, 일단 그렇게 부르겠다. 나보다 나이가 많은 팀원이 우리 회사 직원도 아니라면 어찌 대해야 할까? 회사에서 지시해서 참여하고 싶지 않은 프로젝트에 들어온 팀원은? 빵과 드라마에 대해 주로 이야기하는 여자 개발자에게 어떠한 방법으로 동기를 부여할 수 있을까? 자기 의도를 거의 설명하지 못하는 개발자는? 설계를 해야 하는 친구가 검증도 없이 코드만 한참 짜 놓았다면? 몇 주 동안 작업한 내용이 무용지물이 될 만큼 자기 스타일 안에서 작업하는 친구는?
이미 오래전 이야기이다. 돌아보면 한편으로는 처음이라 잔뜩 경계하는 초보 팀장의 모습이고, 다른 한편으로는 머리로만 살아온 까칠한 팀장의 모습이다. 당시 우리는 인력 구성은 꽤나 훌륭했다. 다만, 팀장이 초행길을 나섰고, 아직 우리는 팀이 아니었다. 서로 모여 팀을 구성했지만, 아직 팀워크 즉 팀으로 작업을 진척하는 데는 익숙지 않았다.
이 시점에서 가장 좋아하는 만화인 원피스가 떠오른다. 각기 다른 이유를 갖고 있지만, 함께 항해하는 해적선(?). 가끔 빈번하게 드러나는 문제에 대해서 SI 혹은 소프트웨어 분야를 탓한다. 하지만, 어찌 여기만 그러하겠는가? 사실 위에서 제기한 문제는 소프트웨어 개발분야에 국한한 문제는 아니다. 유독 애자일 개발에서만 드러나는 고민 역시 아니다.
이렇게 바꿔보자.
1. 줄곧 일등만 하는 우리 아이가 우쭐해 하고 버릇없이 굴지 않게 하려면 어떻게 할까?
2. 항상 공부 잘하는 형 때문에 주눅들어하는 둘째 녀석에게 어떻게 하면 용기를 줄 수 있을까?
많은 부모님이 고민하는 위와 같은 문제는 완전히 다른 문제일까? 자칫 질문에 대한 부정으로 오해할까봐 노파심이 생겨서 말해두지만, 추억으로 데려가서 다양한 사고를 하게 해준 질문에 대해 감사한다.1
질문을 존중하는 태도로 돌아가서 현장의 상황을 정확히 알 수 없는 상황에서 어떠한 일반적인 조언을 해줄 수 있을까? 기법 관점에서는 자연스런 지식 교류와 동료 의식을 높일 수 있는 짝 프로그래밍이 어떨까 싶지만, 실전에서 해보지도 않는 기법을 추천할 순 없는데다가 질문하신 분이 이미 불가능한 상황을 전제했다. 기법은 포기하고 초보 팀장 시절에 막막한 상황을 타개한 방법은 무엇이었을까? 일시적인 짝 프로그래밍 시도, 팀원 취향을 고려한 개인 면담 등 다양한 방법을 시도했다. 더 좋은 방법을 찾으려고 회고도 시도하고, 다양한 조합, 다양한 형태로 리뷰를 했다.
하지만, 해결책은 팀원에 대한 믿음이 아니었나 싶다. 믿음이 주는 효과를 증명할 순 없어 단지 짐작일 뿐이지만, 내가 팀원을 믿는 순간 모두가 다르게 보였다. 각 개인의 능력 차를 부정할 수 없지만, 개발을 잘하는 팀원과 못하는 팀원으로 나누어 보는 순간은 점차 줄었다. 대신, 각 팀원의 성향에 대해서 더 잘 이해했다. 최대한 구체적으로 작업을 지시해주면 빠른 결과를 내는 친구, 자신감을 심어주면 확연하게 결과가 달라지는 친구, 더러는 그냥 둬도 짧은 회의와 진도 확인만으로도 자기 몫을 하는 친구도 있다. 개발을 잘 못하는 친구는 코드 검증이나 가이드 작성을 시킬 수도 있다. 설령 이전에는 자신보다 개발이 더딘 동료였을지 몰라도 어느 순간 모두의 짐을 단번에 덜어주는 조력자로 바뀌었다. 섣불리 이런 일화가 해결책이라고 말할 수는 없다. 책을 포함해서 다른 사람의 경험은 그저 영감을 전할 뿐이고, 답은 항상 현장에 있다.
2009.2.14
to 낭만거미의 생각.:
팀원에 대한 믿음은 그가 자기 몫을 해내리라는 믿음이다. 과거의 나처럼 막연히 팀원이 내 기대를 충족해줄 것을 기대하는 것은 믿음이 아니라 요행을 바라는 마음이다. 로또 당첨을 바라는 것과 무어가 다른가?
* 이미지 출처: http://i155.photobucket.com/albums/s307/Renjiro_Chiyo/One%20Piece/One_Piece_Crew.jpg
- 요즘 거품 물고 나를 비방하는 OOO 이 있는데 신경 안 쓴다고 쿨한 척 했지만, 마음에 앙금이 남았는지 성격과 다르게 조심스러워진다. [본문으로]
글
Eager Read Derivation
MartinFowler
2009/02/12 00:53
QCon San Francisco에서 Greg Young이 근래에 시스템에 적용한 아키텍처에 대해 흥미로운 대화를 나눴다. Greg은 대단한 Domain Driven Design 팬인데, 이번에는 다량의 거래 처리를 하고, 수많은 사용자에게 데이터를 제공하는 시스템이었다. 나는 그의 설계에서 많은 흥미로운 사실을 발견했다. 특히, 그가 Event
Sourcing를 사용한 방식이지만, 여기서는 단 한 가지 측면에 대해서만 집중하길 원한다. 바로 Eager Read Derivation에 대해서다.
도메인 모델(Domain Model)은 복잡한 도메인 로직(domain logic)을 포함할 때 사용한다. 이러한 도메인 로직의 분류는 도움을 줄 수 있다:
- validations: 입력이 사리에 맞고, 객체를 앞으로 있을 행위에 맞게 적절히 준비했는지 확인
- consequences: 세상을 바꿀(?) 어떤 행위를 시작1
- derivations: 이미 보유한 정보를 바탕으로 새로운 정보를 끌어냄2
이러한 도메인 로직 유형은 조회보다는 갱신에 대해 다르게 적용한다. 우리가 족보 시스템을 갖고 있고, 출생 기록 개정이 있다고 가정하자.
이름: Bilbo Baggins
부: Bungo Baggins
모: Belladonna Took
이 데이터를 도메인 모델에 제출하면, '부모를 같이 입력하지 않았는가?' 등의 validation 을 한다. 이제 consequence를 낼 수 있다. Bungo가 Bilbo에게 줄 상당한 유산을 갖는다. 또한, derivation을 행할 수 있다. 그러나 대개는 validation 혹은 consequence만 지원한다. 가계도에 순환 관계가 없음을 확인하기 위해 Bilbo의 조상 목록이 필요할 수 있다.
대개 데이터를 읽을 때 derivation 로직이 쓰인다. Bilbo의 친할아버지 데이터 조회를 요청했다고 해보자. 필요한 도메인 로직은 친할아버지가 아버지의 아버지라는 지식이다. 시스템 대부분에서는 조회 요청을 받을 때 유도 로직을 동반한 조회를 수행한다. 본래 조회 요청이 있으면, 데이터베이스 호출을 통해 처리 이전의 데이터를 꺼내서, 필요한 유도 로직을 수행하고 결과를 반환한다. (이를 줄이려고 캐시를 쓰기도 한다.)
Eager read derivation은 다르다. 주요 데이터베이스 접근이 일절 없다. 대신 조회 요청과 동일하게 구성한 하나 이상의 보고 데이터베이스(ReportingDatabases)를 갖는다. 조회 요청은 도메인 로직 개입 없이 보고 데이터베이스에 접근해서 바로 데이터를 꺼낸다.
다시 출생 기록을 도식화한다.
- UI에서 출생 기록을 제출했다.
- 도메인 모델은 모든 validation 및 consequences 로직을 수행한다.
- 도메인 모델은 핵심 정보를 반영해 데이터베이스 레코드를 갱신한다.
- 도메인 모델은 개별 UI 출력을 포함해 모든 조회에 필요한 derivation logic을 실행하여 갱신 메시지를 메시지 큐를 통해 보고 데이터베이스로 보낸다.
- 친할아버지 관련 UI에서 요청한 조회는 보고 데이터베이스에서 친할아버지 테이블 접근으로 바로 해결할 수 있다.
Greg의 경우 모두가 비동기 메시지로 처리하고, 모든 입력은 이벤트로 포착하며(Event Sourcing), 도메인 모델은 입력 큐에서 메시지를 처리하고 출력 큐로 출력 이벤트를 공시에 보고 데이터베이스에서 데이터를 적재한다. 모두 비동기로 처리하여 전체적인 성능과 규모가변성 향상에 도움을 준다. 여기에는 불일치가 발생하는 순간이 존재함을 의미하기도 한다. 갱신을 처리하는 순간 조회가 이뤄지면, 메시지 처리보다 빨리 클릭이 이뤄져 갱신 결과를 보지 못할 수 있다. 이러한 비동기 계획은 완벽하게 일관적이지 않지만, 결국 일관성이 있긴 하다. 그러나 이를 거스를 수는 없다. 분산 시스템이라면 일관성을 택하거나 가용성을 택하거나 둘 중 하나다.
이제 분산환경이 아니어도 완벽하게 일관성을 유지하는 방법으로 eager read derivation을 할 수 있다. 그런 상황을 목격했었는지 확실치 않다. 내 생각엔 eager read derivation은 주로 높은 분산 요구에 적합하다.
eager evaluation은 전혀 새로운 내용이 아니다. 나보다 오래되었고, 어쩌면 Ron Jeffries 이전에도 있었을지 모른다. 그리고 대부분의 대용량 웹 사이트(high-volume websites)에서는 항상 파생 데이터(derived data)도 데이터베이스에 저장한다. 그러나 종래의 기법이 권장할만한 것은 아니며, 나는 Greg의 설계처럼 적극적인 방법을 좋아한다.
글
거슬리는 플래시 광고 제거하기
2009 이야기
2009/02/11 13:46
인터넷으로 사전으로 이용하는데, 왼쪽에서 광고가 번쩍번쩍해 집중하기 어렵다. 집중력 훈련을 병행할 목적은 아니라서 광고를 제거하고 싶다. 파이어폭스를 새로 설치한 탓에 설치를 안 한 Adblock Plus를 다시 찾아 설치했다.
기억해야 할 메뉴는 하나다. View > Adblock Plus: Blockable Items인데, 단축키가 있다. Ctrl+Shift+V
걸러내고 싶은 URL을 선택하고 엔터 키를 친다. URL 위에 마우스를 두면 미리 보기를 실행한다. URL만으로는 알 수 없는 이미지를 찾는 데 유용한 기능이다.
광고가 사라졌다. 다시 보고 싶으면, Blockable Items 창을 열고 Disable Filter 명령을 수행한다.
기억해야 할 메뉴는 하나다. View > Adblock Plus: Blockable Items인데, 단축키가 있다. Ctrl+Shift+V
걸러내고 싶은 URL을 선택하고 엔터 키를 친다. URL 위에 마우스를 두면 미리 보기를 실행한다. URL만으로는 알 수 없는 이미지를 찾는 데 유용한 기능이다.
광고가 사라졌다. 다시 보고 싶으면, Blockable Items 창을 열고 Disable Filter 명령을 수행한다.
글
리팩토링에 익숙해지기 2
2009 이야기
2009/02/10 09:18
The goal is clean code that works. [...] First we'll solve the "that
works" part of the problem. Then we'll solve the "clean code" part.
This is the opposite of architecture-driven development, where you
solve "clean code" first, then scramble around trying to integrate into
the design the things you learn as you solve the "that works" problem.
마치 정리하지 않은 디렉터리처럼 코드 역시 마냥 필요에 따라 고쳐가도 작동(works)한다. 그러나 애초부터는 고사하고 시간이 지나고 깨끗이(clean) 정리하지 않으면 작동을 하더라도 유지하기 어렵다. 4개월 넘게 디렉터리 정리 없이 즉흥적으로 썼더니 파일이 중복으로 존재한다. 4개월간 쌓인 파일을 새로운 기준으로 정리하려니까 만만치 않다. 무슨 일이든 작동과 정리(간결히 하기) 사이는 짧을수록 좋다.
글
리팩토링에 익숙해지기
2009 이야기
2009/02/09 08:29
“In order to do Scrum or XP or any form of Agile successfully, you must refactor. Sorry, not optional. Necessary.”
We must evolve the infrastructure. It’s not a rule, it’s worse. It’s essentially a law of nature.
We must evolve the infrastructure. It’s not a rule, it’s worse. It’s essentially a law of nature.
Ron Jeffries의 촌철살인이다. 요즘 공개한 API를 다시 돌아보면서, 온 힘을 다해 정제하지 않은 과거가 부끄러웠다. 의기소침해진 나에게 '그러면서 배우는 것이야.'라고 격려하는 듯하다.
어느 시점에서든 최고의 코드를 만들자고 눈에 불을 켜고 검토하고 수정해도 최고일 순 없었을 것이다. 적절한 간격으로 영리하고 기민하게 일을 하지 못했을 뿐이다. 1
- 의지가 부족해 게을리 보냈던 시간이 있었음이야 물론 말할 필요도 없다. [본문으로]
글
SpringSource의 직원 Michael Isvy와 만나실 분
2009 이야기
2009/02/07 08:30
SpringSource의 직원인 Michael Isvy가 다음 주에 5일 정도 한국을 방문합니다. 저녁 시간에 함께 하며 이야기하는 자리를 가질 예정입니다. 제가 영어가 짧아 대화가 어려운 상황인데, 혹시 Spring에 관심이 있고, 영어에 능통하신 분이 있다면 함께 했으면 좋겠군요. 의향이 있는 분이 있으시다면, 아래 메일로 연락처를 보내주세요. :)
글
제10회 JCO 콘퍼런스 강의 구성
2009 이야기
2009/02/06 08:30
갑자기 취소한 강의 탓에 TFT에서 어렵게 확정한 테이블에서 이가 하나 빠졌다. 그렇지만, 하나의 세션을 빼면 강의를 모두 확정했다.10번째 JCO 콘퍼런스 준비 상황에서 약간 변동이 있다.
먼저 이번 콘퍼런스의 유일한 외국인 발표자인 Michael Isvy가 Dr Paul Chapman 대신 What's New and Cool in Spring's Web Stack?이라는 제목으로 발표한다. 이미Spring 공식 교육 5월 연기와 Michael Isvy의 제10회 JCO 콘퍼런스 발표에서 공지한 바 있다.
2월 2일까지는 확정하지 못했던 나머지 하나의 Hands-on-Lab은 이희승님의 '자바 네트워킹 기초에서 응용까지'이다. 이희승님에 대해서는 별도 소개가 필요없을 듯도 한데 현재 Red Hat의 미들웨어 부서인 JBoss의 수석 소프트웨어 엔지니어로 일하고 있다. 다음은 이희승님이 보내 온 강의 소개 내용이다.
먼저 이번 콘퍼런스의 유일한 외국인 발표자인 Michael Isvy가 Dr Paul Chapman 대신 What's New and Cool in Spring's Web Stack?이라는 제목으로 발표한다. 이미Spring 공식 교육 5월 연기와 Michael Isvy의 제10회 JCO 콘퍼런스 발표에서 공지한 바 있다.
2월 2일까지는 확정하지 못했던 나머지 하나의 Hands-on-Lab은 이희승님의 '자바 네트워킹 기초에서 응용까지'이다. 이희승님에 대해서는 별도 소개가 필요없을 듯도 한데 현재 Red Hat의 미들웨어 부서인 JBoss의 수석 소프트웨어 엔지니어로 일하고 있다. 다음은 이희승님이 보내 온 강의 소개 내용이다.
많은 이들이 자바로 애플리케이션을 개발한다 하면 미들웨어 기반의 웹 개발을 떠올린다. 하지만, 더 넓은 시야에서 보면 웹
브라우저를 통해 접근하는 웹 애플리케이션은 단지 HTTP라는 프로토콜을 채용한 TCP/IP 소켓 애플리케이션에 불과하다. 실제로
고도의 성능이 필요하거나 기존 시스템과 연동이 필요한 경우 소켓을 직접 다룰 일이 많다. 만약 여러분이 메시징 솔루션이나 게임
클라이언트 서버 개발을 해야 하는상황에 부닥쳤다면 본 Hands on Lab을 통해 많은 도움을 얻을 수 있을 것이다. 본
Hands on Lab에서는 신속한 이해를 돕고자 자바 네트워크 애플리케이션 개발에 필요한 배경 지식과 주의 사항을 설명하고,
강사가 직접 개발한 오픈 소스 프레임워크인 JBoss Netty를 통해 수준급의 네트워크 애플리케이션을 신속하고 간편하게
개발하는 방법을 배우게 될 것이다.
글
Spring 공식 교육 5월 연기와 Michael Isvy의 제10회 JCO 콘퍼런스 발표
2009 이야기
2009/02/05 09:33
3월에 열릴 예정이었던 Spring 공식 교육 일정을 5월로 연기했습니다. SpringSource에서 일본 사용자 그룹에 대해 묻더니, SpringSource의 아태교육 일정 페이지를 보면 그 경과를 짐작할 수 있습니다. 강사로 확정한 Paul Chapman이 한일 투어로 강의하는군요. SpringSource가 KSUG 회원을 대상으로 20% 할인을 해서 방법을 물었습니다. Paul이 답변하길 세미나에서 발표자인 SpringSource 직원에게 명함을 주거나, 이메일을 적어서 주면 할인을 해준다고 합니다.1 더 많은 분에게 기회를 주고자 KSUG 세미나 대신 JCO 콘퍼런스에 자리를 만들었습니다. 발표자 확정을 미루더니 교육 일정 변경과 때를 맞춰 어제 발표자를 확정해왔습니다. 프랑스 지부에서 온 Michael Isvy입니다. Spring 3.0 작업을 하고 있다고 해서 찾아보니 SPR-5455을 맡았네요. 문서화 작업(Write documentation for Spring 3.0 new annotations)이네요.
5월 교육을 희망하는 분은 아직 수강 신청을 안 하셨더라도 JCO에서 Michael Isvy의 강의를 듣고 명함도 전하세요. Michael Isvy의 강의는 마치 SpringOne 웹 트랙의 요약판과 같습니다. 애초에 Paul Chapman이 하기로 한 강의와 같은 내용입니다.
5월 교육을 희망하는 분은 아직 수강 신청을 안 하셨더라도 JCO에서 Michael Isvy의 강의를 듣고 명함도 전하세요. Michael Isvy의 강의는 마치 SpringOne 웹 트랙의 요약판과 같습니다. 애초에 Paul Chapman이 하기로 한 강의와 같은 내용입니다.
What's New and Cool in Spring's Web Stack?
Come along to a relaxed evening, meet your peers, have a drink on us and mingle whilst learning about the brand new Spring 2.5 MVC and Spring Web Flow 2 features...
Java developers are spoilt for choice when it comes to web frameworks, ranging from roll-your-own servlets through to the AJAX technologies we're seeing everywhere from Google Maps to Facebook. The Spring community enjoys comprehensive integration with over a dozen different web frameworks, such as Struts, JSF, Tapestry, Grails, RIFE, Wicket, GWT and Flex.
Despite so many web framework choices, a significant proportion of enterprise developers use Spring's own web support. This web support has been substantially improved in the recent Spring 2.5 and Spring Web Flow 2.0 releases. Spring's web support now features a long list of new capabilities, such as annotation-based controllers, partial page rendering, conversational state scoping, significant AJAX integration, a brand-new Spring JavaScript library, Spring Security integration, and an unprecedented number of JSF options.
At tonight's presentation, SpringSource's Dr Paul Chapman
<http://www.springsource.com/
This is a useful presentation for anyone interested in understanding the new Spring web framework improvements. With a focus on those capabilities added to the most recent releases, this presentation will be of benefit to both existing Spring web users as well as those who have never used Spring's web features before. Attendees will gain the most from this presentation if they have a basic understanding of Spring configuration and basic web application principles.
We're also giving away a hot-off-the-press (June 2008) Spring 2.5 book as a lucky door prize. We look forward to seeing you there!
Michael Isvy에 대한 소개입니다.
About Michael Isvy ...
Michael is a Senior Consultant within our French division where he
specializes in training and consulting.
Michael holds a Master's degree in Computer Science and Management and
has been working in the IT industry for 8 years. He started his career
as a Java developer and quickly became an architect on several Java
projects. 4 years ago he specialized in training and consulting. He has
conducted trainings about JEE, Spring, Hibernate, JSF, Struts, Maven,
Tomcat administration, Websphere administration, Design Patterns... In
the past four years, Michael has trained more than 500 people on Java
technologies.
Being a Senior Consultant, Michael regularly works for some of the
largest organizations helping them on solving various technical issues
(performance audit, migration to Spring technologies, Comparison of Java
Web frameworks...).
As a developer, Michael occasionally works on open-source project
development such as the Spring framework. He is currently working on the
upcoming Spring 3.0 release.
Michael is a Senior Consultant within our French division where he
specializes in training and consulting.
Michael holds a Master's degree in Computer Science and Management and
has been working in the IT industry for 8 years. He started his career
as a Java developer and quickly became an architect on several Java
projects. 4 years ago he specialized in training and consulting. He has
conducted trainings about JEE, Spring, Hibernate, JSF, Struts, Maven,
Tomcat administration, Websphere administration, Design Patterns... In
the past four years, Michael has trained more than 500 people on Java
technologies.
Being a Senior Consultant, Michael regularly works for some of the
largest organizations helping them on solving various technical issues
(performance audit, migration to Spring technologies, Comparison of Java
Web frameworks...).
As a developer, Michael occasionally works on open-source project
development such as the Spring framework. He is currently working on the
upcoming Spring 3.0 release.
- Attendees can simply give a business card to Michael if they are interested in attending. If they do register we have a record that they were there and can give them the discount. If they don't have the card. Michael will have some paper slips they can write their name and email address on. [본문으로]
글
자연의 섭리는 인간이 만든 체제에도 녹아 있을 터니
2009 이야기
2009/02/04 12:40
주제넘지만, 갑자기 사치스런 글이 쓰고 싶어졌다.
얼마 전 배포(Release)한 시스템(product)에 대해 즉각적인 결함 보고를 받고 민망했다. 역할이 제품 관리자였으니 얼굴이 후끈한 것이야 당연하다. 그리고 좀 생각해보았다. 부품 수준일 때부터 테스트하지 않는 현실에 대해서 말이다. 나부터도 개발에 대해 순간순간 온 힘을 다하지 못한다.
관리 영역에서 일하면서 느낀 바는 자본주의 체제의 무서움이다. 딱 낸 만큼 얻는다. 물론, 고생스럽게 일을 하고도 적게 얻는 일도 있다. 그 경우는 이미 강자에 의해 빼앗긴 경우다.
하여간 생각해보았다. 고객이 지나치게 헐값으로 시스템을 구축하는 관행. 흥미롭게도 그렇게 해서 얻어낸 제품은 결함투성이다. 심지어는 시스템 운영을 개시하자마자 고객 스스로 결함을 발견해서 보고한다. 이 얼마나 우스운 일인가? 돈을 낸 사람이 검증하는 역할을 직접 수행한다니.
고객이 내 얼굴에서 민망해하는 모습을 읽지 못했다. 고객이 기대하는 품질은 부끄러워하는 우리 팀이 만든 결과보다 훨~씬 아래서 형성되어 있기 때문이다. 아쉽게도 말이다.
얼마 전 배포(Release)한 시스템(product)에 대해 즉각적인 결함 보고를 받고 민망했다. 역할이 제품 관리자였으니 얼굴이 후끈한 것이야 당연하다. 그리고 좀 생각해보았다. 부품 수준일 때부터 테스트하지 않는 현실에 대해서 말이다. 나부터도 개발에 대해 순간순간 온 힘을 다하지 못한다.
관리 영역에서 일하면서 느낀 바는 자본주의 체제의 무서움이다. 딱 낸 만큼 얻는다. 물론, 고생스럽게 일을 하고도 적게 얻는 일도 있다. 그 경우는 이미 강자에 의해 빼앗긴 경우다.
하여간 생각해보았다. 고객이 지나치게 헐값으로 시스템을 구축하는 관행. 흥미롭게도 그렇게 해서 얻어낸 제품은 결함투성이다. 심지어는 시스템 운영을 개시하자마자 고객 스스로 결함을 발견해서 보고한다. 이 얼마나 우스운 일인가? 돈을 낸 사람이 검증하는 역할을 직접 수행한다니.
고객이 내 얼굴에서 민망해하는 모습을 읽지 못했다. 고객이 기대하는 품질은 부끄러워하는 우리 팀이 만든 결과보다 훨~씬 아래서 형성되어 있기 때문이다. 아쉽게도 말이다.
글
고산자(古山子) 김정호식 정리
2009 이야기
2009/02/04 08:06
언제였나 기억은 나지 않지만, 김정호가 대동여지도를 만든 과정에 대해 들으면서 참 지독하다는 생각을 한 일이 있다. 굳이 저렇게까지 할 이유가 있을까 싶었다. 그런데 시간이 흐르고 존재 이유를 떠올려보니 존경해 마지 않는다.
방금 일민형을 통해 입이 딱 벌어지는 정리를 목격했다. 아직 저 정도로 정성을 들여 무언가 작품을 만들기엔 의지가 많이 부족하다. 하지만, 올해는 흉내라도 내보고 싶다. :)
방금 일민형을 통해 입이 딱 벌어지는 정리를 목격했다. 아직 저 정도로 정성을 들여 무언가 작품을 만들기엔 의지가 많이 부족하다. 하지만, 올해는 흉내라도 내보고 싶다. :)
글
Ron Jeffries가 말하는 스크럼 계획 절차
2009 이야기
2009/02/03 08:00
다음은 Ron Jeffries가 권하는 스크럼(Scrum) 계획 절차다.
한편, 7번 역시 매우 중요한 내용이다. 문맥이 내포한 의미를 Chris Sims가 풀어 설명하는 글이 있다. 유사한 사례를 경험한 바 있으니 바로 그 기억이 찾아온다. 스크럼을 처음 적용할 때 기존 관행에 젖어서 요구 사항2을 개별 작업자가 공수 산정이 가능하게끔 잘게 쪼개서 계획을 세운 바 있다. 이런 방식은 애자일의 기본적인 접근 방식에 반하는 Big-Bang 스타일이다. 애자일 기반으로 작업 관리를 할 때, 기존 유산과 어떻게 조화를 이룰지 고민해야 한다. 여기서 말하는 유산의 예로는 WBS, 조직의 진척 산정 방식, 기존에 만들어 놓은 PMS의 입력 방식, 그리고 나를 포함한 팀원의 사고방식 등이 있다.
- Product owner writes story on whiteboard, and explains it.
- Briefly discuss how the story will be tested.
- Developers briefly brainstorm and list technical steps needed.
(Similar to tasks but we’re not going to do the work, nor track it that way.) - Repeat until enough stories are on the board.
- Look at the list, draw the line where you’re confident you can accomplish everything above the line.
- Commit
- Do stories as a unit, not broken into tasks.
- Burn stories, not tasks.
- 한 번도 써 본 일이 없는 새로운 시스템 구현
- 프레임워크나 라이브러리 구현
- C/S 기반의 시스템만 쓰던 사용자가 웹 기반 시스템 요건을 정의할 때
한편, 7번 역시 매우 중요한 내용이다. 문맥이 내포한 의미를 Chris Sims가 풀어 설명하는 글이 있다. 유사한 사례를 경험한 바 있으니 바로 그 기억이 찾아온다. 스크럼을 처음 적용할 때 기존 관행에 젖어서 요구 사항2을 개별 작업자가 공수 산정이 가능하게끔 잘게 쪼개서 계획을 세운 바 있다. 이런 방식은 애자일의 기본적인 접근 방식에 반하는 Big-Bang 스타일이다. 애자일 기반으로 작업 관리를 할 때, 기존 유산과 어떻게 조화를 이룰지 고민해야 한다. 여기서 말하는 유산의 예로는 WBS, 조직의 진척 산정 방식, 기존에 만들어 놓은 PMS의 입력 방식, 그리고 나를 포함한 팀원의 사고방식 등이 있다.
- 테스트에 대한 오해가 떠올라 테스트란 단어를 쓰기 망설여진다. [본문으로]
- 우리는 스크럼 원형 그대로를 적용하지는 않았기 때문에 스토리를 쓰지 않았다. [본문으로]
글
공정 분리와 분업의 전제
2009 이야기
2009/02/02 18:00
흥미로운 포스트가 올라왔다. 설계가 완벽하지 않아야 하는 이유. 설계가 완벽할 수 없는 이유에 덧붙이는 주장이고, 프로젝트 시작부터 개발자가 바글바글이란 글에 대한 반박이 있다.
설계가 완벽하지 않아야 하는 이유는 도표와 함께 self-funding point라는 다소 어려운 용어로 읽는데 다소 장벽이 있었지만, 자세히 살펴볼수록 공감하고 동의했다. 두 가지 사항을 이야기하고 싶다. 하나는, 프로젝트 시작부터 개발자가 바글바글에 대해 동의하지 않았던 부분이고, 다른 하나는 강규영님이 그래프를 이용해 과학적으로 표현한 내용을 더 많은 사람이 공유하려고 현실에서 드러나는 사례를 하나 말하고 싶다.
프로젝트 시작부터 개발자가 바글바글에 대해 반은 동의하고, 반은 반대한다. 여러 사업 수행조직과 일하다 보면 인력 투입의 효용성은 분명히 사업 수행 역량의 중요한 지표이다. 대형 프로젝트의는 가변성이 높지만, 계약은 프로젝트 착수에 선행한다. 그래서, 인력 투입 문제도 사업 수행 관점에서는 예산 범위에서 돈을 쓰는 문제이다. 사업 수행 측면에서 프로젝트 시작부터 개발자가 바글바글에서 지적한 내용은 아주 기본적인 상식이다. 동감하는 바지만, 강규영님이 제시한 것처럼 인력 교체를 효율적으로 하는 방법 외에 다른 해결책이 있고, 더욱 효과적이란 점에 절대적으로 동의한다.
공정 분리와 분업은 먼저 명확한 역할 분리와 역할 사이의 계약에 기초하고 있다. 계약이란 말은 적절한 단어가 없어서 어렵게 썼는데, 선행 작업자의 산출물을 다음 사람이 받아서 과업을 진행하는데 무리가 없어야 한다. 그런데 대부분은 설계자 철수 후 개발자를 투입하는 경우 소프트웨어 설계 산출물이 구현으로 이어지는 데는 병목을 관찰할 수 있다. 설계 산출물을 통해 개발자가 분석, 설계 사항을 그대로 전수받는 일은 아직 어렵다. 화면 설계와 ERD만으로 시스템 개발이 가능한가? UML 다이어그램? UML은 중요한 업무 규칙을 표현하기엔 여전히 범용성이 떨어진다.1 얼마 전 언급한 칼럼의 주장처럼 조기 인스펙션 강조 역시 같은 맥락이라고 본다.
언젠가는 우리 업종에서도 완벽한 설계서가 구현으로 이루어져 명확한 분업이 가능한 날이 올 수도 있겠지만, 아직은 그러한 분업을 효과적으로 실행하기에 성숙도가 낮다고 생각한다. 전통적인 방식 안에서 문제 해결을 꾀하는 것이 현실적이라 할 수 있다. 그러나 반복해서 실패(?)한 경험2이 있다면 분업을 위해서는 산업 성숙도가 낮음을 인정(혹은 SW 업종의 특성 탓이라고 하던)하고, 애자일 도입을 조직차원의 학습 능력과 변화 수용 능력 안에서 수용하는 것도 현실적으로 심각하게 고려해볼 옵션이다.
어제 오랜만에 연락한 어느 분이 대형 SI 업체의 프로젝트에서 겪은 안타까움에 대해 하소연했다. 그 중 하나는 설계가 끝나고 참여했을 때, 설계 문서만으로는 개발할 수 없어 발생한 문제의 책임을 고스란히 개발자가 물었다는 내용이다. 예전에 일을 여러 차례 경험한 바 있었기에 남의 일인데 너무 쉽게 공감할 수 있다는 사실이 씁쓸했다.
설계가 완벽하지 않아야 하는 이유에서 도표를 보면 애자일은 조기에 이익이 드러난다. 불공평한 그림이라 주장할 수도 있다. 왜냐하면, 분석, 설계는 이익 실현이 아니냐고 주장할 수도 있기 때문이다. 하지만, 실제 현장에서 고객이 그렇게 생각할까?
최근 프로젝트에서 애자일 적용을 하고 있다. 초기에는 고객이 거부감을 나타냈다. 미래의 일에 대해 구체적인 작업까지 나누지 않았기 때문이다. 하지만, 조기 릴리즈를 반복하면서 안심하기 시작했고, 공공연히 '애자일로 할 수밖에 없는 프로젝트'라고 하거나 '매주 구체적인 결과를 보지 못하면 답답해' 하기 시작했다. 프로젝트 관리자나 개발자 관점에서는 팀 혹은 자신의 작업이 고객 생각과 다르지 않음을 1~2주 단위로 확인할 수 있다.
분석, 설계를 이익이라고 쳐도 잠재적 이익에 가깝다. 릴리즈 시점에서 고객이 '그게 아니었다.'라고 한다면 부도 수표로 바뀔 위험이 있으니까.
공교롭게 포스팅 후 얼마 지나지 않아, 설계자의 가정에 근거한 선행 개발에 따르는 비용과 위험에 대해 이야기하고, Kent Beck의 점진적인 설계 방식을 소개하는 InfoQ 기사가 올라왔다. 내 글의 제목과 어울리지 않지만, 유사한 내용을 다른 시각으로 다루고 있다.
설계가 완벽하지 않아야 하는 이유는 도표와 함께 self-funding point라는 다소 어려운 용어로 읽는데 다소 장벽이 있었지만, 자세히 살펴볼수록 공감하고 동의했다. 두 가지 사항을 이야기하고 싶다. 하나는, 프로젝트 시작부터 개발자가 바글바글에 대해 동의하지 않았던 부분이고, 다른 하나는 강규영님이 그래프를 이용해 과학적으로 표현한 내용을 더 많은 사람이 공유하려고 현실에서 드러나는 사례를 하나 말하고 싶다.
프로젝트 시작부터 개발자가 바글바글에 대해 반은 동의하고, 반은 반대한다. 여러 사업 수행조직과 일하다 보면 인력 투입의 효용성은 분명히 사업 수행 역량의 중요한 지표이다. 대형 프로젝트의는 가변성이 높지만, 계약은 프로젝트 착수에 선행한다. 그래서, 인력 투입 문제도 사업 수행 관점에서는 예산 범위에서 돈을 쓰는 문제이다. 사업 수행 측면에서 프로젝트 시작부터 개발자가 바글바글에서 지적한 내용은 아주 기본적인 상식이다. 동감하는 바지만, 강규영님이 제시한 것처럼 인력 교체를 효율적으로 하는 방법 외에 다른 해결책이 있고, 더욱 효과적이란 점에 절대적으로 동의한다.
공정 분리와 분업은 먼저 명확한 역할 분리와 역할 사이의 계약에 기초하고 있다. 계약이란 말은 적절한 단어가 없어서 어렵게 썼는데, 선행 작업자의 산출물을 다음 사람이 받아서 과업을 진행하는데 무리가 없어야 한다. 그런데 대부분은 설계자 철수 후 개발자를 투입하는 경우 소프트웨어 설계 산출물이 구현으로 이어지는 데는 병목을 관찰할 수 있다. 설계 산출물을 통해 개발자가 분석, 설계 사항을 그대로 전수받는 일은 아직 어렵다. 화면 설계와 ERD만으로 시스템 개발이 가능한가? UML 다이어그램? UML은 중요한 업무 규칙을 표현하기엔 여전히 범용성이 떨어진다.1 얼마 전 언급한 칼럼의 주장처럼 조기 인스펙션 강조 역시 같은 맥락이라고 본다.
언젠가는 우리 업종에서도 완벽한 설계서가 구현으로 이루어져 명확한 분업이 가능한 날이 올 수도 있겠지만, 아직은 그러한 분업을 효과적으로 실행하기에 성숙도가 낮다고 생각한다. 전통적인 방식 안에서 문제 해결을 꾀하는 것이 현실적이라 할 수 있다. 그러나 반복해서 실패(?)한 경험2이 있다면 분업을 위해서는 산업 성숙도가 낮음을 인정(혹은 SW 업종의 특성 탓이라고 하던)하고, 애자일 도입을 조직차원의 학습 능력과 변화 수용 능력 안에서 수용하는 것도 현실적으로 심각하게 고려해볼 옵션이다.
어제 오랜만에 연락한 어느 분이 대형 SI 업체의 프로젝트에서 겪은 안타까움에 대해 하소연했다. 그 중 하나는 설계가 끝나고 참여했을 때, 설계 문서만으로는 개발할 수 없어 발생한 문제의 책임을 고스란히 개발자가 물었다는 내용이다. 예전에 일을 여러 차례 경험한 바 있었기에 남의 일인데 너무 쉽게 공감할 수 있다는 사실이 씁쓸했다.
설계가 완벽하지 않아야 하는 이유에서 도표를 보면 애자일은 조기에 이익이 드러난다. 불공평한 그림이라 주장할 수도 있다. 왜냐하면, 분석, 설계는 이익 실현이 아니냐고 주장할 수도 있기 때문이다. 하지만, 실제 현장에서 고객이 그렇게 생각할까?
최근 프로젝트에서 애자일 적용을 하고 있다. 초기에는 고객이 거부감을 나타냈다. 미래의 일에 대해 구체적인 작업까지 나누지 않았기 때문이다. 하지만, 조기 릴리즈를 반복하면서 안심하기 시작했고, 공공연히 '애자일로 할 수밖에 없는 프로젝트'라고 하거나 '매주 구체적인 결과를 보지 못하면 답답해' 하기 시작했다. 프로젝트 관리자나 개발자 관점에서는 팀 혹은 자신의 작업이 고객 생각과 다르지 않음을 1~2주 단위로 확인할 수 있다.
분석, 설계를 이익이라고 쳐도 잠재적 이익에 가깝다. 릴리즈 시점에서 고객이 '그게 아니었다.'라고 한다면 부도 수표로 바뀔 위험이 있으니까.
공교롭게 포스팅 후 얼마 지나지 않아, 설계자의 가정에 근거한 선행 개발에 따르는 비용과 위험에 대해 이야기하고, Kent Beck의 점진적인 설계 방식을 소개하는 InfoQ 기사가 올라왔다. 내 글의 제목과 어울리지 않지만, 유사한 내용을 다른 시각으로 다루고 있다.
글
Java EE6에서 등장하는 Web Profiles
2009 이야기
2009/02/02 08:30
Rod Johnson의 글을 통해 Interface21의 Java EE 6 JSR 참여와 Profiles의 등장을 알게 된 지 1년 8개월 지났다. JSR 번호로는 JSR 316인데, 2월 23일 명세서 재정(Specification)을 위한 최종 표결을 마쳤다. 이해관계자가 워낙 많은 표준인지라 긴 시간을 요하겠지만, 20개월이란 시간은 명세서 제정 과정을 느리게 느끼게 한다.1
Specification Lead인 Roberto Chinnici 블로그에서 Java EE에 대한 최근 상황을 설명하고 있다. JSR 316은 두 개의 명세서를 제정한다. 하나는 Java EE 6 자체 명세서이고, 다른 하나는 Web Profile 명세서이다. Web Profile 명세서를 이해하려면 Profiles 개념을 알아야 한다. Java EE 6 명세서 9장에서 Profiles를 다루고 있다. 5쪽 분량으로 정의와 규칙을 설명하고 있는데, 소개 부분만 발췌해본다.
간단히 정리하면 특정 애플리케이션 유형 혹은 영역에 맞춰 Java EE 플랫폼 일부 기술을 조합한 것이라 할 수 있다. 명세서에서 가상의 Java EE Portal Profile을 예로 들고 있긴 하지만, 현재는 Web Profile만이 유일한 프로파일로 존재한다.
그래서 Web Profile의 핵심은 플랫폼에서 어떤 기술을 선정했는가? 이다. 현재 최종 후보(Final Draft)에서 필수 요소(required components)는 다음과 같다:
•Servlet 3.0
•JavaServer Pages (JSP) 2.2
•Expression Language (EL) 2.2
•Debugging Support for Other Languages (JSR-45) 1.0
•Standard Tag Library for JavaServer Pages (JSTL) 1.2
•JavaServer Faces (JSF) 2.0
•Common Annotations for Java Platform (JSR-250) 1.1
•Enterprise JavaBeans (EJB) 3.1 Lite
•Java Transaction API (JTA) 1.1
•Java Persistence API (JPA) 2.0
가장 눈에 띄는 항목은 Enterprise JavaBeans (EJB) 3.1 Lite이다. 그리고 InfoQ 기사, Roberto 블로그에 달린 댓글을 보면 Web Beans 배제가 이슈이다. 눈에 띄는 부분을 발췌해본다.
참고로 Web Beans는 Spring이 채용하는 stateless 기반의 프로그래밍 모델을 비판하며 소개했던 Seam의 개발자인 Gavin King(Red Hat 소속)이 Specification Lead를 맡고 있다. Web Beans 명세서를 제정하는 JSR299에는 SpringSource가 참여하고 있지 않으며, JEE 6 제정에 Red Hat은 참여하고 있다.
한편, Web Profile 명세에도 다음과 같은 노트가 있다.
또 한 가지 흥미로운 사실은 리뷰 과정을 통해 JSR299를 Web Beans라는 새로운 이름 대신에 Contexts and Dependency Injection for Java로 바꾸고, 새로운 프로그래밍 모델로서가 아니라 JEE/EJB Lite container에 흡수시키기로 했다는 점이다.
JEE6와 Web Profile 그리고 JSR299의 변화 등을 살펴보면서 의문사항이 생겼다. Web Profile에 EJB Lite를 포함하는 이유는 J2EE without EJB 실현을 주도하던 Spring의 역할과 크게 다르지 않다. 게다가 Rod Johnson은 JEE6 제정에 직접 참여했다. 그렇다면, Spring은 Web Profile과 EJB 3.1 Lite를 지원할까? 그리고 JSR299와 Spring의 관계는 어떤 양상으로 발전할까?
답은 알 수 없지만, EJB 3.1 Lite를 살펴보면 앞으로 전개할 양상에 대해 어느 정도 짐작은 가능하다. JSR318 EJB 3.1 명세서에서 EJB Lite를 정의한 부분을 찾을 수 있었다.
EJB Lite는 Web Profile을 위한 EJB 실행 환경이다. EJB 3.1 Lite는 JSR318 페이지에서 공개한 다음 쟁점에 대한 산출물로 보인다.
정리를 해야겠다. Rod Johnson 말처럼 Java EE의 Profiles 개념은 혁신적이다. 하지만, 개념의 혁신이 개발자에게 즉각적으로 눈에 띄는 이익을 보장하지는 않는다. 20개월 걸려서 구워낸 결과물에서 호들갑을 떨만한 요소는 보이지 않았다. 마치 JPA가 CMP를 버리고, Hibernate가 입증한 방식을 수용했듯 Spring이 입증한 사실을 JEE에 반영하여 de facto 표준이 아닌 JEE 명세서로 만들려는 시도 정도로 보인다면 지나친 폄하일까?
EJB Lite는 Spring 사용자라면 굳이 필요할까 싶은 내용이다. 만일 JSF를 사용한다면, JSR299 + EJB Lite는 Spring 기반의 웹 프로그래밍 모델에 대안일 수는 있을 법하다. 아직 JSR29에 대해서는 잘 모른다. 오는 2월 28일 JCO 콘퍼런스에서 김태완님이 'Using Web Beans for Standard DI and Context management'라는 제목으로 실습(Hands-on-Lab) 강의를 2시간 동안 진행할 예정이다. 이번 JCO 콘퍼런스 TFT로 일하면서 Hands-on-Lab 강의 기획과 강사 섭외를 맡아서 편성한 네 개 강의 중 하나다. 가능하면 나도 실습에 참석해서 배워보고 싶다.
Specification Lead인 Roberto Chinnici 블로그에서 Java EE에 대한 최근 상황을 설명하고 있다. JSR 316은 두 개의 명세서를 제정한다. 하나는 Java EE 6 자체 명세서이고, 다른 하나는 Web Profile 명세서이다. Web Profile 명세서를 이해하려면 Profiles 개념을 알아야 한다. Java EE 6 명세서 9장에서 Profiles를 다루고 있다. 5쪽 분량으로 정의와 규칙을 설명하고 있는데, 소개 부분만 발췌해본다.
A Java EE profile (from now on, simply “a profile”) represents a configuration of the platform suited to a particular class of applications. A profile may contain a proper subset of the technologies contained in the platform. By doing so, a profile can effectively drop technologies which the platform supports but which are not generally useful in a particular domain. A profile may also add one or more technologies which are not present in the platform itself. For example, a hypothetical Java EE Portal Profile would likely include the Portlet API (JSR-286).
Additionally, a profile may tag certain technologies as optional. In this case, products implementing the profile may or may not include the technology in question. Naturally, if they do, they need to obey all the relevant requirements mandated by the profile specification. A product may implement two or more Java EE profiles, or the full platform and one or more Java EE profiles, as long as their combined requirements do not give rise to conflicts.
Additionally, a profile may tag certain technologies as optional. In this case, products implementing the profile may or may not include the technology in question. Naturally, if they do, they need to obey all the relevant requirements mandated by the profile specification. A product may implement two or more Java EE profiles, or the full platform and one or more Java EE profiles, as long as their combined requirements do not give rise to conflicts.
간단히 정리하면 특정 애플리케이션 유형 혹은 영역에 맞춰 Java EE 플랫폼 일부 기술을 조합한 것이라 할 수 있다. 명세서에서 가상의 Java EE Portal Profile을 예로 들고 있긴 하지만, 현재는 Web Profile만이 유일한 프로파일로 존재한다.
그래서 Web Profile의 핵심은 플랫폼에서 어떤 기술을 선정했는가? 이다. 현재 최종 후보(Final Draft)에서 필수 요소(required components)는 다음과 같다:
•Servlet 3.0
•JavaServer Pages (JSP) 2.2
•Expression Language (EL) 2.2
•Debugging Support for Other Languages (JSR-45) 1.0
•Standard Tag Library for JavaServer Pages (JSTL) 1.2
•JavaServer Faces (JSF) 2.0
•Common Annotations for Java Platform (JSR-250) 1.1
•Enterprise JavaBeans (EJB) 3.1 Lite
•Java Transaction API (JTA) 1.1
•Java Persistence API (JPA) 2.0
가장 눈에 띄는 항목은 Enterprise JavaBeans (EJB) 3.1 Lite이다. 그리고 InfoQ 기사, Roberto 블로그에 달린 댓글을 보면 Web Beans 배제가 이슈이다. 눈에 띄는 부분을 발췌해본다.
I also realize that WebBeans is controversial with the Spring folks,
but this adds fundamental things to web programming (not just JSF) such
as "conversation scope". I want to see this required as well.
Regarding EJB light, what benefit are we going to get from only stateless session beans that WebBeans doesn't already provide? If you do include it, I would expect EJB 3.1 Lite, not EJB 3.0 Lite (no local business interface required). The biggest thing from EJB that I would want to see in WebProfile is the EJB 3.1 Timer.
참고로 Web Beans는 Spring이 채용하는 stateless 기반의 프로그래밍 모델을 비판하며 소개했던 Seam의 개발자인 Gavin King(Red Hat 소속)이 Specification Lead를 맡고 있다. Web Beans 명세서를 제정하는 JSR299에는 SpringSource가 참여하고 있지 않으며, JEE 6 제정에 Red Hat은 참여하고 있다.
한편, Web Profile 명세에도 다음과 같은 노트가 있다.
The expert group would like to solicit feedback from the community on whether to include Web Beans (JSR-299) 1.0 in the full Java EE Platform (see Section 6.30 of the Platform specification) and/or in the Web Profile.
또 한 가지 흥미로운 사실은 리뷰 과정을 통해 JSR299를 Web Beans라는 새로운 이름 대신에 Contexts and Dependency Injection for Java로 바꾸고, 새로운 프로그래밍 모델로서가 아니라 JEE/EJB Lite container에 흡수시키기로 했다는 점이다.
JEE6와 Web Profile 그리고 JSR299의 변화 등을 살펴보면서 의문사항이 생겼다. Web Profile에 EJB Lite를 포함하는 이유는 J2EE without EJB 실현을 주도하던 Spring의 역할과 크게 다르지 않다. 게다가 Rod Johnson은 JEE6 제정에 직접 참여했다. 그렇다면, Spring은 Web Profile과 EJB 3.1 Lite를 지원할까? 그리고 JSR299와 Spring의 관계는 어떤 양상으로 발전할까?
답은 알 수 없지만, EJB 3.1 Lite를 살펴보면 앞으로 전개할 양상에 대해 어느 정도 짐작은 가능하다. JSR318 EJB 3.1 명세서에서 EJB Lite를 정의한 부분을 찾을 수 있었다.
The set of required APIs is divided into two categories : a complete set and a minimum set.The minimum set is also referred to as “EJB Lite.” This reflects the ability of Server Providers to provide an EJB 3.1 container within a product that implements the Java EE Full Profile or within a subset profile such as the Java EE Web Profile.
EJB Lite는 Web Profile을 위한 EJB 실행 환경이다. EJB 3.1 Lite는 JSR318 페이지에서 공개한 다음 쟁점에 대한 산출물로 보인다.
Support for direct use of EJBs in the servlet container,
including simplified packaging options.
정리를 해야겠다. Rod Johnson 말처럼 Java EE의 Profiles 개념은 혁신적이다. 하지만, 개념의 혁신이 개발자에게 즉각적으로 눈에 띄는 이익을 보장하지는 않는다. 20개월 걸려서 구워낸 결과물에서 호들갑을 떨만한 요소는 보이지 않았다. 마치 JPA가 CMP를 버리고, Hibernate가 입증한 방식을 수용했듯 Spring이 입증한 사실을 JEE에 반영하여 de facto 표준이 아닌 JEE 명세서로 만들려는 시도 정도로 보인다면 지나친 폄하일까?
EJB Lite는 Spring 사용자라면 굳이 필요할까 싶은 내용이다. 만일 JSF를 사용한다면, JSR299 + EJB Lite는 Spring 기반의 웹 프로그래밍 모델에 대안일 수는 있을 법하다. 아직 JSR29에 대해서는 잘 모른다. 오는 2월 28일 JCO 콘퍼런스에서 김태완님이 'Using Web Beans for Standard DI and Context management'라는 제목으로 실습(Hands-on-Lab) 강의를 2시간 동안 진행할 예정이다. 이번 JCO 콘퍼런스 TFT로 일하면서 Hands-on-Lab 강의 기획과 강사 섭외를 맡아서 편성한 네 개 강의 중 하나다. 가능하면 나도 실습에 참석해서 배워보고 싶다.
- 그 사이에 그 사이에 Interface21은 SpringSource로 회사 이름도 바꾸었다. [본문으로]
글
10번째 JCO 콘퍼런스 준비 상황
2009 이야기
2009/02/02 08:00
2009년 2월 28일, 2월의 마지막 토요일에 JCO 10번째 콘퍼런스가 있다. 2007년 JCO 오픈소스 컨퍼런스에서 발표할 때 당시 최상훈 부회장에게 KSUG의 회원 커뮤니티 참여 의사를 밝히고 최 부회장이 가입 절차를 설명하면서 KSUG는 JCO와 관계를 맺었다. 작년에는 KSUG 운영진이 바라는 바와 콘퍼런스 내용에 큰 차이가 있었다. 이번에는 장외에서 비판하기보단 적극적으로 개입하려고 콘퍼런스 TFT에 참여했다. TFT에서 맡은 역할은 아셈 세션 강연 관리다. 이번에는 특별히 코엑스 그랜드볼룸 5개의 메인 트랙 외에 추가로 아셈 회의실 2개 트랙을 편성해 Hands-on-lab을 하기로 했다.
첫 TFT 모임에서는 Hands-on-lab 진행 가능성에 대해 반신반의하는 분위기였고, 내 생각도 크게 다르지 않았다. 환경 제약이 많고, 참가자가 불특정 다수인 콘퍼런스 성격을 생각하면 Hands-on-lab에 대해 낙관하기는 어렵다. 그래서, 토론 세션이나 데모 위주 세션도 고려했다. 2달여 동안 TFT에서 다양한 논의가 오갔다.
다음 주에는 강의 테이블을 확정할 듯하다. 현재까지 만들어온 아셈 세션 테이블은 만족스럽다. 우선 강의 시간이 그렇다. 최초에는 1시간짜리 4개, 2시간짜리 2개로 설정했다. 최대 130분을 강의할 수 있는 2시간짜리 세션 4개로 변경했다.
가장 중요한 세션 주제는 다양한 변수가 있어 아직 확정하지 못했지만, 윤곽이 거의 드러났다. 콘퍼런스 세션의 품질 개선에 대해서는 현 최상훈 회장과 뜻이 같아 많은 부분 의도대로 진행할 수 있었다. 현재 아셈의 네 개 세션 중에 셋은 확정했다. 확정한 Hands-on-lab의 개략 정보다.
두 번째 주제는 최상훈 회장을 통해 수렴한 TFT 희망주제에서 출발했다. Web Beans 관련 발표 가능자를 섭외하던 중에 JCO 김정태님의 도움을 받아 태완님을 섭외했다. 유사 강의 경력이 있어 능숙한 진행을 기대할 수 있다.
세 번째 주제는 전 JCO 회장이기도 한 양수열님의 넓은 인맥을 활용해 섭외했다. 애초 TFT에서는 다양한 스펙트럼을 위해 Mobile 혹은 게임 프로그래밍 실습을 원했으나, 대중적인 콘퍼런스에서 진행하기에는 역시 무리가 있었다.
아셈 회의실에서 네트워크을 제공하지 않아 사전 준비가 중요하다. 아셈 회의실이 100석 정도가 한계인지라 사전 접수한 사람만 들을 수 있을 예정이다. 노트북 지참은 필수고, 전원 공급을 위해 멀티 탭은 JCO에서 준비할 예정이다. 참가자가 사전에 개발환경을 구축해온다면 좋겠지만, 그렇지 못한 경우를 고려해 CD 제공도 검토해야 할 듯 하다.
아셈 세션 외에 그랜드 볼룸 세션 3~4개 섭외에 참여했다. 가장 눈에 띄는 점은 SpringSource 인사 초빙이다. 3월 초 SpringSource가 서울 교육 이전에 KSUG 발표를 원했다. 1, 2월경 Dr Paul Chapman이라는 SpringSource 컨설턴트가 What's New and Cool in Spring's Web Stack?이라는 제목으로 KSUG 발표를 원했다. JCO 콘퍼런스를 앞둔 시점인지라 KSUG 세미나 대신 JCO 콘퍼런스 참여 여부를 타진했더니, JCO 콘퍼런스 규모를 고려해 Dr. Ben Alex가 직접 발표하겠다고 했다. 그런데 SpringSource 인사 이동과 일본 쪽 계획 등 때문에 아직 참석자와 주제를 확정하지 못하고 있다.
두 번째로 섭외한 세션은 물개 형의 세션이다. 지금의 회사 동료이기도 하지만, 살살 녹는 "나긋나긋한" 목소리로 유명한 스타 강사이면서, 오픈 시드 시절에 JCO 대위원이기도 하다. 대형 보험사에서 Spring Batch 기반으로 배치 프레임워크를 구축한 사례를 발표할 예정이다. 제목은 Spring Batch 중심의 차세대 배치 시스템 구축 성공 전략이다.
세 번째로 섭외한 세션은 인터뷰를 통해 소개했던 Method Chain의 김영보님이다. TFT 내에서 자바 관련 Ajax 라이브러리로 DWR이 후보에 떠오르던 시점 인터뷰를 했던 계기로 과감히 TFT에 MethodChain 발표를 제안했다. 제목은 MethodChain과 Ajax 애플리케이션 아키텍처 구축 방안이다. 주로 다룰 내용은 jQuery, prototype.js, ExtJS, MethodChain의 아키텍처 설명과 차이점을 제시하며, Ajax 애플리케이션의 Framework 범위와 메커니즘을 다룬다고 한다.
나머지 하나는 아직 확정하지 못한 내 발표다. 블로그를 통해 틈틈이 조각조각 공개했던 프로젝트를 통해 배운 바를 종합해서 공유하고 싶은 마음에 기획했다. 제목은 애자일 프랙티스와 실용주의 소프트웨어 개발 팁의 프로젝트 적용 사례로 정했다. 기본적으로는 CI(Continuous Integration) 적용과정에서 겪은 교훈과 기법, 프로젝트 관리와 팀 작업 관리의 유기적인 연결에 대한 이야기, 프로젝트 이해관계자 관점 차이를 풀어가는 이야기, 테스트나 라이브러리 관리에 대한 팁 등을 나눌 생각이다. 처음에는 고려치 않은 세션인지라 다른 세션 배정 상황에 따라 가능 여부를 알 수 있다. SpringOne 2008에서 Grails 발표가 워낙 인상적이라 해당 세션을 진행하려 했으나, KSUG 세미나가 아니라 JCO 콘퍼런스라 참석자의 Spring 관련 사전 지식을 강제할 수 없고, Hands-on-lab으로 진행하기엔 네트웍 사용이 어려운 환경에서 플러그인 설치 문제, 국내 Grails 시장성에 대한 의문 등 때문에 포기했다.
이번 주 초에 SpringSource에서도 참가자를 확정해주기로 했고, 볼룸 강의도 확정할 것이다. 그리고 나면, 아직 물음표로 남아 있는 두 개 세션도 확정할 수 있다. 테이블 확정 즉시 블로그를 통해 알려 드릴 예정이다.
첫 TFT 모임에서는 Hands-on-lab 진행 가능성에 대해 반신반의하는 분위기였고, 내 생각도 크게 다르지 않았다. 환경 제약이 많고, 참가자가 불특정 다수인 콘퍼런스 성격을 생각하면 Hands-on-lab에 대해 낙관하기는 어렵다. 그래서, 토론 세션이나 데모 위주 세션도 고려했다. 2달여 동안 TFT에서 다양한 논의가 오갔다.
다음 주에는 강의 테이블을 확정할 듯하다. 현재까지 만들어온 아셈 세션 테이블은 만족스럽다. 우선 강의 시간이 그렇다. 최초에는 1시간짜리 4개, 2시간짜리 2개로 설정했다. 최대 130분을 강의할 수 있는 2시간짜리 세션 4개로 변경했다.
가장 중요한 세션 주제는 다양한 변수가 있어 아직 확정하지 못했지만, 윤곽이 거의 드러났다. 콘퍼런스 세션의 품질 개선에 대해서는 현 최상훈 회장과 뜻이 같아 많은 부분 의도대로 진행할 수 있었다. 현재 아셈의 네 개 세션 중에 셋은 확정했다. 확정한 Hands-on-lab의 개략 정보다.
- (가제) From JDBC to iBatis, to Hibernate, 박찬욱
- Using Web Beans for Standard DI and Context management, 김태완
- JRuby on Rails, 정지웅
두 번째 주제는 최상훈 회장을 통해 수렴한 TFT 희망주제에서 출발했다. Web Beans 관련 발표 가능자를 섭외하던 중에 JCO 김정태님의 도움을 받아 태완님을 섭외했다. 유사 강의 경력이 있어 능숙한 진행을 기대할 수 있다.
세 번째 주제는 전 JCO 회장이기도 한 양수열님의 넓은 인맥을 활용해 섭외했다. 애초 TFT에서는 다양한 스펙트럼을 위해 Mobile 혹은 게임 프로그래밍 실습을 원했으나, 대중적인 콘퍼런스에서 진행하기에는 역시 무리가 있었다.
아셈 회의실에서 네트워크을 제공하지 않아 사전 준비가 중요하다. 아셈 회의실이 100석 정도가 한계인지라 사전 접수한 사람만 들을 수 있을 예정이다. 노트북 지참은 필수고, 전원 공급을 위해 멀티 탭은 JCO에서 준비할 예정이다. 참가자가 사전에 개발환경을 구축해온다면 좋겠지만, 그렇지 못한 경우를 고려해 CD 제공도 검토해야 할 듯 하다.
아셈 세션 외에 그랜드 볼룸 세션 3~4개 섭외에 참여했다. 가장 눈에 띄는 점은 SpringSource 인사 초빙이다. 3월 초 SpringSource가 서울 교육 이전에 KSUG 발표를 원했다. 1, 2월경 Dr Paul Chapman이라는 SpringSource 컨설턴트가 What's New and Cool in Spring's Web Stack?이라는 제목으로 KSUG 발표를 원했다. JCO 콘퍼런스를 앞둔 시점인지라 KSUG 세미나 대신 JCO 콘퍼런스 참여 여부를 타진했더니, JCO 콘퍼런스 규모를 고려해 Dr. Ben Alex가 직접 발표하겠다고 했다. 그런데 SpringSource 인사 이동과 일본 쪽 계획 등 때문에 아직 참석자와 주제를 확정하지 못하고 있다.
두 번째로 섭외한 세션은 물개 형의 세션이다. 지금의 회사 동료이기도 하지만, 살살 녹는 "나긋나긋한" 목소리로 유명한 스타 강사이면서, 오픈 시드 시절에 JCO 대위원이기도 하다. 대형 보험사에서 Spring Batch 기반으로 배치 프레임워크를 구축한 사례를 발표할 예정이다. 제목은 Spring Batch 중심의 차세대 배치 시스템 구축 성공 전략이다.
세 번째로 섭외한 세션은 인터뷰를 통해 소개했던 Method Chain의 김영보님이다. TFT 내에서 자바 관련 Ajax 라이브러리로 DWR이 후보에 떠오르던 시점 인터뷰를 했던 계기로 과감히 TFT에 MethodChain 발표를 제안했다. 제목은 MethodChain과 Ajax 애플리케이션 아키텍처 구축 방안이다. 주로 다룰 내용은 jQuery, prototype.js, ExtJS, MethodChain의 아키텍처 설명과 차이점을 제시하며, Ajax 애플리케이션의 Framework 범위와 메커니즘을 다룬다고 한다.
나머지 하나는 아직 확정하지 못한 내 발표다. 블로그를 통해 틈틈이 조각조각 공개했던 프로젝트를 통해 배운 바를 종합해서 공유하고 싶은 마음에 기획했다. 제목은 애자일 프랙티스와 실용주의 소프트웨어 개발 팁의 프로젝트 적용 사례로 정했다. 기본적으로는 CI(Continuous Integration) 적용과정에서 겪은 교훈과 기법, 프로젝트 관리와 팀 작업 관리의 유기적인 연결에 대한 이야기, 프로젝트 이해관계자 관점 차이를 풀어가는 이야기, 테스트나 라이브러리 관리에 대한 팁 등을 나눌 생각이다. 처음에는 고려치 않은 세션인지라 다른 세션 배정 상황에 따라 가능 여부를 알 수 있다. SpringOne 2008에서 Grails 발표가 워낙 인상적이라 해당 세션을 진행하려 했으나, KSUG 세미나가 아니라 JCO 콘퍼런스라 참석자의 Spring 관련 사전 지식을 강제할 수 없고, Hands-on-lab으로 진행하기엔 네트웍 사용이 어려운 환경에서 플러그인 설치 문제, 국내 Grails 시장성에 대한 의문 등 때문에 포기했다.
이번 주 초에 SpringSource에서도 참가자를 확정해주기로 했고, 볼룸 강의도 확정할 것이다. 그리고 나면, 아직 물음표로 남아 있는 두 개 세션도 확정할 수 있다. 테이블 확정 즉시 블로그를 통해 알려 드릴 예정이다.
글
워렌 버핏의 기업 인수 조건
2009 이야기
2009/02/02 00:15
제가 인수하고 싶은 기업의 조건은 네 가지입니다. 첫째, 우리가 이해할 수 있는 사업을 하는 기업입니다. 둘째, 장기간 우수한 실적을 보여준 기업입니다. 셋째, 능력있고 믿을 만한 경영진이 있는 기업입니다. 넷째, 적당한 가격을 제시하는 기업입니다.
<지식 e - 시즌 3> 102쪽
투자의 최고수가 하는 이야기다. 오랜 세월 그가 정제한 원칙인 이상 다른 곳에도 적용할 수 있을 법하다. 가령, 개인 차원에서 자기 시간 투자에 대해서도 적용할 수 있다. 첫째, 이해할 수 있는 사업을 한다. 즉, 어떤 분야가 뜬다고 기웃거리지 않는다. 둘째, 장기간 우수한 실적을 낸다. 뜻하는 결과가 나오지 않는다고 포기하거나 일시적으로 좋은 효과를 봤다고 경솔하게 행동하지 않는다. 셋째, 믿음직스런 판단을 한다. 넷째, 합리적인 대가를 기대한다.
 | 지식 e - 시즌 3 -  EBS 지식채널ⓔ 지음/북하우스 |
워런 버핏의 바이블이라는 현명한 투자자도 읽어봐야겠다.
 | 현명한 투자자 - 벤저민 그레이엄 지음, 제이슨 츠바이크 논평, 박진곤 옮김/국일증권경제연구소 |
