'분류 전체보기'에 해당되는 글 1246건

출처 : 이선우 과장님.

.NET 응용 프로그램에 app.config 라는 설정을 넣는 부분이 있다.(ASP.NET의 web.config과 유사). 응용 프로그램이 최초 실행될때 기본적으로 설정할 때 사용되는 값들인데, 이 부분을 직접 Text로 열어 편집하곤 했다.

이 부분을 직접 편집하는 것도 방법이겠지만, Resource 편집하듯 설정하는 방법이 있다.
솔루션 목록에서 윈도우 응용 프로그램 프로젝트 위에서 속성을 클릭하면 응용 프로그램 속성창이 뜨는데,
그 중 Settings 탭에 위치한 항목이 바로 그것이다.

그런데 저 Type을 보면 알겠지만, .NET에서 제공되는 형만 존재한다.
만일 enum 형태로 사용자가 만든 별도의 형이 있다면? 그것을 사용하는 방법이 있다면?

바로 그것이다.예를 들어보자.만일 다음과 같은 enum이 존재한다면..

TestType 이라는 형태로 저 Settings에 표현하려면??

물론 위와 같은 TestType을 먼저 선언한다.
그리고 난 뒤, 아까 Settings 에 들어가도록 한다. 그리고 Type 부분의 콤보 박스를 클릭한다.

클릭하게 되면 여기서 사용가능한 Type들이 나열된다. 그러나 우리가 원하는 Type은 없다.
이제 맨 아래쪽에 있는 Browse... 를 선택하도록 한다.
이제 Select a Type 이라는 항목을 볼 수 있다. 여기서 아까 선언했던 enum을 찾도록 한다.

찾았으면 선택한 뒤 OK를 클릭한다.

그리고 원하는 값을 선택한 뒤, 저장한다.

자! 그런데 여기서 문제 그 하나.

먼저 위에서 처럼 enum을 선언했는데, browse를 해도 그 enum을 찾을 수 없는 경우.
이 부분 때문에 이선우 과장님이 이리저리 헤매다가 그 차이점을 밝혔다.
즉 저 enum 선언은 반드시 app.config에 걸리는 응용 프로그램 외에 설정해야 된다는 것이다.
다시 말해 만일 app.config가 TestApp 라는 응용 프로그램에 존재한다면, Class Library 프로젝트를 별도로 만들어
그 안에서 선언해야 된다는 것이다.

지금 필자가 구현한 코드 부분을 예로 든다면, 실제 실행되는 응용 프로그램이 TwainGui. 즉 app.config는 저 안에 있다. 하지만, enum은 별도의 Class Library 프로젝트인 TwainLib 라는 위치에 있다. 그것을 선언한 것.

저렇게 만들어 컴파일이 정상적으로 된다면, TwainGui에서 참조를 걸어 놓으면 위의 예제처럼 Browse 할 때 저 enum을 볼 수 있다.

이걸로 땡일까? 부부~ 이제 그 문제 2.

사용자 정의된 이 특수한 Type에 대한 안의 값을 선택하는 콤보 부분을 주목하자.
 
아주 자연스럽게 나타나는데, 실제로 그럴까?

10이면 10, 100이면 100 대부분 아래와 같이 Type 목록으로 나오지 않고, 달랑 한개의 값만 표시된다.

실제로 그 안의 값을 열어보면, 마치 빈 TextBox 마냥 직접 사람이 입력하게 만든다.
말이 쉽지 실제로 그 값들이 기묘한 문자열이라면 찾기 무리.
처리 방법은 매우 간단하다. 일단 위의 값을 그대로 저장한 상태로 컴파일을 완료한다.
그리고 Visual Studio을 껏다가 다시켠다. 그리고 프로젝트 Reload.

즉 프로젝트를 Reload 함으로써 Reset이 되어야 올바른 값 목록이 나온다는 것이다.

일단 여기까지!

.NET Application에서 외부 이벤트를 끌어들이는 방법을 설명하고자 한다.

사실 Windows Event에서는 Managed 환경에서 제공되는 한정된 이벤트 처리를 의외로 간단하다. 하지만, Win32 기반의 외부 응용 프로그램에서 제공되는 커스텀 이벤트 처리에 대해서는 어찌되어야 할지 명확히 알지 못하는 경우가 많다. 이 부분을 언급하려고 한다.

먼저 .NET의 응용 프로그램은 Application 이라는 개체를 자체적으로 가지고 있게 된다. Static 기반으로 되어 있어, From을 띄우거나, 메시지를 가져오고 메시지를 보내는 등 어떻게 보면 OS 처럼 최하위단을 제어하고 움직이는 중요한 부분이다. 바로 이 부분을 활용하여 외부의 이벤트를 끌어오는 것이다.

이 작업을 수행하려면, 외부 이벤트를 수신하는 Windows 개체에 IMessageFilter 라는 인터페이스가 필요하다.
이 인터페이스는 System.Windows.Forms 라는 네임스페이스 상에 존재한다.

제일 먼저 이 인터페이스를 상속 받게 한다.

그 다음은 해당 Windows 소스 내에 IMessageFilter 에 대한 구현을 구성한다.

즉 저 PerFilterMessage 라는 부분에서 실제적인 처리를 시도하게 된다.

Message 객체는 다음과 같이 구성되어 있다.

• HWnd : 윈도우 Handle 주소값.
• Msg : Windows 기반 메시지 ID
• WParam : Windows 메시지와 같이 나온 값 - Word (unsigned int) 단위의 값
• LParam : Windows 메시지와 같이 나온 값 - Long (unsinged Long) 단위의 값

Windows API 프로그래밍을 해본적이 있다면 바로 직감이 오겠지만...
바로 저 PerFilterMessage가 PumpMessage를 의미하는 것이고,
Message 객체는 Windows 메시지로 처리할 때 쓰는 모든 값이다.

이제 필요한 메시지를 직접적으로 처리해 주면 되는 것이다.

.NET을 이용해서 C++/C 로 만든 Windows DLL들을 호출하는 방법이 있다.

그 방법은 DllImport 라고 하는 System.Runtime.InteropServices 네임스페이스의 프로퍼티 클래스를 사용하면된다.

간단한 사용예는 아래와 같다.

[DllImport("twainDSM.dll")]
private static extern TwRC DSMSetParent( [In, Out] TwIdentity origin, IntPtr zeroptr, TwDG dg, TwDAT dat, TwMSG msg, ref IntPtr refptr );

DllImport 에 원하는 DLL을 선언하고, static extern 메소드에 걸어주면 된다.
만일 입출력이 겸해지는 파라미터 인 경우 [In,Out] 을 사용하면 되고, 입력이면 그대로 [in]을 쓰면 된다.

그런데, 하나의 DLL 함수에 여러가지 형태로 정의하고 싶은 경우가 있다.
입력값이 미묘하게 틀린경우 그에 맞추기만 하면 되는 경우다.

예를 들면 TWAIN에서 제공하는 DLL 함수 중 DSM_Entry 라는 함수가 있다.

TW_UINT16 FAR PASCAL DSM_Entry( pTW_IDENTITY pOrigin,
                                  pTW_IDENTITY pDest,
                                  uint    DG,
                                  uint    DAT,
                                  uint    MSG,
                                 (void**)    pData);

그 형태는 위와 같다. 즉 첫번째 두번째 파라미터는 규격화 된 것이지만, 맨 마지막 같은 경우에는 특정한 형태가 없는 값이다. 또, 두번째 파라미터가 null 인 경우도 있을 것이다. 호출하는 방법에 따라 그 방법이 다양한데, 이것을 C#에서는 아래와 같이 표현 할 수 있다.

[DllImport("twainDSM.dll", EntryPoint="#1")]
private static extern TwRC DSM_Entry1( [In, Out] TwIdentity origin, IntPtr zeroptr, TwDG dg, TwDAT dat, TwMSG msg, ref IntPtr refptr );

[DllImport("twainDSM.dll", EntryPoint="#1")]
private static extern TwRC DSM_Entry2( [In, Out] TwIdentity origin, IntPtr zeroptr, TwDG dg, TwDAT dat, TwMSG msg, [In, Out] TwIdentity idds );

[DllImport("twainDSM.dll", EntryPoint="#1")]
private static extern TwRC DSM_Entry3( [In, Out] TwIdentity origin, IntPtr zeroptr, TwDG dg, TwDAT dat, TwMSG msg, [In, Out] TwStatus dsmstat );

위의 첫번째 예에서 달라진 것은 EntryPoint를 명시한 것이다. 즉 DLL에서 제공하는 첫번째 메소드를 쓴다는 것이다. 함수 이름이야 뭐가 되든간에, 무조건 DLL에서 제공하는 첫번째 함수를 쓴다는 것이다. 파라미터도 최대한 DSM_Entry의 함수를 그대로 따르되, 두번째 파라미터가 Null 이라면 zeroptr에 IntPtr.Zero를 넣는 것이다. 그리고 맨 마지막 파라미터 같이 다양한 형태로 때려 박는 스타일일때는 그에 필요한 형을 그대로 집어넣는다. 그러면 .NET에서 DLL 함수와 연결할때, 알아서 해당 부분을 (void **)로써 제공할 뿐이라는 것이다. 다른 것들도 마찬가지로, 각 변수들의 크기만 잘 맞출 수 있다면 ( int 면 4바이트, short 이면 2바이트 등등) 그게 무슨 값이든 상관 없이 적용할 수 있다는 것이다.

Unmanaged .NET은 하면 할 수록 나름 매력이 솔솔 풍기는 기분이다.

지금 Scanner 의 동작을 위해 해당 기능을 탑재한 응용 프로그램들을 테스트 처럼 돌려보는데,
매번 오류가 발생했다. 뭘 설치하면, 뭐가 등록이 안된다는 둥, 무슨 기능이 동작하지 않는 다는 둥, 말도 많고 탈도 많았다. 이런 저런 오류를 찾아는 보지는 찾지 못했다.
그러다가 옆자리 분께 문의하니 간단하게 해결되었다.

Windows 2008을 처음에 쓰다 보면, 이상하게 일반 App 레벨의 프로그램들이 제대로 동작하지 않음을 쉽게 느낄 수 있다. 뭔가 많이 막힌듯 하면서도, 기묘하게 동작이 안되는….
Windows XP 이나 Vista 혹은 7에서 심지어는 Windows 2003에서도 제대로 돌던게,
이상하게 Windows 2008에서는 안도는 문제.

이 문제의 모든 핵은 Windows의 기능 중 하나인 Desktop Experience(데스크톱 경험) 이라는 기능 부재로 발생되는 현상이다. 예전에 바탕화면 꾸미는 작업이나, 간단하게 폴더의 Thumbnail 기능 등등, 이 모든 기능들이 바로 여기에 포함되어 있다. 즉 이 Desktop Experience 기능만 활성화 시켜준다면,
최소한 Windows 2008 에서도 일반 데스크톱처럼 대충이나마 사용이 가능하다.

.NET 2.0 부터 제공되는 Generic 형 Class. System.Collection.Generic 이라는 네임스페이스에 존재하는 내용이다. Collection에서는 모든 값들을 Object를 사용하기 때문에 매번 Casting 을 해야 했고, 그에 따른 성능상 문제로 인해 대안점 처럼 꺼내든 것이다. 뭐 Generic의 역사나 기타 방향성문제는 다른 문서들을 참고하시고..

여기서는 generic에 있는 각 형태에서 제공하는 find라는 함수를 이용하는 방법을 언급하려 한다. 물론 foreach와 같은 순환문을 이용해서 직접 find 함수를 구현할 수 있지만, 최소한 내부에 구현된 find 함수의 성능이 그나마 내가 직접 짠 것 보다는 좋을 것이라는 생각에 최대한 애용하는 편이다.

이 find 함수의 기본 형은 아래와 같다.

public T Find (
	Predicate<t> match
)

위의 형태에 대한 정의 내용을 보면 Predicate<T> 라는 게 있는데, 바로 이 부분에 대리자 역할을 하는 함수가 필요로 한다. match 라는 의미는 자신이 찾는 값의 형태인 경우에는 true 혹은 false를 돌려달라는 의미다.

여기서 개인적으로 가진 의문은 왜 find를 저렇게 구현했을까 했던 점이다. 만일 List<int> aaa 라는 개체를 만들었다면, aaa.find(1111) 식으로 aaa.find(<T>) 형태로 제공되었으면 그냥 썼을텐데, 저런식으로 만드니 원 접근이 될 터인가.. 했다. 하지만, 정작 <T> 안의 값의 형태가 복합형이고, 그 안에 찾는 조건이 복잡한 경우라면 오히려 위의 방법은 좋은 대안 식이라고나 할까?

일단 MSDN에서 제공되는 예제를 먼저 보자.

using System;
using System.Collections.Generic;

public class Example
{
    public static void Main()
    {
        List<string> dinosaurs = new List<string>();

        dinosaurs.Add("Compsognathus");
        dinosaurs.Add("Amargasaurus");
        dinosaurs.Add("Oviraptor");
        dinosaurs.Add("Velociraptor");
        dinosaurs.Add("Deinonychus");
        dinosaurs.Add("Dilophosaurus");
        dinosaurs.Add("Gallimimus");
        dinosaurs.Add("Triceratops");

        Console.WriteLine("\nFind(EndsWithSaurus): {0}", 
            dinosaurs.Find(EndsWithSaurus));
    }

    // Search predicate returns true if a string ends in "saurus".
    private static bool EndsWithSaurus(String s)
    {
        if ((s.Length > 5) && 
            (s.Substring(s.Length - 6).ToLower() == "saurus"))
        {
            return true;
        }
        else
        {
            return false;
        }
    }
}

끝의 글자가 saurus 로 끝나는 명칭을 찾는 로직. 저기서 보면 Find 안에 특정 값이 들어간게 아니고, 특정 함수가 들어가 있다. 즉 값의 결과가 true/false로 떨어지는 독자적인 함수가 있으면 된다.  위의 예제는 바로 List에 담긴 내용들 중 맨 끝의 글자가 saurus가 들어 있는지 체크한 뒤 있으면 true, 없으면 false로 돌려준다.

대충 이해가 되려나 싶다.

그런데, 내가 걸린 문제는 이렇다. 위의 예제대로라면, 실제 find를 사용하는 것은 그 찾으려는 값이 밖에 있다는 사실. 만일 위의 예제대로 라면, 찾기 로직 안에 saurus 라는 값 처럼 아예 박혀 있어야 되는데, 실제로는 저 값이 외부에서 받는 값일때는 걸리게 된다.

예를 들어보자. 사용자가 검색하는 단어를 기준으로 찾는다고 하자.
입력되는 값에 따라 찾는 내용이 달라져야 되는데, 이 경우에는 위와 같은 방법을 사용하면 곤란해질 수 밖에 없다. 그렇다면?

위의 예제를 보면 함수를 넣기 위해 static private로 만들었는데, 그것을 delegate라는 대리자를 사용해서 원큐로 만드는 것이다. txtInput 이라는 Text 박스에서 입력값이 생겼을 때 찾기 명령을 실행 시키는 예제로직을 만들어보았다.

List<string> aryData = new List<string>();

public Test()
{
    aryData.Add("apple");
    aryData.Add("pineapple");
    aryData.Add("steel");
}

private void txtInput_TextChanged(object sender, EventArgs e)
{
    string sResult = aryData.Find(delegate(string s) {
        return s.Equals(txtInput.Text);
    });

    if(string.IsNullOrEmpty(sResult))
        MessageBox.Show(sResult);
}

대략적으로 보면 알겠지만,

Find 라는 함수 뒤에 delegate 라는 대리자를 선언하고, 그 안에 가상 함수로 들어오는 파라미터 값을 정의한다. string s 부분이 있는데, 그 부분이 바로 Find 에서 역으로 호출 될 때 들어오는 값이다. 만일 List<int> 라면 int 가 되어야 할 것이다.

그리고 최종적으로 돌려주는 값은 true, false로 나올 수 있는 값이면 된다.

그러면 실제적으로 Find의 Return 값은 찾은 값을 돌려주게 된다. 지금은 List<string> 이니 돌려주는 값은 당연히 string. 만일 int면 int가 될 것이다.

정리하며.

물론 사람이 만든 코드이기 때문에, 성능이 월등하리라 볼 수는 없다. 하지만, 최소한 그 분야의 대가들이며, 또 내부적인 구현 시, 순수 .NET으로 만들지 않고, 성능을 위해 억지로 Binary로 만들기도 한다. 즉 알지는 못하나, 최소한 날로 짜는 것 보다 더 나은 성능을 보여줄 수 있다는 것이다.

이런 내 함수들을 활용 방법이 의외 복잡하더라도 작정하고 사용하다 보면 지금 보다 더 나은 성능을 보장할 수 있다.

복합형 값용 List<T>.Find 사용방법 예제.

사람 정보 중 이름이 같은 데이터를 메시지 박스에 표현 하는 방법

class PersonData
{
    public PersonData(string sName, string sSocialNo)
    {
        _name = sName;
        _socialNo = sSocialNo;
    }

    string _name;
    public string Name
    {
        get
        {
            return _name;
        }
        set
        {
            _name = value;
        }
    }

    string _socialNo;
    public string SocialNo
    {
        get
        {
            return _socialNo;
        }
        set
        {
            _socialNo = value;
        }
    }

}

List<persondata> aryData = new List<persondata>();

public Test()
{
    aryData.Add(new PersonData("홍길동", "123444-444422"));
    aryData.Add(new PersonData("조조", "123444-444422"));
    aryData.Add(new PersonData("유비", "123444-444422"));
}

private void txtInput_TextChanged(object sender, EventArgs e)
{
    PersonData sResult = aryData.Find(delegate(PersonData p) {
        return p.Name.Equals(txtInput.Text);
    });

    if(sResult != null)
        MessageBox.Show(sResult.Name + sResult.SocialNo);
}

단순한 컨트롤인 TextBox 나 ListBox 같은 것은 그냥 쓰면 되는데, 복합 컨트롤을 만들 필요가 있는 경우 사용자 컨트롤을 만들어 사용하곤 한다. 즉 TextBox와 ListBox가 하나로 합쳐진 특수 목적 컨트롤 같은 것을 만들때다.

저렇게 컨트롤 안에서 동작만 되면 문제가 없는데, 만일 외부로 이벤트를 노출 시킬 필요가 있는 경우가 있다. 위의 그림을 예로 들면 아랫쪽이 ListBox인데, ListBox의 선택이 변경되는 경우 저 통짜 컨트롤을 쓰는 곳에서 그 이벤트를 받기 위해서 구성하는 경우다.

어떻게 해야 될까 고민을 하다가 링크 하나를 발견했다. ( http://www.akadia.com/services/dotnet_user_controls.html )

만드는 방법은 간단하다. 딱 두 줄에 해당하는 내용을 넣으면 된다.

public delegate void 이벤트이름Handler();
public event 이벤트이름Handler 이벤트이름;

위와 같이 구성하면 되는데, 위의 컨트롤에서 사용한 내용은 아래와 같다.

// 컨트롤 내부 소스
public delegate void SelectChangedHander(); 
event SelectChangedHander SelectChanged;

event로 SelectChanged 라는 이름으로 하고 밖에서 연결할 때 사용하는 끈 역할을 하는 Handler를 delegate(대리자)로 선언하여 처리하는 것이다. 그러면 밖에는 이 Handler를 통해 이벤트 가입을 하는 것이다. 가입방법은 예전에도 많이 봤던 그런 형태가 된다. ( 저 이벤트를 받을 메인 프로그램에 선언하는 그 형태. )

// 컨트롤을 사용하는 메인 프로그램 소스
this.categoryCtrl.SelectChanged += new CategoryCtrl.SelectChangeHander(this.categoryCtrl_SelectChanged);

그러면 컨트롤 측에서 이벤트를 발생을 어떻게 하는 걸까?
그 역시 간단하다.

이벤트 이름을 함수로 호출하듯 하면 된다.

// 컨트롤 내부 소스 중 이벤트가 발생되는 시점
if (SelectChanged != null)
   SelectChanged();

보면 뜬금 없이 SelectChage가 null 인지 체크하는 경우가 있는데, 컨트롤이 제대로 초기화되지 않은 상황에서 호출되는 불상사를 막기 위한 안전 장치이다. 무시해도 되긴 하지만, 가급적이면 저렇게 안전장치를 거는걸 권장한다.

자,위와 같이 구성했다면, 이렇게 된다.

컨트롤내부 실행 중

-> SelectChange() 함수 호출

-> SelectChanageHandler로 연결한 모든 부분에 이벤트 발송

-> SelectChangedHandler에 인자값으로 넘긴 함수를 호출
   (위의 예제로 있는 categoryCtrl_SelecChanged() 함수 같은거)

기존에는 그냥 만들어진 이벤트를 소비하기만 했다면 자신만의 이벤트로 작업을 한다면 이런 부분을 활용해 보는 것도 나쁘지 않을 것이다.(생각해보니, 이렇게 만들 수 밖에 없기는 하다.)

중간 중간 일음을 접하게 됐을때 종종 들었지만, 키로로 라는 사실은 전혀 모르고 음악만 들었던 것 같다. 그렇게 머릿속에만 남아 있던 그 음악들이, 우연히 정오군을 통해 징발한 시디들 중 키로로가 있었고, 그 음악을 듣다가 우연히 내 머릿속에 맴돌던 그 음악들이였다는 사실에 알게 되었다.

아직도 미숙한 레벨의 일어 실력이지만, 대충 대충 감으로만으로 대략적인 가사의 뜻은 듣는 정도. 영어로 말하는 가사 역시 그 정도 레벨. 그러다 보니 굳이 집중해서 듣기 보다는 그냥 멜로디 정도만 생각하는 정도랄까?

그러다가 조용히 코딩이 막히는 것이 있었고, 음악을 들으면서 멍하니 있다가 키로로 음악들을 쭉 뽑아 들어보았다. 정말 아무생각없이 그녀들의 음악을 가만히 들었다. 그녀들이 말하는 게 정확히 무엇인지는 모르겠다. 다만, 목소리와 멜로디 그리고 몇몇 익숙한 단어들로 이어지는 이야기.

아...

나에게 강력하게 호소하는 것도, 그렇다고 자기들의 만족감에 어쩔 줄 모르는 것도 아닌 그냥 이런것이죠.. 라고 말하는 기분이다.

갑자기 닥친 복잡한 상황들과, 막연한 미래에 대한 두려움, 망설임, 내가 하고 싶은 것에 대한 포기 등등... 이 모든 것들에 대해서 그냥 말해주는 것 같았다.

순간 볼 위로 흐르지는 않았지만, 찐한 기분에 눈에 물기가 가득해진다.

이제 와서 팬이라고 자칭하는 것도 웃기고, 그렇다고 그녀들을 좋아하게 된것도 아니지만, 지금까지 지낸 세월과 현재의 상황들은 그녀들의 노래가 어느정도 코드가 맞는 것 같다. 내가 정신없이 바쁠때 들을때, 먼 후에 이 음악들을 조용히 들었을때, 과연 같은 느낌을 가질 것 같지는 않지만, 조용히 나중에 또 들으면서 조용히 이런 저런 생각을 해봐야 겠다.

사람들은 각자 자신만의 꿈이 있습니다. 꿈이 없더라도, 최소한 자신이 이루고자하는 목표나 욕구들이 있습니다. 하다 못해 기본적인 생활적인 욕구를 가지고 있죠.

이런 사람들 중 일부는 자신만의 사업이나, 회사를 꾸려나가기도 합니다. 하지만, 대부분은 특정 회사에 취직하여 일정 급여를 받으며 일을 합니다. 그런데 여기서 특정회사에서 자신의 꿈을 이루려 노력하는 사람은 그렇게 많지 않습니다. 심지어는 자신의 능력이나, 사정에 맞지 않아 도리어 나가는 경우도 많습니다. 즉 회사가 바라보는 곳과 사람들 개개인이 바라보는 곳은 다를 수 밖에 없다는 것입니다.(물론 일치하시는 분도 있지만, 그렇지 많지 않다고 생각합니다.)

그렇다면 최소한 한 쪽은 양보를 해야 회사는 큰 문제 없이 돌아갈 것입니다. 대부분은 회사라는 조직에 맞추어 진행되는 경우가 많죠. 특히 급여를 통해 자신의 목표나 욕구로 환원 받는 경우가 많기 때문입니다.

하지만, 단순히 급여만을 보면서 일하기에는 무언가 부족함을 느낄 수 밖에 없습니다. 특히 만족감, 성취감. 이런 부분은 돈으로써 매꾸기에는 한계가 있다는 것입니다. 즉 개개인의 꿈에는 맞지 않지만, 최소한 회사가 바라고 꿈에 일부분이라도 보탬이 되어 스스로에게 대리 만족과 같은 충족감을 느끼는 것이죠.

작은 부분일지라도, 회사의 성공속에 자신의 노력이 뭍어 있다면 두고 두고 자랑거리로 남을 수 있을테니까요.

즉 회사는 각 개개인에게 회사가 바라는 길, 꿈을 제시할 수 있어야 하는데, 제가 생각하는 회사의 Vision은 바로 이 부분이라고 생각합니다. 각기 다른 능력과, 생각, 판단, 목표라 할지라도, 최소한의 공통 분모로써, 회사라는 조직을 통해 하나로 묶을 수 있는 부분이라는 것이죠.

예전 Day&Night라는 곳에서 일할 때, 그 때 사장이 새로 뽑으려는 분에게 비젼 부분에 대해 이렇게 답을 하더군요. "비젼은 단순히 회사가 제시하는 것이 아니라, 일하는 사람들이 모여 만드는 것이다."라고. 그 때는 옆에서 듣기만 했던 나 조차 동의를 하며 그렇구나,라고 생각했습니다.

하지만, 지금의 생각에서는 그 부분에 대해서 100% 동의가 안되더군요. 물론 회사내 구성원이 만들면 좋습니다. 하지만, 각기 다른 개개인이 만들기에는 어떻게 보면 중구난방이라는 것이죠. 각기 다른 능력에 각기 다른 생각과 각기 다른 목표인데, 어떻게 하나로 합쳐질까요?

즉 회사에서는 최소한의 Base가 될 중심 생각을 보여주어야 하고, 그게 바로 Vision이지 않을까라는 것이죠.

회사의 이념을 나타낼 수도 있고, 회사 내 분위기를 표현할 수도 있습니다. 직접적으로는 회사가 어떻게 돈을 벌 것인지도 되는 것이죠. 단지, 각 개인이 한데로 뭉쳐질 수 있는 그 무언가는 반드시 필요하며, 그것이 모두의 동의를 얻어 낼 수 있는 것이여야 한다는 것입니다.

모두가 개고생을 하면서도, 최소한 서로를 위로해주며 다잡아줄 수 있는 Vision이 있다면, 잠깐의 고통정도는 서로 감내해 줄 수 있을 것입니다.

단, Vision이 있더라도, 그 Vision의 가치는 개개인 마다 생각하는 것이 다릅니다. 즉 같은 Vision을 바라보더라도, 그 가치를 생각함이 다르다 보니 누구는 함께 고생하며, 누구는 중도에 포기하도 합니다. 최소한 함께 Vision을 바라보기를 원한다면, 항상 같이 있으면서 Vision의 가치에 대해서 말하며, 지금의 힘든 점을  최소화하도록 노력하고 Vision외의 부분에 고통 받지 않도록 노력해주는 그 누군가가 필요하다는 것입니다.

한 회사의 사장이 될 수 있으며, 한 부서의 부서장이 될 수 있으며, 한 프로젝트의 PM이 될 수 있습니다. 또는 한 팀의 팀장이나 팀원일 수도 있습니다. 이런 사람들이 Vision을 이야기하며 제시하며, 함께 고생을 한다면 아마도 지금과 같은 IT 모습은 아닐 것입니다. 3D 아니 4D ( 3D + Dreamless)의 꼴을 만들어 버린 SI도 Vision을 함께 공유하면서 그 끝의 달디 단 열매를 서로 잘 나누웠다면 말이죠....

밤새고, 주말 근무하고, 개인 생활 파탄내다가, 결국 닭집하거나, 농사일(닭집이나, 농사일이 쉽다는 것은 아닙니다. 이거 해보시면 -_-;;;; )하게 되곤 하죠. 즉 그냥 회사에 출근해서 시키는 일 죽도록 하다가 월급 달달이 받는데 그 또한 여의치 않게 되고, 나이 먹다 보니 이제 하드 코어한 프로젝트는 못뛰는... 불상사. 남는것은 관리직이나, 이제나 저제나 기술만 보다 사람 관리하려니 죽어나는 것이죠. Vision 없이 닥치는대로 일을 하다가 보니, 스스로에 대한 회의감까지 이르르면 사실 끝이죠.

너저분 길게 길게 적었지만, 최소한 저는 이렇게 생각합니다.

지금 IT하는 회사라면, 스스로에게 Vision이 무엇인지 되묻고 달리셨으면 합니다.

지금 있는 개발자들이 과연 무엇을 바라보면서 같이 달리고 있는지 이야기 하고 생각했으면 합니다.

전 직원에게 묻고자 한자리에 쏟아부어 보려고 노력하는데 안모인다고 주저하지 말고, 당장 옆의 친구 부터 하나씩 묻고 이야기하며 현재 상태를 생각해주었으면 합니다.

그래서 지금의 Vision을 정리하여 모든이에게 틈틈히 전달해주고, 그 목표 대로 가고 있는지 늘 지켜보셨으면 합니다. 그냥 단순히 돈 얼마 벌어왔네, 돈 얼마썼네, 니 월급 대비 얼마를 더 벌어와야 하는데 그거 아니네, 어디는 더 벌어왔네와 같은 단순한 돈이 아닌, 정말 같이 공감할 수 있는 그 회사만이 보여줄 수 있는 뚜렷한 목표/Vision이 있는지 지금이라도 다시 살펴보는 계기가 있었으면 합니다.

한여름의 더위에 짜증내면서 끄적여봤습니다.