주요글: 도커 시작하기

요즘 간단한 DB PL SQL 백업 도구를 팀의 막내와 같이 만들고 있다. 오라클 DB의 프로시저 소스를 관리해주는 상용도구가 있겠지만, 비용상의 문제로 그 도구를 사용하지 않기로 결정했다. (음.. 내가 결정한게 아니고 이 기능을 필요로 하는 곳에서 큰 돈을 쓰지 않기로 결정했다.) 그래서, 부득이 오라클 DB의 코드-패키지, 프로시저, 함수-를 주기적으로 백업하는 간단한 어플리케이션을 개발하기로 했다. (음.. 정확히는 타팀의 개발 요청을 받았다.)


요구사항


요구사항은 간단하다.

  • 나: A님, 우리가 만들어야 하는 게 뭐에요?
  • A: DB에 있는 프로시저 소스를 백업해주는 프로그램이요.
  • 나: 백업은 어디다 해요?
  • A: SVN 리포지토리요.
  • 나: 버전 관리를 해야 하는 이유라도?
  • A: 그게 DB 프로시저가 전혀 관리가 안 되기 때문에, 주기적으로 백업해서 변경 이력을 남기고 싶어요.
  • 나: 아, 그럼 매번 전체 프로시저를 백업할 필요는 없겠네요.
  • A: 네, 변경된 것만 커밋하는 식으로 하면 좋겠어요. 변경된 프로시저를 구하는 SQL은 여기(저쪽 팀)에서 제공해줄께요.
오호라, SQL은 제공해 준단다. 우리가 해야 할 건 제공받은 SQL을 이용해서 변경된 PL SQL 코드를 가져오고, 그 코드를 리포지토리에 보관만 하면 된다.
  • 나: 그럼, 지금 바로 시작할 수 있겠는데요. 그런데, 그 쿼리는 언제 주세요?
  • A: 글쎄요. 그거 할 사람이 지금 다른 거 하고 있는데 그거 끝나고 줄께요.
  • 나: (엄..... ) 언제 끝나는데요?
  • A: 아마도 다음주?
  • 나: (엄.................) 네. 일단 할 수 있는 것 먼저 시작하고 있을께요.
구현의 시작

이런, 쿼리를 나중에 준단다. 그렇다고 멍 때리고 있을 이유는 없다. 만들 코드가 많기 때문이다. 변경된 프로시저를 읽어오는 부분은 여기서의 핵심 로직이 아니다. 읽어오는 기능이 있다 치고 핵심 로직과 그 외에 나머지 부분을 모두 만들어 낼 수 있다. (이에 대한 내용은 "저수준의 상세한 내용 없이 구현하기:http://javacan.tistory.com/297" 글을 읽어보기 바란다.)

우리(나+어린개발자1)는 바로 코드를 만들기 시작했다. 가장 먼저 작성한 것은 아래와 비슷한 테스트 코드이다.

public class BackupToolTest {
    @Test
    public void canCreate() {
        BackupTool tool = new BackupTool();
    }

    public class BackupTool {
    }
}

테스트 코드를 먼저 작성한 뒤에, 한 작업은 BackupTool의 행위를 테스트하는 메서드를 작성하는 것이었다.
  • 나: 자 tool의 backup() 메서드를 만들어보자고, 일단 테스트 코드에서 tool을 호출하도록 만들고,
  • 어린개발자1: (열심히 들음)
  • 나: tool 안에서 변경된 코드 목록을 불러와 그걸 로컬 디렉토리에 보관하고, 이를 커밋하도록 만들어야 할 것 같아. tool은 흐름만 관리하게 하고 나머지는 별도 객체가 처리하도록 하자.
  • 어린개발자1: (열심히 들음)
  • 나: 별도 객체가 처리하도록 할 거니까, backup() 메서드를 실행한 뒤에, 그 객체들이 호출되었는지 확인해보면 될 것 같아.
// 빨간색 코드는 컴파일 에러 발생하는 부분
public class BackupToolTest {
    ...
    @Test
    public void runBackup() {
        BackupTool tool = new BackupTool();
        tool.backup();
        verify(dbCodeFinder).findUpdatedDbCodeAfter(any(Date.class));
        verify(localCodeUpdater).update(dbCodeList);
        verify(svnClient).commit();
    }
}

  • 나: 검증 코드를 만들었으니까, 이제 컴파일 에러를 없애 볼까?
  • 어린개발자1: (끄덕임)
  • 나: (아래와 같은 코드를 입력하면서) DbCodeFinder 인터페이스 만들고, Mock 만들고, 나머지도 동일하게 인터페이스와 Mock 만들어주고, Mockito 이용해서 dbCodeFinder의 findUpdatedDbCodeAfter() 메서드가 호출되면 DbCode 목록을 리턴하게 해 주자. 이것들은 아직 구현이 필요 없으니까, 이따가 구현이 필요할 때 실제로 구현하면 될 것 같아.
// 파란색 코드는 새로 추가된 코드
public class BackupToolTest {
    ...
    @Test
    public void runBackup() {
        DbCodeFinder dbCodeFinder = mock(DbCodeFinder.class);
        LocalCodeUpdater localCodeUpdater = mock(LocalCodeUpdater.class);
        SvnClient svnClient = mock(SvnClient.class);

        List<DbCode> dbCodeList = createDbCodeList();
        when(dbCodeFinder.findUpdatedDbCodeAfter(any(Date.class)).thenReturn(dbCodeList);

        BackupTool tool = new BackupTool();
        tool.backup();

        verify(dbCodeFinder).findUpdatedDbCodeAfter(any(Date.class));
        verify(localCodeUpdater).update(dbCodeList);
        verify(svnClient).commit();
    }

    public class BackupTool {
        public void backup() {
        }
    }
    public interface DbCodeFinder {
        public List<DbCode> findUpdatedDbCodeAfter(Date date);
    }
    public interface LocalCodeUpdater {
        public void update(List<DbCode> dbCodeList);
    }
    public interface SvnClient {
        public void commit();
    }
}
  • 나: DbCode에 뭐가 들어올지 아직 모르니까, 일단 클래스만 만들어두자.
  • 어린개발자1: 네~
public class BackupToolTest {
    ...
    ...
    public class DbCode {
    }
}

이후 작업은 테스트를 통과시키기 위한 코드 작업을 진행했고, 몇 차례의 테스트 실패-테스트 통과-코드 정리 과정을 거쳐 아래의 코드가 완성되었다.

public class BackupToolTest {
    @Test
    public void runBackup() {
        DbCodeFinder dbCodeFinder = mock(DbCodeFinder.class);
        LocalCodeUpdater localCodeUpdater = mock(LocalCodeUpdater.class);
        SvnClient svnClient = mock(SvnClient.class);

        List<DbCode> dbCodeList = createDbCodeList();
        when(dbCodeFinder.findUpdatedDbCodeAfter(any(Date.class)).thenReturn(dbCodeList);

        BackupTool tool = new BackupTool();
        tool.backup();

        verify(dbCodeFinder).findUpdatedDbCodeAfter(any(Date.class));
        verify(localCodeUpdater).update(dbCodeList);
        verify(svnClient).commit();
    }

    public class BackupTool {
        private DbCodeFinder dbCodeFiner;
        private LocalCodeUpdater localCodeUpdater;
        private SvnClient svnClient;

        public void backup() {
            List<DbCode> dbCodeList = 
                    dbCodeFinder.findUpdatedDbCodeAfter(getPreviousUpdatedTime());
            localCodeUpdater.update(dbCodeList);
            svnClient.commit();
        }

        private Date getPreviousUpdatedTime() {
            // 어제 날짜 6시 값 리턴
            return ...;
        }

        public void setDbCodeFinder(DbCodeFinder dbCodeFinder) {
            this.dbCodeFinder = dbCodeFinder;
        }
        public void setLocalCodeUpdater(LocalCodeUpdater localCodeUpdater) {
            this.localCodeUpdater = localCodeUpdater;
        }
        public void setSvnClient(SvnClient svnClient) {
            this.svnClient = svnClient;
        }
    }
    public interface DbCodeFinder {
        public List<DbCode> findUpdatedDbCodeAfter(Date date);
    }
    public interface LocalCodeUpdater {
        public void update(List<DbCode> dbCodeList);
    }
    public interface SvnClient {
        public void commit();
    }
    public class DbCode {
    }
}

뭔가 정상적으로 동작하는 코드가 만들어졌다. 이제 테스트 클래스에 중첩 클래스로 구현한 클래스와 인터페이스들을 모두 별도 파일로 분리해냈다. 별 것 없는 테스트 코드를 만들어낸 것 같지만, 우리는 동작하는 코드로 설계를 진행하였다. 초기에 만들어진 클래스와 인터페이스의 설계는 아래와 같다.



DbCode 데이터 도출

주요 인터페이스가 도출되었다. 이제 할 일은 각 인터페이스를 구현하는 것이다. 가장 먼저 진행한 작업은 디렉토리에 읽어온 DbCode를 로컬에 파일로 기록하는 LocalCodeUpdater의 구현이었다. 이를 위한 테스트 코드를 작성했다. 최초에 대화를 주고 받으면 점진적으로 만들어진 테스트 코드는 아래와 같았다.

public class LocalFileCodeUpdaterTest {
    private LocalFileCodeUpdater codeUpdater;

    @Before
    public void setUp() {
        codeUpdater = new LocalFileCodeUpdater();
        codeUpdater.setRepositoryRoot("target/repo");
    }

    @Test
    public void whenNewDbCode_createFile() {
        deleteIfExists("target/repo/S1/PACKAGE/code1.sql");
        DbCode dbCode = dbCode();
        dbCode.setSchema("S1");
        dbCode.setType(Type.PACKAGE);
        dbCode.setName("code1");
        dbCode.setDdl("test ddl");
        List<DbCode> dbCodeList = new ArrayList<DbCode>();
        dbCodeList.add(dbCode);
        codeUpdater.update(dbCodeList);
        assertFileData("target/repo/S1/PACKAGE/code1.sql", dbCode);
    }

    ... // 파일이 존재할 때 수정되는 지 확인하는 테스트 코드
}

 위 테스트 코드를 만드는 과정에서 DbCode가 가져야 할 데이터가 정리가 되었다. 이후 과정은 테스트를 통과시키는 과정에서 LocalFileCodeUpdater의 구현을 완성해 나갔다. 그리고, SvnClient를 구현하는 단계로 넘어갔다.

[이어지는 이야기는 다음에....]



탁월함은 어디서부터 올까? 천부적인 기질? 생각? 행동? 3년 전에 받은 리더십 교육에서 강사가 탁월함을 이끄는 것에 대해 대해 언급을 했었는데, 그 중에 중요한 것으로 꼽았던 것이 바로 '습관'이다. 물론, 좋은 습관을 가졌다고 해서 탁월할 수 있는 것은 아니겠지만, 좋은 습관만으로도 이전보다 더 좋은 결과물을 만들어낼 수 있다고 생각한다. 그리고, 프로그래머에게도 이것이 적용된다고 생각한다.


프로그래머가 가져야 할 좋은 습관 중의 하나로 (요즘 필자가 초식 수련중인) "TDD"를 들 수 있다. TDD는 테스트 코드를 먼저 작성하고, 테스트를 통과 시키고, 그 다음에 리팩토링을 하는 간단한 흐름으로 구성된다. 이 간단한 흐름을 지키는 작은(?) 습관만으로도 다음의 결과물을 얻어낼 수 있다.

  • 테스트 시간을 줄여준다. 손과 눈으로 하는 테스트보다 컴퓨터가 실행하는 테스트가 훨씬!! 빠르다.
  • 테스트를 할 수 있도록 노력하는 덕분에 나름의 좋은 설계가 유도될 가능성이 높아진다.
  • 회귀 테스트를 만들어주기 때문에, 코드 수정에 대한 자신감을 갖게 된다.
  • 반복적인 리팩토링을 함으로써 더러워진 코드를 일정 부분 청소해준다.
  • 결과적으로 전반적인 코드의 가독성이 나빠지는 것을 방지해주거나 가독성을 향상시켜준다.

처음부터 TDD를 잘 하기는 어렵겠지만, TDD를 지속적으로 시도하는 것만으로도 위의 장점 중 몇 가지를 얻어낼 수 있으며, 이는 곧 개발 생산성의 향상으로 연결될 수 있다. TDD라는 (어떻게 보면 작은) 습관이 (TDD를 하지 않는 경우와 비교해서) 생산성을 올려주는 것이다!


작은 습관이 더 나은 결과물로 연결되는 경우의 또 다른 예로 단축키를 들 수 있다. 단축키가 별 것 아닌 것 같지만, 단축키를 잘 활용하는 개발자와 그렇지 못한 개발자의 코드 입력 속도는 많은 차이를 발생시킨다. 마우스를 잡고 이동하고 클릭하고 선택하는 시간보다 단축키를 눌러서 처리하는 시간이 빠르다. 이 시간이 쌓이면 쌓일수록 같은 기간 동안 더 많은 코드를 만들어내고 더 많은 생각을 할 수 있게 되고, 이는 곧 더 나은 품질의 결과물을 더 빠르게 만들어낼 수 있도록 만들어준다.


이 외에 좋은 습관으로 꾸준한 리팩토링, 일을 작게 나누기, 체크 리스트 만들기 등이 있을 것 같다.


좋은 습관. 좋은 습관이 우리를 탁월하게 만들어주진 않겠지만, 좋은 습관을 가진 것만으로도 탁월해 질 수 있는 가능성을 열어준다. 우리 모두 좋은 습관을 가져보자.



  1. 홍성민 2013.12.31 14:35

    늘 좋은글 감사해요

오래된 휴대폰에서 사진을 정리하다가 아래 그림이 나왔다. 2년 반 정도 전에 다니던 회사에서 모바일 게임 개발팀과 개발 범위에 대해 논의하는 회의를 하면서 그린 그림이다.



그 당시 회의를 진행하면서 서로들 다른 소리를 하길래 (실은 몇 명이 잘 못 알아듣길래) 회의 진척을 위해 화이트보드에 그림을 그렸다. 이 그림을 그린 뒤로 서로 오해 없이 대화를 진행한 기억이 난다.


이 그림은 별 것 아니지만, 이 그림이 그려지기 전까지 서로 다른 모습을 상상하며 대화를 했었다. 통신하는 방식도 주요 컴포넌트의 구성도 비슷한 듯 다르게 상상했기 때문에, 대화도 "아,, 그게 아니라....." 이런 식으로 진행되곤 했다. 지식을 시각적으로 표현하고 나서야 비로서 상호 간의 차이를 맞추고 정확하게 의사 소통 할 수 있었다.


올바르게 동작하는 소프트웨어를 만들어야 하는 프로그래머라면, 다른 프로그래머에게 소프트웨어에 대한 지식을 공유할 수 있는 역량이 필수적이다. 이는 아키텍처, 상위 수준 설계, 심지어 코드 수준까지 모두 해당된다. 지식을 서로 제대로 공유하지 못한다면, 해메는 시간이 그 만큼 길어진다.


소프트웨어에 대한 지식을 공유하는 역량을 키울 수 있는 가장 효과적이면서 가장 쉬운 방법은 그림으로 지식을 표현하는 것이라고 생각한다. 게다가 소프트웨어를 다어그램으로 표현하는 표준인 UML도 있다. 아직 다이어그램으로 소프트웨어를 표현하는데 익숙하지 않다면, 기존에 자신이 만든 코드/소프트웨어/시스템 등을 모두 다이어그램으로 표현하는 연습을 해 보자. 그러다보면 소프트웨어를 정확하게 표현하는 역량이 향상될 것이다.


  1. 대관령 2014.04.08 22:31

    바로 이거야~!
    저도 모르게 무릅치고 박수치고 갑니다.

  2. 붉은세상 2014.08.27 16:22

    회의때를 생각하면 늘 발생하는 상황이네요.. 엄청 공감합니다.

좀 거창한 목표가 하나 있는데, 그것은 "국내 프로그래머들의 전체적인 역량을 한 단계 끌어올리는 것"이다. 정말 거창하다. 나 스스로도 고수가 아닌 상황에서 이런 거창한 목표를 잡은 건, 많은 프로그래머들을 중수로만 끌어올릴 수 있어도 한국의 전반적인 소프트웨어 개발 역량이 높아지지 않을까라는 막연한 기대감을 갖고 있기 때문이다. 내 주제에 이런 걸 할 수나 있을까 하는 의구심이 아주 강하게 든다. 하지만, 학원/학교/회사들은 프로그래머를 성장시키기 위한 노력을 하기 보단 당장 써 먹어야 하는 기술을 가르치는데 급급하고, 프로그래머 스스로 자신을 끌어올리기에는 많은 한계가 있다고 생각한다.


주변을 보면 10년 가까이 지나도록 그 수준에 머물러 있는 프로그래머들이 가득하고, 이 바닥을 발전시켜줄 수 있는 고급 인력은 항상 모자라다. 프로그래머가 만드는 최종 결과물인 코드의 품질은 높아질 줄 모르고 이로 인해 소프트웨어를 만들고 개선하는 비용은 점점 증가하기만 한다. 프로그래머라는 직업이 고난이도의 지식과 사고력을 요구하는 그런 것이 아닌 몸으로 떼우고 시간으로 떼우는 노동 집약적인 것으로 인식되고 있기도 하다. 지식 집약이 아닌 노동 집약이라니... 이러다 보니 미국에서는 선망의 직업인 프로그래머가 한국에서는 기피 대상이 되어가고 있다.


프로그래머를 고용하는 사람들의 인식 구조가 조금씩 바뀌고는 있지만 (예를 들면, SKP나 쿠팡 같은 곳에서 프로그래머를 높은 연봉으로 빨아가는 것) 여전히 많은 고용주는 프로그래머를 벽돌 쌓는데 필요한 일용직 잡부 정도로 생각하는 곳이 많다고 느껴진다. 이런 인식 하에서 일을 빨리 끝낼 수 있는 방법이라곤 시간 투입을 늘려 노동 강도를 높이는 것 뿐이다. 이러다보니 피고용인인 프로그래머들도 더 적은 시간으로 더 나은 결과물을 만드는 방법을 찾기 보다는 (즉, 본인을 성장시키기 보다는), 벽돌 쌓는 기술을 연마하고 시간을 늘려서 일하거나(즉, 잡소리 듣기 싫어서 적당히 눈치봐가며 일하거나) 피똥싸가며 일을 하기에 바쁘다. 이런 상황은 고용인도 피고용인도 서로를 망치는 결과(프로젝트의 오픈 일정이 끝도 없이 뒤로 밀리고, 소프트웨어의 품질은 엉망이고, 오픈 후에도 유지보수에 높은 비용이 발생하는)만 초래할 뿐 윈-윈의 결과를 만들어내지 못한다.


이런 현실을 바꾸려면 회사-프로그래머-사회에 걸쳐 여러 가지 변화가 필요하겠지만, 한 가지 반드시 필요한 변화는 프로그래머들 스스로가 노동 집약이 아닌 지식 집약적인 전문가로 거듭나는 것이라고 생각한다. 프로그래머 스스로가 전문가로서 성장하지 않고서는 프로그래머를 일용직 잡부 정도로 생각하는 인식은 앞으로도 크게 바뀌지 않을 거고, 프로그래머를 이곳 저곳에 팔아먹는 인력 사무소만 활개칠 것이다. 지금도 내 폰엔 개발자 필요 없냐는 인력 사무소의 문자가 왔다.


변화를 만들어보고 싶다. 그래서 거창한 목표를 세우게 되었다. "그래, 프로그래머들의 역량을 한 단계 올려 보자!" 이 목표를 이룰 수 있는 지 여부는 생각하지 않는다. 무엇이 되었든 간에 프로그래머들의 역량을 올려줄 수 있는 것이라면 일단 시작해보자. 하다보면 결론이 나겠지.




  1. 김과객 2013.06.11 17:24

    내 실력도 아니고 내 팀 실력도 아니고 내 회사 실력도 아닌 대한민국 전체 개발자의 실력을 번쩍 들어 올리겠다는 야심에 박수 짝짝짝... 모름지기 목표는 그정도 거대해야 맛이죠.

    대한민국 전체의 개발자 실력 향상의 첫 단추로 제 생각은 개발자들 스스로의 자성을 하고실력연마를 해야겠다는 의식을 일깨워야한다고 생각합니다.

    그냥 단순한 당위가 아니라 진짜로 뼛속까지 느끼는 그런 게 필요합니다.

    • 최범균 madvirus 2013.06.12 15:13 신고

      정말 꿈 같은 목표죠. 작은 것 부터 하나 하나 하다보면 뭔가 눈에 보이지 않을까 하고 생각해봅니다.

  2. 남학생 2013.09.30 18:09

    화학공학의 전공을 바꾸고 개발자로 전향하는 26살의 학생입니다.
    이렇게 좋은 목표를 가지고 노력하시는분이 있다는 것에 참 감사합니다 ㅎ
    많이 배우고 좋은 프로그래머가 되도록 노력하겠습니다 ^^

  3. Reality 2013.11.29 22:02

    안타까운 현실은,

    구인구직 사이트에 대기업을 제외하고 어떤 기업도 프로그래머를 직원으로 고용치 않고 온통 인력사무소 구직정보만 널려 있다는게 안타깝네요..

    프로그래머 접은 1人

  4. 오치문 2014.02.26 09:46

    목표가 훌륭하시군요.
    경험을 공유해주시는 것만으로도 큰 영향을 미치고 있다고 생각합니다. :)

요즘 책을 쓰고 있다. 그 동안 써 오던 책들이 사용법 위주 책이었다면 이번 책은 이론에 가까운 책이다. 


책에 대한 반응이 싸늘하면 어쩌지? 너무 안 팔려서 출판사가 손해가 난다면?


오늘도 이런 걱정이 날 사로잡고 있다. 여러 종류의 책을 썼고, 운 좋게 팔린 책도 있지만, 그렇지 않은 책이 더 많다. 2년 전에 출판된 자바 기초 책은 출판사에 민망할 정도로 속된 말로 망했다.


그래도 시도는 해 봐야 한다. 10년 전에 MVC 프레임워크를 주제로 책을 썼던 때처럼, 6년 전에 한글로 된 레퍼런스가 필요할지 모른다고 생각하며 썼던 스프링 책처럼, 시장에 압도적 1위가 있지만 그래도 나만의 방식으로 자바 안내서를 만들고 싶었던 2년 전처럼, 시장에서 ORM을 의심하던 시절(지금도 그런 듯 하지만)에 썼던 하이버네이트 책 처럼.


시장에서의 반응은 알 수 없지만, 걱정을 뒤로 하고 담고 싶은 내용을 잘 담아내는데 집중하자.

  1. 나그네 2014.03.10 09:39

    개발자가 정복해야 할 객체 지향과 디자인패턴 정말 잘보고 있습니다.
    그러고 보니 책장에 범균님 책이 4개나 있네요 ㅋㅋ
    잘보구 있으니 힘내세요!!!

    범균님 책으로 누군가는 지식과 행복을 느끼고 있는 구독자가 있다는걸 명심하세요
    앞으로도 좋은책 많이 써주세요!! 화이팅

"올 겨울 아우터 스타일링은 블랙컬러로 시크하게 연출하거나 크레이지한 컬러패딩으로 유니크하거나 펑키하게 연출하는 ... " 


이 문장을 보면 무슨 생각이 드는가? 전문가임을 티내려는 걸까? 아니면, 영어를 안다고 잘난 척 하려는 걸까? 그런데, 이런 문장은 의상 디자인에서만 사용되는 게 아니다. 몇 년전 국내 개발 관련 컨퍼런스에서 이런 저런 발표를 듣고 있는데, 함께 듣던 후배가 이런 말을 했다.


"무슨 발표 자료를 다 영어로 만들었어요. 영어 잘 한다고 잘난체하려는 건지.... 말 중간 중간에도 어찌나 영어 단어를 많이 쓰는지 짜증나더라구요."


정말이지 발표자의 자료는 온통 영어였고 (영어 단어, 영어 문장, 영어 이미지), 한글로 된 건 발표자의 이름 뿐이었다. 물론, 발표하는 내내 영어 단어를 많이 섞었음은 두말할 필요도 없다. 그런데, 얼마전에 다른 컨퍼런스에 사용된 발표자료를 봤는데, 뜨아... 이것도 역시나 온통 영어였다. 물론, 영어를 사용하는 사람들을 위한 컨퍼런스는 아니었고 국내에서 한국 개발자들을 위해 개최된 그런 컨퍼런스였다.


청자는 어디로?


후배는 다음과 같이 심정이었을 것이다.

발표자가 발표를 시작했는데 영어가 펼쳐진다. 발표자는 그 화면과 관련된 내용을 한글과 영어를 섞어가며 설명을 한다. 젠장, 난 집중해서 재빠르게 영어 문장을 읽어서 그 내용을 이해한 다음에 발표자가 하는 말과 내 눈에 비치는 문장을 함께 이해해야 한다. 영어를 재빠르게 읽는 능력이 없을 뿐더러 영어 자료와 한국어(물론, 영어 단어가 많이 섞인) 발표가 잘 섞이지도 않는다. 안 그래도 이해 안 되는 내용이 더 이해가 안 되기 시작한다. 이번 시간은 포기다.

그래, 결국은 내용을 제대로 이해하지 못하는 상황이 발생한다. 발표자는 단지 자신의 지식을 자랑하러 나온 건 아닐 것이다. 그 지식을 함께 나누기 위해 나왔을 것이다. 그런데, 영어로 범벅이 된 자료라니, 거기에 영어로 된 단어 남발이라니.. 


물론, 소프트웨어 개발의 특성상 영어 단어를 많이 사용할 수 밖에 없다는 점을 이해한다. 게다가, 특정 단어는  영어 단어를 사용할 때 그 의미가 명확하게 와 닿는 경우도 많다. 하지만, 그렇다고 하더라도 온통 영어 문장에 영어 단어인 발표자료를 모든 청자들이 이해할 수 있는 것은 아니다.


그렇다고 하더라도 99% 영어로 된 자료는 문제가 있는 것 아닌가? 이건 한국어를 사용하는 사람들을 위해 한국에서 개최되는 컨퍼런스에서 발표자가 취할 자세는 아닌 것 같다. 차라리 깨알같은 글씨로 만든 한글 발표 자료는 읽을수라도 있다. 그런데, 영어로 된 자료는 지식을 얻어갈 가능성을 박탈해버린다. 이럴거면 시간 내서 컨퍼런스에 참여한 이유가 없어진다.


발표자가 참석한 모든 사람들에게 지식을 공유하는 것은 불가능하겠지만, 적어도 그 가능성은 높여야 한다고 생각한다. 앞으로 있을 컨퍼런스들은 영어 자랑보다는 지식 공유에 좀 더 초점을 맞춘 그런 발표자분들이 많았으면 좋겠다.

흔히들 실무와 관련된 학습을 한다는 분들의 말을 듣다보면 그 실무라는 것이 사용 기술에 특화된 경우를 많이 본다. 스프링 프레임워크의 사용법이라든지, jQuery 사용법, 하둡 설치, Redis 연동, Node.js 이용한 메시지 처리 등 뭔가 기술 사용에 대한 것들이 많다. 그런데, 실무라는 게 진짜 이것 뿐인가? 그래서, 개발자에게 있어 실무가 뭔지 고민을 좀 해 보려고 한다. 


실무의 사전적 정의는 '실제적이고 구체적인 업무'이다. daum 사전을 검색해 보면 '실제'란 '있는 사실이나 현실 그대로의 상태나 형편'이고 '구체'란 '사물이나 현상이 일정한 모습을 갖추고 있는 것'이다. 이런 의미를 종합해보면 개발에 있어 실무란 '소프트웨어를 만들기 위해 수행하는 모든 업무'라고 볼 수 있을 것 같다.


소프트웨어를 만들기 위해 수행하는 모든 업무를 이곳에 다 나열할 수 없지만 (나 스스로 이걸 다 알지 못한다), 잠깐만 생각해봐도 다음과 같은 것들이 떠오른다.

  • 코딩
  • 요구사항 분석(요구사항 이해)
  • 설계 / 모델링
  • 테스트/QA (기능, 성능)
  • 소스 관리 / 버전 관리
  • 배포 / 인프라 관리
  • 운영
  • 일정 관리 / 비용 관리 (최소한 일정과 비용에 대한 개념)

하나의 소프트웨어가 만들어지려면, 위의 모든 작업들이 유기적으로 연결되어 실행되어야 한다. 요구사항이 제대로 분석되지 않은 상황에서 코드를 작성하면 의미없는 소프트웨어가 만들어질 것이다. 설계가 유연하지 않으면 요구사항의 변화를 제대로 수용할 수 없을 것이다. 소스 관리와 배포 관리가 되지 않으면, 이전 버전이 배포될 지도 모른다. 일정 관리가 되지 않으면 제때에 소프트웨어를 내놓지 못할 수도 있다.


이 모든 것들이 실무다. 단지, 스프링을 익히고, jQuery를 익히는 것만이 실무는 아닌 것이다. 스프링이나 jquery를 익히는 건 코드를 만드는 역할로서의 실무를 하기 위한 활동일 뿐이다. 개발자는 코더일 뿐만 아니라 코드를 만들기 위한 설계자로서 역할도 수행하며, 이를 잘 수행하기 위해서 요구사항을 분석하는 역할도 수행해야 한다. 또한, 본인이 만든 코드에 결함이 없도록 하기 위해 테스트도 어느 정도 수행해야 한다. 게다가 작은 조직이라면 직접 배포도 해야 하고, 일정도 어느 정도는 스스로 관리해야 한다. 소프트웨어에서 실무란 이런 작업들을 모두 포함하고 있는데, 단지 실무의 범위를 코드를 만드는데 사용되는 기술만으로 한정짓는 것은 건축 현장에서 벽돌을 쌓는 걸로 본인의 작업을 한정하는 것과 크게 다르지 않다.


개발자로서 실무를 잘 하려면 단지 특정 기술을 익혀 코딩하는 것만으로는 안 된다. 이건 소프트웨어를 만드는 데 있어서 가장 기본일 뿐이다. 코딩을 하지 않으면 소프트웨어는 만들어지지 않으므로 구현 기술을 익히는 것은 가장 기본이면서 가장 중요하지만, 이것만으로는 '좋은' 소프트웨어를 만들 수 없다.


사용자가 원하는 '좋은' 소프트웨어를 만들려면, 구현 기술뿐만 아니라 요구사항 분석 실무를 익혀야 한다. 또한, 요구사항의 변화를 적은 비용으로 대처할 수 있도록 유연한 설계를 만들 수 있는 방법을 익혀야 한다. 소프트웨어 결함을 낮추는 데 도움이 되는 테스트를 만드는 방법도 익혀야 한다. 이 뿐인가,, 서비스 중단을 최소화하면서 기존 소프트웨어를 업그레이드하는 방법도 익혀야 한다. 또한, 역할에 따라서 프로젝트 일정을 관리하고, 투입 예산을 관리하는 방법도 익혀야 한다.


이런게 다 실무다. 코딩만이 실무가 아닌 것이다. 이런 실무들을 잘 하려면 구현 기술을 익히기 위해 책/온라인자료/오프라인 강좌 등을 통해서 학습하는 것 처럼, 설계를 학습하고, 좋은 코드를 만드는 방법을 학습하고, 프로젝트 관리를 학습하고, 테스트를 학습해야 한다. 벽돌 쌓는 기술로 1층짜리 벽돌집은 간신히 만들 수 있을지는 모르겠으나, 고층빌딩은 고사하고 3-4층되는 집도 만들 수 없을 것이다. 비슷하게 소프트웨어 개발자도 간단한 코드는 만들 수 있을지 모르겠지만, 규모가 조금만 커져도 소프트웨어는 점점 엉망이 되서 더 이상 발전할 수 없는 그런 결과물이 만들어질 것이다.


이제 갓 이 바닥에 발을 들여 놓은 개발자들이 실무를 단지 벽돌쌓기 기술을 향상하는 것으로만 생각하지 않았으면 좋겠고, (나름 포함한) 많은 개발자들이 다양한 영역의 실무를 익혀서 좋은 소프트웨어를 만들 수 있는 개발자로 성장할 수 있기를 바란다.

  1. 이루리 2013.04.05 16:57

    좋은 글 감사합니다.
    비록 제 현실과는 맞지 않지만 저렇게 업무를 할 수 있는 회사로 이직하는 날을 꿈꾸며

  2. 큐라 2013.04.13 15:27

    좋은 글이군요..
    역시 실무에 핵심은 지루한 회의가 아닐까요?..

  3. bluepoet 2013.04.29 15:19

    좋은 포스팅 잘 읽었습니다.

    아래부분이 핵심 요지가 아닌가 싶네요^^

    ==============================================================================

    사용자가 원하는 '좋은' 소프트웨어를 만들려면, 구현 기술뿐만 아니라 요구사항 분석 실무를 익혀야 한다. 또한, 요구사항의 변화를 적은 비용으로 대처할 수 있도록 유연한 설계를 만들 수 있는 방법을 익혀야 한다. 소프트웨어 결함을 낮추는 데 도움이 되는 테스트를 만드는 방법도 익혀야 한다. 이 뿐인가,, 서비스 중단을 최소화하면서 기존 소프트웨어를 업그레이드하는 방법도 익혀야 한다. 또한, 역할에 따라서 프로젝트 일정을 관리하고, 투입 예산을 관리하는 방법도 익혀야 한다.

객체 지향 관련 서적을 읽다보면 원서의 'concrete class'를 '구상 클래스'로 번역한 것을 보게 된다. 구상? 뭔가  잘 와닿지 않는다. 왜 이 용어가 어색한걸까? 이 어색함을 풀어보려고 글을 써 본다.


먼저, 이 어색함을 풀어보려면 'concrete class'의 의미를 먼저 알아야 할 것 같다. 'concrete class'는 'abstract class'가 아닌 'class'이인데, 여기서 'abstract class'는 'abstract operation'을 포함하고 있는 클래스를 뜻한다. 'abstract operation'은 시그너쳐만 제공하고 실제 구현(implementation)은 제공하지 않는 'operation'이다. 즉, 'abstract class'는 구현은 제공하지 않는 'operation'을 정의하고 있는 'class'인 것이다. 'concrete class'는 'abstract class'가 아닌 'class'이므로, 'concrete class'란 모든 'operation'이 구현을 제공하는 'class'라고 정의할 수 있을 것 같다.


다시 '구상 클래스'로 돌아가자. '구상'이라는 단어는 실제적이고 구체적이라는 뜻을 같는다. 미술의 경우 '추상 미술'과 '구상 미술'이라는 단어로 초현실적인 것과 현실을 그대로 반영하는 표현기법을 구분해서 표현하기도 한다. 앗, '추상 미술(abstract art)'/'구상 미술(concrete art)', '추상 클래스(abstract class)'/'구상 클래스(concrete class)'? 그러고 보니 '추상'과 '구상'은 쌍을 이루는 단어이다. 영어의 abstract와 concrete가 '추상적인'과 '구체적인(비슷한 의미로는 구상적인)'으로 번역이 되기 때문에, 'abstract class'와 'concrete class'를 각각 '추상 클래스'와 '구상 클래스'로 번역하는 것은 무리가 없어 보인다.


우리가 흔히 사용하는 '추상'과 '구상'이란 단어와 실제 'abstract class'와 'concrete class'의 의미를 함께 생각해보자.

  • 구현을 제공하지 않는 오퍼레이션(메서드)를 갖는 클래스 <--> 추상? 클래스
  • 모든 오퍼레이션이 구현을 제공하는 클래스 <--> 구상? 클래스

소프트웨어에서 '추상화'라는 것은 데이터나 프로세스 등을 의미가 비슷한 개념이나 표현으로 정의하는 것이므로, 추상화를 하면 실제 상세한 구현을 감추고 (더 상위 수준에서 개념적으로) 사고할 수 있는 결과를 얻게 된다. 이런 의미에서 오퍼레이션의 시그너쳐만 정의하고 실제 구현은 제공하지 않는 클래스는 결과적으로 인터페이스와 같은 역할을 하게 되므로 '추상 클래스'라고 표현해도 무난한 듯 하다.


그런데, 'concrete class'는 모든 오퍼레이션이 구현을 제공하는 클래스이다. 즉, 이는 각 오퍼레이션의 실체가 존재한다는 것을 뜻하는 것이다. 구상이라는 것은 추상과 대비되는 말이기 때문에, 뭔가 추상 클래스를 상속한 클래스를 지칭하는 용도로 '구상 클래스'라는 단어를 사용하는 것이 나쁜 선택은 아닌 것 같긴 하지만, 특별히 어떤 추상 타입을 상속받지 않은 클래스를 '구상 클래스'라고 부르기엔 다소 어색함이 있다. 필자의 경우 'concrete class'를 표현할 때 '구현 클래스'라는 단어를 주로 사용해 왔는데, 이 단어 역시 주로 인터페이스를 구현한다는 의미에서 '구현'이라는 단어를 선택한 것이기에 어떤 인터페이스도 상속받지 않은 클래스를 표현하기에는 다소 무리가 있다.


'concrete class'는 실제로 메모리 상에 인스턴스 생성이 가능한 클래스이기 때문에 '실체화 가능 클래스'라고 길게 표현할 수도 있을 것 같긴 한데, 너무 길다. '실체 클래스'는 어떨까? (숨어 있는 범죄 집단 느낌이 나네....) 딱히 뭐라고 표현해야 할지 떠오르지 않는다. 누군가가 언어 감각이 뛰어난 고수분이 'concrete class'를 좀 더 와닿는 용어로 번역해주었으면 하고 바래보면서 글을 마친다.

  1. 이대영 2013.04.09 14:09

    저는 코드리뷰나 뭐 대화할대 구현클래스라고 했었던것 같은데.. 또 생각하려니 가물가물 하네용..^^;

    • 최범균 madvirus 2013.04.09 14:39 신고

      저도 구현 클래스란 단어를 많이 써요. 콘크리트 클래스/구현 클래스를 혼용해서 사용하지 않을까 싶습니다.

  2. 야식 2014.02.26 14:28

    안녕하세요.
    저도 구상클래스라는 말을 보고 검색하다가 따라 들어왔습니다.

    어느 글에서는 '구체' 클래스 라는 용어를 쓰던데요.
    너무 직역한 느낌이 드나요?
    그래도 구체 라는 인스턴스화가 되었다는 뜻도 포함하긴 하는데, 포스팅에서 지적했던 추상을 구현해 내는 느낌은 살짝 부족해 보이긴 합니다.

    아무튼 좋은 생각거리를 해볼 수 있는 기회 주셔서 감사합니다.

  3. 마크 2015.05.02 22:09

    구글에서 구상클래스를 검색해서 들어왔습니다.
    덕분에 개념 이해하고 감니다.
    감사합니다 ^^

  4. 도움받은자 2017.01.15 15:07

    구상 클래스 개념에 대해서 혼동이 있어서 이렇게 찾아와 글을 읽어보니 도움이 되었습니다. 감사합니다.

  5. 구성클래스 구글링해서 들어옴 2020.07.18 23:39

    전 구체클래스거 제일 나은것같습니다

    구현이라는 단어는 implemetation 의 번역으로 많이 쓰이고, 구상이라는 단어는 일상 생활에서 '구상하다' 의 의미 외에는 들어본 적이 없는듯 하네요

  6. 껍데기 클래스와 알찬 클래쓰????

모든 사장은 열정이 넘치는 직원을 좋아한다. 꼭 사장이 아니어도 팀장들 역시 열정이 넘치는 직원을 좋아하기 마련이다. 그렇다면 누군가가 열정이 넘친다는 건 무엇으로 알 수 있나?


열정이 넘치는 사람의 특징을 내가 알면 얼마냐 알겠냐마는, 그래도 뭔가를 막 하고 싶어한다는 특징이 있다는 건 알고 있다. 뭔가를 정말 하고 싶고, 시도 때도 없이 그 뭔가만 생각나고, 그걸 너무 하고 싶어서 밤도 새고, 새벽같이 일어나서도 하고..... 이런게 열정이 넘치는 사람들의 특징 중 하나가 아닐까라는 생각이든다.


그런데, 이런 특징만으로는 열정을 정의하기에는 부족함이 느껴진다. 많은 사람들이 처음에는 흥미를 느껴서 빠져들더라도 조금만 시간이 지나면 금세 시들해지는 경우를 많이 봤기 때문이다. 나도 금세 시들해지는 경우가 많았다. 어렸을 때 만화가가 되보겠다고 만화를 열심히 따라 그렸을 때 그랬고, 기타를 쳐보겠다며 낙원상가에 가서 기타를 샀을 때가 그랬다.(대학생 시절에 샀던 이 기타는 지금도 집에 있다.)


열정이란 단순히 좋아하는 것 이상을 요구하는 것 같다. 뭘까 곰곰히 생각해봤는데, 열정의 또 다른 특징은 '인내'와 '꾸준함'이 아닐까? 무언가를 해 낼때까지 계속해서 시도하는 것. 이게 열정의 또 다른 면이 아닐까? 사실 무언가를 해 낸다는 것은 매우 힘겨운 과정인데, 그 힘겨운 과정을 이겨내면서 해 냈을 때 성취감을 느끼는 것~. 이건 오디션 프로를 봐도 알 수 있다. 노래 부르는 게 너무 좋고, 노래를 더 잘 부르고 싶어서, 그 힘든 과정을 참고 참아내는 모습은 오디션 프로에서 흔히 볼 수 있는 내용이다.


다시 처음 얘기로 돌아가서 직장에서 모든 상급자는 열정이 넘치는 사람을 좋아하다. 왜냐면 정말 뛰어난 천재를 제외하면 많은 경우 열정이 넘치는 사람이 좋은 결과물을 더 빠르게 만들어낼 가능성이 높기 때문이다. 나 역시 똑똑한 사람과 같이 일하고 싶고, 그 다음으로 같이 일하고 싶은 사람이 결과물을 남들보다 빠르게 만들어내는 사람이다. 그렇다면, 상급자는 열정이 넘치는 사람을 어떻게 알 수 있을까?


연차에 많고 적음에 상관없이 얼마나 일을 잘하기 위해 노력했느냐로 판단할 수 있을 것 같은데, 이것은 다음의 두 가지를 꾸준히 한 사람인 경우가 많은 듯 하다.

  • 끊임없는 배움 (이게 참 힘든 일이다!)
  • 끊임없는 개선 (앞의 배움이 없으면 이건 전혀 안 된다!)

열정적인 사람은 일을 통해서 배우든, 개인적인 공부를 통해 배우든, 배움을 얻기 위해 부던히 노력하고, 그 배움의 결과를 다시 일에 반영하는 선순환을 끊임없이 만들어낸다.


그런데, 직장인에게 '힘들어도 좋아하는 걸 하는 즐거움'이라는 열정의 특징이란게 보통은 초과근무와 비슷하게 표현된다. 몇 가지 예는 다음과 같은 것들이 있다.

  • 저녁에 남아 일을 함 (코드 작성을 멈출 수 없음, 책을 읽지 않을 수 없음)
  • 가족들을 재우고 새벽까지 함 또는 새벽에 일어나서 함 (코드 작성을 멈출 수 없음, 책을 읽지 않을 수 없음)
  • 금요일에 하던 걸 주말에도 계속 함 (코드 작성을 멈출 수 없음, 책을 읽지 않을 수 없음)

그냥 코드를 계속 작성하고 싶은 것일 뿐인데, 읽던 책을 마저 읽고 싶은 것 뿐인데, 잘 안 되는 게 있어서 그걸 해결하고 싶은 것일 뿐인데, 겉으로 보여지는 건 초과 작업이다.


그렇다면 상급자에게 어떤 사람이 열정이 넘쳐 보일까? 그래, 바로 '초과 근무'이다. '초과 근무'를 한다고 해서 그 사람이 열정적인 건 절대 아니지만, 적어도 '열정'이 넘치는 사람은 남들보다 더 많이 일한다. (일한다는 표현보다는 노력한다가 더 맞을 것 같긴 하다.) 스포츠 스타를 생각해보라~ 정말 천재처럼 보이는 인재들도 남들보다 훨씬 강도높은 훈련을 하는 경우가 많다. 하물며 천재가 아닌 사람들이 열정이 넘칠 때에는 회사에서든 집에서든 아님 다른 곳에서든 '초과 근무'를 하기 마련이다.


즉, 누구나가 인정하는 천부적 능력이 없는 이상, 상급자들은 '초과 근무'를 하는 사람이 열정적으로 보일 가능성이 높아 보이기 마련이다. 그런데 문제는 여기서부터 발생한다. 다음은 전형적으로 발생할 수 있는 문제들이다.

  • 성과나 실력이 별로 늘지 않았는데, 야근을 해서 열정적인 것 처럼 보인다.
  • 심한 경우 야근하지 않는 동료보다 성과가 안 좋음에도 불구하고 상급자가 좋아한다.

게다가 평가에는 보상 심리가 따르기 때문에 같은 평범한 성과라면 고생한 사람을 더 쳐주기 마련이다. (어디까지나 평범한 성과에 한해서다. 뛰어난 성과는 근무 시간을 떠나서 누구나가 인정한다.) 하지만, 같은 평범한(!) 성과라면 야근한 사람을 평가를 잘 줘서는 안 됨을 알고 있다. 왜냐면, 결과가 더 늦게 나오면서 비용은 더 많이 썼기 때문이다. (다시 강조하지만, 어디까지나 평범한 성과인 경우를 말하는 것이다. 뛰어난 성과는 예외다.)


상급자로서 열정적인 사람을 만나면 정말 기분이 좋다. 내가 사장이 되었을 때 열정적으로 일하는 사람을 만나면 아마 더 기분이 좋을 것이다. 그렇다고, 열정을 강요하고 싶진 않다. 열정을 강요하면 자칫 거짓 열정으로 저녁에 시계나 보면서 자리를 지키는 경우가 발생할 것 같아서이다.


쓰다보니 글이 길어졌다. 하튼, 열정이 뭔지는 잘 모르지만, 열정이 넘치는 사람은 숨길 수 없고, 강요한다고 해서 절로 생기지는 않으며, 힘든 걸 이겨내는 '인내'와 '꾸준함'이 없이는 열정적일 수 없다는 글을 적고 싶었다.


  1. 백명석 2013.01.08 09:41

    http://t.co/ZJflJFD3 에 의견 달았습니다.

    • 최범균 madvirus 2013.01.08 10:08 신고

      넵, 명석님. '힘든 줄도 모르고 했다'라는 말이 바로 말씀하신 그거죠. 리더로부터 자극을 받아 찾을 수도 있겠지만, 열정은 본인이 찾는 게 우선일 것 같아요. 리더는 단지 찾아 나서는 사람에게 도움을 주는 사람 정도가 아닐까하합니다.

  2. 김광수 2013.01.09 09:34

    열정을 유지하기 위해 끊임없는 배움과 개선이 필요하단말씀, 100% 공감합니다. 자기반성이 없다면 열정을 유지할 수 없을것 같아요.
    더불어 자기가 무엇에 열정을 가져야할지 명확하게 인식하는것과, 열정이 느껴지는 순간이 올때 무아에 빠지는 방법을 터득하는것도 중요할것 같아요.
    리더는 최대한 그 열정에 손상이 가지않는선에서 올바른 방향을 보도록 조향해주는게 좋을것 같습니다.
    적절한 피드백또한 그 열정의 관성을 유지하는데 도움이 될 것 같아요.

  3. 이호영 2013.01.21 11:15

    제가 이해력이 않좋은 지
    위에 글을 읽어보면 열정이 결국 야근으로 표현된다고 이해가 됩니다.
    결론적으로 야근으로 한 사람을 평가하고 보상하는건 합리적이지 않다고 봅니다.
    저는 열정이 있지만 야근으로는 표현 하지 않습니다. 저 또한 야근을
    엄청 싫어합니다.
    제 열정은 집에서 마음과 편한 옷차림, 편한 자세에서 책을 읽거나
    코딩하거나 주말에 세미나 참석하는 것으로 표현 되는것 같습니다.

    야근을 많이 한다고 해서 프로젝트 개발일정에 절대 도움되는것이 아닙니다.
    2,3시간 고민하고 열심히 만들어도 아침에 맑은 정신에서 그 소스를 다시 보면
    버그 일 경우가 많습니다.
    밤늦게 고민해서 해결 못본 문제를 아침에 15분도 안되어서 쉽게 해결 됩니다.
    만성피로 상태에서 소스의 품질이 좋을 수 없습니다.

  4. Kunny 2013.02.15 15:36 신고

    평소 항상 책을 보고 공부하며 나는 개발자로써 열정을 가지고 배우고 있다고 생각했었는데, 이 글을 읽으니 그렇지 않은 것 같다는 생각이 먼저 드네요.
    그냥 저는 개인의 만족감을 위해서 책을 읽었지 개발의 열정을 가지고 읽진 않았거든요.
    초과근무를 하는 경우에도 열정보다는 어쩔 수 없이 했었더랬죠...
    한번에 바뀌진 않겠지만 인내, 꾸준함 저한테 절실하네요.
    감사합니다.

  5. 김용훈 2014.12.08 13:44

    어차피 혼자가는 길이지만, 열정이 없는 사람과 함께 일하는 건 즐겁지가 않네요.

    이왕이면 본인이 하고 싶은 일이 명확하고 그것을 이루기위해 적극적으로 행동하는

    사람들과 함께 걷고싶은 마음입니다.

  6. msk 2015.11.13 02:55

    열정 보다는 관심이라는 표현을 쓰고 싶네요. 요즘 열정이라는 단어가 매우 부정적인 색채가 강해서.. 그리고 열정이란 무엇이라고 생각 하는지에 대해서는 모든사람들이 저마다의 의미가 다 다를 것 같아요. 타인으로 부터 열정이 있다 없다라는 평가는 정말 거부하고 싶네요. 자신이 정의내리는 열정을 불태우는 것은 좋은 일이지만 같은 방식의 열정을 타인에게 기대 하거나 요구한다면 누군가에게는 소모적인 일이 될 수도..

  7. 나영주 2017.05.22 11:32

    요즘에 열정이란 관리자가 하급자를 착취하기 위한 수단이라고 생각합니다.
    열정이 있으면 좋기는 하겠지만 범균님 말씀처럼 야근으로 열정을 판단하는 것은 지양해야 하는 일입니다. 열정이란 자발적으로 뭔가를 해보고 싶어서 하는 것이지 관리자가 열정을 강조하면서 착취하는 수단으로 쓰여서는 안됩니다. 그러나 우리나라는 열정이란 말을 그런 착취의 수단으로 사용하고 있습니다. 업무에 관련된 일로 열정을 불태운다면 리더는 당연히 그에 대한 방침을 정하고(교육이나 컨퍼런스 참여/사내 교육) 이것이 업무외시간으로 투자되는 것은 지양해야 하는 일일것 같습니다.

얼마전에 트윗에 올라온 '개발자라고 착각하는 무늬만 개발자?'http://techit.co.kr/6551 글을 읽었다. 이 글이 한국의 많은 개발자들에게 생각할 거리를 던져주었다고 생각한다. 이 글에 대한 답글은 아니지만 필자가 개발자인가라는 질문을 하고 싶어져서 썰을 좀 풀어보조자 한다. 참고로 필자는 월급을 받고서 일하기 시작한지는 12년째로 접어들고 있다.


현재 내가 하는 역할


필자는 현재 개발 팀장을 하고 있다. 3년전부터 개발 팀장이라는 직책을 맡고 있고, 지금 하고 있는 일은 다음과 같다.

  • 아키텍처 설계하기, 기술 선택하기
  • 프로젝트 초반에 개발환경 구축하기
  • 주요 도메인 모델 설계 또는 팀원이 설계한 것 리뷰하기
  • 프로젝트 일정 계획 세우기/체크하기
  • 외부 인력 수급 관리하기
  • 난이도 높은 모듈/기능에 대한 구현하기
  • 여러 프로젝트에 동시에 참여하기
  • 회사 외적으로는 기술 관련 글 쓰는 사람

하고 있는 일을 주요 역할로 나눠보면 다음과 같다.

  • 아키텍트
  • 선임 개발자
  • 구현자
  • 프로젝트 관리자
  • 작가

필자는 (초보이긴 하지만) 아키텍트의 역할을 하고 있다. 만들어야 할 소프트웨어의 전체 구조를 설계하고 구현 기술을 선택하고 밀고 나간다. 이 외에 성능, 보안, 확장성 등 여러 가지 구현과 직결되는 내용을 챙긴다.


주요 도메인에 대한 모델을 설계하거나 팀원이 설계한 모델을 리뷰하는 선임 개발자의 역할도 수행한다. 경우에 따라 코드 중에 마음에 안 드는 부분을 변경하도록 지시도 한다. 팀이 규모가 크다면 이 역할을 다른 사람에게 주겠지만 아직 규모가 작기 때문에 필자가 하고 있다. 물론, 필자가 다 하는 것은 아니며 일부는 중간에 위치한 팀원이 초급 팀원을 가이드하고 있다.


때로는 직접 구현에 참여하기도 한다. 난이도가 다소 높거나 일정을 단축시켜야 할 때가 그런 경우다. 물론, 아직까지 제일 잘 하는 것 중의 하나가 코딩이기도 하다. 하지만, 코딩하는 비중은 높지 않다. 1주일에 2일 이상을 코딩에 투자하지는 않는다. 코딩에 많은 시간을 투자했다간 다음에 언급할 프로젝트 관리자로서의 역할을 제대로 수행할 수 없게 된다.


필자는 근무시간의 40~60% 정도를 프로젝트 관리에 사용한다. 큰 수준에서의 일정 계획을 수립하고, 진행 상황을 확인하고, 위험 요소를 해소하는 데 많은 시간을 소요한다. 예를 들어, 필요한 인력을 수급하기 위해 외부 업체와 미팅을 하며, 매일 오전마다 미팅을 통해 진척상황을 관리한다. 아직까지 프로젝트 관리는 잘 하는 분야가 아니기에 위기의 순간에는 윗사람의 힘을 많이 빌리곤 한다.


이 외에 회사의 소프트웨어 분야의 기술쪽 팀장으로서 몇 가지 업무에 프로젝트 코디네이터나 실행자로 참여하고 있다.


그리고, 남은 한 가지 역할은 기술 관련 글을 쓰는 작가이다. 작가는 필자가 오래도록 갖고 싶은 역할로서 블로그나 책을 통해서 기술 관련 내용을 글로 남기고 있다.


포기 또는 일부러 하지 않는 것


현재의 역할을 '잘' 해야 하기 때문에, 아래의 것들은 일부 포기하고 있다.

  • 모든 신기술들을 공부하기
  • 하루 종일 코딩하기
이제 모든 신기술을 익힐 수는 없다. 요점 정도만 알고 넘어가거나 호기심에 책을 읽어보는 정도이다. 예를 들어,  최근에 읽은 책 중의 하나는 node.js와 하둡에 대한 책이었는데, 이 책들을 읽은 이유는 node.js나 하둡 자체를 익히기 위해서가 아니라 node.js나 하둡이 무엇인지 알기 위함이었다.

하루 종일 코딩을 하는 것도 하지 않는다. 그랬다간 다른 역할에 구멍이 난다. 순간적으로 프로젝트의 진척도는 올라갈 지 몰라도 여러 곳에서 구멍이 나면서 프로젝트 들이 엉망이 될 수 있다.


역할을 잘 수행하기 위해 하는 것들


아키텍트나 구현자로서의 역할을 잘 수행해내기 위해 하는 일은 지속적으로 기술 흐름을 파악하는 것이다. 최근의 빅 데이터, node.js, HTML 5 등이 각광받는 이유 등에 대해 공부한다. 일단, 큰 그림 수준에서 이해하고 필요하면 한 놈씩 골라서 본격적으로 판다.


프로젝트 관리자는 필자가 잘 하고 싶은 분야는 아니다. 프로젝트 관리 자체가 아주 재미없는 건 아니지만 필자는 구현에 참여할 때가 더 즐겁다. 하지만, 구현이 재미있다고 구현만 하면 큰 그림을 볼 수 없고, 프로젝트 관리 능력이 없다면 사실상 괜찮은 아키텍트나 선임 개발자가 될 수 없음을 알고 있기에 어느 정도의 프로젝트 관리 능력을 보유하기 위해 노력하고 있다. 프로젝트 관리와 관련된 책이나 글을 읽고 따라해 보는 것이 주된 노력이다.


필자의 오랜 목표 중의 하나는 기본기와 관련된 책을 쓴 작가가 되는 것이다. 이를 위해 설계와 관련된 내용을 지속적으로 학습하고 있고, 틈틈히 글로 배운 지식을 정리해 보고 있고 언젠가 이를 바탕으로 좋은 책을 쓸 것이다. 더불어, 입문자를 위한 책을 쓰는 것도 중요하게 생각하고 있기 때문에 JSP나 Java 언어와 관련된 책도 꾸준히 개정해 나갈 것이다.

그래서 난 개발자인가? 앞으로도 개발자일 것인가?

그럼, 이제 본론으로 돌아가 '난 개발자인가?'라는 질문에 답을 해 보자. 프로젝트 관리도 넓은 의미에서 보면 개발의 범주에 속하지만, 아키텍트까지가 개발자가 아닌가 하는 생각이 든다. 그런 의미에서 필자는 현재 절반은 개발자로서 일을 하고 있고, 나머지 절반은 관리자로서 일을 하고 있다. 물론, 사생활에서는 작가로서 반, 개발자로서 반 정도의 시간을 보내고 있다. 이런 점에서 아직은 개발자라고 불려도 손색은 없을 것 같다.


요즘 내가 하는 고민은 이 비율을 앞으로 어떻게 조정할 것인가에 대한 것이다. 올해 이 고민을 시작했고, 올 해 안에 답을 내려고 한다. 참고로 필자는 올해 36세이며, 결정에 따라 앞으로 5년 동안 무슨 일을 할 지가 결정될 것이다. 이 결정에는 여러 가지 고려할 것들이 있는데, 이는 다음과 같다.

  • 아이의 나이
  • 또 다른 수입원
  • 즐거움

필자는 가장이고, 아이가 있기도 하다. 앞으로 가정에 돈이 많이 들어갈 예정이기에, 연봉은 중요한 고려 사항이다. 한국에서 평균적으로 팀원보다 프로젝트 관리자가 연봉이 높은 점을 감안하면 고민이 더 커진다. 프로젝트 관리자나 기술쪽의 더 높은 지위(본부장, CTO 등)로 경로를 잡아서 향후 5년간 연봉을 더 높여갈 것이냐 아니면 적당한 연봉에 만족하면서 구현자로서의 즐거움을 좀 더 만끽할 것이냐? 이것이 큰 고민거리다.


한국에서 구현자로서 15년 이상의 경력을 가진 고급 개발자는 (연봉으로서) 인정해주는 곳이 별로 없기에 구현자로서 즐거움을 계속해서 누리고 싶다면 프리랜서로 경력에 비해 더 낮은 돈을 받고 계속 일을 해야 할 지도 모른다. 아니면 단가를 그나마 잘 받기 위해 외주로 일을 받아 전문적으로 구현을 해 주는 업체를 차려야 할 지도 모른다. 하지만, 필자가 일을 계속 따 올 수 있는 영업력이 있는가에 대해서는 상당한 의구심이 든다. 


프로젝트 관리자 경로를 잡든 구현자의 기간을 연장하든 둘 다 국내에서는 쉽지 않아 보인다. 필자의 역량은 구현자로서 역할을 수행할 때 더 잘 발휘되지만 40살 넘은 구현자가 존재하는 경우가 흔치 않을 뿐더러, 개발 팀에서 40이 넘은 팀원을 구현자로 두고 있는 회사가 얼마나 있을까 하는 의구심도 든다. 물론, 관리자로서 본부장/CTO 등으로 승진하는 것은 더 어려운 일이다. 필자는 구현자로서의 역할을 잘 한다고 해서 관리자로서의 역할도 잘 할거라는 보장이 없음을 알고 있고, 그런 의미에서 피터의 법칙(승진할수록 일을 못 한다는)에 어느 정도 동의한다.


내 위에 직접적으로 연결된 40대 초/중반의 선배님들 중에 구현자로서 역할을 하는 분은 정말 소수에 불과하고 대부분은 관리자로서 일을 하고 계신다. 이런 모습을 보면 내가 앞으로 얼마나 구현자로서 한국에서 버틸 수 있을까 하는 고민에 빠져든다.


필자가 하고 싶은 것은 켄트 벡이나 밥 아저씨처럼 IT의 개발자로서 계속해서 일을 하면서 기본기를 닦아 줄 수 있는 지식을 전파하는 것이다. 언젠가 실력을 더 쌓아 객체 지향과 패턴에 대한 기초 서적을 쓰고 싶고, 그러면서 개발자로서 능력에 알맞은 대우를 받으면서 일을 하고 싶다. 이게 가능하지 않다면, 본업을 바꾸고 취미로 개발을 해야 할까?


한 동안은 하고 싶은 것과 먹고 살 거리를 함께 고민하는 시간이 될 것 같다. 고민해 보자.






  1. Konn 2012.07.09 23:05 신고

    잘 읽었습니다. 작년쯤에 이런쪽에도 알아두는게 좋을것같아서 자바 책을 사놓고있는데 아직도 절반도 못 읽고있네요. 너무 어렵기도 하고 제가 너무 게을러서도 이겠죠. 언제나 느끼는거지만 이런 능력자분들을 보면 정말 부럽습니다.

  2. ddalki 2012.07.09 23:21

    평생하게되는 고민같습니다.

  3. seungbeomi 2012.07.09 23:45

    개발자라는 좋은(?) 직업을 가지고서도 모두들 이와같이 진로에 대한 고민을하게 되는 현실이 참 안타깝습니다.

    • 최범균 madvirus 2012.07.10 11:41 신고

      옛날처럼 평생 직장 개념이 없고, 기술자를 부리는 사람 정도로 취급하는 사회이다 보니, 더 많은 고민을 하게 되는 것 같습니다. 앞으로 살아가기 위한 현실적인 방법을 찾아야겠지요.

  4. msbaek 2012.07.10 14:26

    고민된다. 근데 꿈이 나랑 같다. 켄트벡이나 엉클밥. 근데 나는 관리를 하고 있는 듯. 요즘은 관리도 조금이고 프리젠테이션이 더 많은 듯. 에구.

  5. 그누 2012.07.10 15:16

    개발자라면 누구나 가지고 있는 로망 아닌가요? 막상, 현실은 뒷받침이 안되어 주고요^

    이게 우리 스스로 변해야 합니다. 누군가 바꿔주길 기대하지 말고 ~ 작은것에서 부터 실천해가는 모습~

    님께서 작성해주신 역할 즉, 아키텍트, 선임 개발자, 구현자, 프로젝트 관리자, 작가
    등에 대한 정의 및 상세 액티비티 등을 정의해서~ 공유하는 계몽운동을 벌여야 합니다.

    널리 퍼뜨려야 하지요. 요샌 개발자가 스토리 보도까지 작성 책임을 돌리는 상황까지도 전개 되었다라는 애기가 나돌고 있지요 기획자는 단순히 그리러 왔을뿐이다 라고 고객님께서 편드는 세상이 왔으니 말이죠

  6. innerman 2012.07.20 23:22

    제가 조금 나이가 더 많은데요... 전 아직도 개발하고 있습니다. 또 운좋게 개발만 해도 되는 환경에서요...(회사 전사가 애자일팀으로 변경되어서...)
    저는 개발자가 관리자가 되는 것은 반대입니다. 물론 아키텍트도 개발의 범주로 보구요... 코딩과 구별을 특별히 두고 싶지는 않네요... ㅋㅋ

  7. 체리파플 2013.10.13 01:42

    고급개발자 분이 필요합니다.
    신입들은 누가 키웁니까..

최근 ActiveX 및 ActiveX와 연결된 클라이언트 프로그램을 업데이트를 수행하고 있는데, 이 과정에서 엄청난 뻘짓을 두 번 했다. 이 두 번 모두 고객 환경에 대한 이해가 부족한데서 발생한 것인데, 대단한 내용은 아니지만 나 스스로에게 고객 환경 이해의 중요함을 각인하기 위해 글을 정리하기로 했다.

첫 번째 뻘 짓 원인, 신뢰 사이트

작업중인 코드는 크게 두 종류의 사이트가 자바 스크립트를 이용해서 통신을 하도록 되어 있었다.
  • 개별 사이트: 공통 기능을 필요로 하는 개별 사이트로서, 공통 기능을 이용할 때 ifrmae을 사용한다.
  • 공통 기능 제공 사이트: ActiveX를 제공하며, 개별 사이트에 숨겨진 iframe으로 삽입된다.
개별 사이트와 공통 기능 제공 사이트가 자바 스크립트로 데이터를 주고 받기 위해 두 사이트 모두 document.domain을 설정하였다. 통신 과정에서 크게 문제가 발생하진 않았다.

그런데, 두 번째 개별 사이트에 기능을 추가할 때 공통 기능을 사용하려고 버튼을 클릭하면 자바 스크립트 오류가 발생한다는 고객의 신고가 들어오기 시작했다. 정말 많은 부분을 뒤졌고, 또 뒤졌지만 원인이 쉽게 찾아지지 않았다. 결국 일부 고객의 PC 환경을 보다 자세하게 분석을 했고 그 결과 스크립트 오류가 발생하는 고객이 '개별 사이트'를 신뢰 사이트에 등록한 것을 알게 되었다.

개별 사이트만 신뢰 사이트에 등록하고 공통 기능 사이트는 신뢰 사이트에 등록되어 있지 않아, 두 사이트가 자바 스크립트로 통신할 때 접근 권한과 관련된 문제가 발생한 것이다.

'신뢰 사이트'라니!!! 웹 개발을 오래 했지만 신뢰 사이트에 추가한 경우를 거의 경험하지 못 했었다. 게임 관련 일을 하는 주변 사람들에게 물어보니, 해당 사이트의 ActiveX가 설치되지 않거나 하면 신뢰 사이트에 등록해서 해결하는 경우가 종종 있기 때문에, 게임 유저 중에는 신뢰 사이트에 등록하는 경우가 드물지만 있다는 것을 알게 되었다.

이 문제를 해결하기 위해 여러 가지 안을 찾다가, 결국 개별 사이트와 공통 기능 사이트가 통신하는 부분을 모두 제거하였다. 공통 기능에서 담당해야 할 일 중 일부가 개별 사이트로 넘어가긴 했지만 기능을 정상적으로 제공하는 것이 더 중요하기에, 일부 공통 기능을 각 개별 사이트에 중복해서 구현하는 방법을 택하게 되었다.

두 번째 뻘 짓 원인, PC방 환경

첫 번째 문제도 잡았고 ActiveX도 상당 부분 안정화 되었다. 이제 거의 모든 게 잡히는 듯 했다. 그런데, 세 번째 개별 사이트에 공통 기능을 적용하는 과정에서 고객 민원이 들어오기 시작했다. 아 뭐지? 뭐지?

그 고객들의 공통된 특징을 찾다가 PC방에서 문제가 발생한다는 것을 알게 되었다. 담당자에게 주변 PC방에서 테스트해 보라고 했다. 결과는 정상 실행된다는 것이었다. 고객들이 문제가 났다는 PC방의 위치를 확인했다. 종로5가에 있는 PC방임을 확인하고, (미안하지만) 담당자를 종로5가 PC방에 급파했다.

PC방의 PC를 조사하던 중 PC 환경이 이상한 것을 알게 되었다. 프로그램 목록에는 존재하는데, 관련 파일은 찾을 수 없고, 레지스트리 정보 일부가 삭제되어 있는 것이었다. 이건 또 뭐야? 컴퓨터에 서툰 사용자가 프로그램을 삭제할 때 해당 폴더를 그대로 지우는 건 알고 있었지만, 레지스트리를 관련된 것 전부가 아니라 일부만 지운다고?

원인은 PC방에서 사용하는 '보안관'류의 프로그램이었다. '보안관'류 프로그램들은 일정 시점 이후 추가된 파일과 레지스트리를 삭제하는 기능을 제공하고 있다. 그런데, 이 프로그램이 파일은 잘 지워놓고 레지스트리는 일부만 삭제한 것이었다.

아쉽게도 일부 레지스트리 정보가 없는 경우에 대한 방어 코드가 없었고 (방어 코드를 넣긴 넣었으나 그 코드를 비켜가는 경우가 발생했다) 그 덕(?)에 실행 오류가 발생하고 말았다.

담당자들과 논의하여 긴급하게 레지스트리가 비정상적인 경우에 대한 방어코드를 추가해 패치를 진행을 했다.

뻘 짓을 왜?

앞의 두 가지 사건은 "고객의 실제 환경"에 대한 이해가 얼마나 중요한 지 알려주는 계기가 되었다. 책에서 고객을 이해하는 것이 중요하다는 문장을 많이 봐왔지만, 이렇게 피부로 느낄 수 있었던 경우는 거의 없었던 것 같다. 신뢰 사이트에 직접 서비스 사이트를 등록하는 사용자가 있음에 놀랐고, PC방에서 비정상적으로 데이터를 삭제하는 경우가 있다는 점에 한 번 더 놀랐다. 생각해보면 날 비롯한 담당자들은 정상적으로만 PC를 이용하는 유저여서 실제 고객들의 다양한 환경을 충분히 고려하지 못했던 것이었다.

지금의 경험은 나에겐 매우 중요한 경험으로 남을 것 같다. 앞으로 조금 더 고객 관점에서 생각해 볼 수 있는 계기가 되었고, 비정상적인 상황에 대한 고려가 중요함을 다시 한 번 느끼게 되었다.

앞으로 뻘 짓을 하는 회수가 줄어들기를 내 스스로에게 바라며....
  1. 달려라네오 2011.05.23 13:12 신고

    뻘짓?! 하지만 누군가의 불편을 해결해주고 감동을 주는 서비스..
    여전이 만들고 또 전파하고 계시는군요 ^^
    잔잔한 IT 감동을 배웁니다. (건강하시죠?!)

최근에 'Slack' 이라는 책을 읽고 있는데, 이 책을 읽다 보니 몇 달 전에 읽었던 '일본 전산 이야기'라는 책이 생각났다. '일본 전산 이야기'와 다른 듯 같은 느낌이 들어서, 다시 한번 훑어보았다. 개발자를 위한 내용은 아니지만, 많은 개발자들이 보면 발전하는 데 도움이 될 수 있을 것 같아, 정리를 해 보았다.

'일본 전산 이야기'의 전반적인 분위기는 다음과 같다.
  • 할 수 있다. 즉시 한다. 반드시 한다. 될 때까지 한다.
  • (실력이 없으면) 배로 일하고, 기간을 반으로 줄여라.
  • '안 되는' 이유를 쓰느라 시간을 허비하지 마라. '되는' 일에만 집중해도 시간이 모자라다.
  • 꾸중을 듣고 잔뜩 삐쳐 있다가 감정으로 받아치려는 사람은 결국 큰일을 스스로 처리할 수 없는 사람이다. 반대로 꾸중을 듣게 되면 자신을 질책하면서 '발전적 반발심'을 가지고 일에 더 덤벼드는 사람이 진짜 클 수 있는 사람이다.
  • 감점주의가 아닌 가점주의에 답이 있다.
  • 남들이 하지 못하는 것을 하고, 남들이 잘못하고 있는 것은 절대 하지 않는다.
  • 그 월급 받아가며 잔업 안 하고 휴일 챙기면서, 당신은 우리(회사)에게 무엇을 줄 수 있느냐?
  • 주도권을 쥐는 자가 주연이다.

덤으로 다음과 같은 내용도 있다.

일본전산에 쓸모없는 사람
  • 변명만 하고 혼을 내는 진의를 이해하려 하지 않는 사람
  • 혼을 내도 진보적 반발심(승부욕)을 가지지 않고 태연한 사람
  • 다른 사람이 혼나고 있는 것에 대해 무관심한 사람
  • 다른 사람을 나무랄 줄 모르는 사람
  • 개인적인 사생활을 전혀 이야기하지 않는 사람
일본전산에서 떠나야 할 직원
  • 지혜를 내지 않는 직원
  • 지시받은 것만 하는 직원
  • 처음부터 다른 사람 힘에 의존하는 직원
  • 곧바로 책임 전가부터 하는 직원
  • 혈기왕성하지 않은 직원
  • 자주 불평불만을 말하는 직원
  • 자주 쉬고 자주 늦는 직원
등용문으로 들어서는 직원의 일곱 가지 조건
  • 건강 관리를 제대로 하는 직원
  • 일에 대한 정열, 열의, 집념을 기복 없이 가질 수 있는 직원
  • 어떤 경우에도 비용에 대한 인식을 가지는 직원
  • 일에 대한 강한 책임감을 가진 직원
  • 지적받기 전에 할 수 있는 직원
  • 꼼꼼하게 마무리할 수 있는 직원
  • 당장 행동으로 옮길 수 있는 직원

이제 사회에 발을 들여 놓은 개발자, 매너지즘에 빠지는 등 성장하지 못하는 개발자들에게, 에자일이니 조직이니 하는 그런 책/발표자료를 읽기 전에 '일본 전산 이야기'를 읽어 볼 것을 권한다. 위에 언급한 내용대로 하자는 건 아니지만, 읽어보고 '자세(attitude)'에 대해서 생각해볼 수 있는 계기가 되었으면 한다.
  1. Shrek 2010.05.20 14:43

    개인적인 사생활을 전혀 이야기하지 않는 사람

    딱 저인데 , 일적인 이야기만 하고, 사적인 이야기 전혀 안하는데...
    책에선 왜 그릇된거라고 하는 거에요? 궁굼해 지네요

    • 최범균 madvirus 2010.05.25 08:44 신고

      피플웨어를 읽어보시면 왜 인지 아실 수 있을 듯 합니다.

    • 2011.08.03 12:36

      제가 생각할땐..
      자기사생활을 이야기 하지 않고, 일이야기만 하고,
      남의 이야기만 듣는 사람은...
      남에게 재미를 주지 못해요..
      또 그런사람들은 이렇게 생각해요..
      내가 왜 남에게 재미를 줘야하지? 개그맨이 아닌데..
      위에서 재미는 포괄적인의미에요.. 흥미, 관심 등등요

  2. 군Go9마 2010.07.15 16:13

    그냥 회사의 노예가 되라는 얘기인거 같네요.

    •그 월급 받아가며 잔업 안 하고 휴일 챙기면서, 당신은 우리(회사)에게 무엇을 줄 수 있느냐?
    -> 월급 말고 회사가 내게 뭘 해주나도 생각해봐야죠.

    •할 수 있다. 즉시 한다. 반드시 한다. 될 때까지 한다.
    •'안 되는' 이유를 쓰느라 시간을 허비하지 마라. '되는' 일에만 집중해도 시간이 모자라다.
    -> 되는 일인지 안되는 일인지 해보기 전에 파악이 가능하면 능력자죠.

    • 최범균 madvirus 2010.07.28 15:13 신고

      물론, 회사가 해 줘야 하는 게 있지요. 하지만, 회사에서 투자하는 돈(월급 등)에 비해 성과를 제대로 내지 못하는 개인/팀/조직이 많은 게 사실이기 때문에 책에 그런 말이 나오는 것 같습니다.

      이 책에서 말하고자 하는 건, 남보다 더 잘 하기 위해서 일본전산이라는 회사와 그 창업주는 이렇게 했다 라는 거구요, 이 책을 읽고서 제가 전달하고 싶었던 건, 결국은 해 내고 싶다는 자세가 중요하다라는 것이었습니다.

      그리고, 위의 요약한 내용을 '회사의 노예'가 되라고 받아들이시는 건 저로서는 다소 이해가 안 되네요. 오히려 위 내용은 '이런 종류의 사람이 없고, 이런 종류의 사람이 있어야' 회사가 성공한다라는 내용에 가까운데요.

  3. kariyan 2010.11.18 10:55

    maven 에 대한 정보를 검색하다가 여기까지 왔네요. madvirus 님은 참으로 열정적인 사람이라 느껴집니다. 여러 글들 잘 읽고 갑니다.

  4. 꼬맹거북 2010.12.02 09:42

    안녕하세요~! 블로그 타고타고 방문하였습니다.

    - 다른 사람을 나무랄 줄 모르는 사람
    - 다른 사람이 혼나고 있는 것에 대해 무관심한 사람

    왠지 찔리내요 ㅜ.ㅜ 결국 어떻게 보면 남에게 무관심한 성향이 큰 이유인거 같은데...
    다시한번 생각하는 기회가 됬어요 ^.^ 위의 글 트랙백 달아도 될까요?

  5. catchAndroid 2015.04.13 11:38

    항상 포스팅 잘보고 있습니다 ^_^

  6. 2015.07.29 15:36

    급여를 얼마나 내치는지 모르겠지만..

    그냥 농노를 데려다 일을 시키지.

    개발자들한테 저게 할 소리인지 모르겠네요.

    한참 오래된 포스크긴 하지만.

    • 최범균 madvirus 2015.07.30 00:19 신고

      이 책의 저자는 기본은 사장이기에 근로자 입장에서 보면 거부감이 드는 구석도 있습니다. 저도 몇 가지 문장은 맘에 안들지만, 자세에 대해 공감가는 부분이 많아 정리했습니다.

여러분은 닮고 싶은 사람이 있나요? 또는 적어도 어떤 면에서는 존경하고 있는 대상이 있나요?

'저 사람은 참 코드가 예술이야', '저 사람은 설계를 잘해~ 나도 그렇게 되고 싶어' 이런 사람이 좀 처럼 떠오르지 않나요?



실력이 좋고 나쁘고에 상관없이 모든 분야에는 좋은 롤 모델이 존재하기 마련입니다. 가수는 또 다른 가수를 롤 모델로 삼고, 스포츠 선수는 또 다른 스포츠 선수를 롤 모델로 삼습니다. 물론, 다른 분야의 사람을 롤 모델로 삼는 경우도 있습니다. 롤 모델은 내가 나아가 방향을 알려주는 나침판과 같은 기능을 하게 됩니다.

개발자들도 역시 본인에게 알맞은 롤 모델을 필요로 합니다. 그 롤 모델은 시간이 지남에 따라서 변할 수 있지만, 롤 모델이 존재하고 명확할수록 내가 해야 할 것을 구체적으로 알 수 있게 되는 것 같습니다. 개발자의 경우 '뛰어난 아키텍츠 그 사람', 'DB 전문가 A씨', '성공적인 프로젝트 관리자 그녀' 또는 '구현 기술이 뛰어난 개발자 폐인씨' 등 다양한 사람들이 롤 모델의 대상이 될 수 있습니다.

하지만, 롤 모델의 대상이 많지 않은지는 모르겠지만, 주변 개발자들은 롤 모델을 갖지 않은 경우가 많습니다. 멘토와 달리 롤 모델은 내가 가고자 하는 길을 안내해주는 역학을 해 주기 때문에, 롤 모델은 나를 성장시켜주는 중요한 원천이 됩니다. 이런 성장 동력을 갖고 있지 못한 개발자들이 많다는 것은 그 만큼 어떻게 커 나가야 할 지 갈피를 못 잡고 있는 개발자가 많다는 것을 의미하는 것 같기도 합니다.

오랜 시간 동안 롤 모델이 없었다면 지금 당장 롤 모델을 고민해 보세요. 롤 모델은 멀리서 찾을 필요가 없습니다. 가급적이면 주변에서 배울만한 부분이 있는 (더 나아가 존경할 만한 부분이 있는) 사람을 찾아보세요. 바로 옆의 동료도 좋은 롤 모델이 될 수 있습니다. 모임에서 만나는 사람 중에서도 롤 모델을 찾을 수도 있습니다. 물론, 컨퍼런스나 강의에서 감동을 준 강사가 롤 모델이 될 수도 있습니다.

롤 모델을 찾았다면, 롤 모델이 되기 위해서 무엇을 해야 할 지 고민해보세요. 롤 모델로 선택한 사람과 대화를 통해서 그들이 어떤 것들을 해 왔는 지 들어보세요. 그리고, 그들처럼 되기 위해 행동하고 노력하세요. 그러다보면 어느 정도 길을 따라 성장하게 됩니다. 물론, 중간에 새로운 롤 모델을 찾고 방향을 바꾸는 경우도 있구요. 무엇이 됐든 중요한 건, 현실에 안주해서 나를 도태시키지 않고 롤 모델을 통해 끈임없이 성장해 나간다는 겁니다.

참고로 개발자 롤 모델을 찾을 때, 파워 블로거인 개발자를 롤 모델로 삼는 건 주의하세요. 글이 그 사람의 모든 걸 보여주는 건 아니고, 글이 그 사람의 실체를 보여주는 건 더더욱 아니니까요. 이런 의미에서 롤 모델은 근처의 잘 아는 사람이나 실제로 누구나 인정하는 업적을 쌓은 사람으로 정하는 것이 좋을 것 같습니다.


  1. okgosu 2009.04.09 02:32

    범균...여차 저차 들렀네...잘 지내지?
    좋은 자료 많네...ㅋㅋ 다 퍼가버릴까부다...^_^;
    잘 보고 가네....

    with okgosu (-..-)a

  2. 아릴랑 2009.10.27 16:56 신고

    롤 모델이 없어서 방황했던거 같군요. 요즘, 공부도 안되고ㅎㅎ 나도 찾아 볼까나??

작년 2/4분기 정도부터 팀 내에서 개발/파트 리더 역할을 수행하고 있고, 그 덕에 기술적인 리드를 하는 것과 더불어 다양한 규모의 프로젝트를 계획하고 관리하는 역할을 수행하고 있다. 그 동안 프로젝트의 규모가 크지 않았고, 그 덕에 어려움 없이(쉬웠다는 것은 아니다) 프로젝트를 진행할 수 있었다.

하지만, 최근에 준비중인 프로젝트의 규모는 내가 감당할 수 있는 범위를 넘어섰고, 난 우왕좌왕하다 결국 바닥이 드러나고야 말았다. 사실 체계적으로 프로젝트를 계획하고 관리하는 교육을 받은 적이 없었기에 규모 있는 프로젝트를 잘 끌고 나갈 수 없었던 건 당영한 결과였던 것 같다.

하튼 그래서 선배에게 도움을 받게 되었고, 그 과정에서 프로세스와 방법론에 대한 몇 가지 원론적인 하지만 매우 중요한 내용을 전달받을 수 있었다. 여러가지 도움이 되는 이야기를 듣고 난 뒤에 집에 가는 길에 문득 5년 전에 읽은 '프로젝트 생존 전략'이라는 책이 떠올랐다. 그 책이 떠오른 이유는 선배가 한 말과 비슷한 내용을 그 책에서 본 것 같았기 때문이었다.

책을 다시 집어들고 읽어봤다. 신기하게도 중요하다고 생각되는 부분에 줄도 쳐저 있었고, 뭔가 열심히 책을 읽은 흔적이 남아 있었다. 그리고 실제로 책속에는 선배의 말과 비슷한 내용이 많이 포함되어 있었다. 중요한 내용을 오래 전에 읽었음에도 불구하고 실천하지 못했다는 생각이 들자, '난 이 책을 읽었으면서도 도대체 왜 실행을 안했지?'라는 자괴감에 빠지고 있었는데,,,,,,,,,,

생각해보니, 그 당시 난 프로세스나 방법론이 중요하다고 해서 책을 읽었을 뿐, 진심으로 그것에 관심이 있었던 건 아니었다. 또한, 설사 관심이 있었다 하더라도 내가 그런 것들을 주도적으로 행할 수 위치가 아니었고, 난 올바른 설계에 코드를 잘 만들어야 하는 위치를 간신히 바라보는 위치에 있었을 뿐이었다. 그래서 책을 읽었어도 그게 마음속에 와닿지 않았고 실천해 옮겨볼 수도 없었다.

이번 경험을 통해서 느낀 건, 지식과 경험은 적당한 시기에 이루어져야 한다는 점이다. 마치 초등학교 1-2학년에게 미적분을 소개한들 이해할 수 없듯이, 개발자들에게 시기에 따라 알맞은 지식과 경험이 필요한 것이다. 그런 의미에서, 만약 지금 자신이 수용하기 힘든 (지식이 어려울 수도 있지만 더 큰 이유는 마음속에 진심으로 와닿지 않아서 힘든) 지식을 접하고 있다면, 그걸 잠시 뒤로 미룬다고 못난 사람이 되는 것은 아니라고 생각된다. 오히려 지금 가장 잘 흡수할 수 있는 것들을 선택해서 빠르게 내 것으로 만드는 게 더 중요한 것 같다.
  1. sharpise 2009.01.13 11:37

    마음에 와 닿는 글이네요. 퍼가도 될까요??
    블로그에 올려두고 두고두고 봐야 할것 같아서요^^

    • 최범균 madvirus 2009.01.14 18:22 신고

      퍼가시는 것 보다는,,, sharpise 님의 블로그에 제 글에 대한 의견을 적어주시고, 트랙백을 이용해서 제 글에 링크를 걸어주시면 어떨까요?

  2. aLex 2009.01.13 18:27

    고생이 많습니다.
    밥 한 번 먹자던 약속은 결국 해를 넘겼네요.
    그래도.. '조만간' 밥 한 번 같이 먹자구요 :)

  3. sharpise 2009.01.16 18:00

    그런 방법이 있군요. ^^ 몰랐네요. 워낙 블로그를 잘 사용안해서^^

  4. 2009.01.19 04:09

    비밀댓글입니다

  5. nungma21c 2009.03.03 14:02

    참으로 공감이 가는 글입니다.
    ServletContextListener 관련 자료를 찾다가 우연히 읽게 되었는데 고개가 절로 끄덕입니다.

  6. 오산돌구 2011.09.20 16:47 신고

    저의 결심과 비슷한 것 같아서 오래된 글이지만 트랙백 걸어봤습니다.
    좋은글들 잘읽고 있습니다. 감사합니다.

초고수 선배와의 술자리에서 얻은 교훈 두 가지.

  • 프로젝트를 원하는 방향으로 이끌어 가는 힘: 공세적 자세
  • Stakeholder에 대한 분석과 알맞은 대처
  • 빅 마우스

프로젝트의 규모가 커질수록, 엮어 있는 사람이 많을 수록 프로젝트를 성공적으로 이끌어 나가기 위해 위의 세 가지를 잊지 말자.
 


  1. Max 2008.12.19 09:32

    위 3가지 중 하나만으로 잘한다면 인정받는 사람이 될수 있을듯 합니다. ^^*

  2. 비기너 2010.03.15 12:52

    빅마우스는 무엇이죠?

+ Recent posts