주요글: 도커 시작하기
개발 이야기
반응형

앞 이야기:

작은 요구 사항 변경이 발생했다. 최초의 계획은 '전날 6시 이후의 변경 내역'을 읽어와 리포지토리에 반영하는 것이었는데, 대화를 진행하면서, 아래와 같이 변경되었다.

  • 나: 팀장님, 말씀하신 것 개발이 완료되어 가는데요, '전날 6시 이후로 변경된 내역을 보관하도록 했어요. 매일 오전 6시에 배치로 돌리면 될 것 같아요.
  • A: 최팀장, 그거 업무 시간 중에 변경되는 증분을 보고 싶은 그런 것도 있어서 24시간은 너무 긴 거 같아. 좀 더 짧았으면 좋겠는데....
  • 나: 그럼 얼마나요?
  • A: 음.. 10~20분 주기로?
  • 나: 아,, 네. 단순히 일단위 백업이 아니라 소스 버전 관리 느낌을 좀 더 보태고 싶다는 말씀이시죠?
  • A: 네 그래요~
요구사항의 변화를 수용하기 위한 첫 작업: 테스트로부터 개발


이 요구사항을 충족하려면 전날 6시가 아니라 마지막으로 백업 받은 이전 시간을 어딘가에 기록했다가 다음에 실행할 때 그 시간을 찾아야 한다. 기록할 장소로 파일을 선택했고, 이를 반영하기 위해 테스트를 수정했다.


public class BackupToolTest {


    private static final String TIMEFILE_PATH = "target/timefile.txt";

    private DbCodeFinder mockDbCodeFinder = mock(DbCodeFinder.class);

    private BackupTool tool = new BackupTool();

    private SvnClient mockSvnClient = mock(SvnClient.class);

    private ArgumentCaptor<Date> captor;

    private List<DbCode> dbCodeList;


    @Before

    public void setUp() {

        tool.setDbCodeFinder(mockDbCodeFinder);

        tool.setSvnClient(mockSvnClient);


        captor = ArgumentCaptor.forClass(Date.class);


        createDbCodeList();

        when(mockDbCodeFinder.findUpdatedDbCodesBetween(any(Date.class), any(Date.class)))

                .thenReturn(dbCodeList);


        deleteTimeFileIfExists();

    }


    private void deleteTimeFileIfExists() {

        File file = new File(TIMEFILE_PATH);

        file.delete();

    }


    @Test

    public void givenTimeFileNotExists_run() throws IOException {

        tool.backup();


        verify(mockDbCodeFinder).findUpdatedDbCodesBetween(captor.capture(), captor.capture());

        verify(mockSvnClient).commit(dbCodeList);


        List<Date> dateValues = captor.getAllValues();

        Date fromDate = dateValues.get(0);

        // 파일이 없는 경우 하루 전달 이후 변경 분을 읽어오는 지 검사

        assertThat(getTimeByMinutes(fromDate), equalTo(getOneDayBefore()));

        // tool.backup() 실행 후, 지정한 파일에 마지막 실행 시간 기록하는 지 검사

        assertTimeFileWritten(dateValues.get(1));

    }


    @Test

    public void givenTimeFileExists_run() throws Exception {

        givenTimeFile();


        tool.backup();


        verify(mockDbCodeFinder).findUpdatedDbCodesBetween(captor.capture(), captor.capture());

        verify(mockSvnClient).commit(dbCodeList);


        List<Date> dateValues = captor.getAllValues();

        // 변경된 쿼리 구할 때 사용할 시작 시간 값을 파일에서 읽어오는 지 검증

        assertThat(DateUtil.formatDate(dateValues.get(0)), equalTo("20131018120130"));

        // tool.backup() 실행 후, 지정한 파일에 마지막 실행 시간 기록하는 지 검사

        assertTimeFileWritten(dateValues.get(1));

    }


    private void givenTimeFile() throws Exception {

        File file = new File(TIMEFILE_PATH);

        FileCopyUtils.copy("20131018120130", new FileWriter(file));

    }


    private void assertTimeFileWritten(Date toTime) throws IOException {

        String fileContents = FileCopyUtils.copyToString(new FileReader(TIMEFILE_PATH));

        assertThat(fileContents, equalTo(DateUtil.formatDate(toTime)));

    }


    ... // 나머지 다른 메서드들


처음부터 위 테스트 코드가 완성된 것은 아니고, 아래의 순서로 위 코드가 만들어졌다.

  • givenTimeFileExists_run() 메서드를 작성
    • 마지막 실행 시간을 기록한 파일이 존재할 경우, DB에서 조회할 때 사용되는 시간 값으로 파일에 기록된 값을 사용하는지 검사
    • 실행 종료 후 마지막 실행 시간을 지정한 파일에 보관하는지 검사
  • givenTimeFileExists_run() 테스트를 통과시키기 위해 BackupTool의 backup() 메서드 구현
  • 기존 테스트 메서드의 이름을 givenTimeFileNotExists_run() 으로 변경
    • 기존 파일이 없는 경우이므로, setUp() 메서드에서 파일 존재시 삭제 처리
    • 파일이 없는 경우 24시간 이전 시간을 조회 시작 시간으로 사용하는 지 검사
    • 실행 종료 후 마지막 실행 시간을 지정한 파일에 보관하는지 검사
  • givenTimeFileNotExists_run() 테스트를 통과시키기 위해 BackupTool의 backup() 메서드 구현
아직 테스트 코드에서 발생하고 있는 중복을 제거하진 않았지만, 이 과정에서 BackupTool의 backup() 메서드가 완성되었다. 아래 코드는 테스트 코드가 통과된 뒤 약간의 리팩토링을 한 BackupTool 클래스의 일부이다.

public class BackupTool {
    private String timefilePath;
    private DbCodeFinder dbCodeFinder;
    private SvnClient svnClient;

    public void backup() {
        Date fromTime = getPreviousLastTime();
        Date toTime = getToTime();
        List<DbCode> dbCodeList = findUpdatedDbCodesAfter(fromTime, toTime);
        commit(dbCodeList);
        writeLastTimeToFile(toTime);
    }

    private Date getPreviousLastTime() {
        File file = new File(timefilePath);
        if (file.exists())
            return getPreviousTimeFromFile(file);
        else
            return getOneDayBeforeTime();
    }

    private Date getPreviousTimeFromFile(File file) {
        try {
            String fileContents = FileCopyUtils.copyToString(new FileReader(file));
            SimpleDateFormat format = new SimpleDateFormat("yyyyMMddHHmmss");
            return format.parse(fileContents);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

    private Date getOneDayBeforeTime() {
        Calendar time = Calendar.getInstance();
        time.add(Calendar.DATE, -1);
        return time.getTime();
    }

    private Date getToTime() {
        return new Date();
    }

    private List<DbCode> findUpdatedDbCodesAfter(Date fromDate, Date toTime) {
        return dbCodeFinder.findUpdatedDbCodesBetween(fromDate, toTime);
    }

    private void commit(List<DbCode> dbCodeList) {
        svnClient.commit(dbCodeList);
    }

    private void writeLastTimeToFile(Date toTime) {
        try {
            File file = new File(timefilePath);
            FileCopyUtils.copy(DateUtil.formatDate(toTime), new FileWriter(file));
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public void setDbCodeFinder(DbCodeFinder dbCodeFinder) {
        this.dbCodeFinder = dbCodeFinder;
    }

    public void setSvnClient(SvnClient svnClient) {
        this.svnClient = svnClient;
    }

    public void setTimefilePath(String timefilePath) {
        this.timefilePath = timefilePath;
    }

}


이제 남은 작업은 정리하지 못한 코드들을 마저 정리하는 것이다. 이건 어린개발자1에게 숙제로 남겨둘 예정이다.


저작자표시비영리변경금지
Lazy Loading 구현, 개발경험이야기, 지연로딩
반응형

이전글:


드디어 DB에서 변경된 DB 코드(프로시저, 함수, 패키지) 목록을 뽑아주는 쿼리를 전달받았다. 애초에 상상한 쿼리 실행 결과는 아래와 같았다.


[상상속에서 기대했던 쿼리 실행 결과]

OWNER

TYPE 

NAME 

QUERY 

O1

PROCEDURE 

findXXX 

프로시저 코드 

O2

PACKAGE 

somePkg 

패키지 코드 

...

... 

... 

... 


그런데 이게 왠 걸? 실제 쿼리를 실행하지 아래와 같은 결과가 나왔다.


[실제 쿼리 실행 결과]

OWNER

TYPE 

NAME 

QUERY 

O1

PROCEDURE 

findXXX 

프로시저 코드 1번줄

O1

PROCEDURE 

findXXX 

프로시저 코드 2번줄

...

... 

... 

... 

O1

PROCEDURE 

findXXX 

프로시저 코드 n번줄 

O2 

PACKAGE 

somePkg 

패키지 코드 1번줄 


오 마이! 이게 뭐야! 각 PL SQL의 각 코드가 1줄씩 결과로 리턴된다. 


쿼리를 갖고 몇 가지 방법을 쪼물딱 거려 봤으나, 줄 수가 좀(많이) 긴 패키지의 경우 오라클 장비가 먹어주지 못하는 상황이 발생했다. 이런 짜증 날 때를 봤나. 게다가 몇 만 줄이나 되는 패키지가 있다. (실제로 2만 줄이 넘는 패키지가 있다.)


한 번에 모든 쿼리 데이터를 다 읽어올까? 아님 필요할 때 읽어올까? 잠시 고민을 해 봤는데, 최초에 모든 쿼리를 받아서 SVN 리포지토리에 업로드해 주어야 하는 상황이 필요했고. (실DB에 수만 줄에 해당하는 프로시저 덩어리가 얼마나 있는 지 몰라 한방에 모든 DB 코드를 다 읽어오지 않고) DB 코드가 필요한 순간에 코드를 읽어오도록 DbCode 클래스 및 DbCodeFinder 의 코드를 수정했다. 먼저 다음과 같이 getDdl() 메서드를 호출하는 순간에 실제 쿼리 내용을 읽어오는 LazyDbCode 클래스를 추가했다.


public class LazyDbCode extends DbCode {


    private JdbcTemplate jdbcTemplate;


    public LazyDbCode(JdbcTemplate jdbcTemplate) {

        this.jdbcTemplate = jdbcTemplate;

    }


    @Override

    public String getDdl() {

        String query = "SELECT B.TEXT FROM ALL_OBJECTS A, ALL_SOURCE B "

                + "WHERE  A.OWNER = ?  AND A.OBJECT_NAME = ?  "

                + "AND A.OBJECT_TYPE = ?  AND A.OBJECT_NAME = B.NAME  "

                + "AND A.OBJECT_TYPE = B.TYPE  ";


        List<String> queryLines = jdbcTemplate.query(query,

                new PreparedStatementSetter() {

                    public void setValues(PreparedStatement ps) throws SQLException {

                        ps.setString(1, getSchema());

                        ps.setString(2, getName());

                        ps.setString(3, getType().name());

                    }

                }, new RowMapper<String>() {

                    public String mapRow(ResultSet rs, int rowNum) throws SQLException {

                        return rs.getString(1);

                    }

                });

        return queryLinesToString(queryLines);

    }

    

    public String queryLinesToString(List<String> queryLines) {

        ...

    }


}


DbCodeFinder의 구현 클래스인 JdbcDbCodeFinder는 DbCode 대신에 LazyDbCode 객체를 생성해서 리턴하도록 구현했다.


public class JdbcDbCodeFinder implements DbCodeFinder {


    private JdbcTemplate jdbcTemplate;


    public List<DbCode> findUpdatedDbCodesAfter(final Date fromTime, final Date toTime) {

        String query = "SELECT * FROM   ALL_OBJECTS A "

                + "WHERE  SUBSTR(A.OWNER,1,1) IN ('A','B','C','D','E','H')  "

                + "AND    A.OBJECT_TYPE IN ('PACKAGE', 'PACKAGE BODY', 'FUNCTION', 'PROCEDURE', 'TRIGGER')  "

                + "AND    TO_CHAR(A.LAST_DDL_TIME, 'YYYYMMDDHH24MISS')  BETWEEN ? AND ?  "

                + "ORDER BY A.OBJECT_NAME, A.OBJECT_TYPE";

        

        List<DbCode> dbCodeList = jdbcTemplate.query(query,

                new PreparedStatementSetter() {

                    public void setValues(PreparedStatement ps) throws SQLException {

                        ps.setString(1, formatDate(fromTime));

                        ps.setString(2, formatDate(toTime));

                    }

                }, new RowMapper<DbCode>() {

                    public DbCode mapRow(ResultSet rs, int rowNum) throws SQLException {

                        DbCode code = new LazyDbCode(jdbcTemplate);

                        code.setSchema(rs.getString("OWNER"));

                        code.setType(DbCode.Type.valueOf(rs.getString("OBJECT_TYPE")));

                        code.setName(rs.getString("OBJECT_NAME"));

                        return code;

                    }

                });

        return dbCodeList;

    }


SvnClient와 DbCodeFinder의 콘크리트 클래스를 구현이 완료된 시점의 설계는 아래와 같다.



[다음 이야기에서 계속 ...]


저작자표시비영리변경금지
구현 이야기
반응형

지난 이야기:

svn 프로그램을 이용해서 SvnClient를 구현하기로 결정했다. 그리고, 이런 저런 코드를 구현하고 있었다. 그러던 중 SvnKit이라는 자바 모듈을 찾게 되었고, 이 모듈을 이용해서 SvnKit을 실험해 보기로 했다. 실험 결과 SvnKit을 사용하면 로컬에 파일을 따로 보관할 필요 없이 곧 바로 원격 리포지토리에 변경 내역을 커밋할 수 있음을 알게 되었다.

  • 어린개발자1: 팀장님, SvnKit을 실험해 봤는데요, 원격 리포지토리에 바로 추가/수정/커밋이 되는데요.
  • 나: 그래? 아, 그럼 LocalCodeUpdater는 필요 없군!
SvnKit 사용에 따른 설계 변경 (LocalCodeUpdater의 제거)

LocalCodeUpdater가 필요 없어졌다. 그래서 기존의 테스트 코드를 아래와 같이 변경했다.


public class BackupToolTest {

    private BackupTool tool;

    private DbCodeFinder mockDbCodeFinder;

    private LocalCodeUpdater mockLocalCodeUpdater;

    private SvnClient mockSvnClient;

    private List<DbCode> dbCodeList;


    @Before

    public void setUp() {

        tool = new BackupTool();

        mockDbCodeFinder = mock(DbCodeFinder.class);

        mockLocalCodeUpdater = mock(LocalCodeUpdater.class);

        mockSvnClient = mock(MockSvnClient.class);


        dbCodeList = createDbCodeList();

        when(dbCodeFinder.findUpdatedDbCodeAfter(any(Date.class)).thenReturn(dbCodeList);


        tool.setDbCodeFinder(mockDbCodeFinder);
        tool.setLocalCodeUpdater(mockLocalCodeUpdater);
        tool.setSvnClient(mockSvnClient);

    }


    @Test

    public void runBackup() {

        tool.backup();


        verify(mockDbCodeFinder).findUpdatedDbCodeAfter(any(Date.class));

        verify(mockLocalCodeUpdater).update(dbCodeList);

        verify(mockSvnClient).commit(dbCodeList);

    }


LocalCodeUpdater가 필요 없어지면서, SvnClient의 commit() 메서드에 바로 DbCode 목록을 전달하도록 테스트 코드를 수정했다. 컴파일 에러를 잡아주기 위해 아래와 같이 SvnClient를 수정해주고,


public interface SvnClient {

    public void commit(List<DbCode> dbCodeList);

}


이 후, 테스트를 통과시키면서 BackupTool에서 LocalCodeUpdater가 사용되는 부분을 제거하였다.


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(dbCodeList);

    }


    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;

    }

}


이후, LocalCodeUpdater 인터페이스를 제거하였다.


이후 작업은 SvnKit을 이용한 SvnClient의 구현을 진행했다.

  • 나: 이제 SvnKit을 이용해서 SvnClient 구현 클래스를 만들도록,
  • 어린개발자1: 네!
[다음회에 계속.....]


저작자표시비영리변경금지
반응형

요즘 간단한 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

    늘 좋은글 감사해요

    # Delete Reply
diagram, software, UML, visualization, 다이어그램, 소프트웨어, 시각화
반응형

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



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


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


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


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


저작자표시비영리변경금지
  1. 대관령 2014.04.08 22:31

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

    # Delete Reply
  2. 붉은세상 2014.08.27 16:22

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

    # Delete Reply
반응형

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


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


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


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


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




저작자표시비영리변경금지
  1. 김과객 2013.06.11 17:24

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

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

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

    # Delete Reply
    • madvirus 2013.06.12 15:13 신고

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

      # Delete
  2. 남학생 2013.09.30 18:09

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

    # Delete Reply
  3. Reality 2013.11.29 22:02

    안타까운 현실은,

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

    프로그래머 접은 1人

    # Delete Reply
  4. 오치문 2014.02.26 09:46

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

    # Delete Reply
    • madvirus 2014.02.28 17:42 신고

      ^^ 고맙습니다. 작은면 작은데로 한발짝 나갈 수 있도록 노력해야죠.

      # Delete
3 페이지, 시도, 집필, 책, 책쓰기, 출판사
반응형

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


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


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


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


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

저작자표시비영리변경금지
  1. 나그네 2014.03.10 09:39

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

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

    # Delete Reply
발표, 배려, 영어, 청자, 한국어
반응형

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


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


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


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


청자는 어디로?


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

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

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


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


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


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

저작자표시비영리변경금지
개발자, 실무
반응형

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


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


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

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

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


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


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


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


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


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

저작자표시비영리변경금지
  1. 이루리 2013.04.05 16:57

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

    # Delete Reply
  2. 큐라 2013.04.13 15:27

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

    # Delete Reply
  3. bluepoet 2013.04.29 15:19

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

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

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

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

    # Delete Reply
abstract class, concrete class, 구상 클래스, 용어, 추상 클래스
반응형

객체 지향 관련 서적을 읽다보면 원서의 '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

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

    # Delete Reply
    • madvirus 2013.04.09 14:39 신고

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

      # Delete
  2. 야식 2014.02.26 14:28

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

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

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

    # Delete Reply
  3. 마크 2015.05.02 22:09

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

    # Delete Reply
  4. 도움받은자 2017.01.15 15:07

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

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

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

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

    # Delete Reply
  6. 일단은생각해놓은닉넴이없음 2020.09.11 23:40 신고

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

    # Delete Reply
  7. youngik.joo 2021.03.20 08:52

    최범균님의 디자인패턴 책으로 공부하면서 거기 언급된 글을 찾아왔습니다.
    "구상"이라는 용어를 추상과 대비되는 말이라고만 생각하면 어색하지만, "사물이 직접 경험하거나 지각할 수 있도록 일정한 모습을 갖추고 있음"이라는 사전적 의미에 비추어 보면 전혀 어색하지 않습니다. 구현클래스라는 말보다는 구체클래스가 concrete라는 의미에 더 맞는다 생각하고, 구체클래스 보다는 의미에 문제 없고 널리 퍼진 구상클래스란 용어가 좋다고 생각합니다.

    # Delete Reply
    • madvirus 2021.03.21 20:56 신고

      의견 고맙습니다. 말씀하신 부분에 완전 반대하진 않지만 전 아직도 '구상'이란 단어는 많이 어색하게 느껴집니다.

      # Delete
passion, 열정
반응형

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


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


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


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


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


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

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

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


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

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

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


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


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

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

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


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


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


저작자표시비영리변경금지
  1. 백명석 2013.01.08 09:41

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

    # Delete Reply
    • madvirus 2013.01.08 10:08 신고

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

      # Delete
  2. 김광수 2013.01.09 09:34

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

    # Delete Reply
  3. 이호영 2013.01.21 11:15

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

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

    # Delete Reply
  4. 알 수 없는 사용자 2013.02.15 15:36

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

    # Delete Reply
  5. 김용훈 2014.12.08 13:44

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

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

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

    # Delete Reply
  6. msk 2015.11.13 02:55

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

    # Delete Reply
  7. 나영주 2017.05.22 11:32

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

    # Delete Reply
개발자, 고민
반응형

얼마전에 트윗에 올라온 '개발자라고 착각하는 무늬만 개발자?'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 신고

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

    # Delete Reply
    • madvirus 2012.07.10 11:39 신고

      책은 80% 이상 읽어주시면, 쓴 사람으로서 매우 기쁠 것 같습니다. ^^

      # Delete
  2. ddalki 2012.07.09 23:21

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

    # Delete Reply
  3. seungbeomi 2012.07.09 23:45

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

    # Delete Reply
    • madvirus 2012.07.10 11:41 신고

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

      # Delete
  4. msbaek 2012.07.10 14:26

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

    # Delete Reply
    • madvirus 2012.07.10 16:51 신고

      거짓말하시긴요. 열심히 하시는 것 알고 있습니다.

      # Delete
  5. 그누 2012.07.10 15:16

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

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

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

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

    # Delete Reply
  6. innerman 2012.07.20 23:22

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

    # Delete Reply
  7. 체리파플 2013.10.13 01:42

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

    # Delete Reply
PC방환경, 고객환경이해, 뻘 짓, 신뢰사이트
반응형
최근 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 감동을 배웁니다. (건강하시죠?!)

    # Delete Reply
등용문 조건, 떠나야 할 직원, 쓸모없는 사람, 일본전산이야기, 자세
반응형
최근에 'Slack' 이라는 책을 읽고 있는데, 이 책을 읽다 보니 몇 달 전에 읽었던 '일본 전산 이야기'라는 책이 생각났다. '일본 전산 이야기'와 다른 듯 같은 느낌이 들어서, 다시 한번 훑어보았다. 개발자를 위한 내용은 아니지만, 많은 개발자들이 보면 발전하는 데 도움이 될 수 있을 것 같아, 정리를 해 보았다.

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

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

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

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

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

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

    # Delete Reply
    • madvirus 2010.05.25 08:44 신고

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

      # Delete
    • 썰 2011.08.03 12:36

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

      # Delete
  2. 군Go9마 2010.07.15 16:13

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

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

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

    # Delete Reply
    • madvirus 2010.07.28 15:13 신고

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

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

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

      # Delete
  3. kariyan 2010.11.18 10:55

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

    # Delete Reply
  4. 꼬맹거북 2010.12.02 09:42

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

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

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

    # Delete Reply
  5. catchAndroid 2015.04.13 11:38

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

    # Delete Reply
  6. 쩝 2015.07.29 15:36

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

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

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

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

    # Delete Reply
    • madvirus 2015.07.30 00:19 신고

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

      # Delete

+ Recent posts