IT/모바일
저자: 한동훈(traxacun@unitel.co.kr)
최근에 심심찮게 받는 질문중에 하나가 "C# 프로그래머가 되려면 어떻게 해야할까요?" 라며 나름대로의 학습 계획이나 선정한 도서들이 자신의 학습 계획에 타당한지 묻는 분들이 있다.
이 글은 그냥 오만한(?, -_-) 필자의 지나가는 글이라 생각하고 관심있는 분들은 읽고, 그렇지 않은 분들은 지금 당장 다른 곳으로 클릭하기 바란다.
필자는 상당히 운이 좋은 편이다. 닷넷의 정식 버전이 나온 현시점까지 필자는 몇 권의 닷넷 관련서적을 번역할 기회가 있었고, 출간예정 도서를 검토할 기회가 있었다. 그리고 최근에는 닷넷 마이그레이션 프로젝트를 끝냈다. 때문에 여기서 느낀 점을 간단히나마 쓰면서 닷넷 프로그래머가 되기 위한 것들에 대해서 함께 고민해보자.
최근에 필자는 윈도우 3.1 응용 프로그램을 윈도우 95용으로 마이그레이션한 VB6 응용 프로그램에 대한 닷넷, 정확히는 C# 언어로의 마이그레이션 작업에 참여했다.(프로젝트라는 용어의 사용은 삼가도록 하자. C#(삽)이라는 거창한 "삽질 언어"를 이용해서 그저 "삽질"하는 작업을 했을 뿐이다)
VB6에서 VB.NET으로 마이그레이션하더라도 사용하는 키워드만 비슷할 뿐 언어의 구조나 처리방식이 모두 변경되었기 때문에 크게 의미가 없다고 판단하였기 때문에 C#을 사용하기로 하였다. 하지만 필자역시 VB와 ASP 기술에 상당히 익숙하기 때문에 웹 서비스를 이용한 웹 클라이언트(ASP.NET)는 VB.NET을 이용하여 작성하기로 하였다.
최초의 윈도우 3.1 버전의 응용 프로그램은 자체적으로 만든 데이터 구조를 사용하여 필요한 데이터를 관리하는 작은 응용 프로그램이었다. 16 비트 코드와 VBX를 사용하여 작성되었으며, 이것을 32 비트 윈도우(윈도우 9x)에서 동작하도록 하기 위해 VB5에서 부터 마이그레이션 되어 VB6 응용 프로그램까지 발전해 온 것이다. 또한, 이 과정에서 클라이언트/서버 유행에 따라서 32 비트 윈도우 버전으로 마이그레이션되면서 응용 프로그램 전체를 재설계하여 클라이언트/서버 버전으로 한층 기능을 강화한 것이다.
마지막으로 이 응용 프로그램을 닷넷 버전으로 마이그레이션하고 "웹 서비스"를 이용하는 것으로 발전시키기로 하였다. 또한 데이터베이스 연결, 질의, 갱신과 같은 데이터 처리 로직과 필요한 업무 규칙을 모두 갖고 있는 기존 윈도우 팻 클라이언트 응용 프로그램을 씬 클라이언트 응용 프로그램으로 만들기로 하였으며, 데이터 처리 로직과 업무 규칙을 모두 분리하기로 결정하였다.
즉, 기존의 중앙 집중화된 데이터베이스 서버와 모든 기능을 갖고 있는 클라이언트를 닷넷 개념과 웹 서비스를 적용하도록 하며, 업무 규칙 수정이나 기타 사소한 수정에 따른 클라이언트 재배포 문제와 각종 사용자 시스템에서의 컴포넌트 의존성 문제로 인한 응용 프로그램 설치 오류 문제들을 최대한 제거하고자 하였다. 최대한 유연성 있으면서 변경하기 쉽고 가용성과 확장성있는 시스템을 구축하고자 한 것이다.
또한 내부 데이터 교환이나 사용자 UI에 사용되는 모든 데이터는 XML로 통일하도록 하였다.(기술적인 세부 사항을 소개하는 것은 피하겠지만, 닷넷에서는 데이터셋에서 모든 컨트롤에 이르기까지 XML을 훌륭하게 지원하고 있으므로 이것은 당연한 선택이었다)
따라서 최종적인 시스템의 모습은 데이터베이스 서버 1대, 데이터 처리 서버 1대, 비즈니스 로직 서버 1대와 같은 모습을 갖도록 하였다. 비즈니스 로직 서버는 사용자 UI(윈도우 클라이언트 응용 프로그램, ASP.NET 웹 응용 프로그램)와 연결되는 부분이므로 웹 서비스로 구현하였다. 또한 이 웹 서비스에 대한 프록시 클래스를 작성하여 클라이언트 응용 프로그램 작성에 사용하였다.
닷넷 프로그래머 되기라는 데 갑자기 이렇게 복잡한 이야기를 꺼내서 어리둥절해 했을지도 모르겠다. 하지만 이 글을 다시 생각해보면, 지금까지의 응용 프로그램의 변화라는 것을 알 수 있을 것이다.
자체적인 데이터 구조를 갖는 단독 실행 응용 프로그램에서 관계형 데이터베이스를 이용한 클라이언트/서버 환경으로 옮겨왔고, 이제는 웹 서비스라는 것을 이용하며, 기존의 2계층이나 비즈니스 로직 층(Business Logic Layer, BLL)을 끼워넣은 단순한 3계층 대신에 BLL을 데이터 액세스 층(Data Access Layer, DAL)과 BLL로 더욱 세분화하고 있으며, 내부 데이터 표현 형식을 모두 XML로 통일하고 있다. BLL을 웹 서비스로 노출시킴으로써 어떤 클라이언트에서도 이것을 사용할 수 있도록 하고 있으며, UI는 단순히 이들을 연결하는 것에 지나지 않는다.
이렇게 얘기하고 보니 옛날이 프로그래머가 되는 게 더 쉬웠던 것처럼 느껴질 수도 있지만, 그때나 지금이나 마찬가지로 프로그래머가 되는 것은 어려운 모양이다. 시대가 변하고 기술이 변해도 늘 어려운 것은 어렵다. "그 시대에 그 사람"이기 때문이 아닐까?
프로그래머가 된다는 것은 쉬운일이 아니고 꾸준한 학습을 필요로 한다. 필자역시 C 언어만 2년 6개월간 쓰다가 2년간을 LPI-COBOL 프로그래밍을 하면서 먹고 살줄이야 누가 알았겠으며, 최근의 CRM 일로 인해 사용언어가 22개까지 될줄이야 알았을까.(처음에는 C 언어로 시스템 프로그래밍을 했었고, 시스템을 업그레이드했다가 필자의 작업 코드들을 모두 고치는데 많은 시간을 보낸 기억이 있다. ? 필자가 쓰는 시스템에서만 돌아가는 시스템 코드들이었다. 메모리의 0 ? 1024 바이트의 벡터 테이블을 외웠던 시기가 있었고, 비트의 세계를 가장 좋아했던때가 있었다)
C#을 선택하거나 VB.NET을 선택하거나 그건 개인의 취향이라고 생각한다. VB6에서 VB.NET으로 발전하면서 마이크로소프트의 행위에 불만을 갖게 된 필자는 닷넷 개발 언어로 C#을 선택하고 말았지만 말이다. 어쨌거나 닷넷에서는 다양한 언어를 사용해도 결국에는 IL 코드로 변환되기 때문에 사용 언어는 크게 문제가 되지 않는다.
자, 이제 언어를 선택했으면 그 언어의 기본적인 문법들을 익히도록 한다. 책은 너무 두껍지 않으면 좋다. 요즘엔 왠지 두꺼운 책들이 잘 팔리는 경향이 있어선지 같은 말을 앵무새처럼 반복하면서 내용의 깊이는 형편없는데 두께만 두꺼운 책들이 많다. XML에 대해서 깊이 이해하면 좋겠지만, 초보에게는 무리가 아닌가 싶다. 따라서 XML에 대한 것은 A4 5-6장 정도로 간단히 사용 규칙만을 명명한 것을 보는 것으로 이해하면 된다. XML은 프로그래밍 언어도 아니고, 정확히는 데이터 구조를 기술하는 메타 언어다. 따라서 그 구조를 기술하는 표기 방법만 알고 있으면 된다.
입문서를 보았다면 해당 언어의 문법은 익혔을 것이라 생각한다. 그리고 간단한 콘솔 응용 프로그램, 윈도우 폼 응용 프로그램, ASP.NET 응용 프로그램과 웹 서비스를 작성하는 방법에 대해서 알게 되었을 것이다.(대개의 입문서들은 언어의 문법과 함께 이런 것들을 하나의 챕터 정도로 다루고 있다)
언어의 기본 문법을 알았다면 닷넷 프레임워크에 대해서 알아야한다. 모든 닷넷 언어들은 언어의 표기 방법과 특징만이 다를뿐 그 기본 기능은 모두 닷넷 프레임워크에서 가져온다. 닷넷 프레임워크에서 어떤 것들을 제공하는지 알고 있다면 나중에 프로그래밍을 할 때 보다 효율적으로 프레임워크를 이용할 수 있을 것이다.(적어도 프레임워크에서 제공하는 기능을 스스로 구현하는 우는 피할 수 있다) 닷넷 프레임워크 각각의 영역은 매우 방대하므로 어떠한 것들이 있는지를 가볍게 이해하는 선에서 넘어가도록 한다.
지금까지 언어의 문법을 알고, 프레임워크에 대해서 알았다고 하더라도 그것은 살아있는 지식은 아니다.(적어도 필자의 단단한 돌머리로는 그렇다. -_-) 이제부터 필자는 이것들로 무엇인가를 만들어 볼 궁리를 하기 시작한다. 즉, 여러분도 뭔가를 스스로 만들 생각을 한다. 윈도우 응용 프로그램도 좋고, ASP.NET 응용 프로그램도 좋다. ? 보통 필자는 입문서 한 권을 읽고, 예제를 직접 입력하면서 테스트한다. 하지만 실제로 필자가 자연스럽게 코드를 입력하지 못한다. 클래스 선언을 어떻게 했지? 문자열 처리는 어떻게 했지? 라는 생각과 함께 책에서 봤던 부분들을 들쳐보게 된다(심지어 변수 선언 방법이나 for나 if의 구조를 참고하기 위해 책을 펼쳐보게 된다). 이렇게 1주일 정도 하게되면 기본적인 것들을 책 없이 할 수 있게 된다. 이제부터는 레퍼런스를 참고하면서 개발을 하다보면 많은 지식이 머리속에 들어가있고, 남들이 훔쳐갈 수 없는 지혜가 되어 있을 것이다.
이렇게 한 달 정도 연습하고 나면 언어에 대한 기본적인 이해와 언어와 함께 딸려오는 많은 개념들을 어느 정도나마 소화할 수 있게된다.(모두는 아니다. 필자의 경우에는 머리가 단단해선지 체한다. -_-) 현재 자신이 개발하는 것과 관련된 책들을 읽으면서 자신의 경험과 책에 있는 지식을 비교하여 체화하도록 한다. 데이터베이스를 사용하는 것이라면 데이터베이스 관련 프로그래밍 책도 좋고 데이터베이스 그 자체에 대한 책도 좋다.
이제 여러분은 코드를 통해서 기계와 대화할 수 있는 방법을 터득한 것이다. 이제는 입문서에 간단하게 소개된 일천한 객체 지향 프로그래밍, 응용 프로그램 설계와 같은 지식들을 보충하여 디자인 패턴과 같은 것들을 익히도록 한다. ? 그렇다고 거창하게 하지는 말고, 간단하게 얇은 입문서 하나 정도나 온라인 자료를 읽는 것으로 생각의 폭을 넓히는 데 만족하자.
이와 같은 것들을 학습했거나 이미 알고 있다면 이제 부터는 여러분이 하고 싶은 것들을 하도록 한다. 그리고 그 깊이를 깊게 해라. 단순히 기술을 아는 것이 아니라 그것을 무엇에 쓸 것인가 생각하도록 한다.
설계에 대해서 언급한 것은 단순히 "디자인 패턴"이라든가 "리팩토링"과 같은 알 수 없는 용어를 사용해가며 입문자들에게 "권위"라는 것을 세우기 위한 것이 아니다. 처음에 쓴 소개 글 처럼 응용 프로그램은 점점 더 복잡해지고 있고, 지금까지 수 많은 개발자들이 이러한 복잡한 응용 프로그램을 개발하면서 부딪혔던 문제들을 하나의 패턴으로 만들어 소개한 것이다. 따라서 이러한 패턴을 익히고, 주어진 문제에 대해서 우아하게 해결할 수 있는 방법을 익혀나가도록 한다.
마지막으로 시간이 난다면 지금까지 어떤 기술들이 거쳐왔으며 어떤 언어들이 있어왔는지 이해한다면 현재 왜 자신이 이러한 기술과 언어들을 사용하고 있는지 명확히 할 수 있을 것이다.
컴퓨터는 업무 프로세스를 단축시켜서 일을 빠르게 처리할 수 있도록 해주는 도구다. 프로그래밍 언어 또한 컴퓨터에게 원하는 일을 지시하기 위한 도구에 불과하다. 특정 언어, 기술에 스스로를 옭아매고, 편협한 개발자가 되지 않기를 바란다. 열린 소스(Open Source)이전에 열린 마음(Open Mind)가 먼저다. 항상 이 사실을 염두에 두었으면 좋은 개발자가 되리라 믿어 의심하지 않는다. 부족한 글 읽느라 고생한 분들에게 심심한 감사를…
관련자료
최근에 심심찮게 받는 질문중에 하나가 "C# 프로그래머가 되려면 어떻게 해야할까요?" 라며 나름대로의 학습 계획이나 선정한 도서들이 자신의 학습 계획에 타당한지 묻는 분들이 있다.
이 글은 그냥 오만한(?, -_-) 필자의 지나가는 글이라 생각하고 관심있는 분들은 읽고, 그렇지 않은 분들은 지금 당장 다른 곳으로 클릭하기 바란다.
필자는 상당히 운이 좋은 편이다. 닷넷의 정식 버전이 나온 현시점까지 필자는 몇 권의 닷넷 관련서적을 번역할 기회가 있었고, 출간예정 도서를 검토할 기회가 있었다. 그리고 최근에는 닷넷 마이그레이션 프로젝트를 끝냈다. 때문에 여기서 느낀 점을 간단히나마 쓰면서 닷넷 프로그래머가 되기 위한 것들에 대해서 함께 고민해보자.
최근에 필자는 윈도우 3.1 응용 프로그램을 윈도우 95용으로 마이그레이션한 VB6 응용 프로그램에 대한 닷넷, 정확히는 C# 언어로의 마이그레이션 작업에 참여했다.(프로젝트라는 용어의 사용은 삼가도록 하자. C#(삽)이라는 거창한 "삽질 언어"를 이용해서 그저 "삽질"하는 작업을 했을 뿐이다)
VB6에서 VB.NET으로 마이그레이션하더라도 사용하는 키워드만 비슷할 뿐 언어의 구조나 처리방식이 모두 변경되었기 때문에 크게 의미가 없다고 판단하였기 때문에 C#을 사용하기로 하였다. 하지만 필자역시 VB와 ASP 기술에 상당히 익숙하기 때문에 웹 서비스를 이용한 웹 클라이언트(ASP.NET)는 VB.NET을 이용하여 작성하기로 하였다.
최초의 윈도우 3.1 버전의 응용 프로그램은 자체적으로 만든 데이터 구조를 사용하여 필요한 데이터를 관리하는 작은 응용 프로그램이었다. 16 비트 코드와 VBX를 사용하여 작성되었으며, 이것을 32 비트 윈도우(윈도우 9x)에서 동작하도록 하기 위해 VB5에서 부터 마이그레이션 되어 VB6 응용 프로그램까지 발전해 온 것이다. 또한, 이 과정에서 클라이언트/서버 유행에 따라서 32 비트 윈도우 버전으로 마이그레이션되면서 응용 프로그램 전체를 재설계하여 클라이언트/서버 버전으로 한층 기능을 강화한 것이다.
마지막으로 이 응용 프로그램을 닷넷 버전으로 마이그레이션하고 "웹 서비스"를 이용하는 것으로 발전시키기로 하였다. 또한 데이터베이스 연결, 질의, 갱신과 같은 데이터 처리 로직과 필요한 업무 규칙을 모두 갖고 있는 기존 윈도우 팻 클라이언트 응용 프로그램을 씬 클라이언트 응용 프로그램으로 만들기로 하였으며, 데이터 처리 로직과 업무 규칙을 모두 분리하기로 결정하였다.
즉, 기존의 중앙 집중화된 데이터베이스 서버와 모든 기능을 갖고 있는 클라이언트를 닷넷 개념과 웹 서비스를 적용하도록 하며, 업무 규칙 수정이나 기타 사소한 수정에 따른 클라이언트 재배포 문제와 각종 사용자 시스템에서의 컴포넌트 의존성 문제로 인한 응용 프로그램 설치 오류 문제들을 최대한 제거하고자 하였다. 최대한 유연성 있으면서 변경하기 쉽고 가용성과 확장성있는 시스템을 구축하고자 한 것이다.
또한 내부 데이터 교환이나 사용자 UI에 사용되는 모든 데이터는 XML로 통일하도록 하였다.(기술적인 세부 사항을 소개하는 것은 피하겠지만, 닷넷에서는 데이터셋에서 모든 컨트롤에 이르기까지 XML을 훌륭하게 지원하고 있으므로 이것은 당연한 선택이었다)
따라서 최종적인 시스템의 모습은 데이터베이스 서버 1대, 데이터 처리 서버 1대, 비즈니스 로직 서버 1대와 같은 모습을 갖도록 하였다. 비즈니스 로직 서버는 사용자 UI(윈도우 클라이언트 응용 프로그램, ASP.NET 웹 응용 프로그램)와 연결되는 부분이므로 웹 서비스로 구현하였다. 또한 이 웹 서비스에 대한 프록시 클래스를 작성하여 클라이언트 응용 프로그램 작성에 사용하였다.
닷넷 프로그래머 되기라는 데 갑자기 이렇게 복잡한 이야기를 꺼내서 어리둥절해 했을지도 모르겠다. 하지만 이 글을 다시 생각해보면, 지금까지의 응용 프로그램의 변화라는 것을 알 수 있을 것이다.
자체적인 데이터 구조를 갖는 단독 실행 응용 프로그램에서 관계형 데이터베이스를 이용한 클라이언트/서버 환경으로 옮겨왔고, 이제는 웹 서비스라는 것을 이용하며, 기존의 2계층이나 비즈니스 로직 층(Business Logic Layer, BLL)을 끼워넣은 단순한 3계층 대신에 BLL을 데이터 액세스 층(Data Access Layer, DAL)과 BLL로 더욱 세분화하고 있으며, 내부 데이터 표현 형식을 모두 XML로 통일하고 있다. BLL을 웹 서비스로 노출시킴으로써 어떤 클라이언트에서도 이것을 사용할 수 있도록 하고 있으며, UI는 단순히 이들을 연결하는 것에 지나지 않는다.
이렇게 얘기하고 보니 옛날이 프로그래머가 되는 게 더 쉬웠던 것처럼 느껴질 수도 있지만, 그때나 지금이나 마찬가지로 프로그래머가 되는 것은 어려운 모양이다. 시대가 변하고 기술이 변해도 늘 어려운 것은 어렵다. "그 시대에 그 사람"이기 때문이 아닐까?
프로그래머가 된다는 것은 쉬운일이 아니고 꾸준한 학습을 필요로 한다. 필자역시 C 언어만 2년 6개월간 쓰다가 2년간을 LPI-COBOL 프로그래밍을 하면서 먹고 살줄이야 누가 알았겠으며, 최근의 CRM 일로 인해 사용언어가 22개까지 될줄이야 알았을까.(처음에는 C 언어로 시스템 프로그래밍을 했었고, 시스템을 업그레이드했다가 필자의 작업 코드들을 모두 고치는데 많은 시간을 보낸 기억이 있다. ? 필자가 쓰는 시스템에서만 돌아가는 시스템 코드들이었다. 메모리의 0 ? 1024 바이트의 벡터 테이블을 외웠던 시기가 있었고, 비트의 세계를 가장 좋아했던때가 있었다)
C#을 선택하거나 VB.NET을 선택하거나 그건 개인의 취향이라고 생각한다. VB6에서 VB.NET으로 발전하면서 마이크로소프트의 행위에 불만을 갖게 된 필자는 닷넷 개발 언어로 C#을 선택하고 말았지만 말이다. 어쨌거나 닷넷에서는 다양한 언어를 사용해도 결국에는 IL 코드로 변환되기 때문에 사용 언어는 크게 문제가 되지 않는다.
자, 이제 언어를 선택했으면 그 언어의 기본적인 문법들을 익히도록 한다. 책은 너무 두껍지 않으면 좋다. 요즘엔 왠지 두꺼운 책들이 잘 팔리는 경향이 있어선지 같은 말을 앵무새처럼 반복하면서 내용의 깊이는 형편없는데 두께만 두꺼운 책들이 많다. XML에 대해서 깊이 이해하면 좋겠지만, 초보에게는 무리가 아닌가 싶다. 따라서 XML에 대한 것은 A4 5-6장 정도로 간단히 사용 규칙만을 명명한 것을 보는 것으로 이해하면 된다. XML은 프로그래밍 언어도 아니고, 정확히는 데이터 구조를 기술하는 메타 언어다. 따라서 그 구조를 기술하는 표기 방법만 알고 있으면 된다.
입문서를 보았다면 해당 언어의 문법은 익혔을 것이라 생각한다. 그리고 간단한 콘솔 응용 프로그램, 윈도우 폼 응용 프로그램, ASP.NET 응용 프로그램과 웹 서비스를 작성하는 방법에 대해서 알게 되었을 것이다.(대개의 입문서들은 언어의 문법과 함께 이런 것들을 하나의 챕터 정도로 다루고 있다)
언어의 기본 문법을 알았다면 닷넷 프레임워크에 대해서 알아야한다. 모든 닷넷 언어들은 언어의 표기 방법과 특징만이 다를뿐 그 기본 기능은 모두 닷넷 프레임워크에서 가져온다. 닷넷 프레임워크에서 어떤 것들을 제공하는지 알고 있다면 나중에 프로그래밍을 할 때 보다 효율적으로 프레임워크를 이용할 수 있을 것이다.(적어도 프레임워크에서 제공하는 기능을 스스로 구현하는 우는 피할 수 있다) 닷넷 프레임워크 각각의 영역은 매우 방대하므로 어떠한 것들이 있는지를 가볍게 이해하는 선에서 넘어가도록 한다.
지금까지 언어의 문법을 알고, 프레임워크에 대해서 알았다고 하더라도 그것은 살아있는 지식은 아니다.(적어도 필자의 단단한 돌머리로는 그렇다. -_-) 이제부터 필자는 이것들로 무엇인가를 만들어 볼 궁리를 하기 시작한다. 즉, 여러분도 뭔가를 스스로 만들 생각을 한다. 윈도우 응용 프로그램도 좋고, ASP.NET 응용 프로그램도 좋다. ? 보통 필자는 입문서 한 권을 읽고, 예제를 직접 입력하면서 테스트한다. 하지만 실제로 필자가 자연스럽게 코드를 입력하지 못한다. 클래스 선언을 어떻게 했지? 문자열 처리는 어떻게 했지? 라는 생각과 함께 책에서 봤던 부분들을 들쳐보게 된다(심지어 변수 선언 방법이나 for나 if의 구조를 참고하기 위해 책을 펼쳐보게 된다). 이렇게 1주일 정도 하게되면 기본적인 것들을 책 없이 할 수 있게 된다. 이제부터는 레퍼런스를 참고하면서 개발을 하다보면 많은 지식이 머리속에 들어가있고, 남들이 훔쳐갈 수 없는 지혜가 되어 있을 것이다.
이렇게 한 달 정도 연습하고 나면 언어에 대한 기본적인 이해와 언어와 함께 딸려오는 많은 개념들을 어느 정도나마 소화할 수 있게된다.(모두는 아니다. 필자의 경우에는 머리가 단단해선지 체한다. -_-) 현재 자신이 개발하는 것과 관련된 책들을 읽으면서 자신의 경험과 책에 있는 지식을 비교하여 체화하도록 한다. 데이터베이스를 사용하는 것이라면 데이터베이스 관련 프로그래밍 책도 좋고 데이터베이스 그 자체에 대한 책도 좋다.
이제 여러분은 코드를 통해서 기계와 대화할 수 있는 방법을 터득한 것이다. 이제는 입문서에 간단하게 소개된 일천한 객체 지향 프로그래밍, 응용 프로그램 설계와 같은 지식들을 보충하여 디자인 패턴과 같은 것들을 익히도록 한다. ? 그렇다고 거창하게 하지는 말고, 간단하게 얇은 입문서 하나 정도나 온라인 자료를 읽는 것으로 생각의 폭을 넓히는 데 만족하자.
이와 같은 것들을 학습했거나 이미 알고 있다면 이제 부터는 여러분이 하고 싶은 것들을 하도록 한다. 그리고 그 깊이를 깊게 해라. 단순히 기술을 아는 것이 아니라 그것을 무엇에 쓸 것인가 생각하도록 한다.
설계에 대해서 언급한 것은 단순히 "디자인 패턴"이라든가 "리팩토링"과 같은 알 수 없는 용어를 사용해가며 입문자들에게 "권위"라는 것을 세우기 위한 것이 아니다. 처음에 쓴 소개 글 처럼 응용 프로그램은 점점 더 복잡해지고 있고, 지금까지 수 많은 개발자들이 이러한 복잡한 응용 프로그램을 개발하면서 부딪혔던 문제들을 하나의 패턴으로 만들어 소개한 것이다. 따라서 이러한 패턴을 익히고, 주어진 문제에 대해서 우아하게 해결할 수 있는 방법을 익혀나가도록 한다.
마지막으로 시간이 난다면 지금까지 어떤 기술들이 거쳐왔으며 어떤 언어들이 있어왔는지 이해한다면 현재 왜 자신이 이러한 기술과 언어들을 사용하고 있는지 명확히 할 수 있을 것이다.
컴퓨터는 업무 프로세스를 단축시켜서 일을 빠르게 처리할 수 있도록 해주는 도구다. 프로그래밍 언어 또한 컴퓨터에게 원하는 일을 지시하기 위한 도구에 불과하다. 특정 언어, 기술에 스스로를 옭아매고, 편협한 개발자가 되지 않기를 바란다. 열린 소스(Open Source)이전에 열린 마음(Open Mind)가 먼저다. 항상 이 사실을 염두에 두었으면 좋은 개발자가 되리라 믿어 의심하지 않는다. 부족한 글 읽느라 고생한 분들에게 심심한 감사를…
관련자료
- Microsoft Solutions Framework Teaches Best Practices for Project Management
엔터프라이즈 응용 프로그램의 설계와 관리에 대한 것으로 1년에 몇 차례정도 갱신된다. 현재 최근 업데이트는 2001년 11월이다.
- SoftwareAG XML
SoftwareAG사의 XML 사이트. XML 전문 회사로서 XML에 대한 많은 리소스를 제공한다.
- The XML FAQ
Peter Flynn에 의해 운영되는 XML FAQ 사이트. 초기에는 W3C의 XML Special Interes Group에 의해 운영되었었다. 현재 2.0까지 버젼이 올라간 상태이고, 가장 기본적인 질문뿐만 아니고, 개발자, 사용자 및 XML에 관심이 있는 모든 이들이 참고할 수 있는 사이트
- W3C
W3C(World Wide Web Consotium)은 XML 표준을 제정한 곳으로 웹과 관련된 여러 표준을 만드는 비영리단체. 각종 XML 관련 표준들(HTML, XML, 등)이 제정되고 있으며 표준에 대한 Spec들을 제공하고 있음
- Clpicode Snippets for the Clipcode Components SDK
UML 예제와 함께 각각의 디자인 패턴에 대해서 자세하게 설명하고 있다. C++, C#, VB.NET으로 된 UML 예제 모델과 튜토리얼을 받아 볼 수 있다. 처음에는 C#만을 제공했으며 현재는 UML 튜토리얼과 함께 Jscript.NET, C++, C#, VB.NET, Java로 구현한 코드와 XML 스키마를 모두 제공하고 있다.
TAG :
이전 글 : 왜 데이터베이스가 중요한가?
최신 콘텐츠