개발수양록

QB로 만든 Code can be an art 출력

CCK(Creative Commons Korea)의 Code can be an art 행사에서는 '코드잼’이라는 순서가 있었습니다.

'Code can be an art’라는 문자열을 출력하는 프로그램을 자유롭게 짜서 발표하는 것이었죠.

코드잼 설명 : http://ccsalon.tistory.com/4

저도 이날 점심을 먹는 것도 잊고 나름대로 코드를 준비해 갔는데, 발표를 하지는 못했네요 . 발표자가 적은 분위기면 앞에 나가볼려고 노트북까지 들고 가기는 했었습니다 ^^; 그런데 열띤 호응으로 많은 분들이 발표를 하셨고, MSX 에뮬레이터로 하신 분 등 제가 말하고 싶었던 내용을 다른 분들이 더 훌륭히 말씀해 주셔서 큰 아쉬움은 없습니다.

8bit 화면 같은 행사 로고를 보고 저도 제 세대에 맞게 Quick Basic으로 코드를 짜볼 생각을 해봤습니다. 이 행사 중에 '8bit kid의 생애’라는 패널토론 주제도 있었었죠. ^^; 저는 그 다음 시대인 IBM XT세대입니다. 허큘리스 그래픽카드, 5.25인치 FDD, 조금 지나서 ADLIB card, 2400bps MNP 모뎀 등이 저에게는 가슴을 파고드는 핵심단어들이에요.

그 추억의 시절에 제가 가장 많아 가지고 놀았던 프로그램 언어가 Quick-Basic이였습니다. Basic에서 행번호를 없애고 구조화프로그래밍 개념을 도입한, 당시 저에게는 충격적으로 대단한 언어였어요. 이 도구에다 basic을 배웠던 사람이면 누구나 회상할 추억의 명령어 line(선긋기), play(음악연주), read,data(데이터 읽는 구문)을 넣어서 코딩을 해봐야겠다고 마음 먹었습니다. 대신 제 PC환경상 그때의 Quick-basic 대신 Window XP에 내장되어 있는 q-basic을 사용할 수 밖에 없었어요. 프롬프트에서 qbasic이라고 치면 언제나 튀어나오는 도구죠.

Quick-Basic과 q-basic이 뭐가 다르냐구요? 문법은 거의 똑같은것 같아요. Quick-basic은 따로 패키지로 나와서 버전4.5까지 발표되었었는데, q-basic은 어느 새 MS-DOS의 상위버전에 포함되어서 나오더군요 . Quick-Basic에서는 실행파일(.exe)도 만들 수 있고, 각종 라이브러리도 많았었습니다. 아뭏든 대타로 q-basic을 썼기에 실행할때는 아래와 같이 치면 됩니다.

프롬프트> qbasic/run cba2.bas

단순히 화면에 큰 글자를 찍어주는 것 밖에 없지만, 꽤나 시행착오 작업을 많이 거쳤었습니다. 예전 Quick-Basic에서는 screen 12라는 화면모드를 주로 썼었었는데, 이번 환경에서는 screen 2 밖에 안 먹는 것이였습니다. 화면 전체 해상도가 몇곱하기 몇 인지도 모르고 그냥 무작정 네모를 그리는 숫자값을 바꿔가면서 화면을 만들어 봤습니다. 결국 한참 후에야 그럭저럭 화면중간에 크게 들어간 글자를 얻어낼 수가 있었죠. 평소에 일할 때 이렇게 무식하게 작업을 한다면 스스로 한심하게 느껴졌겠지만 이번에는 그것조차도 옛 추억을 되살리는 즐거움이였습니다.

그리고 이 프로그램에 들어간 멜로디를 아시는 분이라면 아마 저하고 비슷한 컴퓨터 세대이실 것 같아요. 불후의 고전명작게임 'Loom’의 메인테마 입니다. 처음에 노트북을 들고 행사장에 갈때까지만 해도 프로그램에서는 단순히 '도미솔' 정도의 소리만 났었습니다. 그러다가 행사가 끝난 다음 주에 문득 여기에다 듣기좋은 멜로디를 넣어보고 싶다는 충동을 느꼈고, 그때 게임 'Loom’의 음악이 머리 속에 떠올랐습니다. 당연히 악보 같은 건 없었고 기억하는 멜로디를 스스로 휘파람으로 불어서 청음으로 코드를 만들었습니다. 남다른 음감각을 가진 것도 아니어서 계속 시행착오를 거치면서 play문에 들어가는 음표코드를 넣었죠. 어쩐지 박자와 음이 약간 어설프고 불안정한 느낌이 들지 않나요?

행사 때 김국헌님께서 발표하시는 분들마다 물어보셨던 말이 있었습니다. '이 작업을 하시면서 즐거웠습니까?'' 저도 여기에 그때 다른 분들이 하셨던 말과 똑같이 '네. 굉장히 즐거웠습니다’라고 말할 수 밖에 없네요. 한 때는 왠만한 단축키는 다 외웠었던 Quick-Basic이였는데 오랜만에 쓸려니 함수 선언방법 조차도 가물가물 하더군요. 그래도 기억을 되살려 가면서 작업을 하다보니 이런 도구로 고등학교 때 축제 전시회 때 내놓을 게임을 만들던 일이 생각이 났었습니다. 그 때 정말 밥 먹는 시간도 잊어 버릴 정도로 매달려서 어설픈 게임을 만들었고, 어쩌면, 아니 확실히 그런 기억들 때문에 지금도 컴퓨터 코드를 짜는 일을 하고 있다는 사실도 새삼스럽게 떠올랐습니다.

뭐 어떤 분들은 이 글을 보시면, 몇줄 안되고 실행결과도 허접한 프로그램 짜놓고 제목은 아트니 뭐니 되어 있고 되게 거창한 척을 한다고 느끼실 것 같습니다. 하지만 누가 뭐래든 이 코드를 짜던 순간, 그리고 Quick-Basic이 어떤거니 하는 , 요즘은 별 정보도 되지 않을 이런 글을 주절주절 쓰고 있는 이 순간까지도 행복감의 여운을 느낍니다.

다 해놓고 보니 코드는 그리 길지는 않네요~

DECLARE SUB display (c$, p$)

SCREEN 2
lg$ = " Code can be an art! "
DATA "t90O1p4","e8","a8","b8",">c+8","g8","f8","<a8"
DATA ">d8","c+8","<e2","e8","a4","b8",">c+4","<b8","a2","e2","p4","p4","p4","p4"
FOR i = 1 TO LEN(lg$)
    READ p$
    display MID$(lg$, i, 1), p$
NEXT i
SCREEN 0
END

SUB display (c$, p$)
PLAY p$
CLS
PRINT c$
FOR i = 0 TO 10
  FOR j = 0 TO 10
    IF POINT(j, i) THEN LINE (j * 60 + 80, i * 25 + 10)-(j * 60 + 140, i * 25 + 40), 1, BF
  NEXT j
NEXT i
LOCATE 1, 1
PRINT " "

END SUB

다른분들의 발표작

방명록

블로그 방명록이에요. 댓글로 달아주세요

더골(THE GOAL)

image

(이미지는 yes24에서)

더 골(The Goal) , 제프 콕스 저, 김일운 역, 동양문고

회사 소모임의 워크샵에서 이 책을 주제로 한 발표가 있었습니다. 그 때 생각난 내용을 나중에 회사 커뮤니티 게시판에 적었는데, 그 내용의 일부를 옮겨써 봅니다.

저의 사촌형이 이 책을 낸 출판사에 일하고 있어서, 저는 책을 공짜로 받았었습니다. 몇년전 제가 그 형 집에 놀러 갔을때 이책을 아마 제가 꼭 읽어야 할 것이라면서 그냥 저에게 주는 것이였습니다. 대충 넘겨보면서 내용을 훑어보니 공장에 대한 이야기라서 서비스업에 종사하는 저로써는 별 상관없는 내용으로만 보였습니다. 그래서 한동안 책장에 꽂아만 두고 있었죠. 책을 받고 한참 뒤에서야 잡지나 블로그 등을 통해 개발자가 읽을 책으로 이 책을 권하는 사람이 많은 것을 알게 되었고, 다시 찾아서 읽게 되었습니다.

소설의 내용은 공장장이 문제의 공장을 해결해 나가는 이야기입니다. 그 문제의 공장이 잘 돌아가지 않았던 것은 각각의 공정의 부분적인 생산성에만 작업자의 목표가 맞춰져 있었기 때문이라고 정리하고 싶습니다. "부분적인 최적화는 전체 최적화를 보장하지 않는다"는 말도 학교 다닐때 들었는데, 그 예가 이 소설 내용에 있는 것 같네요.

공장에서는 자동로봇을 도입하고 이를 자랑꺼리로 여겼는데, 그 로봇은 많은 부품을 찍어냈지만, 그 부품은 결국 재고만 더 쌓이게 만들어서 오히려 공장에 손해만 끼치는 결과를 낳았다는 내용이 있습니다. 그 로봇이 있는 공정에서는 부품의 생산양만 보고 높은 성과를 이루고 있다고 생각했겠죠.

모두들 열심히 일하고 로봇도 쉬지 않고 있는 공장이 고객이 주문하는 생산량을 못 맞추자 공장장은 대학 때 교수로 부터 자문을 받아서 이를 해결해 나가기 시작합니다. 그 방법들은

  1. 병목이 일어나는 공정에 대해서 외주를 주거나 동원가능한 다른 기계를 이용해서 지원작업을 한다.

  2. 우선 순위가 급한 부품을 다른 표시를 해서 그 부품이 해당 공정에 들어왔을때는 가장 먼저 작업을 하도록 한다.

등입니다. 위에 로봇의 경우와는 반대로 최적화된 한번의 작업량 (예를 들면 붕어빵틀에 모든 구멍에 밀가루를 채우는 것 같이 해당공정의 효율이 극대화 되는 한번의 양)을 포기했을 때 오히려 공장의 전체 생산성이 더 좋아지는 예도 책에 나옵니다. 그리고 "재고는 자산이 아닌 비용이다"라는 개념도 기존 통념을 뒤엎는 것이였죠.

전에 이 책을 다 읽고나서도 "그래도 나와는 큰 관련 없는 공장이야기군"하고 생각을 했었는데, 최근에 들어서야 IT업과 연관성을 생각해보게 되었습니다.

개발 프로젝트를 하면서 제가 경험한 일정관리는 프로그램의 목록을 엑셀시트나 이슈 트래커에다 나열해 놓고 그중에 몇개를 완성했느냐, 그것이 전체의 몇%냐로 평가를 받는 것이였습니다. 그 갯수가 적으면 다른 사람보다 생산성이 적은 것이 되고, 계획했던 갯수보다 적으면 일정을 못 맞춘것이 되는것이였습니다. 여기서 개발자가 충족해야할 목표는 그 갯수를 늘이는 것인데, 그러다보니 쉬운 프로그램, 고객이 별로 신경쓰지 않는 프로그램을 먼저 구현을 하게 되는 경향이 생기기 쉬워집니다. 그러다보면 오히려 정말 많이쓰이고, 고객이 민감해 하는 프로그램들은 나중에 급하게 졸속으로 구현되는 경우를 봐왔습니다. 이는 개발자가 평가받는 부분적인 목표(프로그램 갯수)와 프로젝트 성공의 목표(고객의 필요한 프로그램이 잘 돌아가서 검수를 받는것)이 상충되는것이 아닐까 합니다. 익스트림 프로그래밍 서적에서도 비슷한 이야기를 본것 같네요. 고객이 가장 우선시 하는것부터 먼저 구현을 하고 고객에게 피드백을 받고 다음 스토리로 넘어가야한다는 내용이였던것 같습니다.

그리고 프로젝트에서 "고객검토"가 병목인 경우가 많다는 생각도 듭니다. 한참동안 피드백이 없다가 프로젝트 종료시점에서야 요구사항을 쏟아내는 고객의 경험을 다른 분들도 겪었을것 같습니다. 병목을 보강하듯이 업무별 고객담당자를 적절히 분할해서 지정하거나, 개발팀 쪽에서도 고객검토을 촉진시킬수 있는 담당자를 두거나 하는 해결방안등이 생각이 납니다.

이 책이 공장의 이야기인데도 개발자들사이에 많이 권해지는 이유를 연결시켜서 생각해봤습니다. 그 외에도 연관시킬만한 것이 있는지 궁금합니다.