Programming is Fun

.NET환경에서 MongoDb 사용 tutorial

xyzlast Y2K — Wed, 02 Nov 2011 13:32:12 +0900

개인적 관심사로 NoSQL중 RDBMS와 가장 유사하기도 하고, 중대용량에 적합하다고 하는 mongodb를 좀 건드려봤다.
http://mongodb.org 에서 BSON driver를 다운 받고, driver를 이용하면 매우 쉽게 mongodb를 handling할 수 있다.

간단한 test code들은 다음과 같다.

[TestFixture]
public class MongoDbTest
{
    [Test]
    public void CreateSchema()
    {
        string connectionString = "mongodb://localhost";
        //서버 접속
        MongoServer server = MongoServer.Create(connectionString);

        //Database 이름 설정
        var dbSetting = server.CreateDatabaseSettings("mongoDbTest2");
        dbSetting.Credentials = new MongoCredentials("ykyoon", "newPassword");
        var db = server.GetDatabase(dbSetting);

        Assert.That(db != null);

        //Create Table
        db.CreateCollection("NewCollection");
        var collection = db.GetCollection("NewCollection");
    }

    [Test]
    public void InsertTest()
    {
        string connectionString = "mongodb://localhost";
        MongoServer server = MongoServer.Create(connectionString);

        var data01 = new BsonDocument();
        data01.Add("author", "ykyoon");
        data01.Add("name", "first bsonDocument");

        //var dbSetting = server.CreateDatabaseSettings("mongoDbTest");
        //var dbNames = server.GetDatabaseNames();

        var db = server.GetDatabase("mongoDbTest");
        //db.CreateCollection("Users");

        var userCollection = db.GetCollection("Users");
        userCollection.Insert(data01);

        Assert.That(server.DatabaseExists("mongoDbTest"));
    }

    [Test]
    public void SelectTest()
    {
        var connectionString = "mongodb://localhost";
        MongoServer server = MongoServer.Create(connectionString);
        var db = server.GetDatabase("mongoDbTest");

        var userCollection = db.GetCollection("Users");
        var qq = Query.EQ("author", "ykyoon");

        var users = userCollection.Find(qq);
        foreach(var user in users)
        {
            Console.WriteLine(user);
        }
    }
}

프로그래머로서의 자신이 작두를 타고 있다고 느낄때..

xyzlast Y2K — Tue, 07 Jun 2011 23:16:38 +0900

이 글은 컴퓨터 프로그래밍을 이미 자기 삶의 중요한 일부분으로 받아들였지만 잠시 주춤하고 있는 사람들과 프로그래머의 길 앞에서 그렇게 될 것인가 말 것인가 고민하고 있는 사람들에게 '삶의 과정으로서의 프로그래밍'이라는 관점을 갖고 작성했다. 이를 통해 프로그래밍하는 인간의 모습을 돌아보고 프로그래머로서의 인간 에너지를 충전시키는 시간을 제공하고 싶다.

이만용 (리눅스코리아 CTO ) 2001/04/13

필자는 이 글을 통해 지난 3-4 년간 프로그래머가 되고 싶어했던 사람들, 이미 직업으로서 프로그래밍을 하고 있다. 현재보다 더 나은 프로그래머가 되길 원했던 사람들이 필자에게 보낸 메일에 대한 답장 속에서 했던 이야기. 그리고 하고는 싶었지만 답장 메일로 적기에는 너무 길어 적지 못했던 마음속의 말들을 꺼내어 정리하는 시간을 갖게 되었다. 종종 일상의 지겨운 반복 속에서 좌표를 잃지 않기 위해 컴퓨터 앞을 떠나 편안하게 사색에 잠길 수 있기를 바라며 이야기를 시작한다.

원래 창조적인 지적 유희이며 그러해야 한다
필자에게 왜 프로그래밍을 하고 있냐고 묻는다면, 주저없이 '재미(fun)'라고 답할 것이다. 한 가지 덧붙이자면, 만약 프로그래밍보다 더 재미있는 일이 있다고 생각한다면, 역시 주저함 없이 프로그래밍 대신 그 일에 몰두할 것이다. 재미없는 일을 억지로 하면서 보내기에는 인생은 너무 짧지 않은가. 여러분이 이미 생계의 족쇄 속에 또는 사회적 위치 속에 결박당해 탈출할 수 없는 경우가 아니라면, 그리고 충분히 새로운 선택을 하여 재시도할 수 있는 사람이라면, 다시 한 번 진정으로 자신이 프로그래밍을 즐기고 있는지 생각해 보는 시간을 갖기 바란다. 꼭 프로그래밍을 해야 하는 절대절명의 이유란 없다. 앞으로 전개될 글을 읽기 전에 마음의 고리를 풀고 편안한 마음으로 자신의 사고가 흐르는 대로 방치하기 바란다.

꼭 프로그래밍만이 재미있다고 말할 수는 없지 않겠는가. 당연히 재미라고 하는 것이 인간의 다른 모든 행위로부터 프로그래밍을 구별해 주는 유일한 요소일 수는 없다. 이 세상에는 프로그래밍 이외에도 이미 사람이 재미를 느낄 수 있도록 해 주는 일이 헤아릴 수 없을 정도로 많듯이 말이다. 예전에도 그리고 지금도 수억의 인구가 회화, 악기 연주, 운동 등에서 즐거움을 느끼고 있다. 이 활동들은 새로울 것도 없지만, 여전히 재미있는 활동이다. 프로그래밍도 시간이 지남에 따라 훨씬 더 대중화하고 똑 같은 취급을 받을 것이다. 하지만 프로그래밍이 똑같이 재미있는 수많은 일 중 그냥 하나라고 말하기에는 너무 극단적이다. 어떤 점에서 프로그래밍이 주는 재미가 다른 재미와 같고 또한 다른 것일까.

프로그래밍은 이미 오랜 시간 동안 인간의 역사 속에서 사람들에게 재미를 제공했던 기존 활동과는 도구적 관점에서 다르다. 여기서 컴퓨터라고 하는 20 세기의 놀라운 발명품을 이야기하지 않을 수 없을 것이다. 책, 기관차, 전화와 같은 출판 기술, 증기 기관, 통신 기술이 인간 세상을 변화시킨 것처럼 컴퓨터가 현재의 인간 생활을 변화시켰다는 점을 부인할 사람은 없다.

인간은 그 동안 자신이 발견하거나 발명한 것을 즐기며, 도구를 통해 자신을 다시 변화시켜 왔다. 프로그래밍은 컴퓨터라고 하는 도구를 통해 그 안에서 인간의 상상력과 논리적 사고력을 실현해 내는 고급 유희다. 그러나 바로 이전 문장에서 표현했듯이, 인간이 지적 노력을 쏟아 지적인 재미를 만들어 내려고 하는 지적 유희라는 점에서는 그 이전의 모든 창조적 지적 유희와 하나도 다르지 않다. 여기서 필자는 다르다는 점보다 같다는 점을 강조하고 싶다.

채 다 배우기도 전에 쏟아져 나오는 프로그래밍 언어, 선택해 보지 못한 메뉴가 아직도 많은데 버전업돼 나오는 통합 개발 환경에 치여 살다 보니, 프로그래머인 우리 자신이 인간이 최근 만든 가장 놀라운 발명품을 사용해 가장 재미있는 창조적 지적 활동을 하고 있다는 사실을 너무도 쉽게 잊어버리는 모습을 목격할 수 있다. 그리고 현실 속에서는 이러저러한 언어, 도구에 지배받으며 지쳐 있는 불쌍한 자신을 쉽게 발견한다.

하지만 그 어떤 컴퓨터를 사용하든, 그 어떤 프로그래밍 언어나 도구를 사용하든 우리 프로그래머들이 본질적으로는 참 재미있는 일을 하고 있다는 사실을 망각하지 말아야 한다고 말하고 싶다. 그것도 매우 지적인 재미 말이다.

그러한 자기 만족감이 없이 버틸 수 있는 프로그래머가 있을까. 프로그래밍 언어책을 보다 며칠씩 이해되지 않던 부분이 갑자기 슬슬 풀려 나갈 때, 작지만 자기가 예상한 대로 모든 일이 척척 진행돼 나갈 때, 하루 종일 찾지 못했던 버그를 커피 마시다 갑자기 찾아냈을 때 느끼는 자신에 대한 대견스러움, 만족감을 느껴보지 않고 어떻게 프로그래머라고 말할 수 있을까. 이런 즐거움은 이성 친구, 애인, 가장 가까운 친구에게도 어떤 말로도 전달할 수 없는 매우 개인적인 차원인 것이다. 때로는 자신의 소스 코드와 프로그램을 이해하는 지구 반대편의 프로그래머와 더 진한 동질감을 느끼기도 하는 것 또한 프로그래머다.

자신에 대해 대견스러워하는 마음, 무엇보다 자신이 설계한 대로 컴퓨터가 작동하는 것을 보는 즐거움, 컴퓨터를 통해 자기만의 세계가 창조되는 즐거움을 느끼지 못한다면 앞으로 하는 모든 이야기는 별 의미가 없다. 취미로든 직업으로든 왜 프로그래밍을 선택했는지 그리고 왜 수많은 책과 읽을거리와 투쟁하고 있는지 자기 확신을 갖자. 아무리 생각해 봐도 프로그래밍은(유일하지는 않아도) 꽤 매력적인 고급 활동이다. 재미있는 일을 재미있게 하지 못한다면 그것은 큰 문제가 아닐 수 없다.

프로그래밍의 본래 의미를 찾는다
대학생 친구들을 위한 언어 교재를 만들면서 자주 등장하는 외래어 표현을 정리하고 있었다. 그런데 바로 프로그램(program)이라는 말 그 자체가 우리에게 시사하는 바가 많다는 사실을 발견했을 때 마치 보물을 발견한 양 즐거워 한 적이 있다.

'program'이라는 단어는 'pro'와 'gram'의 합성어다. 여기서 'pro' 는 '어떤 일을 하기 전에...' 라는 'before' 의 의미를 갖고 있으며 'gram'은 '무엇인가를 쓰다' 즉 'write'의 의미를 갖고 있다. 따라서 program은 쓰거나 만드는 행위라기보다 '쓰기 전에 하는 일' 즉 계획적인 사고 행위를 가리킨다.

현실적으로 우리가 우리 자신을 설계자나 기획자라고 생각할 수 있는 여유는 거의 없는 것 같다. 우리가 매일 확인할 수 있는 자신의 모습은 특정 언어나 특정 제품, 특정 프로젝트의 노예로 전락해 있는 초라한 모습이지 않은가. 프로그래밍은 어느 새 밤을 세며 코딩하는 중노동과 동일시돼 버렸다. 그래서인지 요즘 미국이나 한국 젊은이를 대상으로 한 설문조사를 보면 그래픽 디자이너가 되고 싶다는 답변이 프로그래머가 되고 싶다는 답변보다 월등히 많다고 한다. 이미 프로그래머란 컴퓨터 분야 중 가장 선호하는 직업이 아닌 것이다.

프로그래밍 작업의 특성이 무엇을 이뤄내기 전에 먼저 머리 속에서 설계하는 정신적 유희라는 본질적인 의미를 자꾸만 잊게 하는 그 무엇을 갖고 있다고도 볼 수 있다. 프로그래머를 계속해서 괴롭힐 동전의 양면적 특성이 존재하는 것이다. 계획과 함께 실천이 있어야만 완성되는 것이 프로그래밍의 중요한 특성이다.

설계한다는 점에서 프로그래머는 건축가와 유사한 점이 많다. 아무리 작은 프로그램을 만들지라도 프로그래머의 머리 속에는 이미 어느 정도의 프로그램 진행 과정에 대한 설계가 먼저 이뤄진다. 그러나 건축가가 실제 건물을 만들지는 않는다. 건물을 직접 만드는 일은 건축 노동자들의 몫이다. 이렇게 건축이라는 영역에서 건물을 설계하는 일과 짓는 일은 완벽히 분리돼 있다. 그러나 프로그래머는 결국 자기 손으로 건물까지 지어야 한다는 점에서 크게 다르다. 상상만 하고 코드를 입력해 실행 프로그램을 만들어내지 않으면 아무 것도 하지 않은 것과 같다. 그런 점에서 프로그래머는 어떻게 보면 화가나 조각가에 더 가깝다. 자기 내면에 비춰진 이미지에서 그치는 것이 아니라 캔버스나 대리석에 실체를 구현해야 하며, 생각하는 주체와 그것을 실현해 내는 주체가 같다.

프로그래머인 우리가 결국 C, C++, 자바 등 특정 언어를 배워 우리의 아이디어를 실행 가능한 소프트웨어로 만들어내야 한다는 사실은 분명하다. 그러나 그렇다고 해서 프로그래밍이 언어를 잘 구사하는 것만으로 끝날 일은 아니다. 그림만 잘 그린다고 해서 화가라고 말하지 않는 것과 같다.

시작은 언어 대신 사고력 부터
그렇다 해도 여전히 훌륭한 프로그래머가 되기 위한 시작은 언어가 아니라 사고 능력이라는 점을 지겹도록 강조하고 싶다. 프로그래밍 언어책을 붙들고 공부한다고 해서 자연스럽게 프로그래밍을 잘 하게 되는 경우는 없다. 만약 그랬다면 이 글을 쓰고 있어야 할 이유조차 없었을 것이다. 언어 공부가 자연스럽게 자신을 프로그래머로 만들어 주지는 않는다. 이 사실은 독자 여러분이나 필자나 말하지 않아도 알고 있다.

또한 그렇다고 해서 무조건 명상에 잠긴다거나 순서도 그리는 일을 다 마치고 나서 언어를 배우고 프로그래밍하는 것도 아니다. 원래 생각하는 과정과 도구를 사용해 실현하는 과정이 떨어져 있는 것도 아니다. 인간은 자유로운 상태에서 생각하며 도구를 사용하고, 도구를 사용하며 생각한다.

인간의 놀라운 점 중 하나는 도구를 사용함으로써 자신의 사고 능력을 발전시키고 그 발전된 사고 능력으로 도구를 개선하거나 새로운 도구를 만들어 가는 무한 사이클을 이어간다는 것이다. 여러 가지 관점에서 설명할 수 있겠지만 필자가 강조하고자 하는 면은 다음과 같다. 생각하지 않으면서 언어를 사용하고 코딩하는 것은 계속 제자리를 맴도는 것과 같다. 생각없는 코딩은 생각하는 사람의 사고 능력에 아무런 영향도 미치지 않는다. 아니, 오히려 악영향을 미치기도 한다. 생각없는 반복적 행동은 오히려 생각을 굳게 만들어 반복적 행동을 또 다시 만들어 낼 가능성이 높다. 극단적으로 말해서 생각없이 코딩하느니 너무 지겨워서 다시 생각을 하고 싶을 정도로 빈둥대거나 잠을 푹 자두는 것이 현명한 일이다(필자는 실제로 그렇게 하고 있다).

인간의 다른 지적 노동과 마찬가지로 현명한 반복만이 현명함을 낳는다. 학문이라는 것이 마치 강을 거슬러 올라가는 것과 같다는 옛말이 있는데, 사실 이보다 더 끔찍하다고 생각한다. 아무 생각없는 반복은 또 다른 생각없는 반복만을 낳을 뿐이며, 현명하게 반복할 수 있다는 사실을 잊게 만든다. 자연스럽게 어떻게 프로그래밍을 배워나가야 하는지 얘기를 이어나가고자 한다.

프로그래밍, 어떻게 배워나가야 하나
'닭이 먼저냐 달걀이 먼저냐' 하는 전통적인 질문이 여기서도 그대로 적용된다. 똑똑해지려면 똑똑하게 배워야 한다. 현명해지려면 현명하게 배워야 한다.

어떻게 똑똑하게 배울 수 있는가
반대로 설명하는 것이 좋겠다. 프로그래밍은 매우 지적인 유희라고 앞서 몇 번이고 반복한 바 있다. 현재 대부분의 프로그래머 지망생이 학습하는 방법은 크게 다르지 않다. 학습이 매우 단순 반복적이다. 단순 반복에 의해 지적인 성장이 이뤄진다고 생각하는가. 게다가 학습 과정이 지겹기 때문에 유희적인 측면도 이미 상실한 지 오래다. 무엇보다도 몇 번의 반복 속에 자기 자신을 지치게 만들면 이미 게임은 끝난 것이다(물론 꾹 참고 꾸준히 하면 언젠가 길이 보일 것이라고 얘기할 수도 있다. 그러나 이렇게 말해 버리면 역시 이 글의 의미가 완전히 사라진다).

똑같은 책, 똑같은 도구를 갖고 배우는데 서로 다른 결과물이 나온다면, 조금만 논리적으로 생각해 봐도 차이를 결정짓는 것은 책이나 도구가 아니라 다른 곳에 있다는 결론을 내리게 된다.

여기서 프로그래밍 학습에 있어 가장 중요한 부분이라고 말할 수 있는 언어 선택 및 학습 과정에 대하여 짚고 넘어가겠다. 먼저 거의 대부분 첫 번째 언어를 잘못 선택함으로써 프로그래밍의 본격적인 재미를 느끼기도 전에 탈락한다. C/C++/자바는 원래부터 만만한 언어가 아니다. 현실적으로 많이 사용하고 있는 이 언어를 많은 사람들이 배우기 어렵다고 말하는데 그 대답은 당연하다. 이 전문언어는 매우 다양한 일을 해낼 수 있는 다목적 언어이며 전문 프로그래머의 경험 속에서 진화해 온 언어이기 때문에 어렵다. 그냥 열렬한 컴퓨터 사용자였다가 갑자기 자기 손으로 프로그램을 만들고 싶다고 해서 제일 먼저 덤빈 언어가 C, C++, 자바와 같은 전문 언어라면 여러분은 열 명 중 여덞, 아홉은 탈락할 것이다.

필자 나이의 다른 프로그래머와 마찬가지로 필자의 첫 번째 언어는 베이직이었다. 필자는 아직도 이 언어에 대한 향수를 갖고 있을 정도로 좋아한다. 이제 생각해 보니 행 번호 개념과 GOTO 문이 유치하게 느껴질 정도로 까마득하지만, 사용자에서 프로그래머가 되기 위한 첫 번째 단계에서는 매우 유용한 중간 단계라고 생각한다. 베이직은 필자에게 인간의 논리가 아니라 컴퓨터의 논리 입장(물론 이것도 창조한 사람이 만들어낸 것이지만)에 서서 자연스럽게 프로그래밍하는 것을 가르쳐 주었다. 지금은 전혀 사용하지 않지만 매우 중요한 언어임에 틀림없다.

단순 조급증에서 벗어나야 한다
프로그래머가 되고 싶어하는 수많은 사람을 처음부터 확실하게 걸러내 준 악습 중 하나는 프로그래머가 되려면 마치 C, C++, 자바 중 하나로 꼭 시작해야 한다는 강박 관념이다. 사람들의 책꽂이에는 최소 2~3 권의 C/C++/자바 책이 꽂혀 있다. 모두 1/3도 보지 않은 채 방치되고 있을 것이다. 바이블에 해당하는 몇 개의 책을 구입했다가 포기하고 결국에는 '며칠 내에 완성하기', '그냥 따라하기'라는 유혹적인 제목의 책을 마지막에 구입한다. 하지만 '21 일 완성하기'를 21일 안에 끝내는 사람은 거의 보지 못했다. 원래 어려운 것을 쉽게 설명하는 일은 더 어렵다.

현실에서 가장 널리 사용하고 있는 매우 현실적인 언어가 C, C++, 자바이기 때문에 처음에 언어를 배울 때부터 이 언어로 시작하면 뭔가 큰 이득이 될 것이라고 생각하는 것이 바로 앞서 표현한 단순 조급증이다. 물론 뭔가에 빨리 도달하고 싶겠지만 생각처럼 되지 않는다. 오히려 꽃도 피워보지 못하고 초반전에서 프로그래머의 세계로부터 탈락하는 지름길을 선택하게 된다.

꿋꿋하게 버텨 살아남은 한두 명도 결국에는 잘못된 믿음의 피해자가 된다. 그들은 어렵게 어렵게 배운 C, C++, 자바로부터 벗어나려고 하지 않는다. 마치 이 세상에 그 세 가지 언어만 있는 것처럼 살아가는데, 사실 살아남기는 했어도 어처구니없게도 언어라는 도구의 노예가 되어 버리고 만다. 이들의 프로그래머적 성장은 이미 끝나버렸다.

상처받은 사람들을 위한 언어, 파이썬
물론 사회적으로 준비가 잘 되어 있는 것은 아니다. 서점에 가봐도 C와 C 유사 언어 외에 다른 언어에 대한 훌륭한 책이 많지도 않다. 여러 가지 언어를 잘 구사하는 훌륭한 프로그래머도 많지 않고 강사는 거의 없다고 봐도 무방하다. 현재 훌륭한 정보의 대부분은 인터넷에 뿔뿔이 흩어져 있고 대부분 영어로 작성돼 있는 것이 현실이다.

이런 상황 속에서도 지금 막 프로그래머가 되고 싶어하는 사람들을 위한 첫 번째 언어로서, 그리고 기존 언어를 모두 맛보고, 패배감을 가진 사람들이 자신을 재정비하고 다시 프로그래밍의 즐거움 속으로 빠져들기 위한 재충전용 언어로 '파이썬'이라는 언어를 권하고 있다.

아직 첫 번째 교육 언어로 채택하기에는 훌륭한 서적과 과정이 나와 있지 않은 상황이어서 필자가 처음 시작했던 베이직보다는 어려울 것이다. 그러나 다른 언어에 의해 상처받은 사람들을 치유하는 치료용 언어로서는 상당한 효과를 볼 수 있다. 이 언어를 통해 언어가 중요한 것이 아니라 인간의 사고력을 풍부하게 발휘하는 것이 중요하다는 사실을 배울 수 있다.

여러분이 오히려 컴퓨터 언어를 단계적으로 여러 가지 배워감에 따라 자신이 진정 원했던 결과를 더 빠르게 그리고 더 견고하게 세워 나갈 수 있다는 사실을 느끼길 바란다. 언어는 결국 교체 가능한 도구라는 사실을 알게 되고, 여러분의 필요에 따라 새롭게 배우고 구사할 수 있다는 자세를 갖추는 것이 중요하다. 또한 2~3 가지 언어를 구사할 수 있어야 한 가지 언어만 알았을 때보다 훨씬 더 심도깊게 언어를 사용할 수 있다는 사실도 깨닫게 될 것이다.

다양한 오픈소스의 세계
컴퓨터 언어를 배우는 플랫폼도 중요하다. 필자로 하여금 C, C++, 자바 이외에도 이 세상에는 수많은 언어가 있으며 수많은 새로운 아이디어가 있다는 사실을 일깨워 준 것이 바로 리눅스와 오픈소스 세계다. 오픈소스는 필자에게 프로그래머로서의 새로운 의지를 수혈해 준 주역이다. 여기서 파이썬을 포함해 LISP, 펄, Ada 등등 많은 언어를 접할 수 있었으며, 여러 번의 외도(?)를 통해 오히려 이미 알고 있던 C 언어를 훨씬 더 잘 이해하고 어디에 어떻게 적절하게 사용해야 할 지 알게 되었다. 무엇보다 각 언어마다 나름의 이유가 있으며 그 창조자의 생각을 어느 정도 이해할 수 있다는 즐거움도 만끽할 수 있었다. 다양한 욕구를 가지고 있는 독자라면 리눅스에서 다양한 오픈 소스 언어를 만나 보기 바란다. 그리고 여러분이 눈길을 주기를 기다리는 어마어마한 분량의 소스 코드가 널려 있다. 또한 멋진 것은 매우 초보적인 소스 코드부터 매우 전문적인 소스 코드까지 선택의 폭이 넓다는 것이다.

한편, 윈도우 플랫폼에서는 좋으나 싫으나 마이크로소프트의 제품 정책에 따를 수밖에 없으며(그나마 예외는 자바 정도) 따라서 제품의 노예가 되어버리기 쉽다. 예를 들어 현재 프로그래머 사이에 논란이 되고 있는 C# 이라는 언어는 새롭게 출현해야 할 정당한 논리적 이유없이 자바와의 전쟁 속에서 나온 사생아라는 지적이 나오고 있다. 직업적 프로그래머라면 새로운 언어와 규칙을 배워야 하는 수고를 마다해서는 안되겠지만, 프로그래머가 되어 볼까 생각하는 사람들에게는 짜증나는 현실이다.

조금이나마 다행스러운 것은 오픈소스 진영이 매우 성숙해 훌륭한 소프트웨어의 대부분이 윈도우와 매킨토시 등 리눅스/유닉스가 아닌 플랫폼에서도 동작한다는 사실이다. 여러 플랫폼에서 동작하는 멀티 플랫폼 언어나 도구를 사용하는 것도 현명한 선택 중 하나다.

웹 프로그래밍 언어에만 집착하지 말자
마지막으로 언어 선택에 있어 웹 프로그래밍과 관련한 PHP, ASP, JSP에 대한 의견을 개진하고자 한다. 결과를 즉시 확인할 수 있으며, 현재 유행하는 개발 영역의 언어이기 때문에 많은 사람들이 쉽게 시작하고 있지만, 이 언어들은 모두 실용 언어로서 인간에게 프로그래밍하는 더 좋은 방법을 알려주지는 못한다. 따라서 전문 프로그래머가 되려면 이 언어에만 집착해선 안된다. 또한 프로그래밍 본연의 지적 유희를 즐기려는 취미 프로그래머도 역시 이 언어에만 집착해선 안된다. 실전의 전문 프로그래머는 이들의 한계를 분명히 인식하면서 사용한다. 실용 언어와 함께 일반 언어도 동시에 익혀 나감으로써 프로그래밍 사고력과 실용성을 모두 성취할 수 있기를 바란다.

직업적 프로그래머가 되고 나면
프로그래밍이란 생계와 결부되는 매우 실용적인 영역임에도 불구하고 의도적으로 이 이야기를 지금까지 피해 왔다. 직업으로 프로그래밍을 하고 있는 사람은 이 글을 읽으며 무슨 지적 유희냐고 화를 내고 있을 지 모른다. 실전에 들어가면 프로그래머의 생활이란 다음과 크게 다르지 않다.

* 자바 프로그래머로 입사했는데(사실 이 말 자체가 우습다. 프로그래밍 언어 중 자바도 구사할 수 있는 프로그래머라고 표현해야 한다) 실제 프로젝트는 별로 사용해 본 적 없는 C++로 해야 한다고 팀장이 전달한다. 자기가 잘 모르는 언어로 프로그래밍을 해야 한다는 부담감 때문에 매일 짜증내면서 어쩔 수 없이 새롭게 책을 구입해 쫓기듯 학습한다.

* 쉬엄쉬엄 컴퓨터 앞에 앉아 이런 생각 저런 생각을 하면서 코드만 작성하고 만들어내기만 하면 되는 줄 알았는데, 거의 대부분의 시간을 보고서와 설명서를 쓰는 데 허비하고 있다. 과연 내가 프로그래밍을 하고 있는지 문서 작성을 하고 있는지 한탄스러울 때가 많다.

* 열심히 만들었더니 주문한 고객의 마음이 또 바뀌어 모든 부분을 일일이 다 고쳐야 하는 일이 다반사다. 창조적이라기 보다는 코딩 막노동(?)이라는 느낌이 들면서 자신이 한심하게 느껴지기 시작한다.

* 거의 대부분의 시간을 버그 잡느라고 머리털 빠지고 있다. 재미없는 디버거와 함께 하는 시간이 코드 짜는 시간보다 월등히 많다.

이런 현실적인 문제들을 하나씩 짚어 가기 전에 필자는 독자 여러분에게 이 세상에 재미를 느끼게 해 주는 수많은 일들이 있는데 프로그래밍을 자기 직업으로 삼은 이유가 무엇이냐고 우선 반문하고 싶다. 마음속으로 자기만의 답을 생각해 보고 앞서 나열한 네 가지 문제를 하나씩 다뤄보자.

새로운 언어를 적극 받아들이자
번 문제를 살펴보자. 회사나 팀장의 요구가 부당하다고 생각할 지 모르지만, 자신이 모르는 다른 언어로 프로그래밍해야 한다는 요구가 무조건적으로 틀린 것은 아니다. 사실 여러분이 직업적 프로그래머로서 직장 상사나 팀장에게 '나는 이 언어밖에 못합니다'라고 말하는 것은 프로그래머로서의 자신의 진짜 가치를 고백하는 것이나 다름없다. 굳이 사회적으로 통용되는 표현을 쓰자면, 한 가지 언어만을 전문으로 구사할 수 있다고 말하는 사람은 그 언어만 다룰 수 있는 기능사일 뿐이다. 기술자라면, 아니 진짜로 프로그래머라면 새로운 언어를 배워야 한다는 것이 짜증나는 일이라고 단언해서는 안된다. 새로운 언어를 배워 나가는 것은 전문 프로그래머의 일상 업무이다.

물론 지금 당장은 답답할 지 모른다. 그러나 필자의 논지에 수긍한다면 어떤 언어든 자기가 구사할 줄 아는 언어의 전부가 아니라 그 중 하나일 뿐이어야 한다. 팀장의 요구가 없다 하더라도 사실 유행에 따라 어쩔 수 없이 또 다시 끌려가야 하는 경우도 있지 않은가. 원래부터 피할 수 없는 일이므로 적극적으로 받아들이자.

문서화는 결코 어려운 일이 아니다
번 문제를 살펴보겠다. 필자도 보고서를 쓰거나 설명서를 쓰는 작업은 태생적으로 싫어한다. 그러나 보고서나 설명서를 쓰는 작업 자체가 프로그래머의 몫이 아니거나 또는 무가치한 일로 보는 입장에는 동의할 수 없다. 물론 형식화한 보고서, 설명서를 쓰는 것은 매우 지겹고 화나는 일이다.

보고서와 설명서를 쓰는데 많은 시간이 걸리는 이유는 두 가지를 들 수 있다. 원래 문서화 작업이라고 하는 것이 생각보다 시간이 많이 걸리는 작업이다. 우리의 머리 속에 있는 것을 글로 표현한다는 것이 쉽지 않다는 사실은 어렸을 때부터 독후감 쓰는 일이 쉽지 않다는 경험으로부터 잘 알고 있을 것이다. 글로 표현한다는 것은 자유롭게 흘러가는 생각을 그대로 반영하는 것이 아니라 한 번 더 숙고해 체계화하는 과정이기 때문이다(필자 또한 지금 이 원고 쓰는 일을 흔쾌히 승낙해 놓고서는 얼마나 후회하는지 모른다).

그러나 무엇보다도 자신이 글을 쓰는 일에 익숙하지 않다고 스스로를 묶어 버림으로써 문서 작업을 싫어하고 집중할 수 없게 되는 수도 있다. 자기 최면을 통해 집중하지 않음으로써 여러분은 자기가 싫어하는 일에 더 많은 시간을 할애할 수밖에 없고 그 만큼 여러분이 원하는 작업에 필요한 시간을 허비하고 있다.
리눅스나 오픈소스라고 해서 마냥 코딩만 하고 문서화는 전혀 안한다고 생각하면 오산이다. 최소한의 README, 잘 만들어진 문서가 없는 오픈소스 소프트웨어는 초보 프로그래머의 작품일 뿐이다. 이미 수준 높은 품질의 아파치, 삼바, 리눅스 커널을 보면 상당히 친절한, 하지만 작성한 사람 입장에서는 많은 노력을 들인 문서들이 포함돼 있다는 사실을 알게 될 것이다.

문서화 또한 현명한 대처가 필요하다. 막무가내로 불필요한 분량의 문서를 요구하는 팀조직이 있다면 매우 고루한 조직임에 분명할 것이다. 이러한 조직에 대해 말할 수 있는 해결책은 없다. 그 조직은 여러분이 선택한 것이다. 너무 불합리한 경우가 아니라면, 문서화 작업을 소프트웨어 디자인의 일부로 여기는 능동적인 자세가 필요하다.
코딩을 할 때 소스 코드에 주석(comment)을 넣지 않는 것은 전문 프로그래머로서의 자질이 없음을 단적으로 보여 주는 것이므로 주의하자. 직업적 프로그래머라면 어떤 일이 있어도 소스 코드는 주석으로 시작해서 주석으로 끝나야 한다.

문서화란 어떻게 보면 그렇게 어려운 것도 아니며 프로그래밍의 필수 과정이기도 하다. 기본적으로 소스 코드의 주석, README, INSTALL, 그리고 TODO(앞으로 할 일), 각 버전간의 변경 사항을 적는 Changes 문서는 모든 문서화의 기초가 된다. 아직 직업 프로그래머로 취업하지 않는 예비 프로그래머는 지금부터라도 이를 습관화하기 바란다.
많은 사람들이 오해하고 있는 것을 하나 지적하고자 한다. 대부분 프로그래밍을 코딩에 쏟은 시간만 갖고 평가하려는 경향이 있다. 그러나 앞서 'program'의 어원을 알아보면서 확인한 것처럼, 프로그래밍에서 가장 중요한 것은 계획이다. 계획하고 기획한 것을 좀 더 구체적인 방법으로 설계하고 언어를 통해 구현하고 중간 과정을 기술하는 모든 행위가 프로그래밍이다.

'간략한' 프로그램을 위해 노력하자
번 문제로 넘어가겠다. 일단 계획이 서면 거침없이 코드를 작성하고 고치지 않을 것 같지만 몇 명의 천재적인 프로그래머를 제외하고(실제로 그런 사람이 있는지 궁금하다. 자기가 수없이 반복하면서 얻은 경험에 의지해 거침없이 하는 것은 아닐까?) 거의 모든 프로그래머는 그런 식으로 프로그래밍하지 않으며 할 수도 없다. 열심히 프로그래밍했다고 생각했는데 일 년이 지나 소스 코드 개수와 줄 수를 세 보고나면 자괴감에 빠질지도 모른다.. 실제로 우리는 끝없이 고치고 고치고 또 고친다. 그러면서 소프트웨어가 견고해 지는 것이다.

그리고 현실 세계에서 고객의 요구는 첫 번째로 중요하다. 그들의 요구가 변화하는 것은 당연하다. 훌륭한 프로그래머는 고객이 처음부터 정확한 요구 사항을 제시하도록 유도하고 변화의 폭이 제어할 수 있는 범위 안에 들 수 있도록 잘 안내한다.
소프트웨어의 기능을 잘 구분하고 반복적인 패턴을 함수/라이브러리/모듈화하지 못하는 초보 프로그래머는 똑같은 소스 코드를 여기 저기 복사해서 쓰게 되는데, 이 때는 소프트웨어를 고치는 일이 곤역스러울 수밖에 없다.

전문 프로그래머라면 반복적인 패턴을 훨씬 더 많이 찾아내고 압축하는 기술을 가꿔 나가야 한다. 다시 한 번 말하지만 반복적인 경험에서는 얻을 것이 별로 없다. 그 수많은 경험 중에서 문제 해결을 위해 고민한 시간만이 소중한 경험이다.
고객의 변덕에 따라 짜증이 날 정도로 많이 고쳐야 한다면, 그것은 오히려 여러분에게 더 많은 경험과 사고가 필요하다는 증거이다. 같은 일을 하더라도 지난번보다는 더욱 더 간략하게 프로그램을 작성할 수 있도록 노력하라.

디버깅은 불필요한 일이 아니다
번 문제를 생각해 보자. 우리의 예상과 달리 프로그래밍 중에서, 특히 프로그래밍의 일부분인 코딩 중에 새로운 코드를 만들어 내는 시간보다는 기존의 코드를 개선하거나 잘못된 코드를 찾아내는 일에 절대적으로 많은 시간을 쏟는다고 한다.

필자의 경우도 예외는 아니었다. 그러나 경험을 토대로 스타일을 바꿔나가기 시작했다. 필자가 제일 많은 시간을 쏟는 부분은 자료 수집과 연습 코드 부분이다. 필자의 경우에는 무조건 책이나 웹을 통해 관련 자료를 수집하고 재빨리 훑어 내려간다. 다 이해하지 못해도 상관없다는 듯이 읽어 내려간다. 특히 요즘은 노하우보다 노웨어가더 중요하다고 말하지 않는가. 이미 많은 문제의 일부분을 다른 사람이 해결했을 가능성이 높다. 이를 반복할 필요는 없다. 현 시대에서 요구하고 있는 프로그래머의 자질 중 하나는 처음부터 다시 만드는 것이 아니라, 기존의 것을 취사 선택해 창의적으로 결합시키는 능력이다.

그 다음에는 짧은 연습 코드를 많이 작성한다. 핵심적인 부분에 대한 연습 코드를 몇 번 작성하다 보면 프로그램의 절반이 끝났다고 해도 과언이 아니다. 개인적으로 자료 수집과 연습 코드, 특히 연습 코드에 신경을 많이 쓰는데 이렇게 함으로써 프로그래밍 과정에서 절대 빠질 수 없는 디버깅(debugging)을 최대한 피할 수 있다고 생각하기 때문이다.

하지만 어떤 식으로든 디버깅 과정을 피할 수 있다고 생각하지 말라. 사실 버그를 얼마나 빨리 잡는가, 그 짜증나는 시간을 어떻게 빨리 마칠 수 있는가는 그가 얼마나 유능한 프로그래머인지 판단할 수 있도록 해 주는 잣대이다. 디버깅이 마치 불필요한 과정이라고 생각하지 말았으면 한다. 여러분이 만든 버그야 어떻게 잘 피할 수 있을 지 몰라도 실전에서는 남이 만들어낸 버그를 찾아야 할 때가 많다. 그런데 남이 만들어낸 버그를 잘 찾는 사람이란 결국 알고 보면 자기 자신도 똑같은 버그를 만들어 보았고 고통스러운 시간을 통해 버그를 찾아낸 경험이 많은 사람이다.

디버깅에서 중요한 자세는 절대 짜증내지 말고, 적군을 무찌르겠다는 식의 투지를 갖고 단시간 안에 돌파하는 것이다. 만약 한 가지 방법이 실패했다면, 잠시 먼 발치에서 새로운 구상을 한 뒤, 다시 전투적으로 임한다. 지루하게 디버깅을 하면 시간도 많이 걸리고 정신도 피폐해진다.

결론적으로 정도의 차이가 있을 뿐, 여러분이 현실 세계에서 당면하고 있는 모든 문제는 피해야 할 어떤 일이 아니라 사실 프로그래밍이라고 하는 전체 과정에 원래부터 속해 있던 일부라는 사실을 인식하고 이에 대해 짜증을 내는 수동적인 방식이 아니라 좀 더 현명하게 그리고 적극적으로 자기만의 해결책을 찾아나가길 기대하겠다.

몇 가지 실천안
다음 실천안은 여러분이 좀 더 프로그래밍을 즐길 수 있고 직업적으로도 유능함을 발휘할 수 있게 되길 바라며 마음속에 떠도는 생각을 아주 간략하게 정리해 본 것이다.

◆ 프로그래밍이란 절대 코딩이 아니다. 먼저 생각하고 만든 것을 정리하고 문제점을 해결해 나가는 모든 과정이 프로그래밍이다. 이 점을 자기 자신에게 충분히 납득시켜야 한다. 코딩은 프로그래밍의 일부이다.
◆ 각 언어는 모두 나름의 탄생 이유가 있으며 그 언어를 만든 사람의 아이디어가 담겨 있다. 언어를 먼저 선택하려 하지 말라. 유능한 프로그래머는 절대 한 가지 언어에 집착하지 않는다.
◆ 언어를 처음 배울 때에는 그에 걸맞게 쉬운 언어부터 시작하라. 실전에서 사용하는 언어를 먼저 배워두면 더 이득이 될 것이라고 생각하지 말라. 전문 프로그래머가 되려면 최소한 세 개 이상의 언어를 익혀야 한다. 물론 세 가지 언어를 똑같이 잘 할 필요는 없다. 자기 주 종목 언어를 갖지 말라는 말이 아니다.
◆ 책을 다 읽고 나서야 프로그래밍할 수 있다고 생각하지 말고 배운 만큼만 갖고도 연습 코드를 작성할 수 있어야 한다.
◆ 언어 그 자체는 여러분의 상상력을 키워주지 않는다. 상상력은 여러분 스스로 인생의 모든 영역에서 듣고 배우면서 채워야 한다. 언어는 상상력을 실현할 도구만 제공할 뿐이다. 과학과 수학에 관심을 가져 보라(그렇다고 해서 A 등급을 맞을 만큼 잘 할 필요는 없다).
◆ 주석 및 문서화 버릇을 들이자. 프로그래밍의 귀찮은 일부가 아니라 매우 중요한 핵심 부분이다.
◆ 언어책이 줄 수 있는 지식의 양은 딱 그 만큼이다. 여러분의 상상력과 프로그래밍 능력을 살찌워주는 것은 다른 사람, 다른 프로그래머다. 적극적으로 프로그래밍 사용자 모임 또는 뉴스그룹에 참여해 남을 돕고 남으로부터 도움을 받는 것이 자기 계발의 원천이다.
◆ 자기가 습득한 지식은 자신만이 볼 수 있는 형태든 아니면 홈페이지를 통해 누구나 볼 수 있는 형태든 상관없이 정리하는 습관을 갖자. 무엇이든 막상 글로 적으면 자신이 얼마나 피상적으로 알고 있는지 각성하게 되고 지식을 좀 더 견고하게 만들게 된다.
◆ 현실은 현실이다. 영어를 잘 못하고 두려워하는 사람이 최고의 프로그래머가 되기는 거의 불가능하다. 여러분이 한국어만 하면 한국 프로그래머의 지식만 습득할 수 있을 뿐이다. 영어를 두려워하지 않는다면, 그 대가는 전세계 프로그래머의 지식 습득이 된다(영어를 잘 하는 방법은 영어를 잘 하는 사람에게 물어보라).

아무튼 여러분이 프로그래밍의 본질을 재확인하고 프로그래밍하는 그 과정을 즐길 수 있는 사람이 될 수 있기를 바라며 글을 마친다.

NHibernate Like 검색

xyzlast Y2K — Thu, 02 Jun 2011 14:45:46 +0900

QueryOver<> method에서 LINQ 쿼리인 .Contains가 먹히지 않는다.;
이때 다음과 같은 코드를 사용하면 LIKE 검색을 가능하게 할 수 있다.

var restriction = Restrictions.On(m => m.Name).IsLike("%바람과%");
var movies = session.QueryOver().Where(restriction).List();
foreach(var movie in movies)
{
    Console.WriteLine(movie.Name);
}

NHibernate, Oracle 환경에서 StoreProcedure 호출

xyzlast Y2K — Thu, 26 May 2011 10:23:44 +0900

Oracle에서 REFCURSOR 타입을 사용하는 StoreProcedure를 OUT parameter로 사용하는 경우에는 2가지 제약 사항이 있다.

1. Table Cursor를 사용하는 것이 아닌, SYS_REFCURSOR 를 사용해야지 된다.
2. 1개의 Cursor만 return되는 것을 지원하며, in parameter의 순서가 중요하다. 반드시 SYS_REFCURSOR를 처음에 return시켜줘야지 된다.

이와 같은 규칙을 따르면 다음과 같은 StoreProcedure를 사용하는 경우 다음과 같이 HBM이 구성 가능하다.

CREATE OR REPLACE PROCEDURE FWKUSER.sp_XMMenu_MenuName_Test_q
  (
   spcur        OUT sys_refcursor, 
   p_menu_name    IN VARCHAR2) IS
BEGIN
  OPEN spcur FOR
    select   
    *         
   
    from   xm_menu 
    where   menu_name like '%' || p_menu_name || '%'
    and        fold_yn = 'N'
    and        hidden_yn = 'N'
    and        use_yn = 'Y'
    and        del_yn = 'N'
    order by instr(menu_name, p_menu_name, 1, 1), menu_name;
END;
/

이렇게 구성된 hbm을 이용해서 다음과 같이 StoreProcedure를 호출 할 수 있다.

using(var session = sessionFactory.OpenSession())
{
    var query = session.GetNamedQuery("GetMenus");
    query.SetParameter("menuName", "%");
    var output = query.List();

    foreach(var p in output)
    {
        Console.WriteLine(p.MenuName);
    }
}

Class의 모든 Property를 Xml 값으로 표현하기.

xyzlast Y2K — Thu, 21 Oct 2010 18:44:36 +0900

PropertyInfo를 이용해서 간단히 슥삭. 너무나 편하게 debuging할 수 있는 방법이라서 자주 사용하기도 하고, 긁어서 그냥 넣어주면 편해서 올려둔다. 기본적으로 Property Invoke를 이용해서 각 값을 얻어내고, 그 값을 표시하는 방법인데... 이모저모로 편하구.

public override string ToString()
{
    StringBuilder sb = new StringBuilder();
    sb.AppendLine(string.Format("<{0}>", GetType().Name));
    foreach(PropertyInfo property in GetType().GetProperties())
    {
        string propertyName = property.Name;
        object value = property.GetValue(this, null);
        if(value != null)
        {
            if(value is IEnumerable && !(value is string))
            {
                sb.AppendLine(string.Format("<{0}>", propertyName));
                IEnumerator enumerator = ((IEnumerable)value).GetEnumerator();
                while(enumerator.MoveNext())
                {
                    sb.AppendLine(enumerator.Current.ToString());
                }
                sb.AppendLine(string.Format("", propertyName));
            }
            else
            {
                sb.AppendLine(string.Format("<{0}>{1}", propertyName, value.ToString()));
            }
        }
    }
    sb.Append(string.Format("", GetType().Name));
    return sb.ToString();
}

Windows Phone 7 발매와 Apple 이야기.

xyzlast Y2K — Wed, 13 Oct 2010 02:50:48 +0900

개인적으로 굉장히 기대를 하고 있는 Windows 7 Phone Series가 드디어 나왔다.

보면, 재미있는 특징들이 있는데..

첫번째로, 스팩을 보면 상당히 천편일률적인 스팩과 디자인

두번째로, OS의 업그레이드는 MS에서 일괄적으로 배포

세번째로, UI의 차별화를 볼 수 있다.

첫번째의 경우에는... 이건 하드웨어 제조사들에게 축복이다.

기존 안드로이드 폰들의 경우에는 안드로이드에 최적화된, 그리고 자신만의 UI를 넣기 위해서 자신들만의 안드로이드를 각 폰마다 새로 만들고 있었는데, Windows 7 Phone에는 전혀 그럴 필요가 없다. MS의 스팩대로만 만들어주면, 그 다음은 MS에서 알아서. 각 장치 드라이버 관리 뿐 아니라 표준화된 PC의 운영체제의 30년 노하우를 가진 기업이 알아서 처리한다. 왜 퀄컴이 이번 Windows 7 Phone에서 모든 제조업체를 뛰어넘고 MS의 최고 파트너가 되어있는지... 예전의 PC 시장의 Intel + MS 동맹과 같은 방법이다.

두번째로는... 이건 기존 안드로이드폰들에게 재앙이 될수 있는 문제다.

기존 안드로이드폰의 계속되는 문제는 폰을 발매하고 나서 구글에서 OS 업그레이드를 하고, 그 업그레이드를 자신의 폰에 반영하기 위해서 또 인적자원을 투입해야지되는 악순환의 발생이다. 1.6->2.0->2.1->2.2 여기에 내년에 나올 3.0 업그레이드를 과연 기존 폰들이 할 수 있을까? 그리고, 제조 업체에서는 계속해서 하드웨어에 최적화된 안드로이드 버젼을 만들어낸다는 것은 폰을 팔아서 나온 이윤보다 사후관리가 더 문제가 되버린다. 애플은 앱스토어를 통해서 폰을 판매한 후에 지속적인 이윤을 얻을 수 있지만, 안드로이드는 그것이 불가능하다. 제조업의 특성상 (애플제외) 10~20% 이상 이윤을 얻기는 거의 불가능하다. 거기에 지속적인 업그레이드로 6~7 개월 이상 개발 인력을 그 폰에 계속해서 쏟아야지 된다면... 그건 재앙이다. -_-; 이 부분은 MS가 기존의 Windows upgrade를 관리하던 방법대로 한다면, 의외의 대박은 이 점에서 나올수도 있겠다는 생각이 든다. 제조사들의 코스트를 혁신적으로 줄일 수 있다는 말이지. (안드로이드는 절대 공짜가 아니다. 발머의 의견에 전적으로 동의한다.)

세번째로는 이건 호불호가 나뉠것 같은 의견이긴 하지만, 개인적으로는 MS만의 차이점을 주는 좋은 UI라고 생각된다.

애뮬레이터로 돌려보면 정말 직관적으로 알 수 있는 UI라는 것을 느낄수 있었고, 꼭 내 손으로 만져보고 싶은 그런 UI라는 욕심이 든다.

이번 Windows Phone 7 발매는... 지금 가속화되어가고 있는.. (미국에서 갤럭시S가 공짜로 풀려있다는..) 스마트폰 시장의 레드오션을 더욱더 가속화하게 될 것 같다. 치킨게임하기에 딱 좋은 운영체제가 나와버렸다는 말이지.; 여기서 가장 좋은 위치는... 뭐니뭐니해도 삼성이다.; 모든 폰들에 들어가는 칩과 AMOLED, LCD를 자신이 생상하기 때문에 가장 적절한 가격으로 공급받고 뿌려버리는 것이 가능하다. 열받으면 경쟁사것 약간약간 막아주기까지 하면서 말이야.;

애플의 고민은 이제부터 시작일 것 같다. 애플은 안타깝게 치킨게임에서 이긴적이 단 한번도 없다. 애플의 마인드는 새로운 것을 개척하고 놀라움을 주기에는 충분하나, 레드오션에서 자신이 승자가 되기에는 매우 안좋은 마인드를 가지고 있다. 결국, 예전에 했던 바보짓을 또하면 정말로 망하는건데... 과연 어떻게 될지?

Design Pattern with StarCraft(2) - Adapter Pattern

xyzlast Y2K — Tue, 04 Aug 2009 22:52:11 +0900

1의 경우에서 Strategy Pattern을 사용해서 각각 Marin, Firebet, Medic을 구현을 다 해놓고 나니, Zerg Unit를 다른 개발자가 개발해서 들고 왔다.

그런데, 각 unit의 method가 다르기 때문에 사용할 수가 객체가 어떤 형태인지에 따라 접근 방법을 달리 해줘야지 되는 문제가 발생되었다. 이럴 때에, Method의 Interface를 한번 덮어줘서 사용하고자 하는 interface로 변경해주는 것만으로, 이런 문제를 해결 할 수 가 있다. 이것이 Adapter Pattern이다.

기본적으로 Zerg Unit는 MoveTo를 갖지만, Attack이 아닌 Bite Method를 갖는다.

그렇지만, 본질적으로 Bite, RunTo Method는 BaseUnit의 Attack, MoveTo와 유사 동작을 하기 때문에

Public으로 선언된 각 Method를 변경시켜주면 된다.

public abstract class ZergUnitBase
{
    //Terran 의 Unit과는 다른 Bite와 Run Method를 가지고 있다. 
    public abstract String Bite();
    public abstract String Run(String direction);
}

따라서, BaseUnit과의 호환성을 맞추어주기 위해서 ZergUnitToBaseUnit이라는 Adapter를 구성해준다.

public class ZergUnitToBaseUnit : BaseUnit
{
    private readonly ZergUnitBase zergUnitBase;

    public ZergUnitToBaseUnit(ZergUnitBase zergUnitBase)
    {
        this.zergUnitBase = zergUnitBase;
    }

    public override string Attack()
    {
        return zergUnitBase.Bite();
    }

    public override string MoveTo(string direction)
    {
        return zergUnitBase.Run(direction);
    }
}

구성된 zerg unit을 이용해서 terran과 zerg의 난타전을 테스트하면 다음과 같다.

BaseUnit unit1 = new ZergUnitToBaseUnit(new Zergling());
BaseUnit unit2 = new ZergUnitToBaseUnit(new Hydralisk());

Console.WriteLine(unit1.Attack());
Console.WriteLine(unit2.MoveTo("Terran"));

보면, Zerg와 Terran의 Unit을 다루는 법이 동일하게 변경되었다. 다른 인터페이스와 동일하나, class의 변경은 이루어지지 않는다.

Design Pattern with StarCraft(1) - Strategy Pattern

xyzlast Y2K — Tue, 04 Aug 2009 22:39:10 +0900

전에 한번 정리한 소스를 한번 정리해보는 내용으로...

Marin과 Medic, FIrebet.. 이 3개의 unit가 존재를 하고, 이 unit은 Attack과 Move라는 기본 동작을 갖는다.

Move라는 동작은 모든 Unit이 동일한 동작을 할 수 있지만, Attack 방법은 각기 다르고, 기본적으로 Attack이라는 Method를

갖지만 내부 구현이 다른 동작이 되게 된다.

따라서, 각기 다른 동작을 구현하는 Class를 따로 뽑아내서 구현하는 Strategy Pattern이 사용 가능하다.

먼저, 각기 다른 Attack에 대한 동작을 구현하는 Rifle, Firebazuka, Heal Class를 구현한다.

class Rifle : IAttack
{
    #region IAttack Members

    public string Attack()
    {
        return "dddd...";
    }

    #endregion
}

public class Firebazuka : IAttack
{
    #region IAttack Members

    public string Attack()
    {
        return "Fire!!...............";
    }

    #endregion
}

public class Heal : IAttack
{
    #region IAttack Members

    public string Attack()
    {
        return "Heal... ";
    }

    #endregion
}

그리고, 이 Attack Method의 IAttack을 인자로 갖는 BaseUnit class를 만들어준다.

BaseUnit은 각 Unit의 parent class가 된다.

class Runner : IMove
{
    #region IMove Members

    public string MoveTo(string direction)
    {
        return String.Format("To :{0}, Move it!", direction);
    }

    #endregion
}

public abstract class BaseUnit
{
    protected IAttack attackMethod;
    protected IMove moveMethod;

    protected BaseUnit()
    {
        
    }

    protected BaseUnit(IAttack attackMethod, IMove moveMethod)
    {
        this.attackMethod = attackMethod;
        this.moveMethod = moveMethod;
    }

    public virtual String Attack()
    {
        return attackMethod.Attack();
    }

    public virtual String MoveTo(String direction)
    {
        return moveMethod.MoveTo(direction);
    }
}

이렇게 구성된 BaseUnit을 이용해서 Marin, Firebet, Medic을 구현해준다. 구현된 코드는 다음과 같다.

public class Marin : BaseUnit
{
    public Marin() : base(new Rifle(), new Runner())
    {
        
    }
}
public class Firebet : BaseUnit
{
    public Firebet() : base(new Firebazuka(), new Runner())
    {
        
    }
}
public class Medic : BaseUnit
{
    public Medic() : base(new Heal(), new Runner())
    {
        
    }
}

구현된 Class를 이용해서 Test Code를 작성하면 다음과 같다.

//Marin, Medic, Firebet의 class 생성
BaseUnit unit1 = new Marin();
BaseUnit unit2 = new Marin();
BaseUnit unit3 = new Medic();
BaseUnit unit4 = new Firebet();

//BaseUnit으로 Attack, MoveTo를 모두 구현
Console.WriteLine(unit1.Attack());
Console.WriteLine(unit2.Attack());
Console.WriteLine(unit3.Attack());
Console.WriteLine(unit4.Attack());

Console.WriteLine(unit1.MoveTo("Direction"));
Console.WriteLine(unit2.MoveTo("Direction"));
Console.WriteLine(unit3.MoveTo("Direction"));
Console.WriteLine(unit4.MoveTo("Direction"));

Strategy Pattern은 같은 Interface에서 각각 다른 동작을 하는 class들을 구현하는 방법으로,

Method의 주체가 되는 Rifle, Firebazuk, Heal class의 구성이 관건이다. 다른 것을 객체화하라. 라는

Design pattern의 성경같은 구절이 생각난다.

WMI Performance Monitoring

xyzlast Y2K — Wed, 29 Jul 2009 08:44:02 +0900

indows에서 System의 모든 Monitoring은 WMI를 통해서 가능하다.

WMI를 이용하는 경우, Remote에서 접근이 용의하다는 장점과 Server군의 경우 다양한 속성들을 모두 Monitoring할 수 있다는 큰 장점을 가지고 있다. 또한, 기본적인 WMI의 Query를 통해서 값을 얻는 것이 아닌, .NET에서는 WMI에 대한 Event Handling이 가능하다.

지정될 수 있는 Event는 http://msdn.microsoft.com/en-us/library/aa394583(VS.85).aspx을 참조.

모니터링 소스는 다음과 같다.

ConnectionOptions connectionOptions = new ConnectionOptions()
     {
            Authentication = AuthenticationLevel.Default,
            Username = @"UserName",
            Password = @"Password",
            EnablePrivileges = true,
            Impersonation = ImpersonationLevel.Impersonate
      };
            
ManagementScope scope = new ManagementScope(@"\\hyperv\root\cimv2", connectionOptions);
scope.Connect();

//__InstanceCreationEvent : Wmi instance create event
//__InstanceModificationEvent : Wmi instance value modified event
//__InstanceDeletionEvent : Wmi instance delete event
//__InstanceOperationEvent : Wmi instance method call event

WqlEventQuery wQuery = new WqlEventQuery("Select * From __InstanceModificationEvent Within 1 " + "Where TargetInstance ISA 'Win32_PerfFormattedData_Tcpip_NetworkInterface'");

ManagementEventWatcher watcher = new ManagementEventWatcher(scope, wQuery);
watcher.EventArrived += new EventArrivedEventHandler(DisplayWatcherEvent);
watcher.Start();

Console.ReadLine();
            
watcher.Stop();

일반적인 Monitoring Handling과 동일하다. 특징이 나타나는 곳은 오히려 Event 처리기쪽이 더 특징이 나타난다.

private static void DisplayWatcherEvent(object sender, EventArrivedEventArgs e)
{
    foreach(var property in e.NewEvent.Properties)
    {
        if(property.Name == "TargetInstance")
        {
            ManagementBaseObject managementObject = property.Value as ManagementBaseObject;
            if (managementObject == null)
            {
                Console.WriteLine("Data convert is null");
            }
            else
            {
                var bytesPerSec = managementObject.Properties["BytesTotalPersec"].Value;
                var bytesReceivedPersec = managementObject.Properties["BytesReceivedPersec"].Value;
                var bytesSentPersec = managementObject.Properties["BytesSentPersec"].Value;
                string name = managementObject.Properties["Name"].Value.ToString();

                Console.WriteLine("{0}\t{1}\t{2}\t{3}", 
                    name.Substring(0, 4), bytesPerSec, bytesReceivedPersec, bytesSentPersec);
            }
        }
    }
}

특징으로 보이는 것이 EventArrivedEventArgs에서 Property의 Value형태로 WMI Instance의 값이 전달된다는 점이다. 그리고, Performance Counter의 경우에는 이전값, 현재값이 Property의 Name으로 전달되기 때문에 Diff. Monitoring에도 용의하다.

나라가 미쳐버렸군. -_-

xyzlast Y2K — Tue, 03 Feb 2009 19:16:54 +0900

말도 안되는 출판 검열이라니.;;

정말로 20년은 확 돌려버리는 미친정권이라는 생각마져든다.

http://bbs1.agora.media.daum.net/gaia/do/debate/read?bbsId=D109&articleId=194216

저는 한 출판사에 다니는 편집자입니다.

이번에 저희 출판사에서 나오는 책이 검열 아닌 검열(?)을 당해 너무 답답한 마음에 처음으로 아고라에 글을 남기게 되었습니다.

이번에 출판사에서 근현대문학을 초판본 형태로 출간한다는 기획을 하고, 기획된 100종 중 50종(현재는 47종)을 출간했습니다.

그런데, 그중 한 작품이 때 아닌 ‘검열’을 받고 출간하지 못하고 있습니다.

근현대문학 전체를 다루는 것이기에 당연히 납북, 월북, 북한 작가들이 포함되었는데,

저희 50종 중에 48년 이후 북한에서 출간된 책의 경우는 황건의 <<개마고원>> 하나가 있었습니다.

이 사실이 통일부로 넘어가자 이제 본격적으로 ‘검열’(?)이 시작되었습니다.

<<개마고원>>의 본문 파일을 요구하더니, (발췌본인지라) 나중에는 원본을 달라고 했습니다.

요청대로 원문을 복사하여 주고, 한참을 기다렸습니다. (그동안 제작 완료된 47종을 출간했습니다.)

그리고 통일부로부터 연락이 왔습니다.

‘원래 이런 타이틀은 반입을 허가하지 않는데, 한국근현대문학 출간의 취지를 고려하여 조건부 승인’을 하겠다는 것입니다.

바로 그 조건부 승인이란 ‘전체 190쪽 분량 가운데 23쪽은 전부 삭제하고, 그 외 29쪽가량은 자신들이 표시한 부분을 삭제하면’ 출간을 허용하겠다는 것입니다.

정말 이 이야기를 듣는 순간 어이가 없었습니다. 지금이 80년대도 아니고, 2000년대에 문학을 통일부 기준으로, 마음대로, 삭제하라니요.

진짜 뭐, 이런 경우가 다 있나 싶었습니다.

삭제하라는 부분을 보면, 정말 가관입니다.

가령 소설에서 당시 시대 상황을 이야기한 장면인데도 ‘김일성’이 들어가면 무조건 삭제하라 하고,

소설의 주인공이 북한 쪽의 입장이기 때문에 당연한 것을, 가령 남한군이나 미군을 ‘원수’, ‘놈들’이라고 부르는 것도 전부 삭제하랍니다.

또 미군이 북한 마을에 와서 행패를 부린 부분은 아예 도려내라고 합니다.(대체 미군이 선량하지 않으면 출간될 수 없다는 현실이 슬픕니다.)

“그사이에 평양에는 북조선 인민 위원회가 창설되고 김 일성 장군이 위원장으로 추대되였다.”(삭제하라는 문장)

“더 안 될 일로 나는 조국의 이 엄중한 날에 원쑤에 대한 싸움보다도 내 개인을 위한 적은 생각에 빠지고 있으며, 빠져가고 있는 것은 아닌지?”(밑줄 친 부분 삭제 요청 문구)

“정치부대 대장은 우선 래일 밤중에, 놈들이 밤이면 기여드는 십릿길 오른편 삼림 속을 기습하겠는데 총소리가 들리는 대로 그 안골 쪽에서 탄약더미에 불을 지르면 놈들을 더욱 당황하게 만들면서 량쪽 전투가 다 유리하리라고 하였다.”(밑줄 친 부분 삭제 요청 문구)

“...고모네가 늦게 떠난 것이 확연한 것처럼 필시 이것은 늦어서야 피난 가다 숨은 두 녀자를 미국 놈들이 발견하고 겁탈하려 끌어냈던 것이며, 반항하는 그들에게 수없는 총탄으로 보복한 것에 틀림없었다...”(이 부분 포함 거의 반 장가량 삭제 요청)

이상이 <<개마고원>> 검열에 대한 이야기였습니다.

지금 답답한 것은 ‘검열’ 자체보다도 이런 일이 벌어지고 있다는 사실을 아무도 몰라줄까 걱정되어서입니다.

현재 회사에서는 그쪽에서 압력을 받게 될까 봐 이러지도 저러지도 못하고 있는 실정입니다.(아무래도 출간을 포기하는 것으로 가닥을 잡아가는 것 같습니다.)

도대체 그들은 문학이 무엇인지, 예술이 무엇인지 아는지 묻고 싶습니다.

이미 연구도 많이 되어온 <<개마고원>>을, 출간하지 못하게 하는 것이 어떤 의미인지... 이제 북한 문학 연구도 금지하려고 하는 것인지... 정말 답답하기만 할 뿐입니다.

도대체 출판의 자유가 이런 식으로 침해받아도 되는 것인지 잘 모르겠습니다.

마지막으로 몇몇 분이라도 <<개마고원>>을 기억해 주십사 하고 <<개마고원>> 줄거리를 넣고, 이야기를 마치겠습니다.

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

징병으로 끌려간 지 두 달 만에 경석은 1945년 6월 하순에 비를 맞으며 집으로 몰래 숨어든다. 스스로를 “어떤 학대받는 주린 짐승”처럼 여기는 경석은 버들골 고모네 집에 숨어 있다가 돌아온 것이다. 순희네 집안 사람들에 의해 일찍 징병에 내보내졌다고 생각하는 경석은 울분을 참으면서 낮에는 숨어 지내고 밤이면 뒷방으로 나오는 은둔 생활을 계속한다. 적극적 저항보다는 일신의 안위와 자유로움을 기대하는 해방 이전의 경석은 나약한 지식인의 표정을 보여준다. 하지만 해방이 되고 면 자치위원회와 보안대가 조직되면서 경석은 적극적으로 해방조국의 건설을 위해 헌신하게 된다. 그러면서 순희와의 앞날에 불길한 예감을 감지하게 된다. 경석은 순희가 정치 학교에 나오지 않자 추궁을 계속하고, 정태기와 정영익의 주도로 보안서가 습격받자 경석은 총상을 입는다. 반란이 수포로 돌아간 뒤, 경석은 순희에게 집에서 도망을 치라고 이야기하지만, 순희는 엄두를 내지 못한다.

1946년 3월 토지 개혁 법령이 내려, 태기네 밭이 거의 몰수되기에 이르고, 경석은 면 민청위원장에 당선된다. 순희에게 다시금 집을 떠날 것을 권유하지만, 순희는 어머니의 만류에 의지를 꺾게 되고, 경석은 순희가 단순히 마음과 용모가 아름다운 여자에 불과했음을 깨닫는다. 경석에게 순희는 낭만적 이상형의 여성이었던 것이다. 신흥리로 돌아온 경석은 안계숙을 보면서 첫눈에 반해 얼굴이 달아오른다. 순희와의 관계가 마무리되기도 전에 다른 여성을 자기의 시선 안에 담게 된 것이다. 이해 겨울 맹증을 교부하러 갔다가 눈보라에 휩싸인 산길을 넘는 계숙을 만나, 경석은 귀중한 벗을 얻은 것 같은 느낌에 젖어든다. 그런 일이 있은 후 허전하거나 외로운 밤이 되면 계숙과 순희 사이에서 경석은 심리적으로 갈등하게 된다. 순희는 계숙과 경석의 사이를 오해하고는 계숙에 대한 원한을 품은 채 자살을 시도한다. 그러한 순희를 보고 소름이 끼친 계숙은 마을을 떠나 군 여맹으로 간다.

2년 반이 지나고 1949년 섣달 그믐께에 남쪽에서 태기를 찾아온 영익은 ‘국군’이 북진해 들어올 날이 멀지 않았음을 이야기한다. 순희는 자살사건 이후 조병호와 혼인을 치르지만, 남편의 불신과 폭력 속에 유산을 하게 된다. 1950년이 되어 양 축사 문 개방 사건과 당원 등록부 도난 사건 이후 전쟁이 발발하자, 경석은 피가 거꾸로 솟는 느낌을 받는다.

전쟁이 나자 경옥은 군대에 자원해 나가고, 경석은 인민들의 애국심과 열성을 발휘시키고자 노력한다. 전선이 이북으로 옮아와서 격전이 지속되고, 경석은 마을 주민들을 산속으로 소개시킨다. 전선 상황이 악화되면서 경석도 빨치산이 되어 마을을 떠나며 동지들에게 용감성과 헌신성을 강조한다. 경석은 헌신적으로 투쟁하다가 태악이 등에게 붙잡혔다가 소작농인 원갑의 도움으로 가까스로 탈출에 성공한다. 순희는 남편 병호에게 살해되고, 1950년 겨울이 가고 봄이 와서 병원에 입원해 있던 경석은 동생 경옥으로부터 편지를 받는다. 지칠 줄 모르는 전투 정신을 가진 사람을 사랑하게 되었으며, 계숙과의 사이가 좋아진 것을 축하한다는 내용이다. 경석은 병문안 온 계숙과 더욱 많은 일을 할 것을 다짐하며 오월에 결혼식을 거행하는 것으로 작품은 종결된다.