Aspect Oriented Programming (AOP)

by ·0 Comment

저자: 김대곤(private @ roadtohome.com)
출처 : 한빛 네트워크. (http://network.hanbitbook.co.kr/view.php?bi_id=968)




본 기사는 Aspect Oriented Programming에 대해 간략한 소개글이다. 아직까지는 생소한 분야일 수 있겠지만, 점점 더 많이 듣게 되리라 생각된다. AOP를 설명하는데 있어서 자주 등장하는 네 개의 용어들(Aspect, Cross-cutting concern, Point-cut, Advice)를 설명함으로서 AOP가 왜 등장하게 되었으며, AOP가 제시하는 해결책에 대해 살펴볼 것이다. 먼저 “Aspect”, “Oriented”, “Programming”에서 생소한 단어는 단연 “Aspect”일 것이다. 야후 사전의 정의에 따르면, “Aspect”은 “사물의 면, 국면, 관점”으로 정의되어 있다. 소프트웨어 시스템은 여러가지 관점에서 바라볼 수 있다, 또는 여러 가지 단면을 가지고 있고 있다. 예를 들어, 자금 이체를 하는 프로그램을 작성한다고 생각해 보자. 출금계좌와 입금계좌, 그리고 이체금액을 입력받아 SQL 문장 또는 함수 한 번 돌리는 것으로 끝나는가? 절대 아니다. 먼저, 해킹을 방지하기 위해 사용자가 적절한 보안 프로그램을 설치했는지 점검하는 코드도 있어야 하고, 사용자가 인증되었는지 점검하는 코드도 써야 하고, 상대방 은행에서 적절하게 처리되었는지도 점점해야 하고, 혹시 사용자가 이체버튼을 두 번 누른 것은 아닌가 체크해야 하고, 시스템 로그도 남겨야 한다. 즉, 구현하려고 하는 기능 뿐 아니라 보안, 인증, 로그, 성능와 같은 다른 기능들도 녹아 있어야 한다. 어쩌면 이체를 위한 코드보다 잡다한 다른 측면의 문제들을 다루는 코드가 더 길어질 수 있다. 이런 코드들은 입금이나 출금 같은 다른 곳에서 들어가야 한다. 구현하려고 하는 비즈니스 기능들을 Primary(Core) Concern, 보안, 로그, 인증과 같이 시스템 전반적으로 산재된 기능들을 Cross-cutting concern이라고 부른다. AOP는 Cross-cutting concern를 어떻게 다룰 것인가에 대한 새로운 패러다임이라고 할 수 있다.

AOP는 구조적 방법론에서 객체지향 방법론으로 전환처럼 시스템 개발에 관한 전체적인 변화는 아니다. Object-Oriented Programming이 Aspect-Oriented Programming으로 대체되는 일은 없을 것이다. AOP는 구조적 방법론에도 적용될 수 있고, 다른 방법론에도 다 적용될 수 있지만, 주로 객체지향방법론이 가지는 단점을 보완하는 것으로 묘사되고 있다. 그러면 객체지향 프로그래밍이 또는 다른 이전의 프로그래밍 기법들이 Cross-cutting Concern를 어떻게 다루는지 알아보자. 매우 간단하다. Primary Concern를 구현한 프로그램에 함께 포함시켰다. 그것이 단 한 줄의 메소드 호출이라 하더라도. 많은 프로그래머들은 거의 모든 프로그램에 산재된 로그하는 단 한 줄의 코드를 찾아서 바꾸어 본 경험이 있을 것이다. 또는 간단하게 생각하고 프로그램을 수정하려고 했는데, 도데체 어디를 수정해야 되는지 모르게 코드가 길고, 알 수 없는 코드들이 자리를 차지하고 있을 때의 난감함. Primary concern, Cross-cutting concern이 하나의 프로그램 안에 들어가게 되면, 프로그램을 이해하기가 힘들고, Cross-cutting concern 코드가 여기저기에 산재되어 수정하기 힘들게 된다. 당연히 생산성 떨어지고, 품질 떨어지고, 유지보수 비용 많이 들게 된다.

그럼 AOP는 Cross-cutting concern를 어떻게 처리하는가? 이것도 매우 간단하다. 새로운 아이디어라고 할 수도 없다. Primary Concern 구현하는 코드 따로, Cross-cutting concern 구현하는 코드 따로 쓰고, 나중에 두 개 조합하게 완벽한 어플리케이션 만들겠다는 것이다. 기술 용어로 쓰면, Advice(Cross-cutting concern 구현한 코드)와 Primary concern 구현한 코드를 Point-cut 정보를 이용해서 Weaving(조합)하는 것이 AOP가 이 문제를 다루는 방법이다.



기술적 용어로서의 “Aspect”은 “Advice”와 “Point-cut”을 함께 지칭하는 단어이다. Point-cut은 어떤 Advice를 Code 어느 위치에 둘 것인가 하는 것이다. 예를 들면, 로그 기능을 구현한 Advice는 Code 속에 있는 모든 public 메소드가 수행되고 나면, 그 마지막에 실행되어라 라고 지정한 것이라 할 수 있다.

이전까지의 객체지향 프로그래밍은 Cross-cutting concern을 정적으로 어플리케이션에 결합시킨 반면 AOP는 동적으로 Cross-cutting concern를 다룬다고 표현하기도 합니다. 용어에서도 알 수 있듯이 AOP는 소프트웨어 엔지니어링 원칙 중에 하나인 “Separation of concern”를 구현하려고 하고 있습니다. 이러한 문제들을 다루고 있는 분야 중에 하나는 디자인 패턴할 수 있고, 예를 들어, Visitor 패턴은 정적인 구조를 동적으로 바꾸려고 합니다. AOP가 현재까지 나온 방법들 중에서 Cross-cutting concern를 다루는 가장 좋은 방법인가 하는 질문엔 아직 답하긴 힘들 것 같습니다. 그럼에도 분명 언제가는 책상 위에 관련 서적 한 권 있어야 할 것 같은 분야가 될 것 같습니다.

이기준 교육부총리 사건을 보며

by ·36 Comments

이기준 교육부총리 사건을 보며


57시간이란 최단수명 기록을 남기고 사퇴한 이기준씨 교육부 총리 사건을 보며 우리 사회의 가치관의 대립이 이렇게 심각한 수준이라는 것을 보게 되었다. 이런 차이가 결국은 나라를 하나되지 못하게 하여 결과적으로는 삼류 국가로 전락하게 만드는 원인이 될 수 있다. 한국전쟁 이후 민주화 운동과 경제 성장 운동을 통해서 하나의 비전과 목표를 갖고 한마음이 되었던 국민들이 이제는 진보와 보수 내지는 전통적인 가치관과 서구적인 가치관 속에서 나아갈 방향을 제대로 찾지 못하고 있는 것 같다. 노무현 대통령과 정부는 교육 개혁을 단행할 만한 능력을 갖고 있는 사람을 찾는 과정에서 이기준이라는 사람을 찾았지만 역시 적지 않은 도덕적인 결함과 문제 발생의 요지를 발견하고는 고심했던 것 같다. 그러나 정부의 이번 인사에서의 기준은 전통적인 기준 보다는 한 사람의 능력을 우선시 하는 서구적인 기준이었기 때문에 이기준씨의 도덕적인 결함에도 불구하고 인사를 단행했지만 결국은 전통적인 기준을 내세우는 시민단체들과 일반 국민들의 반발에 부딧쳐 결국은 57시간만에 실패로 돌아가고 말았다. 이는 국가적으로나 개인적으로나 큰 낭비가 아닐 수 없다. 다시는 발생하지 말아야 할 일이지만 우리 사회에 존재하는 가치관의 혼돈을 극복하지 않는 이상 이런 문제는 사회의 어느 곳에서든 계속하여 일어날 것이다.

여러 가치관 중에서 특히 최근 들어서 국민들이 원하는 지도자상은 이런 것 같다. 능력이 그다지 뛰어나지 않아도, 확고한 목적의식과 비전이 없어도 일단 도덕성에 문제가 없고 청렴한 사람이라면 일단은 지도자로 문제가 되지 않는다는 한마디로 말해 목민심서적인 지도자를 원하는 것 같다. 지난 대선때 이회창 후보가 탈락했던 가장 큰 이유중 하나도 그의 도덕적인 문제였고 역시 같은 교육부총리직에서 24일만에 사퇴했던 송자씨의 경우도 그러하다. 이런 의식은 지도자뿐만이 아니라 연예인과 같은 공인들에게도 똑같이 적용되어 군 면제 비리 사건이 터질 때마다 당사자들은 정당하게 죄값을 치름에도 불구하고 온갖 비인격적인 모독을 감당해야만 했고 어떤 가수의 경우에는 영원히 입국이 거부되는 수모를 당하기도 했다. 그 이유가 무엇인지는 솔직히 나도 알 수가 없다. 하지만 분명한 것은 이러한 가치관이 국가의 선진화에 큰 방해 요인이 된다는 것이다.

지금의 정부는 이러한 전통적인 가치관 보다는 좀더 서구적이고 개혁적인 가치를 추구하는 것 같다. 대통령 선거때의 여러가지 공약을 보거나 정부의 인사 기준을 보더라고 쉽게 알 수 있다. 특히 인사에 관련해서는 이번 이기준 교육부총리 사건을 통해서도 알 수 있듯이 ‘단점없는 사람’보다는 ‘강점있는 사람’ 중심의 인사가 자리를 잡아가고 있는 것 같다. 특정 분야에 강한 사람을 쓴다는 것은 어떤 목표를 달성하기 위해 그 목표 달성에 적합한 인물을 쓰면서 그만큼 다른 분야, 예를 들면 도덕성과 같은 부분에서 드러나는 단점이 있다면 그것을 묵인할 수도 있다는 말이 된다. 한 설교에서 들은 비슷한 경우를 들자면 남북전쟁 당시 북쪽의 링컨 대통령이 단행한 군 인사를 들 수 있다. 링컨 대통령은 남북전쟁이 발발하자 예비역에서 소집된 그랜트 대령을 장군으로 발탁하여 중용하였다. 여러 사람들은 당시 그랜트가 갖고 있던 나쁜 버릇인 술주정을 트집삼아 적절치 못한 인사였다고 주장했다. 그러자 링컨 대통령은 오히려 그랜트가 좋아하는 술을 다른 장군들에게 한상자씩 보냈다고 한다. 그들도 같은 술을 마시고 그랜트 처럼 훌륭하게 되라는 의미에서였다. 또한 1759년 캐나다 퀘벡을 점령한 영국의 울프 장군을 누군가가 국왕 조지 2세 앞에서 울프 장군을 미친 개라고 비난했다. 그의 성격의 단점을 비난했던것 같다. 그러자 국왕은 “제발, 그 울프 장군에게 다른 장군들도 한 번씩 물려서 모두 그 같은 미친 개가 되었으면 좋겠네”라고 대답했다고 한다. 손자병법에는 “장수가 능력이 있고 군왕이 그 장수의 指揮(지휘)를 제어하지 않으면 승리한다(將能而君不御者勝)”라고 기록되어 있다고 한다. 이러한 ‘강점주의 인사’는 결국 전쟁에서의 승리라는 좋은 결과로 이끌어 주는 원동력이 되었다.

하지만 어떤 가치관이 더 옳다는 결정을 내리는 것을 불가능해 보인다. 항상 시대에 따라, 문화에 따라 가치 판단의 기준은 항상 달았었고 앞으로도 그럴 것이다. 유교 사상이 팽배해있던 조선시대만 하더라도 쇄국 정책이라는 어이없는 결정이 통일된 국가 정책으로 유지되었던 시절이 불과 200년도 되지 않았다는 사실은 매우 놀랍다. 여기서 분명한 것은 그런 변화의 속도는 상당히 빠르다는 것이고 우리 국민 대다수고 옳다고 여기고 있는 이 전통적인 가치관은 하루 빨리 변화되어 정부가 갖기 시작한 발전적인 가치관과 부합되어야 한다는 것이다. 국가와 그 구성원의 가치관의 흐름이 같은 방향을 가질 때에만 우리가 갈급하는 선진국 대한민국을 만들 수 있다.

Use Hibernate and JSF with Less Coding

by ·2 Comments

이 글은 http://blog.exadel.com/?p=8 에서 가져왔습니다.
THIS ARTICLE IS COPIED FROM http://blog.exadel.com/?p=8
The copyright of the article is owned by below person. I swear to delete this when the author request to delete the article from my blog.

Author: Igor Shabalov

As you can see from the heading, I’d like to talk a bit about JSF and Hibernate. Both technologies promise us better results with less code. Perfect, this is exactly what I’m looking for. I strongly believe that less coding is better, even if it comes with a price.
To demonstrate this, I will build a realistic example that interacts with both user and database using JSF and Hibernate. Both technologies promise us a truly declarative way of coding, hiding most of the complexity under the hood. This is good, but there is also a price for this that I’ll talk about later.

Use Case

I took a simple example from a developer’s everyday life: A user views or edits a timesheet. TimeSheet is a collection of zero or more Records, usually one per day, with information about Task, Project and hours. I’d like to see and edit the entire TimeSheet (all records for the current week) in a single page.
Here are several UML Diagrams to sketch this example out.


Figure 1: Use Case Model


Figure 2: Class Diagram


Figure 3: Activity Diagram

In fact, if you get already bored going through all of this, you can download the live example application from here, get it into you favorite IDE (my favorite is Exadel Studio Pro, of course), and see what’s in it. It should work “as is” with no database required, I used HSQL’s in-memory configuration, the perfect solution for such a case. You can download example and use Eclipse menu “Import Existing Project” right from zip file. At least on my computer it works I used JDK 1.5 generics in my example, so, you will need JDK 1.5.


Figure 4: MVC unleashed

But if you bother to read more, I’ve put a little bit more theory and commentary below.

Visual Components

To implement something like this, you need a good presentation framework that supports a component-based approach. You need a rich set of standard components, but you also need a good way to create and use special components. JSF is perfect for standard components and user interface controls, but it is not set up as well for custom components. Tiles is a better technology for this, but not all JSF implementations are compatible with Tiles. In my example, I use MyFaces, a complete JSF implementation from the Apache Foundation that also works with Tiles.

Hibernate Session and Database Connection

I assume that you already know a little bit about this problem. You need to pay special attention to the moment when you obtain or free a Hibernate Session (and effectively a Database Connection) in your application. There are two major reasons for that:

A Hibernate Session has a one-to-one relation (OK, almost) to a Database Connection. When you get a Session, you effectively get a Connection. And, we are always told that a connection to database is a valuable resource that needs to be used very carefully. For example, it is not good to keep a Database Connection taken between requests.
A Hibernate Session has a special relationship with objects that are loaded by it. The Hibernate Runtime keeps track of all modifications and generates queries to synchronize the object state with the database. If you keep a persistent object somewhere, but forget about the Session, you cannot do anything with this object (ok, almost).
As a result, we were told to use the “One Session per Request” pattern. You cannot keep persistent objects between requests, you need to store primary key and load objects in every request or use the “detach/attach” technique, which is basically same thing. And, you cannot keep queries open.


Session per Session

Instead of this, what I do is use the “One Session per Session” approach. A Hibernate Session gets created when a Web Session is created, and then kept till the Web Session expires. You can either keep Database Connection or use the “disconnect/reconnect” technique. Personally, I believe, that in many cases, you can keep a Database Connection between requests. Most real business applications are intended to be used by a limited number of users.

Personally, I hate the situation where a developer loads an entire database into memory in order to save database connections. Memory is cheap, but still limited! Keep the data in the database and let database vendors worry about efficient memory use. If database vendors try to ration allowable connections, use an open source product, like MySQL.
Or, you can implement a more middle-of-the-road approach. For example, keep the Database Connection opened when you have something like an opened scrollable query on hand, but otherwise use the “disconnect/reconnect” technique.
In the end, the result is clear code, less code overhead, more effective memory use, and fewer database round-trips.
But, everything has a price. In our case, we need to pay special attention to the Hibernate Session Cache. In our case, if somebody loads TimeSheet from user A into memory, then for user B and then repeats that for 10,000 more users, we get into trouble. At any given moment, we will see just one TimeSheet, the current one kept in Web Session, but the Hibernate Session will have all 10,000 of them. This is wrong.

Here is where Business Transaction becomes our good friend! All we need to do is remove TimeSheet from Hibernate Session either on entering or on leaving Business Transaction. In my example, I’m doing this on entrance, using a session.evict() call. This is why we need Business Transaction and why Page Flow is so important, because Page Flow naturally defines transaction boundaries.

Business Transactions

If you take a look to Activity Diagram, you will see Business Transaction. The User can navigate between “View” and “Edit” forms working with the same data, TimeSheet, which is essentially the Business Transaction Context. This Context is properly initialized at the beginning of the transaction; however, we need to pays some special consideration to the end.

Page Flow

Turning to the Page Flow, I have to admit JSF Page Flow is still “under construction”. I have a dream to eventually present you with the completed Page Flow the JSF gurus will deliver. They were talking about integration with Spring Web Flow, so perhaps I will finally be able to see the point of using Spring!

However, JSF Page Flow does exist now. The default implementation is good enough, and I’m using it in my example. Here is a picture of how it looks:


Figure 5: JSF Page Flow

No Transport Beans, Please

In one my previous projects, I suffered through a painful experience with Transport Objects. I will never ever do that again. I recommend using your persistent Model objects anywhere in screens, and let Hibernate unleash its full power. Keep your Presentation Tier close to the Service and Data Tiers. By close, I mean within the same JVM. If you need to expose some of your services (and data) to the outside world, then use the special Services Externalization interface, basically a wrapper around existing services. From this point, you can use Transport Beans, XML, or whatever you want to move data.

Front Controller, Back Controller

I used Front Controller in my example. It’s very natural for JSF, because it is intended for use with backing beans to implement view-related functions. You can put it anywhere, but I suggest you to keep it separated from “real” controller (Business Service) functions.


Figure 6: Front Controller, Back Controller

Here is a more complicated illustration to show how this works. You can see all this implemented in my example. The Form uses a JSF DataTable component and needs a special DataTableModel. It just display objects from the Model Tier, TimeSheetRecrd. TimeSheetView (it is actually a Front Controller, despite it’s name!) holds all the view-related functions, like saveTimeSheetButton(). TimeSheetService is a typical Business Service implementation, with functions like saveTimeSheet().


Conclusion

I hope you found my example helpful. I didn’t try to make a full blueprint; I just tried to highlight some important issues. And, this isn’t the end at all. I will continue my series of articles about JSF and Hibernate. This time, I didn’t pay too much attention to Database Connection. This is an area that I will revisit soon, when I plan on talking about “scrollable” queries.
Finally, as you can see, my example continues to use the “Injection of Control” pattern that I discussed last time!

Best regards,
Igor Shabalov

2004년 오늘~!!

by ·0 Comment

1년전 오늘…
2004년 8월 4일에는 호주 Fraser섬에 있었음..^^
Fraser섬은 세계에서 가장 큰 모래섬이고.. 도로는 없고 해변의 단단한 모래밭이 도로 역할을 한다… 법적으로 4×4만 통행이 가능함..




직접 4륜구동 트럭을 몰고 백사장을 달리는 기분~





이 섬에서 가장 높은 지점에서…

한국인의 엽기 술문화‘깬다 깨’

by ·0 Comment

장면 1 서울중앙지법의 ㄱ판사(40)는 10여년 전 신촌의 한 고깃집에서 겪은 일을 떠올리면 소름이 돋는다. 가까운 판·검사, 변호사 등 법조인 선·후배를 만난 자리였다. 퇴근이 늦어지는 바람에 30분 가량 늦은 ㄱ판사는 ‘후래자삼배(後來者三盃)’, 즉 늦게 온 벌로 3잔을 연거푸 마시게 됐다. 문제는 주종이 소주가 아니란 점이다. 소주를 뇌관으로 하고 맥주를 채운 소맥폭탄주였던 것이다. 술이 약하지만 ㄱ판사는 먹지 않을 수가 없었다. 최연장자였던 당시 서울지검 ㅂ검사(45)의 강력한 권유(?) 때문이었다. 말이 권유지, 거역할 수 없는 분위기였다. 계속해서 3잔을 들이킨 ㄱ판사는 그만 고기판에 방금 먹은 고기를 토한 후 의식을 잃었다. 몇분 후 깨어난 ㄱ판사는 정신이 오락가락하는 와중에 고기원형이 그대로 보존된 고기판에 있는 구토물을 잘 구워진 고기인 줄 알고 집어먹었다. 그 장면을 본 옆 자리 선·후배들은 입을 틀어막고 화장실로 직행했다. 의식 불명이던 ㄱ판사는 나중에 참석자들로부터 이 사건을 전해듣고 두고두고 잊지를 못한다.
장면 2 벤처기업의 ㅇ사장(39)은 최근 동문 선·후배들과 술자리를 하며 20여 년 전 신입생 MT를 화제에 올리며 미소를 지었다. 당시 MT를 주도했던 선배가 소주 한 병을 국그릇에 따라 ‘원샷’하게 했는데, 자신에게만은 두 병을 ‘원샷’하게 한 것. 나중에 이유를 물었더니, 술이 셀 것 같아서 일부러 그랬다는 대답이었다. 그 정도로 ㅇ사장은 ‘한술’ 하는 편이다. 지금에야 추억으로 남아 웃을 수 있었지만, 소주 두 병을 원샷한 ㅇ사장은 여기서 그치지 않고 계속되는 ‘술고문’으로 꽤 괴로운 신입생 MT를 경험했다. 업무상 술 자리가 많았던 ㅇ사장은 또 희한한 폭탄주를 이날 동문 선·후배들에게 공개했다. ‘혈맹주’란 것이었다. 몇 년 전 한 정부기관의 선배로부터 배운 것인데, 우선 맥주와 양주를 큰 그릇에 부은 뒤 약지를 바늘로 따서 모든 참석자의 피를 이 폭탄주에 섞은 후 맥주잔에 따라 돌리는 것이다. 혈맹주는 피를 나눈다는 의미가 있다. 그만큼 가까움을 표시하는 것이다. 참석자들은 눈을 질끈 감고 이를 먹었다.
한국의 술문화는 세계에서 별로 유례를 찾기 힘들다. 아무 곳에서나 술을 살 수 있고, 아무 때나, 아무 데서나 술을 마실 수 있다. 맘껏 취할 수 있고, 술 때문에 저지른 실수는 적당히 양해가 된다. 술에 관한 한 지상천국인 셈이다. 그리고 폭탄주를 즐겨 마신다. 그것도 값비싼 위스키를 뇌관으로 이용한다. 하루 저녁에 폭탄주나 스트레이트로 위스키를 한 병 이상 마시는 것을 보면 외국인들은 입을 다물지 못한다. 이들은 언더록이나 스트레이트로 한 잔을 마시는 것이 고작이기 때문이다. 스코틀랜드 위스키의 본고장인 스코틀랜드에서조차 위스키를 마셔도 6년산 이하를 가장 많이 마신다. 12년산 이상이면 프리미엄급으로 분류돼 가격도 비싸고 특별한 날에만 마신다고 한다. 그러나 우리나라에선 12년산 위스키를 싸구려 취급한다. 17년산이나 21년산은 돼야 고급으로 인정한다. 그것도 맛을 전혀 음미할 수 없는 폭탄주로 만들어 마신다.
12년산 위스키 싸구려 취급하는 한국인
우리나라 술문화의 키워드는 공음(共飮)이다. 다함께 마시는 것이다. 술잔을 돌리는 것에 잘 나타나 있다. 왜 우리나라는 이러한 술문화가 발달했을까. 우리나라는 단일 민족으로 서로 신뢰하고 하나 됨을 강조해왔다. 하지만 마음이란 보이지도 않고 잡히지도 않는다. 이러한 마음을 주고받을 때 어떤 형태로든 그 무와 유를 보고 싶어한다. 술박물관 리쿼리움(www.liquorium.com)의 조삼현 부관장은 “그러한 정신이 술을 마실 때 술잔을 돌려가며 더불어 마시는 형태로 나타난 것”이라고 해석했다. 이렇게 일심동체를 다지는 공음은 살아 있는 사람뿐 아니라 신이나 죽고 없는 조상신에게도 마찬가지다. 제사 때 올린 음식과 술을 나누어 먹는 음복 절차가 바로 조상과 후손을 잇는 결속 행위인 것이다. 우리나라처럼 술잔을 주고받으며 마시는 음주 문화를 ‘수작문화’라고 하며, 미국 등 제 잔에 제 술을 따라 마시는 문화를 ‘자작문화’라고 한다. 중국이나 러시아처럼 잔을 맛 대고 마시는 것을 ‘대작문화’라고 한다.
폭탄주도 공음의 한 단면이다. 잔을 돌려가며 마시는 것에서 잘 드러난다. 맥주잔에 위스키를 채운 쇼트글라스(30㎖ 정도의 작은 잔)를 넣고 그 위에 맥주를 부어 한 번에 마시는 폭탄주는 1980년대 중반 위스키가 접대주로 자리를 잡으면서 유행했다. 한국이 원조처럼 돼 있지만 한국에서 처음 만든 술은 아니다. 미국의 동부 부두 노동자들이 맥주에 위스키를 섞어서 마시는 ‘보일러 메이커(boiler maker)’에서 유래했다. 보일러 메이커는 ‘온몸을 취기로 끓게 하는 술’이라는 뜻이다.
어려서부터 술에 대한 올바른 교육 필요
이렇게 공음을 하다보니 ‘장면1’ ‘장면2’와 같은 ‘엽기적인 사건’이 흔하게 발생한다. 그러나 이런 것은 우리나라 전통 술문화가 아니다. 우리나라 전통 술문화는 철저하게 예절을 중시한다. 특히 어른을 모시고 술을 마실 때는 행동을 삼가는데 먼저 어른에게 술잔을 올리고 어른이 술잔을 주면 두 손으로 받는다. 또 어른이 마신 뒤에 비로소 잔을 비우며, 어른 앞에서 술을 마실 수 없어 돌아앉거나 상체를 뒤로 돌려 마시기도 한다. 술잔을 어른께 드리고 술을 따를 때 도포의 도련이 음식물에 닿을까봐 왼손으로 소매를 쥐고 오른 손으로 따르는 풍속이 생겼다. 이런 예법은 현대에 이르러 소매가 넓지 않은 양복을 입고 살면서도 왼손을 오른팔 아래에 대고 술을 따르는 풍습으로 남아 있다. 물론 군음(群飮)도 있었다. 군음은 형식과 절차에 구애받지 않고 거리낌 없이 즐기는 자유롭고 호탕한 자리였다. 군음은 현재의 술문화와 비슷한 면이 있다.
고주망태에 대한 반발로 최근 우리 전통 음주예절인 ‘향음주례‘에 대한 관심이 높아지고 있다. 향음주례란 성균관이나 전국의 향교에서 행하던 일종의 주도(酒道)예절이다. 여기서 공경지심(恭敬之心), 손을 씻고 잔을 씻어 상대방에게 권하는 청결지심(淸潔之心), 일미동심(一味同心)의 공동체 의식, 적절한 양으로 끝낼 줄 아는 절제의 사양지심(辭讓之心)을 가르쳤다. 물론 일부는 아직도 남아 있다.
술박물관인 리쿼리움에서는 중고생이나 대학생을 대상으로 향음주례를 가르치는 프로그램을 개설할 예정이다. 일찍부터 주도를 가르쳐 술문화를 개선해보자는 것이다. 조삼현 부관장은 “향음주례가 이어지려면 어려서부터 술에 대한 올바른 교육이 필요하다”면서 “학생들을 위한 체험학습 프로그램를 9월에 선보일 예정”이라고 말했다.

——————————————————————————–

세계인의 술문화
미국- 미국의 음주문화는 함께 어울려 마시더라도 서로 잔을 권하거나 2차를 가는 일이 거의 없으며 취해서 비틀거릴 정도로 마시는 사람도 찾아보기 힘들다. 단지 자기가 마시고 싶은 양의 술을 마시고 특정인이 사겠다고 말하지 않는 한 술값은 각자 계산한다.
영국- 영국은 지역별로 선호하는 주종도 다르고 음주량과 음주문제에 많은 차이를 보인다. 1982년 웨일스에서는 일요일에 술을 팔지 못하게 했으며 1976년까지 스코틀랜드의 술집들은 잉글랜드나 웨일스보다 문을 일찍 닫았다. 스코틀랜드 사람들이 가장 좋아하는 술은 위스키이며, 북아일랜드 사람들은 상대적으로 술을 덜 마신다. 맥주나 칵테일은 일상적이지만 위스키는 거의 마시지 않는다. 비싸서다.
일본- 술잔을 돌리거나 술 마시기를 강요하는 행태는 거의 찾아볼 수 없다. 각자 자기가 즐기고 술을 시켜 주량만큼만 마신다. 같이 온 일행이 각각 다른 종류의 술을 놓고 마시는 광경도 쉽게 볼 수 있다. 그러면서 상대방이 조금 마시고 아직 바닥이 드러나지 않은 술잔에 상대방이 시킨 술을 따라서 가득 채운다. 이른바 첨잔 방식이 일본식 주법이다. 술값은 ‘와리깡’이라고 해서 일행이 똑같이 나눠 내거나 자기가 마신 술값만 치르는 것이 보통이다.
독일- 독일인은 술을 마실 때 술잔을 돌리는 법도 없으며 다른 사람에게 술을 따라주고 권하는 경우도 거의 없다. 또 술 한 잔을 안주 없이 30분 넘게 마신다. 취하기 위해서가 아니라 주로 분위기를 즐기기 위해서 술을 마신다. 더치페이가 관례여서 남에게 술을 강요하고 싶으면 자기가 술을 사야 한다.
러시아- 많이 마실 뿐 아니라 술잔을 기울인 뒤에야 비로소 친해지는 한국의 음주스타일과 가장 비슷하다. 러시아인은 보드카를 제일 좋아하며 코냑이나 위스키 같은 유럽 스타일의 술은 고상한 자리에서나 마신다. 혼자 마시는 경우는 거의 없다. 폭주스타일로 전체 잔을 한번에 채워 한꺼번에 마신다.
중국- 중국에서는 술잔을 돌리지 않는다. 각자 자기 잔에 술이 가득 부어지면 잔을 들어 ‘건배(깜뻬이)’를 하고, 또 술을 마신 뒤에도 잔은 자기 앞에 놓는다. 마신 뒤에 ‘깜뻬이’하면서 빈 잔을 보여준다. 상대편이 술잔을 비울 때까지 기다려 주며 극성도 부리지 않는다. 술을 강제로 권하지도 않으며, 취한 사람은 재워 보내는 미풍도 있다.
프랑스- 프랑스는 주로 식사와 함께 반주로 포도주를 마시며 주인은 손님에게, 남성은 여성에게 제때 알아서 잔을 채워준다. 식사가 끝나면 코냑이나 칼바도스 등 알코올농도가 높은 술을 한잔 마셔 입가심을 한다.
<조완제 기자 jwj@kyunghyang.com>

[펌] SW 거장들이 국내 개발자들에게 던지는 충고

by ·1 Comment

이 글은 아래 URL에서 copy-paste하였습니다.
http://www.it-solutions.co.kr/news/news_view.asp?code=03&news_id=696





SW 거장들이 국내 개발자들에게 던지는 충고
“언어·자격증 갖춰 해외 시장으로 눈 돌려라” 2004/11/30

영어 실력, 국제 공인 자격증, 전문성 갖춰 세계 시장으로 무대를 옮겨라. 세계적인 소프트웨어 거장 이바 야콥슨 박사와 오라클 교육담당 존 홀 수석부사장이 국내 소프트웨어 개발자에게 이같은 충고를 전했다. 이 두 거장은 최근 시점을 달리해 방한했지만 전하는 메시지에는 공통점들이 많았다.
우선 야콥슨 박사와 홀 수석부사장이 공통으로 국내 개발자들의 취약점으로 지적한 것은 ‘언어’문제였다. 새로운 기술 서적이 나와도 번역되기를 기다려야 하기 때문에 영어권 나라의 개발자보다 정보습득이 늦고 영어로 의사소통하는 것이 원활하지 못하다는 것이다.

최근 방한한 이 두 소프트웨어 거장들은 국내의 IT개발자 교육에 주력할 계획이다. 특히 야콥슨 박사는 국내에 자신의 이름을 딴 이바야콥슨컨설팅(IJC)코리아를 설립, 개발자 교육을 시작했다. 존 홀 수석부사장은 OCM이라는 기존 OCP보다는 상위 수준을 측정하는 자격증을 소개하면서 한국오라클유니버시티(OEU)의 영업 인력을 2배로 늘이는 등 교육사업을 강화하겠다고 발표했다.
존 홀 오라클 수석부사장은 국내 개발자들에게 “영어 실력을 쌓고 자신의 능력을 입증할만한 자격증을 획득하라”고 충고했다. 홀 수석부사장은 “OCM을 취득한 인도인들이 미국에서 취업한 사례가 많은데 이는 영어로 의사소통이 가능했기 때문”이라고 덧붙였다. 한국과 일본 개발자들의 여건은 비슷한데 이 두 나라의 해외 진출이 저조한 이유 역시 언어문제인 것으로 풀이했다.
개발자들이 자산의 정보를 업그레이드하고 신기술을 계속 습득하는 것은 교육을 통해서 가능해진다. 대부분의 소프트웨어가 외산이기 때문에 외국 기술을 더 빨리, 정확하게 얻고자 한다면 영어 실력을 향상할 수밖에 없을 것이다.

이바 야콥슨 박사가 다른 나라보다 한국에 가장 먼저 IJC 지사를 설립한 이유에 대해 ‘사업 기회가 있기 때문’이라고 밝혔다. 국내 개발자들을 유럽이나 미국 수준으로 향상시키기 위해 교육이 필요한데 교육에 대한 수요가 많을 것으로 판단했던 것이다. IJC는 올 8월부터 한 과정에 1주일씩, 총 4개 과정으로 이뤄지는 교육 프로그램을 가동했다. IJC는 앞으로 100명의 개발자를 교육할 것을 목표로 하고 있다.

한국오라클은 OEU를 통해 최소 3일에서 5일 등 다양한 교육프로그램을 실시하며 교육에 대한 만족도도 핵심기술이 92%, e-비즈니스 스위트가 93%로 높은 것으로 나타났다. OCM을 취득한 사람은 전세계에 161명이 있으며 이 자격증은 상위 1%에게 주는 것으로 2일 동안 모든 상황에 대해 개발자가 빨리 대처하는 능력을 검증하게 된다. 국내에는 한국오라클 직원 7명을 포함해 총 27명이 최근 OCM을 취득했다.

외국 업체들이 국내 개발자 교육에 대한 관심을 가지는 이유는 국내 IT시장에 비해 수준 높은 개발자들이 적다고 판단했기 때문이다. 한국 IT시장이 계속 성장하고 발전하려면 개발자들의 실력이 향상돼야 하며 이를 위해서는 교육이 중요하다는 것이다. IJC코리아와 한국오라클의 경우 매출에서 교육부분이 차지하는 비중은 컨설팅, 소프트웨어 등 다른 분야보다 작지만 사전 영업으로서 중요한 역할을 하기도 한다.
IJC코리아는 우선 내부 인력들부터 양질의 교육을 받게 한 후 이들이 자사의 고객과 협력사들에게 교육을 전달하도록 한다. 한국오라클은 사용자에게 자사의 제품을 검토할 수 있도록 하고 이를 소프트웨어 판매로 이어간다는 전략이다.

박해정 기자 hjpark@it-solutions.co.kr

한 SW기업의 의미있는 자정선언

by ·0 Comment

우리 회사 (주)네트빌이 신문에 났습니다. 얼마전 소프트웨어 불법 사용이 적발되어 한차레 곤욕을 치른 계기로 전 직원이 정품 사용을 서약했는데… 현재 비교적 잘 지켜지고 있는 것 같습니다…^^ 기사에 난 사진은 어제 찍은 사진인데… 그날 이상하게 사장님이 디카 있는 사람을 애타게 찾으셨어요.. 제가 마침 디카가 있었는데 급하게 사진을 보내야 한다고 하셔서 다른 사람 디카로… (SD 메모리 리더기는 회사에 없어서…) 음.. 근데 사진이 이렇게 신문에 날 줄이야…. 전 이 사진 찍을때 제 자리에서 열심히 일하고 있었나봅니다… 아니면 화장실에 갔었거나…-_-;;

“정품SW만 사용하겠다”…한 SW기업의 의미있는 자정선언

<아이뉴스24> 소프트웨어를 개발해 이를 팔아 먹고 사는 기업들도 사실 남몰래 SW를 불법복제한다. 남의 소프트웨어는 불법복제해 쓰면서, 자신들이 개발한 SW는 지적재산권을 강조한다. 이런 이중적 행태에 대해 스스로 반성하고 자발적인 자정선언을 한 기업이 있어 눈길을 끈다. e비즈니스 솔루션 개발업체인 네트빌(대표 문기헌, www.netville.co.kr)은 12일 스스로 정품SW 사용기업임을 선언하고 앞으로도 정품 소프트웨어 사용을 자율적으로 이행해 나가겠다는 조촐한 결의대회를 가졌다. 결의대회에서 네트빌 전직원은 정품SW 사용에 대한 서약을 했으며 자율적으로 약속을 이행할 것을 다짐했다. 문기헌 네트빌 사장은 “SW산업에 종사하는 한 사람으로서 SW인들이 먼저 자발적이고, 자율적인 정품사용에 앞장서는 것이 바람직하다고 판단했다”고 결의대회 배경을 설명했다. 문 사장은 “우리도 SW를 불법복제해 사용하다 곤욕을 치른 적이 있다. 그러나 그것때문에 이같은 자정 결의대회를 한 것은 아니다”며 “단속과 처벌위주의 방식에는 명확히 반대하는 입장이다. 이는 장기적으로 SW인들에 대한 잘못된 인식을 만들게 되어 SW산업의 발전에 또 다른 장애요인을 만들 수 있는 면이 있다”고 말했다. 그러면서 “자발적인 정품SW 사용선언을 통해 자율에 의한 정품SW 사용문화를 SW인이 스스로 만들어 갈 때, SW산업의 발전을 견인해 나갈 수 있을 것”이라며 “이러한 문화조성을 위해 SW기업들이 먼저나서 자율적 문화를 만들어 나가는 계기가 되길 바란다”고 밝혔다. 네트빌은 이번 결의대회를 계기로 사내 인트라넷에 정품SW 사용내역을 파악할 수 있는 시스템을 구축했으며, 전직원의 자발적 참여에 맡겨 운영해 나갈 계획이다. ‘작은 기업의 작은 선언’이 어떤 반향을 불러올 지 주목된다. /김상범기자 ssanba@inews24.com IT는 아이뉴스24, 연예스포츠는 조이뉴스24 (Copyright ⓒ 아이뉴스24. 무단전재 및 재배포 금지) 기사 출처는: http://news.media.daum.net/digital/computer/200507/12/inews24/v9569173.html