> 밤바님 후기 잘봤습니다~
> 전 직장 다닐때 밤바님이 좀 무서고 날카로운 이미지로 느껴져서 아주 까칠한 후기를 올리셨을 줄 알았는데, 긍정적으로 봐주셔서
> 감사합니다~ ^^;
> 담기회에 다시 뵙겠습니다~
> 2010년 11월 15일 오후 1:17, 멀더바래 <ddoly7...@gmail.com>님의 말:
> > 후기 천천히 정독 하면서
> > 머리속으로 세미나의 내용들이 다시 정리가 되는 느낌입니다.
> > 잘 읽었습니다.^^*
> > On 11월14일, 오후3시59분, 밤바 <codela...@gmail.com> wrote:
> > > 어제 끝나고 바로 후기 올리려다가
> > > 주말에 세미나 간다고 방치해둔 집사람과 아들놈 달랜다고 오늘에야 들렀습니다.
> > > 사실 프로젝트 오픈이 임박해서 주말에도 상시 대기라 엄두도 못낼 세미나 참관이었지만
> > > 모 출판사 모 기획자님의 소환으로 좋은 자리 함께할 수 있었습니다.
> > > 거두 절미 간략히 소감을 정리할까합니다.
> > > [스프링 트러블슈팅 - 백기선]
> > > 현장에서 Spring을 셋업하고 아키텍처 잡고 트러블슈팅을 하는 저로서도
> > > '이게 어디가 틀렸을까요?' 할 때는 식은 땀이 절로 나더군요. ㅎㅎ
> > > 사실 SI 프로젝트에서 Spring을 활용하는 대부분의 개발자들이
> > > Spring을 사용하는 기법만 익힌 상태가 대부분이기 때문에
> > > 근본적인 동작 원리나 뒷 단의 매커니즘을 이해하고 있지 못한 탓에
> > > 제시된 오류 상황에 대해 적지않게 당황해하는 경우가 적지 않습니다.
> > > (정확히 표현하자면 당황해 하지 않고 Framework 때문이라면서 역정을 냅니다. -ㅁ-)
> > > 프로젝트가 일단 저가 수주를 하는 것과
> > > 현장 개발자들이 자신의 코드에 문제가 없다고 생각되면 직접 오류 원인을 분석하기 보다는
> > > 일단 오류가 나는 즉시 기술 지원 인력 (혹은 선도 개발자)에게 도움을 청하는 것을 감안하면
> > > 당분간은 현장 개발자들의 Spring에 대한 전반적인 이해도가 높아지기까지는
> > > 아직 시간이 더 필요할 것으로 보입니다.
> > > 사실 아직 Java5 annotation도 모르는 개발자가 부지기수라..
> > > 그래서 백기선님이 제시해주신 각종 트러블슈팅 사례는
> > > Framework을 직접 케어하는 기술지원 인력 중심으로 사고사례 전파 형식으로 공유되면
> > > 단기간의 효과를 볼 수 있을 것 같습니다.
> > > 개인적으로는 신규 Framework 인력들을 위한
> > > 퀴즈 시험 문제집으로 축적되면 재미있을 것 같습니다.
> > > (저 역시 상당히 쫄았던지라.. ㅎㅎ)
> > > [Rich Domain Model - 조영호]
> > > CBD를 처음 배웠을 때의 기억이 새록새록 돋아나는 세션이었습니다.
> > > CRC 카드도 오래간만에 봤고 책임 소재를 어디에 두느냐에 대한 고민도 참 어려웠던 기억이 나는군요.
> > > 결국 그 당시에도 OO로 만들어진 모델을 RDB에 구현하기 위한 방법이 이슈였고
> > > WebLogic 5.1의 패키지 깡통에 같이 들어있던 TopLink라는 게 있었던 것도 같습니다.
> > > 의도치 않게 SQL을 중시하는 DBA들과의 아규도 있어서 이건 결국 이론으로 끝나는가 아쉬웠었는데
> > > 말씀대로 Data Mapper류의 Framework들이 어느 정도 절충된 구현 모델을 제시하고 있어 아직은 포기하고 싶지 않다
> > > 는 생각을 하였습니다.
> > > 각 사에서 CBD 방법론이 있음에도 불구하고 여전히 데이터와 화면 기반인 IE 방법론이 적용되는 것을 보면
> > > 설계에서 구현으로 넘어가는데 필요한 Expert judgement가 모든 프로젝트 팀원에게는 기대하기 어렵다는 것을 말해주고 있
> > > 는 것 같습니다.
> > > OO에서 RDB로 넘어가는 기술적인 부분을 논외로 한다면
> > > 프로젝트의 이해 관계자 중 의사결정권이 있는 분들의 배경 지식, 즉
> > > ERD는 볼 줄 알지만 UML은 보지 못하는 고객측 정보기획과 PM, PL들도 한 몫한다고 봅니다.
> > > 의사소통 도구인 UML이 ERD 만큼의 가독성(?)을 발휘하는 것을 보려면
> > > 그들이 UML과 CBD를 배우는 것이 아니라 그것을 익힌 자들이 득세(?)하는 것을 기다리면되지 않을까 싶습니다.
> > > 말씀대로 SI 현장에선 Transactional Pattern이 대부분이고 저 역시 그렇게 아키텍처를 구성하고 있던지라
> > > 오래도록 잊고 있었던 Domain Model에 대한 자극이 되어 좋았던 것 같습니다.
> > > [SpringOne 2010참관기 - 정상혁]
> > > 개인적으로 왜 이 사람을 같은 회사에 있을 때 보지 못했을까라는 아쉬움과
> > > 한편으론 이 사람이 다른 회사에 있는 것이 어쩌면 다행이라는 안도감을 동시에 맞본 세션이었습니다.
> > > 쉬는 시간에 마이크를 잡고 사람들을 기다리는 무서운(?) 표정과 달리
> > > 막상 세션을 시작한 뒤 작렬하는 유머러스한 진행에 조금은 경계하고 있던 방어막이 사라지는 계기가 되었습니다.
> > > 단편적인 Spring에 대한 기능 설명이나 소개하기 보다는
> > > Spring을 둘러싼 전반적인 동향과 공식화되지 않은 가십거리까지
> > > 예리한 통찰력으로 재해석을 해주시는 것이 인상 깊었습니다.
> > > 앞으로의 Spring의 모습, 그리고 우리가 대응해야할 방향을 생각하면
> > > 벌써부터 한숨이 나옵니다만 (2.5에서 3.0으로 넘어갔을 때 Deprecated 된 소스 라인의 충격보다 더 강력하게)
> > > 정상혁님의 흥분에 가까운 열의와 그 열의에서 쏟아져 나오는 기대감이 제게도 전달되어
> > > 일에 찌들어 굳어 있었던 창작 욕구, 삽질 욕구에 단비를 뿌려준 것 같습니다.
> > > [Spring Framework 3.0을 이용한 RESTful 웹 서비스 구현 - 박찬욱]
> > > 그 동안 게을러진 탓인지 관심 분야가 아닌 것에 대해서는 업체에게 맡겨버리는 나쁜 습관이 생겼는데
> > > 그 중 하나가 웹서비스 관련 영역이었습니다.
> > > EAI, MCI, 각종 인테페이스류의 제품들에게 일방적으로 맡겨둔 탓에
> > > 불가피하게 꼭 필요하다면 ViewClass를 확장해서 JSON이든 XML이든 변환해서 보내곤 했었습니다.
> > > 하지만 박찬욱님의 프로토타이핑 사례를 보면서 다시금 살펴봐야겠구나라는 경각심을 일깨울 수 있었습니다.
> > > REST와 직접적인 관계는 없지만 http 스펙 본연의 내용에 충실하려하는 내용,
> > > 즉, get은 데이터 요청, post 데이터 변경이라는 아주 당연한 논리를 다시금 깨우쳐 주었는데
> > > 이는 처음 SimpleFormController를 분석하면서 무릎을 쳤을 때의 감동과 비슷했습니다.
> > > 게다가 죽어있던 다른 두 가지 method 까지 활용하고 있다고 하니
> > > 문제가 생겼을 때 스펙을 살펴보지 않고 꼼수로 해결하고 있는 스스로를 반성하게 하더군요.
> > > 게다가 request header의 정보를 보고 response을 json으로 할지 xml을 할지
> > > 능동적으로 대응하는 방식은 현장에서 사용되는 channel 계열의 솔루션들이
> > > 얼마나 불필요한 오버헤드를 하고 있는지 깨닫게 해주었습니다.
> > > REST를 적용하면서 경험한 솔직한 사례는 더욱 제게 큰 의미가 있었는데
> > > 특히나 URL을 Naming하는데 큰 고민을 하셨다는 대목에서 공감 백배였습니다.
> > > 개발 일정이 지연되면 표준이 잘못나가서 그렇다고 개발자들이 드러눕는 사례가 많다보니
> > > 표준화 과정은 한 두번의 경험에서 완성되는 것이 아니고, 또 완벽하지도 않기 때문에
> > > 변경 시 기존 적용 내용에 대한 replace 방안에 대해서도 명확한 방법을 제시해야겠다는 생각을 굳힐 수 있었습니다.
> > > [그 외]
> > > 회장님이 전날 만나셨다는 기술사 분 (저도 아는 분일 것 같습니다)과의 말처럼
> > > 경험있는 SA는 현장에 턱없이 부족하고 점점 확장되는 영역을 따라가긴 어려운 상황이라
> > > 이번 세미나처럼
> > > Framework에 대한 전반적인 이해가 개발자들 모두에게 저변 확대될 수 있는 기회가 더 많아지길 기대해 봅니다.
> > > 그리고 회장님이 중간에 가벼운 듯 진지하게 흘린 말 중
> > > 개발자는 해법을 내놓고 아키텍트는 해법과 비용을 내놓는다는 말에 고개를 절로 끄덕였는데
> > > 결국 Spring이 가진 수 많은 기법과 해법 중에 무엇을 선택할 것인가는 결국
> > > 그 해당 문제 영역에 얼마나 더 잘 부합하는지 판단하는 아키텍트의 막중한 책임을 상기시켜 주었습니다.
> > > 혹자는 개발자와 아키텍트를 굳이 구분할 필요가 있느냐고 말했지만
> > > 개발자는 주어진 기법을 오류없이 잘 활용할 수 있도록 정확한 표현법과 사용법을 익히고
> > > 아키텍트는 그들의 구현 기술과 노력이 물거품이 되지 않도록 정확한 상황 판단을 하는데 주력한다면
> > > Spring이라는 좋은 재료를 가지고 원하는 시스템을 구축하는데 시행착오를 덜 할 것이라고 정리하였습니다.
> > > 오랜만에 참관한 세미나라 생각도 많아지고 자극도 많이 되었습니다.
> > > 비록 오늘도 프로젝트 때문에 출근하여 찌들어 있습니다만
> > > 이 자극
...
