자바 개발자들이 한자리에 모였다. (JCO 컨퍼런스 후기)

+ 한국 자바 개발자 컨퍼런스(JCO) 에 참가하다.

저는 자바 개발자로 새로운 자바 기술의 흐름과 관련 커뮤니티 행사에 관심이 있습니다. 마침 JCO(한국자바개발자협의회)에서 주최하는 제9회 한국 자바 개발자 컨퍼런스는 자바 관련 컨퍼런스/세미나중 가장 큰 규모로 열리는 행사였기에 이번에 참가하게 되었습니다.

잠깐,
자바란 무엇인가? 어떤 H/W, 어떤 O/S에서도 같은 코드로 실행 가능해야 한다. 라는 개념으로 탄생한 객체 지향 언어로 특히 기업 환경(Enterprise 환경)에 크게 성공하여 공공, 금융, 기업 전산화에 널리 쓰이고 있다.

JCO(Java Community Org), 자바 개발자 역량 향상, 업무 환경 개선등의 자바 개발자를 위해 탄생한 비영리 협의회

한국 자바 개발자 컨퍼런스, JCO에서 자바 개발자를 위해 실질적으로 도움되는 내용들을 공유하기 위해 매년 개최하는 자바 개발자를 위한 컨퍼런스

2004년 신입사원때 JCO 컨퍼런스에 참가하고 오랜만에 참가하게 되었는데요. 그 동안 저는 이런 오프라인 행사를 귀찮아 했습니다. 모든 개발자의 특징은 아니겠습니다만 조용하게 혼자 공부하고 프로그래밍 하기를 좋아하는 저는 오프라인 행사 참가를 귀찮아 했습니다.

그러나 혼자서 노력하는 것보다는 커뮤니티 활동에 적극 참가하여 얻는 것이 훨씬 크다는 것을 깨닫고, 지금이라도 열심히 커뮤니티 행사에 참가하려고 마음 먹던 중, 자바 개발자를 위한 이번 대규모 행사는 꼭 참가 해야 했습니다.

+ 한국 자바 개발자 컨퍼런스(JCO) 행사장 풍경

10시 30분부터 시작되었는데 늦잠 자는 바람에 늦게 가던 중 먼저 도착한 친구로부터 문자가 왔습니다.

“여기 사람 억수로 많다. 된장..”

예상은 했습니다만 도착해보니 대한민국 자바 개발자는 여기에 다 모인 것 같습니다. 무수히 많은 사람들이 정신 없이 움직이고 있었습니다.

이렇게 자바 개발자가 무수히 많다는 것 자체가 저의 시야를 넓혀주는 것 같습니다. 나름대로 긍정적으로 생각하고 주변을 돌아다녔습니다.

[한국 자바 개발자 컨퍼런스 행사장 풍경, 사람이 억수로 많았다.]

+ 한국 자바 개발자 컨퍼런스(JCO) 행사장 풍경, 다양한 관련 업체들이 홍보하다.

행사장 근처에는 다양한 업체들이 기념품을 나눠주며 홍보를 하고 있었습니다. 생각해보니 무수히 많은 자바 개발자가 모이는 오늘 행사야말로 관련 업체 입장에서는 최고의 홍보 기회입니다.

저도 기념품 좀 받으려고 했습니다만 길고 긴 줄의 행렬 속에서 기다렸다가는 강의는 포기해야 될 것 같습니다.

미련 없이 기념품은 포기했습니다.

[다양한 관련 업체들의 홍보, 역시 사람들로 북적였다.]

[행사장에는 타로점도 봐줬다. 타로 전문 블로거 지인인 러브네슬리님이 생각났다.]

+ 한국 자바 개발자 컨퍼런스(JCO) 발표 시작, 서서 듣다.

첫번째 발표가 시작되었습니다. 참가자는 5가지 주제의 트랙중에 하나를 선택하여 들을 수 있었습니다.

그런데 인기 강의와 비인기 강의가 확실히 차이가 나서 인기 강의에 사람들이 몰렸습니다.

* 비인기 강의는 대개 스폰서 업체의 강의다. 실제 도움되는 내용 보다는 은근히 자기 업체 광고를 하기 때문이다.

가뜩이나 사람이 많은데 인기 강의에 사람이 몰리니 저와 지인들은 투덜거리며 다른 강의실로 옮겼습니다. 그런데 그 강의 역시 사람이 많아서 서서들어야 했습니다.

서서 들으면서 생각했습니다. 이 트랙 저 트랙 옮겨 다녔다가는 앉아서 제대로 들을 수 없을 것 같다. 차라리 하나의 트랙만 듣자~

그래서 저는 'Software Engineering' 이라는 주제의 트랙만 계속 듣게 되었습니다.

선택과 포기 전략입니다.

[서서 찍은 사진, 사람이 역시 많다.]

+ Software Engineering 발표 상세 리뷰, 개발자만 보세요.

1. 아키텍트로 가는길

프로그래머란 프로그램 짜는 사람이라고 명확하게 답이 나오는데, 아키텍트라는 단어는 그 해석의 모호함처럼 하는 일도 모호하게 느껴집니다.

그러나 아키텍트란 용어부터 일단 멋있게 느껴지고, 특히 우리나라 힘든 개발환경에서 벗어날수도 있는 일종의 탈출구로 여겨지기 때문에 저는 인기가 있다고 생각합니다.

발표자가 말씀하시는 아키텍트는 성숙기에 접어든 프로그래머가 선택할 수 있는 직업의 하나로 프로젝트 관리자와 하는일은 비슷하기도 히지만, ‘정보 기술’을 책임지고 ‘분석 및 설계 단계 작업’에 집중하는 ‘전체 아키텍쳐’를 기획 하고 관리 하는 사람이라고 하며,

일단 프로그래머의 기본 자세와 능력과 경험을 성실히 향상시킨 다음에, 아키텍트로 갖춰야 될 역량을 습득해야 한다고 말씀하셨습니다.

아키텍트가 전체 ‘아키텍처’를 기획 및 관리한다고 했는데 그럼 아키텍처란 무엇일까요.

* 아키텍처는 추상적인 컴포넌트를 이용하여 시스템을 표현한 것이다. 여기서 추상적이란 표현은 개별적인 컴포넌트들의 상세한 정보는 아키텍처의 대상에 해당되지 않는다.

라고 얘기하고 있는데요. 아키텍처란 정의 자체가 다분히 객체지향적인 요소를 갖추고 있습니다. 그래서 아키텍처를 기획하고 관리하는 아키텍트 역시 객체지향 적인 지식 습득이 많이 필요한 것 같고, 실제로 발표자 께서도 ‘명확한 객체지향 개념 이해’를 아키텍트로 성장하기 위한 중요한 요소로 말씀하셨습니다.

객체지향 기술 습득에 더욱 더 노력해야 겠습니다.

[첫번째 S/W 공학 발표, 아키텍트로 가는 길]

2. 레거시 코드 관리 전략

이번 강의는 okjsp.pe.kr 로 유명하신 kenu님이 발표하셨습니다. kenu님은 자바 개발자 뿐만 아니라 ‘블로거’로 블로그 세상에 폭넓게 참여하시는 분입니다. 그래서 이번에 강의로 뵙고 싶었습니다.

kenu님은 잘생기시고 유머감각도 풍부하셨습니다.

[kenu님의 쇼맨십, 유머감각 풍부하셔서 듣는 개발자들이 즐거워 했다.]

레거시 코드란 몇 년전, 다른 사람이, 구식 기술로 짠 해석하기 힘들고 고치기 힘들고 성능도 나쁘고 유지보수도 고통스러운 코드를 의미합니다.

kenu님은 다양한 방법으로 레거시 코드를 고치는 방법을 소개하셨습니다.

기초적으로, 들여쓰기와 코드 명명 규칙을 알아내고 통일시켜라.

JSP에서는 JSP 코드와 자바스크립트를 분리시켜라.

자바 코드 테스트 할때는 JUnit를 이용하여 테스트 클래스를 만드는데, 이때 테스트할 기능 클래스를 인터페이스로 만들고 이 인터페이스를 구현하는 테스트용 기능 구현 클래스를 따로 만들어서 테스트 하라고 조언하고 있습니다.

사이드 이펙트 관리, 기능을 테스트하는 테스트 케이스의 존재 유무는, 보트를 탔는데 구명조끼를 입은 것과 안 입은 차이라는 비슷한 비유로 테스트 케이스의 중요성을 다시 실감하게 되었습니다.

[두번째 S/W공학 발표, 레거시 코드 관리 전략]

3. S/W 품질요소와 ATAM

발표자께서는 아키텍처 설계를 많이 하셨다고 하는데 자신도 성공시킨 아키텍처는 드물다고 하셨습니다.

초기 아키텍처 설계는 프로젝트의 성공을 좌지우지하는 중요한 요소지만 성공적인 아키텍처 설계는 어렵습니다.

ATAM은 Architecture Tradeoff Analysis Method 라는 아키텍처 검증 방법론 이라고 하합니다.

성공적인 아키텍처 설계 및 검증에 도움이 되는 기술 같습니다.

이 발표에서는 아키텍처와 ATAM 방법론에 대하여 설명했습니다.

[3번째 S/W 공학 발표, S/W 품질요소와 ATAM]

4. 패턴 언어 산책

패턴이란 비슷한 상황에 공통적으로 해결될수 있는 솔루션을 패턴으로 정리한 것이라고 정의해봤는데요. 이렇게 패턴이 모이고 모여서 패턴 관련 기술이 발전되고 있는 것 같습니다.

패턴에는 크게 아케텍처 관점의 패턴과 각 모듈별 디자인 패턴과, 각 상세 기능별 패턴이 존재한다고 합니다.

그리고 이 패턴끼리의 조합(컴파운드 패턴)을 통한 다양한 ‘컴파운드 패턴’의 예를 설명하고 있습니다.

[4번째 S/W 공학 발표, 패턴 언어 산책]

5. 애자일에 대한 7가지 교훈

제가 알고 있는 애자일은 XP(Extreme Programming) 방법론(지속적인 통합, 작은 배포, 짝프로그래밍, 테스트 주도 개발, 주40시간 근무 등)을 실천하다? 로 대략 이해하고 있습니다.

발표자인 김창준님은 XP를 국내에 도입하는데 선구자 적인 분으로 알고 있습니다. 김창준님이 애자일 컨설팅을 하면서 깨달은 7가지 교훈을 말씀하셨습니다.

바로 삼위일체, 품질, 왜 이걸 하는가, 우선순위, 마음의 중요성, 생명의 느낌, 끝없는 길 입니다. 저는 7가지 교훈중에 유독 삼위일체와, 생명의 느낌이 와닿았습니다.

삼위일체란 배움, 즐거움, 성과가 일체되어야 된다는 뜻이었는데 배우는 것과, 즐거움을 얻는 것과, 배움을 실행한 끝에 얻은 성과는 언제나 삼위일체 되야 된다는 뜻으로 이해했습니다.

프로그래밍은 끊임없이 배워야 하고, 그래서 즐거워야 하고, 무엇보다 성과로 나타나야 된다는 것은 제가 회사 생활 할 때 명심해야 될 부분으로 이해했습니다.

그리고 ‘생명의 느낌’은 내가 프로그래밍 하는 결과물을 생명처럼 여기고 소중하게 만들어 나간다는 뜻으로 이해했습니다. 내가 만드는 결과물을 생명 처럼 여기고 성의를 다해 개발한다는 것이야 말로 장인 정신입니다.

삼위일체와 생명의 느낌을 생각하며 개발해야 겠습니다.

[5번째 S/W 공학 발표, 애자일에 대한 7가지 교훈, 그리고 김창준님의 카리스마]

6. 실용주의 개발 환경

작년 오픈소스 컨퍼런스때 들었던 내용인데 또 듣게 되었습니다. 그만큼 제가 개발자의 행복을 위한 개발환경 구축에 관심이 많습니다. 개인적으로 불편한 컨퍼런스 환경에서도 유종의 미를 거두고 돌아올수 있었던 유익한 강의였습니다.

제가 와닿았던 것은 기존의 폭포수 개발 방법에서 린 소프트웨어의 풀 방식 개발 방법론으로의 진화와 CI툴을 이용한 지속적인 통합입니다.

6.1 폭포수 개발 방법 -> 풀 방법

폭포수 개발 할 때 예를 들어 조회, 이체, 대출, 공과금 이 전체 기능이라면 이 전체 기능에 대하여 한 뭉텅이로 보통 요구사항 분석, 분석, 설계, 구현, 테스트 전형적인 절차를 거치게 되는데 변화무쌍한 프로젝트 환경에 대처하기 힘든 낡은 방법론입니다.

그런데 풀 방식은 조회, 이체, 대출, 공과금의 각 기능별로 쪼개서 기능 구축을 고려 합니다.

어떻게 하느냐, 제가 이해한 바로는 예를 들어 조회, 이체, 대출, 공과금 별로 우선순위를 매깁니다.

* 예를들어 1.조회, 2.이체, 3.대출, 4.공과금으로 우선순위를 매겼습니다.

그리고 각 우선순위 별로 설계자가 요구분석을 하고 요구 분석이 끝나는데로 이슈 관리 시스템에 업무 진행 내역을 등록을 합니다. (그 시스템이 이슈 관리 시스템인지는 약간 햇갈립니다.)

특정 시기에 개발자가 이슈 관리 시스템을 보니 설계자가 1.조회, 2.이체, 3.대출에 대하여 설계 단계 까지 마무리 한 상태였습니다.

그럼 개발자가 설계까지 완료된 1, 2, 3을 조회하고 인제~ 1, 2, 3 은 개발하면 되겠구나~ 하며 개발을 진행합니다.

특정시기에 이번에는 테스터가 이슈 관리 시스템을 조회합니다. 조회 결과 개발자가 1.조회, 2.이체에 관하여 개발까지 완료했다고 체크를 했습니다.

그럼 테스터는 1,2번에 대하여 테스트를 수행하고 결과를 이슈 관리 시스템에 등록합니다.

참으로 멋진 방법입니다. 설계자, 개발자, 테스터 간의 각 직군별로 별도의 회의나 문서 전달 없이 자발적으로 유기적으로 개발 프로세스가 시스템화 되어 프로젝트가 진행 될 수 있습니다.

저는 이 풀 방식 개발방법론을 한번 적극적으로 회사에 건의 할 예정입니다.

(그림과 같이 봐야 이해하기 쉬우므로 교재나 추후 공개할 PPT랑 같이 보시길 바랍니다.)

6.2 CI툴을 이용한 지속적인 통합

XP에서 지속적인 통합의 중요성을 얘기하고 있습니다. 별도로 작업하다가 나중에 한꺼번에 통합하는 것이 엄청난 일이라고 알고 있습니다.

CI 툴은 지속적인 통합 툴을 도와 줍니다. 예를 들어 프로젝트 빌드 절차가 SVN Commit -> 기능 JUnit 테스트 -> 배포 라고 하면 CI 툴은 SVN이 Commit 됐는지 주기적으로 확인합니다.

개발자가 CI 환경에서 개발 완료된 소스를 SVN에 Commit하면 CI툴은 자동으로 빌드하고 성공 또는 실패 내용을 메일등의 각종 로깅 기능으로 공지 합니다.

대략 이렇게 이해했는데 CI툴도 따로 공부하여 우리회사로의 도입을 적극 권장 하고 싶습니다.

그 외 메이븐을 이용한 라이브러리 의존 관리 등의 발표 내용은 여러 가지로 유익했습니다.

[6번째 S/W 공학 발표, 실용주의 개발 환경, 도움이 많이 됐다.]

+ 발표가 끝나고, JCO의 행사 진행이 아쉽다.

발표가 끝나고 경품 추첨은 못보고 바로 돌아왔습니다.

지인들이랑 같이 JCO 행사에 갔는데 지인 한명은 두번째 발표 듣자마자 이렇게 말하고 행사장을 떠났습니다.

“사람 너무 많아서 간다. 이것 참 사전등록은 도대체 무슨 의미가 있는지.. 나는 간다.”

지인 한명은 발표 몇 개 듣다가 이렇게 말하고 갔습니다.

“엉덩이도 아프고 더워서 불편해요. 더 이상 못듣겠어요. 먼저 갈께요.”

사람이 너무 많은 것은, 마치 트래픽 예측을 제대로 못해 과부하가 걸려 비상이 걸린 서버실과 같았고, 발표 듣는 주변 환경도 불편했습니다.

자바 개발자를 위해 이런 대규모 컨퍼런스를 개최할 수 있다는 것 자체가 JCO의 큰 역량이고 성과지만 이번 행사에 보였던 몇 가지 문제점은 꼭 보완해야 된다고 생각했습니다.

[컨퍼런스가 끝나고.. 그래도 끝까지 듣기를 잘했다는 생각이 들었다.]

+ 마지막으로 대규모 자바 개발자 행사의 의미를 생각하다.

저는 처음에 주력 언어로 자바를 선택했을 때 과연 자바가 오래 갈 것인가 걱정하기도 했지만 갈수록 발전하고 커가는 자바 세계를 보며 최소한 이런 걱정은 안 해도 될 것 같다는 생각을 했습니다.

* 아마도 자바 세계가 이렇게 발전될 수 있었던 것은 오픈 소스 중심의 개방된 기술 커뮤니티 활동이 활성화 됐기 때문이라고 생각한다.

그리고 자바 세계에는 끊임없는 기본 기술 발전 외에도 JCO처럼 자바 개발자를 위한 다양한 커뮤니티와 행사가 있고, 자바 개발자의 행복을 위한 기술들까지 연구되는 것을 보면서 마음속에 든든함을 느끼고 돌아왔습니다.

앞으로도 자바 세계가 발전되길 바라며, 앞으로도 열심히 자바 기술 습득에 노력 해야 겠습니다.