로또생성기 java로 만들어보기

정상혁정상혁

javaservice.net에서 보고 저도 한번 짜봤어요.

( 원글: http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=qna2&c=r_p&n=1196139164&p=3&s=t#1196139164 )

문제

  • 1부터 45까지의 숫자 중에 6개를 뽑는다.6개의 값이 다 달라야 한다.

  • java.util.Random를 이용해서 임의의 값을 구한다.

  • 출력시 작은 숫자부터 순서대로 출력

저의 풀이

간단하게 짠다면 일단 저는 아래와 같이 해보고 싶어요.

import java.util.Random;
import java.util.SortedSet;
import java.util.TreeSet;
public class LottoMachine1 {
    public static void main(String[] args) {
        SortedSet<Integer> pickedNumbers = new TreeSet<>();
        Random random = new Random();
        while(pickedNumbers.size()< 6) pickedNumbers.add(random.nextInt(45)+1);
        System.out.println(pickedNumbers);
    }
}

무엇인가를 만들고 싶다는 것

정상혁정상혁

마이크로소프트웨어지 2007년 11월호의 특집기사는 '개발고수 7인의 천기누설, 슈퍼개발자로 가는 길’이였습니다. 왠지 얄팍해 보이는 제목이 마음에 들지 않았고, 내용을 읽기 전까지는 이제 이 잡지도 소재가 고갈되었나 하는 생각까지도 들었습니다. 그러나 거기에 포함된 델파이 고수 양병규님의 기사는 충격적일 정도로 감명을 주는 내용이였습니다.

그 기사에서는 양병규님이 PC원격제어 프로그램을 혼자서 2개월만에 개발한 이야기가 나옵니다. 양병규님은 다른 PC원격 제어 프로그램을 처음 보는 순간부터 그런 프로그램을 직접 만들어보고 싶은 마음이 들었고, 그후로 부터 실제 개발을 시작한 시기 사이의 2년동안 틈틈히 아이디어를 생각하고 메모를 했다고 합니다. 화면 캡쳐, 이미지 압축, 소켓 전송 등 프로그램에 필요한 구체적인 것까지 다 미리 생각해 둔 덕분에 실제 개발기간인 2개월동안에는 코딩만 하니 끝이였다고 하네요. 대단하지 않습니까? 아래는 그 기사에서 인용한 내용입니다.

이런 방법으로 작은 수첩하나를 가슴에 품고 자신의 생각들을 차곡차곡 쌓아가다 보면, 방금 산 복권을 양복 주머니에 넣고 희망찬 모습으로 걸어가는 모습의 복권 포스터 주인공 못지 않게 희망찬 하루하루를 살 수 있을 것이다.

델마당 양병규 님의 40대 초보 프로그래머에 대한 답변 글에 있는 양병규님의 첫 프로그램 이야기도 감동적입니다. 저의 부모님께서도 예전에 어렵게 생활하셨던 분들이라, 어른들의 젊었을 적에 고생한 사연은 어릴 때부터 하도 많이 들어왔기에 왠만한 이야기들은 저는 무덤덤하게 느껴집니다. 하지만 그런 저도 양병규님의 이야기를 읽은 뒤에는 저절로 고개가 숙여집니다.

위의 글들을 다 보고나니, 제가 프로그램 개발을 하게 된 이유를 한동안 잊어먹고 있었다는 것을 깨달았습니다. 뭔가를 만들어보고 싶다는 것. 그 과정의 즐거움, 결과가 주는 뿌듯함, 혹시나 그것이 다른 사람에게 도움이 될 수 있을까 하는 기대감.. 그런 것들이였습니다. 다른 많은 분들도 마찬가지 일 것입니다.

그것을 잊고 살다 보니 만들어보고 싶은 것이 생각나도 '시간나면 해봐야지’하는 마음으로 흘려보낸 시간들이 많았습니다. 앞으로는 자주 안 잊어먹도록 여기에도 적어놓습니다 ^^

제 꿈은 아래에 나오신 분들 같은 '발명 할아버지’가 되는 것입니다.

(간혹 방송이나 인터넷에서 몇 분을 보기는 했는데 찾아보니 이런 할아버지들 꽤 많군요)

2050년쯤 '발명 할아버지’로 검색했을 때 어느 시골의 마을신문에서 낸 기사로 '집념의 발명 할아버지 정상혁’과 비슷한 제목이 뜬다면 제가 꿈을 이뤘다고 보셔도 됩니다. 혹시나 그 기사에 '그러나 만든 것 중 쓸모있다고 인정받은 것은 하나도 없음', '주변에서 계속 뜯어 말리고 있으나 소용없음','가족들은 갈수록 헛소리가 심해진다고 걱정이 많음’과 같은 내용이 포함된다고 해도 말이죠.

Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

정상혁정상혁

momo/TopCate57/MidCate09/5683498.jpg

마이크로소프트웨어지에 '커뮤니티 노트’라는 컬럼을 연재하고 계신 최재훈님이 번역하신 책입니다. 사실 처음 책의 목차만을 보았을 때는 '실용주의 프로그래머’와 겹치는 내용이 많을 것 같아서 큰 기대를 하지는 않고 읽기 시작했었습니다. 아마 제가 블로그를 통해서 이 책을 알지 못하고 서점에서 우연찮게 만났다면 책을 안 사고 지나쳤을 법도 합니다. 그런데 다 읽고나니 다음에 프로젝트 시작할 때는 사비로라도 이 책을 사서 프로젝트 팀원들에게 돌리고 싶다는 생각이 들더군요.

이 책에서는 프로젝트를 성공적으로 이끄는 해결책으로 다음의 방법들을 제시하고 있습니다.

  • 소스코드 버전관리 프로그램을 이용해라.

  • 테스트 자동화를 해라.

  • 프로젝트 첫날 빌드스크립트를 작성해서 자동화하고, 지속적으로 통합, 빌드, 테스트를 해라.

  • 일일회의로 개발자들간의 의사소통을 활발히 해라

  • 상호 코드 검토를 해라.

아마 이미 식상한 이야기라고 느끼실 분도 많을 것 같네요. 저도 요약한 것만 봤다면 그렇게 느꼈을 것 같습니다. 그러나 이 책의 조언들은 현장감이 넘칩니다. 상세한 행동 방법들과 잘 되어 가고 있는지 확인할 수 있는 검토사항들을 알려주고 있습니다. 부록으로 책에서 말한 지침을 실천하는데 도움이 되는 테스트 프레임웍 같은 도구들의 URL을 모아서 정리해주는 친절함도 있습니다.

요즘과 같이 지식이 잘 전파되는 환경에서 위의 조언들을 모르고 있는 개발조직은 거의 없을 것입니다. '외국에서나 통하지 우리나라 현실에 안 맞는 방법이다. ' , '실무를 모르고 책상에 앉아서 만든 이야기일 것이다', '내가 프로젝트를 많이 해봐서 아는데 다 이상적인 내용일 뿐이다.' 등의 생각으로 적용을 안하고 경우도 많습니다. 또는 당장 급하게 돌아가게 있는 프로젝트에서 변화를 주는 것은 위험하다고 판단하기도 하겠죠.

저도 그런 경험들을 거쳐왔었습니다. 몇년전에 제가 경험했던 프로젝트에서는 본사차원에서 버전관리 프로그램(PVCS Merant version manager)를 쓰도록 표준이 정해졌었고, 그 프로그램에 대한 설치, 개발자와 고객에게 같이 교육까지도 지원되었습니다. 당시에 저도 버전관리 프로그램이 좋다는 말은 책에서 들어서 알고 있었지만, 막상 쓸려고 하니 괜히 소스관리에 시간만 더 들이게 되는 것이 아닌가 하는 생각이 들더군요. 그리고 PVCS에 check in 한 다음에도 취합, 컴파일, 파일업로드는 한 개발자의 PC에서 이루어 졌기 때문에 실제로 버전관리는 해봤자 백업의 의미밖에 없었습니다. 소스의 최종버전은 결국 개발자들의 각자의 PC에 저장되어 있었고, 버전관리는 프로젝트 기간동안 한 두번 정도 한꺼번에 파일을 올리는 식으로 형식적으로 하고 넘어갔습니다. 파일서버에 각 개발자들이 그날 작업한 것을 폴더 형식을 맞춰서 올리면 한 명이 개인PC로 복사, eclipse로 컴파일, 알ftp로 업로드하는 일을 했는데, 한번에 30~40분은 걸리는 작업을 거의 매일 했었던 것으로 기억합니다. 통합,컴파일, 업로드까지 한꺼번에 해주는 빌드스크립트를 작성하면 좋겠다는 생각도 있었지만, 당장 매일매일 오늘은 프로그램 몇개 짰다고 엑셀파일에 체크를 안 하면 죄인이 되는 것 같은 프로젝트 분위기에 잠깐 다른 일을 할 엄두가 안 나더군요.

다음에 이어진 프로젝트는 연속사업이였기 때문에 운영서버에서 돌아가는 소스와 새로 개발되는 소스가 복잡하게 꼬일 위험이 있었습니다. 그 때부터는 버전관리의 필요성을 팀원 모두가 어느정도 인식하기 시작했었습니다. 그래서 빌드 스크립트를 작성하는데 시간을 쓸 수가 있고, 컴파일, 새로 바뀐 파일만 복사, 소스업로드, 서버 리부팅, 로그 남기기의 작업을 한번에 해주는 ant build script를 작성했습니다. 빌드 스크립트를 윈도우 스케쥴러에 걸어서 하루에 두 번 돌리고 로그만 아침에 출근해서 한번, 점심 먹고 한번 확인해주고 에러난 것 있으면 개발자에게 통보해 주는 절차를 거쳤습니다. 당시의 제 지식의 한계로 크루즈컨트롤 같은 툴을 활용해서 완벽한 CI를 해보는 수준까지 생각 못한 것이 아쉽기는 합니다. 그래도 그 수준이라도 만들고 나니 전에 프로젝트에서 했던 원시적인 작업방식들은 이제 다시는 불편해서 못할 것만 같았습니다.

개발자들의 버전관리 프로그램을 통해서만 소스를 수정한다는 것을 고객이 인식을 하고 나니, 몇몇 고객들은 자신의 PC에 버전관리 프로그램을 설치해 달라고 요구하기 시작했습니다. 그리고 간단한 글자수정 정도는 스스로 하는 고객도 나왔습니다. 비록 <font> 태그로 제가 별로 맘에 안 드는 색깔로 도배를 해서 찜찜해진 페이지도 있었지만, 그래도 고객에 취향에 맞는 결과를 제가 손대지 않고 얻었으니 만족해야겠죠.

지금 돌아보면 이슈관리를 위한 Tracker도 적극적으로 사용했어야 하는데 하는 생각이 듭니다. 연속사업의 첫번째 프로젝트에서는 Tracker도 본사에서 교육지원을 나온 인력이 고객과 개발팀 모두에게 사용법을 강의해 줬으나, 거의 활용되지 못했습니다. 두번째 프로젝트에서는 개발팀내에서만 진도관리 정도만을 체크하는 수준에서 Tracker를 사용했었습니다. 그때는 '어짜피 고객이 안 쓰니까 우리만 쓰는 용도로 쓸 수 밖에 없다’라고 생각했었는데, Version Manager처럼 적극적으로 우리가 쓰서 고객을 끌어들일 시도조차 하지 않고서 너무 쉽게 단정을 내렸었습니다.

프로젝트가 끝난 뒤에 특정 방식이 얼마나 생산성을 향상시켰는지 객관적으로 비교하는 것은 어렵습니다. 프로젝트는 정해진 시간에 딱 한번 하는 것이기 때문에 '조건을 통제한 반복실험’이 불가능하기 때문입니다. 마음이 받아들이지 못하는 방식이라면 설령 그 프로젝트가 무사히 끝났어도 '그것만 없었으면 더 프로젝트를 편하게 했을텐데’라고 생각할 것이고, 믿고 있는 방식이라면 지연된 프로젝트라도 '그래도 그거 썼으니깐 이정도로 끝낼 수 있었지.'라고 여길 수도 있습니다.

그리고 새로운 방식의 적용은 사람의 습관을 바꾸는 일입니다. 누구나 몸에 익은 편한 방식이 있고 그 방식으로도 큰 실패는 없을 것이라고 믿고 있습니다. 더 나아진다는 확실한 증거가 없는데도 기존의 방식을 흔쾌히 바꿀 사람은 흔치 않을 것입니다. 그렇게 공감을 얻는 방식을 같이 찾아간다는 것이 쉽지 않은 일임에도 프로젝트에서 그것을 위한 소통의 노력들은 부족할 때가 많습니다.

저의 경험처럼 아무리 위에서 프로세스를 정해주고 지원을 해줘도 그것을 수행할 사람들이 그 필요성에 대해서 공감하지 못한다면 어떤 좋은 도구나 방법론들도 다 형식적인 것에 그치게 되고, 오히려 프로젝트 진행의 발목을 잡는 짐이 되기도 합니다. 어쩌면 가장 좋은 도구나 방법론은 위에서 똑똑한 사람들이 칼같이 정해준 것이 아닌, 팀원 중 다수가 그것이 좋다고 믿음을 가지고 있고, 그 방식의 전도사가 될 준비가 되어있는 것들일 것입니다. 그 믿음을 공유하고 있다면 팀원들은 그것을 증명하기 위해서 더욱 그 방법을 쓰는 작업에 몰입을 하고 정성을 다할 것이고, 공감하지 못한 상태라면 '거봐~ 그거 내가 안 될거라고 했잖아~' 라는 말을 언제라도 하고 싶어서 마음에 품고 다닐 것입니다.

몇년 전의 그 정신없던 프로젝트를 마치고 나서 가장 크게 들었던 후회했던 점은 '왜 그때 더 좋은 방법을 찾아볼 노력을 더 안 해봤고, 찾은 것을 알릴려고 애쓰지 않았을까?' 라는 것이였습니다. 빡빡한 일정은 사람의 시야를 좁게 만들어서 당장 오늘,내일을 위한 임시 방편들만을 양산했고, 결국에는 그것이 더 돌아가는 길이라는 것도 깨닳을 수도 없었습니다. 프로젝트 초기에 전체 개발팀 회의만 몇번 더 하고 코드리뷰만 몇번 했더라면 그 약간의 시간이 그냥 앉아서 코딩하는 시간의 몇배가 가치가 있었다는 것을 확신하지 못했고, 그렇게 투자하지 못했습니다.

이 책에서 제가 가장 감명 깊게 읽은 내용은 다음 부분이였습니다.

최고의 아키텍처는 상아탑의 '아키텍트’에게서 나오지 않습니다. 공동의 노력을 기울여야 최고의 아키텍처가 나옵니다. 전문가 한 명이 독주해서 완성한 아키텍처 문서를 여러분 앞에 던져 놓고 가게 하지 말고, 팀이 함께 일해서 모든 이의 경험을 발휘하고 쌓아나가도록 하세요.

지난 7월7일, P-camp라는 행사에 참가했을 때, 저는 'http://benelog.springnote.com/pages/349170[함께하는 개발표준 만들어 가기]'라는 글을 썼던 적이 있습니다. 프로젝트 후에 가장 절실하게 느꼈던 점을 정리했던 것인데, 비슷한 이야기를 이 책에서 보니 당연히 반가웠습니다.

책을 읽다보니 계속 '다음 프로젝트에서는 이런이런 일을 하고, 이런 말을 사람들에게 해야지..' 하는 상상과 기대를 해보게 되었습니다. 힘들고 황폐한 프로젝트라도 조금이나마 불행을 덜어줄 수 있는 일을 제가 할 수 있었으면 하는 꿈이 다시 불어넣어졌습니다. 앞으로의 현실이 어떨지는 몰라도, 이책을 보면 '그래, 이제 제대로 해보는 거야.'라는 말이 이 책의 요약으로 머리속에 떠오를 것 같습니다.

책에 첫장에는 다음과 같은 명언이 인용되고 있습니다.

현재의 우리는 반복적으로 하는 행동의 결과이다. 그러므로 탁월함이란 행동이 아니라 습관이다. -아리스토텔레스

저는 개발자들이 가질 수 있는 탁월한 습관은 '더 나은 방법이 있다는 것을 믿고, 찾고, 나누는 습관’이라고 생각합니다.