[상관관계] TDD, 리팩터링, 프레임웍, 솔루션

Posted at 2010.09.07 17:19 // in Architecture // by MOOVA 무바㏇


위의 그림은 테스트 주도개발에서부터 MDA & Desinger에 이르기까지 발전되는 상관관계를 가시적으로 표현한 그림이다.

TDD를 통해 제대로 동작하는 주요 기능을 몇 초 또는 몇 분 만에 만들어 낸다.  그 다음, 리팩터링을 통해 필요한 수준의 정교함을 갖출 때까지 발전시킨다. 저수준 리팩토링과 복잡한 리팩토링을 통해 패턴을 만들어 낸다. 패턴을 사용함에 있어 패턴중독이 될 수 있는 부분까지 분류하여 안티 패턴을 도출해 낸다. 적당한 패턴이란 반복적으로 발생하는 문제들을 설명하고, 이 문제들에 대한 해결 방안의 핵심을 설명한 것이다.

그리고 우리는 템플릿을 작성하여 패턴 적용을 자동화하고, 이것을 다시 컴파일된 형식으로 발전시켜 프레임웍을 만든다. 프레임워크의 사용이 애플리케이션의 개발 생산성에 많은 도움을 주지만 컴파일된 코드의 형식으로 제공되기 때문에 사용자들에게 시각적인 효과를 제공하지 못한다.이러한 것을 개선한 것이 결국 디자이너이다. 이것은 시각적으로 설계할 수 있는 수준을 제공해주며 모델과 모형을 생성하고 모델을 변환하여 최종의 결과를 도출해 낸다.(MDA[각주:1])


이 모든 과정이 상황에서 비롯된 문제점들을 보완하고자 나온 형태것이며, 궁극적으로 해결책을 만드는 과정에 포함된다. 간혹 오해할 수 있는 부분이 솔루션과 프레임워크의 상관관계에 대해서 자로 재듯이 비교를 하는 실수를 할 때가 있다. 프레임웍과 솔루션의 상관관계는 상황에 따라

프레임웍 = 솔루션, 프레임웍 < 솔루션 , 프레임웍 > 솔루션

의 관계가 될 수 있다는 것에 주목하자.
  1. Model Driven Architecture [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

[회고] SI에서 TDD를? (2)

Posted at 2010.09.01 09:19 // in Project Life // by MOOVA 무바㏇
그동안 SI 프로젝트에서 웹애플리케이션에 관련된 일을 할 때, 그들과 같이 비공식적으로 TDD나 짝프로그래밍을 시도했던 적이 있다. 그리고 그것과 관련되서 구축해 줬던 라이브러리도 좀 된다. 그 중 몇가지 추려서 설명하고자 한다.

2010:08:31 20:53:04
그림1. 웹 MVC영역의 TDD작성 포인트

그림1은 일반적인 웹MVC의 아키텍쳐중 일부이다. 위에서 빨간색 점으로 표현한 지점이 TDD작성 포인트이다. 사실 위의 TDD작성 포인트가 MVC 웹-영역에서 사용할 수 있는 TDD의 전부라고 해도 과언이 아니다. 그에 맞는 라이브러리는 알려진게 워낙 많아서 번외로 하고 실제 프로젝트에서 직접 구성했었던 TDD작성 사례를 설명할까 한다.

"테스트데이터셋, Mock 객체, 테스트 Dao..테스트 서블릿등등등"

LG에서 시도했던 TDD의 실제 사례이다.
데이터베이스 테이블의 설계가 충분히 고려되지 못한 채 수시로 변경이 되었고 며칠 뒤로 고객에게 시연을 해야만 했다.( 또 어디서 나타났는지 우리의 관리자는 자신의 직원들은 안 쪼고 프리랜서만 닦달하고 있었다.) 고객이 원하는 UI(유저인터페이스)는 fix가 되어 있었다는 게 다행이었다. 뒷단은 수시로 변경되고 있었던 반면, 앞단은 고정되어 있었던 것이다. 여기서 선택할 수 있는 것이 가상의 Dao를 작성해서 가상의 데이터를 원하는 UI에 뿌려주는 것이다. 설계가 미진한 불안정한 데이터셋도 가상의 데이터셋을 만들어서 축출하면 그만이었다.


2010:08:31 21:04:58
이때 사용했던 가상의 데이터셋은 DBUnit에서 쓰는 기본포멧이 아닌 엑셀파일이다. 굳이 엑셀파일을 선택한 이유는, DBMS가 오라클이었고 오라클에서 제공하는 엑셀 익스포터를 사용하면 빠르게 해당 포멧으로 엑셀을 생성할 수 있었기 때문이다. 이렇게 생성한 데이터셋과 가상의 Mock Object를 사용하여 테스트케이스를 완료할 수 있었고, IDao를 구현한 Real Dao를 잠시 뒤로 놓고, 새롭게 작성한 TestDao를 메모리에 올려두었다. 이렇게 해서 고객이 원하는 뷰를 빠르게 작성할 수 있게 되었다. 이 당시는 뒷단의 디비설계가 수시로 변경이 되었었는데 가상의 DataSet을 사용하려 했던 아이디어가 크게 빛을 발휘했던 것이다. 결국, 나중에 디비 설계가 완료되면 그때 TestDao에서 RealDao로 교체만 하면 그만이다.
만약 데이터셋을 갖출 때 아래 그림과 같이 수많은 테이블에서 조인된 결과물이라면 토드와 같은 툴을 사용해서 쿼리를 수행한 뒤 얻은 결과로 엑셀파일을 생성하면 된다.

2010:08:31 21:18:20
그림2, 많은 테이블에서 조인된 결과물을 엑셀로 뽑을 경우 토드와 같은 툴을 사용하면 편리하다.

위와 같은 방법을 사용해야하는 시기와 장점에 대해서 정리해 본다.

1. 앞단의 개발자(UI개발자)와 뒷단의 개발자(서버개발자)가 분리되어 있을 경우, 간섭현상을 줄일 수 있다.
2. 데이터베이스 설계가 미진하지만 UI는 고정된 상태에서 제법 유용한게 쓸 수 있다. (Mock Object)
3. 테스트데이터를 쉽게 구비하지 못할 때 엑셀과 같은 가상의 데이터셋을 사용하면 알맞은 테스트데이터를 마련할 수 있다.
4. 모두 TDD에 용이하다.



2010:08:31 21:19:15
그림3. UI 테스트를 하기위한 컬럼 매핑예제


"직접 고안해낸 UI의 테스트 방법론"


그림3은 직접 삼성에서 프레임웍으로 구축해줬던 실제사례 일부분을 발췌한 것이다. ibatis를 사용하고 있었는데 뷰는 그리드컴퍼넌트를 사용하고 있어서 테스트 하기에 무척이나 까다로웠다. 이때 생각한 것 중에 하나가 UI단의 그리드 컬럼과 쿼리단에 각 컬럼명을 매핑시켜주면 그리드 테스트케이스는 작성할 수 있지 않을까하는 아이디어였다.
기존에는 컬럼 네이밍 규칙도 없었고 개발자들 제각각 컬럼명을 생성했기 때문에 통일성없는 흐름을 관찰했다. 통일성이 없으면 의존성이 증가되어 당연히 테스트도 어렵게 된다.

이렇게 쿼리단의 컬럼명과 그리고 혹은 UI단의 해더부분을 매핑시켜주면 UI의 TDD는 완료할 수 있다.


"분산처리 환경에서의 CRUD TDD"

2010:09:01 09:12:33
그림4. 분산처리 환경에서의 CRUD 테스트

필자는 오픈소스이외에 블랙박스 소프트웨어를 경험했었기 때문에 오픈소스로 알려져 있던, TDD관련 라이브러리들을 블랙박스와 접목해서 사용한적이 많다. 물론 해당 블랙박스 패키지속에 제공해주는 TDD관련 라이브러리들이 많이 있었지만 다루기 까다로울 때는 직접 라이브러리를 등록해서 블랙박스+오픈소스환경을 융화시키야만했다. 보통 데이터베이스를 테스트하는 용도로 CRUD의 반복되는 코드를 테스트하곤 했는데, 이때는 집적 데이터베이스와 붙지 않고 분산환경에서 가상의 프록시를 만들어 테스트를 진행해야했다.
이렇게 분산환경속에서 그것들 모두를 한곳의 테스트로 집중하기엔 의존성이라는 문제가 따라붙었다. 따라서 의존성을 제거하기위해 머신마다 단일책임원칙을 따르는 코드를 작성해야했으며 따라서 개별의 단위테스트를 진행할 수 있었다.

본인은 TDD와 관련된 라이브러리에대해 지식이 없었을 땐, 직접 테스트케이스를 위한 별도의 라이브러리를 구축해서 테스트를 진행하기도 했다. 정 여력이 없을 땐 main 메소드에 테스트를 했다.

얼마전에 나온 "테스트주도개발 TDD실천법과 도구" 를 통해서 본인이 생각하고 구축해 주었던 부분이 상당수 책에 실려었었던 것을 확인했다. 물론 본인도 TDD는 해외사이트나 기사를 통해서 학습을 했었고 unitils와 같은 라이브러리는 그동안 수차례 공부를 해왔던 경험이 있기 때문에 본인이 아는 내용과 책 내용이 상당수 중복되는 부분이 많았다.
그리고 위의 컬럼명 매핑에대한 부분은 순전히 개인적인 생각으로 삼성에 제공한 라이브러리였는데, 그것과 비슷한 방법이 이 책에 실려있어 깜짝 놀랐다.! 세상엔 참으로 비슷한 생각을 하고 실천하는 사람이 많다는 것을 새삼 깨닫게 해주었다. ( 실제 프로젝트에서 만나볼 수 없었던 비슷한 가치를 지닌분들 ).

저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://moonlgt2.tistory.com BlogIcon 소박한 독서가

    2010.09.01 09:49 신고 [수정/삭제] [답글]

    노..전문적인 프로의 포스가 팍팍 느껴지는군요.
    인사만 드리고 갑니다~ㅎ

  2. 2010.09.01 13:55 [수정/삭제] [답글]

    비밀댓글입니다

  3. Favicon of http://blog.doortts.com BlogIcon doortts

    2010.09.03 09:43 신고 [수정/삭제] [답글]

    최근에 저희 회사에서 일하셨었다는걸 알고는 깜짝! 놀랬습니다. 프로젝트룸 근처에 왔다갔다 한 적 많았었거든요. :D 어려가지로 신기한것 같아요.
    UI - SQL 접점에 대한 TDD는 효과는 어느정도 있긴 했었는데요, 아쉬웠던 점은 개발자들이 그다지 '재미'를 느끼지 못했다는 점이었습니다. 과정 자체가 성공의 기쁨을 느낄만큼 도전적이지 않았었던것이 원인이 아니었나 하고 스스로 회고해 봅니다.

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.09.04 17:10 신고 [수정/삭제]

      홋 그랬었군요. 프로젝트 단위로 움직이다 보니..지나치면서 만났을 수도 있었겠군요 :)

      맞습니다. 개발자가 생각할 때 그 일을 어떻게 생각하느냐, 재미있어하느냐 재미없어하느냐가 매우 중요한 것 같습니다. 그전에 그분들에게 동기부여를 해 줘야 하는데 어려운 상황이 많은지라 그러기가 매우 힘이든 것 같습니다. 또한, 저도 그렇구요^^. 취미로 하기엔 재미있는데 실무에서 하기엔 충분한 동기부여가 매번 모자라곤 하더군요.

      그래도 재미를 느끼는 열정 있는 사람들이 꾸준히 노력한다면 그 재미가 전염되지 않을까 합니다. ㅎ

댓글을 남겨주세요.

[회고] SI에서 TDD를 - 번외적인 모습들 (1)

Posted at 2010.09.01 09:00 // in Project Life // by MOOVA 무바㏇
2010:09:01 01:37:27
으핵!! 일단 생각난 김에 뭔가를 끄적이고 싶어서 끄적였는데 글이 길어졌습니다.O.Oㅋ.
회고식으로 작성된 글이라서 수필식의 글이 되어버렸네요. 쿄쿄쿄 ㅎㅎ

기술은 사람의 요구를 충족하기 위해 존재한다.


"TDD를 알게 되고나서.."

웹 스크립트 일을 할 적엔 TDD라는 단어조차 모르고 지냈다.
왜냐하면, 스크립트류의 개발이란, 소스 컴파일을 안 해도 바로바로 결과를 확인할 수 있었고(인터프리터), 디비연동이나 모델적용 조차도 페이지를 분할해서 하는 것이 전부였으니까 말이다. 처음엔 자바쪽의 프레임웍이나 보안 체계를 보고 자바진영은 왜 저렇게 비대한 것에만 관심을 쏟아부을까?라고 혼자서 궁금해 했었고 자바에서 구현한 것들을 다른 스크립트류의 언어로(php,cgi..) 구현하더라도 충분히 똑같이 할 수가 있었기 때문에 자바에 대한 약간의 불신이 없지 않아 있었다. 그 후 실제 자바 프로젝트를 하면서 자바의 구조론을 보았고, 객체설계나 OOAD를 차차 알아가게 되었을 무렵, 여러 오픈소스들을 열어서 소스를 분석하면서 참 놀라운 신세계를 발견하곤, 또 동경의 대상이 되기도 했다. 본격적으로 TDD를 처음 알게 된 것은 해외 오픈소스를 까보기 시작하면서부터이다. 이때는 R&D로 근무했었는데 TDD가 무엇인지 그 본질을 찾기 위해 개인시간을 들여가며 여러 세미나에 참석을 하곤했다. 직장은 연구소였지만 회사경영사정이 매우 어려워 책이나 세미나 활동조차도 여력이 안 되었었던 매우 힘든시기였다. 책도 구입할 돈이 없어 무척 가난했던 시기였다. (지금에와서 그때를 회상하면 참 유익했던 시절이었던 것도 같다.) 이때 같이 근무했던 선배들은 CS프로그램이나 VB와 같은 객체디자인원리나 패턴지향, 아키텍처 지향과는 거리가 먼 사람들이 대다수여서, 디자인 패턴이라든지, 객체지향 기술이라든지, 방법론이라든지 전혀 관심들이 없었다. 아니다 관심조차 두려 하지 않았다는 게 맞는 말일 것이다.

"TDD와 짝프로그래밍을 하기 어려운 SI의 문화와 최초 짝 프로그래밍 시도"

그 후 R&D팀을 나와서 여러 SI 프로젝트를 경험하면서 매우 불합리한 SI현실을 체험하기 시작했다. 그 안에서도 사기꾼 같은 사람, 학자 같은 사람, 이간질을 하는사람, 임기응변에 능한 사람, 매우 소극적인 사람, 매우 호탕한 사람, 매우 유쾌한 사람, 매우 우유부단한 사람, 매우 논리적인 사람, 매우 가난한 사람, 매우 부자인 사람, 묻어가는 사람, 책임감 있는 사람. 등등을 다양하게 겪어 가면서 우리 SI바닥엔 참으로 다양한 인종(?)들이 같은밥을 먹으면서 살고 있구나~하고 매번 놀랄때가 많았다.
그렇게 사람을 겪어 보면서 어떻게 하면 저들이 잘하는 것, 좋아하는 것을 하게 만들어 너도 좋고 나도 좋은(win-win) 그런 팀을 만들지 또는 회사나 프로젝트 환경을 만들지.. 개인적인 목표와 고민이 항상 나를 괴롭혔다. 고작 개발자인 주제에 관리자가 생각하는 그런 생각들을 아주 오래전부터 생각해 왔던 것이다.

내가 겪었던 SI의 70%가 그냥 주먹구구식의 운영과 프로젝트 진행으로 막장의 막장을 달리는 곳이 태반이였고, 체계나 방법론등을 도입할 수도 또는 도입하려 하지도 않았다..(물론 제대로 도입해서 성공한 케이스의 프로젝트들도 있다.)
그냥 고객이 요구하니 넌 맨땅에 해딩해라~ 뭐..이런식이었을까?
그렇게 저렇게 프로젝트를 지내고 다음 프로젝트를 기다리면서 막간의 텀을 이용해서 책과 씨름하며 학습도 하며 여행도 다니며 그런식의 삶을 살고 있었다. 한번은 SS의 프로젝트에서 나와 뜻이 맞았던 어떤 개발자가 TDD와 DDD에 관한 이야기를 했었는데 '어라? 나와 같은 동족이 있네~'하면서 그와 많은 소통을 했다.
이때 처음으로 그와 짝 프로그래밍이란 것을 해봤다. 처음 하는 짝프로그래밍. 처음엔 서로 궁합이 맞아 잘 진행한 듯 보였으나 개인적인 서로의 자존심때문에 묘한 느낌을 서로 받아야 했다. 짝 프로그래밍을 하기 전에 먼저 서로의 마음이 열려있어야 하는데, 인력이동이 잦은 프로젝트에선 실제로 짝프로그래밍을 한다는 게 여간 이상한 것 같았고, 쓸데없이 그런걸 왜 하냐? 라는 주위의 눈총도 받아야 했다. 또 다음에 만날 수도 없는 사람이라는 느낌때문에, 내가 겪었던 최초의 짝프로그래밍은 그렇게 흐지부지하게 지나갔다.
사실 짝 프로그래밍을 제대로 하려면 다음과 같은 적절한 도구와 환경이 받춰줘야 한다.

※ 짝 프로그래밍의 환경

  • 둘이 함께 편안하게 앉을 수 있도록 평평한 책상. 일반적으로 개발자 쪽으로 곡선하는 책상은 쾌적한 작업 조건을 제공하지 못하기 때문에 피해야햔다.
  • 저렴하게 구매할 수있는 가장 빠른 개발을 위한 컴퓨터. 짝 프로그래밍을 위한 컴퓨터
  • 듀얼 DVI 출력 을 갖춘 비디오 카드.
  • 24 인치 또는 30 인치 모니터를 2 개. 2 대의 대형 모니터를 데스크탑 클로닝 (또는 미러링) 이 우수 합니다.
  • 2 개의 키보드와 2 개의 마우스 .

  • "여전히 빨리빨리 SI, 하지만 애자일은 건재했다."

    그 후 여러 프로젝트를 전전긍긍하면서도 RSS 정보와 개인적인 학습, 그리고 별도의 애자일 서적을 통한 지식의 도움을 추가해 TDD와 짝프로그래밍 방법, 그리고 애자일을 익혀가면서 프로젝트에 도입하려고 무척 애를 먹었다.
    하지만, 짧은 일정에 덧붙여 내가 관리자가 아닌 이상 그것들의 장점을 주변사람들에게 쉽게 설득하기가 매우 어려웠다.  항상 일정은 촉박했고 누구하나 그런체계에 관심을 두려하지 않았다.
    출근하면 해외 RSS에서 쏟아지는 애자일 관련 기사들을 보고 "외국엔 저렇게 변화되어 가는데, 왜 한국은 항상 빨리빨리만 외쳐댈까?"라는 자괴감이 들었던 것이 한두번이 아니다. 같이 짝프로그래밍을 하자고 요청했던 지나가는 개발자들은 굳이 그런걸 왜 해야 하느냐며, 일만 많아질 뿐이라는 생각에 회피를 하는 게 대부분이었다. 물론 이런 사람들도 자신이 추구하는 가치가 있기 마련이기 때문에, 나와 다르단것을 인정했고, 이런 류의 개발자들에게도 짝프로그래밍과 TDD의 사상을 알려주면서 많이 전파하려고 애를 썻다. (물론 TDD는 개인적으로 깨작거렸던 것이 전부였지만 말이다.) 우리 SI바닥에도 좋은 것들만 골라서 도입을 한다면 충분히 빨리 퇴근할 수도 있고, 더 나은 소프트웨어를 생산해 낼 수 있다는 헛된 꿈이 있었기 때문일까? 왜 SI엔 민첩한 방법론이나 TDD를 할 수 없는지 항상 안타까워했다. 분명히 도입하면 차 후 성과를 볼텐데..왜 그렇게 관심이 없는지.. 점점 개인적인 지식은 늘어만가는데 이것에 대해 서로 이야기할 수 있는 사람 조차도 없었다. 솔루션 엔지니어로 일할때도 일반 범용적인 지식과함께 도메인 특화된 특수기술을 강조하면서 애자일사상을 도입하려고 많이 애를 써봤다. 하지만 OOTB기반의 프로젝트에선 애자일은 전혀 어울리지 않은 프레임웍이었다.(성격이 다른 탓이다. 좋지 않다는게 아니라.) 그래서 늘 하는일에 만족을 하면서도 애자일과 관련된 일에 대해서는 답답함만 늘어갔다. 그래서 TDD는 스프링이나 오픈소스를 학습하면서 개인적으로 시도한 적이 많이 있었다. 또는, 프로젝트 이외의 별도의 제작의뢰건들의 소프트웨어만 개인적으로 사용하곤 했다.(본인는 프로젝트 이외에 제작의뢰건도 종종 맡아서 진행했었으므로 1년에 5개월정도는 투잡을 한 셈이다. 공식적인 프로젝트 이외에 TDD나 새로운 기술을 그런 소일거리를 통해서 적용해 볼 수 있으니 일석이조가 아닌가?)

    "후배들이 생겼고, 진정한 선배란 무엇인가에 대해 고민을 많이 했다."

    그 후 나도 머리가 굵어졌는지 동료와 후배가 생겼다.
     
    솔루션 엔지니어에서 컨설턴트와 아키텍트에 관심을 두고 학습하기 시작할 때가 바로 이 시점이다.
    이때는 주변 저명하신 블로거분들이나 실무에서 나이가 들었어도 꾸준히 연마하시는 재야의 고수들에게 책 추천을 많이 받아서 상당한 도움을 받았다.
    이 당시도 대부분의 선배들이 관심조차 갖지 않았던 민첩한 그것들을 알리려고 매우 노력했다.
    한번은 짝프로그래밍을 몇 번 같이 했던 어떤 선배의 집에 찾아갔는데 책이 한 30권정도 있어서, 관심을 보여하는 나에게 그는 "내 책에 눈독들이지마라!"라는 소리를 들었던 적이 있다. 나 원참~ 책좀 같이 공유하고 보자는 말도 절색을 하며 싫어했다. 우리주변엔 이렇게 소통을 싫어하는 개발자분들도 꽤 된다. 이때 당시는 프로젝트를 한 뒤 남는 여력으로 책을 하나하나 사놓고 공부하고 있었던 터였고, 출근해서 일하고 퇴근해서 공부하는 그런 반복되는 일상에 쪄들어 살고 있었다.
    그 후 SI를 하면서 나보다 나이많은 선배들은 대부분 책이나 스터디보다는 그냥 현실에 안주하며 살아가는 사람들이 다수였다는 것을 확인했고, 개발자들에겐 책추천이나 기술을 배워본 적도 없고, 들어본 적도 없다. 오히려 내가 그들에게 퍼주거나 알려주는쪽이었으니 말을 해서 뭐 하랴..
    ( 물론 책을 추천해주거나 사줬던 선배들에겐 아직도 감사함을 느낀다. 온라인에서 책을 추천해 주신 몇 분에게도 감사함을 느낀다 하지만 나머지는 글쎄다.... )

    그래서 매번 대체 선배라는 게 무엇인가에 대한..회의감에 휩싸였다.

    한가지 다짐한다. 경력이 더 쌓이면 텅빈 그릇이 아니라 꽉찬 그릇이 되고싶었다. 후배들 보기에 쪽팔리지 않는 그런 선배가 되리라 굳게 마음을 다졌다.  개인적인 세미프로젝트를 세워가며 학습을 했고, 퇴근 후에도 다른 언어를 익히려고 참 노력도 많이 했다. 리펙토링도 수시로 열어서 연습했고, 각종패턴도 열어서 연습했다. 일부러 짝프로그래밍도 해보려고 후배의 TASK를 대신 해 줘가면서, 애자일스러운 경험을 쌓으려고 노력을 했다. 누구 하나 알아주는 사람도 없었고, 왜 그런것을 해야 하는지 의아해하던 사람들도 있었다. 하도 답답해서 이때부터 행동을 달리했다. 이때 선택한 행동이란 후배들에게 내가 아는 지식을 먼저 알려주고, 그들이 발전하면 같은 관심사에대해 터놓고 소통할 수 있는 사람을 찾는 기대감을 현실화 하는 것이었다, 그래서 개인적으로 봐왔던 책들을 후배들에게 주거나 사주었다. 물론 직장이 안정되있고 탄탄한 회사에 다녔던 사람들은 제외다. 그들이 그렇게 지식체계를 쌓으면 나중에 나와 대화를 할 수 있는 포인트에 도달할 것 같아서이다. 하지만, 아직까지 TDD와 애자일에 대해서 누구와 시원하게 탁 터놓고 대화를 할 수 있는 사람은 별로 없었다.

    "TDD와 짝프로그래밍은 아직도 나에겐 먼 섬, 그러나 시도의 즐거움"

    개인적으로 오픈소스를 공부할 때 그리고 프로젝트를 하면서 짬이 날 때만 TDD를 시도했다. 운이 좋을때는 Eclipse의 Community Framework와 같은 플러그인을 써서 짝 프로그래밍을 도입했다. 그리고 또 잊혀만 갔다. 본인은 프로젝트에서 얻은 지식보다는 개인적인 독학으로 공부한 지식과 경험을 굉장히 중요시하고 있다. 왜냐하면, 프로젝트라는게 항상 반복되는 일상과 똑같은 업무, 그리고 똑같은 규칙으로만 살면 그럭저럭 할 수 있는 게 프로젝트였고, 뭔가 새로운 시도를 좋아하는 나에게 또 다른 나만의 연구와 학습이 필요했던 것이다. 다른사람에게 거저 들어서 안 지식과, 자신이 노력해서 일군 지식은 그 가치정도가 상당히 크다고본다. 그리고.. 그런 연구적인 취미가 아직도 나에게 남아있다.

    "후배들에게 강조하는 것"

    나는 후배들에게 개인적인 학습을 지속적으로 하라한다. 이 말은 더 강조해도 지나치지 않는다.
    물론 가치관이 다른 사람들에게는 이런 말 조차도 꺼내지 않지만 말이다.
    남들이 한 것을 그냥 배껴서 살면 항상 그 자리에 맴돈다고 설명한다.
    일은 일이고 학습은 학습이라고 이야기한다.
    그리고 지식적인 소통을 하라고 강조한다. 귀찮을때까지 말한다.
    한가지 아쉬웠던 것은 개인의 능력이란 게 모두 달라서 똑같은 패턴의 학습을 강요할 수는 없다. 이 사람의 자질과 능력에 맞게 책을 추천해주고 소통할 수 있게 하는게 나의 취미이자 목표가 되어버렸다.
    (이즈음 되면 나도 어느정도 교육자의 피가 흐르는 것 같다. 현업에게 기술적인 교육을 하거나 후배들에게 무언가를 가르칠때 많은 보람을 느낄때가 많다.)
    한번은 그런 강조와 설명이 지나쳤던 적도 있다. 그래서 도망다닌 후배도 있다. (ㅋ)
    후배가 생겼을때부터 그들에게 IT에 관련된 이야기할 때는 그 사람의 레벨에 맞추어서 이야기해야 한다는 것을 깨닫는다. 몇 번 이야기를 해보면 이 사람이 어떤곳에 위치해 있는지 대강 알 수 있는 수준이 되었다. 막 입사한 사람들에겐 쉬운단어로 소통을 해야하고 그들이 바라보는 시각으로 설명을 해주어야 한다. 또한, 그 보다 상위 레벨에 있는 사람들에겐 또 그에 맞게 낮춰서 이야기를 해야한다. 때로는 이러한 레벨의 높낮이를 잘못 판단해 실수한 적도 있지만, 최근엔 거희 실수하지 않고 적당한 수준에서 조절한다.

    "좋은 선배가 되는것은 무척이나 어려운일이다. 하지만 노력할만한 값어치는 있다"

    더 보기 좋은 선배가 되기 위해서 노력한다는것은 꽤 어려운 일이다.

    그냥 일만 시키는 선배가 될지, 아니면 일만 떠넘기는 선배가 될지, 또는 실력도 좋고 인간성도 좋고 그들에게 뭔가 더 보탬이 될수있는 선배가 될지는 개인의 노력여하에 달린 것 같다. 이런 내 마음을 아는지 모르는지 어떤 프로젝트에서는 무슨 선동을 한다고 오해를 받을적도 있다. 가끔씩하는 회식자리나 술자리에 참여하더라도 나는 "우리의 본질에 대해서 잊지말자"라는 말을 항상 동료와 후배들에게 각인시킨다. (그런 나를 선동자로 몰아붙였던 어떤 PM에게 참으로 억울하다는 이야길 하고 싶다.) 그리고 그들에게 놀 때는 놀고 확실하게 일할때는 일하고 공부할때는 공부하자는 마인드를 심어주려 노력한다.
    개인적인 모임을 통해서 스터디를 꾸미려고 노력도 많이 해 보았다. 하지만, 나처럼 지식적인 갈구를 하는 사람은 별로 없었다.
    스터디에 대해서 크게 기대하던 후배들도 몇 명 있었지만, 그들도 하는 일이 SI라서 일회성 결심에 지나지 않았다. 그들을 끌어주기 위해서 한번 제대로 된 스터디 그룹을 갖고 싶어했다. 그리고 내 지식을 물려주고 소통하고 같이 공유하고 싶었다. 그리고 또 다른 차원에 있는 사람들에게 배우고 또 공유하고 소통하고 싶었다. 배우고 공유하고 소통하고, 배우고 공유하고 소통하고, 배우고 공유하고 소통하고 그것이 그때는 전부였다.

    "만나면 헤어지고 헤어지면 만나는게 인간사,
    기술보다.사람..그것부터 모든것이 시작이다."


    하는 일이 프리랜서라 잦은 프로젝트 이동때문에 또 이들과 헤어졌고, 다시 새로운 사람을 만나야만 했다.  만남이 있으면 헤어짐이 있고, 헤어짐이 있으면 만남이 있는 것이다.
    그리고 또 새로운 사람들에게 그러한 것들을 물려주고 또한 그들에게서 영감을 얻는다.
    한번은 내 직업자체가 잦은 이동과 출장을 나가야 하는 직업이라서 신세한탄이나 푸념을 늘어놓기도 했다. 어떤 새로운 조직에서는 그런 새로운 만남도 무뎌질대로 무뎌져서 더이상 새로운 만남을 원하지도 않았다.
    프로젝트가 장기라면 좋겠지만, 단기 프로젝트가 종종 있어서 진득하니 사람들을 사귈 기회가 좀처럼 주어지지 않았지만, 쭈욱 연락하고 지내는 동료와 후배가 있어서 참으로 다행인 것 같다.
    그들은 나에게 많은 관심을 두려한다. 그리고 나도 그들에게 많은 관심이 있다.
    서로에 대해 관심이 있을때 소통할 수 있으며 결국 같이 지향하는 그곳에 다다를 수 있다고 생각한다. 비록 일터에서 만났지만 난 그들을 신뢰하고 서로간에 도움을 줄 수 있는 사람이란것에 만족한다.
    하지만 아직 이들과 같이 애자일이나 XP, 또는 짝프로그래밍이나 TDD를 이야기할만한 수준의 동료는 나에겐 없다. 하지만 기술이 전부는 아니니 인간적인 형으로써 또는 친구로써 이들을 대하고 있다. 그들도 곧 터닝포인트를 갖고 순회하리라 난 믿어 의심치 않는다. 그들이 그 쟁점에 다다랐을때 나는 또 서포트를 해줄 것이고 또 새로운 장르에 대해서 이야기 할 것이다.
    그리고 제발 퇴색되어 가는 한국의 IT현실에서 그러한 열정과 도전들이 암흑의 나락으로 내동댕이 쳐지는 일은 없을것이라고 확신한다.
     

    글이 좀 많이 길어졌다. 아..진짜 길어졌다.
    깨작거리고 싶어서 쓴글이 무척이나 길어졌고 건조해졌다는 것을 지금 깨달았다. 
    이어서 다음 포스팅에 진짜 하고 싶은 말을 할 것이다.

     


     

    저작자 표시 비영리 변경 금지
    신고
    블로그코리아에 블UP하기
    1. Favicon of http://blog.doortts.com BlogIcon doortts

      2010.09.03 09:38 신고 [수정/삭제] [답글]

      쉽지 않은 환경에서도 노력하셨던 모습이 상상이 갑니다.:) "좋은 선배가 되는것은 무척이나 어려운일이다. 하지만 노력할만한 값어치는 있다"는 말씀도 인상깊었습니다. 기다림의 미학을 가지신것도 배울점이라 생각했습니다. 좋은글 감사합니다.

      • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

        2010.09.03 20:14 신고 [수정/삭제]

        그동안 매 프로젝트에서 가치를 가지고 일하려고 애를 많이 썻었었요. 알아주는 사람 한명도 없었지만..ㅋ
        문득 생각이 나서 글을 쭈욱 적어 내려갔는데, 읽어 주셨다니 정말 감사합니다.^^

    2. Favicon of http://kimkoon.tistory.com BlogIcon 김꾼

      2012.01.10 14:56 [수정/삭제] [답글]

      관리자의 승인을 기다리고 있는 댓글입니다

    댓글을 남겨주세요.

    [TDD] 정독완료..TestCase의 private 메소드.

    Posted at 2010.07.08 15:00 // in TDD // by MOOVA 무바㏇
    테스트주도개발TDD실천법과도구
    카테고리 컴퓨터/IT > 프로그래밍/언어 > JAVA > JAVA일반
    지은이 채수원 (한빛미디어, 2010년)
    상세보기
    해당 포스트는 : http://moova.tistory.com/entry/SI에서-TDD에-대한-노력2 과 연결되어 있습니다.


    나름대로 구입을 잘했다는 만족감.

    목록중 대부분이 학습을 통해서 알게 되었거나 주시하는 RSS를 통해서 습득을 한 것들이어서 구입을 꺼려했는데, 막상 정독하고 보니 새롭게 알게된 사실도 몇 가지 있어서 대체적으로 만족할 만하다. 개인적으론 실무경험에 있어서 덧붙일 내용이 필요하다는 생각이 들었지만, 그것은 나중에 정리하기로 하고..

    그리고, 내가 생각한 것과 똑같은 글귀를 보게 되어 좀 깜짝 놀랐다. 일을 하면서 이렇게 생각들이 일치한 사람을 만났다면 지금쯤 나는 어디서 무엇을 하고 있을가?

    내가 생각했던 것과 같은 소견


    책중 일부분 = private 메소드도 테스트 케이스를 만들어야 하나요?
    우선 먼저 private 메소드가 왜 생기나? 혹은 언제 private메소드를 만들게 되나?를 생각해볼 필요가 있습니다.
    java에서의 private은 접근 범위로 봤을 때 오직 자신의 클래스 내에서만 접근 가능한 속성이나 메소드입니다. 즉, 외부에 알리고 싶지 않은 부분이라는 전제하에 만들어집니다. 하지만 클래스의 효용 가치는 그 클래스가 갖고 있는 정보와 그 정보를 기반으로, 다른 클래스와 상호작용한다는 데 있습니다. 이를 모듈화, 독립화라고도 하는데, 다른 클래스 입장에서는 자신이 원하는 기능을 올바로 해주기만 하면 더 이상 신경 쓰지 않아도 되는 겁니다. 그리고 그 외부에 제공하는 기능이 제대로 동작하는지 보장해준다는 의미로 테스트케이스를 만드는거죠.. 생략...
    public 메소드를 테스트하면 그에 딸린 private메소드는 자연스럽게 테스트되었다고 간주합니다.

    KSUG에 올렸던 비슷한 내용
    JUnit의 테스트 메소드는 왜 public이어야 할까요?

    몇가지를 생각해 보았습니다.

    먼저 의미상으로 '테스트'라는 것을 생각해보면..
    테스트는 실제 돌아가는  모듈이나 단위 기능들을 점검하여 잘 돌아가는지 이리저리(?) 확인 하기 위한 것이라고 알고 있는데요

    만약에 실제로 운용중인 기능들을 모두 테스트 한다고 치면,
    구지 테스트를 숨길 필요가 있을까..하는 생각이 듭니다.
    테스트 작성자가 테스트를 숨겨놓았다면 아마도 그것은 테스트를 기피하는 부분 이겠거나
    아니면 양심 없는 코드를 작성해 놓았기 때문에 테스트를 숨겨놓았을 것입니다.

    이렇게 의미상으로 보면 테스트는 모두에게 공개되어야 한다는 의미에서 language측면에서도 public이어야 한다는 생각을 하고 있구요.

    두번째 접근은 리팩토링과 관련된 것입니다.
    TDD방법에서는 테스트 코드를 먼저 만들고 실제  클래스를 생성해서 그안에 실제 메소드를 만들게 되죠.
    대부분 클래스 안에 제일 처음 만들게 되는 메소드를 private으로 만들진 않는 것 같습니다..
    처음부터 private으로 코드를 넣게 된다면 그분은 아마 대단한 실력가가 아닐까 생각합니다.

    저는 대게 public으로 메소드를 만들고 필요에 따라서 extract method와 같은 리팩토링 기법을 사용해 중복되는 부분
    이나 기능의 분할을 위해서 메소드를 private으로 빼는 습관이 있습니다.

    리팩토링 된 private 메소드는 외부에서 직접 호출 하진 않죠(호출하는 방법도 있긴 하지만)
    외부에서는 먼저 공개된 public메소드를 호출기준으로 삼고 클래스 내부에 있는 private메소드들는 자연스레 public
    소드에서 사용 될테니까요. 만약에 클래스 내부에 private메소드가 심하게 있다고 치면 그 클래스는 단일책임원칙에 의해서 잘 설계된 클래스가 아니라고 생각됩니다. 이를테면 분할을 잘못한 구조이거나 procedure스타일로 짜여진 클래스일 가능성이 클 것 같습니다.

    이렇듯 테스트는 테스트하기 편한 실제 코드를 좋아한다는 입장에서,
    호출할 부분 즉, public메소드를 호출하는 입장에서 테스트 메소드가 private일 필요가 없다고 생각합니다.

    이와 비교해서 테스트케이스 안에 메소드들이 public이어야 하는 점도 위와 비슷하게 생각을 해봅니다.
    단위 테스트용 클래스들은 잘 분할된 실제 클래스를 테스트 하기 위한 메소드들이지
    테스트 케이스안에 private 메소드들을 테스트하기 위한 것은 아닌 것 같습니다.
    테스트케이스안에 private 메소드가 있다면 실제로 테스트안에서 리팩토링이 이루어졌다거나 아니면 중복되는 테스트를
    private으로 뺐다는 가정이 있으므로, 이 관점에서 생각해 본다면 private 메소드는 테스트 대상이 될 수가 없는 것 같
    습니다.

    다음은 기술적인 관점입니다.
    TestSuit류의 테스트를 하게 되면 한꺼번에 단위 테스트들를 묶어서 테스트하게 되겠죠. 이것도 위에서 설명한 것처럼 외부에
    서 호출대상이 되는 부분은 공개 되어진 부분이지 숨어 있는 부분이 아니란 점입니다. 테스트가 숨어있다면 분명 공개된 테스트에서
    이미 사용하고 있을 가능성이 크기 때문입니다.

    생각나는대로 적으려다가.. 좀 더 생각하고 적었습니당;;;



    결론은 내가 생각했던 것과 같은 이야기다.. 사뭇 놀람.. 세상엔 비슷한 생각을 하는 사람들이 의외로 많다. 좀처럼 찾아 볼 수 없다는게 흠이지만..
    저작자 표시 비영리 변경 금지
    신고

    'TDD' 카테고리의 다른 글

    [TDD] 정독완료..TestCase의 private 메소드.  (2) 2010.07.08
    블로그코리아에 블UP하기
    TDD
    1. Favicon of http://blog.doortts.com BlogIcon doortts

      2010.07.09 21:57 신고 [수정/삭제] [답글]

      안녕하세요? 많이 부족하고 부끄러운 책안의 글 정독해 주셔서 감사합니다. 그와는 별개로 (비록 일부분이긴 하지만) 저와 생각이 같은 부분이 있었다는 걸 알고는 더욱 반가웠습니다.

      읽으시며 아쉬웠던 내용, 기회 되실 때 알려주시면,
      배움의 하나로 알고 감사히 듣겠습니다. 그럼, 편안한 주말 되세요.

      감사합니다.

      • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

        2010.07.10 05:49 신고 [수정/삭제]

        오우~ 이렇게 직접 블로그까지 찾아와 주시다니 정말 감사드립니다.~**
        Agile과 TDD에 관하여 몇 해동안 탐독중, 그렇게 정성이 깃든 TDD관련책은 한국에 별로 없었던 것 같습니다. 때에 따라서 시도해 보려다가 포기한 기법들도 책속에 있어서 제 자신을 다시한번 반성하게 만들었습니다.(실무속에서 제가 경험했던 아쉬운 부분들도 대체적으로 책속에서 지적을 해 주셔서 매우 공감이 되는 부분이 많았습니다. 무조건 TDD를 맹신하는 것은 좋지 않다는 생각도 저랑 비슷했구요.
        앞으로 저의 부족한 소견까지 받아주신다면 정말 즐거운 이야기를 할 수 있지 않을까 합니다**)

        다시한번 찾아주셔서 깊은 감사를 드립니다.

        주말 편하게 보내세요~~**

    댓글을 남겨주세요.

    [Books] 7월볼책. 열심히들 하겠지...

    Posted at 2010.07.07 22:36 // in Books // by MOOVA 무바㏇
    7월달에 읽을 책이 오늘 도착했다. 오라클 서적 1권이 추가됐으니 RDBMS책이 총 16권이 된 셈 ( 다 뼈가되고 살이된다. ). 헉 아니지 후배들 준 책 마이너스하면 총 RDBMS 11권이 집에 있구나...
    ( 영어단어 암기할 때 한장씩 질겅질겅 씹어먹는 버릇보다..
    난 책을 다본 후, 후배들에게 나눠주는 습관이 있다. UML책도 8권중 3권밖에 남지 않았으니.. 다들 잘 사용하고 있겠지.. RCP책도, XML책도, OOP관련책도, 리팩토링책도, 다들 잘 보고 있겠지... 열심히들 하겠지. 
    프리생활하면서 이런 습관이 나에겐 낙中 하나였다..모두 챙겨주지 못해서 미안하기만 함..
    이런모습보고 나를 완전 부자로 생각하는 사람들이 더러 있는데, 난 결코부자가 아니다. 있는자들에게 붙어먹는 행위보다 없는자들과 함께 토닥토닥하며 가는게 비위에 맞는 사람이다. 단지 있어보이고 권력에 편입될거 같다고 붙어먹는 행위는 정말 내 스타일이 아니야~~~~ㅎ)

    코믹 스튜디오는 동생에게 컴퓨터로 만화 그리는 법을 배우기 위해 사둔 책이다. 일본 프로그램중에 코믹 스튜디오라는 만화편집툴인데 타블렛으로 그리면 실제 그림체를 더 정교하게 꾸밀 수 있다고 한다. 그림 그리는 것은 언제나 나의 취미. 마침 시큰둥해 있는 동생의 기를 살릴 수도 있고 해서 구입한 책.~

    십자가 초승달 동맹과 경제 상식 충전소는 대중교통을 이용할 때 읽을 책이고..

    애자일 이야기에서 본 테스트 주도개발 TDD 한번 읽어보기 위해 주문했다.  (목차를 보면 대부분 지난 날 써봤던 내용이라 구입을 망설였는데, 애자일 이야기 이거보고 바로 구입했다. 꼭 봐야하는 책이다. )

    LG CYON | KU9100 | Normal program | Unknown | 2010:07:07 20:21:17

    또 시작인가 책 고문..

    저작자 표시 비영리 변경 금지
    신고
    블로그코리아에 블UP하기
    1. Favicon of http://minimonk.net BlogIcon 구차니

      2010.07.07 23:06 신고 [수정/삭제] [답글]

      책 고문은 행복하죠...
      전 토익 고문의 시작이에요 ㅠ.ㅠ

    2. Favicon of http://moonlgt2.tistory.com BlogIcon 소박한 독서가

      2010.07.08 00:16 신고 [수정/삭제] [답글]

      다들 전문적인 냄새가 나는 책들이군요..
      전 엄두를 못낼 듯 합니다^^
      열심히 독서하세요~^^

    3. Favicon of http://gkyu.co.kr BlogIcon G-Kyu

      2010.07.08 00:49 신고 [수정/삭제] [답글]

      책을 많이 읽으시는군요!! +_+
      전 한달에 2권정도..읽으면 많이 읽는 축인데요...! ^^

    4. Favicon of http://legendre.tistory.com BlogIcon 세레

      2010.07.08 10:49 신고 [수정/삭제] [답글]

      저도 새로나온 TDD 책 보려고 주문했는데, 정말 기대되네요.

    5. Favicon of http://kindtis.tistory.com BlogIcon 친절한티스

      2010.07.08 11:03 신고 [수정/삭제] [답글]

      오~ TDD 책은 저도 구매예정 리스트에 있는 ㅋㅋ
      보시고 나서 서평 좀~!!

      • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

        2010.07.08 17:29 신고 [수정/삭제]

        TDD를 어제 2/3정도 일독했어요. 기존에 사용해봤던 부분이 많이 중복이되어서 책을 속독할 수 있었던 것 같아요. 책 구입에 대해서 어느정도 만족하고 있습니다. 나중에 편하게 서평한번 올릴께요~

    6. Favicon of http://kwang.info BlogIcon 광서방

      2010.07.08 16:04 신고 [수정/삭제] [답글]

      믹시에서 소식듣기 메일 받고 와봤습니다. 좋은 책 많이 읽으시네요. 저도 '압박'이 많은데 사실 '즐거운' 압박이기에 계속 견뎌가고 있습니다. 즐거운 독서 생활 하시죠 ^^;;

    7. Favicon of http://yes250.tistory.com BlogIcon Always(恒常)

      2010.07.09 16:37 신고 [수정/삭제] [답글]

      읽을책들이 많아서 행복하시겠습니다....서평도서만 아니면 읽고싶은 책좀 구입할텐데...ㅠ.ㅠ 즐독 하시기 바랍니다!!~ ^^

    댓글을 남겨주세요.

    [Books] 6월 읽은 책.

    Posted at 2010.07.07 22:19 // in Books // by MOOVA 무바㏇

    LG CYON | KU9100 | Normal program | Unknown | 2010:07:07 21:24:28


    그개는무엇을보았나참을수없이궁금한마음의미스터리
    카테고리 자기계발 > 자기능력계발 > 아이디어
    지은이 말콤 글래드웰 (김영사, 2010년)
    상세보기
    다소 실망한 책이다. 책의 요점을 찾을 수 없을 만큼 짜깁기 한 듯한 기분이다. 상당히 기대하고 봤는데 10에 2정도로 미달인 책

    1026
    카테고리 소설 > 한국소설 > 공포/추리소설
    지은이 김진명 (새움, 2010년)
    상세보기

    작가 김진명의 소설이다. 무궁화 꽃이 피었습니다, 한반도 같은 약간의 국수주의가 담긴 책을 좋아한다. 현대사상 가장 미스테리한 하루인 10.26을 다룬 소설이고, 사실을 근거로 한 허구가 마치 사실을 보는 듯한 느낌을 가져다준다. 김진명 소설이 그렇듯 이번에도 기대를 져버리지 않았다. 앞뒤 전개가 딱 떨어질 만큼 충분한 연구조사를 통해서 내용을 집약해 놨다. 상당한 수작이다. 별 10개.

    스눕상대를꿰뚫어보는힘
    카테고리 인문 > 심리학 > 교양심리
    지은이 샘 고슬링 (한국경제신문사, 2010년)
    상세보기

    심심풀이 땅콩용으로 보기 적당하다. 상대방의 행동이나 몸짓 사물을 보고 타인을 꿰뚫어 보겠다는 연구적 가치가 담긴 책이다. 여러가지 사례를 통해 자신의 논리를 좀 과학적으로 주장한다. ( 매우 재미있다. )
    우연이 아니고 직감을 넘어서 과학적으로 상대를 꿰뚫어 볼 수 있는 책.
    하지만 타인을 알기 위해선 자신을 먼저 알아야 할 것이다.
    드라마 멘탈리스트와 같은 성격의 책으로 승격.

    심리학콘서트
    카테고리 인문 > 심리학 > 교양심리
    지은이 다고 아키라 (스타북스, 2006년)
    상세보기

    다소 찌뿌둥한 그런 책이다. 읽는 듯 마는 듯한 기분. 몇 가지 얻을 수 있는 단락도 있다.
    내기 모습에서 사회생활이 보인다든지, 인간적인 모습은 친밀감을 증가시킨다던지, 사람과의 애증 관계가 오히려 득이 된다던지..말씨나 표정 감정과 같은 지각들을 심리학적인 측면으로 서술했다.
    한 5년 전에 봤었으면 득이 될만한 책. 별 10개 중 6점 정도 줄 만하다.

    번역의탄생한국어가바로서는살아있는번역강의
    카테고리 인문 > 언어학 > 언어학일반 > 언어교육론/번역
    지은이 이희재 (교양인, 2009년)
    상세보기

    지금 탐독하고 있는 책. 정말 기가막힌 책. 직역보다 의역을 중요시하는 글쓴이의 의도가 논리적으로 표현되어 있다. 실제 의역에 활용할만한 가치가 있는 책. 이 책은 계속 읽고 있는 책이므로 책의 소개로 대신할까 한다.

    -- 한국어가 바로 서는 살아 있는 번역 강의『번역의 탄생』. “번역은 외국어를 옮기는 작업이 아니라, 한국어를 바로 세우는 작업이다!” 20여 년간 말과 말이 치열하게 맞붙는 번역 일선에서 살아온 전문 번역가 이희재가 그의 노하우를 가득 담은 책을 내놓았다. 바로 이 책, 우리말과 글을 바로 세우는 살아 있는 번역 원칙론을 제시하는 인문 도서이다.
    한국어의 논리는 무엇일까? 이 책은 번역 현장에서 찾아낸 한국어의 고유한 개성을 뚜렷이 보여준다. 영어는 사물을 주어로 하는 경우가 많지만, 한국어는 주어 자리에 추상명사보다 사람이 오는 걸 좋아하며 추상성과 보편성보다는 구체성과 특수성을 나타내는데 강하다. 이처럼 저자는 번역에서도 적극적으로 한국어의 특징을 드러내야 한다고 말한다.
    무엇보다 한국어가 지닌 개성을 더욱 풍요롭게 창조할 수 있다는 가능성을 보여준다는 것이 이 책의 장점이다. 서구 이론가의 추상적 틀에서 벗어나 한국어 현실에서 출발한 이론을 바탕으로 함으로써 한국어 재창조의 방법을 알 수 있기 때문이다. 우리글을 올바르고 아름답게 쓰고 싶은 모든 이들에게 자신감과 희망을 얻을 수 있도록 도와주는 책이다. [양장본]


    그리고....
    저작자 표시 비영리 변경 금지
    신고
    블로그코리아에 블UP하기
    1. Favicon of http://wearcom.tistory.com BlogIcon wearcom

      2010.07.08 00:05 신고 [수정/삭제] [답글]

      오웃~ 엮인글 보고 왔습니다. 하하하. 스눕을 읽으셨네요~ 읽을려고 북리스트에 담아 놓은 책인데 ^^
      게다가 저와 같은 개발자시군요. 종종 놀러 올께요~

    댓글을 남겨주세요.

    티스토리 툴바