'델파이'에 해당되는 글 3건
- 2007.01.03 개발자의 미래...
- 2007.01.02 사용자 인터페이스 설계시 고려사항.. Part I
- 2006.10.30 서버를 JAVA로 개발하고 Delphi로 클라이언트로 구축한 경험담..
어차피 세계 경쟁시대에.. 타국에서 만든 개발툴의 논란에 그리 휘말릴 필요는 없다고 생각합니다. 개발툴이라는 것은 좋은 소프트웨어를 만들어내는 좋은 공구일 뿐이니까요.
물론.. 공구를 다루는 뛰어난 테크닉도 중요하고.. 전체를 바라보는 눈도 필요한것은.. 누구나 다아는 사실이라고 보입니다.
다만.. 국내의 현실에서는.. 코딩과 관련된 테크니션의 필요성도 있지만, 그 인력이 그렇게 쉽게 만들어지는 것도 아니고.. 사실상, 각 업체나 SI업체에서 그렇게 고급인력을 찾지만 정착 필요한 인력을 구하기도 어렵다고 합니다.
제가 생각하는 미래의 개발자는 다음과 같이 몇가지로 나뉜다고 보입니다.
모든 개발자들이 꿈꾸는..
대우를 좀더 받으며..
가치있는 일을 할 수 있는 개발자가 되기를 원한다고 생각합니다.
단, 개발자보다는.. 사업을 하고 계신 분들은 일단 제외합니다.
이 분들은.. 이미 다른영역에 계신것이 아닌가 하네요. ㅎㅎ.
그리고..
사업관리 영역으로 빠진분들도 일단 제외...
일단..
단순 개발만 하는 경우에는..
보수가 그렇게 높으신 분이 적더군요.
그렇지만..
일단 기술적인 부분들만으로 대우를 받는 받는 분들이 몇분 계시더군요.
그런 분들을 몇개의 유형으로 분류해봤습니다.
1. 뛰어난 코딩 테크닉을 보유한 테크니션으로 각 업체나 공공SI의 스페셜리스트
생각보다 이러한 자리가 꽤 많이 보였습니다. 각 SI업체에서도 이러한 사람들을 정말 많이 찾더군요.
소프트웨어가 복잡해지면서.. 특히나 요즘같이 복잡한 아키텍쳐를 사용하는 곳에서는 개발 생산성이 최고 이기 때문에 이러한 테크니션을 꽤 찾습니다.
보수도 상당한 편이구요. 한번 이런 곳에서 소문나면.. 대기업에 스카웃되거나 좋은 보수로 상당히 일할 수 있습니다. 앞으로도 이러한 일자리는 계속 있으리라고 보입니다.
어차피.. 고급인력은 쉽게 나오는 것이 아니니까요.
보통 이정도 경륜에 다다르려면.. 최소 경력 6~7년 차에서.. 하나의 언어로 다양한 경험을 한 테크니션이 가장 큰 대우를 받더군요.
다만, 정시 출근, 퇴근을 하는 일반 셀러리맨처럼 하고 다녀야 하니까.. 그것이 조금 단점이죠.
2. QC능력을 갖추고 소스를 리팩토링할 수 있는 능력을 소유한 스페셜리스트
3. 다양한 서버 아키텍쳐를 인지하고 구사할 수 있는 아키텍쳐
4. 여전히 각광받고 있는 SQL 튜너나 SQL 모델링을 능수능락하게 구사하는 스페셜리스트
5. 객체지향방법론이나 UML과 관련되어 교육, 실제 구사, 문서 체크능력을 소유한 스페셜 리스트..
6. 순수하게 델파이 코딩과 관련된 컴포넌트 제작능력이 출중해서 컴포넌트만 만들고 유지보수하는 스페셜 리스트..
대충..
이러한 분들은.. 제주변에 계신.. 실제 존재하는 분들입니다.
실제 대우들이나 보수도 상당이 고가로 받으시는 분들이구요.
작게는 월 400 정도부터 많게는 월 1000에 호가하는 대우를 받으시더군요.
아!
시간당 20만원정도 받는 분도...
( 현재 받으시는 급여가.. 순수하게 인건비로... )
부러워라~~
위의 예를 들어서 보면..
제가 생각하는 개발자의 미래는 크로스오버입니다.
한가지 분야에서 나름대로 S급으로 성장하고..
다른 부분들을 A급으로 적당하게 채우는 거죠.
보통..
이렇게 성장하기 까지 과거의 경험으로 보면 10여년 정도가 걸리더군요.
한번..
이 경지에 도달하면..
우스운 소리로.. ?어들은 것이 많아서..
공부하는 것이 습관이 되어서...
이제는.. 플밍보다는..
주변의 잡다한 상식(?)만 늘어가는
이제는 '취미가 코딩입니다'라고.
남들에게 이야기햐에 겠네요~
쩝~~
대규모 업무프로그램을 개발할 경우에 UI설계를 너무 단순하게 생각하거나 너무 복잡하게 생각하는 경우들이 있는데, 저의 경우에는 이러한 부분들을 어떻게 구분하고 처리하는지 몇가지 정리해봤습니다.
도움이 되실지는 잘.. 모르겠네요. ㅎㅎ
일단, UI설계시에 많은 개발자들이 간과하는 것은 클라이언트 시스템과 데이터베이스, 화일시스템과의 빈번한 데이터 엑세스에 대해서 그렇게 심하게 고려하고 있지 않다는 것이지요.
저와 같은 경우에는 다음과 같은 규칙을 정하고 UI설계를 하는 편입니다.
기본규칙
1. C/S이건 WebService이건 Session을 Connect하는 방식이 아닌 명령을 수행하고 리턴하는 구조로 설계한다.
2. 최대한 한번에 많은 처리가 가능하도록 한다.
3. SmartClient의 경우에는 최대한 많은 조건을 체크하여 서버로 완벽하지 않은 질의나 대량의 질의를 발생시키는 자료를 호출하지 않도록 한다.
4. 대량의 자료를 다운로드 해야 하는 경우에는 서버에서 생산하여 클라이언트로 전송받는 구조를 사용한다.
( 대표적으로 Excel생산물의 경우에는 보통 표준 레포트 출력기능을 이용한다던지 한다 )
5. Touch Point를 잘 설계하여 최소화 한다.
( 이 TP라는 개념은 원래 CRM에서 사용하던 개념인데.. 저는 화면설계에 이 개념을 응용해서
많이 사용합니다.
필요한 자료를 Accessg하는 경우를 1 TP라고 정의합니다.
보통 필요한 자료를 계산, 접근, 처리 하기 위해서 여러번의 데이터베이스 질의나
처리를 하는데 궁극적으로는 이러힌 TP를 최소화하는 것이 주 목적이죠. )
결론적으로 최소한의 규칙은.. 서버의 리소스를 최소한으로 사용하면서 사용자의 UI상에서 최대한 빠르게 필요한 데이터를 작업하는 것이 UI 설계의 기본이라고 생각합니다.
그래서, 저같은 경우에는 UI설계시에.. 다음과 같은 기준으로 화면을 구분합니다.
Detail 0 : UMS, HTP, MTP, UMW
Detail 1 : SDS
이렇게 구분하는 이유는 UI설계시에 비효율적인 분석, 설계 문서를 최소화하고, 꼭 필요한 부분들만 정의하기 위해서 구분합니다.
Detail 1 의 SDS ( Simple Document Screen )
화면상의 UI흐름이 단순한 CRUD성인경우에 해당화면의 UI설계와 UI Control간의 상호처리 관계, 관련 Touch Point를 위한 계산식과 데이터처리(DML)을 기술하는 선에서 분석, 설계를 마무리합니다.
관련 산출물로는 UI 디자인, Control 흐름도, 관련테이블, 관련 SQL문장등과의 연결관계를 주로 서술하죠.
Detail 0 의경우에는 보다 상세하게 분석 설계합니다.
UMS ( User Meet Screen )
사용자들이 고객과 같은 사람을 상대하거나 속도가 요구되는 화면을 의미합니다. 이런 화면들은 은행창구나 공공기관의 민원인 상대화면이므로 해당 화면들은 정말 설계를 잘해야 합니다. 가장 민감한 부분이니까요.
HTP ( Heavy Transaction Point )
화면의 구성상에서 빈번한 데이터의 수정과 중간계산형식등을 통하여 하나의 완성된 데이터를 만들기위하여 복잡한 화면의 구성이 필요한경우.
보통 이러한 화면은 800~1000여개의 UI를 설계하는 경우 20여개의 화면정도가 나오더군요.
정말 어찌할 수 없는..
MTP ( Multiply Transaction Point )
특정조건을 단순 반복하거나 대량의 반복 처리하는 경우입니다.
이 부분은 분석은 단순하지만, 실제 서버의 리소스나 UI의 구성을 무겁게 하는 경우이기 때문에 이 부분들을 잘 체크해야 합니다.
UMW ( User Many Work )
사용자가 빈번하게 사용될 화면이라고 생각되어지는 화면들을 의미합니다.
저 같은 경우에는 이러한 화면들을 별도 리스트업하고 체크해서 실제 작업 공수를 더 많이 투여할 수 있도록 조정합니다. 실제 이러한 화면들이 가장 많은 유지보수를 거치게되고 수정과 에러를 엄청 발생시키니까요.
그리고..
저는.. 화면의 분석 설계시에 다음과 같은 부분들을 더 정의합니다.
작업화면은 Resize를 고려하는지?
데이터조회조건과 작업영역, 컨트롤 영역등을 명확하게 분리하는지?
데이터 Control은 몇개인지?
데이터 표시의 Area의 갯수는 명쾌한지?
작업화면을 시작할때에 몇번의 Touch Point가 발생하는지?
데이터 질의시 Touch Point를 더 줄일 수 있는지 체크.
레이아웃 디자인시에 조회조건, 필수항목, 참조항목등의 컨트롤이 명확한ㅁ지?
상호참조되는 컨트롤들이 존재하면 그 해결책은 없는지?
에러 발생시에 메시지를 업무와 연계하여 어떻게 명쾌하게 에러가 나오는지?
그리고. Touch Point의 설계시에 다음과 같은 부분을 고려합니다.
1. 하나의 컨트롤은 Was이든 DB Server이든 가능한 한번에 1 Touch Point를 발생하도록 합니다.
2. 1 Touch Point는 최장 2초를 넘기지 않게 설계합니다.
( 보통 CRUD성의 조건을 전달하고 첫번? 자료를 응답받는 순간을 의미한다. )
3. 2초를 넘기는 경우에는 서버가 존재하면 해당 모듈을 서버모듈화 한다.
하지만, 서버가 없으면... 메시지 처리나 쓰레딩 처리를 한다.
4. 각 클라이언트로부터의 동시 처리 용량은 5개 이상 실행하지 않는다.
보통 Was의 경우 쓰레드 갯수가 보통 50개 정도이므로 적정한 처리 리소스 갯수는
그때 그때 다르다...
머.. 주절주절 여러가지 글을 끄적거렸지만.
제가 생각하는 가장 중요한 개념은 TP입니다.
상당히 많은 델파이로 개발되어진 업무 소스를 보았습니다.
어떤 업무 프로그램들인 경우에는..
화면을 로딩하면서..
20 TP가 넘게 발생하기도 하도..
어떤 작업화면에서는.. 버튼 하나가.. 30 TP를 발생하기도 하더군요.
이벤트가 꼬여있기도 하고..
물론.. 당장의 C/S 프로그램에서는 문제가 없는 것 처럼 보일것이지만..
정말 많은 사용자들이 해당 서버에 붙어서..
작업을 취하게 되면.. 큰 문제를 많이 야기합니다.
흔히들.. 이런 경우에..
테스트는 몇대에서 문제없는데.. 실제 업무 몇백대에서는 문제를 일으키는 경우이죠.
아무리.. 서버가 좋아져도.. 이런 부분은 클라이언트나 서버 설계시에 중요한 체크사항입니다.
많은 초보 개발자들이 이러한 부분들을 간과하고 있어서..
조금 걱정되네요.
델파이든, 자바이든... 기본적인 원리는 변하지 않는다고 생각해요.
ㅎㅎ~
일단.. 오늘 간단하게 생각하는 내용들은 대충 이렇습니다.
다음 기회에.. 다음 글을..
서버OS : AIX
DB : Oracle
서버 프레임웍 : Spring ( or EJB ), iBatis
구체적인 목표를 달성하기 위해서는 서버사이드의 비즈니스 오브젝트를 자바로 구축하고
해당 자바객체는 Axis를 활용하여 WebService화 시킵니다.
이 부분은 서버영역에서 다양하게 개발되어 질 수 있으므로..
그렇게 중요하지는 않습니다.
다만.. SOAP Server형식으로 개발된다는 점만 주목하면 됩니다.
여기서...
전체적인 개발속도 향상을 위하여 SOAP Server로 구축되어질
서버의 Front 영역에 MOM으로 JMS와 유사한 서비스를 구축하여
Event Call방식으로 서버의 비즈니스 오브젝트를 구축하도록
하는 프레임웍들을 보통 사용합니다.
이 부분은 꼬옥 Rich Client를 사용하는 방식이 아니라고 하더라도
흔히들 사용하는 방식입니다.
이 방식을 사용하면..
서버의 영역은 필요한 프레임웍을 생성한 다음 해당 업무의 오브젝트들을
정해진 규칙에 따라 작업하고, 필요한 인터페이스 부분만 결정하면
서버의 개발에는 커다란 영향을 주는 부분이 존재하지 않게 됩니다.
클라이언트를 델파이로 선택하는 경우에는..
델파이의 UI의 기능을 적극적으로 활용하는 방법이 필요한데.
두가지의 가정을 두어야 합니다.
하나는 클라이언트에서 필요한 SQL문장이 존재하면서 서버사이드의 데이터 추출
을 통하여 처리하는 단순 구조를 처리하는 구조
둘, 클라이언트는 정말 단순한 프리젠테이션 역활을 하면서 데이터 조작에는
최소한 참여하는것.
가장 중요한 포인트는 클라이언트에서 서버로 접속하는 방식입니다.
간단하게 처리하는 방법은 SOAP Interface를 사용하는 방식입니다.
자바로 SOAP Server를 구성하고 WSDL을 클라이언트 측에 전달하여
연계하는 방식이죠.
생각보다 쉽고 간단합니다.
비즈니스 전반적으로 사용하는 방식으로도 괜찮습니다.
그러면, 보통 델파이를 사용하는 클라이언트에서는 데이터 처리를 어떻게 하는
것이 좋을까요?
가장 간단한 방식은 클라이언트에서는 SQL문장을 사용하여 DB에 접속하는 방식으로
비동기식으로 DB에 연결되었다라고 생각하고 프로그램을 구성하면 무방합니다.
보통 업무용 프로그램의 경우에는 데이터를 입/출력하는 경우가 대다수이니.
이 부분을 처리하는 방식이 가장 간단하죠.
델파이 내의 MIDAS나 SOAP, Snap등의 다양한 방법도 있고.
사용솔루션으로는
RamObjects, ASTA, kbmMW라는 제품군들로 다양하게 존재합니다.
다만, 서버의 OS가 Windows와 linux에 국한되어 있기 때문에.
국내의 비즈니스 환경이나 공공환경과 어울리지 않는다는 점이죠.
국내의 비즈니스 환경에서는 현재 서버 Side는 모두 자바로 구축되어 지고 있기때문에.
이 자바와 연계하는 방법에만 주목하면 됩니다.
개발하여보았던 방식은 두가지입니다.
1. EJB Component를 개발하고 WebService로 전환하여 WSDL을 통하여
델파이 Rich Client를 구축하여 프로그램을 구동하는 방법
2. Spring JAVA Component를 Axis기반하에 개발하고 Business Object를 컴포넌트하고
유스케이스와 이벤트 ID로 구분시킨후 단일 WSDL을 사용하여
Front를 통일 시킨 델파이 Rich Client를 구축하는 방법
3. 델파이의 TDataSet구조를 확장하여 서버사이드에 Spring기반의 프레임웍위에서
SQL과 SP를 직접 제어할 수 있는 비동기식 데이터 컨트롤 셋을 구현하여
델파이 Rich Client에서 손쉽게 SQL문장을 사용하여 업무를 구현하는 방법
이 방법들은 차근 차근 풀어보겠습니다.
Prev
Rss Feed