Home

Toggle Space Navigation Tree
Space Map
Last changed 3월 17, 2010 09:09 by 자바지기
Labels: applicationcontext, parent, child

이번에 Spring Batch에 대한 지원 업무를 하면서 다음과 같은 요구사항이 생겼습니다. 기존에 이미 Quartz를 통하여 구현되어 있는 Batch Job이 이미 존재하는 상태이고, 각 Quartz Job이 실행될 때마다 ApplicationContext을 새로 생성해서 실행하는 구조로 되어 있었습니다. 이렇게 동작하다보니 각 Batch Job 간의 독립성을 보장하기 위한 목적으로는 좋지만 매번 같은 인스턴스를 만들어야 하는 비용적인 부담이 발생하게 됩니다.

왜 이와 같이 관리하느냐고 의아해 하는 분들도 있겠지만 그 때의 요구에 따라서 충분히 만들어질 수 있는 구조라 생각합니다. 이와 같이 독립적으로 실행하고 독립적으로 관리할 경우 Batch Job 간의 의존 관계를 만들려고 해도 만들기 쉽지 않은 구조가 되기 때문에 개발자가 많거나 개발자의 변경이 많은 경우에는 나름 좋은 선택이라고 생각합니다. 물론 개인적으로 이 선택에 찬성하지는 않지만요.

그런데 이 같은 구조를 한번에 모두 바꾸기에는 운영하는 측에서 부담스러워하더군요. 그래서 단계적으로 변경해 가기로 했습니다. 먼저 각 Batch Job에서 공통적으로 사용하는 부분을 서블릿 컨테이너가 시작할 때 WebApplicationContext로 만들어 재사용을 하고 이후 각각의 Batch Job에서 생성한 ApplicationContext와 parent/child 관계를 유지할 수 있도록 만들자는 것이 하나의 안이었습니다. 물론 Quartz와 Spring에 대한 통합도 하지 않고 현재의 구조를 최대한 유지하면서 Spring Batch로 단계적으로 전환하는 전략을 구사하고 있습니다.

물론 처음부터 모두 바꾸는 전략도 좋지만 정말 하고자하는 일이 Batch에 대한 모니터링이 가능한 환경을 구축하는 것이기 때문에 Spring Batch로 전환하는데 집중하기로 한 것입니다. 좋은 전략이라고 생각합니다. 이 시점에 정말 중요한 것은 Batch Job을 통일시키는 것이지 Scheduler를 변경하는 것은 아니기 때문입니다.

이 같은 요구사항을 만족시키기 위하여 ApplicationContext간의 parent/child 관계를 동적으로 만들고 Batch Job이 완료되면 parent/child 관계를 해제해야 상황이 발생했습니다. 이 문제에 대한 해결책을 찾기 위하여 검색해 봤는데 딱히 좋은 해결책이 없더군요. 그 동안 웹 애플리케이션을 개발할 때는 서블릿 컨테이너를 통하여 한번에 ApplicationContext를 생성했기 때문에 딱히 고민하지 않던 문제였으니까요. 그래서 Spring MVC를 사용할 때 parent/child 구조가 발생하기 때문에 가능하다고 생각했죠.

그래서 찾아보게 된 것이 ApplicationContext의 API내에 해결 방법이 있을 듯 하더군요. 그런데 의외로 쉽게 해결책을 찾았습니다. Spring API가 이미 잘 지원하고 있더라고요.

package net.javajigi.ac;

import static org.junit.Assert.assertNotNull;

import org.junit.Test;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class ApplicationContextLoadTest {
  @Test
  public void loadBeanFromChild() throws Exception {
    ClassPathXmlApplicationContext parent = new ClassPathXmlApplicationContext("parent.xml");
    ClassPathXmlApplicationContext child = new ClassPathXmlApplicationContext(new String[] {"child.xml"}, true, parent);
    
    Person person = child.getBean(Person.class);
    Address address = child.getBean(Address.class);
    assertNotNull(person);
    assertNotNull(address);
    child.close();
  }
}

Person과 Address의 초기화와 소멸되는 과정에 로깅을 하고 테스트 진행해 보면 결과를 확인할 수 있습니다. 테스트를 할 수 있도록 나머지 소스도 첨부하면 다음과 같습니다.

Person.java
package net.javajigi.ac;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.stereotype.Component;

public class Person implements InitializingBean, DisposableBean {
  @Override
  public void afterPropertiesSet() throws Exception {
    System.out.println("Person start!!");
  }

  public String getName() {
    return "name";
  }

  @Override
  public void destroy() throws Exception {
    System.out.println("Person end!!");
  }
}
Address.java
package net.javajigi.ac;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

public class Address implements InitializingBean, DisposableBean {
  @Override
  public void afterPropertiesSet() throws Exception {
    System.out.println("Address start!!");
  }

  public String getCity() {
    return "yong in si";
  }

  @Override
  public void destroy() throws Exception {
    System.out.println("Address end!!");
  }
}
parent.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
  <bean id="person" class="net.javajigi.ac.Person"/>
</beans>
child.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
  <bean id="address" class="net.javajigi.ac.Address"/>
</beans>
Posted at 3월 17, 2010 by 자바지기 | 0 comments
Last changed 3월 13, 2010 20:56 by 자바지기

제가 지난 번에 안드로이드 스터디를 진행한다면..이라는 글을 통하여 안드로이드 스터디를 진행해 보려고 생각했습니다. 그래서 스터디에 참여할 의사가 있는 사람들에 대하여 사전 조사를 했고, 저도 안드로이드 책을 통해서 예제를 실행해 봤습니다. 제가 책의 모든 부분에 대하여 실습을 진행해 보지는 않았지만 이 내용으로 스터디를 할 필요가 있을까라는 생각이 들었습니다. 그냥 관심이 있다면 개인적으로 공부해도 충분한 수준이 아닐까라는 생각이 들었습니다.

따라서 안드로이드만을 가지고 스터디를 진행할 경우 주제가 좀 작겠다는 생각이 들더군요. 그리고 과거 스터디에 비하여 활발하게 토론할 수 있는 부분도 많지 않겠다는 생각이 들더군요. 커리큘럼에 대해서는 좀 더 생각해보고 결정하는 것이 스터디의 활성화를 위해서도 좋겠다는 생각입니다. 스터디 신청하신 분들 미안합니다. 좀 더 고민하고 스터디 진행 여부와 커리큘럼 정하도록 하겠습니다.

Posted at 3월 13, 2010 by 자바지기 | 0 comments
Last changed 3월 12, 2010 20:56 by 자바지기
Labels: selenium, continuous, integration, xvfb

2008년 Selenium 기반으로 웹 UI에 대한 테스트 코드를 만들고, UI에 대한 자동화된 테스트 환경을 만들기 위하여 노력했던 기억이 난다. 그런데 2008년에 마지막으로 진행하고 싶었던 부분이 Selenium과 지속적 통합툴(Continuous Integration)과의 통합 작업이었다. 일반적으로 지속적 통합툴은 모니터가 없는 개발 서버이며, 리눅스 환경에서 동작하기 때문에 브라우저를 통해서 테스트를 진행하는 Selenium의 경우에는 지속적 통합툴을 활용하기 힘들었다. 시간적인 여력 때문에 2008년에는 지속적 통합툴까지 연동하지는 않고 필요할 때 로컬 컴퓨터에서 테스트하는 방식으로 진행했다.

한 동안 잊고 지내다가 어제 갑자기 이 숙제에 대한 해결책을 찾고 싶어졌다. 그래서 오랜만에 "Selenium Continuous Integration'을 검색어로 온라인 문서를 찾아봤다. 그랬더니 정말 내가 원하는 해결책을 제시하는 문서들이 많이 보였다. 그렇게 해서 이틀 동안 총 4시간 정도의 시간을 투자해서 성공했다. 이 작업을 위하여 참고한 문서는 다음과 같다.

위 문서를 통하여 리눅스, 유닉스 환경에서 Selenium을 테스트하기 위해서는 Xvfb (X Windows Virtual Frame Buffer)을 사용하면 된다는 것을 알게 되었고, 현재 Ant 버전과 Maven 버전으로 개발이 되고 있다는 것을 확인할 수 있었다. 나는 Maven 플러그인을 활용해서 진행했다.

Headless X11 with Xvfb 문서에 Maven 설정에 대해서는 상세하게 설명이 되어 있어서 쉽게 세팅할 수 있었다. 문제는 Xvfb를 설치하고 설정하는 과정에서였다. 생각보다 쉽게 성공할 수 있었는데 처음에는 로컬에 설치되어 있는 Cygwin에서 Xvfb를 설치하고 테스트를 했는데 자꾸 에러가 발생하고 해결책을 찾는데 많은 시간을 보냈다. 도저희 해결책을 찾을 수가 없어서 Cygwin는 포기하고 자바지기 개발 서버에 다시 세팅하기 시작했다. 그랬더니 Xvfb 세팅이 너무 쉽게 끝나 버렸다. 어제 회식이 있었던 관계로 "설마 그냥 되는 건 아니겠지?"라는 마음으로 회식하러 갔는데 마무리를 하지 못해서 찜찜한 마음이었다. 아침에 출근하자마자 다시 테스트를 위한 빌드 환경을 만들고 테스트를 했는데 바로 성공해 버렸다. Maven을 빌드하면서 Xvfb가 실행되고, Selenium Server Start, Firfox Launch, Test 과정이 흘러가는 모습을 보면서 어찌나 기분이 좋던지..

이제 마지막 남은 한 가지 작업은 소스 코드를 Commit하는 순간 빌드 실행, 컨테이너에 소스 배포를 하면 Selenium Test가 자동으로 실행되도록 하는 부분이다. 이 부분까지 완성된다면 단위 테스트 뿐만 아니라 웹 UI를 통한 통합 테스트까지 완전하게 자동화할 수 있을 것으로 생각한다.

Posted at 3월 12, 2010 by 자바지기 | 0 comments
Last changed 3월 11, 2010 12:03 by 자바지기
Labels: spring, batch, integration, channel

Spring Batch를 기반으로 Batch Job과 Batch 관리툴을 어떻게 만들고 배포하느냐에 관심을 가지다 보니 상당히 다방면에 관심을 가져야겠다는 생각이 든다. 최근에 Spring과 자바 진영의 변화가 얼마나 빠르게 진행되고 있는지 느끼기도 했지만 한편으로는 Spring의 복잡도가 너무 높아져서 쉽게 접근하기 힘들겠구나라는 생각이 들었다. 자바를 처음 접하는 개발자가 힘들어 하듯이 Spring도 그런 상태에 도달했구나라는 생각이다. 물론 내부까지 속속들이 이해하지 않은 상태에서 단지 사용만 한다면 더 쉽고, 편하게 생각하는 개발자들도 있을 듯 하지만 문제가 발생했거나 프레임워크가 제공하지 않는 새로운 형태의 기능을 추가하기 위해서는 내부 구조까지 이해할 필요가 있다. 지금까지는 Spring Batch를 분석하면서 최근에 느낀 점이다. 지금부터 본론으로 들어가보자.

Spring Batch를 분석하다보니 Spring BatchSpring Integration을 통합해서 사용하면 좋겠다는 생각이 들었다. 특히 얼마 전에 올라온 Practical Use of Spring Batch and Spring Integration 문서를 보면 Spring Batch와 Spring Integration을 어떻게 접목해서 사용할 수 있는지 아이디어를 얻을 수 있다. 2009년 SpringOne에서 발표한 Automating Operations with Spring Batch and Spring Integration 동영상을 보면 Spring Batch와 Spring Integration에 대한 내용을 볼 수 있는데 Spring Integration에 대하여 처음 접해서인지 바로 이해가 되지는 않는다. 관심이 있는 사람들은 한번 살펴보면 많은 도움이 될 듯하다.

Spring Batch와 Spring Integration을 통합해서 사용하는 가장 좋은 예제는 현재 개발 진행 중인 Spring Batch Admin 소스를 분석하면 많은 도움이 될 듯하다. Spring Batch와 Spring Integration을 통합하고 있어서 Spring Batch와 Spring Integration에 대한 기본 지식이 없는 상태에서 Spring Batch Admin 소스를 보면 다소 어렵게 느껴질 수 있다. 따라서 먼저 Spring Batch와 Spring Integration에 대한 기본적인 개념과 구조를 이해하고 Spring Batch Admin 소스를 보는 것이 더 빠른 접근 방법일 듯하다.

몇 일간 Spring Batch, Spring Integration, Spring Batch Admin과 관련한 문서와 소스를 보면서 Spring Batch Job을 개발해서 운영할 때 다음과 같은 구조로 운영할 수 있겠다는 생각이 들어 간단하게 정리해 본다.

먼저 Spring Batch 운영에 대한 구조를 이해하기 위하여 Spring Integration의 Service Activator와 Channel Adapter에 대하여 이해해야 한다. 물론 Spring Integration의 다른 개념도 이해할 필요가 있지만 이 글에서는 다루지 않겠다. 더 자세한 내용은 Spring Integration Reference 문서를 참고하기 바란다.

Service Activator
Service Activator는 Input Channel을 통하여 전달된 메시지를 이용하여 Service Instance(우리들은 흔히 이야기하는 비지니스 로직을 담당하는 Object)를 실행하는 역할을 한다.

위 그림에서 보는 바와 같이 Input Channel에 전달된 메시지를 있는지를 확인하고 메시지가 있다면 이 메시지를 이용하여 비지니스 로직을 수행하는 역할을 한다. 만약 Service Instance 영역에서 Return 값이 있다면 Output Channel을 통하여 다른 영역에 전달하는 것이 가능하다.

Channel Adapter
Channel Adapter는 Spring Integration 내에서 사용하는 Message Chnnel과 다른 시스템을 연결하는 역할을 한다. File, HTTP Request, JMS Message에서 전달되는 메시지를 Spring Integration의 Channel Message 형태로 바꾸거나, Spring Integration의 Channel Message를 File, HTTP Request, JMS Message 형태로 변환하는 역할을 한다.

Spring Integration의 위 두가지 개념을 접한 후 Spring Batch Job을 다음과 같은 구조로 운영하는 것이 가능하겠다는 생각이 들었다.

먼저 Batch Job 앞단에 Job-requests라는 Input Channel을 만든다. Job-requests에 메시지가 전달되면 ServiceActivator가 JobLaunchingMessageHandler를 실행하여 각각의 BatchJob을 실행하는 구조이다. 이와 같은 구조로 가져갈 경우 Job-requests Input Channel에 실행하고자하는 Job 이름을 전달하면 각각의 Job을 실행할 수 있는 방식이다.

이와 같이 Job-requests Input Channel을 열어주면 다음과 같이 다양한 방식으로 Batch Job을 실행 및 관리하는 것이 가능하다.

위 그림에서 각각의 상황에 따른 시나리오를 살펴보면 다음과 같다.

1. 특정 디렉토리에 파일이 추가되는 경우 Batch Job이 실행되어 해당 File을 읽어 Batch 작업을 실행해야 한다. 이 같은 요구사항의 경우 주기적으로 특정 디렉토리에 파일이 추가되었는지 모니터링하고 있다가 파일이 추가되면 FileToJobRequestAdapter를 통하여 Spring Integration의 Message 형태로 변화하여 Job-requests Input Channel에 Batch Job 실행을 요청한다.
2. Batch 관리툴에서 관리자가 특정 Batch Job에 대한 실행을 요청한다. Batch 관리툴과 Batch Job이 같은 JVM에서 동작하고 있다면 StringToJobRequestAdapter을 실행한다.
3. Batch 관리툴에서 관리자가 특정 Batch Job에 대한 실행을 요청한다. Batch 관리툴과 Batch Job이 다른 JVM에서 동작하고 있다면 JMS, RMI, Http Adapter를 통하여 실행한다.
4. Quartz, Crontab과 같은 Scheduler에 의하여 특정 Batch Job을 주기적으로 실행한다. Scheduler와 Batch Job이 같은 JVM에서 동작하고 있다면 StringToJobRequestAdapter을 실행한다.
5. Quartz, Crontab과 같은 Scheduler에 의하여 특정 Batch Job을 주기적으로 실행한다. Scheduler와 Batch Job이 다른 JVM에서 동작하고 있다면 JMS, RMI, Http Adapter를 통하여 실행한다.

위 그림은 이해를 돕기 위하여 각 영역의 동작을 최대한 단순하게 그렸다. Batch 관리툴, Scheduler, Batch Job이 서로 다른 영역에서 동작하고 있다면 위 구조보다 훨씬 더 복잡한 구조가 될 가능성이 높다. 위 두개의 그림을 통합하여 하나로 만들어 보면 전체 흐름을 좀 더 명확하게 이해할 수 있을 듯 하다.

위에서 살펴본 바와 같이 Spring Integration의 Channel을 통하여 Batch Job을 Launch, Restart, Stop을 할 수 있도록 한다면 다른 시스템과의 통합을 더 쉽게 가져갈 수 있다. 물론 위와 같은 구조로 운영하는 것은 복잡도를 증가시키는 결과를 가져올 수 있다. 따라서 반드시 위와 같은 구조로 가져갈 필요는 없다. 단지 다른 시스템과 연계하거나 하나의 Batch Job을 다양한 방식으로 운영할 필요가 있는 경우에는 위와 같은 구조로 개발해 유연성을 확보할 수도 있다.

아직 Spring Integration에 대한 이해도 높지 않은 상태라 Spring Batch와의 통합할 경우 이 정도의 통합이 가능하지 않을까 생각해봤다. 앞으로 이해도가 높아지고 실무에 적용사례가 있다면 더 다양한 구조로 개발, 운영하는 것이 가능하리라 생각된다.

Posted at 3월 11, 2010 by 자바지기 | 1 comment
Last changed 3월 09, 2010 21:31 by 자바지기

최근 Spring Batch에 대한 사내 기술 지원 업무를 진행하면서 고민했던 것이 "Batch Job을 어떻게 배포할 것인가?"였다. Batch Job을 잘 개발하는 것도 중요하지만 어떻게 배포하느냐에 따라서도 운영 비용이 크게 차이가 날 수 있기 때문이다. Batch Job을 배포하면서 Batch 모니터링 툴도 어떻게 배포하는 것이 좋을지에 대한 고민도 같이 하게 되었다. 이 같은 고민을 하면서 배포 유형을 어떻게 가져갈 수 있을까에 대하여 정리해 봤다.

  • Batch 관리툴이 있는 경우
    • Batch Job과 Batch 관리툴을 분리하여 운영한다.
    • Batch Job과 Batch 관리툴을 통합하여 운영한다.
  • Scheduler 유형에 따른 경우
    • 시스템 Crontab 기능을 활용한다.
    • Quartz와 같은 Scheduler Framework를 활용한다.
  • Batch Job의 분리 유무
    • 각각의 Batch Job을 분리하여 관리하는 경우
      • 단독 Application으로 만들어서 운영
      • 웹 컨테이너 또는 OSGi 컨테이너 기반으로 운영
    • 각각의 Batch Job을 통합하여 관리하는 경우
      • 단독 Application으로 만들어서 운영
      • 웹 컨테이너 또는 OSGi 컨테이너 기반으로 운영

생각할 수 있는 모든 방법을 고려하다보니 경우의 수가 무지 많다. 위 각각의 방법으로 Batch Job을 관리할 때의 장,단점을 살펴보면 다음과 같다.

Batch Job과 Batch 관리툴 분리 vs 통합

Batch 관리툴이 필요없다면 이에 대한 고려는 필요 없겠지만 Batch 관리툴이 필요한 경우에는 어떻게 운영하는 것이 좋을지에 대하여 고려해야 한다.

Batch Job과 Batch 관리툴 통합

Batch Job과 Batch 관리툴을 통합해서 관리해야 할 경우의 장점은 운영할 때 고려해야 하는 요소가 하나 줄어든다는 것이다. 이와 같이 통합해서 운영하는 경우는 각각의 Batch Job을 독립적으로 운영할 만큼의 대용량 Batch Job이 아니고, 운영을 쉽게 하는 것이 목적인 경우 유용한 접근 방법이다. 따라서 이와 같은 판단을 하는 경우 Batch 관리툴과 모든 Batch Job을 하나의 웹 컨테이너를 통하여 관리하는 경우가 일반적이다.
Batch Job과 Batch 관리툴을 통합해서 운영할 경우 Batch Job과 Batch 관리툴이 의존 관계가 있기 때문에 각각에서 문제가 발생할 경우 다른 영역에 영향을 미칠 수 있다. 또한 Batch Job과 Batch 관리툴에 변경이 발생했을 때 독립적으로 배포하기 힘들다.

각각의 Batch Job의 크기가 작고, 실행에 큰 부담이 없다면 운영의 편의성을 위해서 이 방법을 선택하는 것이 좋을 것으로 생각한다. 특히 Batch Job이 많지 않은 상황에서는 이 방법으로 운영하고 문제가 발생하는 경우 이후 분리하는 것도 좋은 전략이다.

Batch Job과 Batch 관리툴 분리

앞의 통합과는 반대로 독립적인 배포 및 운영이 가능하지만 관리해야할 부분이 늘어나기 때문에 운영 비용이 증가한다. 이 방법은 대량의 Batch 작업을 해야 하는 경우와 Batch Job과 Batch 관리툴의 의존 관계를 만들지 않고자 할 때 선택할 수 있는 좋은 전략이라고 생각한다.

각 Batch Job 분리 vs 통합

각각의 Batch Job을 분리해서 관리하느냐 통합해서 관리하느냐도 앞의 Batch 관리툴의 분리와 통합과 같은 전략으로 접근할 수 있다. 각 Batch Job의 독립성이 중요하고 실행 비용이 크다면 분리하는 것이 바람직한 선택이며, 그렇지 않은 경우에는 통합해서 관리하는 것이 운영 비용을 줄이기 위하여 좋은 선택이 될 수 있다.

Crontab과 Scheduler Framework(예. Quartz)

Batch Job을 실행하기 위하여 Scheduler 기능을 활용해야 하는데 일반적으로 Crontab과 Scheduler Framework를 이용하는 경우가 많다. 각각의 장,단점에 대하여 살펴보면 다음과 같다.

Crontab은 crontab 명령을 이용하여 쉽게 Scheduler를 등록하는 것이 가능하다. 또한 Scheduler와 Batch Job이 분리되어 있기 때문에 Scheduler에 변경이 발생하는 경우 Batch Job과 독립적으로 시간을 변경할 수 있다. 하지만 Batch Job과 같이 관리되지 않기 때문에 서버를 이전하는 경우나 운영 담당자가 바뀌는 경우 누락하는 경우가 많다. Batch 관리툴까지 없는 상태라면 Batch Job이 실행되지 않아서 버그나 장애가 발생하는 경우를 종종 경험한다.

Quartz와 같은 Scheduler Framework는 Batch Job과 같이 소스 코드를 관리하고 배포 단위를 같이 가져갈 수 있기 때문에 Batch Job을 운영하기 위해서는 좋은 선택이지만, 시간이 변경되는 경우 설정을 변경하고 소스를 재배포해야 하는 불편함이 있으며, 개발자가 새로운 API를 익혀야하는 부담이 있다.

하지만 Batch Job을 운영해 본 경험으로 봤을 때 새로운 API에 대한 학습 비용과 소스 코드 재배포에 대한 비용보다는 장애가 발생하지 않도록 운영하는 것이 운영자의 입장에서는 더 중요하기 때문에 가능하면 Crontab 보다는 Scheduler Framework를 활용하는 것이 더 좋은 선택이지 않을까 생각한다.

위와 같이 각각에 따른 장,단점이 있기 때문에 Batch Job과 Batch 관리툴에 대한 배포 전략은 다음과 같이 가져가는 것이 좋지 않을까?

  • 대용량의 Batch Job이 없고, 운영 비용을 줄이는 것이 목적이라면 Batch 관리툴, 모든 Batch Job을 하나의 웹 컨테이너에 배포하여 관리한다. 만약 대용량 Batch Job이 발생한다면 해당 Batch Job에 대해서만 독립적으로 관리한다.
    • Batch Job과 Batch 관리툴을 개발해 보면 각각의 개발 환경이 다른 경우가 많다. 따라서 개발은 모듈로 분리하여 개발하고 배포만 같이하는 전략도 좋은 선택이 될 수 있다.
  • 각 Batch Job 간의 독립적인 배포 및 운영이 중요하다면 각 Batch Job과 Batch 관리툴을 분리하여 배포한다.
  • Batch Job에 대한 Scheduler는 가능한 Quartz와 같은 Scheduler Framework를 활용하고, 각 Batch Job 기준으로 관리하여 분리할 필요가 있을 때 분리하기 용이하도록 한다.

위와 같이 Batch Job과 Batch 관리툴에 대한 배포 전략을 수립하고 나서 좀 더 좋은 방법이 없을까 고민하다가 OSGi 컨테이너인 Spring DM Server에 눈길을 돌리게 되었다. Spring DM Server라면 각 Batch Job별로 Stop, Start, 재배포가 가능하지 않을까 생각하면서 접근하기 시작했다. 이렇게 해서 Spring DM Server에 배포할 Batch Job Bundle을 만들고 삽질을 한 결과 내가 원하는 형태로 배포하는 것이 가능하다는 결론을 얻었다. Spring DM Server에 Batch Job을 배포할 경우 얻게 되는 장,단점은 다음과 같다.

장점

  • 서버 운영 중에도 각 Batch Job 별로 소스를 배포하는 것이 가능하다.
  • 서버 운영 중에 각 Batch Job 별로 Batch의 Stop, Start가 가능하다.
  • Batch Job이 실행 중에 Stop을 실행할 경우 Batch Job이 완료되는 것을 보장해 준다.

단점

  • Batch Job을 OSGi Bundle로 만들어야 하기 때문에 학습 비용이 발생한다.
  • Spring DM Server에 대한 운영 노하우가 없어 이 또한 학습 비용과 경험이 필요하다.
  • 단순한 Batch Job을 개발하는 경우 복잡도가 너무 높을 수 있다.

Spring DM Server를 활용할 경우 좋은 점도 많지만 아직 경험이 많지 않다는 것과 작은 Batch Job까지 OSGi Bundle로 만들 필요가 있을까라는 생각이 든다. 아직 경험이 없는 상태라 그럴 수 있지만 기술적인 욕심 때문에 쉽게 풀 수 있는 문제를 너무 어렵게 접근하는 것은 아닌가라는 의구심을 가지게 되었다.

아직 Spring DM Server에 대한 운영 노하우가 없어 실무에 바로 적용하기는 힘들겠지만 경험이 쌓이고, 운영 노하우가 생긴다면 가져갈만한 전략이라고 생각한다. 현재로서는 Spring Dynamic Module로 개발하는 것이 익숙하지 않기 때문에 많은 삽질을 해야겠지만 경험이 축적되고 모듈 기반으로 개발해 재사용성을 높이는 노하우를 쌓는다면 장기적인 관점에서는 좋은 선택이 되리라 생각한다.

Posted at 3월 09, 2010 by 자바지기 | 7 comments
Last changed 3월 02, 2010 20:59 by 자바지기

올해 책을 100권 읽겠다는 목표를 세웠지만 책 읽는 습관은 어떠해야할까? 글에서 이야기 했듯이 많은 책을 읽기 보다는 한 권의 책을 정독하는데 집중하려고 하고 있다. 그래도 지금까지의 습관이 쉽게 고쳐지지 않는지라 재미있으면 그냥 편하게 읽고 넘어가는 경우가 대부분이다. 단, 책을 읽으면서 나중에 다시 한번 읽으면 좋겠다고 생각하는 책에 표시를 하고 있다.

그 동안 읽어야지 하면서 계속 미루고 있던 책인데 책 두께가 있는지라 생각보다 많은 시간을 걸려서 읽었다. 물론 책의 내용은 체 게바라의 일대기를 다루고 있어서 좋았지만 책 사이 사이에 나오는 상당히 생소한 이름들 때문에 책 흐름을 유지하는데 힘들었다. 특히 등장인물이 많으면 책을 잘 따라가지 못하는데 이 책은 처음부터 끝까지 정말 많은 이름이 등장해 흐름을 끊는 경우가 많았다. 정말 마지막 100페이지는 의무감으로 읽은 듯하다.

그래도 그 동안 체 게바라에 대하여 막연함을 가지고 살았는데 이 책을 통하여 그의 열정적인 삶을 되돌아 볼 수 있는 계기가 되었다. 자신이 생각하는 바를 그대로 행동으로 옮긴 사람.. 자신을 사랑했지만 자신보다 타인을 더 사랑했던 체 게바라.. 몇 일 전에 있었던 사내 강의에서는 그가 남긴 한마디를 다른 이들과 공유할 수 있어 더 좋았다.

우리 모두 리얼리스트가 되자.

그러나 가슴 속에 불가능한 꿈을 간직하자.

나 또한 항상 불가능한 꿈을 꾸며 살고 있지만 현실주의자가 되려고 노력하고 있다.

지난 3일 연휴 때 읽은 두 권의 책이다. 생각했던 것보다 너무 재미있고, 책이 잘 먹어가는 바람에 3일에 걸쳐서 두권을 읽었다. 이 책을 읽으면서 1800년대부터 조선이 일본에게 망하게 된 이유를 이 책을 보면 분명하게 느낄 수 있다. 1800년 즈음이나 지금이나 별반 달라진 것은 없는 듯하다. 어쩌면 그 당시에 영향을 미쳤던 노론 벽파의 영향이 지금까지 우리 사회를 지배하고 있을지도 모른다는 느낌이 든다. 정조가 5년만 더 살았더라면 지금의 역사는 어떻게 바뀌었을까?

이 책을 읽으면서 역사적인 사건에 대해서 알게 된 것도 좋았지만 그 보다 더 피부로 느낄 수 있었던 것은 유배에 대한 생각이다. 유배를 당한 사람에게 있어서 정말 가슴 아픈 일이지만 항상 바쁘게 살아가는 현대인에게 있어서 유배와 같은 생활이 필요한 것은 아닐까? 항상 바쁘게 돌아가는 세상 속에서 현실적으로 돈을 벌기 위하여 일하고 있지만 가끔씩은 조용하게 자신만의 시간을 가지면서 지금까지 공부한 지식을 정리하는 시간을 가질 필요가 있지 않을까? 대학 교수들이 몇 년에 한번씩 안식년을 가지는 것처럼 지식 사회를 살고 있는 지식 노동자에게 있어서도 안식년이 필요하다는 생각이다. 한번 쯤은 자신이 지금까지 쌓은 지식을 정리하고 한단계 성숙시킬 필요가 있기 때문이다. 지금까지 우리가 쌓은 지식은 현장에서 필요한 지식을 익혀 바로 활용하는 것에만 집중했는데 이 같은 지식은 깊이를 쌓는데 한계가 있기 때문이다. 물론 소프트웨어 개발 지식은 빠르게 변하기 때문에 이 같은 시간이 불필요하다고 생각할 수 있지만 소프트웨어의 근간이 되는 핵심 지식은 잘 변하지 않기 때문이다. 이 같은 지식은 지금과 같이 빨리 빨리를 외치는 상황에서는 쉽게 익히기 어려운 지식이며, 습관이다. 이 같은 지식은 많은 삽질과 연구를 통해서 자신의 것으로 만들 수 있으며, 한 단계 성숙시킬 수 있을 것이다. 유배로 인해 정약용과 그 가족의 삶은 힘들고 고닲았겠지만 유배의 삶 속에서 집대성한 지식은 200년 가까이 지나고 있는 지금까지도 영향을 미치고 있는 것이라 생각한다.

Posted at 3월 02, 2010 by 자바지기 | 2 comments
Last changed 2월 23, 2010 22:15 by 자바지기
Labels: 조직구조, 소프트웨어개발회사, 웹서비스

지금까지 두 번의 글을 통하여 조직이 커지면서 생산성이 떨어지는 이유에 대하여 살펴보았다. 첫 번째 글에서는 생산성이 떨어지는 가장 큰 원인이 업무와 조직의 세분화라고 이야기했다. 두 번째 글에서는 이 같은 세분화가 어떠한 문제점을 가지고 있는지는 지난 글에서 다루었다.

그렇다면 소프트웨어 개발 회사는 어떤 형태의 조직 구조와 업무 형태를 가져야할까? 지금부터 내가 생각하는 웹 서비스 소프트웨어 개발 회사의 조직 구조 및 업무 형태에 대한 해결 방법을 제시해보도록 하겠다. 이 해결 방법은 지금까지 나의 경험을 바탕으로 이러한 방향으로 나아가는 것이 바람직하지 않겠느냐는 의견을 제시하는 것이다. 글을 읽으면서 내가 생각하는 방향이 가지는 문제점과 또 다른 대안에 대해서 많은 의견을 주면 좋겠다.

핵심 업무 중심으로 조직이 확대

모든 회사는 회사를 유지하는데 가장 핵심이라고 할 수 있는 업무가 있다. 웹 서비스 소프트웨어 개발 회사라면 회사의 중심에 서비스(또는 프로젝트)가 있을 것이다. 웹 서비스 개발 회사가 성장하면서 급격하게 조직이 커지는데 이 때 중심에 두어야 할 것은 서비스이며, 서비스를 중심으로 조직 구조가 확대된다.

서비스를 중심으로 조직을 확대하다 보면 각 서비스에서 공통적으로 발생하는 문제와 해결책이 빈번하게 발생한다. 이 때문에 업무의 효율화라는 명목과 효율적인 인력 관리를 통한 비용 절감이라는 명목으로 이 업무를 전담하기 위한 조직들이 서서히 등장하기 시작한다.

이 시점이 조직이 커지면서 조직을 재편할 때 가장 중요한 시점이라고 생각한다. 이 시점에 공통 업무를 위한 새로운 조직을 만드는 것에 신중해야 한다. 한번 만들어진 조직을 없애고 새로 재편하기 위해서는 조직을 만들 때보다 몇 배의 비용과 고통이 따르기 때문이다. 이 시점에 조직을 각 업무별로 세분화하고, 공통 작업 단위로 세분화할 경우 발생하는 문제점에 대해서는 앞에서 살펴봤다.

그렇다면 어떤 방법이 가능할까? 나의 관점으로 봤을 때 하나의 서비스를 담당하는 조직이 커지고 공통 업무가 발생한다고 하더라도 서비스의 핵심 업무 단위에 대해서는 세분화하지 않는 전략을 가져가야 한다. 예를 들어 하나의 웹 서비스를 개발하기 위하여 필요한 핵심 업무 단위는 PM, 개발자, 디자이너, DBA, QA라고 판단한다면 이 업무 영역에 대한 세분화는 하지 않는 것이 바람직하다. 또한 각 구성원간의 유기적인 협업이 필요한 경우에도 분리하는 것은 바람직하지 않다. 이 영역에 대한 분리는 신중하게 판단해 마지막 단계에서 분리하는 것이 바람직할 것이다.

조직이 커지면서 조직을 재편할 때 가장 중심에 두어야 한다고 판단하는 부분은 서비스에 중심을 두고 의사 결정을 하는 조직이 만들어져야 한다는 것이다. 조직을 키우더라도 서비스를 중심으로 조직이 커지고, 수직 구조가 만들어 지더라도 서비스를 기준으로 만들어 지는 것이 바람직하다..

서비스 중심으로 조직 구조를 가져갈 경우 각 조직에서 공통적으로 발생하는 문제를 해결하기 위한 방안으로 별도의 조직을 만들고자 하는 경우가 발생한다. 이 같은 요구는 항상 발생하는 것이 아니라 특정 상황에 따라 가끔 발생하는 경우가 일반적이다. 따라서 문제가 발생하는 시점에 해당 문제를 해결하기 위하여 일시적으로 조직(TF 형태)을 만들거나, 만약 공통 문제를 해결하는 상시 조직이 있다면 일정 기간 동안 해당 조직에 참여하여 개발을 진행한 후 원 조직으로 복귀하거나 공통 모듈에 대한 지속적인 지원이 필요하다면 지원 조직으로 남는 형태를 취해야 할 것이다.

예를 들어 A 서비스를 개발하면서 얻게된 지식을 전사적으로 사용하는 것이 좋겠다고 판단된다면 A 서비스에 참여했던 개발자가 사내 프레임워크 개선 조직에 참여하여 해당 기능을 사내에서 범용적으로 사용할 수 있도록 개발하고, 다시 원 조직으로 복귀하는 구조이다.

이와 같이 조직을 유지해야 하는 이유는 지원 업무를 담당하는 조직을 최대한 작은 규모로 유지하기 위해서이다. 지원 업무를 담당하는 조직이 커질 경우 지원 조직은 자체적으로 성과를 만들어야 하는 상황이 발생하는 경우를 종종 본다. 자체적인 성과를 내기 위하여 만들어진 결과물은 실질적으로 각 서비스 조직에서 필요하지 않은 경우가 많다. 그 이유는 지원 조직의 사용자라고 할 수 있는 각 서비스 조직의 요구사항을 수렴하기 보다는 자신의 조직에 성과가 클 것으로 보이는 결과물을 만들어 내기 때문이다. 이와 같이 만들어진 결과물은 서비스에 적용되어야 최종적으로 성과를 낼 수 있다. 따라서 지원 조직은 자신들이 만든 결과물을 서비스에 적용하려는 시도를 끊임없이 시도하게 된다. 이 같은 상황에서 서비스의 목표와 지원 조직의 목표가 충돌하는 상황이 발생한다. 이 같은 상황이 발생하면 어느 조직이 힘이 세냐에 따라서 적용 여부가 결정되는 구조로 치닫게 된다.

따라서 진정 사용자에게 가치를 만들어내는 핵심 업무를 기준으로 조직이 커지는 것이 바람직할 것으로 판단한다. 이 상태에서 특정 문제를 해결하기 위한 지원 조직은 임시 조직으로 유지하거나, 상시 조직으로 유지한다면 최소한의 인력으로 유지하는 것이 바람직하다.

서비스 중심으로 조직이 발전하면 조직 구조가 수직 구조에서 수평 구조로 발전하는 것이 가능하다. 지금까지 국내 거의 모든 회사의 조직 구조는 수직 구조이다. 그러나 수직 구조는 조직이 커지면서 의사 결정자의 단계가 증가하고, 의사 결정자의 수가 많아짐으로써 의사 결정 속도를 더디게 한다. 특히 웹 서비스와 같이 사용자의 요구에 발빠르게 대응하고, 빠르게 변화하는 기술에 대응하기 위해서는 조직이 커지고, 서비스 복잡도가 증가하더라도 빠른 의사 결정을 요구하고 있다. 이 같은 요구에 대응하기 위해서는 수평 구조로 유지하는 것이 더 빠른 의사 결정을 하고 사용자에게 가치를 부여하는 일에 집중할 수 있다.

리소스의 효율적인 사용을 하려면..

각 업무별로 조직 구조를 가져가는 또 하나의 이유는 리소스를 효율적으로 사용한다는 명목이 있다. 한 명의 개발자가 한 서비스를 전담하고 있을 경우 우선 순위가 높은 서비스 또는 프로젝트가 발생했을 때 유연하게 대처하기 힘들다는 것이다. 또 하나는 HTML 마크업이나 디자인 작업과 같이 한 서비스에 100%를 투입할 작업 분량이 되지 않는 경우이다. 이 같은 상황에 대응하기 위하여 업무 단위로 조직을 분리하는 것이 효율적인 리소스 관리가 가능하다고 생각한다.

첫 번째 우선 순위가 높은 서비스에서 새로운 프로젝트가 발생했을 때 어떻게 하면 유연하게 대처할 수 있을까? 업무 단위로 조직을 분리한다고 해서 이 문제를 해결할 수 있을까? 나는 없다고 생각한다. 업무 단위로 조직을 분리하더라도 새로운 업무가 발생하면 똑같은 상황이 발생한다. 따라서 내가 생각하는 해결책은 다음과 같다.

먼저 각 서비스별로 조직 구조를 만들고, 서비스를 운영, 개선하기 위하여 상시적으로 필요한 인원의 적정 규모가 어느 정도인지를 결정한다. 인원 규모는 서비스를 운영하면서 어느 정도가 적정 수준인지를 판단하는 것이 바람직하다. 이와 같이 상시 업무를 담당하기 위한 인원을 제외한 사람들은 별도의 인력풀처럼 관리한다. 이 인력풀에 속해 있는 사람들은 우선 순위에 따라서 자신이 하고 싶은 서비스 또는 프로젝트에 참여하여 업무를 진행하는 방식을 취한다.

인력풀이라고 이야기하니 SI 할 때의 인력 시장과 같은 것 아니냐고 부정적으로 생각하는 사람들도 많이 있다. 하지만 내가 생각하는 인력풀은 인력 시장과는 다르다. 인력풀에 속해 있는 사람들은 자신이 원하는 서비스 또는 프로젝트를 선택할 수 있는 권한을 주고, 서비스 또는 프로젝트가 완료되면 상시 업무를 진행할 것인지, 새로운 서비스 또는 프로젝트를 진행할지에 대한 선택권을 주어야 한다.

한 서비스에서 안정적으로 상시 운영 업무를 하는 것에 따른 장,단점이 있듯이, 인력풀에서 계속해서 새로운 업무를 맡게 되는 사람들에게도 충분한 보상이 주어져야 할 것이다. 예를 들어 하나의 프로젝트가 완료되었는데 바로 다른 프로젝트에 투입하는 형태처럼 하나의 부속품처럼 취급되는 것이 아니라 하나의 프로젝트를 완료하면 자신의 역량을 개발할 시간과 쉴 수 있는 여유 시간에 대한 보상이 뒤따라야 할 것이다.

또한 이 같은 구조를 지속적으로 유지하고 성장시키기 위해서는 서비스 조직, 인력풀 조직, 지원 조직 사이에 유기적인 업무 순환이 있어야 한다.

두 번째는 각 서비스에 한명에게 할당할 업무가 100%가 되지 않는 경우이다. 따라서 한 명이 여러 개의 서비스에 참여해야 효율적인 활용이 가능할 것으로 생각한다.

그런데 정말 이와 같이 관리하는 것이 리소스를 효율적으로 사용하는 방법일까? 한 측면으로 본다면 맞는 맞일 수 있겠지만, 별도의 조직을 만들어 조직을 관리하고 유지하는 비용을 생각한다면 이 또한 만만치 않은 비용이 발생한다. 또한 조직이 분리됨으로써 발생하는 협업 비용 또한 고려해야 할 것이다. 그렇다면 어떻게 하는 것이 합리적인 방법일까? 나 또한 이 부분에 대하여 명확한 해결책을 제시하기는 힘들지만 조직을 분리하는 것만이 좋은 해결책은 아니라고 생각한다.
이상적이기는 하지만 내가 생각하는 첫 번째 해결책은 가능한 한명이 하나의 서비스를 담당하도록 하는 것이다. 한 명이 여러 개의 서비스나 프로젝트를 담당하는 것은 서비스나 프로젝트 간의 이동 비용이 발생하기 때문에 한 명이 여러 개의 서비스를 담당하는 것은 효율적인 방법은 아니다. 하지만 동시에 여러 개의 서비스를 담당하는 상황이 아니라면 괜찮다고 생각한다. 한 명이 여러 개의 서비스를 담당하지만 시간 상으로 겹치는 부분이 많지 않다면 충분히 효율적인 작업이 가능하리라.

각 업무에 대한 역량 강화는?

업무 단위로 조직을 분리하는 이유 중의 하나는 역량을 강화하기 위한 목적이라고 이야기한다. 그런데 정말 업무 단위로 조직을 분리하면 전체적인 역량이 강화될까? 개인의 역량을 강화하는 것이 조직 구조에 따라 달라질까? 물론 일정 부분 영향을 미칠 수 있겠지만, 개개인의 역량 향상에 가장 큰 영향을 미치는 것은 자신의 역량을 강화하기 위한 개인의 노력이다. 개인의 노력이 부족한 사람은 어떤 형태의 조직이 되더라도 큰 효과는 볼 수 없으리라.

업무 단위로 조직을 분리할 경우 오히려 자신의 업무에 대한 이해도와 지식은 높아질 수 있겠지만, 다른 업무에 대한 지식과 이해도는 상당히 낮아지는 것을 느낄 수 있다. 최근 전문화라는 이유로 업무를 세분화해서 자신의 분야에만 관심을 가진다면 이것이 진정 전문가로서 성장할 수 있는 길일까? 진정 전문가로서 성장하려면 자신의 전문 분야 지식도 필요하지만 이와 더불어 서비스(또는 프로젝트)의 전반적인 모습을 같이 볼 줄 알아야 하며, 다른 분야에 대한 지식과 이해도도 필요하다고 생각한다. 그렇게 되었을 때 다양한 분야에 대한 고려가 가능할 것이기 때문이다. "사용자의 입장은 고려하지 않고, 자신의 전문 분야에 빠져 역량만 강화하고 있다면 이것이 진정 전문가의 올바른 길일까?"라는 의구심을 가져본다.

업무 단위로 조직을 분리하던 서비스 단위로 조직을 분리하던 개인의 역량을 강화한다는 것은 쉽지 않은 일이다. 진정 회사가 개인의 역량 강화를 통하여 전반적인 품질 향상을 바란다면 멘토링을 적극 활용하고, 이와 같은 멘토링에 대해서는 개인 성과와 역량에 반영하여 모든 구성원이 적극적으로 참여할 수 있도록 해야 한다. 국내 대부분의 회사를 보면 개인 역량을 강화하고, 교육을 하는 것이 정말 중요하다고 이야기하지만 실상을 보면 신입 사원을 키우고 사원의 역량을 강화하는데 인색한 것이 사실이다. 정말 개개인의 역량 강화가 서비스 품질 향상에 중요하다는 판단을 한다면 단기적인 성과 위주의 전략이 아니라 장기적으로 인내심을 가지고 정책을 펴야할 것이다. 개인의 역량 강화는 단기간에 비용을 투자한다고 해서 해결되는 것이 아니다.

평가는 어떠해야 하는가?

앞의 글에서도 잠시 언급했지만 서비스 기반으로 조직 구조를 가져갈 경우 평가는 서비스 단위로 하는 것이 바람직하다. 하나의 서비스에 여러 업무가 혼재되어 있기 때문에 각각의 개인을 평가하는 것이 힘들 뿐더러 팀워크를 위해서 좋지 않은 방법이다. 업무에 대한 성과는 개인이 아니 서비스를 기준으로, 서비스 지원 조직은 서비스에 대한 기여도를 기준으로 평가하는 것이 바람직할 것으로 판단한다. 물론 내가 생각할 때 평가는 개인이나 조직에 대한 동기 부여 효과는 크지 않을 것이라 생각하지만 그래도 해야 한다면 개인보다는 조직 단위로 하는 것이 불합리한 부분을 최소한으로 줄일 수 있다고 생각한다.

개인에 대한 평가는 개인의 역량에 대한 평가가 되어야 한다. 서비스 기반 조직이고 수직 구조에서 수평 구조로 조직 구조를 유지한다면 과거처럼 좀 더 높은 관리자로 올라가는 것이 승진의 개념이 될 수 없다. 수평 구조에서는 상위 조직장으로 올라가는 것이 의미 있는 것이 아니라 자신의 역량 레벨을 높이는 것을 승진의 개념으로 보아야 할 것이다. 각 업무별 역량에 대한 기준을 세우고 이 기준에 따라서 개인별로 역량 레벨을 평가하는 방식이 되어야 할 것이다.

피터 드러커는 프로페셔널의 조건에서 조직에 대한 공헌의 세 가지 영역에 다음과 같이 이야기하고 있다.

'공헌'은 여러 가지를 의미한다. 모든 조직은 세 가지 주요 영역에서 성과를 올리 필요가 있다. 1) 직접적인 결과를 산출하고, 2)가치를 창출하고 재확인하며, 3)인재를 육성하는 것이 그것이다. 만일 이 세 가지 영역 가운에 어느 하나라도 성과를 달성하지 못한다면, 그 조직은 썩어서 없어지고 말 것이다. 그러므로 조직에 몸담고 있는 모든 지식 근로자의 공헌 활동은 이 세 가지 영역과 연결되어 있어야만 한다. 한편 세 영역의 상대적인 중요도는 조직의 필요에 따라 그리고 지식 근로자 개개인에 따라 상당히 많이 달라진다.
– 피터 드러커, 프로페셔널의 조건 중에서..

위 글에서 피터 드러커가 이야기하고 있듯이 지식 근로자를 평가하고 판단할 때 세 가지 측면에서 회사에 대한 기여도를 판단해야 할 것이다. 하지만 많은 회사에서 "1)직접적인 결과를 산출하고"에 해당하는 직접적인 성과에만 집중하는 경향이 있다. 이와 같이 성과에만 집중하게 되면, 회사 전반적인 분위기가 단기적인 성과에만 집착하게 되는 경향이 있다. 또한 성과 위주의 평가가 우선시되는 많은 조직을 보면 서비스를 안정적으로 운영하는 것보다 새로운 기능을 추가하는 것에 더 큰 가치를 부여하는 경향이 있다. 새로운 결과물을 만들어 내는 것이 성과 측면에서는 더 큰 성과로 보이기 때문이다. 하지만 이 같은 현상은 결과적으로 고객의 목소리에 귀기울이기 보다는 각 조직의 성과에 이익이 되는 업무를 우선시하는 경향이 발생하게 된다. 따라서 조직과 개인을 평가할 때 직접적인 성과 뿐만아니라 "2)가치를 창출하고 재확인하며, 3)인재를 육성" 부분에 대한 기여도 고려해야 할 것이다.

지식 근로자인 우리는 어떻게 대응해야 하는가?

내가 위에서 제시하는 형태로 조직 구조를 가져갈 경우 지금까지 일하던 방식과 다르기 때문에 많은 부분에서 혼란스러움을 느낄 수 있다. 이 같은 변화에 대응하기 위하여 우리 지식 근로자들은 어떻게 대응해야 할까?

지금까지 수직 구조에서는 위에서 시키는 일만 열심히 하고, 조직이 움직이는 데로 따라가기만 하면 되는 수동적인 자세를 가지고 있는 것이 사실이었다. 하지만 수평 구조로 변경된다면 지금보다는 좀 더 적극적으로 자신의 의견을 개진하고, 자신의 역량을 강화하기 위하여 더 많은 노력을 해야할 것이다.

이 같은 노력은 회사를 위한 것이 아니라 결과적으로 우리 자신을 위한 것이다. 좀 더 효율적으로 일함으로써 더 좋은 품질의 서비스를 만들어 회사에 기여하는 바도 크지만 궁극적으로 우리가 시간적인 여유를 가질 수 있으며, 이런 여유 시간을 통하여 좀 더 재미있고, 의미 있는 일들을 해나갈 수 있을 것이기 때문이다.

마치며..

지금까지 세 번에 걸쳐서 글을 작성했다. 이 번 글에서 제시하고 있는 것처럼 조직 구조를 바꾸고, 평가 제도를 개선한다고 지금까지 비효율적이었던 부분이 곧바로 효율적인 구조로 바뀐다고 생각하지 않는다. 내가 세 번의 글을 통하여 이야기하고 싶었던 것은 업무 세분화, 전문화로 인해 비효율적인 부분에 대하여 다룬 것 뿐이다. 업무와 조직을 너무 세분화하는 것은 많은 문제점을 가지고 있기 때문에 신중해야 한다는 것이며, 새로운 방법으로 접근할 수도 있다는 것이다.

실질적으로 업무의 효율화와 생산성을 극대화하기 위한 더 좋은 방법은 바로 우리 개개인의 마음 가짐이다. 어떤 조직 구조를 가지던, 어떤 평가 체계를 가지던 간에 같은 목표와 비전을 가지고 업무에 임할 수 있다면 크게 중요하지 않다. 각 조직의 성과 위주가 아니라 정말 사용자에게 가치를 만들어 내는 것에 집중할 수 있는 환경이라면 어떤 조직 구조라도 상관 없다. 하지만 이런 상태를 유지하는 것은 쉽지 않다. 특히 조직이 커지면서 이와 같은 초심을 유지하는 것은 더더욱 힘들어지게 된다. 이런 상황에서 좀 더 사용자 지향적이고, 목표 중심적인 조직 구조 형태가 어떤 것인지에 대하여 언급했다.


이 글은 내가 포털 회사에 4년 간 몸담고 있으면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 이 글의 내용은 포털과 같이 하나의 소프트웨어를 지속적으로 관리하고 성장시켜 나가야하는 소프트웨어 개발 회사에 도움이 될 듯하다. 나는 지금까지 웹 에이전시, SI 회사에 몸담은 경험이 더 많은데 웹 에이전시, SI와 같이 특정 회사에 업무 의뢰를 받아 단기간에 개발을 완료해야하는 조직에는 적합하지 않을 수 있다.

이 글의 내용은 내가 몸담고 있는 조직의 의견과는 무관하다. 지금까지 소프트웨어 개발 업무를 진행하면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 내가 이 글을 쓰는 가장 큰 이유는 내가 잘못 판단하고 있는 부분도 많을 것이기 때문에 그에 대한 의견을 받아보고 더 바람직한 모습에 대한 논의를 해보고자 함이다.

논리적으로 타당하지 않거나 근거가 부족하다고 생각하는 부분에 대해서는 가차없이 의견 마구마구 날려주기 바란다.

Posted at 2월 23, 2010 by 자바지기 | 6 comments
Last changed 2월 23, 2010 20:40 by 자바지기
Labels: , 모바일, 아키텍처, spring, roo, rest, html, xml, json

나는 아키텍처를 깊이 있게 공부하지도 않았으며, 깊이 있는 고민을 한 것도 아니다. 프로젝트를 시작하거나 각각의 상황에 따라서 어떤 모습이 좋을까를 고민하는 형태라고 할까? 물론 대형 프로젝트를 주도해서 개발한 경험이 없기 때문에 아키텍처가 얼마나 중요한 것인지 피부로 느끼고 있다고 이야기할 수도 없다. 하지만 아키텍처에서 정말 중요한 것은 처음에 만들어진 아키텍처는 시간의 흐름에 따라서, 시장의 상황에 따라서 변화 발전해야 한다는 것이다. 최근의 아이폰 열풍이 불면서 모바일 환경에 대한 관심이 높아지고 있는 현 시점이 새로운 아키텍처에 대한 고민을 해야 하는 시점이 아닌가 생각한다.

최근 GWT, Spring Roo, Rest에 대하여 고민하다보니 다양한 방식의 아키텍처가 가능할 수 있겠다는 생각이 든다. 더불어 웹 뿐만 아니라 모바일까지 고려한 소프트웨어 개발에 대하여 고민할 때라고 생각한다. 물론 웹과 모바일을 동시에 고려하지 않는 단독 애플리케이션이라면 상관 없겠지만 대부분의 웹 애플리케이션이 모바일을 고려할 것으로 생각한다. 과거에는 모든 거래가 오프라인을 통하여 이루어졌지만 지금은 오프라인 + 온라인(웹 주도), 온라인(웹 주도) 형태로 발전했지만, 앞으로는 오프라인 + 온라인(웹 + 모바일), 온라인(웹 + 모바일), 온라인모바일) 형태로 발전할 가능성이 크기 때문이다. 기존에 웹 주도의 온라인 회사들이 큰 비용 없이 모바일 환경을 지원할 수 있느냐가 현재 온라인 회사들의 생사를 결정 지을 수도 있을 듯하다. 물론 초반에 상당한 비용을 들여서 모바일 환경을 지원할 수 있겠지만 뒤따르는 유지보수 비용을 고려한다면 초반 아키텍처가 중요할 것이다. 초반에 제대로 된 아키텍처를 가져가지 않을 경우 막대한 유지보수 비용을 치를 수 밖에 없을 것이다. 사실 이런 내용을 아키텍처라고 이야기하는 것이 맞는지 모르겠지만 적절한 단어가 생각나지 않아서 사용한 것도 있다.

지금까지 국내 대부분의 온라인 애플리케이션은 웹이라하는 하나의 클라이언트를 고려해서 개발해왔다. 이 같이 하나의 클라이언트를 고려하는 상황에서도 상당한 유지보수 비용을 지불하고 있는데, 웹과 다양한 모바일 환경을 고려해야 하는 상황이 되면 이 때 발생하는 중복코드와 유지보수 비용은 생각하기도 끔찍하다. 어쩌면 이 같은 환경 변화로 인해서 아키텍처, 설계, 품질에 대한 중요성이 부각될 수도 있겠지만 이를 느끼고 실행하는 회사는 얼마나 될 것인지 의문이다. 만약 다양한 클라이언트 환경을 고려한다면 해당 서비스의 핵심 도메인에 집중해야 할 것이다.

핵심 도메인 영역을 얼마나 정교하게 개발하느냐에 따라서 새로운 클라이언트가 추가되더라도 큰 변화 없이 대응할 수 있을 것이다. 그렇다면 핵심 도메인 영역을 어떻게 다양한 클라이언트에 제공하는 것이 좋을까? Spring Roo를 적용하면서 Rest 방식에 관심을 가지고 문서를 찾다보니 Restlet, a RESTful middleware for GWT, GAE and Android 문서를 보게 되었다. Restlet, a RESTful middleware for GWT, GAE and Android 문서에서 얻은 아이디어와 Spring MVC 3.0부터 지원하고 있는 ContentNegotiatingViewResolver API를 결합해 사용한다면 다음과 같은 형태로 다양한 클라이언트를 지원하는 것이 가능할 것이라는 생각이 들어 테스트를 진행해 봤다.(ContentNegotiatingViewResolver에 대한 더 자세한 사용 방법은 Spring 3.0 Web MVC and JSON) 문서에서 확인할 수 있다.)

첫 번째 방법은 외부와 통신하는 핵심 도메인 Controller는 하나이고, 요청 URL의 확장자에 따라 다른 데이터를 제공하는 형태이다.

두 번째 방법은 외부와 통신하는 핵심 도메인 Controller는 하나이고, 요청 Content Type에 따라 다른 데이터를 제공하는 형태이다.

테스트한 결과는 예상하는 데로 지원할 수 있겠다는 생각이다. 물론 실무에 적용하면서 많은 문제에 봉착하겠지만(벌써 Spring Roo를 적용하면서 문제가 생겨 해결책을 찾았다.) 그런 문제들이 하나씩 해결해 나가면 될 것이다.

위 두가지 모두 외부와 인터페이스를 위한 Controller는 하나이지만 확장자와 요청 Content Type에 따라 다른 데이터를 제공하기 때문에 중복 코드를 만들지 않고 다양한 클라이언트와의 통신이 가능하다. 물론 이 같은 구조가 가능하기 위해서는 각 Controller 뒤에 잘 만들어진 핵심 도메인이 존재해야 할 것이다.

물론 모든 API를 위 구조로 통일하는 것이 힘들 것이다. 하지만 대부분의 API(90%는 되지 않을까? 너무 긍정적인가?)는 위와 같은 구조로 개발하는 것이 가능할 것이다. 기능에 따라 예외적인 경우가 발생한다면 예외적인 상황이 발생하는 부분에 대해서만 Controller를 분리하면 될 것이다. 클라이언트 수가 증가할 때마다, 요구사항이 기존과 조금 다를 때마다 새로운 Controller를 추가한다면 중복 코드가 발생할 가능성이 높으며, 유지보수 비용 또한 증가할 것이다.

새로운 클라이언트가 추가되고, 새로운 요구사항이 발생하더라도 최대한 중복 코드를 만들지 않고, 하나의 API를 이용하여 요구사항을 만족시키도록 노력해보자. 그래도 해결 방법이 없다면 그 시점에 추가하는 것이 적절한 선택이 되리라. 이 같은 방식으로 접근하는 것이 장기적으로 개발자의 삶에 여유를 가져다 줄 수 있는 환경이 될 것이라 확신한다. 현재의 편함을 위해서 미래의 불편함을 만드는 오류는 범하지 말았으면 좋겠다.

Posted at 2월 23, 2010 by 자바지기 | 0 comments
Last changed 2월 22, 2010 18:10 by 자바지기
Labels: 독서

3개월간 독서 통신 신청해 진행하고 있는데, 대부분의 책이 비슷한 내용이라 좀 재미가 없고 따분하다는 생각이 들었다. 그래서인지 이번 달에는 마감을 임박해서야 책을 읽고 있다. 역시나 먼저 읽은 한 권의 책은 큰 의미를 가지지 못하고 읽었다. 그런데 "세상을 가질 수 있는 사람 없는 사람"은 나에게 많은 것을 느끼게 해주고 있다. 새해를 맞아 새롭게 세웠던 계획과 마음가짐은 조직 개편과 몇 가지 상황에 부닥치면서 물거품이 되었는데 이 책으로 인해서 다시 한번 되돌아 볼 수 있는 계기가 되었다.

이 책을 읽으면서 다시 한번 나의 목표를 검토해봐야겠다고 생각한 부분이 있어서 공유해 본다. 올 해 나의 목표 중에 하나는 책 100권 읽기이다. 지금까지 틈 날때마다 책을 읽고 있어서 100권이 가능할 듯도 하다. 그런데 이 책에 독서와 관련하여 다음과 같은 내용의 글을 읽고서 나의 책 읽는 습관을 다시 한번 되돌아 보게 되었다.

이 책에서는 독서에 대하여 다음과 같아야 한다고 이야기하고 있다.

첫째는 책을 읽기 시작하면 끝까지 읽을 것,
둘째는 책을 완전히 이해하기 전엔 다 읽었다고 생각하지 말 것,
셋째는 온 정신을 기울여 읽으라는 것이다.

위 세 가지 중에서 잘 지키고 있는 습관은 첫째이다. 둘째와 셋째는 영 꽝인 듯하다. 책을 제대로 이해하지도 못하면서 10권, 100권을 읽는 것이 중요할까? 단 한권이라도 제대로 이해하는 것이 더 중요하리라. 그러기 위해서는 책을 읽을 때 맑은 정신으로 온 정신을 집중해 읽는 것이 중요하리라.

소프트웨어 관련 서적 또한 똑같다. 배우고자하는 기술과 관련한 서적을 읽는다고 해서 그 기술을 사용할 수 있는 것은 아니리라.

PS. 이 책이 쓰여진 시대는 19세이다. 그럼에도 불구하고 지금 시점에 읽을 만한 충분한 가치가 있는 책이다. 단점이라면 번역서에 오타가 너무 많다.

Posted at 2월 22, 2010 by 자바지기 | 3 comments
Last changed 2월 18, 2010 22:07 by 자바지기
Labels: spring, roo

2월 1일자로 조직 개편이 되면서 프로토타이핑을 담당하는 조직을 맡게 되었다. 새롭게 진행하는 업무가 기획자의 요청에 따라 발빠르게 프로토타이핑을 할 수 있어야 하기 때문에 최대한 빨리 대응할 수 있는 기반을 만들기 위한 준비 작업을 하고 있다. 처음 개발 작업을 위한 기반 프레임워크로 Ruby on Rails, Grails, Spring Roo 세 개가 물망에 올랐다. 각각에 대하여 개발 편의성, 학습 비용, 프로토타이핑 팀 개발자 및 사내 개발자들의 지식 수준, 향후 실 프로젝트에 적용할 때의 적용 가능성 등을 고려해서 Spring Roo로 진행하기로 잠정적으로 결정하고 준비하고 있다. 이에 대한 더 자세한 내용은 같이 일하고 있는 꿈꾸는 개발자님이 더 자세하게 부연 설명 해주리라 생각한다.

직접적인 기반 준비 작업은 꿈꾸는 개발자님이 진행하고 있지만, 옆에서 지켜보면서 느끼는 Spring Roo에 대한 감정은 일단 긍정적이다. 우리는 Spring Roo의 UI 관련 기능은 제외하고 Entity 영역만 사용하기로 결정했다. 포털의 성격상 UI에 대한 변화나 요구가 많고, Spring Roo를 통하여 생성되는 JSP가 만족스러운 수준은 아니었다. Spring Controller까지 자동 생성하고 싶었지만 Ben Alex에게 문의한 결과 Controller만 단독으로 생성할 수는 없다고 한다. Spring 3.0으로 버전업 하면서 @MVC가 잘 만들어져 있어 Controller 만들기는 어렵지 않게 해결하고 있다. 이후 이 작업이 귀찮으면 Controller만 생성할 수 있는 add-on을 하나 만들어도 좋을 듯 하다.

Spring Roo를 적용하면서 가장 만족할만한 부분은 코드 생성 방식이다. Introduction To Spring Roo 1.0.0 문서에서도 설명하고 있지만 Passive Generation과 Active Generation을 모두 지원하고 있다는 것이다.

이 같은 코드 생성 방식은 roo shell을 이용하여 소스 코드를 생성하는 것도 가능하지만, 도메인 모델 클래스를 직접 변경하더라도 관련된 aj 소스가 자동으로 변경되는 것을 확인할 수 있었다. 예상하지도 못했던 부분까지 고려해서 개발되었다는 것을 보고서 놀라지 않을 수 없었다. 이 같은 기능을 지원하기 때문에 JPA Annotation과 Validation Annotation만 알고 있다면 굳이 roo shell을 사용하지 않고 도메인 모델 클래스에서 직접적인 수정이 가능하다. 이 같이 동작하는 방식에 대해서는 Spring Roo 1.0.0 Technical Deep Dive 문서에서 좀 더 구체적으로 파악할 수 있다.

아직 add-on까지 만들어 보지 못하고 Spring Roo에서 제공하는 샘플 add-on 프로젝트를 생성하고 배포해 봤는데 생각보다 쉽게 개발할 수 있을 듯 하다. 이미 add-on을 쉽게 개발할 수 있도록 roo shell에서 샘플 프로젝트까지 제공하고 있어 이 프로젝트를 참고해서 만든다면 어렵지 않게 개발하는 것이 가능하리라.

이 참에 지난 번에 만들었던 Spring Batch Monitoring System을 Spring Roo 기반으로 만들어보면 어떨까라는 생각을 했다. "Spring Batch Log야 단순 조회용도니까 지금처럼 Spring Jdbc 기반으로 개발하면 되고, 그 외의 User, Role, 통계 기능에 대해서는 Spring Roo를 적용가능하지 않을까?", "기존 Legacy Project에 Spring Roo를 적용하기 어렵지 않을까?"라는 생각으로 시도해봤는데 생각보다 쉽게 Spring Roo를 통합할 수 있었다. 물론 아직까지 기존 Legacy 테이블까지 매핑해서 개발하는 단계까지는 가지 않았지만 기존 Legacy Project에 쉽게 통합해서 일부만이라도 Spring Roo 기반으로 개발하는 것이 가능하다는 것을 확인할 수 있었다. Spring Roo에서 강조해서 이야기하고 있듯이 Spring Roo는 상당한 유연성을 가지고 있다는 생각이 들었다.

아직 프로토타이핑 업무에 직접 적용한 단계는 아니고 준비 단계이지만 만족할만한 수준이라고 생각한다. 사내 프로토타이핑 업무와 Spring Batch Monitoring System에 적용해 나가면서 Spring Roo의 허와 실에 대해서 지속적으로 공유해보도록 하겠다.

Posted at 2월 18, 2010 by 자바지기 | 2 comments
Last changed 2월 18, 2010 09:18 by 자바지기
Labels: 안드로이드, 스터디

최근에 아이폰, 안드로이드폰이며 모바일 환경에 급격한 변화가 일고 있다. 지금 같은 추세라면 모바일 환경이 기존의 웹 시장을 무너트릴 기세이다. 하지만 생각하는 것만큼 너무 부풀려지는 감이 없지 않다. Yes24나 강컴과 같은 온라인 서점은 보면 아이폰, 안드로이드폰과 관련한 개발 서적이 베스트 10안에 들어와 있는 것을 보면 소프트웨어 개발 업계 종사자에게 얼마나 많은 관심사가 되고 있는지 알 수 있다.

이 같은 변화의 흐름 속에 소프트웨어 개발 회사들은 모바일 어플에 집중하고 있는 것이 사실이다. 기존에 자신들의 핵심 서비스에 집중하기에도 여력이 부족한데 모바일 어플에 대한 분산 투자라.. 기존에 세워져 있던 우선 순위 또한 뒤죽박죽되고 있는 현실이다. 정말 이렇게까지 해야할까? 정말 지금과 같은 시점에 우리 개발자들은 무엇에 집중해야 할까? 이런 고민을 안고서 스터디를 진행해볼까 한다.

이런 관점에서 봤을 때 아이폰이냐 안드로이드폰이냐는 중요하지 않다고 생각한다. 필요하다면 그 시점에 준비해서 진행해도 될 터이다. 소프트웨어 개발에 있어서 진정 중요한 것은 유행을 따라가는 것이 아니라 핵심에 집중하는 것이다. 아이폰, 안드로이드폰 개발자 급구 글을 통해서 많은 것을 느낄 수 있다고 생각한다.

내가 생각하는 스터디의 방향은 단순히 스터디에서 안드로이드에 대한 기술적인 부분만을 이야기하고 싶은 생각은 없다. 현재와 같이 스마트폰이 이슈인 현재 시점에 개발자인 우리에게 정말 필요한 것이 무언인지에 대한 논의도 해보고(물론 안드로이드 어플도 만들어 보겠죠.) 더 깊이 있는 논의를 하고 싶다. 이런 방향으로 스터디를 진행한다면 참석하고자 하는 사람들이 있을까? 현재 아이폰 스터디도 진행하기 위해서 준비하고 있는데 동시에 두개의 스터디를 진행하는 것도 좋은 생각일 듯하다. 관심이 있는 분들은 덧글을 남겨주면 좋겠다. 어느 정도의 관심이 있는지 살펴보고 스터디의 진행 여부를 결정할 생각이다.

1. 자신의 직군 => 기획자, 개발자 등등
2. 경력
3. 기타 의견

위 세가지 내용으로 덧글을 남겨 주면 앞으로 스터디의 방향을 정하는데 많은 도움이 될 듯하다.

Posted at 2월 18, 2010 by 자바지기 | 10 comments
Last changed 2월 23, 2010 22:15 by 자바지기
Labels: 업무세분화, 조직세분화, 평가

지난 글에서는 개발자(프로젝트에 참여하는 모든 구성원을 통칭한다.)는 증가하지만 개발 생산성이 향상되지 않는 가장 큰 원인은 "업무가 세분화되고, 세분화된 업무 단위를 기반으로 조직 구조가 만들어지는 것이다."라는 이야기를 다루었다. 이번 글에서는 업무 단위를 기반으로 조직이 만들어질 경우 생산성 저하와 발생 가능성이 있는 문제점에 대하여 살펴보도록 하겠다. 문제점의 우선 순위는 파급효과가 큰 부분을 먼저 다루도록 하겠다.

급격하게 증가한 협업 비용

소프트웨어 개발 과정에서 업무를 세분화할 경우 가장 큰 문제점은 협업 비용이 급격하게 증가한다는 것이다. 이에 대한 가장 큰 원인은 앞 글에서 인용했던 Pete McBreen의 글을 통하여 확인할 수 있다. 다시 한번 인용해본다.

소프트웨어 개발에 있어서 작업을 세분화하고 분업화할 때 작업이 더 작은 단계로 세분화될수록, 한 사람에서 또 다른 사람으로 정보를 전달하는 데에 더 많은 시간이 걸린다. 생산라인 접근 방식은 수작업 노동에는 잘 맞을 수 있다. 그러나 지적인 작업에는 형편없이 실패한다.

소프트웨어 개발은 팀원들의 머리에서 일어난다. 사람들을 특정 활동에 전문화시킴으로써 간단한 프로젝트의 딜리버리도 여러 경로를 통해야 한다. 각 경로는 실수와 결함에의 잠재성을 갖고 있는 값비싼 과정이다.

  • Pete McBreen, 소프트웨어 장인 정신

Pete McBreen의 말처럼 업무를 세부화할 수록 한 사람에서 다른 사람에게 정보를 전달하는데 많은 비용이 발생한다. 특히 각 업무를 맡고 있는 담당자의 Context가 다른 경우 그 비용은 더 커진다. 비용을 좀 더 구체적으로 살펴보면 다음과 같이 구분할 수 있을 듯 하다.

  • 다른 파트에 정보를 전달하기 위한 문서화 및 문서에 대한 유지보수 비용
  • 각 파트간에 정보를 공유하기 위하여 발생하는 회의비용
  • 다른 파트에서 정보가 넘어오기를 기다리면서 소요되는 비용
  • 정보를 잘못 이해함으로써 원하는 형태의 결과물이 나오지 않음으로써 발생하는 비용

위에서 살펴본 네 가지 이외에도 많은 비용이 발생하게 된다. 위 네 가지 비용 중에서 가장 큰 문제가 되는 경우는 네 번째일 것이다. 잘못된 요구사항 파악 및 구현으로 인하여 추가적으로 발생하는 유지보수 비용은 상당히 클 것으로 생각한다.

한 서비스(또는 프로젝트)를 여러 단위로 나뉘어 프로젝트를 진행할 경우 이와 같이 비용이 발생한다. 이 상태에서만 보아도 많은 비용이 발생하고 있는데, 각각의 업무 단위로 조직이 만들어질 경우 추가적인 비용이 또 발생하게 된다.

서비스(또는 프로젝트)가 개인 단위에서 조직 단위로 진행할 경우 각 조직의 성과와 정치적인 목적까지 개입하게 된다. 그러면서 추가적으로 발생하는 비용은 다음과 같은 부분이 있을 수 있다.

  • 각 조직의 프로세스에 따라서 업무를 요청하고 업무를 진행한다. 새로운 프로세스를 익히고, 요청 문서를 많드는데 비용이 발생한다.
  • 원할한 리소스 관리를 위하여 각 조직에서는 전체적인 리소스를 관리하기 위한 관리자가 필요한 상태가 된다.
  • 조직이 물리적으로 분리되어 있는 경우가 일반적이기 때문에 협업을 위하여 이동, 전화, 이메일 작성에 비용이 소요된다. 이 같은 비용은 결과적으로 협업 횟수를 줄임으로써 요구사항을 잘못 이해하고 개발함으로써 추가적인 비용을 발생하게 한다.
  • 서비스(또는 프로젝트)의 목표와 각 조직의 목표가 충돌하면서 추가적인 비용이 발생한다. 이 부분에 대해서는 잠시 후에 추가적으로 살펴보도록 하겠다.

이와 같이 업무 단위를 세부화화면서 업무 단위로 만들어진 조직까지 개입하게 되면 하나의 서비스(또는 프로젝트)를 진행하기 위하여 발생하는 협업 및 추가적인 비용은 급격하게 증가하게 된다. 이는 결과적으로 많은 사람을 투입했지만 생산성을 떨어트리는 결과를 가져온다.

원할한 리소스 관리를 위하여 각 조직에서는 전체적인 리소스를 관리하기 위한 관리자가 필요한 상태가 되면 여러 곳에 많은 관리자가 생겨나게 된다. 이와 같은 상황이 지속되다보면 가슴 아픈 이야기이지만 나 혼자 삽질하고 있는데 수 많은 관리자가 구경하면서 간섭하는 현상까지 발생한다. 즉, 고객의 가치를 위하여 일하는 시간과 사람보다 가치를 만들어내지 못하는 시간과 사람이 많아지게 된다.

이 같은 문제점을 해결한다는 명목하에 새로운 프로세스(방법론)가 도입되고, 값 비싼 도구를 구입하지만 결과적으로 실패하게 된다. 가장 큰 원인은 원론적인 부분을 해결하지 않은 상태에서 임시 방편의 해결책이기 때문이다. 이와 같은 상태의 가장 좋은 해결책은 업무 관련자들이 최대한 가까운 공간에서 일할 수 있도록 해야 하며, 각 조직의 정치적인 목적을 최대한 배제한 상태가 되어야 한다. 하지만 각 조직의 성과와 조직 관리를 해야 하는 입장에서는 쉽지 않은 선택이다.

조직의 목표와 서비스(또는 프로젝트) 목표와의 충돌

서비스의 목표는 고객에게 가치를 부여하면서 고객과 서비스가 같이 성장해 나가는 것이리라. 무슨 기술을 사용하고 방법론을 사용했느냐가 중요한 것이 아니라 서비스가 생존하는 것이 우선적인 목적이기 때문이다. 이를 실현하기 위해서는 서비스의 목표를 세우고 그 목표에 따른 우선 순위를 정하고 작업을 해나가는 것이 효율적인 방법이리라.

그런데 업무 단위가 세분화되고, 더 나아가 조직까지 세분화되어 있는 상태에서는 가장 중심에 있는 서비스의 목표와 각 조직의 목표가 충돌하는 상황이 발생한다.

목표가 충돌할 경우 각 조직의 목표보다 서비스 목표가 우선시 되어야 하지만 많은 경우 각 조직의 목표를 우선시 하는 상황이 발생할 가능성이 있다. 이 상태에서 평가 권한까지 서비스(또는 프로젝트)에서 가지고 있는 것이 아니라 각 조직에 부여되어 있을 경우 더 이상 서비스 성공이나 목표가 중요한 것이 아니다. 각 조직의 성과를 내기 위한 조직의 목표를 맞추는 것이 더 중요한 상태가 되어 버린다.

이 같은 상태가 되면 서비스에 대한 우선 순위를 조정하기 힘들 뿐만 아니라 고객에게 가치를 줄 수 있는 부분보다는 각 조직에 성과를 내는 데 집중하게 됨으로써 서비스의 품질은 점진적으로 떨어지는 결과를 초래하게 된다. 이는 장기적으로 서비스에 큰 위험요소로 작용한다.

서비스 목표와 각 조직의 목표가 충돌하고, 조직의 세분화가 지속될 경우 대부분의 조직이 "프로젝트가 서쪽으로 간 까닭은?"에서 이야기하는 아드레날리 중독증에 빠진 상태가 될 가능성이 높다.

다음은 아드레날린 중독증에 걸린 조직이 보이는 특징이다. 아마 익숙하리라.

  1. 우선순위가 계속 변한다.
  2. 어제까지 모든 결과물이 나왔어야 했다.
  3. 시간이 언제나 부족하다.
  4. 모든 프로젝트가 긴급하다.
  5. 긴급한 프로젝트가 계속 쏟아진다.
  6. 모두가 언제나 미친 듯이 바쁘다.

이런 조직에서 일하는 사람들은 전략적으로 사고하지 않는다. 무조건 긴급한 업무부터 처리한다. '긴급도'가 낮은 프로젝트는(장기적인 이익이 보장되어도) 일단 무시한다. 그러다가 갑자기 급해지면 그제야 돌아본다. 아드레날린 중독증에 걸린 조직은 계획보다 전력 질주가 최선의 방법이라 믿는다.

  • 톰 드마르코, 팀 리스터외 지금, 프로젝트가 서쪽으로 간 까닭은

모든 개발자들이 바쁘게 일하고, 열심히 일하고 있지만 생산성은 떨어지고, 개발자는 지속적으로 더 필요한 상태가 된다. 이 상태에서 개발자를 더 충원한다고 개발자의 삶이 나아질 수 있을까? 오히려 더 바빠지면 바빠졌지 나은 상태가 되지 않을 것이다. 왜? 이 상태에서 개발자를 충원하는 것이 원론적인 해결책이 아니기 때문이다. 하지만 아드레날린 중독증에 대해서는 조직 구조 개편이나 새로운 관리자로 대체한다고 해결할 수 있는 쉬운 문제가 아니다.

조직은 응급 상태가 아닐 때 가장 효율적이라는 사실을 인정하는 관리자가 필요하다. 하지만 이런 인력 교체는 거의 불가능하다. 흔히 조직이 미친 듯이 바쁘기를 바라는 사람은 경영진이나 CEO이기 때문이다. 그들은 회사가 미친 듯이 바빠야 잘 돌아간다고 믿는다. 회사 경영진이 아드레날린 중독증에 걸렸다면 프로젝트 팀들도 금방 따라 걸니다.

  • 톰 드마르코, 팀 리스터외 지금, 프로젝트가 서쪽으로 간 까닭은

경영진이나 CEO가 자진해서 변할 수 있을까? 이 같은 문제점을 이야기할 수 있는 사람은 몇 사람이나 될 것이며, 이야기한다고 진실되게 들을 수 있는 경영진은 얼마나 될까? 이에 대한 대답은 글쎄올씨다가 맞을 듯 하다.

공정한 평가를 하기 힘들다.

평가를 공정하게 한다는 것은 사실 불가능한 일이다. 평가와 인센티브는 오히려 하지 않는 것이 지식 근로자에게 있어서는 더 나은 선택이 아닐까 생각한다. 왜냐하면 지식 근로자의 업무를 정량적으로 판단하기 힘든 부분이 대부분이기 때문이다. 특히 소프트웨어 개발 업무는 정량화하기 더 힘든 영역에 속한다. 많은 사람들이 정량화를 시도하고 있지만 그 내면을 보면 대부분이 정성적인 사실이다. 따라서 평가를 아무리 잘 하더라도 불만이 나올 수 밖에 없다.

그런데 조직 구조가 세분화되어 있고, 여러 조직이 하나의 프로젝트에 투입되는 상황에서 평가를 어떻게 해야할까? 만약 서비스 또는 프로젝트의 PM에게 평가 권한을 준다면 PM은 각 업무에 대한 이해도가 있어야 하며, 각 업무에 대한 난이도와 품질에 대한 기준도 알고 있어야 할 것이다. 다른 대안은 각 업무 조직에게 평가 권한을 위힘하는 경우이다. 이 경우에는 팀원들이 각 프로젝트에서 어느 정도의 기여를 했는지를 판단해야 할 것이다. 이 경우 잘못할 경우 프로젝트에 대한 기여보다는 각 조직에 어느 정도의 기여를 했는지에 따라서 평가가 진행될 수 있다. 이럴 경우 앞에서 이야기한 것처럼 프로젝트 목표보다 조직의 목표를 우선시 하는 부작용이 발생한다.

어떤 방식을 취하더라도 문제가 있을 수 있으며, 이 두가지 방법을 조합해서 평가를 한다고 하더라도 조직장의 기준에 따라서 평가 기준이 달라질 수 밖에 없다. 평가에 대한 정답은 없다. 하지만 위와 같이 많은 문제점을 가진 상태라면 오히려 평가와 인센티브 지급이 생산성을 높이는 것이 아니라 저하시킨다. 이 상태라면 인센티브는 동일하게 지급하고, 평가는 개인의 역량을 강화하기 위한 목적으로 진행하는 것이 훨씬 더 효율적일 것이다.

이 글에서는 업무와 조직을 세분화할 경우 발생할 수 있는 문제점에 대하여 살펴보았다. 이 같은 문제점은 사람을 꾸준히 늘리더라도 생산성이 높아지는 것이 아니라 떨어트린다. 소프트웨어 개발회사에서 이 같은 문제점은 일정 수준 규모에서 급격하게 사람을 늘릴 경우 발생할 가능성이 높은 현상으로 판단된다.

지금까지 두편의 글에서 원인과 문제점에 대하여 살펴보았다. 그렇다면 "네가 생각하는 해결책은 뭔데?"라는 질문을 던질 것이다. 다음 글에서는 내가 생각하는 해결책에 대하여 다루도록 하겠다.


이 글은 내가 포털 회사에 4년 간 몸담고 있으면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 이 글의 내용은 포털과 같이 하나의 소프트웨어를 지속적으로 관리하고 성장시켜 나가야하는 소프트웨어 개발 회사에 도움이 될 듯하다. 나는 지금까지 웹 에이전시, SI 회사에 몸담은 경험이 더 많은데 웹 에이전시, SI와 같이 특정 회사에 업무 의뢰를 받아 단기간에 개발을 완료해야하는 조직에는 적합하지 않을 수 있다.

이 글의 내용은 내가 몸담고 있는 조직의 의견과는 무관하다. 지금까지 소프트웨어 개발 업무를 진행하면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 내가 이 글을 쓰는 가장 큰 이유는 내가 잘못 판단하고 있는 부분도 많을 것이기 때문에 그에 대한 의견을 받아보고 더 바람직한 모습에 대한 논의를 해보고자 함이다.

논리적으로 타당하지 않거나 근거가 부족하다고 생각하는 부분에 대해서는 가차없이 의견 마구마구 날려주기 바란다.

Posted at 2월 11, 2010 by 자바지기 | 8 comments
Last changed 2월 23, 2010 22:14 by 자바지기
Labels: 전문화, 세분화, 분업화, 생산성, 업무, 프로페셔널의조건

푸켓 여행 기간 중 프로페셔널의 조건(자기 실현편)이라는 책을 읽었다. 책을 읽기 시작할 때부터 나의 관심을 끄는 내용으로 시작하더니 끝까지 흥미진진하게 읽을 수 있었다. 현재의 나의 모습을 되돌아 볼 수 있는 기회도 제공해 주면서 앞으로 내가 나아갈 방향으로 제시해 주고 있다. 특히 지식 근로자의 생산성에 대하여 다루는 부분이 특히 좋았다.

내가 몸담고 있는 소프트웨어 개발자 또한 지식 근로자 중의 한 분야이기 때문에 더 많은 부분에서 공감할 수 있었다. 지식 근로자의 생산성과 앞으로 나가야할 방향에 대하여 많은 숙제를 안고 휴가에서 복귀한 시점에 CSO님이 사내 관리자를 대상으로 진행했던 강의 동영상을 볼 수 있었다. 강의를 듣다가 CSO님이 던진 질문의 원인과 해결책에 대한 내 나름대로의 생각을 정리하기 위하여 지금까지 고민했던 내용을 적어본다.

CSO님이 던진 질문은 다음과 같았다.

"개발자가 부족하다고 해서 몇 배의 개발자를 충원했다. 그런데 개발자 리소스는 항상 부족하다고 한다. 개발자가 충원되었음에도 불구하고 개발 생산성은 높아지지 않은 것 같다."

먼저 위 질문에서 개발자에 대한 정의가 필요할 것으로 생각한다. 내가 보는 관점에서 위에서 이야기한 개발자는 우리들이 흔히 이야기하는 프로그래머를 의미하는 것이 아니라 프로젝트에 참여하는 프로젝트 구성원으로 보는 것이 타당할 것으로 생각한다. 해외의 경우에는 프로젝트에 참여하는 구성원의 대부분이 개발자일 가능성이 높겠지만 국내 웹 서비스 개발 회사는 많은 업무로 나뉘어 개발이 진행되고 있기 때문에 이들을 통틀어 개발자로 보는 것이 맞을 것으로 생각한다.

이 질문에 대하여 지금 몸담고 조직에 있으면서 느꼈던 내용을 바탕으로 내가 생각하는 방향을 정리해보고자 한다. 물론 내가 지금 회사를 경영하는 경영자는 아니지만 효율적인 조직을 만드는 방법에 대해서 많은 관심을 가지고 있었기 때문에 내 나름대로의 원인과 해결책을 가지고 살아왔다. 몇 번의 포스팅을 통하여 이 내용을 다루어 보도록 하겠다. 이 글에서 다루고 있는 내용이 내가 몸담고 있는 조직에 국한된 것이 아니라 소프트웨어 개발을 하고 있는 많은 조직에서 발생하고 있는 현상이리라 생각한다. 어쩌면 소프트웨어 개발 조직 뿐만 아니라 앞으로 점점 지식 근로자가 많아지는 회사에서 경험하게 될 현상이 될 수도 있다고 생각한다.

자 그럼 이제 본격적으로 이야기를 시작해보자.

소프트웨어 개발은 다른 분야에 비하여 역사가 길지 않기 때문에 생산성 향상을 위한 방법을 다른 분야의 성공 사례를 도입하여 적용하는 것이 현실이다. 그 중 대표적인 예가 제조업의 경험으로부터 분업화와 자동화를 도입하려는 시도가 많았다. 또한 제조업, 건축 분야로부터 모듈화를 통한 재사용 가능한 컴포넌트화에 대한 시도가 그것이리라. 이 글에서는 자동화와 모듈화를 통한 생산성 향상에 대해서는 언급하지 않았다. 이 글에서는 제조업 분야로부터 도입한 분업화에 대하여 언급하고자 한다.

프로페셔널의 조건에 나오는 내용을 보면 다음과 같은 내용이 나온다.

작업은 연구될 수 있고 분석될 수 있으며, 또한 작업은 일련의 간단하고도 반복적인 동작으로 나눌 수 있다는 것 - 즉 작업에서의 각 동작은 하나의 옳은 방법으로, 주어진 시간 내에, 알맞은 도구를 사용하여 수행될 수 있다. - 테일러의 주장

테일러의 주장에 의한 훈련 방식을 도입한 국가들의 생산력은 거의 50배 가까이 증가하였는데, 이 놀라운 생산력 증대야말로 모든 선진 국가에서 생활 수준과 삶의 질을 월들히 향상시킬 수 있었던 근원이었다.

  • 피터 드러커, 프로페셔널의 조건 1장 일부 발췌 및 정리

위 인용문의 테일러의 주장은 한마디로 말해서 모든 작업을 분석하여 세분함으로써, 단순화할 수 있고, 짧은 기간의 훈련만으로 '일류 기술자'를 만들어 낼 수 있다는 것이다. 이 주장은 제조업 분야에는 적중했으며, 이로 인해 생산성 혁명이 가능하게 되었다.

이와 같이 제조업에서의 비약적인 생산성 향상은 새롭게 등장한 소프트웨어 개발 분야에서도 매력적일 수 밖에 없었다. 하지만 제조업에서 성공적이었던 이 방법이 소프트웨어 개발에 있어서는 성공하지 못하고 있는 듯하다. 그 이유에 대하여 Pete McBreen은 다음과 같이 이야기하고 있다.

소프트웨어 개발에 있어서 작업을 세분화하고 분업화할 때 작업이 더 작은 단계로 세분화될수록, 한 사람에서 또 다른 사람으로 정보를 전달하는 데에 더 많은 시간이 걸린다. 생산라인 접근 방식은 수작업 노동에는 잘 맞을 수 있다. 그러나 지적인 작업에는 형편없이 실패한다.

소프트웨어 개발은 팀원들의 머리에서 일어난다. 사람들을 특정 활동에 전문화시킴으로써 간단한 프로젝트의 딜리버리도 여러 경로를 통해야 한다. 각 경로는 실수와 결함에의 잠재성을 갖고 있는 값비싼 과정이다.

  • Pete McBreen, 소프트웨어 장인 정신

소프트웨어 개발에 있어서 작업을 세분화할 경우의 문제점에 대하여 설계 작업과 개발 작업을 분리할 경우 발생할 수 있는 한계점을 다루고 있는 다음 글을 읽어보면 많은 부분에서 공감할 수 있을 것이다.

소프트웨어 개발에 있어 세분화, 분업화로 인하여 얻을 수 있는 한계가 있다는 것을 알고 있지만 아직도 많은 소프트웨어 개발회사는 제조업의 생산성 향상 방식을 도입하고 있다. 이와 같이 변화하게 되는 과정을 살펴보면 다음과 같다.

회사가 성장하는 초기 단계에는 각 서비스(또는 프로젝트)별로 업무를 세분화하여 프로젝트를 진행한다. 물론 이 시점에 업무가 세분화되어 있지만 문제가 될 정도로 세분화되어 있는 상태는 아니다. 조직 구조 또한 서비스(또는 프로젝트)를 기준으로 분리되어 있는 경우가 많다. 회사가 성장하는 단계에 있어서 일정 수준의 분업화와 조직 구조는 크게 문제가 되지 않는다. 하지만 회사가 성장하고 조직이 커지면서 전문화와 효율화를 해야 한다는 이유로 각 업무별로 조직 구조가 바뀌고, 업무는 점점 더 세분화되어 간다. 이 같은 논리는 다분히 과거의 제조업에서의 생산성 향상에 대한 경험에 기반을 두고 있는 것으로 판단된다.

예를 들어 초기 단계에서는 다음 그림과 같이 업무 분석가(또는 기획자), 개발자, 디자이너, DBA(선택) 정도로 시작하는 경우가 많다.

시간이 지나면서 서비스가 성장하고 회사의 규모가 커질수록 각 프로젝트에 참여하는 역할은 세분화된다. 이에 대한 요구는 각각의 업무에 대한 전문성을 강화하기 위한 일환으로 진행된다. 전문화함으로써 소프트웨어의 품질을 향상시킬 수 있으며, 생산성 또한 높아질 것이라는 판단 때문이다.

이와 같이 프로젝트 하나를 진행하기 위하여 여러 개의 업무로 나누어지고, 각각의 업무를 담당하는 구성원들은 점점 더 증가한다. 시간이 지나면서 각각의 업무 담당자들은 자신과 같은 업무를 하고 있는 동료와 같은 조직에서 일하는 것이 자신의 실력을 향상할 수 있으며, 전문성을 더 강화할 것이라 생각한다. 이 같은 생각이 확대되면서 자연스럽게 각 업무는 하나의 조직으로 만들어지게 된다. 이와 같이 각각의 업무가 조직으로 바뀌게 되면서 프로젝트를 진행하기 위하여 관여하는 구성원이 한 개인이 아니라 조직(대표적으로 팀)이 되어버리는 상황이 발생한다.

많은 개발자를 충원했지만 개발 생산성이 향상되지 않는 가장 큰 원인에 대하여 내가 내린 결론은 앞에서 본 바와 같이 업무 단위를 너무 세분화, 분업화했기 때문이다. 업무 단위를 세분화하면서 조직 구조가 각 서비스(또는 프로젝트) 단위로 구성되었다면 좀 더 효율적이었을 것이라 생각한다. 하지만 조직 구조까지 업무 단위로 재편되면서 개발 생산성은 급격하게 떨어지게 된다. 업무 단위가 조직 구조로 변경되는 초기 단계에는 기존에 진행하던 업무 방식이 남아 있기 때문에 큰 변화는 없거나 오히려 각 업무 단위가 전문화 되면서 생산성이 향상된다는 착각을 할 수 있다. 하지만 더 큰 문제는 업무 단위 기반의 조직이 점점 더 탄탄해 지면서 발생하게 된다.

이번 글에서는 소프트웨어 개발 회사에서 개발자는 지속적으로 충원되지만 개발 생산성이 높아지지 않는 이유에 대하여 나의 생각을 정리해봤다.다음 글에서는 업무 단위를 기반으로한 조직이 점점 더 탄탄해지면서 발생할 수 있는 문제점에 대하여 살펴보도록 하겠다.

PS. 개발자가 늘어남으로 인해서 생산성이 떨어지는 이유는 이 이외에도 무수히 많을 것으로 생각한다. 이 글에서 내가 선택한 원인은 여러 개의 원인 중에서 가장 큰 원인이라고 생각하는 부분에 대하여 다루었다. 이후에 기회가 된다면 더 많은 원인에 대하여 이야기해보고 싶다.


이 글은 내가 포털 회사에 4년 간 몸담고 있으면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 이 글의 내용은 포털과 같이 하나의 소프트웨어를 지속적으로 관리하고 성장시켜 나가야하는 소프트웨어 개발 회사에 도움이 될 듯하다. 나는 지금까지 웹 에이전시, SI 회사에 몸담은 경험이 더 많은데 웹 에이전시, SI와 같이 특정 회사에 업무 의뢰를 받아 단기간에 개발을 완료해야하는 조직에는 적합하지 않을 수 있다.

이 글의 내용은 내가 몸담고 있는 조직의 의견과는 무관하다. 지금까지 소프트웨어 개발 업무를 진행하면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 내가 이 글을 쓰는 가장 큰 이유는 내가 잘못 판단하고 있는 부분도 많을 것이기 때문에 그에 대한 의견을 받아보고 더 바람직한 모습에 대한 논의를 해보고자 함이다.

논리적으로 타당하지 않거나 근거가 부족하다고 생각하는 부분에 대해서는 가차없이 의견 마구마구 날려주기 바란다.

Posted at 2월 09, 2010 by 자바지기 | 5 comments
Last changed 2월 08, 2010 20:47 by 자바지기

그 동안 me2daytwitter를 할까 말까 고민하다가 오늘부터 me2day를 시작했다. 사실 개설한지는 1년이 다 되어간다. 오늘 들어가서 보니 개설 날짜는 2009년 2월 12일이다. 조금만 더 참았으면 딱 1년이 되는 시점에 시작할 수 있었는데.. 개설하게 된 이유는 1년 전에 같이 일하는 동료가 두명의 친구를 끌어들이면 스타벅스 커피를 공짜로 먹을 수 있다는 속임에 빠져서 개설했는데 알고 보니 추천했던 그 친구에게만 커피가 있었고 나한테 떨어지는 건 아무 것도 없었다.

어딘지 모를 배신감을 느꼈지만 그래도 javajigi 아이디를 미리 선점할 수 있는 기회는 되었다. 내가 마이크로 블로그를 시작하지 않은 이유는 지금까지 마이크로 블로그이 의미있는 컨텐츠일까에 대해서 많은 의구심을 가져왔고, 필요성을 느끼지 못했다. 그런데 최근 me2daytwitter의 흐름을 보면 비동기이지만 실시간성 커뮤니케이션 채널로 유용하게 사용되는 모습을 보면서 나 또한 관심을 가지게 되었다. 더불어 글쓰는 사람들간의 부담 없는 의사소통은 토론을 싫어하는 국내 환경에서 다소 의미가 있지 않을까라는 생각이 들었다. 물론 팀을 옮기고 개발에 대한 관심 뿐만 아니라 기획에 대한 관심도 생기면서 자연스럽게 사용해봐야겠다는 생각도 하게 되었다.

친구들을 찾기 위해서 이리 저리 찾고 있는데 쉽지 않다. 나를 알고 있는 친구들 중 미투하고 있는 친구들 있다면 친구로 초대 좀 해줬으면 좋겠다. 아직 미투 초보라 어떻게 사용해야 되는지 막막한 상태이다. 이러다 미투에 빠져서 iphone도 지르고, 이 커뮤니티도 방치하는 것은 아닌지 모르겠다. 아무쪼록 과용은 금물..

내 미투 주소는 http://me2day.net/javajigi이다. 많은 분들과 친구로 지냈으면 좋겠다.

Posted at 2월 08, 2010 by 자바지기 | 0 comments
Last changed 2월 06, 2010 12:12 by 자바지기
Labels: 선대인, 100분토론, 전문가

나는 경제 현안이나 부동산에 대한 정보를 얻기 위하여 종종 다음에 개설되어 있는 김광수경제연구소포럼 카페에 들른다. 이 연구소를 좋아하는 이유는 자신들이 분석한 내용을 국가나 특정 기업의 눈치를 보지 않고 솔직하게 전달하고 있다고 판단되어 신뢰감이 가기 때문이다. 오히려 지금 정부나 기업들이 싫어할 말들만 골라서 한다고 해도 좋을 듯하다.

어제 이 카페에 잠시 들렀다가 카페에서 케네디언이라는 별명으로 활동하고 있는 선대인 부소장이 MBC 100분 토론에 참석했다는 소식을 접하게 되었다. 최근에 TV도 없고, 손석희 아나운서도 자리에서 물러나면서 100분 토론을 보고 싶은 마음은 없었는데 자주 들르는 카페에서 활동하는 분이 참석했다기에 다시 보기를 통해서 100분 토론을 보게 되었다.

100분 토론의 주제는 "2010 부동산, 어디로?"였다. 내가 이 방송을 보면서 느낀 것은 부동산에 대한 지식을 얻고 앞으로 어떻게 행동해야 되겠다는 것이 아니었다. 내가 이 방송을 보면서 더 크게 느낀 것은 "진정한 전문가라면 어떻게 활동하는 것이 맞을까?"라는 것이었다. 최근의 많은 지식 전문가들은 특정 기업이나 연구소에 소속되어 해당 기업이나 연구소의 이익을 위하여 일하고 있으며, 이로 인해 월급을 받으며 생계를 유지한다. 이런 실정이기 때문에 자신이 옳다고 생각하는 진실을 전달하지 않고 왜곡하는 경우가 많다. 하지만 진정한 전문가라면 자신이 분석하고 연구한 내용의 진실을 이야기할 수 있어야하지 않을까? 100분 토론의 선대인 부소장을 보면서 "진정한 전문가라면 저러해야 한다."라는 생각을 하게 되었다. 자신이 연구하고 분석한 내용이 현재 많은 사람들이 주장하는 논리와 틀리더라도 자신있게 이야기할 수 있어야 하지 않을까? 다른 사람이 이야기하기 꺼리는 부분이더라도 맞다고 판단한다면 소신을 가지고 이야기할 수 있어야 하지 않을까?

이 방송을 보면서 내 자신을 돌아볼 수 있는 계기가 되었다. 현재 사회는 많은 사람들이 점점 더 전문가가 되기 위하여 노력하고 있으며, 전문가로 성장하면서 부를 얻기 위하여 노력한다. 하지만 전문가가 되기 위하여 노력하기 전에 어떤 자세를 가지느냐가 더 우선시 되어야 하지 않을까 생각한다. 나 또한 전문적인 지식을 습득하는데만 집중할 것이 아니라 전문적인 지식을 습득해 무엇을 할 것인지를 고민해봐야겠다. 부동산에 대한 분석 내용도 좋았지만 그 보다 전문가로서 자세를 보여주는 모습이 나에게는 더 큰 감동이었다.

Posted at 2월 06, 2010 by 자바지기 | 1 comment
Last changed 2월 08, 2010 13:16 by 자바지기
Labels: 팀장

2009년 10월 팀장 자리에 실증을 느끼고 팀장을 그만 두었다. 팀장을 그만두고 내가 하고 싶었던 기술 지원 업무를 하고 싶었지만 진행하고 있던 프로젝트가 있었던 관계로 프로젝트를 마무리하고 조직을 이동하기로 결정했다. 2009년 12월 말 진행하던 프로젝트를 마무리하고 2010년 1월 인수인계를 진행하면서 자연스럽게 이동할 계획이었다. 그런데 올해 2월 조직 개편을 하면서 4개월간 버렸던 팀장을 다시 하게 되었다. 자의반 타의반 팀장의 자리를 맡게 되면서 다시 한번 새로운 도전을 하게 되었다.

내가 맡게 된 팀은 전략적으로 의사 결정이 필요한 업무에 대하여 프로토타이핑을 진행하면서 요구사항을 수렴하고, 구체화하는 것이 주요업무이다. 기존에 진행했던 개발 업무와는 완전히 다른 새로운 성격의 업무이다. 휴가에서 어제 복귀하고 이틀째인 오늘까지도 팀을 어떤 방향으로 만들어갈지에 대한 구체적인 모습을 잡지 못한 상태이다. 조직 내에서도 완전히 새로운 시도인지라 딱히 이렇게 일을 해야 한다는 것 또한 없다.

아무 것도 없는 것에서 하나씩 만들어 가야 한다는 것이 나름 재미있는 일이기도 하지만 일정 수준으로 구체화하기 전까지는 많은 고통이 따름을 안다. 하지만 내가 지향하는데로 조금씩 구체화되어 가는 모습을 보는 것은 개발을 통하여 좋은 소프트웨어를 만드는 것만큼 짜릿한 즐거움을 준다. 물론 바람직한 모습으로 조직이 성장하고 가치있는 일을 하고 있을 때의 이야기이다. 그렇지 않은 경우에는 더 큰 고통이 따르는 법..

오랜만에 나에게 던져진 새로운 도전거리라 약간의 긴장과 흥분이 교차한다. 한편으로는 개발에서 다시금 조금 멀어지는 느낌이지만 나름 이 조직 속에서도 재미있는 시도는 다양하게 해볼 수 있을 듯하다.

내가 진정 바라는 조직의 모습을 이 조직에서 더 빨리 만들어볼 수 있지 않을까라는 기대감으로 다시 팀장을 맡았다. 이번 시도에서도 진정 내가 바라는 일을 할 수 없다면 이젠 다른 시도를 해보는 수 밖에 없을 듯하다. 너무 한 곳에서 오래 안주하고 있는 것은 아닌지 모르겠다. 너무 오랫동안 가슴 뛰는 일을 하지 못해 무력감을 느낄 때가 많다. 다시 한번 가슴 뛰는 일을 만들어가고 싶다.

Posted at 2월 05, 2010 by 자바지기 | 1 comment
Last changed 2월 04, 2010 12:49 by 자바지기
Labels: 푸켓, 여행

2월 2일까지 푸켓에서의 5박 6일 여행을 마치고 돌아왔다. 푸켓 여행은 생각보다 너무 좋아서 돌아오기 싫을 정도였다. 정말 밥 먹고, 수영하고, 낮잠자다가 수영하고, 밥 먹고의 생활을 며칠간 했더니 이렇게 좋을 수가.. 나 뿐 아니라 아내와 아이들이 너무 좋아해서 더 즐거운 여행이 될 수 있었다.

지금이 건기라 휴가 기간 내에 위 사진에 보이는 것처럼 맑고 푸른 하늘과 바다를 볼 수 있었다. 어찌나 파랗던지 누워서 하늘을 보고 있으면 어린 시절 시골 마루에 누워서 하늘을 바라보던 때가 생각이 났다.

나와 아내 모두 활동적인 여행보다는 조용하고 쉬기 위한 여행을 바래서였는지 더 만족스러운 여행이 되었다. 외출은 코키리를 타기 위해서 하루 외출했을 뿐이다. 왼쪽 사진은 코끼리를 탔을 때 찍은 사진이다. 나머지는 리조트에서 수영하고, 다양한 스포츠(양궁, 스쿼시, 테니스 등등) 하는데 시간을 보냈다.

물론 다양한 볼거리가 있는 여행도 좋지만 이번 여행처럼 아무 생각없이 책 읽으면서 편히 쉬는 여행도 정말 좋은 여행이라는 것을 다시 한번 느낄 수 있었다.

처음 떠난 가족의 해외 나들이였는데 너무 만족스러운 여행이었다. 여행에서 돌아오면서 지금부터 조금씩 돈 모아서 3~5년 후에 다시 한번 해외로 나가자는 계획을 세웠다. 넘 무리하는거 아닌지 모르겠다. 적게 벌어서 적게 쓰면서 살고자 하건만..

Posted at 2월 04, 2010 by 자바지기 | 4 comments
Last changed 1월 27, 2010 18:08 by 자바지기
Labels: 결혼, 10주년, 푸켓, 여행

아내와의 약속을 결혼 10년이 지나서야 지킬 수 있게 되었다. 결혼할 때는 군인 신분이었기 때문에 신혼 여행도 해외로 가지고 못해 지금까지 한번도 해외에 나가보지 못한 상태다. 나야 프로젝트, 컨퍼런스 때문에 몇 번 나간 경험은 있지만 아내와 아이들은 이번이 처음이라 더욱 설레인 듯하다.

나도 최근에 조직 개편 때문에 어수선한 분위기이지만 이 여행 때문에 참으면서 지낼 수 있었던 듯하다. 요즘 생각할 꺼리가 많아서 혹시나 여행 중에도 그 생각 때문에 고민을 좀 하겠지만 그래도 여행이 여행인지라 마냥 즐거울 듯하다. 아내와 결혼해 10년을 살면서 큰 돈을 벌고, 많은 것을 해주지 못했지만 조금씩 모은 돈으로 이렇게 여행을 떠날 수 있다는 것이 진정 행복이라는 생각이 든다.

당분간 사이트가 조용할 듯하다. 요즘 서버 새로 세팅하면서 가끔 불안한데 잘 살아있기를.. 여행 후에는 여행지에서 찍은 사진들로 염장질을 좀 해야겠다.

Posted at 1월 27, 2010 by 자바지기 | 3 comments
Last changed 1월 25, 2010 18:01 by 자바지기
Labels: reviews, 월든, 헨리, 데이비드, 소로우

지금까지는 무슨 책을 읽을까 고민을 하는 경우가 많았는데 한 권의 책을 읽다가 그 책에 추천 서적으로 나오거나 연관된 서적들이 참 많이도 눈에 띈다. 책이 눈에 띄일 때마다 하나씩 추가하다보니 정말 많은 책이 한번 읽어봐야할 목록으로 추가되고 있는 상태이다. 이 책은 한비야씨 책을 읽으면서도 한번 읽어봐야지 생각했는데 먼저 읽었던 조화로운 삶에서도 많은 부분이 인용되고 있어서 더 관심이 간 책이다.

사실 책 가격만 놓고 본다면 커피 한잔 값 밖에 되지 않는 저렴한 가격의 책이다(온라인으로 구매했을 경우..). 책이 쓰여진 시점을 봐도 1800년대로 지금 시점에 읽는 것이 무슨 의미가 있을까라는 생각이 들 정도이다. 책의 두께와 작은 글씨 때문에 중간에 책 읽는 것을 포기하고 다른 책을 먼저 읽었다. 그런데 이 책을 읽으면서 묘한 느낌이 들었다. 책을 읽기 시작할 때는 몰입이 잘 되지 않지만 일단 몰입해서 읽으면 어딘지 모를 편암함이 느껴지는 책이라고 할까? 이 책을 보면 자연에 대하여 정말 잘 묘사하고 있다. 정말 어떻게 이와 같이 세세하게 묘사할 수 있을까 생각해 봤는데 이 모든 것이 사물과 자연에 대한 관심이라고 생각한다. 그 동안 대수롭지 않게 생각했던 자연물과 자연 현상에 대하여 저자는 얼마나 많은 관심과 애정을 가지고 바라보고 있는지 느낄 수 있었다.

나 또한 자연과 더불어 살고 싶고, 귀농을 하기 위하여 개인적인 계획도 세우고 있지만 이 책의 저자와 같은 관심과 애정을 가지기는 힘들 듯하다. 그 만큼의 감성 또한 아직 부족한 상태이다. 몰론 자연과 더불어 지내면서 마음의 여유를 가진다면 지금보다는 더 많은 모습이 눈에 띄일 수 있겠지만서도..

이 책의 가장 중요한 부분은 자연과 시골 생활에 대하여 묘사하고 있는 부분이 아니라 자신이 진정 원하는 삶을 살라는 메시지라고 느꼈다. 다른 사람들이 살아가는 속도를 인정하고, 다양성을 인정하면서 자신 또한 자신의 삶을 살아가는 것이 진정 행복한 삶이리라. 최근에 읽는 책이 이와 비슷한 주제에 관한 책이 많아서인지 현재 내가 살고 있는 삶이 진정 내가 원하는 삶을 살고 있는지에 대하여 반문해보고 있다. 아직 답을 찾지 못했다. 내가 진정 바라는, 원하는 삶이 무엇인지에 대하여..

월든 - yes24

Posted at 1월 25, 2010 by 자바지기 | 0 comments
Last changed 1월 25, 2010 11:13 by 자바지기

2008년 말에 프로젝트를 진행하면서 Batch 작업이 많아서 Spring Batch 기반으로 Batch를 만들면서 간단하게 모니터링 툴을 만들었다. Batch 작업을 통한 연관된 작업이 많았고, 테스트를 진행했던 QA들이 프로그래밍을 이용하여 Batch를 실행하는 것이 쉽지 않았던 관계로 모니터링 툴을 통하여 실행이 가능하도록 지원하였다.

Spring Batch는 모든 Batch 실행 결과를 DB에 로그로 관리하고 있기 때문에 쉽게 해결할 수 있었다. 2008년 말에는 단순히 필요한 기능만 개발했었기 때문에 UI나 다른 요구사항에는 특별히 관심을 가지지 않았었다. 2009년이 들어서 UI 개선도 하고 요구사항도 수렴해서 더 좋은 Spring Batch 관리툴을 만들고자 했지만 이런 저런 핑계 때문에 미루고 있다가 최근에 개발을 진행했다.

이번에 공개하는 Spring Batch Monitoring System은 본인이 UI에 대한 능력이 없기 때문에 GWT 기반으로 개발했다. Spring Batch Monitoring System의 기반이 되는 기술 스펙을 보면 다음과 같다.

  • GWT 2.0
  • GWT EXT 2.1.0
  • Spring Framework 3.0
  • Spring Batch 2.0
  • Spring Security 3.0.1

GWT와 Spring 프레임워크 기반으로 개발을 진행했다. 이와 같이 진행한 이유는 GWT와 GWT-EXT는 UI에 대한 구현 능력이 없는 나에게 있어서는 어렵지 않게 내가 원하는 UI를 만들어 내는 것이 가능했다. Spring 프레임워크를 채택한 이유는 내가 가장 친숙한 프레임워크이기도 하지만 Spring Batch가 Spring 프레임워크 기반으로 되어 있기 때문에 별도의 프레임워크를 학습하지 않아도 된다는 이유에서이다. Spring Security는 개인적으로 공부는 많이 했지만 아직까지 프로젝트에 도입해본 경험이 없어서 공부도 하면서 Spring Security의 기능을 배워보고 싶다는 욕심도 있었다.

Spring Batch Monitoring System 0.5 버전 기능

Spring Batch Monitoring System(가칭 batchmon) 0.5 버전까지 구현한 기능은 2008년 말에 포함하고 있었던 단순한 기능이다. 기능 목록을 살펴보면 다음과 같다.

  • 현재 프로젝트에서 관리하고 있는 Job을 목록을 볼 수 있는 기능
  • 각 Job별로 Job Execution 목록과 상태를 볼 수 있는 기능
  • 각 Job Execution별로 Step Execution 목록과 상태를 볼 수 있는 기능
  • 각 Step Execution의 상세 내역과 에러 내역을 볼 수 있는 기능
  • 각 Job별로 웹 상에서 실행할 수 있는 기능(Spring Batch Monitoring System과 같은 Instance내의 Job에 한하여)

1차적으로 Spring Batch Monitoring System의 핵심 기능이라고 할 수 있는 위 기능만 포함시켜서 0.5버전을 만들어서 공개했다. 이후에 추가할 기능에 대해서는 요구사항을 수렴해서 우선 순위를 정하고 시간적인 여력이 될 때 하나씩 추가하는 방식으로 진행할 계획이다. 개인적으로 1.0 버전이 나오기 전에 추가하면 좋겠다고 생각하는 기능은 다음과 같다.

  • Role과 User를 관리툴에서 관리할 수 있는 기능. 현재는 Spring Security 설정 파일에서 md5 기반으로 관리하고 있다.
  • 현재는 동일한 Instance 내에 있는 Job만 실행하는 것이 가능한데 JMX를 통하여 원격에서 실행되고 있는 Batch Job도 실행해야 한다.

장기적으로 추가되면 좋을 것으로 생각하는 기능은 다음과 같다.

  • 각 Job별 성공률과 실행 시간등을 확인해볼 수 있는 Dashboard 기능
  • 각 Job별 설정에 따라 Job Instance가 실행되지 않을 경우 Email이나 SMS가 전송되는 기능

우선 이 정도까지만 생각해봤다. 앞으로 온라인을 통하여 더 많은 요구사항을 수렴하고 기능 개선을 해나가도록 하겠다. 소스 코드가 정리되면 공개해볼 생각이다. 이 때쯤 되면 마음이 맞는 개발자와 같이 기능을 개선해 나가면 하는 바람도 가지고 있다. 현재는 GWT 기능을 익히는데 초점을 맞추다보니 테스트 코드도 부족하고 소스 코드도 부끄러운 수준이다.

Spring Batch Monitoring System Demo

위 URL에서 현재까지 개발된 기능에 대하여 테스트할 수 있다. 위 데모 사이트에서 테스트 진행하고 추가했으면 좋겠다고 생각하는 요구사항이 있다면 요구사항 페이지에서 의견 개진을 해주면 좋겠다.

Posted at 1월 25, 2010 by 자바지기 | 5 comments
Last changed 1월 22, 2010 19:27 by 자바지기
Labels: 골든티켓, reviews


골든 티켓

살아오면서 가장 가슴 뛰는 삶을 살았을 때는 언제였을까? 지금 생각해보면 회사를 그만두고 책을 쓸 때인 듯하다. 책을 쓰기 위하여 회사를 두 번(스트럿츠 프레임워크 워크북, Spring 프레임워크 워크북)을 그만 두었는데 첫번째는 둘째가 태어나는 바람에 정신이 없는 상태에서 책을 썼기 때문에 별다른 감정은 느끼지 못한 듯하다. 진정 즐거울 때는 Spring 프레임워크 워크북을 쓸 때인 두번째였다. 그 때는 새로운 책을 쓰는 것도 즐거운 일이였지만 Spring 프레임워크를 통해서 무엇인가 새로운 것을 할 수 있을 듯한 흥분이 있었기 때문이리라.

몇 년이 흐른 지금 그 때 만큼의 두근거림을 가지고 삶을 살아가고 있을까? "그렇다."라고 자신 있게 이야기할 수 없다. 그 때와 비슷하게 열심히 살아가고 있다고 생각하지만 그 때 만큼의 흥분은 없는 듯하다. 어쩌면 새로운 도전이 없기 때문이거나, 내가 진정 원하는 삶을 살지 않고 있기 때문일 수도 있겠다.

이 책은 현재 자신의 삶에 만족하지 못하고 있는 이들에게 작으나마 변화할 수 있다는 가능성을 제시하고 있다. 이런 류의 책들이 모두 비슷하지만 이 책은 놀이 공원의 배경으로 재미있게 풀어나가고 있어 어렵지 않게 읽을 수 있다. 편한 마음으로 자신의 삶을 생각해보면서 읽으면 좋을 듯하다.

Posted at 1월 22, 2010 by 자바지기 | 0 comments
Last changed 1월 21, 2010 21:40 by 자바지기
Labels: maven, repository, nexus

Maven을 기반으로한 프로젝트가 많아지면서 라이브러리 관리하는 것이 귀찮아서 자바지기 Maven Repository를 하나 구축했다. Maven Repository는 Nexus를 활용해서 구축했다. http://repository.javajigi.net/에 접근하면 로그인하지 않은 상태에서 자바지기에서 관리하고 있는 Maven Repository를 확인할 수 있다.

새로운 Repository를 추가할 필요가 있다면 자바지기 Maven Repository 환경 페이지의 덧글로 남기면 Repository 종류에 따라서 구분한 후에 추가하도록 하겠다.

또한 Maven Archetype을 만들어 공유하면 좋겠다고 생각하는 결과물이 있다면 공유해주면 좋겠다. 자바지기 Maven Repository에 등록해 활용할 수 있도록 하겠다.

Nexus는 GWT 기반(GWT Ext를 활용한 것으로 생각된다.)으로 만들어져 있어 GWT를 활용하여 무엇인가를 만들고 있는 요즘 유용하게 참고하고 있다. 물론 소스를 참고하기 힘들지만 전체적인 UI는 많은 부분에서 참고하고 있다. 지금 만들고 있는 애플리케이션을 조만간 공개할 수 있을 듯하다. 최근에 이 툴을 개발하면서 그 동안 잊고 있었던 개발의 재미를 느끼고 있다. 물론 작은 시작이지만 시간이 지나면서 기능을 추가해 나갈 생각을 하니 더 없이 기쁘다.

Posted at 1월 21, 2010 by 자바지기 | 0 comments
Last changed 1월 19, 2010 08:49 by 자바지기
Labels: reviews, 습관, 독서통신


미래를 바꾸는 습관

사내에 독서 통신 교육이 있어서 신청해 듣고 있는 중이다. 좋은 습관을 만들기 위한 일환으로 시작하게 된 독서 통신 교육이고, 기대를 많이 해서인지 의외로 책이 많은 도움이 되지는 않았다. 많이 도움이 되지 않았다기 보다는 지금까지 알고 있었던 내용들을 반복하고 있어서 피부로 와닿지는 않았다. 아마도 이와 비슷한 책들을 몇 권 읽었기 때문이리라.

역시 "어떤 책을 읽느냐?", "무엇을 알고 있느냐?"는 중요하지 않다. 알고 있다면 무엇보다 실천하는 것이 중요하지 많은 것으로 알고 있는 것은 아무런 도우이 되지 않는다. 이 책을 읽으면서 나 또한 좋은 습관을 만들기 위한 많은 방법들을 알고 있지만 실천에 옮기지 못하고 있는 것이 가장 큰 패착이리라.

이 책을 읽으면서 내가 지금까지 습관에 대하여 정말 중요하게 느꼈던 때를 찾아봤다. 그건 다름 아니라 프로그래머의 길을 시작하면서 읽기 시작한 온라인 기사들이었다. 개발을 처음 시작했을 때는 Java World 가 유명했는데 이 사이트에 올라오는 대부분의 기사를 읽었던 기억이 난다. 출,퇴근하면서, 출근한 이후에 읽는 이 기사들은 이후에 내가 프로그래밍에 대한 감각을 얻는데 큰 도움을 주었다. 지금도 가끔씩은 InfoQ에 올라오는 기사들을 즐겨 읽고 있지만 프로그래머로서의 초기만큼은 아니다.

아무리 작은 일이라도 매일 매일 빼놓지 않고 1년, 3년, 5년, 10년을 지속하기란 힘든 법이다.

이 책은 자신의 습관을 바꿔보고 싶은 사람들이 가볍게 읽으면 좋을 듯하다. 이 책을 계기로 관련된 다른 책이나 온라인 문서를 찾아서 자신의 행동을 바꾸고 습관으로 만들 수 있는 기회로 삼을 수 있겠다.

현재의 우리는 반복적으로 하는 행동의 결과이다.
그러므로 탁월함이란 행동이 아니라 습관이다.
- from 아리스토텔레스
Posted at 1월 19, 2010 by 자바지기 | 0 comments
Last changed 1월 13, 2010 17:51 by 자바지기
Labels: gwt, spring, archetype, maven

조만간 조직을 옮긴다. 작년에 조직을 옮기려고 했지만 진행하고 있는 프로젝트를 마무리하고 옮기라는 지시를 받고 지금 진행하고 있는 프로젝트를 마무리할 때까지 기다렸다. 12월 말에 카페북 프로젝트를 완료하고 인수인계 작업까지 마무리한 상태이다. 일부 작업이 남은 상태이지만 남은 개발자들이 잘 마무리하리라 생각한다.

조직을 옮기기 전에 시간적인 여력이 있어서 그 동안 정리하지 못했던 내용들에 대해서 공부도 하고 정리도 하고 있다. 내가 사내 개발 서버를 임의적으로 활용할 수 없는 상태이기 때문에 자바지기 서버에다 이런 저런 세팅도 했다.

첫째, 지금까지 Tomcat 단독으로 운영하고 있었는데 개발 환경과 실서비스 도메인을 분리하기 위하여 Tomcat 앞단에 웹 서버를 추가했다. 웹 서버는 Apache가 아니라 최근에 관심을 받고 있는 nginx를 설치해봤다. 간단하게 nginx 설치와 설정 관한 문서도 작성했다. 순전히 내가 필요해서 작성한 문서라 무지 간단하다.

둘째, 사내에서 사용하고 있던 서버 설치 및 프로젝트 배포 스크립트를 적용해봤다. CATALINA_BASE를 지정했더니 서버가 뜨지 않아서 초반에 삽질을 좀 했는데 Tomcat 버그였다. Tomcat 6.0.20으로 버전업을 했더니 아무 문제없이 해결되었다. 이 스크립트는 나에게 소유권이 있지 않은 관계로 공개하기는 힘들겠다. 추후에 내가 안정화하고 기여할 수 있다면 공개해보도록 하겠다.

셋째, Nexus Maven Repository를 세팅했다. 그 동안 세팅하고 싶었는데 귀차니즘으로 인해서 계속 미루고 있었는데 개발을 다시 시작하는 지금 시점에 세팅했다. 그 동안 Archetype을 통하여 공유하고 싶은 프로젝트가 있었는데 Maven Repository가 없어서 아쉬웠다. 앞에서 이야기한 CATALINA_BASE 문제 때문에 삽질한 것을 제외하고 쉽게 세팅할 수 있었다.

넷째, GWT 2.0과 Spring 3.0의 Archetype을 만들었다. 작년 여름쯤에 GWT 1.6과 Spring 2.5 기반으로 작은 프로젝트를 진행했다. 프로젝트를 진행하면서 기반으로 잡았던 내용을 GWT 2.0과 Spring 3.0으로 바꿔서 Archetype으로 만들었다. 이 작업하면서 삽질 엄청했다. 한 동안 개발과는 다소 떨어진 자리에 있었던지라 오랜만에 하는 삽질이 싫지는 않았는데 한번에 너무 많은 삽질을 하고 있자니 은근히 스트레스였다. GWT와 Spring 연동은 GWT Widget Library를 활용했다. 내가 만든 Archetype을 사용하고 싶은 개발자는 GWT 2.0과 Spring 3.0 Archetype 활용 문서를 참고하기 바란다.

GWT 2.0과 Spring 3.0 연동은 개인적으로 만들고 싶은 것이 있어서 시작했다. 이전에는 새로운 것을 시도할 때 문서 작업도 자주하고 이후에 다시 시작하려고 할 때 개인적으로 활용하는 경우가 많았는데 최근에 제대로 정리해 놓지 않아서 또 다시 삽질을 하는 경우가 많았다. 이 같은 단점을 보완하기 위하여 이번부터는 다시 정리를 해보기로 했다. 내 자신을 위해서.. 또한 다른 개발자에게 조금이나마 도움이 되기를 바라는 마음으로..

오늘로 기본적인 세팅은 완료했으니 내일부터는 개발을 시작해야겠다. 물론 아직까지 Continuous Integration(이하 CI) 툴은 세팅하지 않은 상태인데 개발을 하면서 CI툴이 필요한 시점에 세팅할 계획이다. 지금부터는 GWT의 싸움이 될 듯하다. GWT가 1.x에서 2.x으로 버전업 하면서 개선된 내용도 많고 재미있는 내용도 많은 듯하다. 시간나는 틈틈이 개발을 해볼 계획이다.

Posted at 1월 13, 2010 by 자바지기 | 0 comments
Last changed 1월 05, 2010 20:49 by 자바지기


조화로운 삶

나는 제 2의 인생을 내가 태어난 고향에서 시작하고 싶다. 내가 사회 생활을 시작하면서부터 가지고 있는 바램이다. 귀향에 대한 꿈만 가지고 있었지 아직까지 구체적으로 실행에 옮기지는 못하고 있는 실정이다. 개인적인 목표로 세우고 있는 나이는 내 나이 50이다. 아이들이 어느 정도 성장한 이후라면 나의 원하는 삶을 찾아서 갈 수 있으리라는 생각 때문이다.

한비야씨 책을 읽다가 우연한 기회에 읽게된 이 책은 정말 내가 꿈꾸던 삶을 살았던 두 사람의 귀농 이야기이다. 물론 이들이 살았던 모든 원칙들을 지키면서 살 자신은 없다. 하지만 이들이 진정 원했던 "단순하면서 충족된 삶"을 살고자 한다. 다른 사람들과의 경쟁 속에서 치열하게 사는 것이 아니라 협력을 통하여 서로 공생할 수 있는 환경 속에서 살고 싶다. 자연의 고마움을 느끼면서 나의 노동을 통하여 얻은 곡식과 채소로 나의 식생활을 주도해 나가고 싶다.

이 같은 바램이 지금까지는 단순히 하나의 바램일 뿐이었다. 이 책을 읽으면서 올해부터 하나씩 준비해 나가기로 마음 먹었다. 먼저 귀향 후에 내가 살 집터를 마련하는 일부터 시작할 계획이다. 집터는 부모님이 신혼 생활을 시작했던 곳을 1차 후보지로 결정했다. 부모님이 신혼 생활을 시작했던 집터는 현재 밭으로 사용되고 있는데 도로까지 진입로가 없어서 집을 지을 수 없는 상황이다. 따라서 진입로를 확보하기 위하여 집터 앞에 있는 밭을 사야 한다. 귀농을 위한 준비 작업으로 올해 1차 목표는 진입로 확보를 위하여 땅을 사는 일이다. 매수할 땅이 크지 않아서 비용 부담은 크지 않을 것으로 생각하지만 땅 주인이 매도할 의사가 있는지가 가장 중요할 듯하다.

만약 이 땅 매수가 원할하다면 다음 계획들도 차례대로 진행해볼 계획이다. 지금까지 집은 당연히 누군가를 통해서 지어야 한다는 생각을 하고 있었는데 이 책을 읽으면서 내가 직접 지을 수도 있겠다는 생각이 들었다. 20대에는 시골 집 수리도 직접하고 다른 집 지을 때 돈을 받고 일하기도 한 경험이 있는데 손수 집을 짓는다는 것은 참 재미있는 경험이라는 생각이 든다. 고향 주위에 많은 흙을 이용해도 좋고, 이 책에서 이야기하고 있는 돌집을 지어도 좋을 듯하다. 이와 같이 나의 삶을 위하여 필요한 많은 것을 자급자족할 수 있다면 나의 노후를 위하여 그리 많은 돈이 필요하지는 않겠다는 생각이다.

지금까지 집을 사려는 욕심 때문에 많은 부분을 포기하며 살았다. 하지만 집에 대한 욕심을 버린 지금 한편으로 마음이 편하다. 진정 내가 하고 싶은 일을 하면서 살 수 있다는 자신감과 함께..

Posted at 1월 05, 2010 by 자바지기 | 2 comments
Last changed 12월 29, 2009 08:34 by 자바지기


행복의 정복

내가 학생 시절 가장 싫어했던 주제가 철학이다. 철학과 관련된 내용은 몇 번을 읽어봐도 이해가 되지 않을 뿐만 아니라 도저히 의미를 알 수 없는 수 많은 단어들.. 철학에 대한 나의 생각은 고등학교 시절에 굳어져버려 지금까지 그대로 인 듯하다.

오랜만에 많은 생각을 하게 하는 책을 읽었다. 옮긴이는 이 책이 행복에 대하여 상당히 평이한 문장으로 기술하고 있다고 하지만 나의 능력 부족 때문인지 상당히 어렵게 느끼면서 책을 읽었다. 물론 행복에 대하여 이런 방식으로 풀어낼 수도 있구나라는 생각에 감탄을 한 곳도 많지만 난해한 문장 때문에 그냥 읽고 넘어간 부분도 많다.

어쩌면 책을 집중해서 읽지 못한 나의 잘못도 크리라. 지금까지 읽었던 책과 같이, 쉽게 읽고 넘어갈 수 있는 책에 너무 익숙해 있기 때문일 수도 있다. 어쩌면 책을 빨리 마무리하는 것에 대한 집착 때문인지도 모르겠다. 책의 한 문장 한 문장이 의미하는 바를 되새기기 보다는 한 권의 책을 끝까지 읽었다는 것에 대한 만족감을 최대한 빨리 얻고자 함이 더 강했는지도 모르겠다.

이 책에 대한 리뷰를 지금 쓰기는 힘들 듯하다. 이제 책을 한 번 읽었을 뿐, 책이 전달하고자 하는 많은 부분을 이해하지 못했기 때문이다. 이 책은 마음의 여유가 있을 때 다시 한번 정독해볼 계획이다.

Posted at 12월 29, 2009 by 자바지기 | 0 comments
Last changed 12월 23, 2009 05:06 by 자바지기
Labels: 카페북, 서비스, 오픈

2007년 10월.. 블로그 서비스를 맡아서 운영하고 있는데 갑자기 위키라는 신규 서비스를 오픈한다고 해서 새로운 서비스 개발을 시작하게 되었다. 새로운 서비스이고 그 동안 위키를 사용한 경험이 많기 때문에 많은 관심을 가지고 진행했다. 위키 기능을 개발하면서 새로운 시도도 많이 해보고 재미 있는 경험도 많이 했다. 그런데 2008년 10월 내부 사정에 의하여 위키 서비스를 접게 되었다. 그렇게 위키 서비스에 대한 아쉬움은 뒤로 하고 잠시 동안 다른 서비스 개발하는데 지원하는 역할을 했다.

방랑의 시간을 몇 개월 하고 난 뒤 카페에 위키 기능을 추가하는 업무를 맡았다. 2007년 11월부터 본격적으로 시작된 위키와의 시작이 오늘에서야 막을 내리게 되었다. 물론 최초 위키 서비스를 시작할 때 구현했던 많은 기능들이 기존 카페의 한계 때문에 구현하지 못한 부분도 있지만 나름 의미 있는 작업이었다. 이번 오픈하는 기능이 앞으로도 번창할 수 있기를 바란다. 나는 오픈 이후에 다른 업무를 맡는 관계로 서비스가 성장하는 모습은 먼 발치에서 볼 수 밖에 없을 듯 하다.

이번에 오픈하게 되는 카페북 기능의 특징은 다음과 같다.

멤버들이 공동집필 할 수 있습니다.

카페 게시글은 한 명의 멤버가 작성했다면 카페북은 여러 명의 멤버들이 함께 작성하여 페이지를 편집할 수 있습니다.

  • 페이지를 편집할 때마다 내용은 자동으로 저장되어, 이전 버전의 내용 확인 및 복구가 가능합니다.
  • 동일한 버전의 페이지를 여러 멤버들이 동시에 편집하는 경우, 저장하는 순서에 따라 버전이 관리가 될 수 있도록 지원합니다.
  • 편집 히스토리를 비교할 수 있으며, 최신버전에 추가되거나 삭제된 내용을 확인할 수 있습니다.

카페의 책을 만들 수 있습니다.

카페북은 카페의 책으로 활용할 수 있도록 지원합니다.

*'카페북 책꽂이'는 카페의 모든 카페북을 한눈에 확인할 수 있습니다.

  • '표지'는 표지이미지와 목차 일부를 확인할 수 있습니다.
  • '목차'는 페이지의 상하단계를 정의할 수 있습니다.

더 자세한 내용은 카페북 베타서비스를 오픈합니다.에서 참고할 수 있다.

Posted at 12월 23, 2009 by 자바지기 | 3 comments
Last changed 12월 20, 2009 20:27 by 자바지기
Labels: reviews, 한비야, 지도, 밖으로, 행군하라


지도 밖으로 행군하라

그건, 사랑이었네를 읽은 이후로 나는 한비야씨의 펜이 되어 버렸다. 그래서 선택한 책이 이 책이다. 또한 "그건, 사랑이었네"를 읽으면서 다시금 독서에 대하여 생각해 보게 되었다. 대학 시절에는 한 해에 책 100권 읽기도 하고, 그 해에 읽은 도서 목록도 만들고 했던 기억이 다시금 되살아났다. 그 동안 완전히 새로운 프로그래밍이라는 세계를 발을 들여놓게 되면서 내가 읽는 대부분의 책은 프로그래밍 서적이 되어 버렸다. 그래서일까? 내가 사고하는 수준이 점점 더 떨어지는 것 같은 느낌과 삭막해져가는 느낌이랄까?

물론 개발자로 살기 위해서 프로그래밍 서적을 보지 않을 수는 없겠지만 근 10년 동안 너무 편식을 했다. 지금부터라도 편식하지말고 다양한 책을 읽어볼 계획이다. 그래서 먼저 시작한 것이 한비야씨 책과 "그건, 사랑이었네"에서 추천해 준 책부터 시작해 보기로 마음 먹었다. 주말에 TV를 보지 않기 때문에 시간적인 여유가 생겨 책 읽기에 더할 나위 없이 좋다.

"지도 밖으로 행군하라". 참 무거운 주제를 생동감 있게 그려낸 저자의 글솜씨에 감동했다. 책을 읽는 곳곳에서 내가 현장에 있는 듯한 느낌이었다. 이와 같이 몰입할 수 있도록 하기 위한 글쓴이의 부단한 노력이 한편으로는 부럽고, 대단하다는 느낌이다. 나도 지금까지 수 많은 글을 썼지만 한비야씨의 글쓰기 위한 노력을 보면서 부끄러울 따름이다. 다음에 다시 한번 글쓰기에 도전한다면 내가 가진 모든 것을 쏟아부을 수 있도록 해봐야겠다. 그녀에게서 많은 것을 배우고 느끼고 있다. 내 삶에 있어 진정 중요한 것이 무엇인지 느낄 수 있는 많은 경험을 공유해 준 그녀에게 고마움을 전한다.

진정 나의 가슴을 뛰게 하는 일을 하고 있는지 고민해 본다.

태어날 때부터 전문가인 사람이 어디 있는가.
누구든지 처음은 있는 법. 독수리는 기는 법부터 배우지 않는가.
처음이니까 모르는 것도 많고 실수도 많겠지.
저런 초자가 어떻게 이런 현장에 왔나 하는 사람도 있을 거다.
그러니 이 일을 시작한 지 겨우 6개월 된 나와 20년 차
베테랑을 비교하지 말자. 오늘의 나와 내일의 나만을 비교하자.
나아감이란 내가 남보다 앞서 가는 것이 아니고,
현재의 내가 과거의 나보다 앞서 나가는 데 있는 거니까.
모르는 건 물어보면 되고 실수하면 다시는 같은 실수를 하지 않도록 하면 되는거야.

우리가 불행하다고 생각하는 많은 이유는 내 자신을, 내가 가진 주변의 여견을 다른 사람과 비교하기 때문이 아닐까? 다른 사람과의 비교가 아니라 어제의 내 자신, 그제의 내 자신과 비교해 조금 더 나아진 상태라면 그 자체로서 행복하지 않을까?

프로젝트를 마치고, 올 한해에 대한 평가를 하는 시기이다. 누군가에 의하여 진행되는 평가에 의하여 일희일비할 것이 아니라 이전 프로젝트보다 한 걸음 더 전진했다면, 작년보다 한 단계 더 성장했다면 그 자체만으로 만족하고 기뻐할 수 있으리라. 자기 자신의 싸움에서 승리하고 나아지는 모습을 볼 때 진정한 행복을 얻을 수 있으리라. 나는 한비야씨의 삶속에서 그런 모습을 본다. 나 또한 다른 무엇보다 자기 자신과의 싸움에서 승리해나가는 그녀의 모습이 가장 부럽다.

Posted at 12월 20, 2009 by 자바지기 | 2 comments
Last changed 12월 19, 2009 08:25 by 자바지기
Labels: reviews, 영혼


내 영혼이 따뜻했던 날들

이 책을 읽으면서 가장 크게 느꼈던 부분은 나 또한 이 책에 나오는 대부분의 경험을 했다는 것이다. 나 또한 "작은 나무"가 경험했던 것과 비슷한 경험을 한 적이 있었다는 것은 이 책에 빠져들어 읽을 수 있도록 했다. 책을 읽으면서 나의 어린 시절을 회상할 수 있었기 때문이다. 산, 들, 물과 어울어져 살았던 어린 시절의 경험은 지금의 나를 지탱해주는 큰 버팀목이 되고 있다. 어린 시절 자연과 더불어 사는 추억이 없다면 참 슬프지 않을까라는 생각도 해본다.

지금도 가끔씩 느껴지는 어린 시절의 느낌이 참 좋다. 봄이 되면 한순간 불어오는 따스한 바람을 느낄 때면 어린 시절 모내기철에 불어오던 바람을 맞으면서 느꼈던 편안한 마음, 하루를 마치고 저녁을 먹기 전에 집 앞에 있는 작은 도랑에서 온 가족이 손과 발을 씻을 때의 그 느낌, 할아버지를 따라 가서 밭고랑을 만들기 위해 소를 몰던 일, 이 책에서도 그렇듯이 내가 소를 몰면 꿈쩍도 하지 않던 소가 할아버지의 "이려..이려..워이.."라는 말에 순순히 움직이던 모습 등등등..

나는 새, 나무, 바람과 이야기를 나눌 정도로 감수성이 예민하지는 않았으며, 어른들은 말을 통하여 자신들의 살아온 지혜를 전달하지는 않았다. 하지만 자연 속에서 자연 그대로의 모습을 느낄 수 있었으며, 어른들은 자신들의 행동을 통하여 자연스럽게 본인들의 지혜를 전달했다. 물론 그 때는 많은 것을 느끼지 못했지만 몇 십년이 지난 지금은 나의 할아버지, 할머니, 아버지, 어머니로부터 많은 것을 배우고 느끼면서 성장했다는 것을 느낀다.

이 책은 비슷한 어린 시절의 추억이 있다면 그 때의 추억을 회상하면서 마음의 편안함을 느낄 수 있도록 해준다. 만약 자연과 더불어 살아온 추억이 없는 사람이라면 이 책을 통하여 간접 경험을 할 수 있도록 해준다. 인디언의 삶을 이야기하면서 자연스럽게 삶에 대한 지혜를 전달하고 있다. 할아버지, 할머니의 말과 행동을 통하여 전달되는 인디언의 지혜를 점점 더 복잡하고 삭막하게 살아가고 있는 현대인이 한 번쯤은 되새겨볼 필요가 있을 것이다.

할머니는 우리들에게 다음과 같이 이야기하고 있다.

할머니는 사람들은 누구나 두 개의 마음을 갖고 있다고 하셨다. 하나의 마음은 몸이 살아가는 데 필요한 것들을 꾸려가는 마음이다. 몸을 위해서 잠자리나 먹을 것 따위를 마련할 때는 이 마음을 써야 한다. ... 그런데 우리에게는 이런 것들과 전혀 관계없는 또 다른 마음이 있다. 할머니는 이 마음을 영혼의 마음이라고 부르셨다.

만일 몸을 꾸려가는 마음이 욕심을 부리고 교활한 생각을 하거나 다른 사람을 해칠 일만 생각하고 다른 사람을 이용해서 이익 볼 생각만 하고 있다면...... 영혼의 마음은 점점 졸아 들어서 밤톨보다 더 작아지게 된다.

몸이 죽으면 몸을 꾸려가는 마음도 함께 죽는다. 하지만 다른 모든 것이 다 없어져도 영혼의 마음만은 그대로 남아 있는다.
...
...

몸을 꾸려가는 마음이 영혼의 마음보다 더 커지면, 영혼의 마음은 땅콩알만하게 줄어들었다가 결국에는 그것마저도 완전히 사라지고 만다. 말하자면 영혼의 마음을 완전히 잃게 되는 것이다.
그런 사람들은 살아 있어도 죽은 사람이 되고 만다. 할머니는 어디서나 쉽게 죽은 사람들을 찾아낼 수 있다고 하셨다.
...
...
영혼의 마음은 근육과 비슷해서 쓰면 쓸수록 더 커지고 강해진다. 마음을 더 크고 튼튼하게 가꿀 수 있는 비결은 오직 한 가지, 상대를 이해하는 데 마음을 쓰는 것뿐이다. 게다가 몸을 꾸려가는 마음이 욕심 부리는 걸 그만두지 않으면 영혼의 마음으로 가는 문은 절대 열리지 안는다. 욕심을 부리지 않아야 비로소 이해라는 것을 할 수 있기 때문이다. 반대로 더 많이 이해하려고 노력하면 영혼의 마음도 더 커진다.

우리들 대부분은 몸을 꾸려가는데 너무 많은 시간을 쏟아 붓고 있는 것은 아닐까? 나는 서서히 죽어가는 사람이 되어가고 있는지도 모른다.

Posted at 12월 19, 2009 by 자바지기 | 0 comments
Last changed 1월 27, 2010 14:06 by 자바지기
Labels: 스프린트, 데모


지난 해 진행했던 위키 서비스를 만드는 프로젝트부터 스프린트 주기를 두고, 각 스프린트가 완료할 때마다 스프린트 기간 동안 구현한 기능에 대하여 데모를 진행했다. 프로젝트 초반에는 잘 지켜졌는데, 프로젝트가 진행될 수록 그 효과도 미미하고 의미가 없는 것으로 판단해 진행하지 않았다.

그런데 올해 새로운 프로젝트를 시작하면서 스프린트 단위로 항상 데모를 진행했다. 지금까지 프로젝트 중에 데모를 하는 경우가 많지 않았기 때문에 처음에는 다소 의아하게 생각했는데 시간이 지나면서 스프린트 데모가 의미있는 활동이다라는 이야기를 여기 저기서 듣게 되었다. 아직 그들에게 스프린트 데모가 어떤 면이 좋았는지에 대한 피드백은 받지 못했다. 아마도 조만간 진행할 프로젝트 회고에서 그들의 의견을 들을 수 있으리라 생각한다.

다른 사람들이야 프로젝트 중에 데모를 통해 지금까지 만들어진 기능을 미리 확인할 수 있으니 의미있고 좋은 활동이었다고 생각할지 모르지만 내 개인적으로 판단했을 때 이번 프로젝트에서 진행한 데모는 내가 생각했던 것만큼 프로젝트 성공에 큰 기여를 하지 못했다. 내가 스프린트 데모를 진행했던 이유는 최초 기획, 디자인했던 기능을 빨리 사용해보고 그에 따른 피드백을 받고 싶었기 때문이다. 그러나 QA를 하고 있는 지금의 상황을 보면 나의 최초 의도는 물거품이 되고 말았다. 이번 프로젝트도 지난 프로젝트들과 똑같이 수 많은 기획 변경과 디자인 변경 작업 발상해고 있다. 서비스 오픈을 얼마 남겨두지 않은 지금까지도 변경사항이 발생하고 있는 것을 보면 스프린트 데모를 통한 효과는 극히 미미했다.

그렇다면 왜 이 같은 결과가 나타나고 있는 것일까? 가장 큰 이유는 대부분의 프로젝트 참여자들이 데모를 단순하게 데모로만 인지하고 있었다는데 있다. 데모를 통하여 전체적인 기능이 어떻게 구성되어 있으며, 어떻게 동작하는지 이해하는데는 도움이 되었지만 좀 더 자세하게 분석하는 시간을 가지지 않았기 때문이다. 3주 단위로 스프린트를 진행했는데 3주가 끝나는 금요일 Status Meeting에서 의례적으로 데모를 진행하는 것으로 생각하고 자신의 것으로 받아들이지 않았던 것이다.

우리가 스프린트 데모의 효과를 극대화하기 위해서는 다음과 같은 노력이 필요할 것으로 생각한다.

  • 모든 프로젝트 구성원이 스프린트 데모의 의도를 이해할 수 있도록 해야 한다.
  • 단순한 데모가 아니라 각각의 기능에 대한 심도 있는 토론의 장이 되도록 해야 한다.
  • 스프린트 데모를 하기 전에 기획, 개발, 디자인, QA등 각 파트에서 테스트를 하고 문제를 해결하는 시간을 가져야 한다.
    • 대부분의 경우 일정을 맞추느라 지금까지 개발한 기능을 되돌아볼 여유가 없다. 따라서 스프린트 일정상에 반드시 테스트할 시간을 포함시키는 것이 바람직할 것으로 판단한다.
  • 스프린트 데모를 한 사람이 주도하는 것이 아니라 프로젝트 구성원들이 돌아가면서 하는 방법도 좋은 선택이라 생각한다. 아직 시도해보지는 않았다.

이번 프로젝트에서 항상 테스트할 수 있고, 데모를 할 수 있다는 것은 프로젝트 관련자들이 많을 경우 상당히 유용하다는 것을 느낄 수 있었다. 하지만 이는 현재 진행하고 있는 프로젝트 기능에 대하여 설명할 때는 유용했다. 하지만 프로젝트를 담당하는 구성원의 생각을 끌어 내어 더 좋은 서비스를 만들어 내기 위해서는 좀 더 깊이 있고 전략적인 데모가 필요하다.

프로젝트의 성공에 큰 기여를 하지는 못했지만 이번 프로젝트 데모를 통하여 새롭게 느끼는 부분이 많았기 때문에 개인적으로는 큰 의미를 부여하고 있다. 다음 프로젝트에서는 이번 프로젝트의 경험을 발판삼아서 더 의미있는 데모를 해봐야겠다.

결과적으로 나에게 남은 건 사용자에게 서비스 발표회를 할 때 시연을 하는 업무가 떨어졌다는 것이 씁쓸할 따름이다. 좋은 의도로 시작했던 것이 하나의 업무가 되어버리는 상황이라니.. 어딘가에서 많이 경험했던 일인 듯하다.

PS. 무엇인가 변화를 만들어가려고 할 때 항상 느끼는 것이지만 변화를 만들려고 하는 사람에게 마음의 여유와 시간의 여유가 없다면 변화를 만들기 참 어렵다. 이런 상황이라면 오히려 역효과를 낼 수 있다. 따라서 이후에 새로운 변화를 만들고자 했을 때 부정적인 생각이 많은 관계로 변화를 만드는데 더 큰 어려움을 느낀다. 변화를 만들고자한다면 사람들에게 마음의 여유와 시간의 여유를 줄 수 있는 환경으로 바꾼 후에 진정한 변화를 꽤해야 할 것이다. 하지만 많은 경우 이런 부분은 무시하고 곧바로 변화를 만들려고 하기 때문에 실패하는 경우가 많다.

Posted at 12월 10, 2009 by 자바지기 | 2 comments
Last changed 12월 06, 2009 12:53 by 자바지기
Labels: 프로젝트, 패턴, 관리, 아드레날린

프로젝트가 서쪽으로 간 까닭은?

현재 조직의 전체 사원수는 2000명 내외이다. 올해 신규 인원을 채용하기 위하여 개발자가 필요한 조직을 파악하기 위하여 전사적인 조사가 이루어진다. 각 조직별로 몇 명의 개발자가 필요한지를 파악해 수요에 따른 채용 규모를 결정하기 위해서이다. 개발자 수요를 조사한 결과 거의 모든 팀에서 개발자를 요구하고 있다. 그 규모는 200명이나 된다. 작년에 새로운 사업을 확장하고 다양한 조직을 신설하면서 500명이나 되는 개발자를 충원했음에도 불구하고 올해 다시 200명이 필요하다니..

경영진을 도저히 이해할 수 없어 어떻게 된 상황인지, 정말 각 조직별로 그 만큼의 인력이 필요한 것인지에 대한 구체적인 조사에 착수하기 시작한다. 그런데 각 팀을 조사한 결과 대부분의 팀이 바쁘고, 개발자가 없어 개발 속도가 떨어진다고 불만투성이다. 그러나 경영진은 도저히 이해할 수 없다. 작년에 500명이나 충원했는데 애플리케이션을 개발 속도는 오히려 더 떨어지는 것처럼 느껴지는데 여기에 200명이나 되는 개발자를 더 충원해 달라고 하니 말이다.

하지만 아직도 대부분의 프로젝트에서 야근 횟수는 줄지 않고 있으며, 모든 개발자가 바쁘게 움직이는 것처럼 보인다.

위와 같은 상황은 내가 가상으로 만들어본 내용이면서 현재 내가 몸담고 있는 조직에서 발생하고 있는 일이기도 하다. 그러나 현실에서 이 같은 상황이 발생하는 경우는 종종 있다. 특히 사업이 급성장하면서 조직이 급격하게 커질 때 제대로된 조직 관리를 하지 못할 경우 발생할 가능성이 많다. 위 조직에서는 무슨 일이 벌어지고 있는 것일까? 직원이 지속적으로 충원됨에도 불구하고 개발 속도는 빨라질 기미가 보이지 않고 있으며, 올해 또한 상당히 많은 인원의 직원을 충원해야 한다고 요구하고 있다.

위 조직은 "아드레날린 중독증 패턴"에 걸린 것이다. 특히 국내의 많은 조직에서는 이와 같이 항상 미친듯이 바쁘게 움직여야 생산성이 높아지리라 생각한다. 모든 사람들이 바쁘게 움직이면 일을 잘하고 있구나라고 위안을 삼는다. 일시적인 착시 현상으로 생산성이 높아지는 것처럼 보일지 모르지만 결과적으로 생산성과 효율성은 오히려 떨어진다.

"프로젝트가 서쪽으로 간 까닭은?" 책은 프로젝트를 진행하면서 발생할 수 있는 현상들을 패턴으로 정리한 책이다. 지금까지 다양한 패턴들에 대하여 들어왔지만 프로젝트에서 발생하는 현상들까지 패턴으로 정리할 수 있다라는 생각은 해보지 못했다. 그런데 막상 이렇게 책을 통하여 접해보니 지금까지 프로젝트를 진행하면서 느꼈던 많은 현상들이 패턴으로 정리될 수 있겠구나라는 생각이다. 정말 의미 있는 작업을 했구나. 그 동안 프로젝트에서 무엇인가 문제가 있는 듯 한데 무었 때문인지 막연함이 있었으며, 그런 막연함을 다른 동료들에게 설명하기 힘든 경우가 많았다. 그러나 이와 같이 체계적으로 정리해 놓고 보니 이 같은 상황이 우리 조직만의, 우리 프로젝트만의 문제가 아니라는 것을 느낄 수 있었다.

이 책에서는 조직과 프로젝트에서 발생하는 문제점도 좋은 현상들에 대하여 패턴으로 정리했다. 하지만 문제점에 대한 해결책과 좋은 상황으로 만들어가기 위한 구체적인 활동에 대해서는 제시하지 않고 있다. 물론 각각의 패턴에 대한 해결책과 구체적인 활동을 제시할 수도 있지만 이 내용을 포함할 경우 몇 개의 패턴만으로 한권의 책이 훌쩍 넘어버릴 것이다. 그 보다는 조직과 프로젝트에서 발생하는 상황에 대하여 하나의 패턴으로 인식하고 좋은 패턴이라면 지속적으로 활성화하고 문제점이 있는 패턴이라면 이를 극복하기 위한 활동을 찾아서 하도록 유도한 것만으로 의미있는 작업이다. 사실 막연하게 문제점이라고 인식하고 있으면서 무엇인가 변화를 꽤하지만 "나 혼자만의 생각이 아닌가?", "내가 너무 불만 투성이가 아닌가?"라는 막연한 두려움이 있었던 것은 사실이다. 이 같은 두려움 때문에 변화를 만들어 가는데 더 적극적으로 대응하지 못하게 되고, 위축되게 된다. 하지만 이 책을 통해서 지금까지 느꼈던 것이 막연함이 아니라 다른 프로젝트에서도 발생하는 상황이며, 변화시킬 필요가 있다는 자신감을 얻게 되었다.

물론 이 책에서 다루고 있는 패턴이 모두 나의 영향력으로 해결할 수 있는 문제들은 아니다. 앞에서 살펴본 "아드레날린 중독증"과 같은 경우에는 상위 조직장들에 의하여 발생하는 경우가 많기 때문에 전사적으로 변화할 필요가 있는 부분이다. 하지만 내 영향력을 통하여 해결할 수 있는 패턴들 또한 무수히 많다. 이 패턴들에 대해서만 서쪽이 아닌 동쪽으로 갈 수 있도록 유도해도 지금보다는 훨씬 더 재미있게 일하면서 효율적으로 일할 수 있을 것이다.

최근에 프로젝트를 진행하면서 중요하다고 생각하는 패턴이 이 책의 31번째 패턴에 해당하는 리듬이다. 꾸준한 리듬을 가지고 프로젝트를 진행하면서 점진적으로 발전시켜 나가는 것이 가정과 회사의 균형을 맞추면서 일을 진행하는데 중요한 부분이라고 느끼고 있었다. 내가 중요하다고 생각하고 있던 것이 하나의 패턴으로 정리된 것을 보니 더 기뻤다. 앞으로 이 책을 통하여 조직과 프로젝트 속에서 느끼지 못했던 많은 부분을 인식하면서 일을 할 수 있을 듯 하다. 프로젝트를 시작하기 전에 이 책에 나오는 패턴을 살펴보고 문제가 발생하는 현상이 보인다면 해결하려는 노력을 하나씩만 해보면 좋을 듯하다. 처음부터 너무 많은 부분에 욕심을 내기 보다는 한가지만이라도 해결하려는 노력을 하고 성공한다면 지속적인 변화를 만들어가는데 재미를 느낄 수 있으리라. 이 책이 조직, 프로젝트, 일 속에서 허덕이고 있는 개발자에게 작은 희만이나마 제시해 줄 수 있으리라 믿는다.

Posted at 12월 06, 2009 by 자바지기 | 0 comments
Last changed 12월 04, 2009 08:51 by 자바지기
Labels: 프로젝트관리, 카페

지금 진행하고 있는 프로젝트가 서비스 오픈을 얼마 남겨두지 않고 있다. 이번 프로젝트는 지금까지 진행했던 다른 프로젝트보다 효율적이라 생각했기 때문에 QA 기간에 다소 여유가 있을 것으로 생각했다. 하지만 "폭탄 돌리기를 하고 있다는 느낌은 왜 일까?" 글에서도 이야기했 듯이 QA 기간이 개발 기간보다 오히려 더 바쁜 상황이 되었다. 이 같은 상황이 발생하게 된 가장 큰 원인이 어디에 있을까 생각해 봤다. 개인적으로 생각하기에 가장 큰 원인이 프로젝트를 시작할 때 위험요소로 판단될 수 있는 부분을 간과했기 때문이라고 생각한다.

카페 서비스에 신규 기능을 추가하고 있는 지금 프로젝트의 인원 구성을 보면 다음과 같다.

  1. 올해 입사한 프로젝트 매니저 1명
  2. UX(User Experience) 업무에서 기획자 업무로 전환한지 얼마 되지 않았으며, 카페 서비스 도메인 지식이 깊지 않은 기획자 1명
  3. 다른 서비스 개발에 참여하고 있다가 카페 신규 기능 추가를 위하여 투입된 개발자 6명(내가 여기에 속한다.)
  4. 카페 서비스에서 프로젝트를 한번 경험해본 개발자 1명(6개월 정도 경험)
  5. 카페 서비스를 담당하고 있는 전담 QA 1명(서비스 개발 중에는 10% 미만으로 참여)

프로젝트에 참여한 다른 구성원도 있지만 디자인과 클라이언트 영역이라 이 글과 큰 연관 관계가 없어 제외했다. 위와 같은 인원 구성이라면 가장 먼저 고려해야할 부분이 무엇이었을까? 프로젝트를 시작하는 시점에는 이런 저런 바쁘다는 핑계로 관심을 가지지 않았지만 프로젝트를 마무리하는 시점에서 위와 같이 간단하게 정리를 해놓고 보니 가장 큰 문제점이 한눈에 파악이 된다. 내가 느끼는 가장 큰 위험요소는 7년 이상을 운영해오고 있는 카페 서비스의 복잡도에 비해 카페 서비스에 대한 도메인 지식을 가진 사람이 없다는 것이다. 간단히 위와 같이 한번 정리하고 위험요소를 파악하는 시간을 가졌다면 현재 우리가 가지는 가장 큰 위험요소가 무엇이며, 이 위험요소를 해결하기 위하여 취할 수 있는 행동들을 먼저 취할 수 있었을 것이다.

지금 프로젝트에 대한 원인 파악은 현재 프로젝트를 시작할 때의 상황을 봤을 때의 상황과 내가 해결할 수 있는 범위로 국한했다. 프로젝트가 지금과 같은 상황이 된 더 근본적인 원인은 다른 곳에 있다. 이 글에서 이야기하는 원인보다 더 근본적인 원인이 몇 개나 더 있다. 하지만 더 근본적인 원인을 이야기해보아야 내가 해결할 수 있는 범위를 벗어나기 때문에 내가 해결할 수 있는 범위 내에서의 가장 근본적인 원인을 찾는데 집중했다. 다음 프로젝트부터는 이 같은 실수를 반복하지 않기 위해서..

더 근본적인 원인에 대한 해결 방법은 나 혼자만의 노력으로 변화하는 것이 아니라 많은 이들의 노력이 합쳐져야 하며, 그 만큼 많은 시간이 소요될 것이다. 근본 원인을 찾아 해결책을 찾으려는 노력을 한다면 앞으로 10년 이상 꾸준히 성장할 것이며, 그렇지 않다면 지금의 상황만을 유지하거나 그저그런 회사로 전락 할 것이다.

하지만 우리는 이 부분을 간과했다. 우리는 카페 서비스와는 독립적인 형태로 갈 수 있다고 낙관했다. 많은 부분을 독립적으로 개발하려고 했으며, 그렇게 할 수 있으리라 생각했다. 하지만 QA를 진행하고 있는 지금의 상황을 보면 우리가 가장 큰 실수를 했다는 생각이 든다. 만약 도메인 전문가가 없는 것이 가장 큰 위험요소였다고 판단했다면 다음과 같이 대응하는 것이 가능했으리라.

  1. 기획자에 의하여 전달되는 상세 기획서에 대하여 개발자까지 참여해 분석하는 기간을 가진다.
  2. 개발을 시작하기에 앞서 카페 서비스를 이해하고 새롭게 추가되는 기능과의 연관성을 분석하는데 일정 시간을 할애한다.
  3. 지금까지 축적되어 있는 QA의 Test Case를 이용하여 카페 서비스의 전체적인 기능을 파악한다.
  4. 이 외에도 다양한 많은 시도들을 했을 가능성도 있다.

프로젝트 초반에 위험요소를 파악한다고 모든 문제점을 해결하고 진행할 수는 없다. 위와 같은 위험요소를 알았다 하더라도 모든 의존관계와 영향도를 파악할 수 없다. 위와 같이 도메인 전문가가 없는 상황은 많은 프로젝트에서 다반사로 발생하는 부분이다. 하지만 이 같은 위험요소를 인지하는 것과 그렇지 않은 것은 많은 차이점을 보인다. 프로젝트에 참여하고 있는 구성원 한명, 한명 현재 프로젝트가 가지고 있는 가장 큰 위험요소를 알고 있었다면, 프로젝트를 진행하는 중간 중간 기존 카페 서비스와의 영향도를 한번 씩 더 고민했을 것이다. 그에 따라 많은 문제점이 조기에 발견될 가능성이 높아졌을 것이다. 프로젝트 기간 진행했던 주간 Status Meeting에서 카페와의 연관성에 대하여 더 많은 논의를 했을 가능성도 있다.

프로젝트를 진행하면서 도메인에 대한 지식이 점점 더 높아질 수록 지금까지 개발한 기능에서 부족한 점이 보인다. 많은 유지보수 비용이 발생할 부분이 어느 부분인지도 알겠다. 지금이라도 당장 바꾸고 싶다. 하지만 이미 넘어올 수 없는 강을 넘고 말았다. 지금보다 좀 더 빨리 이 같은 상황을 알 수 있었다면 이에 대처할 수 있었을텐데 하는 아쉬움이 남을 뿐이다. 프로젝트를 완료하고 카페 서비스에 남아서 계속 운영 업무를 한다면 개선할 여지가 있겠지만 다른 업무를 진행해야 하는 나로써는 아쉬움이 더 클 뿐이다.

이번에 진행했던 프로젝트에서는 간과했던 부분이지만 다음 프로젝트에서는 위험요소를 프로젝트 초기에 파악하려는 노력을 해봐야겠다. 물론 모든 사람이 프로젝트 매니저 역할을 담당하지 않지만 프로젝트의 성공을 위해서는 프로젝트에 참여하는 개개인이 한번쯤 "현재 상태에서 프로젝트의 가장 큰 위험요소가 무엇인가?"라는 화두를 던져볼 필요는 있으리라. 프로젝트 매니저의 영역을 침범하는 것처럼 보일 수도 있겠지만 프로젝트의 성공을 위한 진정성으로 다가간다면 그 하나만으로도 의미있는 활동이다.

Posted at 12월 04, 2009 by 자바지기 | 2 comments
Last changed 12월 03, 2009 19:24 by 자바지기
Labels: reviews


정말 우연히 읽기 시작한 책이다. 집에서 TV를 보지 않은지 3개월 정도 되어 가는 듯하다. 지난 번에 TV를 보지 않기로 했지만 3달 정도 지난 시점에 TV를 다시 보게 되었다. 그리고 얼마의 시간이 지나지 않아서 TV가 아예 고장이 나 버렸다. 아내와 아이들이 TV를 고쳐야 되지 않느냐고 했지만 나는 일부러 고치지 않고 있다. 3개월이 지나고 있는 지금 시점에는 TV를 고치지 않기 정말 잘했다는 생각이다.

평일은 시간이 잘도 가지만 문제는 주말에 남는 많은 시간이다. TV 시청을 하지 않고부터 주말에 남는 시간을 무엇으로 채울까 고민하다 책 읽기가 점점 더 습관이 되어 가고 있다. 물론 주말에 1,2시간씩 운동도 빼놓지 않고 하고 있다. 이런 상황에서 이 책을 우연히 만나게 되었다. 사실 나는 오래전부터 한비야씨에 대하여 알고 있었지만 책을 읽을 생각은 하지 않았다. 특별히 나에게 영향을 줄 수 있을까? 시간 낭비가 아닐까라는 막연한 선입견 때문이었다. 그런데 얼마 전 아내가 이 책을 구입했다. 이번 주말 빈둥거리고 있다가 문득 이 책이 생각났다. 나도 한번 읽어볼까!~! 한비야씨와의 만남은 그렇게 시작됐다.

책을 읽고난 지금의 기분을 한마디로 표현하라면.. "정말 많은 열정과 사랑을 가지고 사는 사람을 한명 알게 되었다. 내가 알게 된 그 사람으로부터 나 또한 많은 영향을 받을 거 같다."는 느낌이다. 또 하나의 느낌은 "나도 한번 종교를 가져볼까?"라는 막역한 느낌도..

한비야씨는 정말 내가 그토록 꿈꾸고 바라던 그런 열정을 가진 사람말이다. 물론 내가 한비야씨가 걸어가고 있는 길을 똑같이 걸어가면서 그 만큼의 열정과 사랑을 가지기를 바라지는 않는다. 나의 그릇이 한비야씨만큼 넓고 크지 않다는 것을 알기에.. 단, 내가 하고 싶은, 내가 걸어가고 있는 나의 길에서 한비야씨 만큼의 열정을 가지고 살아가야겠다는 바람이다. 바람이기도 하면서 갈 수 있다는 강렬한 의지 또한 느낄 수 있었다.

한비야씨가 이 책에서 이야기하듯이 무엇인가 변화를 꿈꾸고, 준비하고 있는 나에게 그 분(나는 하느님, 하나님이라는 단어에 왠지 모를 거부감을 느낀다.)이 이 책을 나에게 제시한 것인지도 모르겠다. 그 분이라고 해서 반드시 그 분을 믿고 따르는 사람들에게만 길을 제시하지는 않는다고 생각한다. 나는 그 분은 모든 사람 속에 존재하고 있으며, 우리들이 치열하게 고민하고 끊임없이 질문을 구할 때 그에 대한 길을 제시한다고 생각한다. 사실 그 분은 하느님, 하나님, 부처님, 이름 없는 형태 등 다양한 모습으로 우리 주위에 나타날 수 있으리라. 사실 이 것이 내 종교관이라면 종교관이다. 특정 종교를 믿느냐 믿지 않느냐는 중요하지 않다. 자신의 삶에 기준을 가지고, 그 기준에 따라서 의미있는 삶을 살 수 있다면 그 자체로 종교를 가진 것이나 별반 다르지 않다는 것이 내 생각이다. 물론 자신의 기준을 만들고 그 기준에 따라 소신있게 사는 것이 정말 힘든 길이라는 것을 알지만 말이다. 쉬운 길이였다면 누구나 갈 수 있으리라.

한비야씨 책을 읽으면서 또 한번 중요하다고 생각하는 것은 습관에 대한 중요성이다. 한비야씨가 그 바쁜 일상 속에서도 꾸준히 책을 읽고, 글을 쓰고, 등산을 하는 모든 일이 하나의 습관이었으며, 이 같은 습관이 1년, 5년, 10년이 되면서 지금의 한비야씨를 만들어가고 있다. 시작할 때는 작은 움직이었지만 꾸준함으로 지속할 수 있다면 무슨 일이든 성취할 수 있지 않을까? 나 또한 평생을 같이할 필요가 있는 좋은 습관을 찾아볼 생각이다.

Posted at 12월 03, 2009 by 자바지기 | 0 comments
Last changed 12월 01, 2009 21:43 by 자바지기

많은 사람들과 커뮤니케이션을 위하여 블로그를 자바지기 커뮤니티에서 옮겼습니다. 이 블로그를 시작한 첫번째 글을 보니 2006년 12월 2일에 이 블로그를 시작했네요. 지금부터 딱 3년이 됐네요. 블로그의 장점이 많았기 때문에 이 곳으로 옮겨와 많은 이야기를 할 수 있었습니다. 그런데 블로그에 글을 쓰다보니 커뮤니티에 대한 관심이 떨어지게 되었고, 내가 편하게 남기고 싶은 글과 자료를 올리지 못한다는 생각을 하게 되었습니다.

오늘부터 다시 커뮤니티로 블로그를 옮겨갈 계획입니다. 다른 개발자들과의 커뮤니케이션은 떨어질지도 모르겠지만 제가 자료를 정리하고 관리하는 측면에서는 더 좋을 것으로 판단됩니다. 커뮤니티에 더 많은 관심을 가지려고 하는 이유는 처음 개발을 시작할 때의 초심으로 돌아가고 싶은 마음 때문입니다. 개발자의 길을 걷기 시작하고 6개월이 지난 시점부터 자바지기 커뮤니티를 운영하기 시작했습니다. 커뮤니티를 시작하고 많은 개발자들과 의견을 나눌 때의 그 짜릿함을 다시 한번 느껴보고 싶습니다. 물론 자바지기를 처음 시작할 때와 같이 커뮤니티가 활성화되기는 힘들겠지만 제 나름대로의 소신을 가지고 커뮤니티를 운영해볼 계획입니다.

그 동안 이 블로그에 많은 관심과 사랑을 보내준 분들에게 감사드립니다. 앞으로도 자바지기 커뮤니티 블로그를 통하여 많은 분들과 만나도록 하겠습니다.

Posted at 12월 01, 2009 by 자바지기 | 1 comment
Last changed 12월 01, 2009 20:46 by 자바지기
Labels: devs

얼마 전 디자인 패턴을 다시 한번 훑어 보기 위하여 Head First Design Patterns 책을 읽게 되었다. 이 책을 읽다 변화를 이야기하는 부분에서 다음과 같은 질문을 받았다. "여러분이 애플리케이션을 만드는 과정에서 코드를 바꿔야 했던 이유를 적어보세요."

일단 책에서 제시하고 있는 두가지 이유는 다음과 같은 상황이다.(Head First Design Patterns 46쪽)

  1. 고객이나 사용자가 다른 것을 요구하는 경우, 또는 새로운 기능을 원하는 경우
  2. 회사에서 데이터베이스 종류를 바꾸고, 데이터도 전과 다른 데서 구입하기로 했는데, 새 회사에서 다른 데이터 형식을 사용하는 경우. 정말 골치 아프죠.

이 글을 읽으면서 현재 내가 애플리케이션을 개발하는 과정에서 소스 코드에 변화가 발생하는 경우를 정리해봤다. 내가 정리한 내용은 다음과 같다.
사내에 새로운 서비스가 오픈 하면서 내가 운영, 개발하고 있는 서비스와 연동하려는 경우. 또는 내가 운영하고 있는 서비스와의 의존 관계에서 변화가 발생한 경우

  1. 개발자가 자신이 만들었던 코드가 마음에 들지 않아서 개선하려고 하는 경우. 흔히 리팩토링 활동을 통해서 변경한다.
  2. 기획자의 판단으로 사용자가 이러 이러한 기능이 필요할 것으로 예측하여 기능 추가 및 개선을 하려는 경우
  3. 기획 파트의 상사에 의한 요구 때문에 변경이 발생하는 경우
  4. 개발 파트의 상사에 의한 요구 때문에 변경이 발생하는 경우
  5. 여러 파트(DBA, 디자이너 등등)의 요구 때문에 변경이 발생하는 경우

물론 하나의 서비스에 관여하고 있는 사람들이 많고, 각 서비스를 통하여 자신의 성과를 만들어야 하기 때문에 위에서 제시한 경우보다 훨씬 더 많은 윗분들과 조직으로부터 변경 요청을 받는다. 하지만 모든 일이 그렇듯이 안정적이고 지속적인 서비스를 위하여 모든 요구를 수용할 수 없는 상황이기 때문에 위 요구 중에서 우선 순위를 두어야 한다.

그렇다면 위 요구 중에서 가장 높은 우선 순위를 두어야할 부분은 어디일까? 물론 그 때 그 때의 상황에 따라서 우선 순위가 달라지겠지만 일반적으로 좋은 서비스를 만들기 위하여 가장 큰 가치를 두고 진행해야 할 부분은 "고객이나 사용자가 다른 것을 요구하는 경우, 또는 새로운 기능을 원하는 경우"이어야 할 것이다. 위 목록을 제시하고 "어느 부분에 우선 순위를 두는 것이 좋을까요?"라고 질문을 하면 십중팔구 고객과 사용자에 촛점을 맞추어야 한다고 이야기한다. 또한 그렇게 생각한다. 하지만 개개인이 그런 생각을 가지고 있다고 하더라도 조직 속으로 들어와 버리면 정반대의 상황이 발생한다. 특히 성과 지향주의가 팽배한 조직이라면 더 심각하다.

어느 순간부터 애플리케이션에 변화가 발생하는 상당수는 고객이나 사용자의 요구가 아니다. 그렇다고 체질 개선을 하기 위한 개발자의 리팩토링 활동도 아니다. 대부분의 변화는 윗 분들의 관심사와 성과를 내기 위한 일련의 활동들이 주를 이룬다. 이 같은 상황이 발생하면 애플리케이션의 복잡도는 걷잡을 수 없이 높아진다. 복잡도가 높아지면 그에 따른 체질 개선 활동이 필요함에도 불구하고 우선 순위에서 계속 밀리면서 작은 변화를 수용하는데 점점 더 많은 비용이 발생하게 된다. 증가하는 비용을 감당하기 위하여 점점 더 많은 개발자를 투입한다. 하지만 의사소통 비용과 관리 비용만 증가할 뿐 애플리케이션을 개선하는데는 큰 효과가 없다. 윗분들은 개발자까지 몇 배로 지원했는데 효과가 없다면서 개발자들에게 불만을 토로한다. 그러면서 생산성을 끌어올린다는 명목으로 새로운 시도들을 계속한다. 개발자들은 효율적이고 창조적인 활동과는 무관한 단순, 반복적인 활동에 많은 시간을 투자하게 된다. 또한 항상 바쁘면서도 재미가 없다.

위 같은 상황은 국내,외의 많은 프로젝트에서 발생하고 있는 상황이다. 특히 조직이 성과 지상주의화 되고, 정치적으로 흘러갈수록 그 경향은 더 커진다는 것을 느낀다. 진정으로 애플리케이션의 성공을 바라고 사용자를 위한다면, 애플리케이션에 변화를 가할 때의 우선순위에 집중해야 할 것이다. 애플리케이션에 책임을 지고 있는 누군가는 모든 요구사항에 Yes라고 대답하는 대신 No라고 대답할 수 있어야 한다. 하지만 마땅히 책임을 지는 사람이 없다면..

사람 또한 건강을 유지하면서 지속적으로 일하기 위하여 운동을 하고, 휴가를 가진다. 쉬지 않고 일할 경우 1,2년이면 체력이 바닥나 일을 하고 싶어도 할 수 없는 상황이 된다. 애플리케이션 또한 1,2년 사용하고 말 것이 아니라면 꾸준한 체질개선 활동이 필요하다. 빠른 성과를 내기 위한 활동도 필요하겠지만 이 같은 변화가 발생한 뒤에는 체질개선 활동이 반드시 뛰따라야 할 것이다. 그렇지 않을 경우 점점 더 커지는 몽뚱아리 때문에 언젠가는 더 이상 움질일 수 없는 상황이 발생할 것이다.

Posted at 12월 01, 2009 by 자바지기 | 0 comments
Last changed 3월 16, 2009 11:29 by 자바지기
Labels: notice

안녕하세요~

쭈라니입니다.

이번달에 재성오빠의 네번째 책이 출간 됐습니다. - 자바 프로젝트 필수 유틸리티

책 출간도 축하할 겸~

간만에 얼굴들도 볼 겸~

겸사겸사 번개 한번 올립니다~

오실 분들은 미리미리 연락 좀 주시구요~

금요일이니 자리 선정하고 예약을 해 놔야 할 것같네요~

오랜만에 얼굴 보고 즐겁게 담소 한번 나눠 보시죠~~~~ ^^

금욜날 뵈용~

p.s : 재성오빠, 쭈라니, 케니군은 디폴트!!

Posted at 3월 16, 2009 by 자바지기 | 3 comments
Last changed 2월 27, 2009 17:39 by 자바지기
Labels: devs

2008년 내내 신경을 쓰게 만들었던 책이 이제서야 출간된다. 회사를 다니면서 책을 쓴다는 것이 이렇게 힘든 일인 줄 다시금 느낄 수 있었다. 책 이름을 필수 유틸리티 시리즈에 맞추어서 자바 프로젝트 필수 유틸리티로 결정되었다.

근 3년만에 다시 쓴 책이고 직장 생활을 하면서 틈틈이 쓴 책이기 때문에 기쁜 마음이 크지만 한편으로 부족한 부분도 눈에 보이기에 아쉬운 마음이 큰 것도 사실이다. 이 책에서 이야기하고 있듯이 개발 프로세스와 개발 환경은 지속적으로 변화해나갈 수 밖에 없다. 나 또한 지금도 더 좋은 환경을 만들기 위하여 고민하고 있다. 이 책이 끝이 아니라 시작이라 생각하고 더 좋은 개발 프로세스와 개발 환경을 만들어 나갈 수 있도록 노력하겠다.

Posted at 2월 27, 2009 by 자바지기 | 6 comments
Last changed 2월 04, 2009 14:04 by 자바지기
Labels: notice

지금까지 토론마당 Space로 유지되었던 공간을 커뮤니티 공간으로 변경합니다. 위키를 통하여 원할하지는 않겠지만 작은 커뮤니케이션 공간을 만들려고 노력하다가 이와 같은 생각을 했습니다.

현재 모든 컨텐츠는 Tree 구조로 확인할 수 있기 때문에 페이지를 하나의 질문으로 생각하고 그에 따른 답변을 Comment로 처리한다면 충분히 기존의 커뮤니티와 비슷한 형태로 가져갈 수 있다고 생각합니다. 물론 익숙하지 않아서 다소 불편한 점이 있겠지만 한번 사용하면 쉽게 적응할 수 있으리라 생각합니다. 우선 다양한 시도를 해보다가 효과가 없다고 판단되면 다른 방식으로 운영하도록 하겠습니다.

이 공간을 활용하는 방법은 커뮤니티 Space 페이지 Tree에서 자신이 작성하고 싶은 주제 페이지로 이동한 후 페이지를 추가하시면 됩니다. 그리고 자바지기 메인 페이지의 우측 상단에 있는 Recently Update 공간은 커뮤니티의 최신 업데이트 상황을 파악할 수 있는 공간입니다. 모든 Space에 대한 최신 변경 사항은 좌측 하단에서 확인할 수 있도록 했습니다. 그 이유는 자바지기 대부분의 컨텐츠가 검색을 통하거나 Space를 통하여 직접 접근하는 것이 대부분이기 때문에 굳이 모든 Space의 컨텐츠의 변경 사항을 확인하는 사용자는 많지 않다고 판단했습니다.

앞으로도 지속적인 변화를 통하여 여러분이 사용하기 편하도록 변경해 나갈 수 있도록 하겠습니다.

Posted at 2월 04, 2009 by 자바지기 | 0 comments
Last changed 2월 04, 2009 12:55 by 자바지기
Labels: confluence

자바지기 위키를 사용하다보면 자신이 자주 접근하는 페이지가 발생합니다. 예를 들어 자바지기 스터디에 참여하고 있다면 자바지기 스터디를 관리하는 오픈 소스 스터디 페이지에 자주 방문할 것입니다. 자신이 자주 방문하는 페이지의 Depth가 깊지 않으면 상관없지만 3,4번 이상의 클릭을 통해서 페이지에 접근해야 한다면 Confluence 위키의 즐겨찾기 기능을 사용하시면 됩니다.

Confluence 위키의 즐겨찾기 기능을 사용하는 방법은 다음과 같습니다. 먼저 즐겨찾기에 추가하고 싶은 페이지에 접근합니다. 페이지 우축 상단에 있는 Tools 메뉴를 클릭 >> Favourite 메뉴를 선택합니다.

Favourite 메뉴를 실행한 후 Confluence 위키의 메인 페이지로 이동하면 페이지 우측 하단의 "Favourite Pages" 섹션에 조금 전에 추가한 페이지가 등록되어 있는 것을 확인할 수 있습니다. 만약 즐겨찾기에서 제거하고 싶다면 아래 화면에서 제거하고자하는 글의 우측에 있는 별표를 클릭하면 됩니다.

자신이 즐겨찾는 페이지를 최대 10대까지 등록하여 관리할 수가 있습니다. 자바지기 위키에서 자주 방문하는 페이지가 있다면 즐겨찾기 기능을 통하여 접근하면 좀 더 쉽게 활용할 수 있습니다.

Posted at 2월 04, 2009 by 자바지기 | 0 comments
Last changed 2월 03, 2009 17:18 by 자바지기
Labels: notice

사이트 개편을 하면서 몇가지 테스트를 해볼 생각입니다. Google Analytics의 통계 데이터를 분석해 자바지기 사이트에 접근하는 사용자의 유형도 분석하고 사용자들이 자주 접근하는 컨텐츠에 대해서도 분석할 계획입니다.

이 분석 작업을 하면서 Adsense에 대한 테스트도 같이 진행할 생각입니다. Adsense 수입이 많지는 않지만 그래도 자바지기 사이트를 유지하면서 유일한 수입이기 때문에 사용자의 패턴을 분석해서 가장 최적화된 위치에 배치하기 위한 테스트입니다. 한달 정도 유지하고 클릭율이 저조한 곳은 제거할 계획입니다. 당분간 불편하더라도 이해해 주시기 바랍니다. 현재 이틀 정도 테스트해봤는데 메인에 걸려있는 광고의 경우 거의 무용지물이네요. 이와 같은 데이터를 바탕으로 효과가 없는 광고는 지속적으로 제거해 나갈 계획입니다.

앞으로는 개발자가 자바지기 사이트를 자주 찾는 이유를 분석해 그에 맞는 방향으로 컨텐츠를 쌓아 나가도록 하겠습니다. Google Analytics의 통계 데이터를 일부 분석한 결과 2,3년전에 공들여 작성한 문서들이 확실히 활용도가 높네요. 최근에 작성한 문서는 바쁜 일정 때문에 허겁지겁 만들다보니 아무래도 그 만한 가치를 발휘하지 못하는 것으로 판단됩니다. 앞으로 더 좋은 컨텐츠를 만드는데 공을 들이라는 것으로 판단됩니다.

Posted at 2월 03, 2009 by 자바지기 | 0 comments
Last changed 2월 01, 2009 18:35 by 자바지기
Labels: notice

새롭게 업그레이드한 자바지기 위키에 아직까지 몇가지 버그가 있습니다. 하니씩 잡아나가고 있는데 한번에 모두 해결하기는 힘들 것으로 판단됩니다. 서비스 운영하면서 조금씩 해결해 나가도록 하겠습니다.

제가 알고 있는 버그만 정리하면 다음과 같습니다.

  • 한글 검색이 되지 않는다. 검색 값으로 한글을 입력하면 입력한 값이 깨지는 현상이 발생합니다. 과거에도 초기에 이 같은 현상이 발생했는데 어찌 어찌 해결했는데 아직 해결 방법을 찾지 못했습니다.
  • PDF에서 한글 깨지는 문제가 있습니다. 이 문제는 백기선씨가 해결한 방법이 있더군요. 그 해결 방법을 이용해서 조만간 해결하도록 하겠습니다.

저도 사용하면서 발견되는 버그들 정리하고 하나씩 해결해 나가도록 하겠습니다. 서비스 사용하다가 불편한 점이나 버그라고 생각되는 내용들 있으면 올려주시기 바랍니다. 대부분이 한글과 관련된 문제라 생각됩니다.

Posted at 2월 01, 2009 by 자바지기 | 3 comments
Last changed 2월 01, 2009 12:18 by 자바지기
Labels: notice

그 동안 자바지기 서버의 사양이 낮아서 서비스가 불안정한 상태로 운영되었습니다. 2009년을 맞아 서버 사양을 높이기 위하여 여러 곳과 접촉한 결과 지금까지 서버 호스팅을 무료로 지원해 주었던 i-heart에서 더 좋은 사양의 서버를 지원해 주셨습니다.

서버 사양을 높이면서 Confluence 위키 버전 또한 최신 버전으로 업그레이드를 진행했습니다. 그리고 지금까지 커뮤니티 위주로 운영되던 서비스를 위키 위주로 운영하도록 변경했습니다. 커뮤니티 서비스는 기존의 컨텐츠는 그대로 제공하고 새로운 글의 입력 및 수정이 불가능하도록 운영할 계획입니다. 최근 커뮤니티에 대한 활용도가 낮아지는 관계로 이와 같은 결정을 내렸습니다.

커뮤니티가 사라지는 대신 위키를 통하여 다양한 커뮤니케이션이 가능하도록 만들어나갈 계획입니다. 위키를 활용한 커뮤니케이션에 대하여 여러분의 많은 아이디어가 있었으면 좋겠습니다.

Posted at 2월 01, 2009 by 자바지기 | 3 comments
Last changed 9월 28, 2007 12:32 by 자바지기
Labels: myspace

구글 Analytics를 통하여 확인할 수 있는 유용한 기능 중의 하나는 내 사이트를 방문하는 사용자들이 어떤 경로를 통하여 접근하는지를 파악할 수 있는 것이다. 예상은 하고 있었지만 가장 많은 유입 경로는 역시 구글이였다. 검색을 통하여 유입이 상당한 비중을 차지하고 있었으며, 직접 사이트를 방문하는 사용자는 예상보다 많지 않았다. 또한 Referer를 통하여 유입 되는 사용자도 상당히 많다는 것을 확인할 수 있었다.

Google Adsense를 통한 수익이 지속적으로 발생하고 있어 그 이유가 궁금했는데 검색 엔진을 통하여 새롭게 유입되는 사용자들 때문인 것으로 추정된다. 앞으로 위키의 컨텐츠를 더욱 강화하여 검색을 통한 사용자들의 유입이 더 많도록 유도할 필요가 있을 것으로 생각합니다.

검색 엔진을 이용할 때 주로 검색하는 키워드를 살펴보면 다음과 같다.

Maven이 다른 수치에 비하여 높은데 이는 자바지기 위키가 maven을 심도 있게 다루고 있는 것이 아니라 국내에 Maven 관련한 문서가 너무 없다라는 생각이 든다. Maven에 대한 개발자들의 관심사는 점점 더 높아지고 있는데 국내에 참고할만한 문서가 없기 때문에 자바지기에 있는 일부 자료를 참고하기 위하여 방문하는 것으로 생각한다. 그 외에 설치 관련된 자료를 찾기 위하여 방문하는 개발자들이 많다는 것을 알 수 있다. 최근 ORM에 대한 관심도도 높아지면서 ORM, Hibernate, IBatis와 관련한 키워드도 높은 비중을 차지하고 있다. 오히려 Spring과 Struts에 대한 키워드는 많지 않다는 것을 알 수 있다. 이는 국내의 많은 사이트, 블로그들이 Spring과 Struts에 대하여 이미 다루고 있기 때문일 것이라 생각한다.

아직 구글 Analytics를 이용한지 그리 많은 시간이 지나지 않아 신뢰할만한 데이터는 아닐지라도 향후 커뮤니티를 운영하는데 많은 참고자료가 될 것으로 생각한다. 또한 개발자들이 원하는 내용이 무엇인지를 파악해볼 수 있는 유용한 정보가 되리라 생각한다.

Posted at 9월 28, 2007 by 자바지기 | 0 comments

최근 자바지기 커뮤니티의 통계 정보를 좀 더 자세하게 알고 싶어 통계툴을 찾던 중 Google Analytics를 알게 되었다. 대부분의 통계 기능이 내가 원하는 정보를 제대로 알려주지 못하는 관계로 그리 큰 기대를 하지 않고 사용하게 되었다. 그러나 예상했던 것보다는 훨씬 더 많은 정보가 나에게 필요한 정보들을 제공해주고 있어 이 곳에 간단하게 소개하고자 한다.(아래 통계 정보들은 자바지기 위키의 통계 정보이다.)

통계 페이지의 첫 화면은 통계 기능의 Overview를 볼 수 있는 Dashboard 페이지이다. Dashboard 페이지에서는 총 방문자에 대한 요약 정보를 볼 수 있다. 일별 방문자, 방문자의 접속 시간, 방문자 당 본 페이지 뷰등 다양한 정보들을 제공하고 있다. 그외 각 지역별 접속자 정보, 페이지별 방문횟수, Referer 정보등 관심을 가질 만한 모든 정보들을 한눈에 볼 수 있도록 제공해주고 있다.

Visitors Overview 기능은 각 방문자들에 대한 브라우저, Connection Speed와 접속하는 사용자들의 사용 패턴을 보여주고 있다. 그 외에도 총 방문자 수, Unique 방문자 수, Page View, 평균 페이지 뷰 등 다양한 정보를 볼 수 있다.

나에게 흥미로웠던 한가지는 Map Overlay 정보였다. 자바지기 위키에 접속하는 사람들이 어느 지역에서 접근하는지를 알 수 있어 좋았다. 처음에는 큰 기대하지 않고 봤는데 국내만이 아닌 상당히 다양한 국가에서 접속하고 있다는 것을 알 수 있었다. 개인적으로 상당히 기분이 좋았다.

5일 동안 자바지기 위키를 방문한 사람들은 총 37개 국가에서 방문하고 있었다. 우리나라가 가장 많은 방문자를 기록한 것은 당연한 결과였으며, 두번째로 많은 국가는 일본이였다. 최근에 일본에 진출한 개발자들이 많다고 하는데 위 결과를 보아도 알 수 있을 것 같다. 그 다음으로 중국, 미국, 인도 순이였다. 많은 수는 아니였지만 소수의 개발자들까지 방문하고 있는 사이트라는 것에 은근히 기분이 좋았다.

Posted at 9월 22, 2007 by 자바지기 | 0 comments
Labels: devs

JCO 주최로 오픈 소스 컨퍼런스를 진행한단다. 내가 몸담고 있는 NHN이 골드 스폰서로 참여한다고 한다. 각 스폰서에 대한 스폰서 섹션이 있는데 해당 스폰서 섹션의 강의를 내가 담당했으면 좋겠다는 제의를 받고 흔쾌히 수락했다. 그런데 막상 수락하고 보니 무슨 이야기를 해야할지 이 막막하다. 아무래도 이번 추석 연휴를 너무 쉬지 말고 고민 좀 하라는 계시인가보다.

무슨 이야기를 하면 재미있어 할까? 내 자신에게는 또 다른 기회가 되지 않을까 생각한다. 아마도 내가 지금까지 강의한 세션 중에서 가장 많은 사람들 앞에 서게 될 거 같은데 벌써부터 긴장과 흥분이 밀려오는거 같다.

Posted at 9월 21, 2007 by 자바지기 | 2 comments
Last changed 9월 03, 2007 19:29 by 자바지기
Labels: myspace


사회 생활을 하면서 일한 결과물에 대하여 평가를 받지 않는 경우는 없다. 사소한 작업일지라도 평가와 결부되는 경우가 많다. 사실 평가라는 것이 잘하면 그만이고, 잘못할 경우에는 상당히 큰 파급효과를 가져온다. 많은 팀원들이 떠나는 경우까지 발생할 수 있다. 평가에 따라 성과 Incentive가 달라지고 연봉이 결정된다면 모든 일은 평가와 결부되는 경우가 많다.

지금까지 직장 생활을 하면서 제대로 된 평가를 받아본 경우가 없으며, 그로 인해 Incentive까지 받아본 경험은 없다. 현재 직장에서 처음 해보는 경험이었다. 현재 직장에서 총 3번의 평가를 받았다. 평가를 처음 받을 때는 은근히 신경이 쓰이고 기대치는 높아만 갔다. 그러나 모든 직장인들이 그렇듯이 자신이 기대한 만큼의 평가를 받는 일은 쉬운 일이 아니다. 모든 직장인들이 자신이 하고 있는 가장 힘든 일이며, 가치 있는 일이라고 판단하고 있기 때문에 모든 이들이 만족할만한 평가를 하기는 더더욱 힘든 일이다. 또한 하는 일의 성격은 비슷하지만 개인별로 맡고 있는 서비스에 따라 평가 결과가 달라진다는 인식이 확산되면 평가를 잘 받지 못한다고 생각되는 서비스를 맡기 꺼려하는 현상이 발생한다.

현재 직장의 평가는 1월, 7월 두번에 걸쳐 진행된다. 이렇게 두번에 걸쳐 진행되는 평가로 인해 많은 서비스들이 이 때를 오픈 목표일로 잡고 애플리케이션을 개발하는 경향이 상당히 강하다. 애플리케이션의 성격에 따라 더 많은 시간과 품질을 요구함에도 불구하고 평가라는 틀 속에도 더 빠른 오픈을 강요받고 있다. 이 얼마나 가슴 아픈 현실인가? 고객들의 만족을 최우선시 해야하는 서비스에서 고객의 만족보다 자신들의 평가를 더 중요시하고 있는 모습을 보면서 가슴이 저려오는 것을 느낀다. 비지니스적인 가치를 앞세우면서 오픈한 서비스는 당연히 많은 문제점을 가질 수 밖에 없으며, 이에 대한 많은 책임은 유지보수를 담당하고 있는 개발자들에게 전가되는 형국이다. 신규 서비스를 오픈하는 개발자들은 좋은 평가를 받을 수 밖에 없으며, 뒷치닥거리하는 유지보수 개발자들은 밀려드는 고객 문의에 허덕이면서 자신의 가치를 발휘하지 못하고 있다.

나 또한 "평가에 대하여 전혀 신경쓰지 않는다."라고 확신할 수는 없다. 하지만 단편적인 평가 결과에 연연하는 행태는 보이고 싶지 않다. 장기적인 관점에서 서비스를 바라보며, 고객들의 요구사항을 받아들이는 모습이 서비스 기획, 개발자의 자세가 아닐까 생각한다. 이 같은 행동이 단기적으로 나쁜 평가를 받을 수 밖에 없겠지만 장기적인 관점에서는 지속적으로 좋은 평가를 받을 수 있는 지름길이지 않을까? 그리고 평가에 연연해 자신의 목소리를 낼 수 없는 것보다는 자신이 하고 싶은 일을 추진하는 것이 개인적으로는 더 좋은 결과를 가져온다고 확신한다. 개인에 따라 평가가 자신이 하고 싶은 일보다 더 우선시 될 수 있겠지만 이 같은 결과는 결국에 자신만 지치지 않을까 생각한다. 자신이 기대한 결과 만큼의 평가 결과가 나오지 않는다면 그 때의 좌절감이 얼마나 클까?

개발자로서의 길도 똑같지 않을까? 단기적으로는 자신에게 큰 소득이 없는 일이지만, 자신이 좋아하는 일이며 장기적으로 비전이 있는 일이라면 한번 도전해 볼만한 일이지 않을까? 많은 이들이 너무 단편적이고 단기적인 부분만 고민하고 있는 듯하다. 좀 더 멀리볼 때 자신이 진정 원하는 일을 할 수 있지 않을까?

기반이 잘못 만들어져 있는 애플리케이션을 원상복귀하는데 얼마나 많은 시간이 소요될까? 1년, 2년.. 아니 어쩌면 10년이 걸릴지도 모른다. 그 이유는 리팩토링 진행하는 만큼 새롭게 리팩토링해야하는 소스가 만들어지기 때문이다.

최근 평가에 대하여 고민하는 부분은 개인 단위가 아닌 팀 단위로 평가가 행해졌으면 좋겠다. 많은 선진국들이 개인 위주의 평가에서 팀 단위의 평가로 변화하고 있다고 한다. 국내에도 개인 단위의 평가가 아닌 팀 단위의 평가가 더 객관적이라는 생각이 든다. 피플 웨어에서 이야기하듯이 기술적으로 뛰어난 개발자만이 꼭 필요한 존재는 아니 듯이.. 팀을 보면 팀의 활력소를 제공하는 감초 같은 이들이 있을 때 팀워크가 향상된다는 것을 국내의 많은 관리자들이 느낄 수 있었으면 좋겠다.

Posted at 9월 03, 2007 by 자바지기 | 2 comments
Labels: reviews

지금까지 웹 애플리케이션 개발 경험이 7년이 되어간다. 7년이 되는 지금까지 대부분의 개발 경험이 신규 프로젝트였다. 신규 프로젝트의 경우에는 새롭게 만든 애플리케이션이 정상적으로 동작하는 것이 확인되면 유지보수를 담당하게 될 개발자들에게 인수인계를 마치고 빠지는 형태로 지금까지 개발해왔다. 그리고 운영 업무보다는 신규 개발 업무가 훨씬 어려운 작업이며, 대단한 작업으로까지 생각하며 살아왔다. 그러나 7년의 마지막 1년.. 즉 최근 1년은 유지보수 업무와 개발 업무를 병행하고 있다. 처음 유지보수 업무를 맡았을 때 상당한 거부감이 생긴 것 또한 사실이다. 시간이 지나면서 다른 개발자이 개발한 소스코드를 분석하고 개선해 나간다는 것이 얼마나 어려운 작업인지를 새삼 느끼고 있다. 좀 더 빨리 유지보수를 업무를 해봤다면 나의 개발 스타일에도 많은 변화를 가져왔으리라 생각한다.

유지보수 업무를 맡은지 얼마되지 않아 이 책을 읽기 시작했다. 이 책의 "Legacy Code"라는 단어에 필이 꽂혀 책을 선택하게 되었다. 현재 내가 맡고 있는 모든 소스코드를 Legacy Code로 간주하고 좀 더 효율적으로 개발하고 싶은 욕심에 선택하게 되었다. 사실 처음에는 큰 기대없이 읽기 시작했다. 그러나 기대와는 달리 너무 많은 것을 느끼게 하는 책이다. Chapter를 하나씩 읽을 때마다 필자가 Legacy Code들과 얼마나 많은 시간을 싸워왔는지 피부로 느낄 수 있었다. 사실 운영 업무의 시작단계라 할 수 있는 나는 생각할 수 조차 없는 다양한 방식으로 Legacy Code가 가지고 있는 문제점들을 해결해나가는 것에 많은 것을 배울 수 있었다.

유지보수 업무의 핵심은 기존 기능을 변경하지 않는 상태에서 소스코드를 리팩토링하는 것이라 할 수 있다. 이 책은 이에 대한 다양한 해결책을 제시하고 있다. 기존 Legacy Code가 가지고 있는 문제점과 성격에 따라 다양한 해결책을 제시하고 있다. 특히 Legacy Code를 Step by Step으로 리팩토링해 가는 과정은 감동 그 자체이다. 테스트를 만들 수 없을 것으로 생각되는 Legacy Code에 테스트 코드를 만들어 가는 과정이 특히 많은 것을 배울 수 있게 했다. 지금까지 Legacy Code의 가장 큰 문제점은 테스트 코드가 없다는 것이다. 그러므로 기능을 추가하거나 리팩토링을 하더라도 해당 기능에 대해 검증할 수 있는 안정장치가 없으므로 인해 유지보수하기 힘든 것이 사실이다. 이 책은 기존의 Legacy Code에 테스트 코드를 어떻게 만들어 나갈 수 있는지에 대하여 많은 부분을 할애하고 있다.

많은 개발자들이 신규 프로젝트는 유지보수 성격의 없는 것으로 착각하고 있다. 그러나 신규 프로젝트 또한 프로젝트가 중,후반으로 진행될수록 지금까지 개발했던 코드들에 대한 유지보수 업무가 발생한다. 고객들의 요구사항은 언제든지 변경될 수 있기 때문이다. 따라서 이 책은 유지보수 업무를 담당하고 있는 개발자들에게만 필요한 것이 아니라 애플리케이션을 개발하는 모든 개발자들에게 필요한 내용이다. 신규 프로젝트를 진행하고 있는 개발자들도 자신이 개발하고 있는 소스 코드를 유지보수할 때 어떻게 하면 좋을지에 대해서 같이 고민할 필요가 있다. 현재 기능만 정상적으로 동작하면 되겠지라는 안이한 생각은 프로젝트 막바지에 자신의 발등을 찍는 경우가 종종 있다. 이 같은 코드는 추후 유지보수 업무를 전담하는 개발자들에게 큰 업무 부담으로 작용한다. 유지보수 용이한 소스코드를 작성하는 것이 다른 개발자들을 위하는 것이 아니라 자기 자신을 위하는 것이라는 것을 생각하고 이 책을 반드시 읽어봤으면 하는 바램이다. 그리고 현재 자신이 개발하고 있는 소스 코드가 이 책이 지적하고 있는 형태로 개발되고 있다면 이 책이 제시하는 방법을 이용해서 리팩토링해보는 습관을 들이는 것이 어떨까..?

유지보수 업무가 항상 재미없는 것만은 아니다. 유지보수 업무를 하면서 다른 개발자들이 구현해 놓은 소스코드를 보고 리팩토링하는 것도 무엇보다 중요한 업무이며, 많은 재미를 부여한다. 다른 개발자가 구현한 코드를 리팩토링하면서 자기 자신 또한 많은 성장을 가져올 수 있으며, 자신이 신규 프로젝트를 진행할 때 여러가지 상황에 대하여 고려하는 능력까지 키우게 된다. 나는 7년이 지난 지금에서야 유지보수 업무의 중요성을 느끼고 있다. 많은 개발자들이 좀 더 빠른 시기에 유지보수 업무를 해보는 것도 개발자로서 성장하는데 큰 도움이 되리라 생각한다. 이 책은 개발자들이 유지보수 업무를 맡아 막막할 때 새로운 즐거움을 느끼게 해 줄 책이다. 바쁜 업무 때문에 정독하는데 6개월이 걸렸지만 지금부터 다시 한번 읽고 실행해 옮겨볼 생각이다.

Posted at 8월 31, 2007 by 자바지기 | 2 comments
Labels: myspace

NHN에 입사하면서 계획했던 목표중의 하나가 영어였다. 내가 지금까지 살아오면서 가장 싫어하는 과목 중의 하나가 영어였다. 지금은 책까지 쓴 입장이지만 사실 난 국어와 영어를 가장 싫어했다. 국어 중에서도 시를 가장 싫어했다. 수학처럼 공식에 의하여 정확하게 떨어지는 답이 아닌 경우에는 답을 유추해내기가 너무 힘들었다. 특히 시는 은유적인 표현으로 인해 내포되어 있는 의미를 찾기란 더더욱 힘들었다. 고등학교 때의 점수를 보면 극명하게 들어난다. 수학이 거의 만점 수준이였다면 국어와 영어는 항상 반타작 수준이였으니.. 국어와 영어를 좀 더 좋아했더라면 지금과는 다른 삶을 살고 있으리라..

대학교 때도 나의 생각은 변함이 없었다. "영어가 뭐 중요해..난 영어 안하고 평생 먹고 살리라!"는 다짐을 하면서 영어와는 완전히 벽을 쌓고 살아왔다. 그런 각오로 진출한 사회생활.. 내가 몸담고 있는 이 바닥은 영어 아니면 새로운 지식 습득을 할 수 없을 정도로 많은 곳에서 영어를 사용하고 있다. 새로운 지식을 얻기 위해서 읽는 수 많은 영어 Article.. 자주 방문하는 대부분의 프로그램 관련 사이트는 죄다 영어이니..책은 또 어떠한가? 비싸지만 책꽂이에 꽂혀 있는 대부분의 책이 원서이다. 책 넘어가는 속도는 느리지만 그 속에서 얻게 되는 지식의 량이 무한정 크기에 포기할 수 없는 상태이다. 이제는 영어와 친구가 되기로 마음을 고쳐먹었다.

그렇게 싫은 영어를 하고자 하는 이유는 프로그래밍이 재미있고 좋기 때문이다. 더 많은 개발자들과 커뮤니케이션 하고 싶고, 더 많은 지식을 빠른 시간내에 습득하고 싶은 욕심 때문에 영어 공부를 시작하기로 마음먹었다. NHN에 입사할 때 여유가 생기면 바로 영어공부를 시작하리라 생각했는데 지금까지 바쁘다는 핑계로 미루고만 있었다. 이렇게 살아서는 안되겠다는 생각으로 드디어 영어학원 등록.. 다음주 월요일부터 영어와 가까워지려는 노력이 시작된다. 나의 콩글리쉬 발음에 우스워할 학원생들의 얼굴이 눈에 선하다. 나의 하루 일과가 바쁘게 시작될거 같다. 전날에 술 먹는 것도 자제해야 겠다는 생각이다.

6시 20분 기상 => 7시 용인 죽전 출발 => 7시 40분 분당 야탑까지 자전거로 이동 => 8시에서 9시까지 영어 회화 수업 => 9시 30분 자전거로 회사 이동

영어 공부를 시작하면서 운동량까지 늘려볼 생각이다. 지금까지 9개월을 자전거타고 출퇴근 했는데 살이 잘 안빠진다. 아무래도 회사와의 거리가 너무 가까워서 인듯하다. 지금까지 3kg 빠졌다. 학원까지는 대략 40분정도 소요되기 때문에 상당한 운동량이 되지 않을까 기대해본다. 거기다 영어까지..약간 무리한 계획이기는 하지만 답사를 해본결과 야탑까지 자전거로 출퇴근하는 것이 그리 힘들지 않을거 같다. 그 동안 운동량이 좀 되는지라 큰 무리없이 갈 수 있었다.

지금까지 살아오면서 학교를 제외한 학원을 다니는 것은 이번이 두번째이다. 첫번째 학원은 자바를 배우기 위해 다녔던 삼성 멀티캠퍼스이다. 나의 첫번째 학원 경험이 밥벌이를 위한 곳이 될 줄은 꿈에도 생각지 못했다. 이번이 두번째인 만큼 흥분되기도 한다. 사실 내가 학교 다닐 때는 사교육도 많지 않았고, 너무 깡촌이라 학원도 없었다. 중,고,대 모두 학원 다닐 필요도 없었다. 역시 사회 나오니 또 다른 도약을 위해서 학원을 선택하는 것도 좋은 길이라 생각된다. 너무 학원을 다닌 경험이 없어서인지 내 아이에게 너무 많은 학원을 강요하기는 싫다. 모든 것이 남이 아닌 자신이 선택하고 길을 만들어 가듯이 배우는 것 또한 그러하리라 생각하는데.. 주위의 많은 사람들은 나랑 다른 생각을 하고 있어서 힘들다. 심지어 내 아내까지도 완전히 다른 생각을 하고 살아가고 있으니..

이런 우여곡절 끝에 영어 학원에서 사용할 Nickname이 필요하다. 개인적으로 자바지기를 너무 좋아해서 사용하려고 했으나 주위에서 너무 길어서 좋지 않다는 반응이다. 앞으로 영어 관련해서는 계속 사용할 Nickname이라 좋은 Nickname 있으면 추천 좀 해줬으면 좋겠다. 외국인이 발음하기 쉬우면서 기억에 남을 만한 그런 Nickname.. 좋은 Nickname 만들어주는 이에게는 맛있는 식사한끼 대접한다.

기대하시라..조만간 영어 강좌가 위키의 많은 부분을 차지할지도 모른다.

Posted at 8월 30, 2007 by 자바지기 | 8 comments
Labels: devs

근 한달만에 블로그에 글을 쓴다. NHN에 입사해서 팀장 역할을 맡고 어리버리한 상태에서 4개의 프로젝트를 동시에 진행해야 되는 상황.. 팀장이 무슨 역할을 해야되는지도 모르는 상태에서 맡겨진 프로젝트들.. 상상만해도 끔찍하지 않겠는가? 어제 상반기부터 진행해오던 4개의 프로젝트 중 마지막 프로젝트인 블로그 위젯을 오픈 했다.

정말 많은 우여곡절 끝에 여기까지 끌고 왔다. 8월이 지나가고 있는 지금에서야 나의 2007년 상반기 업무가 완료된거 같아 마음이 홀가분하다. 그 동안 초보 팀장 밑에서 같이 고생하고 같이 웃어왔던 우리 팀원들이 있었기에 여기까지 올 수 있었으리라 생각한다. 그 동안 너무 여러개의 프로젝트로 인해 소홀히한 많은 일들을 이제부터 조금씩 챙겨나가야 겠다. 팀장이 되면 하고 싶었던 일들이 많았는데 아직 하지 못한 일들이 많다. 지금부터라도 여유를 가지고 하나씩 만들어 가는 작업을 하고 있다.

힘든 2007년 상반기 였지만 개인적으로 팀의 문화와 Teamwork을 형성하는데는 성공했다는 생각이 든다. 그리고 팀원들의 성향을 파악하고 팀원들이 자유롭게 일할 수 있는 공간으로 만들기 위하여 노력한 결과들이 조금씩 나타나고 있는 것으로 느끼고 있다. 묵묵히 일만하고 회의에서도 침묵으로 일관하던 초보 개발자들이 점진적으로 참여하는 모습을 보면서 현재 팀이 가고 있는 방향이 맞다는 것을 느끼게 된다. 요즘은 너무 시끄러운(내 목소리가 너무 커서이리라..) 팀이 되어서 다른 팀이 좀 조용히 해달라는 에피소드까지 생기고 있는 상황이다.

개인적으로 상당히 시끄러운 팀을 원한다. 개발자들이 자유롭게 이야기하고, 토론할 수 있으며, 열정이 느껴지는 그런 팀.. 우리 팀이 점점 더 그러한 모습으로 변해가는 것을 보면서 내 자신 또한 많은 열정을 느끼고 있다. 아직 부족한 부분이 많지만 새롭게 시도하는 일들에 거부감없이 따라주는 팀원들이 고맙다. 현재 팀의 변화를 위하여 진행하고 있는 일들을 정리해 보면 다음과 같다.

  • 운영 업무를 맡고 있는 팀원들이 Pair로 업무 진행하는 것. 향후 점진적으로 모든 팀원들이 Pair로 일할 수 있는 분위기를 만들어 나갈 생각이다.
  • 운영 개발자와 기획의 원할한 커뮤니케이션을 가져갈 수 있도록 정기적인 미팅과 Jira의 활용.
  • 사용자 스토리 기반으로 반복주기를 결정하고, 반복주기가 완료될 때 QA를 받도록 개발 프로세스를 정리하는 작업.
  • 선배 개발자들이 신입 개발자들의 스킬 향상을 위하여 일주일에 3-4시간 정도 할애하여 Pair로 업무를 진행할 수 있도록 한다.

이러한 작은 변화들이 아직 큰 성과를 내고 있지는 않지만 조만간 그 효과가 나타나리라 확신한다. 이외에 또 하나 준비하고 있는 작업은 팀원들이 개발하는 산출물에 대한 QA 작업이다. 리팩토링 포인트를 찾고, 버그 발생 부분을 찾는 것이 가능한 개발 환경을 많드는 것이다. 현재 팀장의 위치에서 해야할 역할이지 않을까 생각한다. 개발을 직접하는 것이 아니라 개발한 결과물에 대한 검증과 개발자들이 성장할 수 있는 바탕을 만들어 주는 것.. 나 또한 개발을 좋아한다. 하지만 언제까지나 개발하는 것이 전부일 수는 없는 듯하다. 다른 개발자들이 구현한 소스를 분석하고 그에 대한 Comment를 해주는 것 또한 재미있고 중요한 일이라 생각하면서 준비하고 있다. 나 또한 성장할 수 있으며, 팀원들 또한 나로 인해 성장할 수 있다면 그것이 최상이라 생각하면서 좀 더 역동적인 팀으로 만들어 갈 수 있으리라.

Posted at 8월 30, 2007 by 자바지기 | 1 comment
Last changed 8월 03, 2007 20:18 by 자바지기
Labels: devs

Spring IDE가 끝없이 발전하고 있는 모습을 본다. Mylyn이 Europa 버전에 포함되어 배포되지마자 바로 통합을 지원하고 있다. Spring 2.0.1에서는 Spring IDE의 핵심이라고 할 수 있는 core, 확장 기능을 제공하고 있는 AOP, JavaConfig, Web Flow를 지원하는 extension, Mylyn과의 통합을 담당하는 integration 세개의 파트로 분리된 형태로 플러그인을 제공하고 있다.

개인적으로 특히 관심이 있는 부분은 Mylyn과의 통합 부분이였다. Mylyn과 통합되면서 Spring Bean 설정 파일 중 각 Task와 연관되어 있는 Bean에 대하여 하나의 Context로 관리하는 것이 가능하다. Spring 설정 파일은 정형화된 형태이기 때문에 Java 리소스와 같이 하나의 Context로 관리하는 것이 가능하다.

향후 모든 XML에 대하여 Mylyn과의 통합은 힘들 수도 있지만 Spring 설정 파일과 같이 스키마에 기반한 XML 설정 파일의 경우에는 Mylyn과의 통합이 얼마든지 가능할 것으로 판단된다. 예를 들어 Hibernate나 IBatis 설정 파일 또한 Mylyn과의 통합이 가능할 것으로 판단된다.

Spring IDE가 Spring JavaConfig를 지원하는 줄 몰랐다. 이번에 추가된 기능인지는 모르겠지만 Spring JavaConfig에 대한 지원까지 하고 있는 것이 JavaConfig에 관심을 불러일으킨다. 조만간 JavaConfig도 한번 사용해보리라..

Posted at 8월 03, 2007 by 자바지기 | 0 comments
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.