Younghoe.Info (final edition)

우연히 괌 여행기 한 편을 봤다.

괌, 다시 가고 싶지 않다

여행기란 표현은 어울리지 않는다. 날카로운 비평? 어떤 이름이 적절할까? 확실한 사실은 글솜씨가 뛰어나단 점이고, 글쓴이가 잔뜩 화가 났단 사실이다. 3년 전 괌 여행이 너무 좋아서 언젠가 꼭 가고 싶다는 자주 한다.

서민입장에서야 큰 맘 먹어야 한 번 가는 외국여행인지라, 개인적 의견이라도 균형감이 좀 필요하겠다 싶어서 내 경험을 짧게 옮겨둔다.^[각주:1]

1. 시차가 없는 여행에서 강제로 시차를 만들어 체력을 점검할 수 있다.
나 역시 유일(?)하게 불만스런 점이다. 다음 괌 여행에선 외국 항공사를 이용하는 방법으로라도 피하고 싶다. 현지 가이드는 대한항공의 횡포라고 했다.

2. 뭘 먹을지 고민할 필요가 전혀 없다.
여친님이 클릭 품 팔아서 준비해준 덕에 다양한 음식을 매우 맛있게 먹었다. 특히 LA 갈비랑 대하구이는 아직도 맛을 잊을 수 없다. 송원섭님과는 전혀 다른 경험이었다.

4. 짧은 휴가기간에도 고국에 머무는 듯한 착각을 준다.
3은 패스고, 4는 PIC만의 문제다. 나는 다른 리조트에 있어서 다른 한국 사람을 만나기 어려웠다. 크루즈 타는 일행이 PIC에 있어서 잠시 들렀는데, 약간 과장하면 잠시 귀국(?)한 느낌이었다.

5. 전혀 인상적이지 않은 고가 옵션을 통해 해외여행에 대한 내성을 키운다.
마이크로몰이었던가... 팩토리 아웃렛을 가면 초저가로 폴로 옷이나 GNC 건강식품을 살 수 있다. 파티용 원피스를 저가에 살 수도 있고, 우리나라에선 너무 비싸게 하는 콜드스톤 아이스크림을 염가에 즐길 수 있다. 면세점을 잘 이용하면 오클리 선글라스를 저가에 구매할 수 있다. 나도 저가에 오클리 윈드 브레이커를 하나 샀다.

관심을 두지 않았지만, 난리였던 모양이다. 어제도 점심때 화두가 잠시 '미디어법'에 머물렀다. 대다수 국민(혹은 서민)은 나처럼 관심이 있나? 어제 호주 사람이 '미디어법이 뭐기에 난리야?'라는 물음에 '조중동, 공중파 진출 열어주는 법이야.'라는 한쪽으로 치우친 답을 해버리고 치웠다. 그런데 출근길에 손석희의 시선 집중과 이어지는 뉴스를 들으니 조목조목 어제의 진상을 설명해주었다. 혹시 궁금해하실 분이 있을까 요약해둔다.

여야에서 극명하게 갈렸던 부분은 지상파 진출을 위한 장벽의 기준이 '점유율'이냐 '구독률'이냐에 있었다. 한나라당안은 '대한민국 전체 가구 수에서 특정 신문의 구독수를 환산한 가구구독율'은 기준으로 하고 있다. 신문 시장을 독과점하는 조중동의 구독률은 10% 내외다. 20%를 넘는 신문사가 존재하지 않는데 유명무실한 기준 아니냐는 손석희씨 질문에 한나라당 대표는 '미래 일을 누가 아느냐?'라고 답했다. 내림세가 뚜렷한 신문시장을 고려해보면 비현실적인 답이다.

난투극 속에 표결 처리한 어제는 과정에서도 많은 문제를 낳았다. 먼저 몸싸움을 하느라 정족수가 모자랐는데 표결을 한 터라 '부결'인데, '국회법'을 위반(?)하고 재투표를 진행해 법리적 이슈에 휘말렸다. 의견이 분분하지만, 헌법학회장은 명백한 헌법 및 국회법 위반이라고 주장했다. 게다가 대리투표 논란까지 있다. 민주당 모최고의원 주장에 따르면 6~10명 정도의 대리투표를 적발했다고 주장한다. 더구나 몸싸움 중인 야당 강봉균의원이 표결을 해서 여당에서 대신 눌렀다는 주장도 제기했다.

한나라당이 '일자리 창출'을 명분으로 걸고 있지만, 내용 면에서나 절차 면에서나 여러 가지로 문제가 있는 법안이다. 지난 정부 때 '친일청산법'과 '사학법'에 치열하게 반대하던 한나라당이 민생법안도 아닌 '미디어법'에 집착하는 모습을 보면 그들이 말하는 국민이 누구인지 명확해진다.

MB 정부와 한나라당의 행보를 보면, 저작권법을 내세운 누리꾼 단속, KBS 사장 해임, '집시법', 최시중 방송통신위원장, '미디어법'에 이르기까지 여론을 통제하려는 듯이 보이는데 과연 어떤 결과를 낳을까?

얼마 전 모 인터넷 매체 대표가 '듣보잡'이란 표현에 대해 법적 대응을 했다는 소식을 들었다. 누군가에게 굳이 '듣보잡'이란 표현을 하는 이유는 무얼까? 막연한 추측이지만, '끼리끼리 논다.'는 속담이 이 상황에 걸맞지 않나 싶다.

여하튼 이 일은 남 일이었다. 그런데 얼마 지나지 않아 일면식도 없는 투덜이(?) 블로거가 나에게 연거푸 '듣보잡' 운운하는 글을 읽었다. 그 친구 말대로 '영양가 없는 글'인데 왜 굳이 일일이 보도(?)를 하듯 비판하는 글을 올리는지 궁금하다. 내 짧은 머리로는 그게 무엇이든 나 때문에 손해를 본 인사가 아닌가 싶다.

한동안 나는 어쭙잖은 실력을 갖추고 어깨에 힘이 들어가 있었다. 그렇다고 지금 '익어서 고개를 숙이는 단계'는 아니다. 하지만, 듣보잡을 벗어나는 방법을 터득했다. 어차피 나에게 듣보잡이라 하는 이는 수준이 비슷하다고 할 수 있으니 굳이 신경 쓸 이유가 없다. 고수가 나에게 실망했다면 낙심할만하다. 그런데 고만고만한 이가 나를 헐뜯는 이유는 뻔하다.

지금 하고 있은 일에 만족한다면, 스스로 부끄럽지 않은 정도로 노력하고 있다면 그만이지 않은가? '왜 사냐면 웃지요.'까지는 꿈도 꾸지 못하더라도 말이다.

소프트웨어 기술자 신고제도 - 미쳤다.를 보고 점심 시간에 잠깐 메모한다. 기사를 보면, 주관하는 곳은 지경부와 한국SW산업협회다. 여기서 두 가지 사실을 확인할 수 있다. 정통부 시절에는 없던 제도를 지경부는 만들었다. 정통부가 아닌 지경부이기에 이런 문외한(?)다운 제도를 만들지 않았을까? 최근에 주변에서 신고를 하려고, 전 직장에 연락하고 심지어는 폐업신고서를 받으려고 프로젝트 중간에 세무서를 가는 사람도 본다.

짧게 보면 SI에 종사하는 수많은 사람과 기업이 각종 서류를 챙기느라 손해를 본다. 다음달부터는 돈까지 지불해야 한다. 비는 곳이 있으면 차는 곳이 있는 법이다. 이익은 누가 볼까? 역시 단기적으로 보면 한국SW산업협회가 수익을 챙긴다. 시스템 구축이 필요할 터이고, 관리 인력도 보유해야 한다.

고생해서 일일이 등록하는 수고에 대한 대가로 돌아오는 이익이 있을까? 지경부가 강하게 추진하면 가능성이 있을 듯하다. 명분을 만들기 위해서나, 현 정부의 색깔을 보면 가능성이 농후하다.

제도가 옳으니 그리니 얘기하고 싶은 생각은 없다. 경우에 따라서는 데이터를 쌓아놓아서 이익을 보는 때도 있지 않을까? 하지만, 경력은 기술자 역량을 평가하는 여러 가지 기준 중에 하나 일 뿐, 절대적인 기준은 아니다. 정부에서 나서서 우루루 끌고 간 만큼 효과를 낼 수 있을지는 심히 의문이고, 오래 존속할 제도는 아닐 듯하다. 정통부가 사라지니 발생하는 대표적인 대형(?) 시행착오가 아닌가 싶다.

제2회 한국 SW 아키텍트 대회에 발표자 자격으로 참석했다. 행사에 관심 있는 분에게 공유 차원에서 후기를 남긴다. 먼저 리셉션 후기다. 마침 업무상 방문했던 분당에서 올라오는 길에 시간이 맞아 리셉션에 참석했다. 우연히 모 SI 업체에서 아키텍트 팀을 총괄하는 분이 옆에 앉았다. 인사를 청하자, 고객이 '아키텍트가 도대체 뭘 하는 사람이냐?'라고 물으면 한 마디로 뭐라 대답하느냐고 물었다. 난감한 질문이다. 대개는 프로젝트 종료 후에 인정하지, 말로는 설명이 어려웠다. 한 수 배우려고 오히려 반문했지만, 묘안은 없었다. 대화를 나누다 보니 자연스레 대회 필요성을 공감할 수 있었다. 아직, 직무로 통용하기 어려운 '아키텍트'란 역할에 대해 공감대나 저변 확대를명확한 정의, 범용성 확보 혹은 홍보 등의 활동이 필요한 듯하다.

축사 과정에서 두 가지 인상 깊은 발언이 있었다. '통신 분야에서 일하다가 SI에 왔더니 상황이 이 정도로 열악한 줄 몰랐다'라는 모 SI 업체 대표님 발언이 하나고, 다른 하나는 모 교수님의 '상식수준의 내용을 대단한 노하우인양 숨기던 관행을 벗어나자!'라는 취지의 발언이었다.

10일 세션 발표 시간은 아쉬웠다. 오후 발표는 시간이 늦어졌고, 가뜩이나 짧은 25분 발표도 5분이 줄었다. 핵심적인 메시지 위주로만 전달했는데 그래도 1분을 초과했다. 질문사항 응답 및 토론시간의 열기가 놀라웠다. 내 발표에 대해서도 질문이 있어 답변했다. 오픈소스 라이선스 관련 질문이 두 개나 있었는데, 발표자가 참석하지 않아 대신 대답했다. 이를 포함하여 몇 가지 인상적인 질문과 대답을 메모한다.

1. 아키텍처 평가 모델을 실제 프로젝트에 적용한 사례가 있는가?
없다. (좌장 추가 의견) 현실적으로 아키텍처 평가 모델에 입각한 절대적 검증은 불가능하다. 감리는 절차만 다룬다. 내용에 있어서 감리할 수 있는 조직이 국내에는 없다. 따라서, 다른 아키텍트가  경험에 따른 직관으로 조언을 제시할 수 있을 뿐이다.

2. 테스트 자동화를 위해 아키텍처 측면에서 고려해야 할 요인이 있나요?
없다. 테스트 자동화는 오히려 다양한 아키텍처를 포용할 수 있어야 한다. (다른 발표자 추가 의견) 테스트 자동화를 위해 아키텍처를 고칠 수 없다. 그러나 일관성 있는 아키텍처를 갖춘 시스템은 테스트 자동화가 쉽다. 가령, 각 레이어별로 전달인자가 분명한 경우를 떠올려보라.

3. Spring, Struts 등으로 비즈니스 로직을 구현한 경우 공개 의무는?
아파치 라이선스를 채택한 경우이므로, 사용 고지에 대한 의무는 있지만, 소스 코드 공개에 대한 의무는 없다. 자세한 사항은 오픈소스란 어떤 것인가? 내용 참조.

4. Hibernate와 iBatis 성능 비교?
단순 성능 비교는 의미 없다. 개발/운영 시 DBA가 SQL을 짜주는 경우라거나 SQL을 직접 노출하여 관리하기 위해 iBatis를 선택했다거나 장기적으로 객체 모델을 유지해가기 위해서 혹은 솔루션 코어를 만들기 위해서 Hibernate를 선택한다는 식이 바람직하다.

Toby 형이 읽어보라고 권장한 링크다.


생생하고 절절한 글을 또 찾아볼 수 있다. 충분히 성장 동력일 수 있는 '공부병기'가 왜 아내에게 고통스런 삶을 안겨주는 장본인이어야 할까?

이런 개발자를 대할 때면, 사실 개발자가 아니더라도 철저한 생활인을 대할 때면 고개를 숙일 수 밖에 없다. 겉으로 아닌 척 해봐야 소용 없으니까. 그 치열함에 대면 누구^[각주:1] 말대로 난 듣보잡이다. 치졸한 감정과 게으름, 수지타산을 떨쳐 버리고 홀연히 이상 혹은 우아함을 추구할 공력이 내게는 없다. 막연한 추측이지만, 분명 T사에는 열정이 넘치고 뛰어난 개발자가 많이 있을 듯 하다.

그런데 세상엔 다른 부류의 개발자도 많다. 그저 유행을 쫓아 곳곳에 기웃거리는 이도 있고, 쿼리 하나 못 짜고 디버깅도 못하는 점을 부끄러워 하지 않는 개발자도 흔히 볼 수 있다.

그렇다면, T사 핵심 개발자와 쿼리 하나 제대로 못 짜는 개발자 삶의 질은 극명한 차이를 보일까? T사 핵심 개발자는 병기에 가까운 헌신에 대한 보상을 충분히 받을까? 그렇다면 인용한 글을 보지 못했으리라. 개발자에게 적합한 보상이 이뤄지는 세상은 언제 올까?

Gantt와 CSV 출력(export)에 혹해서 잘 써오던 Trac을 버리고 Redmine으로 옮겨 탔다. 작년 초 검토할 때는 너무 느렸는데, 동료 말이 쓸만해졌다고 한다. 후임이 있어 설치는 그 친구에게 맡겼다. 큰 삽질 없이 설치를 했다.

이제 Mylyn 연결을 하려고 connector를 찾았다. 여차저차 따라간 SF 설치 정보는 "org.apache.xmlrpc" 플러그인 설치를 선행하란 메시지를 보냈다.

다행스레 How-to 문서를 다시 찾았다. 그림을 보고 그대로 하니 그대로 연결했다. 브라보... WYSWYG 문서!!!

문서 여기서 다 끝이 나진 않았다. 관리자 계정 정보를 넣었는데 권한 문제로 일감(issue) 등록을 못한다거나 하는 자갈밭이 여전히 남아 있긴 하다.

혹시나 SF 문서 보고 고생할 분을 위해... 메모 남깁니다.

다음과 같은 코드가 있다.


rolls[frameIdx + 1] + rolls[frameIdx + 2] 부분을 메소드로 뽑아내고자 한다. 이클립스에서 블록 지정을 하고 Alt+Shift+M 단축키를 누르면, 다음과 같은 메시지를 만날 수 있다.


두 가지 해결책이 있다. 하나는 굳이 이클립스 명령을 쓰지 않는 방법이다. 다른 방법은 블록 지정 부분을 괄호로 묶고 나서 Extract Method 명령을 수행하는 방법이다.


결코, 빠른 방법은 아니지만 몇 가지 사소한 이점이 있다.

• 타이핑 절감
• 오타 방지
• 자동 줄맞춤
• inline 리패토링하면 다시 제거 가능
  

소송 문제나 OS 출시 등으로 화제(?) 중심에 서곤 하는 소프트웨어 회사가 있다. 다양한 사람을 통해 그 회사 이야기를 듣곤 한다. 프로젝트를 하면서 두 차례 정도 만난 일이 있다. 상식 밖의 주장을 하고, 일도 그렇게 했다.

한 번은 기술 검토를 한 바 있었다. 화면에서 버튼을 누르거나 하면 발생하는 이벤트를 처리하는 서버 프로그램을 처리하는 WAS 인스턴스가 두 개라고 했다. 왜 동일 이벤트를 처리하는데 WAS가 두 개냐고 물었더니 기술 책임자가 화면과 비즈니스를 섞으면 유지보수가 어렵다고 한다. 물론 그렇다. 하지만, 이는 개발 시점 혹은 Development View에서 논할 때 이야기다. 배포 측면(deployment view)에서 프로세스를 나눠서 원격 호출을 해야 하는가는 다른 문제다. 기술 책임자는 필요하면 WAS 인스턴스는 하나로 합칠 수 있다고 했다. 그렇지만, RMI를 쓰지 않고, 로컬에서 호출은 불가능하다고 한다.

'RMI가 좋다'라는 식의 앞뒤 없는 주장을 하기에 답답해서, 설계자 권한에 대해 간섭할 생각은 없으니 되는지 안 되는지 사실만 말해달라고 했다. 아무래도 그 업체와 다시 만나 일을 할 듯하다. 이번엔 상식적인 모습을 보여줄까?

우리 회사도 아닌데 이러쿵저러쿵 이야기할 권한 따윈 없지만, 대한민국 최고의 소프트웨어 기업이라 홍보하고 있다면 격에 맞게 행동했으면 좋겠다.