주요글: 도커 시작하기
예전에 Cvnet이라는 회사에 다닐 적에 임시로 팀장 직책을 수행하셨던 분 한테서 배울점이 많았는데, 그 중 하나는 완성도에 대한 것이었다. 그 분이 제게 해 주셨던 말 중에 가장 기억에 남는 말이 '마지막 1%'에 대한 것이었습니다.

링크가 잘못 걸려 있는데,,

개발작업도 마무리 되었고, 모든 기능이 정상적으로 동작합니다. 이제 남은 건 오픈 뿐입니다. 그런데 이 때 들려오는 한마디.

"여기 링크가 잘못 걸려 있는데,,,,, 여기는 띄어쓰기가,,,,, 어, 여기는 맞춤법이...."

아주 사소하지만 안내 페이지로 가는 링크가 걸려 있지 않았습니다. 작지만 고객 입장에서 중요할 수도 있는 버그가 몇 개 발견되었고, 이런 버그를 오픈 직전에 고쳤습니다.

사실, 개발자 입장에서 이런 링크는 매우 작게 느껴지고, 심지어 별 것 아닌 것 처럼 생각하기도 합니다. 하지만, 고객들은 이런 작은 것 하나 하나에 감동과 (그리고 아마도 감동보다 더 큰) 실망을 할 겁니다. 소위 말하는 명품이라는 것들이 아주 작은 사소한 부분의 디테일까지 감동을 주는 것 처럼, 개발자가 만드는 어플리케이션도 작지만 사소하지 않은 마지막 1%를 채워줄 때 비로소 제품의 품질이 완성된다고 생각합니다.

문제는 개발자들은 이런 디테일을 잘 챙기지 못 한다는 겁니다. 자신이 개발한 코드를 테스트 할 때에는 아무래도 잘 동작하는 방식으로만 테스트를 하는 게 개발자의 습성인가 봅니다. 이런 이유로 제품 테스트는 개발자 당사자가 진행할 경우 놓치는 부분이 많습니다.

1%를 채우기 전에 해야 할 것, 악랄한 테스트!

이런 이유로 올 여름에 오픈했던 프로젝트에서는 QA를 진행하기 전에 내부적으로 테스트를 전담으로 해 줄 사람을 따로 지정했습니다. 그 사람은 프로젝트 개발에 참여하지 않았던 개발자였습니다. 제가 주문한 건 딱 하나였습니다.

"악랄한 테스트 부탁해요!"

그 담당자는 주문한대로 입력 폼 값부터 RIA 조작까지 모든 부분에 대해 코드를 작성한 개발자가 상상도 못한 방법으로 테스트를 수행했고, 그 덕분에 상당량의 버그(기능뿐만 아니라 UX, UI 측면까지)를 고치느라 개발자들이 일부 고생을 하기도 했습니다.

이 악랄한 테스트 덕에 실제 QA 테스트에서는 동작 이상보다는 마지막 1%를 채우기 위한 버그가 주로 리포트 되었습니다. 개발자들은 프로젝트 막바지에 기능 버그가 아닌 간단한 HTML 코드 수정 위주의 작업만으로 오픈 준비를 마무리 할 수 있었습니다.

개발자들의 자세 변화 필요

개발자들은 (저도 역시 그랬지만) 잘못 걸린 링크나 잘못된 맞춤법, 또는 디자이너가 요구하는 디테일을 작게 보거나 무시하는 경향이 있습니다. 하지만, 이런 (나쁜) 자세는 결국 제품의 질을 낮추는 요인 중의 하나가 되고 이로 인해 고객들은 점점 제품을 떠나게 될 겁니다. 제품 경쟁력이 떨어지면,,,, 음,,, 최악의 경우 일자리를 잃을 수도 있습니다.

그 동안 1%를 무시했던 개발자라면 이제라도 자세를 고쳐 잡아야 할 때라고 생각합니다. 특히, 지금처럼 디자인과 감성이 필요한 시대에는 개발자의 능력만으로는 뛰어난 제품을 만들어 낼 수 없으니까요.

  1. locust 2008.12.29 13:05

    '뭐 저런걸 가지고, 그냥 넘어가도 될껄...'
    '뒤늦게 그런 사항을 띄우면 지금에 와서 어떻게...'

    이런 생각들을 가졌던 때가 있었습니다.
    완벽한것이 있겠느냐는둥 스스로 합리화 해서 스트레스를 덜 받으려는 나쁜 버릇이었지요.
    그러나 그 버릇은 이것도 예상하지 못한 당신이 꼼꼼하지 못하다며 상급자를 탓하는 방법에서 부터 개발자에게 있어서 중요한고도 많은 부분들의 생각을 허술하게 만들어 버렸습니다.

    '완벽함은 없다.' 의 사고에서 파생되어 버린 치명적인 사고의 버그들입니다.
    스트레스를 덜 받기위한 합리적인 사고가 아니라는것을 뒤늦게서야 깨닫고, 고쳐나가기 시작했습니다.

    지금은 '완벽함에도 기준이 있다.' 입니다.
    기준점에 도달하기 위해서 최선을 다합니다.
    상급자가 테스트를 거치고 아무런 버그가 없다고 오픈하자고 했을 때 희열을 느낍니다.

    작은 생각의 변화가 더 나은 자세를 만들어간다고 생각하고 있습니다.

능력이라는 건 상대적인 것이고, 또한 능력이라는 건 여러 가지 요소의 조합으로 표현되기에, 딱 잘라서 능력을 어떤 수치로 표현할 수는 없습니다. 능력을 표현할 수 있는 객관적인 수치가 있는 분야는 (예를 들면 스포츠?) 수치의 높고 낮음으로 실력이 좋다 나쁘다를 표현할 수 있지만, 개발자와 같이 명확한 수치가 없는 분야에서는 능력의 좋고 나쁨을 표현해 내기가 매우 힘듭니다. 물론, OCP, SCJP, 기능사와 같은 자격증 제도가 있긴 하지만, 국내 실정상 자격증이 곧 능력을 대변하지는 못합니다.

어떤 객관적인 지표가 없다보니, 개발자들은 여러 가지 주관적인 지표를 이용해서 능력을 비교할 수 밖에 없습니다. 이 바닥에서 일을 하면서 여러 사람들과 대화를 나눠보니, 연차가 적을수록 주관적인 지표로 다음과 같은 기준을 사용하는 것 같습니다.

  • 나보다 먼저 어떤 기술(특히 프레임워크)을 익히고 잘 사용하느냐?
  • 나보다 어떤 툴(특히 이클립스)을 잘 쓰느냐?
  • 블로그 또는 카페 활동을 왕성하게 하느냐?
  • 심지어, 어떤 특정 트릭을 아느냐?
  • 코딩을 나보다 빨리 하느냐?

본인이 맡은 역할에 따라서 능력을 바라보는 관점이 다르겠지만, 위의 기준을 갖고서 능력을 평가한다는 건 솔직히 매우 슬픈 일입니다. 심지어 경력이 3-4년 이상되는 개발자 조차도 이런 기준으로 하는 경우를 보면 정말 슬픕니다. (실제로 이런 사람들을 많이 접했고, 지금도 많이 접하고 있습니다.) 게다가 화가 나는 건, 남보다 (아주 조금) 먼저 프레임워크 사용법을 익혔다고, 또는 블로그에 주저리 주저리 이런 글 저런 글 좀 쓴다고, 본인이 능력이 있는 개발자라고 생각하는 사람들이 있다는 겁니다.

물론, 어떤 기술을 사용할 줄 아느냐, 어떤 툴을 사용할 줄 아느냐, 트릭을 아느냐, 코딩이 빠르냐는 능력을 재는 한 기준이 될 수 있습니다. 특히 1-2년차의 개발자들을 평가할 때에는 주어진 시간 내에 특정 기술을 이용해서 시킨 일을 얼마나 잘 해내는 지가 능력을 평가하는 주요 기준이 될 수 있습니다. 하지만, 3-4년 이상이 되면 단순히 코드를 좀 빨리 만들어내는 것만으로는 능력을 평가할 수 없고, 5년차가 넘어가면서부터는 코딩 좀 한다 그래서 능력이 좋다고 평가할 수 없게 됩니다.

그런데 아쉽게도 3-4년차의 개발자와 5-6년차의 개발자가 아무 차이가 없는 경우를 많이 봤습니다. 5-6년차 개발자들이 1-2년차보다 프레임워크 좀 사용줄 알고 경험에 의해 알게된 몇몇 개발 노하우 말고는 3-4년에서는 느낄 수 없는 그 무언가를 느낄 수 없는거죠. 심할 때에는 7-8년차 되는 개발자들 조차도 3-4년차 개발자하고 별반 차이가 없는 것을 볼 때도 있습니다.

당신이 3-4년차의 개발자라면 주변을 한번 둘러보세요. 5-6년차, 또는 그 이상의 경험을 가진 개발자들로부터 무엇을 배우고 있는지 생각해보세요. 당신이 조금만 노력하면 찾을 수 있는 것 이상의 것을 배울 수 없다면 당신은 능력을 향상시킬 수 있는 기회를 얻지 못하고 있는 겁니다. 나중에 당신이 그들처럼 되지 않으려면, 지금부터 배움을 얻을 수 있는 사람을 찾기 위해 노력하세요. 그렇지 않다면 당신의 실력은 2-3년 후에도 여전히 지금 그 자리에 머물겁니다. 물론, 이 바닥에서 능력을 쌓아 나가고 싶지 않다면 그냥 그 수준에서 머물러도 상관없습니다.

당신이 5-6년차 또는 그 이상의 개발자라면 주변을 한번 둘러보세요. 3-4년차의 개발자들이 당신으로부터 무엇을 배우고 있나요? 혹시 코딩 좀 잘하는 걸로 뻐기고 있지는 않나요? 아니면, 3-4년차하고 별 차이가 없나요? 물론, 이 바닥에서 더 머무르고 싶지 않다면 그냥 버티고 살면 됩니다. 하지만, 배움을 얻을 수 있는 사람이 없어서 그런 것이었다면 지금이라도 늦지 않았습니다. 조금이라도 빨리 배움을 얻을 수 있는 선배를 찾으세요.

전 어떠냐구요? 고수냐구요?? ,,,,, 음,,,, 저 역시 능력 없는 중수에 불과합니다. (경력은 좀 되니 경험에 의해 하수는 면할 수 있을 것 같네요) 그래서, 저도 저를 좀 발전시켜보고자 몇년 전에 배움을 줄 수 있는 선배를 찾아 갔습니다. 운이 좋게도 여러 선배들을 만날 수 있었고, 그 선배들로부터 많은 배움을 얻을 수 있었습니다. 그 덕에 지금은 점점 능력이 향상되고 있는 저를 발견하고 있고, 앞으로도 많은 배움을 통해 발전하게 될 거란 생각을 갖고 있습니다.

혹시 여러 분 중에 3-4년차 개발자가 있다면, 능력에 대해서 고민을 해 보시기 바랍니다. 그리고 저처럼 불필요하게 2-3년을 허비하지 말고 좀 더 빨리 능력을 향상시킬 수 있는 방법을 찾기를 기도합니다. 물론, 가장 좋은 방법은 좋은 스승을 만나는 거라고 생각합니다.


  1. DevBear 2009.01.20 17:13 신고

    초급 개발자로 좋은글 읽고 갑니다.

  2. 용식 2009.01.23 15:07 신고

    좋은 스승을 만나는 것...
    요즘들어 정말 너무 공감가는 말씀이십니다.

    좋은 글 잘 읽고 갑니다. ^^

  3. 나도 좋은스승 만나고싶습니다. 2009.02.21 13:11

    프로젝트 안되면 도망가버리는 그런스승 정말 싫습니다. ㅜㅜ

  4. 초보자 2009.08.20 11:22

    막 자바를 시작하는 초보자입니다.

    정말 피가되고 살이 되는 글이네요^^ 잘읽고 갑니다.

  5. 비기너 2010.03.14 21:06

    나중에 제자가 되어 찾아가겠습니다 +_+

  6. 하수 2011.04.15 17:49

    정말 공감되는 글입니다.....

    다른사람이 만든 어떤 기술을 먼저 공부해서 안다고 고수라고 할 수 없죠....

    진정한 고수는 무에서 유를 만들어내는 남들이 생각해내지 못한걸 생각해내는 사람이 아닐까 합니다^^

  7. ... 2012.03.07 15:34

    좋은글 읽고 갑니다 감사합니다 ^^

  8. 지유 2013.08.12 10:34

    많은 자극 받고 갑니다^^

  9. 체리파플 2013.10.13 01:59

    글 잘 읽었습니다.
    정말 디테일하게 파고들면 몇 년차는 어느정도 실력이 있어야 하는지 궁금합니다

    • 최범균 madvirus 2013.10.14 16:12 신고

      연차별 실력이라기 보다는,,, (연차는 의미가 너무 없으니까요..)
      그냥 제 맘대로 한 번 적어보면요~

      - 신입: 열심히 구현 따라서 한다. 시킨 거 하려고 많이 노력한다. (틈틈히 공부한다.)
      - 같은 분야 몇년 경험 후 (적어도 중급이라면): 앞서 경험한 분야에 대한 구현은 알아서 먹는다. 해당 분야의 신기술 적용시에도 어느 정도는 알아서 먹는다. 작은 규모는 혼자서 먹을 줄 안다.
      - 대충6~7년 이상(적어도 중급 떼려면): 중간 규모 프로젝트를 (혼자서 또는 도움을 받아서) 그려낸다. 더불어, 대략 소규모 인원(2~4명 수준)의 개발 리딩을 한다. 구현기술 기본에, 설계 지원/결정도 해 낸다.
      - 이후는 구현/프로젝트/리더십 등 다양한 분야에서 능력을 키우고, 발휘한다... 정도가 될 것 같아요.

  10. 비가오면 2015.11.13 14:53

    개발 7년차이지만 실력은 2~3년차인 개발자입니다.
    글에 많은 공감을 하고 반성도 하고 갑니다. ^^

  11. sunghyun1200 2016.10.13 14:11

    1년차 이지만 좋은글에 많이 와닿았습니다.. 틈틈히 열심히 공부하겠습니다.

설 연휴 기간에 본가에 가서 이래 저래 노는데, 엄마가 제가 중1때 (음, 그러니까 18년 전 쯤?) 엄마에게 썼던 편지를 와이프에게 보여주더군요. (부끄럽게 그런 편지는 왜 보여주시는지..... ) 사실 뭐라고 썼는지 하나도 기억나지 않아서 저도 한번 읽어봤습니다. 그 편지에는 제가 어릴 때 소망했던 꿈이 적혀 있었습니다. 하나는 기능장이 되는 것이었고, 다른 하나는 다른 사람들이 프로그래머가 될 수 있도록 돕는 것이었습니다.

중 1 때, 전 정보처리 기능사 2급을 준비하고 있었는데, 기능장은 매우 뛰어나 프로그래머라고 생각했었나 봅니다. 그래서 기능장이 되고 싶다고 했었던 거죠. 지금 생각해 보면 웃음이 나기도 하지만, 사실 프로그래머로서의 꿈은 초등학교 4학년(1987년)때부터 시작되었습니다. 그 당시에 시청에 있는 삼성그룹 본사 건물 1층에 컴퓨터 전시실이 있었는데, 그때 SPC-1500이나 애플과 같은 컴퓨터를 처음 보는 순간 컴퓨터라는 놈에 끌리게 되었습니다. 북아현동 집에서 시청까지는 걸어가면 30분-40분 정도의 시간이 걸리는데, 컴퓨터를 치고 싶은 마음에 틈만 나면 걸어서 시청까지 갔다오곤 했을 정도로 마냥 좋았습니다.

컴퓨터에 대한 애정은 점점 커져서 저도 프로그래밍이란 걸 해 보고 싶어졌습니다. 집착이 과했는 지 그만 신촌문고에서 컴퓨터 책을 훔치는 대담한 짓을 하기에 이르렀습니다. (초딩놈이 참.... 이땐 정말 미쳤나봅니다.) 아무것도 몰랐지만, 그냥 코드를 보면서 좋아했었죠. 하지만, 꼬리가 길면 밟힌다고 몇 번 책을 훔치다 결국은 들통이 났고, 엄마한테 뒤지게 맞았습니다. 물론, 그 덕에 컴퓨터 학원에 다닐 수 있게 되었죠 (태어나서 이때처럼 맞아본 적이 없을 정도였죠...)

이후로 전 컴퓨터에 빠져살게 되었고, 중1이 되었을 때 기능장이라는, 즉 뛰어난 프로그래머라는 꿈을 가지게 되었습니다. 여전히 갈길이 멀고 멀어서 이 꿈을 이룰 수 있을 지 모르겠지만 지금처럼 한발 한발 내딛다 보면 언젠가 꿈 근처에는 갈 수 있지 않을까 라는 생각을 해 봅니다.

편지에 써 있던 두번째 꿈은 다른 사람들이 프로그래머가 될 수 있도록 가르쳐서 더 많은 사람이 좋은 프로그래머가 될 수 있도록 돕겠다는 내용이었습니다. (^^; 중학생이라서 이런 생각을 참 쉽게 했던 거였던게죠) 그때 제가 무슨 생각으로 이걸 꿈이라고 편지에 적었는지 모르겠네요. 단순히 컴퓨터 학원 선생이 되겠다고 이 꿈을 적은 것 같지는 않고 하튼 편지를 보면서 웃음이 절로 났죠. 지금 제가 갖고 있는 꿈 중의 하나는 많은 개발자들이 좀더 빠르고 효과적으로 개발을 할 수 있도록 도움을 주는 것인데, 어떻게 보면 어릴 때 꾸던 꿈이 좀더 현실성 있게 바뀐 것도 같습니다.

사실, 두번째 꿈은 제가 책을 쓰고 자바캔이라는 사이트를 운영할 수 있도록 해주는 원동력이자 이유이기도 합니다. 1999년도에 처음 책을 썼으니까 어느덧 책을 써 온지도 회수로 9년이 되어 가는데, 그 동안 책을 통해서 지식을 나누려고 많은 노력을 해 왔습니다. 아직은 보잘 것 없는 것들에 불과하지만 이런 노력이 이어진다면 언젠가 많은 사람들에게 도움을 주고 보탬이 되고 나아가 또 다른 꿈을 심어줄 수 있을 거라 생각합니다.

(첫번째 책이 궁금하신가요? 그럼, http://www.kame.co.kr/book_main.html?board=kame_book&work=read&tcode=73&tbook_top=&tbook_jong=3 사이트를 한번 보세요. 부끄럽지만 저의 처녀작입니다.)

전혀 생각도 못 하고 있었는데, 어릴 적 꾸던 꿈을 이루기 위해 하루 하루 살아 나가고 있다는 것이 새삼 놀라워서 새벽녘에 글을 썼습니다. 이룰 수 있을 지는 모르겠지만, 전 지금도 꿈을 꾸고 있고, 이 꿈을 이루기 위해 앞으로도 계속 한걸음씩 걸어나가 볼까 합니다.

여럿이 어플리케이션을 개발하다보면 레이어를 나눠서 개발을 진행하곤 합니다. 이때, 각 레이어는 인터페이스를 사용해서 통신을 하는 게 일반적일 겁니다. 웹의 경우 클라이언트의 요청을 전달받는 컨트롤러와 비즈니스 로직을 처리하는 도메인 부분 그리고 영속성을 관리하는 부분 등이 존재하게 되는데, 각 부분은 레이어를 구성하게 될거고 인터페이스를 통해서 서로 통신하게 될 겁니다.

각 레이어를 나눠서 개발하다보면 아직 상대방이 구현하지 않은 기능을 내 코드에서 필요로 하는 경우가 있습니다. 이럴 때 mock 이란 놈을 사용하게 되죠. 자바에서는 jmock이나 easymock을 사용해서 이런 mock 객체를 생성하곤 하는데, 사실, 이 두 라이브러리를 사용하는 게 그리 쉽지만은 않습니다. 일단, 외워야 할게 많기도 하고, mock 라이브러리 자체가 검증(assertion) 기능이 있어서 이 두 라이브러리를 잘 사용하려면 그런 기능도 익혀야 하죠.

이런 라이브러리가 좋긴 하지만 제가 보통 작업을 할 때에는 이런 다양한 기능을 제공하는 mock 라이브러리가 필요한 것이 아니라, 제가 원하는 기능을 (주로 가짜로 동작하는 기능을) 제공해주는 mock이 필요한 경우가 더 많았습니다. 그래서, 인터페이스를 직접 implements 한 mock 클래스, 즉 또 다른 구현 클래스에 가짜 구현 코드를 넣는 방법을 사용하는 경우도 많았습니다. 하지만, 이 경우 인터페이스가 변경되면 mock 클래스의 코드에 (필요하지 않아도) 코드를 추가해주어야 한다는 불편함이 따랐습니다.

이런 불편함을 없애고자 간단하게 mock 객체를 만들어주는 유틸리티를 하나 만들었죠. 이름도 tle 프로젝트에서 만든 mock 이라는 의미로 tlemock으로 했답니다. 그런데, 요즘 제가 Maven을 주로 사용하는 터라, Maven 프로젝트에서 제가 만든 tlemock을 쉽게 사용했으면 좋겠다는 생각이 들었습니다.

그래서!!!, tlemock을 maven 중앙 리포지토리에 등록하기로 결심했습니다. tlemock을 maven 중앙 리포지토리에 등록하기 위해 도메인도 따고(^^;) 안내 페이지도 만들었습니다. 배포판도 구글 코드를 통해서 배포했구요. 그리고 나서, 지난 금요일 저녁 maven 중앙 리포지토리에 올려 달라는 요청을 보냈습니다.

그리고, 드디어 오늘 maven 중앙 리포지토리에 tlemock이 올라갔습니다. ^^ 아,, 뭐랄까... 제가 만든 아주 작지만 그래도 누군가에겐 저처럼 유용하게 쓰일 수 있는 mock 라이브러리를 maven 프로젝트에서 손쉽게 사용할 수 있게 되었다는 생각에,, 왠지 모를 뿌듯함이 밀려오더군요. 살짝이 흥분도 되구요. (거짓말 좀 보태면 감동받은 상태라고 할 수도.... )

이번주 내에 tlemock을 사용하는 방법을 정리해서 자바캔에 올릴까 합니다. 그리고, 몇몇 사이트에 공지할 생각이구요.

http://www.tleproject.net/tlemock 사이트에 어설픈 영어로 정리한 tlemock 문서가 있습니다. 영어는 엉망이지만 샘플 코드를 보시면 코드를 보시면 비교적 쉽게 어떤 식으로 tlemock이 동작하는 지 아실 수 있을 겁니다. ^^ 궁금하시다면, 한번 방문해보세요.

* 처음으로 전 세계 개발자에게 기여를 할 수도 있다는 생각에,,, 정말 흥분되는 하루였습니다.

모든 분야가 그렇겠지만, 어느 순간 실력이 몰라보게 향상되었음을 느낄 때가 있습니다. 저 같은 경우는 개발자의 길로 접어들면서 이런 느낌을 두번 경험한 것 같습니다.

처음 이런 느낌을 받았을 때는 대학교 3학년 때 쯤이었습니다. (이때는 처음으로 자바와 관련된 책을 쓴 시기이기도 했습니다.) 책을 쓰면서 자바라는 언어를 많이 알게 되었고, 동아리 전시회에 참여하면서 이런 저런 프로그램을 만들게 되었습니다. 브루마블이라던가, RMI를 사용한 게임 프로그램, 인터넷 바둑과 같은 프로그램을 만들면서 한 단계 밟고 올라간 듯한 느낌을 경험할 수 있었습니다.

또한번 이런 경험을 느끼게 된 건 병역특례 생활을 하면서였습니다. 병역특례 기간 동안에도 꾸준히 다양한 공부를 하고, 또 꾸준히 책을 쓰고, 대학에서는 할 수 없었던 실전 경험들을 쌓으면서 다양한 문제들을 해결해 나갈 수 있는
바탕을 만들었고, 이런 경험을 기반으로 다시 한번 실력이 향상됨을 느낄 수 있었습니다.

실력이 몰라보게 향상된 느낌을 표현할 때 전, '한 계단 올라선 것 같다' 라고 합니다. 이런 느낌은 조금씩 조금씩 지식이 쌓이는 것 같기 보다는 어느 순간 실력이 수직적으로 향상되는 듯 하기 때문이죠. 하지만, 실제로 지식이 조금씩 쌓이지 않았다면 이런 계단을 올라간 듯한 느낌을 일어날 수 없습니다. 어느날 갑자기 실력이 향상된 것을 느끼게 되는 이유는 그 동안 공부해왔던 다양한 지식들이 서로 연결되면서 이전보다 더 넓은 시야를 갖게 되었기 때문일 것입니다.

이런 시각에서 볼 때 최근 3-4년간 전 계단을 올라갈 만큼의 발전을 거두진 못한 것 같습니다. 이제 계단을 한번 더 밟고 올라가기 위해 노력할 때인 것 같습니다. 그 동안 등한시해왔던 다양한 지식들을 다시 한번 살펴보고, 그런 지식들을 함께 묶어낼 수 있는 경험을 쌓아야 할 것 같습니다. 다행히 계단 밝기를 지원해줄 분도 계시기에 노력을 한다면 1~2년 후에는 한단계 더 발전한 제 모습을 볼 수 있을 것 같습니다.

자, 여러분도 저와 같이 계단 한칸을 올라가 볼까요?


개발의 사이클을 간단하게 생각해보면, (머리속에서 생각을 하든, 종이에 그리든, 툴을 사용하든) 설계를 하고, 설계에 따라서 코드를 작성하고, 그리고 테스트를 해 봅니다. 테스트에 성공하면 그 코드는 넘어가고 다음 코드를 만들게 됩니다. 만약 테스트에 성공하지 못하면 어디가 문제인지 찾아내서 문제점을 보완하고 다시 테스트를 수행합니다. 이 과정은 테스트가 통과될 때 까지 반복됩니다.

이런 과정은 개발자에게 꽤 많은 스트레스를 제공합니다. 특히 문제가 어느 부분에서 발생하는 지 알 수 없는 경우에는 더더욱 그렇습니다. 심지어 동일한 코드인데 상황에 따라서 문제가 발생하는 경우도 있는데, 이런 경우는 개발자를 미치기 일보 직전까지 몰고 가기도 합니다.

처음부터 완벽한 코드를 작성하면 좋겠지만, 그게 뜻대로 되진 않을 겁니다. 가급적 오류 없는 코드를 만들기 위해 노력해야 하지만, 어쨋든 버그를 찾는 과정은 반드시 존재하기 마련입니다. 여기서부터 개발 속도가 차이나기 시작합니다. 어떤 개발자는 정말이지 빠른 시간에 버그를 찾아서 수정합니다. 하지만, 어떤 개발자는 똑같은 버그를 반나절을 다 보내고도 찾아내지 못하고 여전히 코드를 해맵니다.

이것이 바로 디버깅 능력의 차이입니다. 디버깅 능력이 뛰어난 개발자는 결국 개발을 빠르게 완료하게 됩니다.

이런 이유로 출현하게 된 것이 TDD(Test Driven Development)가 아닐까 하고 생각합니다. 즉, 테스트 코드를 미리 작성해서 올바르게 돌아가는 코드를 만들도록 강요하는 개발 방식인거죠. 이는 확실하게 스트레스를 줄여주는 효과를 갖고 있습니다. 그래서 처음 개발을 시작할 때에는 TDD를 사용하는 것이 디버깅 시간을 획기적으로 줄여주게 됩니다.

하지만, 굳이 TDD 기법을 사용하지 않더라도 디버깅 능력은 키우는 것이 좋습니다. 언제 어디서나 TDD를 사용할 수 있는 것은 아닐테니까요. 그리고 디버깅 능력을 키운다는 것은 곧 남들보다 빠르게 개발할 수 있다는 것을 뜻하기도 합니다. 그러니, 디버깅 능력을 키우세요. 코드를 만들어내는 능력만큼이나 중요한 능력이 바로 디버깅 능력이니까요!


몇번인가 이런 말을 들어본 적이 있습니다.

"어떻게 OOO 패턴을 이렇게 쓸 생각을 하셨어요?"

제가 썼던 노하우책이나 틀 프레임워크의 소스 코드를 보면 흔히 말하는 패턴이 몇개 나타납니다. 그러면서 또 하나 나타나는 반응이 이렇습니다.

"책으로 이런 패턴들을 봤지만 실제로 사용하려면 어려워요"

그렇습니다. 물론 어렵습니다. 단순히 패턴 관련 책을 한두번 읽고, 그 패턴을 당장에 어디엔가 써 먹을라고 하면 참 난간합니다. 언제 어떤 써야 할지 도무지 모를 일이죠. 책에는 A 경우에 B 패턴을 사용하라고 나와있지만, 아쉽게도 내가 처한 상황은 A가 아니라 C 이고, 그래서 B라는 패턴을 적용해도 맞는 건지 잘 모르는 상황이 발생합니다. 그렇다고 다른 패턴을 적용할 수 있는 것도 아닙니다. 다른 패턴을 설명하면서 사용한 상황 역시 내가 처한 상황과 딱 맞아떨어지지 않기 때문이죠. 그래서 패턴 적용을 포기하기에 이릅니다.

그렇다면 어떻게 하면 책에 없는 상황에서 다양한 패턴을 알맞게 적용시켜 멋진 설계를 할 수 있을까요? 대답은 단 하나뿐 것 같습니다.

"실수에 상관없이 반복해서 패턴을 적용한 코드를 작성해 보는 것!!!!"

패턴을 잘못 적용해도 좋습니다. 일단 이런 저런 패턴을 적용해서 코드를 작성해보세요. 패턴을 적용하는데는 정답이 없습니다. 그냥 패턴을 적용했더니 꽤나 괜찮았거나 별루였던 상황이 존재할 뿐입니다. 패턴을 적용해봤는데 영~ 별루인 설계가 나오는 경우가 있습니다. 이럴 땐 마음속으로 '이게 바로 안티패턴이군' 이라고 한번 외치고, 다음부터 그 패턴을 잘못 적용하지 않으면 됩니다. 패턴을 적용했더니 멋드러진 설계가 나오면 그땐 탄성한번 지르고 다음에 또 써먹으면 됩니다.

이렇게 실수와 성공을 반복하다보면 우리는 어느새 멋진 설계를 할 수 있는 사람으로 변신하게 됩니다. 겉멋만 들어서 '적어도 패턴 정도는 써야지' 라면서 설계를 하다보면 그런저런 설계는 할 수 있어도 멋진 설계는 못하게 됩니다. (저역시 몇가지 패턴을 겉멋에 쓰다가 낭패를 본적이 있었습니다. 그덕에 코드를 거의 처음부터 다시 설계해야 했었죠.)

또 다른 방법은 꽤나 괜찮게 설계했다고 생각한 코드를 그대로 따라서 작성해보는 겁니다. 예전에 네트워크 프로그램을 처음 배울 때 무조건 책에 있는 코드를 따라했던 기억이 나네요. 그땐 저에게 있어서 그 책에서 제시한 패턴이 네트워크 프로그램의 정답과도 같았습니다. 몇번 같은 방식으로 작업하다보니 변형이 필요해졌고, 그 과정에서 네트워크 프로그램의 또 다른 설계 방식을 찾게 되었습니다. 즉, 모방속에서 새로운 걸 배우게 된거죠.

설계를 잘 못한다고 설계를 두려워하시는 분들은 일단 많은 코드를 작성해보세요. 다양한 코드 작성 경험없이 멋진 설계는 나오지 않으니까요. 계속해서 코드를 작성하다보면 자연스럽게 다양한 상황에서 알맞은 설계를 하는 방법을 익히게 될 것입니다.

정말 드럽게 일이 손에 안 잡히는 날이 있습니다. 키보드를 치려고 마음 먹다가도 어느새 마우스로 IE 아이콘을 클릭하고는 나도 모르게 웹 사이트를 방문하곤 합니다. 시간은 너무나도 안 흘러가고 지루하고 그지없고 왠지 허탈한 그런 날이 있습니다. (오늘 같이 비가 부실 부실 오는 날도 일 하기 싫어지는 그런 날입니다. 앗, 그러고 보니 날이 너무 좋아도 일하기 싫은데, 아무래도 전 일하기 좋은 날이 없나봅니다.)

하지만, 이런 날을 이겨내지 못하면 그 만큼 우리의 프로젝트는 뒤로 밀리게 됩니다. 업무 흐름이 한번 끊기면 그 다음에 다시 업무 흐름을 찾기까지는 시간이 꽤나 걸립니다. (톰 디마르코와 티모시 리스터가 쓴 피플웨어란 책을 보면 플로에 대한 얘기가 나오는데, 이 플로에 대해서 한번 읽어보시면 이해가 좀더 빠를 겁니다.) 그래서, 하루를 버리면 실제로는 2틀이란 시간을 버리는 것이나 마찬가지입니다.

무료하고 허무한 날을 이겨내기란 쉽지만은 않습니다. 하지만, 이런 날을 이겨내야 하는게 개발자의 숙명입니다. 개발자들은 언제나 정해진 일정에 따라 일을 진행하기 마련인데, 하루를 날리면 그 만큼 일정에 대한 압박 강도가 높아지게 됩니다. 일정의 압박이 높아질수록 야근은 점점 늘어나고, 밤샘작업도 늘어나게 되고, 몸은 조금씩 망가지기 시작합니다. (스트레스로 인한 정신질환을 앓을지도 모를 일입니다.)

그래서, 하루에 조금이라도 앞으로 나아가는 게 중요합니다. 드럽게 일이 안 되는 날이라도, 개발툴을 띄우고 파일을 열고 코딩을 조금씩이라도 해 나가보세요. 웹 개발자라면 한 페이지라도 만들고, 데스크탑 어플리케이션 개발자라면 명령어 하나를 수행하는 데 필요한 폼이라도 만드세요.

일보 전진하면 일정이라는 적군을 잡을 수 있는 가능성이 조금 올라가지만, 반대로 일보 전진하지 않으면 그만큼 적군의 저항이 세지고, 시간이 갈수록 적군의 포격은 거세지다 언젠가 내가 그 포탄에 제대로 맞아 쓰러지게 될겁니다.

일하기 정말 싫으신가요? 나중에 쓰러지기 싫으면 한발이라도 앞으로 뻗으세요! 오늘의 전진이 미래의 나를 살릴테니까요.

일정을 체크하다보면 다음과 같은 대화가 오고 갈때가 많습니다.

관리자: "OOO 기능 얼마나 했어?"
개발자: "거의 다 했어요. 한 80% 정도 한거 같아요."

하지만 개발업무는 벽돌쌓기와 다릅니다. 벽돌은 쌓는 족족 업무 진행률이 올라가지만, 개발은 코딩량이 많아진다고 해서 업무 진행률이 올라가는 것은 아닙니다. 개발에 있어 완료는 0% 아니면 100% 뿐입니다.

예를 들어, 게시판 목록을 보여주는 기능을 구현한다고 해 보죠. 개발자가 DB에 접속해서 테이블로부터 데이터를 가져오는 것 까지 기능을 구현했다고 해 봅시다. 그렇다면 이 기능은 얼마나 완성된 것일까요? 고객에게 보여줄 수 있는 건 없습니다. 만약 80~90%라는 믿음을 고객에게 준다면 고객은 곧 그 기능이 완성될 것 처럼 생각하며 대충 완성된 기능까지만이라도 보자고 덤빌 것입니다. 하지만, 보여줄 수 있는 건 없습니다. 즉, 사용자 입장에서는 0% 완성된 것이나 마찬가지입니다.

게다가 디버깅 시간까지 생각해보면 지금까지 80~90%를 만드는 데 걸린 시간만큼 나머지 10~20%의 시간이 걸릴지도 모를 일입니다. 이 경우 고객은 "곧 완성된다던 기능이 도대체 몇일이 되도록 그 상태 그대로냐?"를 연발하며 투덜댈겁니다. (개발자는 나머지 10% 기능 때문에 거짓말하는 믿지 못할 사람으로 찍히게 될지도 모르겠네요)

고객의 일정에 대한 불만과 불신을 주지 않으려면, 완성 안된 기능에 대해서 50%니 80%니 하는 등의 수치를 심어주어서는 안 됩니다. 안 된 기능에 대해서는 오직 '0%'만 심어주어야 합니다. 그래야 고객으로부터 그리고 상급자로부터 신뢰를 잃지 않을 수 있습니다.

이렇게 질문하는 분도 있을 겁니다.

"기능 하나를 구현하는데 2주일이 걸리는데 그렇다면 나는 2주일 동안 0%로 머물려야 하는겁니까? 뭔가 일을 했다는 걸 어떻게 알려줄 수 있나요?"

이런 문제가 있긴 하죠. 뭔가 계속 해 나가고 있는데 일정표에는 아무것도 하지 않는 것으로 표시될테니,, 참,, 깨림하죠. 이런 문제를 해결하기 위해서 해야 할 일이 구현할 기능을 세부작업으로 나누는 것입니다. 게시판 목록을 보여주는 기능이라면 다음과 같이 분리될 수 있겠죠.

  • DB에서 게시판 글 읽어오기
  • 결과 화면에 출력하기

따라서, 일정 표에는 이 두가지를 게시판 목록 기능에 함께 표시합니다.

 게시판 글 목록   비완성 
 상세 DB에서 게시판 글 읽어오기  완성
   결과 화면에 출력하기 비완성 

구현할 기능을 상세하게 나눠놓으면 완성/비완성 여부 뿐만 아니라 기능을 구현하기 이해 일을 하고 있다는 것도 확인시킬 수 있습니다.

괜히 일했다는 걸 알리기 위해서 80%, 90% 등의 애매한 수치를 들이대지 말고, 위와 같이 세부적으로 나눠 0% 아니면 100% 식으로 일정을 관리해보세요. 이 방식을 잘 활용한다면 적어도 고객으로부터 "거의 다 됐다던 기능이 아직도 그 모양이에요?"라는 소리는 듣지 않게 될겁니다.


[경고]
이 글은 제가 어릴 때 적은 경험과 지식을 바탕으로 썼습니다. 물론 이 글에서 말한 이유로도 객체 지향을 사용하지만 최근에는 변경/확장 비용에 더 중점을 두고 있습니다. 이에 대한 내용은 제가 쓴 '객체 지향과 디자인 패턴' 책이나 블로그의 다른 객체 지향 관련 글을 확인해 보시기 바랍니다.
- 2018-10-02

자바로 뭔가를 만들어내는 개발자들, 또는 자바를 기반으로 JSP, EJB 등의 기술을 이용해서 뭔가를 만들어내는 개발자들은 최소한 한두번쯤은 객체지향에 대한 얘기를 듣게 됩니다. 자바 기초서적은 객체지향은 캡슐화, 상속성, 다형성의 특징을 갖고 있다고 설명하며, 클래스를 이용해서 객체 지향 기법을 구현하는 방법에 대해서 설명하고 있습니다. 더 나아가 객체를 사용하는 전형적인 모습을 패턴이라는 이름으로 정형화하기도 했습니다.

이렇듯 자바하면 객체지향이 떠오를 정도로 자바는 (자바를 많이 참조한) C#과 더불어 객체 지향을 거의 완벽에 가깝게 구현하고 있는 언어라고 볼 수 있습니다. 필자는 C언어로 진행해야 할 프로젝트에서 다형성을 구현하기 위해 (다들 골치아파하는) 함수 포인터를 사용하기도 했었는데, 이와 비교하면 자바나 C#같은 객체지향 언어는 매우 쉽게 객체지향기법을 적용할 수 있도록 하고 있습니다.

객체 지향을 사용하는 여러가지 이유가 있겠지만, 저는 주로 다음과 같은 이유로 객체지향 기법을 사용합니다.

  • 재사용과 확장
  • 생각하는 방식과 설계의 일치성

너무 뻔하다구요? 하지만 이 뻔한 걸 실천해 옮기는 경우가 생각보다 많지 않다는 걸 아시는지요?


1. 재사용과 확장

재사용은 이미 절차방식의 언어에서부터 그 중요성이 강조되어 왔습니다. C 언어의 경우는 라이브러리를 만들어 배포할 수 있는 기능이 있으며, 이를 통해 개발자들은 남이 잘 만들어 놓은 라이브러리를 사용해서 보다 쉽게 프로그래밍을 할 수 있었습니다. 예를 들어, 15년 전 MS-DOS가 유행할 때에는 터보C 등에서 사용할 수 있는 한글 라이브러리가 인기가 많았으며, 많은 개발자들이 직접 한글처리 부분을 구현하지 않아도 어플리케이션에서 한글을 지원할 수 있었습니다.

객체지향의 꽃인 클래스의 재사용성은 C 언어보다 한층 강화되었습니다. 남이 만든 기능을 재사용할 수 있을 뿐만 아니라 더불어 남이 만든 기능을 확장할 수 있게 된 것이죠. 예를 들어, 전 최근에 진행한 프로젝트에서 객체-관계테이블 매핑(ORM) API로 Hibernate를 사용했었는데, Hibernate의 특정 기능 중 일부를 필요에 의해 확장해서 사용했습니다. 이를 통해 보다 빠르고 보다 프로젝트에 알맞게 Hibernate를 사용할 수 있었습니다.

비단 남이 만든 클래스뿐만 아니라 본인이 만든 클래스를 재사용할 수 있을 것입니다. 클래스를 재사용할 수 있도록 설계하고 구현하면, 나중에 반드시 적은 노력과 적은 시간으로 더 많은 걸 개발해 낼 수 있는 보상을 받게 됩니다.

2. 생각하는 방식과 코드의 일치성

아마 두번째 이유가 객체지향을 사용하는 이유중 가장 흥미로운 이유일 것입니다. 사실 재사용성은 꼭 객체지향이 아니더라도 (코드 차원에서의 재사용이든 라이브러리 형태의 재사용이든) 구현할 수 있습니다. 하지만, 생각하는 방식과 조금이나마 비슷한 구조로 코드를 구성할 수 있는 건 객체지향언어뿐입니다.

어셈블리어, 포트란, 코볼에서부터 C에 이르기까지 비객체지향 언어는 머리속에 떠오른 생각들을 언어에 그대로 매핑할 수가 없습니다. 마치 수학 문제를 풀듯, 언어에 알맞게 문제를 풀어나가야 합니다.

하지만, 객체지향 기법은 다릅니다. 머리속에서 생각하고 있던 개념들을 객체라는 걸로 매핑시킬 수가 있습니다. 머리속에서 사람, 동물, 자동차, 도시 라는 개념을 떠올렸다면 그런 개념과 매핑되는 객체(클래스)를 그려낼 수가 있습니다. 이는 설계를 좀더 빠르게 할 수 있도록 해 줍니다.

예를 들어, 인터넷 사이트의 팝업창을 생각해보죠. 인터넷 사이트에서 팝업창을 띄우기 위해서는 언제 팝업창이 떠야 하는지 관리할 필요가 있습니다. 그리고 팝업창에 무엇을 보여줄지에 대한 정보도 필요하구요. 이를 객체지향기법으로 설계를 해 본다면 다음과 같이 두개의 클래스를 가장 먼저 떠올릴 수 있겠죠.

  팝업관리자, 팝업창

이 두 클래스는 몇차례의 정련 과정이 필요하겠지만, 머리속에 생각한 걸 곧바로 설계와 연결시킬 수 있다는 건 분명히 객체지향의 큰 장점입니다. 게다가 머리속에서 상상한 걸 설계와 바로 연결시킬 수 있기에 설계가 복잡하지 않고 쉬워진다는 장점도 있습니다. (절대 쉽지 않다고 말하는 분도 계시겠지만, 패턴이니 프레임워크니 하는 등의 객체지향의 겉멋만 익히지 말고 본질을 익히시면 설계가 쉬워집니다.)

이 두가지 외에도 객체지향기법을 사용하는 여러가지 이유가 있지만 저의 경우는 이 두가지가 객체지향을 사용하는 가장 큰 이유이며, 이 두가지 때문에 설계나 개발의 속도가 빨라질 수 있기도 했습니다.

객체지향 언어를 사용할 때에는 객체지향기법을 사용할 때 비로서 빛이 난다는 걸 잊지 마세요. JSP/ASP 프로그래밍을 할 때 마치 "C 또는 베이직" 스타일로 프로그래밍 한다면, 그건 객체지향기법을 도입했을 때 얻을 수 있는 장점을 버리고 절차적 언어의 단점만 따라하겠다는 것이나 마찬가지입니다.

여러분도 자바나 C# 등과 같은 객체지향 언어를 기반으로 개발할 때에는 객체지향기법의 장점을 살릴 수 있도록 노력하다보면, 그에 상응하는 보상을 얻을 수 있게 될 것입니다.

  1. ㄱㄱ 2018.10.01 03:41

    좋은글 잘읽었습니다!

자바캔에 Hibernate에 대한 글을 올리면서 동시에 지금 다니고 있는 회사의 서비스 사이트인 www.uasis.com을 Hibernate를 기반으로 구축하고 있었습니다. 사용하는 DBMS는 오라클인데, 기존 테이블 중에는 시퀀스를 사용해서 PK를 생성하는 것도 있었고, 또는 그냥 최대값에서 1을 더한 값을 PK로 사용하는 경우도 있었습니다.

마침 Hibernate는 이 두가지 모두를 지원했고, 최대값에 1씩 증가한 값을 PK로 사용하는 테이블의 경우 Hibernate의 PK generator로 increment를 선택하였습니다. increment generator는 최대값에 1을 더한 값을 자동으로 PK 값으로 생성해주는 기능을 제공하는 것이었기에 딱 맞았다고 생각했습니다.

그런데, 운영을 하다보니 이상한 현상이 발생했습니다. 예를 들어, 테이블에 저장된 PK의 최대값은 100인데, Hibernate는 자꾸 97이라는 숫자를 PK로 생성하려드는 것이었습니다. 서버를 내렸다 올리면 다시 101부터 올바르게 생성하구요,,,

뭐가 이상할까 고민하다가 서버가 두대인 점이 떠올랐습니다. (저희 회사는 WWW를 제공하는 서버가 두대이며, L4를 사용해서 적당히 요청을 분산하고 있습니다.) 그래서 몇가지 테스트를 해 봤더니,, 이게 왠걸.. increment는 분산환경에서는 올바르게 동작하지 않는 것이었습니다. Hibernate API 문서에도 나와 있더군요. (분산환경에서 보장할 수 없다라구요..)

그래서 결국 increment generator의 소스 코드까지 보게 됐는데, 동작 방식이 초기에 한번만 최대값을 구하고 이후부터는 최초에 구한값에서 계속 1씩 증가하는 방식이었습니다. 그래서 A 서버에서 구한 최대값이 100이고, (A와는 다른 시점에 최대값을 구한) B 서버에서 구한 최대값이 105가 되는 엉뚱한 사태가 발생하고 만거죠.

그래서 결국 분산환경에서도 올바르게 동작하는 increment와 비슷한 PK generator를 만들어서 이 문제를 해결했습니다.

만약, 처음에 generator 를 사용할 때 API 문서의 '분산환경에서는 보장할 수 없다'라는 그 한줄만 읽어봤더라도 버그 때문에 불필요한 시간을 허비하진 않았을텐데 말이죠.

뭔가 남이 만든 기능을 사용한다면, 무턱대고 사용하기 보다는 먼저 문서를 자세히 한번 읽어본 뒤에 작업해야 한다는 것을 또 다시 느끼고 말았습니다. 여러분은 저처럼 뻘짓 디버깅을 하지 마세요.

+ Recent posts