자바캔(Java Can Do IT)

이전글:

• 2013/10/22 - [개발자이야기] - 작은 프로젝트 구현 이야기 2 - DB 코드 백업 툴 설계 변경
• 2013/10/21 - [개발자이야기] - 작은 프로젝트 구현 이야기 1 - DB 코드(plsql) 백업툴 초기 설계

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

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

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

[실제 쿼리 실행 결과]

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

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

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

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

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

지난 이야기:

• 2013/10/21 - [개발자이야기] - 작은 프로젝트 구현 이야기 1 - DB 코드(plsql) 백업툴 초기 설계

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

• 어린개발자1: 팀장님, SvnKit을 실험해 봤는데요, 원격 리포지토리에 바로 추가/수정/커밋이 되는데요.
• 나: 그래? 아, 그럼 LocalCodeUpdater는 필요 없군!

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

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

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

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

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

• 나: 이제 SvnKit을 이용해서 SvnClient 구현 클래스를 만들도록,
• 어린개발자1: 네!

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

요구사항

요구사항은 간단하다.

• 나: A님, 우리가 만들어야 하는 게 뭐에요?
• A: DB에 있는 프로시저 소스를 백업해주는 프로그램이요.
• 나: 백업은 어디다 해요?
• A: SVN 리포지토리요.
• 나: 버전 관리를 해야 하는 이유라도?
• A: 그게 DB 프로시저가 전혀 관리가 안 되기 때문에, 주기적으로 백업해서 변경 이력을 남기고 싶어요.
• 나: 아, 그럼 매번 전체 프로시저를 백업할 필요는 없겠네요.
• A: 네, 변경된 것만 커밋하는 식으로 하면 좋겠어요. 변경된 프로시저를 구하는 SQL은 여기(저쪽 팀)에서 제공해줄께요.

• 나: 그럼, 지금 바로 시작할 수 있겠는데요. 그런데, 그 쿼리는 언제 주세요?
• A: 글쎄요. 그거 할 사람이 지금 다른 거 하고 있는데 그거 끝나고 줄께요.
• 나: (엄..... ) 언제 끝나는데요?
• A: 아마도 다음주?
• 나: (엄.................) 네. 일단 할 수 있는 것 먼저 시작하고 있을께요.

• 나: 자 tool의 backup() 메서드를 만들어보자고, 일단 테스트 코드에서 tool을 호출하도록 만들고,
• 어린개발자1: (열심히 들음)
• 나: tool 안에서 변경된 코드 목록을 불러와 그걸 로컬 디렉토리에 보관하고, 이를 커밋하도록 만들어야 할 것 같아. tool은 흐름만 관리하게 하고 나머지는 별도 객체가 처리하도록 하자.
• 어린개발자1: (열심히 들음)
• 나: 별도 객체가 처리하도록 할 거니까, backup() 메서드를 실행한 뒤에, 그 객체들이 호출되었는지 확인해보면 될 것 같아.

• 나: DbCode에 뭐가 들어올지 아직 모르니까, 일단 클래스만 만들어두자.
• 어린개발자1: 네~

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

청자는 어디로?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

객체 지향 관련 서적을 읽다보면 원서의 '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'를 좀 더 와닿는 용어로 번역해주었으면 하고 바래보면서 글을 마친다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

현재 내가 하는 역할

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

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

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

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

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

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

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

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

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

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

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

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

• 모든 신기술들을 공부하기
• 하루 종일 코딩하기

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

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

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

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

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

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

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

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

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