필자가 주무기로 삼는 개발 도구는 델파이다. 델파이는 볼랜드의 첫 제품이었던 터보 파스칼의 새 이름이며 델파이라는 제품명은 1995년부터 사용되어 왔다. 그 터보 파스칼과 델파이를 만든 이가 바로 마이크로소프트에서 C#을 개발한 Anders Hejlsberg 라는 것은 익히 알려진 사실이다.
1. 툴 이야기
볼랜드가 1995년 델파이를 출시하면서 집중적으로 홍보한 부분은 ‘데이터베이스 프로그래밍의 간편화’였다. 마우스로 폼에 그리드와 DB 네비게이터(DB Navigator)를 올려놓고 컴포넌트 두어 개를 올려놓는 것만으로 데이터베이스 프로그램을 간단히 만들 수 있다는 점을 적극적으로 홍보한 것이다. 물론 그 외의 다른 장점들도 많이 소개되긴 했지만 간편하게 데이터베이스 프로그램을 개발할 수 있다는 점이 사용자에게 가장 강하게 어필했다.
델파이는 C++과 같다?
그래서일까? 12년이 지난 지금까지도 델파이를 파워빌더나 폭스 프로와 같은 데이터베이스 툴로 여기는 사람들이 적지 않다. 이는 대학교에서 학생을 가르치는 교수들도 마찬가지다. 교수들 사이에서도 델파이를 정확히 이해하고 가르치는 사람이 드물 만큼, 우리나라에서는 델파이에 대해 잘못된 이해가 만연해 있는 게 사실이다.
델파이는 오브젝트 파스칼 언어로 구성된 RAD 툴이다. 여기에 쓰인 ‘툴’이라는 단어가 오해를 하게 만드는 주요 원인이다. 이 ‘툴’을 우리말로 바꾸면 ‘도구’가 아니라 ‘통합 개발환경’에 해당된다. 이는 사실 필자도 오랜만에 들어봤을 만큼 이젠 기억에서 많이 흐릿해진 단어이다. 과거의 초기 도스 시절에는 컴파일러가 커맨드(command) 라인 형태로 사용되었고, 소스코드 작성은 별도의 에디터를 썼다. 이후 에디터와 컴파일러가 하나로 합쳐지면서 이른바 ‘통합 개발환경’이라고 부르게 된 것이다. 이 ‘RAD Tool’이라는 용어에서 사용되는 ‘툴’이란 단어는 바로 이런 ‘통합 개발환경’을 의미하는 것이지 델파이가 컴파일러가 아니라는 의미는 결코 아니다.
델파이는 이 오브젝트 파스칼 이외에도 VCL이라고 하는 강력한 클래스 라이브러리를 포함하고 있다. 볼랜드 계열의 개발자들은 이미 잘 알고 있는 사실이지만, 마이크로소프트의 닷넷은 바로 델파이의 VCL을 모델로 만들어진 것이다(델파이, 닷넷, C#이 모두 Anders Hejlsberg에 의해 설계되고 만들어졌기 때문이라는 분석에는 아마 이견이 없을 것이다).
VCL은 MFC 등의 다른 클래스 라이브러리에 비해 OOP적으로 상당히 훌륭하게 구성되어 있다. 다른 언어를 쓰면서 OOP에 대한 개념을 깨우치기가 여의치 않았던 사람이 델파이의 VCL을 다루면서 자연스레 OOP를 깨우치는 경우가 상당히 많은 것도 이를 잘 보여준다. VCL은 마치 그것을 다루는 사람에게 ‘프로그래밍은 이렇게 하는 것이다’라고 알려주는 것처럼 느껴질 만큼 논리적으로나 물리적으로 상당히 훌륭하게 만들어져 있다.
등장한 지 12년이 넘은 지금의 델파이는 처음에는 전혀 상상하지 못했던 수준까지 발전해 있다. 델파이 개발 환경 속에서 Win32는 물론이고, 닷넷을 지원한다. 또한 오브젝트 파스칼, C++, C# 등의 세 가지 언어도 지원한다.
한 프로젝트 내에서 여러 언어를 혼합해 사용할 수도 있고, Kylix를 사용할 경우 리눅스용 프로그램도 개발할 수 있다. 델파이는 사용되는 분야도 다양하다. 애플리케이션과 웹, 하드웨어 제어, 게임, 데이터베이스 등 마치 모든 언어를 합쳐 놓은 것 같은 착각이 들 만큼, 많은 분야에 이용되고 그 성능도 매우 강력하다. 이렇게 여러 언어와 플랫폼, 혹은 여러 분야에서 사용될 수 있는 특성이 있음에도 개발 방법에는 언제나 일관성이 유지되어 한 가지 형태로만 개발할 수 있다. 그것이 델파이의 가장 큰 매력이라 할 수 있다. 타 언어 사용자들 중에는 C++이냐 C# 이냐, 혹은 자바냐 닷넷이냐를 놓고 그 사이에서 갈등하는 경우가 많다. 하지만 델파이 사용자 중에는 이런 사람이 적은데, 그 이유가 바로 여기에 있다.
2. 노하우&테크닉
소프트웨어를 개발하는 데 있어서 개발 도구는 상당히 중요하다. 특히 초보에 가까울수록 개발 도구는 중요할 수밖에 없어 개발 도구나 언어를 학습하는 데 상당히 많은 시간을 할애하게 된다. 그러나 이들 가운데 상당수가 개발 도구나 언어를 학습하는 단계에 머무르고 만다. 경험이 쌓일수록, 지식이 많아질수록 또 다른 범위로까지 학습과 경험을 쌓아 가야한다. 그렇다면 개발 도구와 언어 외에 또 무엇을 더 알아야 할까?
개발자에게 가장 중요한 능력
일반적으로 소프트웨어 개발자들이 꼭 알아야 할 지식 범위를 정리하면 다음과 같다.
● 개발 도구 : 기본적인 작업 방법과 도구 특성을 이해
● 개발 언어 : 기본 문법, 기본 유닛 및 함수, 유틸리티 함수 등
● 운영 체제 : Win32, .NET 등
● 클래스 라이브러리 : VCL, MFC, .NET 등
● OOP : 상속 등의 기본 클래스 사용법과 다양한 패턴 등
● 알고리즘
● 개발 분야와 관련된 특별한 지식이나 비즈니스 요소 등
이는 어떻게 보면 너무나 당연하다고 생각되는 내용들이다. 필자는 이 내용들을 조금은 다른 방법으로 정리해 보았다. 필자의 기준에서 개발자들이 알아야 할 범위는 다음과 같다.
● 개발 도구
● 개발 언어
● 물리적 객체 사용 방법
● 논리적 객체 사용 방법
● 논리적+물리적 객체 구성 방법
● 소프트웨어를 평가할 수 있는 능력
앞서 나열한 방법과 이 방법은 순전히 관점의 차이일 뿐이다. 실제로 개발자가 다루거나 알아야 할 내용들은 크게 다르지 않다. 이 중에서 개발 도구와 개발 언어를 제외한 네 가지를 간략하게 설명해본다.
물리적 객체의 의미
위 제목에서 말하는 ‘물리적’이라는 말은 소프트웨어 범주에서의 물리적인 요소를 의미한다. 예를 들면 화면에 내용을 표현하기 위한 각종 컨트롤들과 메시지 처리 방법, DC를 이용하여 그림을 그리는 방법, 키보드 및 마우스 입력을 받기 위한 메시지 처리 방법, 소켓을 이용하여 데이터를 주고받는 방법, 파일 다루는 방법, 데이터베이스 다루는 방법 등이 그것이다. 그 외에도 수 없이 많은 방법들을 알아야 할 필요가 있다. 이것들을 모두 ‘물리적 객체 사용 방법’이라고 지칭한 것은 소프트웨어라는 것이 여러 가지 연산 과정을 거쳐 이뤄지지만 결국 최종 목적은 바로 이와 같은 것들을 제어하는 것이기 때문이다.
위에 열거한 방법들 중에서 어떤 것은 운영체제와 직접적으로 관련이 있고, 다른 어떤 것들은 운영체제하고는 별 관련이 없다. 예를 들어 화면에 내용을 표현하기 위한 컨트롤이나 메시지를 다루는 것은 전적으로 Win32에 기반하고 있다. 그러나 데이터베이스를 다룰때는 Win32보다는 특정 데이터베이스(오라클이나 MS-SQL 등)에 대한 지식과 기본 SQL 문법 등이 훨씬 많이 요구되곤 한다. 또 소켓을 이용해 데이터를 주고받는 일도 결국은 운영체제의 API 함수를 써서 구현하긴 하지만, 패킷 자체나 TCP/IP에 대한 지식이 더 중요한 게 사실이다.
따라서 고급 개발자가 되기 위해서는 어지간한 물리적 객체 사용법은 통달하고 있어야 한다. 평생을 데이터베이스 분야에서만 개발한 이들을 종종 보곤 하는데, 이들 중에는 컨트롤에 DC를 할당하여 자기만의 그림을 그리는 일조차 하지 못하는 개발자도 적지 않다. 또 어떤 개발자는 평생을 게임만 개발하다보니 오라클 서버에 접속하는 것조차 수행하지 못한다.
이런 상황이다 보니 ‘OOP적 객체 구성’ 능력은 개발자에게 가장 중요한 요소로 꼽힌다. 한 가지 분야의 지식만 깊이 아는 개발자들은 다양한 객체 구성을 필요로 하지 않는다. 그 분야에서 주로 사용하는 몇몇 패턴만 다룰 줄 알아도 개발이 가능한 경우가 많기 때문이다. 그러나 다양한 물리적 객체를 다루는 능력은 결국 OOP적 객체 구성 능력을 키우는 데 있어 필수적이다. 또한 개발자가 한 가지 분야에서 평생 코더로만 남지 않고, 소프트웨어 설계와 고급 기획 능력까지 갖춘 이로 거듭나기 위해서는 이 부분에 대한 학습은 절실하다.
논리적 객체의 사용
논리적 객체는 위에서 언급한 물리적 객체와는 달리 눈에 보이지 않는, 즉 메모리상에서만 사용되는 객체들이다. 물리적 객체가 운영체제나 플랫폼, 혹은 각종 Input이나 Output에 관한 것이라면 논리적 객체는 이와 상관없는 개념적 정의에 해당한다. 그렇기 때문에 논리적 객체는 학습하기가 상당히 어려운 부분이기도 하다.
보통 개발자를 초, 중, 고급으로 분류하는 경우가 많은데, 필자는 개발자를 물리적 객체만 사용하는 개발자와 논리적 객체만 사용하는 개발자, 그리고 물리적 객체와 논리적 객체 모두를 잘 이용하는 개발자로 나누고 싶다. 물론 소프트웨어라는 것이 물리적 객체만으로도 구성할 수 있기에 줄곧 그렇게 작업하는 개발자가 많다.
그러나 개발 과정에서 이뤄지는 모든 작업(요구 분석, 설계, 수정, 팀 작업, 원인 분석, 변경 사항 설정, 부분별 성능 및 효율 체크 등)이 아무 문제없이 진행되기 위해서는 물리적인 객체의 성능도 중요하지만, 무엇보다 전체적인 소프트웨어의 구성이 가장 중요하게 고려되어야 한다. 이러한 관점에서 볼 때 논리적 객체의 구성은 매우 중요한 부분이라고 할 수 있다.
논리적+물리적 객체 구성
역시 개발자의 가장 이상적인 모습은 물리적 객체와 논리적 객체를 적절히 활용하여 전체적인 구성을 하는 것이다. 지나치게 OOP나 디자인 패턴에만 몰두한 나머지, 설계만 할 수 있고, 구현은 직접 하지 못하는 개발자를 종종 볼 수 있다. 이는 소설가가 글자를 쓰지 못하는 것과 마찬가지인 상황이다. 어떠한 경우라도 소프트웨어 개발 분야에서 개발자의 구현 능력은 기본 중에 기본이 아닐까 싶다.
이러한 사고 방식은 비단 소프트웨어 분야뿐만이 아니라 거의 모든 산업 분야에 그대로 적용된다. 건축 분야를 예로 들어보자. 물리적으로는 각종 건축 자재와 장비, 인력 등이 있을 수 있고(물리적 객체), 논리적으로는 건축물의 목적이나 시공 방법, 각 부분의 용도 및 활용성 등이 있을 수 있다(논리적 객체).
소프트웨어 평가 능력
개발자는 소프트웨어를 만드는 사람이다. 여기서 ‘소프트웨어를 만든다’라는 말은 크게 두 가지로 생각할 수 있다. 하나는 개발자들이 수행하는 엔지니어적인 개발을 의미하는 것이고, 다른 하나는 기획을 뜻하는 것이다.
일반적으로 개발자들은 자신의 업무가 기획과는 거리가 멀다고 생각해서 기획자로서의 역할에는 그다지 관심을 갖지 않으려는 경향이 있다. 그러나 엄밀히 말하면 소프트웨어 개발자야말로 어떤 기획자보다도 소프트웨어 기획에 필요한 해박한 지식을 갖춰야 한다. 이는 기획이라는 것이 각자가 지닌 ‘개발 능력’의 범위 안에서만 이뤄지기 때문이다.
이를 다른 분야의 예를 들어 비유해보자. 자동차를 기획하는 데 있어서 최고 시속이나 마력 등과 같은 스펙은 어느 단계에서 결정될까? 기획 단계일까? 아니면 구현 단계일까?
아무리 자동차 기획자가 고 성능의 차를 기획해도 자동차 개발자가 이를 구현하지 못한다면 그 기획은 무용지물이 될 것이다. 반대로 개발자가 지금까지 소개된 어떤 종류의 엔진보다도 훨씬 강력한 엔진을 개발해냈다면, 그것을 토대로 애초 기획과는 전혀 다른 새로운 자동차를 기획할 수도 있다. 이 예에 비춰볼 때 개발자가 동일 분야의 제품들을 잘 알지 못한다면 새로운 기술 개발에 목표 없이 임하는 것과 다를 바 없다.
개발자의 습관
현실에는 참으로 다양한 종류의 개발자들이 존재한다. 가장 기본적인 소스 줄 맞추기, 대소문자 구분하기, 줄 바꾸기 등만을 놓고 봐도 이는 금새 확인할 수 있다.
간혹 외국에서 잘 만들어졌다고 평가 받는 소스 코드를 들여다보면, 의외로 줄 맞추기가 형편없이 되어 있는 것들이 많다. 필자뿐만이 아니라 경험 많은 대부분의 개발자들은 소스의 줄 맞추기만큼은 정확하게 지켜야 한다고 입을 모은다. 사실 필자는 앞에서 강조한 OOP적인 능력보다도 이런 줄 맞추기 능력을 훨씬 중요하게 생각한다. 심지어 클래스도 잘 다루고 객체 구성 능력도 뛰어나지만 코드의 줄을 전혀 맞추지 않는 개발자보다는, 클래스와 객체를 잘 모르지만 줄 맞추기나 대소문자 구분 등으로 코딩을 깔끔하게 하는 개발자를 좋아하는 것이다.
물론 이는 사람마다 다르게 평가될 수 있다. 주관적인 판단의 문제이므로 어느 것이 정답이라고는 쉽게 말할 수 없을 것이다. 여기서 필자가 생각하는 개발자가 꼭 지켜야 할 습관 몇 가지를 정리해보면 다음과 같다.
● 내가 사용하는 모든 API 함수, 클래스 및 메소드, 클래스 상속 구조, 각종 함수(파라미터까지), 유닛명 및 유닛의 용도, 유닛에 포함된 내용 등은 모두 다 외우도록 하자. 앞에 몇 글자만 치고 자동완성 팝업창이 나타나면 방향 키와 엔터 키로 키워드 등을 선택해 코딩하는 개발자들이 있다. 물론 코딩의 속도를 빠르게 하기 위해 이는 필요한 방식이다. 그러나 단지 이런 이유가 아니라 키워드의 정확한 스펠링을 외우지 못해 그런 방식으로 코딩하는 개발자들도 적지 않다. 필자는 그런 개발자에게 말하고 싶다. “당신은 아직 입문자입니다”라고….
● 줄 맞추기, 대소문자 구분, 단어 띄어쓰기, 라인 띄어쓰기 등은 가능한 단 한 곳도 틀리지 않도록 정확하게 지키자. 프로의식이 있는 개발자라면 줄 맞추기에 목숨을 걸어야 한다. 왜냐하면 줄 맞추기만큼은 의식적으로 되는 게 아니라, 무의식속에서 습관적으로 이뤄져야 하기 때문이다. 줄 맞추기마저 습관화되어 있지 않다면, 그 개발자는 무엇을 해도 결코 완벽하게 할 수는 없을 것이다.
● 어떤 특별한 방법을 사용하기 위해 학습할 때는 당연히 서적이나 인터넷 등에서 각종 자료를 참조해야 한다. 그러나 일반적인 실무에서조차 책이나 인터넷 없이는 작업 자체를 수행할 수 없다면 그 개발자는 아마추어임에 틀림없다.
● 신용은 개발자이기 이전에 한 명의 인간으로서 가장 중요한 부분이다. 아무리 힘들고 막막한 상황이더라도 동료나 나에게 일을 맡긴 상사에게는 신뢰를 지킬 수 있도록 최대한 노력하자. 맡겨진 프로젝트가 버겁다고 어느 날 갑작스레 출근하지 않는 개발자들의 얘기를 심심치 않게 듣게 된다. 필자가 장담하건데 이런 식으로 업무와 책임을 회피한 개발자들은 이 분야에서는 결코 성공할 수 없다. 개발 업무가 감당할 수 없을 만큼 힘겹다면 차라리 상급자나 동료와 1대1로 대화해 풀어라.
● 생각은 디버거보다 훌륭하다. 과거 가수 김수철 씨는 노래를 부를 때 종종 간주를 입으로 처리하곤 했다. 보통은 기타 연주로 이를 처리해야 하는데 그 대신 입으로 소리를 낸 것이다. 누군가 묻자 그는 이렇게 답했다. “입으로 소리 내지 못하면 손으로도 못 냅니다.”
개발자들도 마찬가지다. 개발자에겐 입이 아닌 머리다. 내가 만들 소프트웨어의 전체 구조는 내 머리 속에 고스란히 들어있어야 한다. 만일 생각으로 정리하지 못한다면 그 코딩은 원활하지 못한 작업이 될 것이다.
3. 이 한마디
언제부터인가 소프트웨어 개발자를 이른바 3D 업종으로 여기는 이들이 많아졌다. 실제로 개발자들 스스로가 3D 업종이라고 평가하는 경우도 심심치 않게 본다. 그도 그럴 것이 낮은 수준의 보수에 하루가 멀다 하고 빈번히 이뤄지는 야근, 개발 과정에서 이 사람 저 사람에게 받는 갖가지 스트레스를 생각하면 3D 업종이라고 얘기해도 결코 지나치진 않을 것이다.
하지만 미국의 경우에는 소프트웨어 개발자가 우리와는 달리 우수한 대우를 받고 있다. 미국과 우리나라의 개발자가 이처럼 다른 대접을 받고 있는 것은 어떤 이유에서일까? 이는 순전히 경제 논리를 따르느냐 따르지 않느냐의 차이이다. 쉽게 말해 미국의 경우에는 그 사람이 하는 일(혹은 생산해낸 결과물)이 얼마만큼 많은 수익을 가져다주느냐가 그 사람의 연봉을 결정하지만, 국내의 경우에는 그렇지 못한 셈이다. 바꿔 말해 이는 국내의 경우 소프트웨어가 그다지 높은 수익을 이끌어내지 못하는 데서 비롯된다.
그렇다하더라도 필자가 생각하기에는 개발자가 그래도 다른 직업군보다는 형편이 양호하다. 한 번 주위를 유심히 둘러보자. 친구, 친척, 후배, 선배, 이웃 등과 자신의 상황을 비교해보면 된다. 아마 금새 소프트웨어 개발자가 그다지 3D 직종이 아니라는 것을 깨닫게 될 것이다.
꿈속에서 헤매는 개발자가 성공한다!
개발자에게 꿈은 무엇과도 바꿀 수 없는 소중한 재산이다. 소프트웨어 개발이 타 직종과 다른 독특한 매력이 있다면 나 홀로 나만의 ‘자산’을 만들 수 있다는 것이다. 아울러 이 자산은 언젠가는 대박을 터뜨려줄 지도 모른다. 로또 복권 1등과 맞먹는 낮은 확률일지라도 이는 희망임에는 틀림없다. 아울러 로또 복권의 경우는 자신의 노력과는 전혀 무관하게 100% 운으로만 결정되나, 소프트웨어 개발에 의한 대박은 각자의 노력에 의해 얼마든지 실현될 수 있다는 큰 차이점이 있다.
여기서 필자가 강조하고 싶은 것은 그 희망은 꿈을 꾸는 데서부터 출발한다는 사실이다. 개발자의 꿈은 꿈이 아니라 현실 세계에서 생명력을 유지하기 위한 에너지라고 할 수 있다. 만일 하루 8시간을 근무한다면 총 480분 가운데 1/16에 해당하는 30분만 내 꿈을 실현시키는 데 투자하자. 아마도 나머지 15/16인 7시간 30분을 포함해 하루 전체가 즐거워질 것이다.
