출처 : http://blog.naver.com/kimsoma/60013241839
이자료의 필자는 내가 아니라 웹 검색해서 찾아낸것입니다
--------------------------------------------------------------------------------
// 개발 분야 및 개발자의 분포 //
중소 규모의 벤처기업에서 펌웨어 제작을 위해 C나 어셈블리어, 퀵베이직등을 사용하여
프로그래밍을 하는 경우가 많았고, 특정 마이크로 칩을 사용한 프로그래밍에는
특정 회사의 PIC용 컴파일러를 사용되고 있다.
C++ 빌더와 VC++는 주로 하드웨어의 고속 제어용 프로그램을 개발하는 데, 사용되고 있다.
데이타 베이스 관련 사무용 프로그램에는 델파이, 파워빌더, 비쥬얼 베이직 등을 사용하여
구현한다. 비쥬얼 베이직 개발자가 많은 것은 툴 가격이 저렴한 영향이 크다.
델파이는 개발자 구룹에서 전문가 집단에서 사용하는 툴로 호평을 받고 있다.
필자가 구직하려고 보니, C언어쪽 개발자를 많이 찾게 된다는 사실을 알았다.
// 새내기의 개발 기업의 입사 후의 처세 //
기업내의 구성원 사이의 관계는 경쟁 관계이다. 자기의 스킬에 따라 승진, 급여,
구조조정 대상이 된다. 따라서, 동료직원 사이에는 수평선을 가지는 일정한
거리를 유지하는 것이 필요하다. 함부러 마음을 여는 것은 매우 위험한 생각이다.
대학내 동아리 처럼 선배가 인정으로 이끌어 주고 배우는 환상을 품어서는 안된다.
회사의 선배는 기업 이윤 획득이라는 공동 목표를 위해 필요한 만큼 조력을 받는 것
뿐이다. 내가 갖고 있는 각종 라이버러리를 회사 동료들에게 아낌 없이 공개한다고
해도 이러한 행위는 구조 조정시 아무 영향을 주지 않는다. 그 행위로 인사 담당자로부터
회사 기여도에 대한 평가를 받기는 무척이나 어려운 일이다. 그러나, CEO 주관으로
적극적인 지식정보시스템을 전사적으로 구축하려 할 때는 적당한 선에서 거기에
협조 할 필요가 있다. 모든 인간 관계가 그렇듯이 경쟁 관계에 있는 회사 동료라고
할 지라도 인간적인 관계를 맺는 것에 소홀이하지 않아야 한다.
구현 과정에서 적극적으로 회사 동료의 문제를 해결하여 주지 않더라도, 동료들과
어울리거나 대화하는 데 인색하지 않아야 한다.
인생 고민이나 자신의 약점을 의논 할 상대를 찾자면 동문 선배나, 회사 이외의
인생 선배나, 동호회 선배들로 부터 구하고 절대로 회사 동료들을 선택해서는 안된다.
필자가 개발자로서 비애를 느낀점은 프로젝트 때문이 아니라 자신의 개발 스킬을
위해 상대의 노하우를 다 빼냈다 싶으면 바로 해고 시켜버리는 악덕 업자들을 많이
보았다. 우리나라는 전체적으로 좁은 나라이며 개발자 간의 인맥도 매우 짧다.
따라서 특정 회사에서 깔끔한 일처리는 매우 중요하다. 나쁜 소문은 개발자 사회에
발을 딛지 못하는 결과를 가져온다.
개발자란 직업은 매우 고독한 직업이다. 그리고 잠이 부족한 직업이다. 이러한 이유는
프로젝트 메니저가 정확한 일정을 예측하지 못하고, 경영자는 개발기간 단축으로
인하여 인건비를 줄이려는 의도이다.
특정 툴과, 특정 분야에서 정통한 개발자라도 모든 개발 분야에서 전문가가 될 수는
없다. 그래서 자기가 취약한 분야가 있기 마련이며, 이것을 극복하기 위해서
오픈 마인드를 가져야 한다. 델마당 같은 동회회의 활동은 바람직하다.
// 사업계획서 작성요령 //
이 설명은 프로젝트 메니저나 프리랜서 개발자가 자영업을 하시는 데 도움을 드리고자
함이다.
1. 사업 계획서 목차
사업계획서 요약
기업 및 산업
사업 및 제품개요
시장 환경분석 / 상황분석
마케팅 계획
재무계획
조직 및 인적 자원 구성
고객 관리 계획
2. 기업소개
1). 회사일반개요
기업명
대표이사
사업영역
자본금
직원수
2). 기업의 비젼
3). 사업개념
비즈니스 모델
주요 사업 전략
향후 사업 전개 방향 :
1단계 : 고객 확보와 시장 점유율 상승
2단계 : 새로운 수익 사업으로의 확장
3단계 : 해외시장으로의 진출 모색
4). 주력 사업 아이템 소개
3. 사업 및 제품개요
1). 주요생산품
2). 주요사업 형태 및 비지니스 모델
3). 수익모델
4. 시장환경분석 및 상황
1). 국내시장 환경 분석 및 상황분석
2). 시장전망
3). 경쟁 업체 현황
5. 마케팅 계획
1). 경쟁우위전략
2). 고객창출을 위한 마케팅전략
3). 고객관리전략
4). 기업시스템 구축전략
5). 시장진입 및 성장전략
6). 예상 매출액과 시장 점유율 산정
6. 단계별 마케팅 전략
1). 시장진입전략
목표(사업목적, 제공서비스, 대상고객)
마케팅 전략(오프라인 마케팅 전략,온라인 마케팅 전략,온 오프라인 마케팅
2). 마케팅 운영 전략
고객세분화
목표시장선정(초반기,중반기,후반기)
포지셔닝
3). 고객 맞춤 마케팅 전략
초기 고객 확보
1:1 마케팅 전개
고객 데이타 베이스 활용
4). 고객유지 마케팅 전략
공유화전략
효율화전략(B2B 거래 마케팅,B2C거래형 마케팅,C2C 거래 마케팅,기업이미지홍보 마케팅)
7.경제성 분석
추정손익계산서=
평균구매액+예상구매고객수+매출원가율(30%)+(판매비/관리비=65%)+ 법인세(20%)
매출액+제조원가+매출총이익+판매비/관리비+세금 공제전이익+세금+순이익+현금흐름
8. 조직 및 인적 자원 구성
CEO(chief executive officer)
CFO(chief fiancial officer)
CTO(chief technological officer)
기술개발지원팀
마케팅홍보팀
비지니스 전략 기획팀
시스템구축/유지보수관리팀
9. 고객서비스
전화+방문+웹+전자우편+팩스=콜센터
// 방법론 탐구//
* 방법론의 프로세스
프로젝트 준비 - 환경분석 - 정보수집 - 집중분석 - 개선안 수립
프로젝트 준비 = 프로젝트 범위설정+요구분석+계획수립+사전정보수립
계획수립(구체적인 작업일정, 업무분장, 산출물정의, 작업방식,
문서화에 대한 계획수립)
환경분석 = 기술조사+관리환경분석
정보수집 = 관리정보수집
집중분석 = 구성분석+성능분석+장애분석
개선안수립 = 개선안 제시, 운영 및 관리체제 수립
// 개발자 직업의 딜래마 //
요즘은 평생 직장은 사라지고 평생 직업만 존재한다는 것을 여러분은 공감하실 것이다.
수 많은 경쟁력 속에서 살아 남아야하고 개발자나 기업 모두다 발전을 위해 새로운
변화에 도전해야만 한다. 새로운 인력의 재배치는 항상 옳은 것만아니다.
인간이란 조직 속에서 바라는 대로만 통제가 이루어지지 않고 언제나 변수가 존제한다.
자기 개발이나 고임금에 스카웃되어 심할정도로 직장을 바꾸는 결과과 항상 좋지
못했다. 보유 스킬은 많지만 기업이나 개발자 모두의 욕구를 충족시키는 경우가
드믈었다. 이러한 변화의 환경속에서도 묵묵히 저급여에도 직장을 옮기지 않고
묵묵히 성실하게 근무하는 직장인도 필요하다는 사실을 깨달앗다.
우리 개발자가 JOB을 찾아 해매이다 보면 개발자란 직업에 대한 미래에 대한 불안과
근본적인 생계 유지에 어려움이 많다는 것이다.
그래서 선배 개발자들이 제안하는 게, 많지는 않더라도 정기적인 수입을 올리는
아이템을 찾으라는 것이다. 그런데, 이것은 말처럼 쉬운일이 아니다.
비록 인기가 많고 성공적인 프로그램을 개발한다 할지라도 불법 복제를 하는 CD판매
업자들 때문에 수입에 한계가 있다. 이것을 극복하기위해 고안한 것들이 네트워크
게임류이다. 비록 크랙되어 널리 퍼진다하더라도 네트워크 접속을 해야하고, 많은
기능을 서버를 통하여 서비스한다면, 망 운영 측면에서 수익을 올리는 것이다.
지금, 필자는 취업을 위해 작년부터 준비해왔지만 지금도 해매고 있다.
안정적인 직장을 찾고 싶다.
// 프로젝트 메니저에 대한 몇 가지 오해 //
지금은 전산 전공자도 아니고 그리고 개발자도 아니고 그리고 코딩 능력을 갖춘 것은
아니지만 서울대 졸업하거나 토익 등 영어 실력이 좋으면 약 4주 정도의 교육을 시켜
프로젝트 메니저로 채용하는 것이 국내 개발 기업의 현실이다.
그럼 미국에서 생각하는 프로젝트 메니저란 무엇인가?
프로젝트 메니저란 코더로서 다년간 구현 능력을 쌓고 개발툴이나 로직등 개발 전
분야에 걸쳐 다양한 능력을 갖고 있어서 프로젝트의 위험성을 잘 알고 있고,
프로젝트 완료 기간을 정확히 예측이 가능할 정도로 안목이 생기는 사람을 말한다.
프로젝트 메니저가 되기까지 몹시 까다롭단 이야기이며 이들의 몸 값도 비싸단
이야기이다.
우리나라에서는 특정 시스템을 구현 할때 어려움을 겪게 되면, 프로젝트 메니저가
해결하는 것이 아니라, 이것의 구현 경험이 있는 개발자를 채용하여 해결하려한다.
그리고 이전 개발자가 잘하는 구현 기능에 대해선 그 개발자에게 다시 의뢰하려고
한다. 이미 해고된 이후에 그렇다.
// 프로젝트 메니저의 역할 //
* PMI 홈 페이지 : http://www.pmi.org
* 프로젝트 관리의 필요성
1. 비용과 투입공수가 착수시에는 낮으나 시간이 흐를수록 점점 높아지다가
종료시점에서는 급격하게 떨어진다.
2. 프로젝트 성공의 가능성도 처음에는 매우 높으나 점차 높아지게 된다.
3. 이해당사자들의 영향도도 처음에는 매우 높으나 점차 낮아지게 된다.
4. 변경비용과 에러수정노력은 시간이 흐를수록 점차 높아진다.
* 프로젝트 관계자
1. 프로젝트 관리자
2. 소프트웨어를 사용 할 사람이나 조직
3. 개발 인력을 파견 및 고용하는 용역회사.
4. 최종 사용자인 개인/조직의 관리자는 최소의 원가에 최대의 이익을 기대한다.
* 프로젝트 단계의 구분은 산출물 완료 시점으로 한다.
* 프로젝트의 처리요소
1. 입력물 : 문서나 문서화가 가능한 항목들
2. 도구와 기법
3. 입력물을 출력물로 변환하는데 사용되는 메카니즘
4. 출력물 : 프로세스의 결과로 산출되는 문서등
* 프로젝트 메니저가 해야 할 업무
1. 프로젝트 통합관리
프로젝트 개발기획 =
입력(다른 프로젝트 산출물,조직의 정책, 제한사항, 가정) +
도구(방법론, 프로젝트 관리 시스템) +
출력(프로젝트 계획서 )
프로젝트 기획의 실행 =
입력(프로젝트 계획서, 조직의 정책, 수정 요구 사항) +
도구(업무처리절차, 제품 기술과 지식 ) +
출력(작업결과서, 변경요구서)
요청사항처리 산출물 =
입력(프로젝트 계획서, 변경 요청서 ) +
도구(변경관리시스템, 추가 계획, 프로젝트 관리시스템 ) +
출력(프로젝트 계획변경서,변경요구서 )
2. 프로젝트 범위관리
프로젝트 범위 도입 =
입력(제품기술서,전략계획서 ) +
도구(프로젝트 선정방법론 ) +
출력(프로젝트 관리서, 제한사항서)
프로젝트 범위 기획 =
입력(범위기술서,제한사항, 다른 프로젝트 산출물) +
도구(분할기법 ) +
출력(...)
프로젝트 범위 정의 =
입력(범위기술서,제한사항, 다른 프로젝트 산출물) +
도구(분할기법 ) +
출력(...)
프로젝트 범위 검증 =
입력(작업결과서,제품설명서) +
도구(조사기법) +
출력(인수 공문)
프로젝트 범위 변경 =
입력(변경요청서, 범위관리 계획서) +
도구(범위관리시스템,추가계획) +
출력(범위변경서,수정요청서)
3. 프로젝트 일정관리
프로젝트 실행정의 =
입력(제품기술서,전략계획서 ) +
도구(프로젝트 선정방법론 ) +
출력(프로젝트 관리서, 제한사항서)
프로젝트 실행순서 =
입력(범위기술서,제한사항, 다른 프로젝트 산출물) +
도구(분할기법 ) +
출력(...)
프로젝트 실행결과 =
입력(범위기술서,제한사항, 다른 프로젝트 산출물) +
도구(분할기법 ) +
출력(...)
프로젝트 일정계획 =
입력(작업결과서,제품설명서) +
도구(조사기법) +
출력(인수 공문)
프로젝트 일정통제 =
입력(변경요청서, 범위관리 계획서) +
도구(범위관리시스템,추가계획) +
출력(범위변경서,수정요청서)
4. 프로젝트 비용관리
5. 프로젝트 품질관리
6. 프로젝트 인적자원관리
7. 프로젝트 의사소통관리
8. 프로젝트 위험관리
9. 프로젝트 진행관리
* 프로젝트 프로세스 = 착수 + 계획 + 실행 + 통제 + 종료
* 프로젝트의 관리
1. 통합관리 = 프로젝트 계획서 작성 + 프로젝트 수행 + 프로젝트 변경통제
2. 범위관리 = 프로젝트 요건파악 + 업무범위선정, 방법론선정 +
업무범위 확인 및 유지+ 업무범위 통제
3. 일정관리 = 공정계획수립(공정파악,스케쥴작성)+일정통제
4. 원가관리 = 원가산정 + 예산집행계획 + 합의 및 승인 + 경비 투입관리 +
예산집행통제(원가+인건비+경비)
5. 품질관리 = 품질보증계획수립 + 표준 및 절차수립 + 테스트계획 +
문서, 소스코드관리 + 결함보고
6. 인력관리 = 조직화 + 인력운영(교육,근태, 인사관리)+인력파견,해지,스킬등록,
7. 의사소통관리 = 의사소통절차수립+회의, 착수, 중간,완료보고+주간,월간,수시보고
의사결정요청,변경요청
8. 위험관리 = 위험파악 및 대응방안 수립 + 문제보고
9. 외주관리 = 외주계획수립,외주인력요청,외주인력선정,외주비용지급+외주인력평가+
외주업체평가+계약종료
// 인터뷰하는 요령 //
지금 설명하는 내용은 실무에서 사용된 내용이므로 그대로 사용하지 마시고
기업 특성에 맞게 수정하여 사용하시기 바랍니다.
1. 인터뷰의 준비
인터뷰의 목적을 명확화 할 것 .
인터뷰 대상자 확정후, 대상자 상사에게 사전 합의를 얻을 것
인터뷰 대상자의 상사로부터 인터뷰 대상자에게 책임,의무를 알릴 수 있도록 유도.
2. 인터뷰 요청 공문 발송.
반드시 먼저 전화 통화로 고객에게 인터뷰 계획을 의논한다음 즉시, 팩스로
문서 공문을 발송해야 한다.
전화 통화시 녹음기 사용을 양해를 구하고 고객의 허락을 받아야한다.
녹취하지 않음으로써 수 많은 분쟁이 고객과 발생한다.
사실 브로커와 계약시에도 녹취는 훌륭한 도구가 된다.
인터뷰는 프로젝트 메니저 혼자하면 안되고 2명이 한다. 한명은 인터뷰를
다른 한명은 협의 내용을 기록한다.
3. 인터뷰 요청 공문의 형식
To: 이름,제목,소속부서 Date: 오늘날짜
From:이름,프로젝트명
인터뷰일자,시간,장소
목적
가능하면 프로젝트 요약설명, 인터뷰 주제
인터뷰 목적을 기술하고 항목 기술함
토의하기를 원하는 토픽 리스트
특정 질문
의문 사항이 있으면 저에게 전화부탁드립니다.
고객의 질문 사항시 연락처를 남김
* 마케팅 이윤의 책정 : 제조 30% + 판매 10%
// 도움이 되는 글들 //
* 고난이도의 프로젝트를 실행하기 위해서는 특별한 기획 및 실행기법이 필요하다.
* 프로젝트를 주어진 시간과 예산 범위 내에서 실행하지 못할 경우
이와 관련된 단기적 및 장기적 비용을 정확하게 산출해야 한다.
* 일은 스스로 만들어 하는 것이지 주어지는 것이 아니다.
* 일이라는 것은 솔선수범하여 '적극적으로 해 나가는 것'이지 결코 수동적으로 하는 것이 아니다.
*'큰 일'과 맞서라. 작은 일은 자기 자신을 작게 만든다.
*'어려운 일'을 목표로 하라. 이것을 이루어 내는 곳에 진보가 기다린다.
* 일단 맞붙으면 '놓아주지 마라' 목적을 완수할 때까지는 죽어도 놓아주지 마라.
*'일을 끌고 가라' 끌고 가는 것과 끌려 가는 것은 엄청난 차이가 있다.
* "계획"을 세워라. 장기적인 계획을 갖고 있으면 여유와 희망이 생기고 인내심도 갖게 된다.
*'자신'을 가져라. 자신이 없기 때문에 일에 대한 추진력도 끈기도 그리고 성의마저 없는 것이다.
* 두뇌회전은 언제나 '풀 가동'으로 하라. 한 치의 빈틈도 있으면 안 된다.
* 마찰을 두려워하지 말라. 마찰은 진보의 어머니요, 적극성의 비료이다.
마찰을 두려워 하는 자는 비굴하고 뒤쳐지게 된다.
// 프로젝트 완료 보고서 작성 요령 //
지금 설명 드리려고 하는 내용은 실무에서 사용된 내용이므로 그대로 사용하시면
안되고 독자가 알맞게 커스텀마이징하면 된다.
1. 기본 프로세스 흐름도.
2. 코드구성 : 시스템에 사용된 코드 목록.
3. 파일구성 : HDD상의 실제 디렉터리 이름 및 파일명 목록표
4. 테이블 구조. : E-R 다이어그램도
필드명칭+자료형태+NULL유무 형식으로 작성
5. 화면설명서
6. 사용자 매뉴얼.
7. 프로그램 소스코드.
8. 개발일정표 : 월별 개발일정표
9. 개발비 산정표.
프로그램 스텝 = 분류+소스코드파일명+세부기능+라인수 형식으로 작성
디자인 : 이미지(그래픽),
난이도+소스파일명+세부기능+총 수량 형식으로 작성
* 개발용역비 = 소프트웨어개발비 + 시스템운영환경구축비 + 데이터제작비 +
자료입력비 + 정보전략계획수립비
* 소프트웨어개발비 = 직접인건비 + 직접경비 + 제 경비 + 기술료
* 직접인건비의 산정 : 프로젝트형태 + 개발언어 + 규모 + 적용대상규정 +
정보처리형태에 따른 보정계수 산출
// PM직의 승낙 //
재무 구조가 튼튼한 기업에서 근무 중인 개발자가 PM직을 권유 받으면 승낙하시기
바란다. 일반적으로 PM직은 고도의 전문성을 요구한다. 그러나 이러한 PM직은
외국계 개발회사에 해당되는 일이고, 일반 기업에서는 명확한 기준이 없고
애매모호하다. 즉, PM직의 원래 기능보다는 거의 인력 관리 수준에 머물러 있다.
채용하고 짜르고 악순환이다.
// 윈도우 운영체제의 보안 //
윈도우 운영체제는 우리에게 경이의 대상이다. 너무 친숙해서 그런지 모른다.
hacker,decker,cracker 등 수 많은 사람들의 표적이 되었다.
아무튼 지금은 수 많은 보안 패치가 이루어 졌지만, 항상 보안 패치보다 침입이
앞서고 있다. 기상천외한 방법으로 윈도우 운영체제를 공격하지만 이 방법이란게
일반화 되지 않고 특수한 계층의 사람들만 알고 있다가 이것이 많은 사람들에게
알려지면 패치가 되어지곤 했다. 아마도 그 중의 하나가 윈도우 98의 공유 폴더에
대한 암호 해독이 그것이다.
요즘에 특이한 방법으로 윈도우 운영체제를 공격하는 방법으로는
님다 바이러스를 이용한 침입,
자사의 홈페이지 로그인 하는 유저들 대상으로 접속 클라이언트의 로그인 창을 클릭
햇을 때 클라이언트의 보안을 해제하는 방법,
스파이웨어 CuteFTP, FlashGet, GetRight, 또는 RealPlayer 등의 루트를 이용하여
재 침입하는 방법...
애플릿, 인터넷 익스플로러의 자바 스크립트, 비쥬얼 베이직스크립트를 이용한 침입방법,
그리고 보안 패치가 되었지만 쿠키를 이용한 침입이 유행하고 있다.
// 공장자동화와 산업용기기의 제어 //
공장 자동화 뿐만 아니라 각종 산업용 기기의 제어용 프로그램을 개발할 경우가 종종
생긴다. 주로 수요처는 자본금 1억 이하의 벤처기업이다.
혹은 특허 제푼의 시제품 제작을 위해 제어용 프로그램을 필요하게 되었다.
이 기업들은 개발자에게 개발 비용을 지불 할 능력은 없지만 산업용 기기 제어용
프로그램 개발이 필요하게 된다.
우리 개발자들도 생계를 위해서 이 분야도 공부해야 한다.
아무래도 전기/전자 전공자에게 유리하다 할 것이다.
동전교환기, 계수기, 바코드 프린터, 마우스, PLC 등등 많은 기기들은 주로 베이직,
어셈블리어, C언에 의하여 컴파일 된다. 베이직은 우리가 아는 비쥬얼 베이직이
아니라 초창기의 Z8086/8088A CPU를 위한 베이직으로서 예를 들면 MS의 QUICK BASIC
을 사용하면 매우 정교한 제어용 어플을 맹글 수 있다. 컴파일 옵션을 잘 사용하면
실행 파일의 크기를 많이 줄 일 수 있다. 음, 컴포넌트 기반이 아니면서 어셈블리어
수준으로 코딩이 가능하며 유지 보수하기도 쉽다.
베이직으로 게임의 종류인 아케이드를 코딩하신 경험이 있는 분들이라면 많이 공감하실
겁니다.
그러나 요즘은 마이콤 개발의 추세와 고속 제어 처리를 위해선 어셈블리어로
코딩하는 경우가 많으며 요즘은 C로 코딩하는 경우가 많아졋다.
많은 경우에 CPU 롬에 HEXA CODE를 기록 할 때, 롬 리이더가 읽지 못하게 혹은 개발
기술을 보호하거나 컴파일러 회사에 라이센스료를 지불하지 않기 위해 암호화하는
경우가 많아졌다.
// NL 차트의 이해 //
업무 분석 단계에서 사용된 도구는 여러 가지가 있다. 지금도 FLOW CHART(흐름도)를
사용하는 경우가 많다. 그러나, 조직화된 개발 팀에서는 일반적으로 MS의 VISIO2000를
사용하여 DFD(DATA FLOW DIAGRAM)를 그리고 이것을 통하여 개발자간 의사 소통을 한다.
그러나 이것도 프로젝트 일정 때문에 잘 지켜지지 않는다.
설계 없이 곧바로 구현하는 경우가 많고, 보고서 및 설계서, 제안서등은 거꾸로 구현이
완료된 뒤에 만들어지는 경우가 많다. 이것은 분명이 잘못된 것이다.
미국이나 인도의 개발자들은 프로젝트 메니저의 개발 설계서를 보고 의견을 나누거나
독특한 도구를 사용한다. 그럼, 실무에서 사용하는 이 도구는 무엇일까?
독자는 매우 궁금해 할 것이다.
이것을 설명드리기 전에 마인드 맵을 들어 보셨는지? 이것은 우리의 맘 속의 생각을
빠르고 용이하게 기술하기 위한 기법으로 서점에 가보면 관련 서적들이 많이 있다.
이것을 약간 응용된 것으로 먼저 핵심 시스템을 박스로 묶고 박스안에 시스템 명칭이나
고려 대상을 적은 다음에 이 박스에서 수직선을 그어 내린다. 마치 일정표 처럼
만들어 지는 데 수직선 사이에는 흘러가는 정보나 방법등을 기술한다.
글로 설명해 드리려하니 얼른 감이 잡히지 않을 것이다.
대형 팀 프로젝트 수행 경험이 있는 분이나 외국계 개발 회사에 근무한 경험이 있는 분은
곧 바로 제가 무엇을 설명하고 있는지 이해 할 수 있을 것이다.
편의상 필자가 이 도구를 NL 차트라고 이름을 붙였으나, 사용해 보면 여러모로 유익하다.
정보공학 산출물을 만드는 데도 매우 유익하다.
// 국내 소프트웨어개발기술의 동향 //
정확한 통계를 제시하지 못하지만 그 동안 경험으로 국내에서의 소프트웨어 개발 기술은
주로 LG-EDS TEAMS과 삼성SDS TEAMS 기술이 산재하여 있다는 것을 알 수 있다.
물론 대형 SI 업체의 기술이라 업체간의 협약으로 노하우 비밀유지 계약 때문에 일반
개발자에게 알려지는 것은 불가능한 일이다.
추측해 보면 상기 개발회사 출신의 개발자가 고용 안정이 되지 않아 자주 자리를
옮기는 것으로 풀이된다.
지금은 IMF 이후와 KOSDAQ 붐으로 인하여 개발 팀들이 많이 해체되어 버렸지만,
소프트웨어 개발 기술이 척박한 이 땅에 땀을 흘린 분들을 생각하며
유솔로몬이 끝없이 존경하는 마음을 표한다.
초창기 우리 개발자는 전산실의 서버 관리자로서 단순 업무 때문에 개발에 필요한
시간이 생겼지만 지금은 옛날 일이 되어 버리고 많았다. 대신에 일반 잡무가 개발자에게
부여 되었다. 기획, 일반사무, 하드웨어 유지보수 까지 등등...
고급 개발자로서 C나 어셈블리어로 펌웨어 즉 장치 구동드라이버 소프트웨어 개발하는
경우가 있는 데, 국내에서 20여명 안팍으로 추산된다. 이 분들의 동향은 주로 대기업이나
프리랜서, 혹은 자영업하는 경우가 있었다.
아주 특이한 경우를 보았는 데, 게임을 개발 할 때, 컴파일러를 사용하지 않고 HEXA 에디터를
사용하여 직접적으로 기계어로 코딩하는 경우를 보았다. 필자로서는 이해가 가지 않는 일이었다.
또 한가지는 유닉스 기반의 오라클 데이타베이스를 shutdown하지 않고 손상된 레코드를 백업을
사용하지 않고 그 손상된 모듈을 기계어로 코딩하여 붙이는 경우가 있었다. 경이로운 일이다.
// 최고 경영자가 삼성SDS 출신이거나 삼성SDS에서 분사한 벤처기업에 취업하려고 할때//
프로젝트 메니저로서 구인 공고를 하는 경우에는 프로젝트 메니저 자신에게 매우 유용하다.
일반 직원이 회사 인사 정책에 관여하는 경우는 매우 드물고, 회사에서 자신의 위치가
인사에 관여 할 정도가 되면 자기 개발에 매우 유용하다.
즉, 프로젝트 메니저란 위치가 회사를 위해서가 아니라 자기 개발을 위해서 매우 중요하다.
그 이유는 입사 지원한 고급 개발자중에서 특정 분야에 대한 개발 인력의 인적 사항을 확보가
가능하고, 프로젝트 메니저 스스로에게 취약한 기술 분야에 대하여 인터뷰를 통하여
동종 경쟁 업체의 기술을 빼낼 수도 있고, 광범위한 테크니컬 로드 맵을 그릴 수 있다.
그리고 정보 통신 흐름을 파악 할 수 있는 기회를 제공한다.
그런데 특이한 점은 이러한 사항을 최고 경영자는 모르는 경우가 많다는 것이다.
다음 사항은 여러 분이 프로젝트 메니저로서 입사 지원할 때 준비해야 할 일반적인 사항이다.
예시로 회사 규모로보면 직원 수 100명에 코스닥 등록업체인 경우로 설정했다.
여러분도 잘 아시는 바와 같이, 삼성SDS는 매우 보수적인 기업이다.
보수적인 기업이라 함은 공무원 사회와 정신적인 기조가 비슷하다는 의미이다.
물론 사무적인 기조는 최첨단이다.
삼성SDS 출신의 최고 경영자는 인사 문제에 있어서 매우 보수적인 성향을 따른다.
경영자 스스로 그것을 탈피하려 하지만 뼈속 깊이 잠재적으로 그 사상이 심어져 있다.
아마도 삼성SDS 사내의 인력양성 프로그램 영향으로 보인다.
삼성SDS 출신의 CEO는 인력 채용시 4단계 이상의 까다로운 절차를 거친다.
1. 서류전형
요즘 추세가 개발자의 사내 양성이 아니라 현장에 곧바로 투입 할 수 있는 인력을
찾기 때문에 실무 경력자를 우선시한다.
프리랜서인 경우에는 인력파견업체의 사장님이나 최종 사용자의 추천서를 받아두는 게
좋습니다.
추천서에는 추천인의 연락처를 명기하여 구인 업체에서 확인이 가능하도록
합니다.
2. 직무적성검사(프로그램머 직무능력검사)
삼성SDS 출신의 CEO는 이것을 매우 중요하게 생각합니다.
비록, 비경력자라도 적성검사에서 좋은 점수를 받게 되면 채용하는 경우가 많습니다.
적성 검사 방법으로는 현장에서 얻는 실시간 데이타 또는 표를 보구 이 자료를 이용하여
역으로 정보 가공 및 분석, 추론을 할 수 있는 능력을 평가합니다.
이것은 일반 개발자라면 쉽게 습득 할 수 있습니다. 연습하면 향상 됩니다.
즉, 전산 수치해석을 의미합니다.
이 검사는 한국SHL에 의뢰하여 실시하므로 한국SHL 홈페이지를 방문해 보는 것도
유익한 일이다.
삼성SDS에서 이것을 중요하게 생각하는 이유는 아더엔더슨 컨설팅 및 SAP등 외국계
개발회사에서 객관적 평가를 위해 이러한 질문지 도구를 사용하기 때문이다.
3. 면접
삼성SDS 출신의 CEO는 인사 문제에 대하여 정형화 되어 있습니다. 따라서 매우 보수적인
성향을 따릅니다. 첫 인상, 발표하는 태도, 성격, 입사햇을 때 다른 사원간의 인화력등을
살펴 봅니다. 역시 임기응변이나 융통성이 강한 것을 선호하기도 합니다.
4. 연봉
입사 지원자가 사규에 따라서 급여를 받겟다 하더라도 희망연봉을 물어봅니다. 아마도
급여로 인한 불만을 사전에 감쇄하려는 의도입니다. 사전에 입사하려는 회사를 탐방하여
급여에 대한 초급 급여, 인사제도에 대한 자세히 조사를 할 필요가 있습니다.
뛰어난 개발 능력을 보유하고 있더라도 고액 연봉을 요구하는 경우에는 수용하지 않는다.
5. 비지니스 영어
삼성SDS 출신의 CEO는 영어 실력을 매우 중요하게 생각합니다.
해외출장 갔을 때, 호텔에 체크인, 체크아웃하는 방법, 호텔 프런트에 남겨진 전화 메시지
독해하는 방법,정보통신 기술적인 사항을 미국인 개발자와 직접 논의할 정도의 회화구사능력
6. 기타사항
실제 채용 의사가 없으면서 프로젝트 위험 때문에 비상시 구인하기 위한 인적사항을
수집하는 경우도 상당히 많다.
사내 아이템이 동종 업계인 경우엔 상대편 회사의 기술을 빼내기 위한 인터뷰로
활용하는 경우가 많다. 이것은 제가 입사 지원시 저와 함께 집단 면접을 보신 분에게
상대 경쟁 회사의 규모, 시스템 구성에 대한 예리한 질문이 있었다.
// 면접시 예시문제 //
1. 당신이 전 직장에서 퇴직하는 사유가 무엇인가요?
2. 당신이 CEO라면 프리랜서를 어떻게 관리하겠습니까?
3. 3분동안 자기 소개를 해보세요?
4. 3분동안 자기 PR을 해보세요?
5. 영어로 자기 소개를 해보세요?
6. 영어로 컴퓨터의 보안에 대한 기술 사항을 외국인과 함께 논의 가능합니까?
7. 희망 연봉은 얼마입니까?
8. 지방으로 파견냈을 때 근무 의사가 있습니까?
9. 지금 발령을 낸다면 언제 출근이 가능합니까?
10. 당신은 연령이 많은 데, 나이가 적은 상사와 인화문제,
개발 과정에서 사고의 유연성에 대하여 어떻게 생각하는가?
11. 당신이 우리 회사에 입사한 동기는 무엇인가?
12. 당신은 지금 직장에 근무 중입니까?
13. 우리가 당신을 채용한다면 언제 근무가 가능합니까?
14. 당신의 현주소는 어디입니까?
// 개발 아키텍쳐의 개념 //
tier : 어플리케이션 아키텍쳐를 논리적으로 구분하기 위해서 사용하는 용어.
2-tier 아키텍쳐 : 클라이언트/서버 어플리케이션의 하나. 두 개의 tier로 구성.
주고 받는 것 : SQL, FTP, HTTP
클라이언트 : GUI(Graphical User Interface)를 담당. 비지니스 로직을 처리
서버 : DBMS나 기타 Legacy System에 해당하는 서버.
3-tier : 클라이언트 : GUI(Graphical User Interface).
Middle-tier : 비지니스 로직을 처리.
서버 : DBMS나 기타 Legacy System에 해당하는 서버.
TP (Transaction Processing) Monitor : Tuxedo(BEA), Encina(IBM)
CORBA (Common Object Request Broker Architecture)
OTM(Object Transaction Monitor) : M3(BEA사), OrbixOTM(Iona사),
Visibroker ITS(Inprise사), TPBroker(Hitachi사)
// 어플리케이션 서버의 정의 //
분산 객체, 분산 트랜잭션, Component 모델을 제공함으로써 N-tier 구조의
어플리케이션을 쉽게 개발하고 운용할 수 있도록 해 주는 소프트웨어
플랫폼이라고 할 수 있다.
어플리케이션 서버에서 어플리케이션은 보통 Component로 개발되기 때문에
어플리케이션이라는 용어 대신 Component라는 용어를 직접 이용하는 경우가 많다.
================================================================================
*********************************************************************
[입문자를 위한 ] 미니프로젝트실무
*********************************************************************
이 자료는 지적재산권 보호를 받습니다.
개인이 개발과 관련된 연구 목적 또는 자기 개발의 목적으로 활용이 가능하지만
무단으로 배포하거나 타 게시판에 게시하지 못하며,
상용이나 영리를 목적으로 인쇄 및 배포를 금합니다.
이 글 내용의 일부분 또는 전체의 무단 전제를 금합니다.
----------------------------------------------------------------------
이 글은 대한민국의 지적재산권, 저작권 관련법의 보호를
받습니다.
이 글을 델마당, 한국델파이개발자연합, 델파이코리아 등의 게시판에
게시했다하여,
상업적으로 이용 또는 부분 및 전체 복제를 허여하는 것은 아닙니다.
즉, 묵시적으로 허용하는 것이 아닙니다.
이것은 자유 게시판에 공개된 글이라도 상업적으로 이용 가능하다는 의미가
아니며, 어떠한 경우라도 상업적으로 이용이 불가함을 알립니다.
이 글의 저작권은 유 솔로몬에게 있습니다.
Copyrights,2002,By ds4byw, All rights reserved.
초 판 : 2000. 7. 6.
최종수정 : 2002. 6. 26.
유솔로몬 (ds4byw@hanmail.net Tel 011-645-9006)
******************************************************************************
이 문서는 텍스트 포맷이며 윈도우 보조프로그램 워드패드에 최적화 되어있습니다.
" 이 문서의 수정판은 델마당 개인게시판 메뉴에서 유솔로몬 게시판에 게시됩니다."
http://www.delmadang.com/solomone
******************************************************************************
유 솔로몬은 이 글 내용 및 기법을 이용하여 제작한 프로그램이 데이타 손실 및
파괴에 대하여 민형사상 책임지지 않으며 사용자의 책임임을 알립니다.
따라서,유 솔로몬은 어떠한 경우에도 귀하에게 보증을 드리지않으니 사용에
주의하시기 바랍니다.
이 글을 대한민국에서 소프트웨어 개발을 하시는 이름모를 개발자님들과
이미 늦어버린 나이에도 개발 기술을 취득할 기회를 허락하여 주신 존경하는
박사님들과 얼굴은 모르지만 전화를 통하여 아낌 없는 도움말과 조언을 주신
한국과학기술원 연구원님들 그리고 필자에게 실무에서 아낌 없이 지도 편달을
주신 개발팀장님들께 충심으로 감사 드리며 바칩니다.
********************************************************************************
대한민국의 소프트웨어 개발 분야의 진흥이 되길 빌며...
델파이란 가공할 만한 고성능의 툴에 아낌 없는 찬사를 보내며 ...
"우리는 델파이란 툴을 사랑합니다."
델파이란 툴을 개발한 볼랜드의 델파이 개발 TEAM에 겸손한 마음으로 경의를 표한다.
델파이가 설치된 컴퓨터에서 델파이를 실행한다음 about 메뉴를 클릭한다음
alt키를 누른 상태에서 TEAM이라고 타이핑 하면 TEAM 이름이 나온다.
델파이코리아 만세! 델마당 만세! 한델만세!
http://www.delphikorea.com
http://www.delmadang.com
http://www.delphi.co.kr
*********************************************************************
// 들어가는 말 : 이 글을 쓴 동기 ~ //
필자는 수 십년 동안 컴퓨터와 함께 하면서 직업적인 프로그램머가
되려고 하면서 기업에서 실무 경력자를 선호하는 현실과 벤처기업에
발자취를 남기며 실무 현장에서 평소에 느낀 점이 많았다.
개발자들이 현장 실무에서 느끼는 고뇌와 최악의 근로 조건에서 처절한
자기 자신과의 싸움 그리고 소프트웨어 공학과 정보공학의 개념에
낮설은 우리 나라에서 이치에 맞지 않는 역현상들이 많이 발생하여
이러한 점을 안타깝게 생각하여, 수 많은 사람과 접촉하고 인터뷰한
결과를 기술하는 마음으로 이 글에 담았다. 이의가 없는 한,
아더엔더슨 컨설팅 회사와 SAP라는 회사가 보유하고 있는 노하우가
소프트웨어 개발에 있어서 훌륭한 길잡이가 됨을 의심하지 않는다.
이 글을 길잡이 하여 초등학생으로 부터 대학교수 까지 손쉽게 소프트웨어
개발이 가능하길 바라며 지적재산인 소프트웨어 분야가 기술적으로
다른 나라에 종속되지 않기를 바라는 마음 간절합니다.
짧은 실무 경력이지만 초보 델파이 개발자에게 도움을 드리기위해 이 글을 씁니다.
초보자가 초보자를 위해 글을 쓰는 일은 부담되는 일입니다.
이 글은 초보자를 위해 쓰여지지만 표현이 난해하고 어려운 용어가 사용 될 수 있으며,
주관적인 생각들이 강하므로 이 글에 대한 댓글이나 질문은 정중히 사양합니다.
이 글과 관련하여 절대로 연락하지 마세요.
어떠한 질문이나 메일, 문의 등을 사절합니다.
필자는 이 글을 열람하시는 분들께 답변할 의무는 없으며,
귀한 시간을 거기에 투자해야 할 어떤 이유가 없습니다 .
이 글의 내용 중에 특별한 경우를 제외하고는 특별히 예시를
않더라도, 사용되는 용어는 각 회사의 등록상표임을 밝힘니다.
그리고,이 글을 열람하시는 독자분들께 연재 약속을 드리지
못합니다. 다만, 개인적인 흥미로 틈틈이 글을 쓰려고 합니다.
필자는 1985년 고3부터 프로그램밍을 취미로 처음 시작했으며, 공식 경력은 4년
비공식 실무경력 5년 이상의 개발자이며 현재는 IT 분야의 컨설턴트입니다.
제 나이가 우리나라 개발 문화에서는 황혼기라고 할까요.
항상 프로그램밍에 들어가면,필자가 실무 경력자이지만 착잡한 기분을 감출 수가
없습니다..
이 글의 만약 독자분이 30대이시고 마땅한 직업이 없어서 프로그램 개발에
도전하려고 한다면, 필자는 강경하게 만류하고 쉽습니다.
여러 가지 이유로 개발업체에서 고연령 개발자를 채용하는 것을
꺼리고 있으며 고등학교 혹은 대학교 졸업을 한 전산 전공자를
선호하고 있으며 21세 이상 30세 이하가 적정 연령인 것 같습니다.
많은 분들이 그렇듯이 30세 이상인 분은 전업이나 장래에 대한
계획이 필요합니다.
이 글에서는 정보공학에 대해서는 언급을 전혀 하지 않습니다.
정보공학이 실제로 단순한 코더 보다는 오히려 부가 가치가 높은 것인지도
모릅니다.
필자는 가난한 개발자입니다. 필자가 부자이고 넉넉한 마음으로
이 글을 쓰고 있다면 마음이 편했을 텐데 웬지 서글픈 마음이 드는 것은
왜? 일까요?
개발자가 되고 싶다고 해도,간단한 업무용 프로그램을
만들려고 해도,초보자에게는 모든 것이 힘들기만 합니다.
개발 기술은 개발 회사에서 보호되어 있고 시중의 참고 서적들은
도움이 되지 않습니다. 참으로 이상한 일입니다.
개발자에 입문한지가 어제 인듯하더니 순식간에 세월이
흘러가 버렸습니다. 어느 순간, 직업적인 개발자가 되어버린 모습에
스스로 놀라울 따름입니다.
하지만, 아직도 배울게 많고, 필요한 기능을 신속하게 구현 할 수
있는 능력을 갖도록 노력하려고 합니다.
이 글에 대한 조회수가 1000회가 넘은 것에 대하여 감사를
드리는 맘입니다. 물론,1년이란 기간 동안 조회한 숫자이지만 ,
허접한 글에 대하여 여러분들이 관심을 가져 주셔서 필자로서
고마울 따름입니다.
이 글은 현업에서 실무 중 느낀 점을 간략하게나마 기술한 것이므로
주관적인 생각이 강하고 객관성이 많이 결여 되어있는 것은 사실이지만
개발 전 분야에 걸쳐서 어려움이 많다는 것을 알려 드리고 싶습니다.
일반인들은 소프트웨어가 담긴 CD 한장에 1-3만원 정도란 것이 각인
되어 있습니다.
보통 불법 소프트웨어 카피본에 1만원에 거래되고, 정품 소프트웨어 가격이
저렴할 경우에는 8만원에서 15만원 사이입니다.
따라서, 소프트웨어 개발 비용이 일천만원 이상을 한다고 말하면 도무지
벌린 입을 다물지 못합니다.
무슨 CD 한장에 일천만원 까지 하냐고...사람을 놀리지 말라고...
여러 소프트웨어 개발 회사의 기술 수준은 차이가 있습니다.
아직까지 그것들과 비교해서 이 글에서 소개한 개발 기법에 대하여
강한 긍지를 가지고 있습니다.개발자는 철저한 생존을 위한 몸부림으로
항상 최적화된 개발 기법을 찾아야합니다.
비교적 팀 프로젝트에서는 시간적인 여유를 가지고 진행 할 수 있으나
프리랜서인 경우엔 모든 작업을 혼자 해야하기 때문에 최적화된 기법을
찾기에 힘써야 하며, 프로젝트 시작 전에 라이브러리가 미리 준비 되어
있어야 합니다.
라이브러리는 공통으로 사용된 함수의 모임이나 콤포넌트, 재사용 가능한 것을
말하며 개발 시간을 단축시키고 효율적으로 코딩을 하기 위함입니다.
******************************************************************************
개발된 소프트웨어의 이상적인 국내에서 판매 카피 수는 50만 장입니다.
******************************************************************************
비록, 개발 비용을 회수 못한다 하더라도 50만 카피는 브랜드로서 성공하신
것입니다. 여러분이 프로젝트 메니저 위치에서 이 글을 접하실 때면
필자의 의견에 동의 하실 겁니다.
이제 뜻 깊은 성탄절이 다가옵니다. 필자가 델파이라는 툴을 알기전에 무척이나
고생을 많이 했습니다. 뉴스 구룹에 의지해서 해답을 찾으려고 했던 기억이 납니다.
그리고 특이한 사실은 영어의 독해력이 개발자의 개발 기술과 자기 개발에 도움이
된다는 사실입니다.
===========================================================================
이 글에 소프트웨어 공학과 정보 공학에 대한 내용을 기술하기 위하여
문서명을 델파이프로젝트실무에서 미니프로젝트실무로 변경합니다.
현재 문서에 자바, 리눅스, MySQL, JSP에 대한 내용을 추가하려 한다.
그리고, 틈틈이 제품기획과 상품기획, 마케팅에 대한 내용을 담아서
프리랜서 여러분이 자영업 하시는 데 도움이 되려고 한다.
이러한 기술 문서가 의도하는 대로 우리 모두에게 유익했음 한다.
이 글을 쓰는 시점에 제가 대형 소프트웨어 업체처럼 큰 수익을 얻었으면
조으련만 그렇지 못하여 못내 아쉬움이 많다.
개발자로 있으면서 느낀 것이지만 개발자에게 도덕적인 면이 많이 요구 되는
것 같다. 데이타베이스를 다루다보면 개인 신용정보나 개인정보들 개발과
관련된 영업기밀 등을 누설하지 않아야 한다. 또한 해킹에 대한 역추적을
위하여 본의 아니게 타 전산망을 침투하는 경우도 발생한다.
현재는 급변하는 개발기술 발전에 따라 신 개발기술을 습득해야만 하는
개발자들에게는 많은 융통성을 필요로 한다.
많은 분들이 소프트웨어 개발관련 사업계획서 작성상의 어려움을 호소하고
있고, 정보공학 및 소프트웨어공학에 대한 문의가 많이 와서 여기에 다루고자 한다.
그러나, 이 문제를 다루긴 위해선 지적재산권 문제를 고민을 해야한다.
국내에는 많은 대형 SI업체들이 존재하고 합리적으로 개발 기술을 문서화하는
방법론이 거의 대부분 미국의 아더엔더슨 컨설팅과 여러분에게 유명한 SAP의
자체적인 노하우이기 때문이다.
아무리 개량하고 발전 시켰다 하더라도 상기의 두 회사의 개발 기법을 벗어나지
않는다. 상기의 개발기법을 이용하기 위해선 천문학적인 비용이 소요된다.
그래서 컨설팅을 위해선 기업의 연간 매출이 100억 이상이 되어야 효율적으로
이용 할 수 있다. 정보공학을 고려하면 심지어 오라클의 개발 방법론 까지도
전체적으로 똑 같지는 않지만 상기한 회사의 개발 방법론이 요소요소에서
비슷하거나 공통적인 요소로 인식 할 수 있다.
그럼 천문학적인 비용을 부담하지 않고 정보공학 프로젝트를 수행하는 방법은
없을까?
필자가 여기에 고심하다 중요한 사실을 알게 되었는 데 바로 국제규격이다.
국제규격은 표준화 하는 대신에 해당 기업에 라이센스료를 지불한다.
ISO에 따르면
1. 소프트웨어품질 인증에 대한 표준규격
2. 프로젝트 관리에 대한 표준규격 등이
있다. 매우 정교하고 합리적으로 기술되어 있다.
우리 개발자들이 국제 규격을 전용하면 프로젝트 실무 전반에 대한 문서화를
효과적으로 달성 할 수 있다.
따라서, 국제 표준규격을 전용하면 어느정도 저작권 문제에 말려들지 않을 수
있지만 그래도 세심한 주의를 해야한다.
현재 서울 소재의 델파이 툴을 사용하는 소프트웨어 개발회사에 따라
또는 프로젝트 메니저에 따라서 독자적인 방법론이 존재하지만,
가장 효율적인 것을 취사할 필요가 있다.
현재 실무 경력 3년차인 프로젝트 메니저까지도 확실한 개념이해의 기반 없이
마치 모래위의 성을 쌓은 분들이 너무 많은 게 사실이다.
사실 정보공학의 산출물은 가장 정교하고도 광범위한 지도이며 설계도이다.
따라서, 개발자는 이러한 산출물만 보고도 바로 자기의 프로그래밍 언어를
사용하여 신속하고 빠른 개발이 가능해야만 한다.
//////////////////////////////////////////////////////////////////////////////
// 구직 //
개발자에게서 안정적인 수입은 매우 중요하다. 초창기에는 서버 관리자로서 안정적인
프로그램 개발을 할 수 있는 시간적 여유가 있었다.
프로젝트 메니저가 개발인력이 부족하다는 말은 고급 개발자가 부족하다는 의미이며
경영자가 개발인력이 부족하다는 말은 임금이 저렴한 개발인력이 부족하다는 의미이다.
직업에 대하여 순수했던 저에게 기분을 상하게 했던 것은 경영자가 아니면서 또는
채용 할 의사가 없으면서 저의 이력서를 요청한 사실이다.
나중에 안일이지만 개발 능력보다 중요한게 인맥이다. 개발 능력이 부족해도 고급
개발자를 많이 알아두어 프로젝트에 따라서 단지 소개만 하여도 돈을 벌 수 있는 것
이다. 경영자 또는 개발 업체에서는 특정 분야에 대한 개발 인력이 필요 할 때
공급하는 능력을 매우 중요하게 생각한다.
프리랜서라함은 단어의 의미가 자유 계약직을 의미하지만, 개발직에 있에서는
전문 개발직을 의미한다. 아르바이트와는 별개의 문제이다.
고도의 전문 개발 기술을 습득한 실무 경력자를 의미한다.
그러나 우리 나라에서는 직업소개소, 인력 파견업체를 의미한다. 독자적인 프로젝트
수주가 불가능하고 다른 기업의 프로젝트와 관련하여 사람을 소개하는 정도이다.
이런 일련의 인력파견 업체로 인하여 많은 개발자들이 이직을 하거나 전업을 하거나
개발일에 대하여 환멸을 느끼는 경우가 생겼다.
// 프로젝트 시작 : 인터뷰 //
미니 프로젝트 수행의 어려움은 역시 의사 소통이다. 초기에 필자는 이 어려움을
필자의 사무직원으로서의 행정 업무에 재직 경험으로 보완 할 수가 있었다.
그러나 이러한 점은 프로젝트 수행에 좋은 점이라고 말할 수 없다.
최고 경영자의 협조 지시가 내려 왔는 데도 실무자의 협조를 얻기란 쉽지가
않다. 회사 기밀 보호라는 장벽도 그러하거니와 자기가 가지고 있던 업무상의
노하우를 공개하지 않으려는 잠재적인 것도 부정적인 변수가 된다.
우리 실제 생활 즉 자연 환경을 전산세계로 변환 시키는 작업은 고뇌와 노력
그리고 창의적인 노력을 필요로 한다.
이 해법을 위하여 실무에서는 비슷한 유형의 프로젝트와 비교하여 맵핑 시킨다.
그러나 비슷한 유형의 프로젝트라고 하더라도 항상 참인 것은 아니다.
경영자의 정보처리 가공의 초점이 개발자가 사소한 것이라고 여기는 사건이라면
개발된 소프트웨어의 만족을 가져 올 수 없다.
한가지 예로들면 우리나라 대형 가전업체의 판매 대리점에 대한 전반적인 시스템
구축이다. 결론적으로 말씀드리면 여기서 중요 사건은 고객의 가치에 대한 감동이다.
가전매장의 문을 들어선 고객은 이 시점에 제품을 구매 할 수도 있고 아닐 수도 있다.
제품 구입을 의도한다면 매장 상주 직원에게 제품에 대한 자세한 정보를 요청 할 수도
있다. 고객은 진열 라인에 따라서 고객 취향대로 진열 제품에 대한 시선을 고정시킬
것이다. ...중략
위의 기술한 예는 인간의 복잡하고 다양한 행동 양식을 표현한 것이다. 이것을 전산
세계로 구현하는 것은 입문자에게는 쉽지가 않다. 이러한 것을 실무에 반영하기 위해선
숙련된 시나리오 작성에 유의해야 한다. 우리 개발자는 일반적으로 시나리오는 게임
개발에만 적용하는 것으로 잘 못 알려져 있다.
그러나 외국계 개발 회사에서는 시나리오가 정보공학의 초석으로 산출물 중에서 중요한
위치를 가지고 있다.
"자료구조나 알고리즘(로직)이 중요한 이유는 특정 문제 해결을 위해서 실세계의 문제를
수학적 아이디어로 랩핑시켜 해결하는 요소이기 때문입니다.
실제 세계의 모델을 컴퓨터에 어떻게 효율적으로 구현할 수 있는지를 설계하고
그것을 실제로 구현해보는 것은 매우 중요합니다.
실세계의 문제를 수학 문제로, 그리고 수학적 개념을 프로그래밍 언어로 효율적으로
표현해내는 것은 매우 중요한 능력입니다.
알고리즘(로직)의 습득을 위해서는
- 로직을 스스로 생각해낼 수 있어야 합니다.(기존의 방법이 아닌 새로운 것)
-다른 로직과 효율을 비교할 수 있어야 합니다.
-로직을 컴퓨터 언어와 다른 사람이 이해할 수 있는 의사 코드로 표현해낼 수 있어야 합니다.
- 로직이 정상작동(correctness) 여부를 검증하여야 합니다.
개발 기술을 빠르게 습득하기 위해서는 코드 내에 주석을 최소화하되 코드의 가독성이
떨어지지 않도록(혹은 오히려 올라가도록) 노력합니다.
그리고 고도의 전문가와 함께 날 밤을 세며 짝 프로그래밍을 하면
강력한 만큼 빠른 개발 기술을 습득 할 수 있습니다.
로직 패턴을 공부할 때는 그 구조보다는 의미와 의도를 우선해야 합니다.
// 프로그래밍 언어와 개발자 //
필자는 고백하건데 파스칼 언어를 많이 싫어 했습니다. 필자는 어셈블리어와
c언어의 맹신자이자 열렬한 팬입니다. 물론 하드웨어 제어 측면에서 그렇습니다.
하지만 델파이란 툴이 파스칼을 조아하게 만들었습니다.
프로젝트 메니저로서 서로 다른 언어로 된 소스코드를 분석하고 로직을 읽을 수
있기 까지는 많은 시간이 흘러야 했습니다.
한 언어에 대하여 정통하다면 비록 문법을 모른다고 해도 함수 판독은 어렵지
않습니다.
// DB와 연동된 산업용 기기제어 프로그램 //
데이타베이스와 연동된 산업용 기기(PLC포함) 프로그램은 동기화와 빠른 처리를
필요로 합니다. 따라서, 데이터 베이스 처리를 하게 되면 약 10초 라는 지연
타임이 발생하게 됩니다. 그렇게 되면 프로그램에 대한 사용자의 신뢰성이
회손됩니다. 제어기기와 연동되어 데이타 베이스에 질의를 해야한다면 기기
제어전에 사전 질의를 하여 로컬에 텍스트 포맷으로 가지고 있다가
다시 불러들여 사용하고, 만약 실시간의 기기제어 사항을 데이타 베이스에
저장해야 한다면 소켓을 사용하여 사용자 화면에 결과를 먼저 보이고
데이타 베이스에 동시에 저장하도록 한다.
만약, 서버 클라이언트 환경이라면 정상적인 질의 보다는 소켓을 효율적으로
제어하는 것이 유익하다.
// 여성 CEO 아래의 개발자의 위상 //
요즘은 벤처기업 육성 정책에 따라 20대 후반의 아름다운 여성이 CEO가 되는
경우가 많다. 이런 회사에 입사한 개발자는 행복하지 않다.
이쁜 여성 사장님과 일을 하게 되서 기쁘다는 생각은 버리는게 좋다.
거의 대부분 여성 CEO도 다른 경영자와 마찬가지로 소프트웨어 개발에 대해서
잘 알지 모른다. 여성을 상사로 두면 직장 생활하기가 편하지 않다.
정말 피곤하다.
인간적인 유대관계를 가지기 위하여 진솔한 대화를 아니 의사 소통하기가
쉽지 않다. 세심하고 정확한 여성미가 때로는 개발자에게 수 많은 스트레스를
안겨준다.
// 개발자와 스트레스 //
개발자란 직업은 극도의 스트레스를 동반하는 직업이다. 이것을 해소하기 위한
나름데로의 개발자의 반응은 스포츠, 충분한 수면, 음란한 성인자료 감상,
스타크래프트 같은 게임, 음악감상, 섹스 등으로 스트레스를 풀려고 한다.
음란물 감상, 섹스, 게임 중독은 업무에 지장이 없도록 적절한 통제가 필요하다.
또한 개발팀에 여성이 포함되어 있다면 직장에서 우발적인 혹은 의도적인 성희롱
에 주의해야한다.
직장내 회식의 경우엔 여성 직원은 1차 회식이 끝나면 반듯이 귀가 시켜야한다.
만약 이것을 지키지 않는다면 이성이나 자제력이 흐려진 상황에서 직장 동료들
사이의 섹스는 결과적으로 프로젝트를 위협하므로 주의해야한다.
개발자가 회사 내에서 극한의 스트레스 해소 목적으로 음란물을 보는 경우도 있다.
사전에 프로젝트 메니저는 여성 개발자에게 사전 이러한 사실을 인지 시키고
동료 남자 직원의 컴퓨터에 접근하는 것을 삼가하도록 사전 교육을 실시한다.
// 프로젝트 메니저의 궁극적인 의미? 공학의 의미? //
공과대학에 입학하게 되면 학과 지도 교수로 부터 공학의 의미를 듣게 된다.
공학이란 관련 순수 기술 학문에 돈을 가미한 학문으로 순수한 학문에 경제적인
가치 창출 그러니까 최소 희생으로 최대의 경제적인 효과를 내는 것을
의미합니다.
프로젝트 메니저는 소프트웨어 개발에 있어서 공통적인 인자인 돈(가치)과 결부
하여 경제적인 수익을 내는 직책을 말합니다.
다시 말하면 프로젝트의 성공을 가져오는 것 뿐만 아니라 프로젝트 결과로 수익을
내는 직책을 말합니다. 비 실무자라면 프로젝트 성공적인 완료까지를 의미하지만
현장 실무에서는 반듯이 수익을 창출해 내는 직무를 수행하는 자를 말합니다.
또 다른 CEO라고 표현하면 적절할 겁니다.
만약, 경제 환경으로 프로젝트 성공을 하였지만 개발 결과로 수익을 내지 못했다면
프로젝트 메니저로서의 책임을 다한 것은 아닙니다.
이러한 이유로 프로젝트 메니저 채용시 반듯이 개발자 출신이 아니더라도 직무
수행이 가능하다고 컨설팅 합니다.
그러나 개발자가 프로젝트 메니저 직무를 수행하게 되면 전체적으로 프로젝트를
조감 할 수 있고 여러가지로 유익한 점은 부인하지 않겠습니다.
그러나 개발자 출신의 프로젝트 메니저가 주의 할점은 고정관념을 깨야합니다.
틀에 박힌 고정 관념은 프로젝트의 성공을 위태롭게 만듭니다.
프로젝트 메니저는 프로젝트 수행 기간동안 모든 변수를 파악하고 항상 돈과
관련을 짖고 판단해야 합니다.
// 곧 바로 투입되는 개발자 양성을 위해서는...//
전공 불문하고 전산 전공자이면 더 바랄 것이 없지만, 비 전공자라면 최소 1년
정도의 프로젝트 실무 과정 또는 컴퓨터 관련 학원에서 컴퓨터와 친숙하면 좋겟다.
이런 사회 초년 대졸자를 실제 프로젝트 실무에 투입하려면 소요 기간은 약2년이며
소요 비용은 약오천만원 정도이며, 이것은 개발자가 주야로 밤을 설치면서 노력했을
때의 이야기이다. 개발자 양성이 얼마나 어려운 일인가를 단적으로 표현하고 있다.
그리고 개발회사에서 실무 경력자를 선호하는 이유는 양성하려는 비용,
즉 위탁 비용을 기업에서 부담하지 않으려 하기 때문이다.
양성을 위한 위탁비용과 인건비로 인하여 이중 부담이 되기 때문이다.
// 개발자와 브로커 //
소프트웨어 개발 세계에는 브로커란 직업이 있습니다. 브로커가 나쁘단 이야기는
아닙니다. 아마도 필요악인듯 싶습니다. 프리렌서에게는 돈 줄이니까요...
이 분들은 개발자 출신도 있지만 개발과는 전혀 인연이 없는 영업맨인 경우가
많습니다. 정부 요직의 관료와 친분있는 자와 관공서 및 기업에 소모품 납품업자
하청 업자들이 주류를 이룹니다.
날밤을 세워 어렵게 프로젝트를 완료했으나 개발비를 한 푼도 받지 못한
경험이 있나요?
어렵게 프로그램 개발을 완료하였으나 개발회사가 부도나서 급여를 한푼도
받지 못한 경우가 있나요?
소프트웨어의 개발 회사의 최소 팀 인원은 5명정도입니다.
그런데, 최고경영자와의 신의를 저버리고
중간관리자가 사장을 배신하고 직원들을 대리고 퇴사하여 회사 기술로 다른
상용프로그램을 만들어 팔다가 이 사실을 전 사장이 추적하자 그 회사를 처분하고
사라져 버리는 것을 경험하셨나요?
브로커란 프로젝트 수요처를 파악하고 프로젝트 진행중의 난해한 솔류션 개발을
위하여 개발자를 수요처에 소개하고 거액의 사례비(소개비)를 챙기는 직업을 말합니다.
인력파견 업체도 브로커 성격을 가진 경우도 있습니다.
헤드헌팅과는 질적으로 다릅니다. 브로커는 거액의 돈을 중간에서 챙기게 됩니다.
보통 대형 SI업체에서 5억 정도가 소요되는 프로젝트에 대해서도 브로커는 단번에
일천만원 정도에 해결하려고 합니다. 나머지 금액은 브로커가 금액을 취하게 됩니다.
최초 정부 발주의 프로젝트는 브로커를 위한 게 아니라 개발자에게 돌아갈 금액입니다.
그러나 건설처럼 재하청에 재하청을 주는 악순환이 생기게 되었고, 발주자로선
누가 프로젝트 비용을 취하는 데 관심은 없고 프로젝트 성공 결과만을 바랄 뿐입니다.
자본금이 1억 정도 밖에 안되는 벤처기업에서, 정작 아이템에 필요한 소프트웨어
개발이 필요하게 되었을 때,개발 자금이 전혀 없는 데도 불구하고 5백만원선에서
해결하려 듭니다. 아마도 개발자를 속이려 드는 일이지요
귀하가 프리렌서인 경우라면 계약 할 때 세심한 주의를 해야하고 개발용역대가를
반듯이 나누어 받으셔야 합니다.
프로그램 개발 완료 후 청구하는 것은 이미 늦으므로, 개발 진행에 따라 나누어
받도록해야 합니다.
// 프로젝트 수주의 과정 //
원래는 정보화촉진기금 등 정보통신 분야의 진흥을 위하여 조성된 기금은
대형 SI 업체를 위한 것이 아닙니다.
말 그대로 정보통신 분야의 진흥을 위한 기금이죠.
정보통신 분야의 육성을 위한 각종 정부 투자 자금등은
결론적으로 말씀드리면 최하위에서 실제로 그 프로젝트를 수행하는 개발자가
지속적으로 개발을 촉진하기위한 자극제입니다.
이러한 정부의 의도와는 달리 결국은 수 많은 프로젝트는 대형 SI 업체에서
수주를 하였습니다.
예를 들면, 개발아이템이 무선모뎀 개발 및 드라이버 개발이라면 이 개발을 위해
하청에 재하청에 또 하청을 받아서 최종적으로 실제 개발 업무를 담당하는
개발자로 프리랜서를 고용하여 일억오천만원을 주기로 계약하고, 프로젝트
완료 기간을 6개월로 한정하였다면 실제 수주액은 오억원이 넘을 가능성이
있습니다.
그럼, 실제로 개발을 담당한 이 개발자가 오억원에 정부로부터 이 프로젝트를
수주 받는 것이 가능할까?
실제로 불가능합니다. 비록 이 개발자가 개발능력을 정부로부터 인정 받기는
쉽지 않으며, 인정 받더라도 각종 담보가 없으면 많은 어려움이 있습니다.
대형 SI 업체는 실제로 개발 능력을 보유하고 있지 않더라도, 우선 정보통신
업체로서 각종 정부의 기준에 대한 구비요건을 갖추고 있습니다.
정부가 발주하면서 바라는 것은 실제 개발 능력이 중요한게 아니라 요식행위
즉, 각종 시행 법령에 적합한 문서와 그 요건에 맞추어 버리면 됩니다.
미국과는 마니 다른 문화입니다. 건설 같은 경우에는 시방서라는 자세한
공정 사항이 기록되어 있는 경우가 있습니다. 미국은 합리적인 문화가 발달되어
있어서 문서화가 잘된 개발회사에서는 비록 전산 전공자가 아닐지라도 그 문서만
보고도 소프트웨어 개발이 가능하다고 합니다.
정부로 부터 프로젝트를 수주하기위해 대형 SI 업체에서는 실제 개발에 참여 할
개발자도 이력서를 통하여 연락처와 인적사항을 알고 있으면 된다.
자기 회사에 고용된 직원이 아니더라도 된다.
비록 개발능력이 없다고 하더라도 정보처리기사1,2급 등 관련 자격 소지자가
있다면 수주 받기가 용이하다.
결국은 이러한 악성 구조가 실제 현업에서 개발자의 수명을 단축하게 만들며
개발자란 직업을 버리고 다른 직종으로 이직하게 만듭니다.
현실에서는 개발자가 필요로 되는 경우에는 고액의 외화를 들여 인도나 미국에서
개발자를 수입하게 됩니다.
// 대형 SI 업체의 타업체 개발 기술을 훔치는 방법 //
예를 들면, 브랜드 가치가 10억이 넘는 업체 A사가 있다고 가정하면, 이 업체는
특정회사를 지칭하는 것이 아니므로 국내의 모 회사를 연상해서는 안된다.
이 글에서는 그냥 보기를 들었을 뿐입니다.
A사에서는 실제 개발 인력을 보유하고 있는 중소 업체들에게 공문을 통하여 제안서
요청을 합니다.
제안서 요청시 프로젝트와 관련있다고 하여 세부 스펙을 정해놓고 기술 사항까지
기술하도록 유도하게 됩니다. 중소 규모 업체들은 이것을 수주하기 위해 불필요한
회사의 개발 노하우까지 제안서에 기술하게 됩니다.
수주를 위해서 고육지책으로 이렇게 하는 것입니다.
A사의 입장에서 보면 방대한 기술 자료가 자동적으로 수집하게 됩니다.
프로젝트 수주에 응했던 중소 기업들이 연락이 오지 않아서, 어떤 기업이 수주하게
되었나 문의해보면, 프로젝트를 발주햇던 A사가 자체 개발하고 있음을 알게 됩니다.
물론,제출된 제안서 덕분에 스펙과 테크니컬 로드맵이 작성된것은 당연하구요.
그럼, 이러한 점을 막기 위해 어떻게 해야 할 까?
프로젝트 수행 제안서에서는 불필요한 개발 노하우까지 기술되지 않도록 주의해야
하며, 발주를 한 대형 업체의 최고 경영자와 직접 접촉 및 계약을 하거나
차라리 로비를 해야합니다. 물론 공개입찰 형식을 시행한다하더라도 내부적으로
결정되게 만들어야 합니다.
두번째 방법으로 타회사의 개발 기술을 훔치는 방법을 기술하겟습니다.
우선 프로젝트를 발주합니다. 발주하면서 특약 사항을 넣게 되는 데, 발주처에서
감독관이란 직책을 주어 자사 직원을 프로젝트 수행 개발자들과 함께 참여하도록
만듭니다. 프로젝트 진행기간 동안 관련 개발 기술을 모조리 훔쳐내게 됩니다.
이것을 막기위해 특약 사항을 만들기 전에 감독관 범위와 회사 노하우 보호를
위한 장치를 만들어야 합니다.
세번째 방법으로 이것은 영업 기밀 즉 노하우 보호와 밀접한 관련이 있습니다.
즉, 핵심 기술을 보유하고 있는 대리급 개발자에게 접근하여 거액 연봉 제시를 하여
별도로 기술적인 면접을 봅니다. 스카웃 내용에 대한 계약 이행에는 시간을 끌며
핵심적인 기술 사항에 대한 질문을 하여 개발 기술을 훔쳐 내게 됩니다.
종국에는 자사의 인사 위원회의 결정으로 스카웃이 백지화 되었다고 통보하게
됩니다.
거액 연봉 제시의 스카웃 제의로 핵심 노하우 유출이 너무 쉽게 됩니다.
영업 기술 유출은 친고죄로서 민사 및 형사상의 책임을 져야 합니다.
// JSP 환경의 구축 //
델파이 개발자가 다른 개발 언어에 관심을 갖는 것은 매우 흥미롭다.
JSP는 윈도우 환경에서 코딩하여, 컴파일 하고,
사용 할 때는 리눅스 서버에 적재하는 것이 이롭다.
물론 리눅스에서 VI 편집기로 코딩하는 것도 괜찮을 것 같다.
우선 코딩 플랫 폼은 윈도우 NT4.0/WINDOWS2000pro에서 하는 것을 추천한다.
윈도우 환경은 왠지 불편함을 느낀다.
*** EJB의 개념 ***
Enterprise Java Bean은 일종의 업무용 컴포넌트이다.
또한 wrapper class file이다.
재사용을 위한 것을 보면 라이브러리라고 해도 틀리지 않다.
윈도우 운영체제에서 공유 DLL은 런타임시 각 응용프로그램에서 동적으로 메모리에
적재하여 사용한다. 그리고 각 응용프로그램에서 공유하여 사용한다.
이런 개념에서 볼때에 자바빈은 자바 콘테이너 서버에서 실행시 동적페이지에
빈 테그를 사용하여 서브릿을 참조하게 된다.
어쩌면 공유DLL, 혹은 공유 라이브러리라고 이해하면 될 것 같다.
사실 데이타베이스 접근 및 업무용 질의어를 JSP 내에 코딩하게 되면
지루하게도 똑 같은 코드가 반복되며, 이와 관련된 JSP 파일을 클라이언트에서
다운로드 받게 되면 모든게 노출되어 보안상 이롭지 못하다.
물론 자바의 특성상 역컴파일이 가능하기 때문에 소스 코드의 노출 위험은 언제나
존재한다.
1. 선의 자바 사이트에 가보면 컴파일러를 다운 받아보려고 하면 수 많은 버전들이
존재하여 어떤 것을 다운 받아야 할지 어려움을 느끼게 된다.
물론 최신 버전을 다운 받으면 되겟지라는 생각은 금물이다.
우선 JDK 버전은 데이타 베이스 관련 서브릿 개발 환경이 목적이므로 반드시
JDK가 아닌 J2SDK-1_3_0_02 버전을 다운 받는 게 노하우이다.
2. 컨테이너를 다운 받으려고 자카르타 톰 캣 사이트에 가보면 무수히 많은
버전 때문에 당황하게 된다.
물론 최신 버전을 받으면 되겟지?라는 생각은 금물이다.
JAKARTA-TOMCAT-3.2.4를 다운 받아야 합니다. 그 이상의 버전을 다운 받으면
JSP와 서브릿을 지원하는 범위가 다릅니다. 그 이상의 버전을 다운 받아 압축을
풀어보면 라이브러리에 servlet.jar가 포함되어 있는지 확인하기 바란다.
3. mysql은 mysql-3.23.49가 무난하며,
mysql을 위한 ODBC 드리이버는 myodbc-2.50.39를 다운 받으며,
JDBC 드라이버는 mysql.jar 형태로 압축된 것을 다운 받아서 사용한다.
4. 각종 라이브러리 클래스 파일, 컴포넌트 클래스 파일, 그리고 이것을 JAR 파일
형태로 압축된 것을 c:\jdk1.3\jre\lib\ext로 copy한다. 물론, 사용자 마다
JSDK 설치 디렉토리가 다르게 된다. c:\jdk1.3\jre\lib\ext는 런타임시에
참조할 클래스패스상에 존재하는 디렉토리이다.
리눅스에서는 J2SDKSE1.2.2 + tomcat3.1
윈도우2000에서는 J2SDK1.3.0 + tomcat3.2.4
를 권장한다.
다음은
톰캣이 올바르게 설치되어 있는지 검사하는 소스코드이다.
파일명 :flowservlet
import javax.servlet.*;
import javax.servlet.http.*;
public class flowservlet extends HttpServlet {
public void init(ServletConfig sc) {
System.out.println("init() 가 호출되었습니다.");
}
public void service (ServletRequest reg, ServletResponse res) {
System.out.println("service() 가 호출되었습니다.");
}
public void destory() {
System.out.println("destory() 가 호출되었습니다.");
}
}
테스트는 것을 컴파일하면 flowservlet.class가 생성 되는 데 이것을
홈페이지 루트 디렉토리하위에 예론
c:\public_html\WEB-INF\classes 에 복사한다.
그 다음에 컨테이너 톰 캣을 실행하고나서
웹브라우저의 URL에
http://localhost:8080/servlet/flowservlet 을 입력하여
에러 없이 아무 화면이 안나오면 설치가 제대로 된 것이다.
소스 코딩 및 컴파일 작업은 윈도우 플랫폼에서 하고
실행은 클래스 파일을 FTP로 리눅스 서버로 넘겨서 한다.
리눅스 서버로 넘길 때는 압축파일로 넘기는 게 좋다.
// 프로젝트 메니저의 인력관리 //
프로젝트 메니저의 중요한 업무 중의 하나가 인력관리 라는 것을 아래 글에서
부연한바 있다.
개발인력의 급여 책정은 개발자의 급여의 3배 수익을 보고 결정합니다.
예를 들면, 개발자가 연봉 일천만원에 계약 했다면 그 개발자에게 1년에
약 3천만원 정도의 수익을 낼 것을 기대합니다.
1년 회사 경영에 예상 수익의 3분의 1정도에서 결정합니다.
쉽게 설명드리면 개발자가 자기가 받는 급여의 3배 정도를 벌어 드리기를
기대한다는 이야기입니다.
// 시리얼 통신 제어 프로그램 -- 프로그래밍 기법 //
여러분이 프리랜서 아니면 초보 개발자라 할지라도 가장 많이 코딩하게 되시는 것이
바로 산업용 시리얼 통신 기기의 제어입니다.
주로 컴퓨터와는 근거리 즉 2미터 이내의 케이블로 연결된 장치를 제어하게 됩니다.
보기를 들면 각종 POS 기기, 바코드 프린터, 터치모니터, 전광판, 카드 인식기기,
휴대폰, PDA 등 수 없이 많습니다.
우선 시리얼 통신 제어 프로 그램을 작성하기 위해선 시리얼 컴퍼넌트를 활성화
하는 부분을 try ~ except ~ end; 문으로 감싸야 합니다.
이렇게 하지 않으면 에러 발생시 컴퓨터가 먹통이 되는 경우도 생깁니다.
다른 어플에서 시리얼 포트를 사용 할 때 또 다른 어플이 같은 시리얼 포트를
사용하지 않도록 해야합니다.
우선 시리얼 제어용 유명한 상용 컴포넌트는 바로 터보 파워의 어씽크
프로페션널입니다. 가격은 아마도 일백만원대 일 것입니다.
이 컴포넌트는 우리에게 많이 알려져 있습니다.
어씽크 콤퍼넌트를 사용 할 때 주의 사항은 버전에 따라서 일회 전송 량이
8 바이트로써 ( 8 * 1024 ) 8바이트가 넘은 경우에는 8바이트 씩 나누어 가져옵니다.
그래서 stx := #02 + 전송 데이터 + etx := #03 형식으로 가져옵니다.
여기에서 전송 데이터가 20 바이트가 넘는 경우에는 어씽크에서는 두번 나누어서
가져오게 됩니다. 전송 이 벤트가 여러번 호출 된다는 의미입니다.
이것은 제어용 데이타가 산업용 제어기기에 전송 시점의 동기화가 필요 할 때는
무척 제어를 어렵게 만듭니다.
모든 시리얼 콤포넌트가 그렇듯이 char 타입으로 1문자씩 8비트로 가져옵니다.
보통 컴포넌트 이벤트에서 카운터 많큼 가져 옵니다.
var
i : integer;
read_data : string;
begin
for i := 1 to count do
read_data := read_data + getread();
end;
예를 들어 알파벳 A라는 문자가 전송 될 때,
STX - A - ETX 또는 [02] - A - [03] 이렇게 전송됩니다.
일단 컴포트로 전송된 데이터를 읽어 드려서 STX가 감지되면 지금 버퍼로 읽어 드리고
있는 중이고 ETX가 감지되면 전송이 끝났다는 것이 감지됩니다. 보통 이 때 데이터를
버퍼로 부터 읽어 들이고 난 다음에 다음 전송을 위해서 버퍼를 초기화 시킵니다.
로직을 자세히 설명드리면,
우선 컴포트 상태를 판별하기 위한 상수가 필요합니다.
stx := 02, etx:=03 으로 상수가 사전 정의 된다.
컴포트 작동을 콘트롤을 하는 판별자를 상태에 따라 변수에 배열 형태로 자료형을 정의하고
그 크기를 설정한다. 변수의 그 크기를 측정하고 그 크기만큼 0으로 채워서 배열 변수를
초기화 시킨다.
카운터가 0 이상이면 카운터 -1 만큼 변수에 읽어 드린 자료를 저장한다.
변수에 읽어드린 데이타를 검사하여 컴포트의 상태를 판별한다.
만약 STX가 인지되면 버퍼에 자료를 수신중임을 나타낸다.
읽어 드린 변수가 STX으로 인지되면 버퍼 변수를 초기화하고 컴포트 상태 판별자를
수신가능 상태로 설정한다.
읽어드린 변수 값에서 ETX가 판별되면 수신 데이타를 모니터 콘트롤에 표시하고
버퍼 변수는 초기화 시킨다.
///////
윈도우에서 클라이언트 프로그램을 설치하다 보면 설치 관리자 프로그램의 사소한
실수로 예론, path 설정 부분에 특수 제어문자 혼입으로, 환경 변수의 path가
먹혀들지 않아 곤란을 겪는 경우가 종종 있습니다.
window 95/98에서 autoexec.bat의 내용중에 path을 설정하는 방법입니다.
형식은 set path="절대경로"
다음줄에 set path="절대경로";"%path%";
형식은 set classpath="절대경로"
다음줄에 set classpath="절대경로";"%classpath%";
보통 autoexec.bat 파일을 편집기로 열어서 한줄에 이어서 적어주어야 하는 데
만약, 한 라인이 길경우에나 제어문자가 혼입되는 경우에 라인이 분리되어
path 설정이 안되는 경우가 많습니다.
이런 경우에는 한줄에 다 기록하지 말고 다음 라인에 기록을 해야합니다.
즉, 이미 설정된 환경변수 %path%를 이용하게 됩니다. 만약 편집이 잘 못되어
2라인으로 인식되면 환경변수를 저장할 공간이 부족합니다 라는 에러 메시지를
냅니다. 그래서 다음 보기와 같이 작성해야 합니다.
보기를 들면,
set path="c:\informix\bin"
set path="c:\other application\bin\;"%path%";
다음 보기를 들면
set path="c:\;c:\windows;c:\windows\command;";
set path="c:\first appl";"%path%";
set path="c:\second appl";"%path%";
위에서 보면 중요도가 높은 프로그램이 설정 부분의 제일 앞에 오도록합니다.
이방법 말고 레지스터리를 이용하면 더 손쉽게 경로 설정을 할 수 있습니다.
CPU가 특정 실행 프로그램을 찾으려 할 때 레지스터리를 이용하여 CPU에 알려주면
그만이다.
위와 같이 하더라도 " 환경변수 저장 공간이 부족합니다." 또는 "too many parameter"
메시지가 나오면 다음과 같이 처리하면 된다.
한글 MS- DOS 창을 연다.
최상단의 타이틀의 왼쪽의 DOS 아이콘에 마우스를 대고 오른 쪽 버튼을 누르게 되면
나오는 메뉴 중에서 등록 정보를 선택한다.
그 다음에 메모리 탭을 선택하면 상단의 기본 메모리에서 초기환경 부분을 자동에서
2816 바이트를 선택한다음 적용을 누르고 시스템을 재 시작하면 된다.
위의 경우엔 자동 실행 파일인 경우이고 만약, 현재 파일은 *.bat의 내용중에
환경 설정하는 부분이 있으면 환경변수가 부족하다는 에러 메시지를 만나게 된다.
이럴 경우에는 *.bat에 대한 *.pif 파일을 만들어 등록 정보에서 초기 메모리를
2816으로 잡아준다. 부연하면 *.bat의 등록 정보를 콘트롤 하면 자동적으로
*.pif가 생성된다.
환경 변수 설정의 확인은 MS-DOS 창에서
c:\echo %path%
로 확인한다.
리눅스에서는
# echo $path 으로 확인한다.
/////////////////////////////////////////////////////////////////////////
이 문서는 원래 델파이 개발자를 위한 것입니다. 그래서 델파이에 관련된 내용을
기술하려 했으나 본래 취지에 맞지 않게 리눅스, 자바, 오라클, 델파이, 마케팅
내용이 들어가서 송구합니다.
볼랜드 제품 군 중에 통합 환경(IDE)인 J빌더가 아닌 순수한 JDK 설치와 관련하여
몇 가지 고려 사항을 기술하려고 합니다.
콘 솔에서 자바 컴파일 명령은
# javac -classpath d:\myclass java_source_code.java
위와 같이 -classpath 옵션을 사용하여 참조할 클래스가 있는 절대 경로를
지정해 주는 방법이 있습니다.
그런데, 만약 시스템 환경변수에
예를 들면, 윈도우에서
# set classpath= .;
리눅스에선
export classpath=./:
위와 같이 추가하면 현제 디렉토리를 중심으로 하위 디렉토리를 클래스를 찾게
됩니다. 따라서 자바 소스코드가 있는 디렉토리 중심으로 참조할 클래스를 하위
디렉토리에 두게 되면 현재 디렉토리부터 하위 디렉토리로 찾아 가게 됩니다.
그리고 패키지 클래스를 임포트한 경우라면 패키지 기술을
A.B.C.D.* 로 한다면 현재 디렉토리 중심으로 .\A\B\C\D\* 으로 찾게 되므로
결과적으로 점연산자가 디렉토리 구분자 \로 맵핑된다.
점하고 디렉토리 구분자인 / 하고 일대일 매칭 된다고 생각하면 쉽습니다.
원래 점 연산자는 클래스에서 멤버를 기술 할 때 사용됩니다.
JDK 환경에서 자바 소스 코드 중심으로 임포트 할 클래스는 소스 코드 있는 곳의
하위 디렉토리에, 웹에서 실행 할 클래스 및 jar 파일은 WEB-INF/classes
하위에 두면 콘테이너인 자카르타-톰캣이 클래스 패스를 잡아줍니다.
여기에 자바 소스 파일을 보관하지 않도록 한다.
윈도우 2000/NT 에서
set classpath=.;c:\jdk\lib\tools.jar;c:\jdk\lib\servlet.jar
자바에서는 압축 파일 형식이 zip 형태이거나 리눅스의 tar 처럼 확장자가
*.jar 인 것은 실행 파일이 아니라 압축 파일 형태임을 의미합니다.
*.zip 이나 *.tar를 환경 변수에 클래스 패스에 파일명까지 설정해 놓으면
실행중에 자동으로 압축이 풀리면서 참조 된다.
// 리눅스와 오라클 //
노련한 프로젝트 메니저가 없다면 초보 상태에서 리눅스에 오라클을 설치하여
보기 바랍니다. 아마도 엄청난 시련이 밀려 올 것입니다.
오라클에 대한 자료는 인터넷에 많이 있습니다. 그러나 오라클 세팅과 설치에
많은 시간과 노력이 필요한 것은 사실입니다.
리눅스 배포판 모두에 오라클을 설치 할 수 있는 것은 아닙니다.
수세 리눅스 같은 겨우에는 수세 리눅스 개인판에 설치하려 하면 사후에 서버로
사용하기엔 어려움이 많다. 아무래도 제일 무난한게 레드핫 배포판을 사용하는 게
좋을 것 같습니다.
* 리눅스 배포판 버전과 설치 할 오라클 RDBMS 버전에 주의하여야 한다 .
특히 리눅스 커널과 glibc 버전이 매우 중요하다 .
* 리눅스를 서버로 사용하고자 할 때는 HDD의 파티션 나눌 때 주의해야 한다.
파티션을 효율적으로 나누게 되면 많은 사용자의 수용과 DB의 성능과 리눅스
운영체제가 최적의 성능을 유지하게 된다.
이미 리눅스가 설치 되었다면 다음 명령으로 HDD의 현재 구성하고 있는
리눅스 파티션 현황과 사용량을 알 수 있다.
# df -k
* 표준적인 파티션 용량
루트파티션 / 최소 150~200MB 최대 400~600MB
/usr파티션 /usr 최소 600~800MB 최대 1200~1500MB
/home파티션 /home 최소 150MB 무제한
/var파티션 /var 최소 200~300MB 최대 400~600MB
/tmp파티션 /tmp 최소 200 최대 300 이상
/swap파티션 /swap 최소 50~120MB 램의 두배이상
위와 같이 디렉토리와 파티션을 대응 시킨 이유는 파일 시스템이
손상 되었을 경우 복구가 용이하고 최소화하기 위함이다.
** 리눅스를 서버로 사용하고자 할 때는 파티션을 나눌 때
주의를 해야한다.
만약, HDD가 9GB라면 아래와 같이 나누면 된다.
실제적인 디렉토리가 별도의 파티션에 마운트되게 하면 관리 및 복구가 용이하다.
/boot sda1 16MB
/ sda8 256MB
/home sda6 3868MB
/usr sda5 3868MB
/var sda7 256MB
/swap sda9 489MB
* 오라클 RDBMS을 설치하기 전에 먼저 환경 변수를 설정해 줘야 한다.
기계적인 성능을 설정하기 위해서는 먼저
# vi /usr/src/linux/include/asm/shmparam.h
# vi /usr/src/linux/include/linux/sem.h
내용을 적절하게 편집을 한다.
레드핫 리눅스 배포판인 경우 bash를 사용 할 경우 프로그램 경로명과 관련된
환경 변수를 설정해 줘야한다. 이것은 .bash_profile에 추가한다.
시스템 환경변수는
# vi /etc/profile
계정 사용자 환경 변수는
# vi /home/oracle/.bash_profile
# 오라클 홈 계정에 퍼미션 설정을 위한 마스크 설정을 함
export UMASK=022
# 오라클이 설치된 호스트명을 설정함
export DISPLAY=host_names:0.0
# 오라클이 설치된 홈 디렉토리 oracle 사용자 계정 디렉토리가 아님
export ORACLE_HOME=/home/oracle/8i
# 오라클 실행 데몬이 있는 경로
export PATH=$PATH:$ORACLE_HOME/bin
#export PATH=$PATH:/home/oracle/app /IBMJava2-13/jre/bin
; 리눅스에서 사용자 계정인 오라클 홈을 의미한다
export ORACLE_BASE=/home/oracle
; 오라클 DB 구조를 가진 전역 객체 파일이다. 디비 서버임
export ORACLE_SID=ORCL
export LD_LIBRARY_PATH= "${LD_LIBRARY_PATH}:$ORACLE_HOME/lib"
; 다국어 설정 부분으로 디비 버전에 따라 설정 방법이 다르다.
export NLS_LANG=AMERICAN_ AMERICA.KO16KSC5601;
export ULIMIT=2113674
; 오라클 파일들의 소유자를 의미
export ORACLE_OWNER=oracle
#export ORA_NLS33= $ORACLE_HOME/ocommon/nls/admin/data
; 클래스 패스를 의미
export CLASSPATH=$ORACLE _HOME/JRE:$ORACLE_HOME/jlib
************************************************************
다른 디렉토리에 있는 압축 파일을 현재 위치의 디렉토리에 풀고자 할 때
압축 풀 디렉토리로 먼저 이동하여 명령을 내린다
# tar xvfz /mnt/windisk/oracle8iR2.tar.gz
# chown oracle.oistall XXX 또는 chown oracle.dba XXX
************************************************************************
해당 디렉토리 아래 모든 파일의 권한을 바꾸려면
# chown -R 소유권자 타겟_디렉토리명
# chown -R oracle /usrdir
***********************************************************
오라클 데이타베이스의 기동
; 리눅스 사용자 계정 중 오라클 계정으로 로그인을 하여 DB를 마운트한다.
; 리스너는 원격 컴퓨터에 설치되어 있는 DB 서버와 통신하기 위한
; 즉, 접근하기 위한 데몬이다.
; 리스너의 환경 설정 파일은 /home/oracle/8i/network/admin/listener.ora
; 오라클을 첨 설치할 때 설치되는 listener.ora를 사용하면 안되고
; ../samples에 있는 listener.ora를 복사해서 사용하도록 한다
; listener.ora 파일은 root 권한으로 설정한 # netcfg 값의 영향을 많이 받는다.
# netcfg 의 설정 방법은
127.0.0.1 localhost.localdomain localhost
210.113.114.7 localhost.localdomain dbserver
위에서 젤 오른 쪽이 호스명에 대한 알리아스 명이다.
위 내용은 /etc/hosts 파일에 기록 된다.
; listener.ora 파일을 편집한 경우에는 시스템을 리부팅하는 게 좋다
; tnslsnrctl start
# lsnrctl start
; DB 서버 관리자의 실행
# svrmgrl
; 명령문 마직막은 ;으로 표시한다
SVRMGR> connect internal;
; DB의 시작
SVRMGR> startup;
; 서버관리자의 종료
SVRMGR> quit
***********************************************************
오라클 데이타베이스의 종료
; 서버 관리자의 실행
# svrmgrl
; DB 서버 메니저에 연결
SVRMGR> connect internal;
; DB 서버의 종료
SVRMGR> shutdown;
SVRMGR> quit
; 리스너의 종료 tnslsnrctl stop
# lsnrctl stop
*********************************************************
오라클 디비 안의 사용자 계정에 대한 암호 변경
오라클을 설치하면 기본 계정과 암호는
# sqlplus system/manager
# sqlplus sys/change_on_install
입니다 . 이것을 변경하도록 합니다.
오라클 디비가 마운트 된상태에서
# sqlplus 엔터
# sql>user name : system 엔터
# sql>password: manager 엔터
# sql>password 엔터
# sql>old password : manager 엔터
# sql>new password : angel 엔터
# sql>Retry password : angel 엔터
# quit 엔터
# sqlplus 엔터
# sql>user name : system 엔터
# sql>password: change_on_install 엔터
# sql>password 엔터
# sql>old password : change_on_install 엔터
# sql>new password : angel 엔터
# sql>Retry password : angel 엔터
# quit 엔터
***********************************************************
* 오라클 데이타베이스의 질의
# sqlplus scott/tiger
************************************************************
BDE Administrator 설정
************************************************************
; 서버 네임은 원격 호스트 이름이 아니라 원격 호스트에 설치된
; 전역 객체인 DB 서버의 이름이다.
; 네트워킹에서 IP에 해당되는 호스명이 아닙니다. 즉,
; 리눅스에서 /etc/hosts 내용에서 그 호스명이 아니며 서버네임은 일종의
; 윈도우에서 보면 데이타베이스 구조를 가진 파일명을 의미합니다.
; 입문하신분들이 많이 혼동하는 부분입니다.
; 아래와 같이 설정하면 ORCL파일은 즉 SID는 오라클 구조와 형식을
; 가진 DB 깡통이다 이 안에 테이블을 생성하게 된다.
; 대부분의 관계형 데이타 베이스는 디비 서버 파일을 즉 전역 객체 파일을 제어하기
; 위한 실행 파일과 DB 구조를 가지고 있는 디비 서버 파일로 존제한다.
* SERVER NAME : ORCL
; 사용자 네임은 운영체인 리눅스의 사용자 계정이 아니고 오라클 DB 안의 DB 사용자 계정이다.
; 유저 네임은 운영체제에 즉 리눅스에 로그인 하기위한 계정이 아닙니다.
; 이것은 각각의 관계형 디비 안의 데이타베이스 사용자 계정입니다.
; 이 유저 네임은 데이타베이스 서버 관리자를 사용하여 생성 시킬 수 있다.
* USER NAME : scott
* 리눅스에서 사용자 계정 생성 방법 *
먼저 구릅을 생성하고 사용자 계정을 생성한다. 생성된 구릅에 사용자 계정을 추가한다.
# groupadd mysql
# useradd -g mysql mysql
***********************************************************************************
많이 사용되므로 주의 할 것
* 특정 디렉토리에 하위 디렉토리까지 권한을 설정하는 방법 *
# chmod 755 -R /usr/local/mysql
# chown -R root /usr/local/mysql
# chgrp -R root /usr/local/mysql
*************************************************************
오라클 데이타베이스의 풀 백업
; 먼저 oracle로 로그인한다음에
형식은
# exp system/시스템계정암호 file=/절대경로/백업파일명.dmp compress=n log=/절대경로/로그파일명.log full=y
# exp system/manager file=BACK_FILE.dmp compress=n log=BACKUP_FILE.log full=y
보기를 들면
# exp system/manager file=/data_backup/data/2001_0306.dmp compress=n log=/data_backup/data/2001_0306.log full=y
# exp system/manager file=/data_backup/20020305.dmp compress=n log=/data_backup/20020305.log full=y
* 자바 사이트 목록 *
;자바에 대한 기본적인 내용 문서
http://rtislab.chungnam.ac.kr/~java/j_lecture/home.html
;자바에 관련된 게시판,커뮤니티가 활성화 되어 있는 곳
http://www.javaservice.net
http://www.javastudy.co.kr
http://www.javasoft.com
;Java Develope site
http://java.sun.com
;Java marketplace at Sun.
http://www.javaworld.com
**** 기호식별 ***
# : 슈퍼유저의 의미 쉘스크립트에서 주석문 의미도 있음
; : 쉘스크립트에서 주석문을 의미함
* 쉘 콘솔로 진입하는 방법
boot: linux init=/bin/sh
* 리눅스로 진입
boot : linux
* 도스로 멀티부팅 :
boot : dos
* 루트디렉토리를 읽기 쓰기 가능한 상태로 마운트하기
# mount -o remount / -rw
* FTP 서버의 사용
1. FTP 서버 사용금지자 목록 파일에서 사용하고자 하는 계정 삭제
# vi /etc/ftpusers
2. 호스트 접근 가능한 계정 목록 파일 편집
# vi /etc/hosts.allow
in.ftpd : localhost
형식 : 데몬 : 호스트네임
3. FTP 서버 실행
# /usr/sbin/ftprestart
4. FTP 서버 실행 중지
# /usr/sbin/ftpshut
* 압축파일 푸는 법 :
# tar zxvf mysql.tar.gz
* 디렉토리 이동 :
# mv dir1 dir2
* 아파치 시작하기
아파치 서버는 다음과 같이 실행합니다.
# /usr/local/apache/bin/apachectl start
아파치 서버의 실행을 종료하고 싶다면,
# /usr/local/apache/bin/apachectl stop
아파치 서버를 재시작 하고 싶다면,
# /usr/local/apache/bin/apachectl restart
와 같이 합니다.
* 부팅할 때 자동으로 서버 실행되게 설정하기
# vi /etc/rc.d/rc.local
위 파일을 편집하면 된다.
파일의 맨 마지막에 아래의 명령어를 추가하면 됩니다.
* 현제 데몬의 확인
# ps -aux | grep daemon_nanme
# ps aux | grep daemon_nanme
* 데몬의 재실행
kill -HUP 1
* 삼바의 데몬 실행
# /etc/rc.d/init.d/smb stop
# /etc/rc.d/init.d/smb start
# SAMBA NetBIOS services (for PC file and print sharing)
netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd
netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd
* 구룹 소유자 변경
# chgrp -R root /root/etc
* 소유자 변경
# chown -R root /root/etc
* 시스템 종료
# shutdown -h
* 프로세스 종료
먼저 프로세스 확인
# ps aux | grep process_name
위 명령결과 포로세스 아이디 확인
# kill -9 process_ID
* 파티션 목록 보기
# fdisk -l /dev/hda
* 특별한 플래그 세팅 루트권한으로도 수정이 불가능하고 읽기만 가능하다
chmod 명령보다 상위 명령이다.
# chattr +i /root/etc
해제 : chattr -i /root/etc
* 디스크 오류검사
# fsck -a
# e2fsck -a
* msdos 파일 시스템으로 플로피 드라이브 마운트하기
형식: mount -t 파일시스템종류 물리적인마운트장치명 논리적인마운트될디렉토리
# mount -t msdos /dev/fd0 /mnt/floppy
* 시디롬 드라이브 마운트
# mount -t iso9660 /dev/cdrom /mnt/cdrom
* 언마운트 하기전에 /mnt/cdrom에 접근하고 있는 프로세스를 모두 죽이라는 명령
# fuser -km /mnt/cdrom
**** 만약 리눅스 부팅 중에 sendmail daemon 뛰우는 중에 오래 동안 멈춰 있다면 ****
콘솔로 부팅하여 다음을 시행한다
부팅 중에 sendmail이 오래 동안 멈추는 이유는 파일 시스템 손상도 있겠지만
가장 많은 경우는 /etc/hosts 파일의 내용이 최초 리눅스 설치시와는 다르게 변경 되었을
경우에 많이 발생합니다.
# vi /etc/hosts
127.0.0.1 localhost.localdomain localhost
210.112.113.7 localhost.localdomain fly
만약 sendmail 데몬이 필요하지 않으면 부팅시에 서비스를 죽이는 방법은 다음과
같이 처리한다.
# setup
화면에 나오는 메뉴를 커서로 이동하여 system service를 선택한다
첨 부팅할 때 띄우는 데몬들인뎅 여기에서 sendmail daemon를 해제한다
*********************************************************************
데이터 베이스 생성 즉, 테이블이 존제하지 않는 빈 깡통 생성 방법은
데이터 종류에 따라 약간은 다르지만 주로 각 데이타 베이스의 서버 메니저를
통하여 생성하게 된다
또한 서버 클라이언트 환경에서 다이렉트 콘솔이 아닌 원격으로 데이터 베이스르
콘트롤 할 때는 각종 프로토콜을 이용하여 제어하게 되는 데
각각의 데이터 베이스에 대한 클라이언트 프로그램이 존제한다
클라이언트 프로그램은 데이타베이스 서버에 접근하기 위한 환경 드라이버들을
제공해 준다.
***************************************************************************
// 게임 소프트웨어의 개발 //
게임 소프트웨어를 개발한 경험은 없습니다. 게임에 대해서 논의 하는 것은
부담스런 일입니다. 게임에서 가장 중요한 것은 바로 제품 디자인 측면에서
시나리오란 것입니다. 기술은 어느 정도 수준에 이르면 어렵지 않게
축적되지만 창의적인 면이 강한 부분이 바로 시나리오입니다.
게임 상품으로 성공한 소프트웨어 모두 훌륭한 시나리오가 기본이 되었습니다.
게임이 유명해서 시나리오가 뛰어나다고 한 것이 아니라 시나리오가 소비자를
이끈 것입니다.
// 제품 디자인과 기술의 비중 //
무릇 한 기업의 경영자는 상품의 디자인에 80% 기술에 20% 비중을 둡니다.
상품의 포장을 아무리 강조해도 지나치지 않다는 말이다.
경영자의 속성은 특정 기술과 개발자의 기술에 종속되려 하지 않는다.
사업상 꼭 필요한 기술이거나 희소가치가 높은 기술이라도 제 값을 주고 기술을
구매하려 하지 않는다.
비용을 줄이려고 노력하는 것이다. 프로그램 개발이나 기타 사업에서 기술지상주의적인
발상은 매우 위험한 생각이다.
자기가 속한 개발 회사의 소프트웨어 개발 기술이 다른 개발 회사에서 꼭 필요한 경우가
있다. 경쟁 업체로서가 아니라 사양 분야인데도 다른 기업에선 필요한 경우를 말한다.
그러나 개발 기술이 융통성 있게 확산 되기란 어렵다.
// 오픈 소스에 대한 유솔로몬의 생각 //
소스 코드는 개발자가 땀과 정열, 귀한 시간을 사용하여 낸 땀의 결정체입니다.
따라서 개발자에게 소스를 공개하라 공개하지 마라는 무례한 요구는 삼가 하셔야 합니다.
공개 여부는 전적으로 개발자의 권한입니다.
소스 코드는 " 고기를 잡는 것이 아니라 고기를 잡는 방법" 즉, 노하우를 알려 주는 것으로
부가 가치가 매우 높은 것입니다.
오픈 소스 코드를 활용하여 제3의 진보된 코드를 생산 하거나 그대로 답습할 것입니다.
개발자의 소중한 재산입니다.
상업적인 다국적 기업에게는 오픈 소스 정책이 금전적으로 위협적인 것이 됩니다.
예를, 들면 어떤 응용프로그램이 다량으로 배포가 되었을 때, 그 응용 프로그램의
사용 기업이 특정 부분을 사용하고자 할 때, 많은 부분을 금전적으로 소스코드 소유 기업에
종속되어 버립니다. 그 기업 아니면 해법이 없다는 독점 상태 같은 것 말입니다.
그러나 오픈 소스가 활성화 되면 특정 문제에 대한 해법을 위해 기술적으로 금전적으로
종속되지 않아도 됩니다.
개발자는 당신의 호기심을 충족 시키기 위하여 소스를 오픈 해야할 어떠한 이유가 없습니다.
유수의 대학 내에 비직업적인 개발자가 소스 코드를 오픈 하는 이유는 기술 공유와
기술 유전과 발전을 위한 배려인 경우가 많습니다.
// 외국계 개발기업 그리고 개발자 //
외국계 개발회사에서 개발 업무를 하고 있는 개발자를 바라보고 무척 부러워하고
선망의 눈 빛을 바라보는 경우가 있습니다.
여러분도 그러한 분들 만나게 되면 근무 환경에 대해서 질문 드려 보면 조을 것
같습니다.
그런데, 의외로 그 분들이 마니 힘들어 하는 답변을 하게 됩니다.
첫째로, 모든 프로젝트가 타이트합니다.
이러한 이유로 항상 긴장하고 어떤 분들은 이것에 적응을 못해서 퇴사하는 경우가
많습니다.
둘째로, 모든 업무가 시간관리 중심으로 이루어 집니다.
첫 번째로 인하여 개인 시간으로 배정된 시간 외에는 업무 시간 중에는 업무를 위해 사용
되어야 합니다. 우리나라 처럼 참고 서적을 보며 코딩하는 것은 쉬운 일이 아닙니다.
자칫 자기 개발을 위한 공부로 인식되어 최고 경영자의 눈에 뛰이면 사직서를 내어야 합니다.
세째로, 철저하게 일정표 대로 진행 됩니다.
경험적인 것 그대로 인정되지 않습니다. 모든 성과는 수치로 환산되어 관리됩니다.
// 프로젝트 메니저(PM)가 하는 일 //
<=============================================================================인용부시작
"다양한 프로젝트 경험을 토대로 유능한 PM이 되기 위해서는
첫째, PM역할에 대해 제대로 이해한다.
프로젝트란 목표를 가지고 일정기간 내에 제품이나 서비스를 수행해야 하는 것이며,
한정된 예산과 비용으로 일정 수준의 인력을 어떻게 효율적으로 활용하는가의 문제다.
흔히 프로젝트 관리를 일정관리를 하는 정도로 이해하는 경우가 있는데
프로젝트 관리의 성공에는 많은 변수가 작용한다.
PM은 프로젝트에 대한 범위·일정·비용·품질·인력·위험·조달을 관리하고 책임진다.
둘째, PM이 되기 위해서는 실전에서의 단계적인 연습이 필요하다.
실제로 전문분야에서 개발경험이 없는 사람이 이론적인 경험을 통해 프로젝트를 진두지휘할 경우
실전경험이 없어 예상치 못한 많은 변수를 만났을 때 프로젝트 관리 및 수행을 성공적으로
이끌 수 없는 가장 큰 걸림돌로 작용할 수 있다. 유능한 PM이 되기 위해서는
프로젝트 실전경험을 토대로 단계적인 연습이 필요하다.
셋째, PM과 관련된 체계적인 훈련을 기본으로 공인된 자격증을 확보한다.
전세계적으로 PMI(Project Management Institute)에서 공인하는
PMP (Project Management Professional) 자격증에 도전해
제대로 PM이 되기 위한 길을 준비하는 것도 한 방법이다.
넷째, 비즈니스와 관련된 업무지식을 확보하기에 힘쓴다.
IT기술 관련 전문성과 함께 귀중한 자산으로 쌓이는 것이 바로 비즈니스 프로세스와
관련된 업무 지식이다.
IT관련 개발 인력들의 허점은 단순 프로그래밍에만 집착하면서
전반적인 업무지식의 보유를 게을리하는 데 있다.
부분적인 요구사항의 수렴보다 큰 줄기를 바라보고 업무의 흐름을 파악하는 것이 중요하다.
다섯째, 영어 실력을 꾸준히 연마한다.
IT관련 각종 프로젝트 혹은 컨설팅 프로젝트가 선진기술을 보유하고 있는
해외 유수 업체들과의 합작 프로젝트로 행해지고, 국내에 상주하고 있는 해외 IT업체의 경우도
실제로 솔루션·서비스를 수행하기 위해 영어로 의사소통이 가능한 PM을 확보하려 하고 있다.
실제로 각종 협력 및 제휴관계로 외국 엔지니어 및 PM과 의사소통을 할 수 있는 기회는 많이 있다.
여섯째, 원활한 의사소통 능력 및 리더십을 갖추도록 한다.
프로젝트의 영역관리 중 한 부류로 간과할 수 없는 것이 바로 '프로젝트 의사소통 관리'다.
프로젝트와 관련된 내부 인력팀 혹은 시스템을 사용할 엔드 유저(end user)와의 긴밀한 의사소통,
나아가서는 외주업체의 IT 전문인력과의 원활한 의사소통을 통한 프로젝트의 진척성 파악,
정보공유 등을 통한 프로젝트의 의사소통 관리는 성공적인 프로젝트의 완결을 위한
성공 요소임을 인지해야 한다. "
<================================================================================================인용부 끝.
<==========================================================================전자신문 게재일자 : 2002/01/16
// 현제 폼에서 다른 폼 열기 //
방법은 여러가지가 있지만 특이한 코드라 여기에 적습니다.
먼저 uses 절에 참조 할 유닛을 첨가하고
procedure TForm1.Button1Click(Sender: TObject);
begin
with TForm2.Create( nil ) do Show;
end;
// 폼위 라벨의 이메일을 클릭했을 때 아웃룩익스프로세스의 실행 //
ShellExecute( 0, nil, PChar( 'mailto:' + TLabel( Sender ).Caption ), nil, nil, SW_SHOW );
*****************************************************************************삭제부시작
// HOOKING 기법 //
아무래도 후킹은 민성기님 여덕수님, 양병규님이 뛰어나게 구현하신 것 같다.
후킹을 사용 할 때에는 세심한 주의가 필요합니다.
윈도우 운영체제에서 메시지는 운영체제의 근간을 이룹니다.
정확이 알지 않고 임의로대로 메시지를 후킹하면 운영체제가 먹통이 되거나
올바른 동작을 하지 않을 수 있습니다.
개발자가 후킹을 제대로 구현하지 못한다 하더라도 결코 실력이 있거나 없거나
판단 기준으로 고려하지 않도록 프로젝트 메니저는 주의해야 합니다.
후킹에서 고려의 대상은 윈도우 운영체제에서 후킹 기법을 사용하는 응용프로그램이
2개 이상 실행 중일 때, 심각한 문제를 일으킬 수 있습니다.
후킹은 제한적으로 꼭 필요할 경우만 사용하도록 합니다.
복사 방지잠금 장치를 위해 사용자 정의에 메시지 후킹은 권장해드립니다.
다른 한편으로, 다른 여러가지 방법으로 각종 콘트롤 사이에 전역적으로 자료를
교환하고자 할 때는 사용자 정의의 윈도우 메시지와 메모리 맵을 사용하여
데이타를 교환하도록 합니다.
후킹에 대한 사용자 정의 함수는 최소화하여 꼭 필요한 함수만 DLL안에 포함시키고
다른 함수들은 별도 공통 유닛에 만들어 두고 uses 절에 포함 시켜 사용하시기
바랍니다.
사실, 전역적으로 데이터 자료 교환과 특정 메시지 없이는 응용프로그램이 실행되지
않도록 하고자 할때만 사용하도록 합니다.
후킹에 대해서는 구현 방법에 대해서 차후 기술 할 예정입니다.
많은 개발자분들은 후킹을 크랙이나 해킹에 사용된다고 부정적인 시각을 갖고 있습니다.
그러나 이용하기에 따라서 유용하게 사용됩니다.
물론 프로그램머 채널에 이용되기는 하지만...^^
제3자가 보기에 HOOK.DLL으로 이름을 설정하면 어플에서 후킹을 사용하는게 인지된다.
가능하다면 DLL 파일의 전혀 다른 이름을 사용하는게 좋습니다.
물론 메시지 스파이를 이용하면 금방 알아내겠지만...
*******************************************************************************삭제부 끝...
// DLL 파일의 처리 //
대부분 프리랜서들은 소스코드를 넘겨주는 계약을 할 때에 핵심적인
사용자 정의 함수를 *.DLL로 묶어서 배포합니다.
물론 이 DLL 파일은 디자인 타임이나 런 타임시에서도 공통적으로 사용됩니다.
그러나 디자인시에 DLL를 사용 할 때마다 임포트를 해주는 선언 할 때마다
귀찮은 작업이 반복된다.
이럴때는 별도로 DLL를 사용하는 유닛을 만들고 그 유닛의 *.dcu 파일을 다시
use문에 기술하면 됩니다.
// 입력 받은 문자열이 숫자인지 문자인지 판별하는 사용자 정의 함수
Function MySearch(S:String):Boolean;
var
find : Boolean;
i : Integer;
begin
find := True; // 판별자 초기화
// 입력 받은 문자열의 길이가 0 이상이면
if Length(S) > 0 then begin
// 글자열의 첫자 부터 문자열 길이까징 반복
for i := 1 to Length(S) do begin
// 입력 받은 문자열이 0에서 9가 아니면 판별자에 False를 설정
if not(S[i] in ['0'..'9']) then find := False;
end;
end else begin
find := False;
end;
Result := find;
end;
// 함수의 사용
var
Result:Boolean;
begin
Result := MySearch('123');
이자료의 필자는 내가 아니라 웹 검색해서 찾아낸것입니다
--------------------------------------------------------------------------------
// 개발 분야 및 개발자의 분포 //
중소 규모의 벤처기업에서 펌웨어 제작을 위해 C나 어셈블리어, 퀵베이직등을 사용하여
프로그래밍을 하는 경우가 많았고, 특정 마이크로 칩을 사용한 프로그래밍에는
특정 회사의 PIC용 컴파일러를 사용되고 있다.
C++ 빌더와 VC++는 주로 하드웨어의 고속 제어용 프로그램을 개발하는 데, 사용되고 있다.
데이타 베이스 관련 사무용 프로그램에는 델파이, 파워빌더, 비쥬얼 베이직 등을 사용하여
구현한다. 비쥬얼 베이직 개발자가 많은 것은 툴 가격이 저렴한 영향이 크다.
델파이는 개발자 구룹에서 전문가 집단에서 사용하는 툴로 호평을 받고 있다.
필자가 구직하려고 보니, C언어쪽 개발자를 많이 찾게 된다는 사실을 알았다.
// 새내기의 개발 기업의 입사 후의 처세 //
기업내의 구성원 사이의 관계는 경쟁 관계이다. 자기의 스킬에 따라 승진, 급여,
구조조정 대상이 된다. 따라서, 동료직원 사이에는 수평선을 가지는 일정한
거리를 유지하는 것이 필요하다. 함부러 마음을 여는 것은 매우 위험한 생각이다.
대학내 동아리 처럼 선배가 인정으로 이끌어 주고 배우는 환상을 품어서는 안된다.
회사의 선배는 기업 이윤 획득이라는 공동 목표를 위해 필요한 만큼 조력을 받는 것
뿐이다. 내가 갖고 있는 각종 라이버러리를 회사 동료들에게 아낌 없이 공개한다고
해도 이러한 행위는 구조 조정시 아무 영향을 주지 않는다. 그 행위로 인사 담당자로부터
회사 기여도에 대한 평가를 받기는 무척이나 어려운 일이다. 그러나, CEO 주관으로
적극적인 지식정보시스템을 전사적으로 구축하려 할 때는 적당한 선에서 거기에
협조 할 필요가 있다. 모든 인간 관계가 그렇듯이 경쟁 관계에 있는 회사 동료라고
할 지라도 인간적인 관계를 맺는 것에 소홀이하지 않아야 한다.
구현 과정에서 적극적으로 회사 동료의 문제를 해결하여 주지 않더라도, 동료들과
어울리거나 대화하는 데 인색하지 않아야 한다.
인생 고민이나 자신의 약점을 의논 할 상대를 찾자면 동문 선배나, 회사 이외의
인생 선배나, 동호회 선배들로 부터 구하고 절대로 회사 동료들을 선택해서는 안된다.
필자가 개발자로서 비애를 느낀점은 프로젝트 때문이 아니라 자신의 개발 스킬을
위해 상대의 노하우를 다 빼냈다 싶으면 바로 해고 시켜버리는 악덕 업자들을 많이
보았다. 우리나라는 전체적으로 좁은 나라이며 개발자 간의 인맥도 매우 짧다.
따라서 특정 회사에서 깔끔한 일처리는 매우 중요하다. 나쁜 소문은 개발자 사회에
발을 딛지 못하는 결과를 가져온다.
개발자란 직업은 매우 고독한 직업이다. 그리고 잠이 부족한 직업이다. 이러한 이유는
프로젝트 메니저가 정확한 일정을 예측하지 못하고, 경영자는 개발기간 단축으로
인하여 인건비를 줄이려는 의도이다.
특정 툴과, 특정 분야에서 정통한 개발자라도 모든 개발 분야에서 전문가가 될 수는
없다. 그래서 자기가 취약한 분야가 있기 마련이며, 이것을 극복하기 위해서
오픈 마인드를 가져야 한다. 델마당 같은 동회회의 활동은 바람직하다.
// 사업계획서 작성요령 //
이 설명은 프로젝트 메니저나 프리랜서 개발자가 자영업을 하시는 데 도움을 드리고자
함이다.
1. 사업 계획서 목차
사업계획서 요약
기업 및 산업
사업 및 제품개요
시장 환경분석 / 상황분석
마케팅 계획
재무계획
조직 및 인적 자원 구성
고객 관리 계획
2. 기업소개
1). 회사일반개요
기업명
대표이사
사업영역
자본금
직원수
2). 기업의 비젼
3). 사업개념
비즈니스 모델
주요 사업 전략
향후 사업 전개 방향 :
1단계 : 고객 확보와 시장 점유율 상승
2단계 : 새로운 수익 사업으로의 확장
3단계 : 해외시장으로의 진출 모색
4). 주력 사업 아이템 소개
3. 사업 및 제품개요
1). 주요생산품
2). 주요사업 형태 및 비지니스 모델
3). 수익모델
4. 시장환경분석 및 상황
1). 국내시장 환경 분석 및 상황분석
2). 시장전망
3). 경쟁 업체 현황
5. 마케팅 계획
1). 경쟁우위전략
2). 고객창출을 위한 마케팅전략
3). 고객관리전략
4). 기업시스템 구축전략
5). 시장진입 및 성장전략
6). 예상 매출액과 시장 점유율 산정
6. 단계별 마케팅 전략
1). 시장진입전략
목표(사업목적, 제공서비스, 대상고객)
마케팅 전략(오프라인 마케팅 전략,온라인 마케팅 전략,온 오프라인 마케팅
2). 마케팅 운영 전략
고객세분화
목표시장선정(초반기,중반기,후반기)
포지셔닝
3). 고객 맞춤 마케팅 전략
초기 고객 확보
1:1 마케팅 전개
고객 데이타 베이스 활용
4). 고객유지 마케팅 전략
공유화전략
효율화전략(B2B 거래 마케팅,B2C거래형 마케팅,C2C 거래 마케팅,기업이미지홍보 마케팅)
7.경제성 분석
추정손익계산서=
평균구매액+예상구매고객수+매출원가율(30%)+(판매비/관리비=65%)+ 법인세(20%)
매출액+제조원가+매출총이익+판매비/관리비+세금 공제전이익+세금+순이익+현금흐름
8. 조직 및 인적 자원 구성
CEO(chief executive officer)
CFO(chief fiancial officer)
CTO(chief technological officer)
기술개발지원팀
마케팅홍보팀
비지니스 전략 기획팀
시스템구축/유지보수관리팀
9. 고객서비스
전화+방문+웹+전자우편+팩스=콜센터
// 방법론 탐구//
* 방법론의 프로세스
프로젝트 준비 - 환경분석 - 정보수집 - 집중분석 - 개선안 수립
프로젝트 준비 = 프로젝트 범위설정+요구분석+계획수립+사전정보수립
계획수립(구체적인 작업일정, 업무분장, 산출물정의, 작업방식,
문서화에 대한 계획수립)
환경분석 = 기술조사+관리환경분석
정보수집 = 관리정보수집
집중분석 = 구성분석+성능분석+장애분석
개선안수립 = 개선안 제시, 운영 및 관리체제 수립
// 개발자 직업의 딜래마 //
요즘은 평생 직장은 사라지고 평생 직업만 존재한다는 것을 여러분은 공감하실 것이다.
수 많은 경쟁력 속에서 살아 남아야하고 개발자나 기업 모두다 발전을 위해 새로운
변화에 도전해야만 한다. 새로운 인력의 재배치는 항상 옳은 것만아니다.
인간이란 조직 속에서 바라는 대로만 통제가 이루어지지 않고 언제나 변수가 존제한다.
자기 개발이나 고임금에 스카웃되어 심할정도로 직장을 바꾸는 결과과 항상 좋지
못했다. 보유 스킬은 많지만 기업이나 개발자 모두의 욕구를 충족시키는 경우가
드믈었다. 이러한 변화의 환경속에서도 묵묵히 저급여에도 직장을 옮기지 않고
묵묵히 성실하게 근무하는 직장인도 필요하다는 사실을 깨달앗다.
우리 개발자가 JOB을 찾아 해매이다 보면 개발자란 직업에 대한 미래에 대한 불안과
근본적인 생계 유지에 어려움이 많다는 것이다.
그래서 선배 개발자들이 제안하는 게, 많지는 않더라도 정기적인 수입을 올리는
아이템을 찾으라는 것이다. 그런데, 이것은 말처럼 쉬운일이 아니다.
비록 인기가 많고 성공적인 프로그램을 개발한다 할지라도 불법 복제를 하는 CD판매
업자들 때문에 수입에 한계가 있다. 이것을 극복하기위해 고안한 것들이 네트워크
게임류이다. 비록 크랙되어 널리 퍼진다하더라도 네트워크 접속을 해야하고, 많은
기능을 서버를 통하여 서비스한다면, 망 운영 측면에서 수익을 올리는 것이다.
지금, 필자는 취업을 위해 작년부터 준비해왔지만 지금도 해매고 있다.
안정적인 직장을 찾고 싶다.
// 프로젝트 메니저에 대한 몇 가지 오해 //
지금은 전산 전공자도 아니고 그리고 개발자도 아니고 그리고 코딩 능력을 갖춘 것은
아니지만 서울대 졸업하거나 토익 등 영어 실력이 좋으면 약 4주 정도의 교육을 시켜
프로젝트 메니저로 채용하는 것이 국내 개발 기업의 현실이다.
그럼 미국에서 생각하는 프로젝트 메니저란 무엇인가?
프로젝트 메니저란 코더로서 다년간 구현 능력을 쌓고 개발툴이나 로직등 개발 전
분야에 걸쳐 다양한 능력을 갖고 있어서 프로젝트의 위험성을 잘 알고 있고,
프로젝트 완료 기간을 정확히 예측이 가능할 정도로 안목이 생기는 사람을 말한다.
프로젝트 메니저가 되기까지 몹시 까다롭단 이야기이며 이들의 몸 값도 비싸단
이야기이다.
우리나라에서는 특정 시스템을 구현 할때 어려움을 겪게 되면, 프로젝트 메니저가
해결하는 것이 아니라, 이것의 구현 경험이 있는 개발자를 채용하여 해결하려한다.
그리고 이전 개발자가 잘하는 구현 기능에 대해선 그 개발자에게 다시 의뢰하려고
한다. 이미 해고된 이후에 그렇다.
// 프로젝트 메니저의 역할 //
* PMI 홈 페이지 : http://www.pmi.org
* 프로젝트 관리의 필요성
1. 비용과 투입공수가 착수시에는 낮으나 시간이 흐를수록 점점 높아지다가
종료시점에서는 급격하게 떨어진다.
2. 프로젝트 성공의 가능성도 처음에는 매우 높으나 점차 높아지게 된다.
3. 이해당사자들의 영향도도 처음에는 매우 높으나 점차 낮아지게 된다.
4. 변경비용과 에러수정노력은 시간이 흐를수록 점차 높아진다.
* 프로젝트 관계자
1. 프로젝트 관리자
2. 소프트웨어를 사용 할 사람이나 조직
3. 개발 인력을 파견 및 고용하는 용역회사.
4. 최종 사용자인 개인/조직의 관리자는 최소의 원가에 최대의 이익을 기대한다.
* 프로젝트 단계의 구분은 산출물 완료 시점으로 한다.
* 프로젝트의 처리요소
1. 입력물 : 문서나 문서화가 가능한 항목들
2. 도구와 기법
3. 입력물을 출력물로 변환하는데 사용되는 메카니즘
4. 출력물 : 프로세스의 결과로 산출되는 문서등
* 프로젝트 메니저가 해야 할 업무
1. 프로젝트 통합관리
프로젝트 개발기획 =
입력(다른 프로젝트 산출물,조직의 정책, 제한사항, 가정) +
도구(방법론, 프로젝트 관리 시스템) +
출력(프로젝트 계획서 )
프로젝트 기획의 실행 =
입력(프로젝트 계획서, 조직의 정책, 수정 요구 사항) +
도구(업무처리절차, 제품 기술과 지식 ) +
출력(작업결과서, 변경요구서)
요청사항처리 산출물 =
입력(프로젝트 계획서, 변경 요청서 ) +
도구(변경관리시스템, 추가 계획, 프로젝트 관리시스템 ) +
출력(프로젝트 계획변경서,변경요구서 )
2. 프로젝트 범위관리
프로젝트 범위 도입 =
입력(제품기술서,전략계획서 ) +
도구(프로젝트 선정방법론 ) +
출력(프로젝트 관리서, 제한사항서)
프로젝트 범위 기획 =
입력(범위기술서,제한사항, 다른 프로젝트 산출물) +
도구(분할기법 ) +
출력(...)
프로젝트 범위 정의 =
입력(범위기술서,제한사항, 다른 프로젝트 산출물) +
도구(분할기법 ) +
출력(...)
프로젝트 범위 검증 =
입력(작업결과서,제품설명서) +
도구(조사기법) +
출력(인수 공문)
프로젝트 범위 변경 =
입력(변경요청서, 범위관리 계획서) +
도구(범위관리시스템,추가계획) +
출력(범위변경서,수정요청서)
3. 프로젝트 일정관리
프로젝트 실행정의 =
입력(제품기술서,전략계획서 ) +
도구(프로젝트 선정방법론 ) +
출력(프로젝트 관리서, 제한사항서)
프로젝트 실행순서 =
입력(범위기술서,제한사항, 다른 프로젝트 산출물) +
도구(분할기법 ) +
출력(...)
프로젝트 실행결과 =
입력(범위기술서,제한사항, 다른 프로젝트 산출물) +
도구(분할기법 ) +
출력(...)
프로젝트 일정계획 =
입력(작업결과서,제품설명서) +
도구(조사기법) +
출력(인수 공문)
프로젝트 일정통제 =
입력(변경요청서, 범위관리 계획서) +
도구(범위관리시스템,추가계획) +
출력(범위변경서,수정요청서)
4. 프로젝트 비용관리
5. 프로젝트 품질관리
6. 프로젝트 인적자원관리
7. 프로젝트 의사소통관리
8. 프로젝트 위험관리
9. 프로젝트 진행관리
* 프로젝트 프로세스 = 착수 + 계획 + 실행 + 통제 + 종료
* 프로젝트의 관리
1. 통합관리 = 프로젝트 계획서 작성 + 프로젝트 수행 + 프로젝트 변경통제
2. 범위관리 = 프로젝트 요건파악 + 업무범위선정, 방법론선정 +
업무범위 확인 및 유지+ 업무범위 통제
3. 일정관리 = 공정계획수립(공정파악,스케쥴작성)+일정통제
4. 원가관리 = 원가산정 + 예산집행계획 + 합의 및 승인 + 경비 투입관리 +
예산집행통제(원가+인건비+경비)
5. 품질관리 = 품질보증계획수립 + 표준 및 절차수립 + 테스트계획 +
문서, 소스코드관리 + 결함보고
6. 인력관리 = 조직화 + 인력운영(교육,근태, 인사관리)+인력파견,해지,스킬등록,
7. 의사소통관리 = 의사소통절차수립+회의, 착수, 중간,완료보고+주간,월간,수시보고
의사결정요청,변경요청
8. 위험관리 = 위험파악 및 대응방안 수립 + 문제보고
9. 외주관리 = 외주계획수립,외주인력요청,외주인력선정,외주비용지급+외주인력평가+
외주업체평가+계약종료
// 인터뷰하는 요령 //
지금 설명하는 내용은 실무에서 사용된 내용이므로 그대로 사용하지 마시고
기업 특성에 맞게 수정하여 사용하시기 바랍니다.
1. 인터뷰의 준비
인터뷰의 목적을 명확화 할 것 .
인터뷰 대상자 확정후, 대상자 상사에게 사전 합의를 얻을 것
인터뷰 대상자의 상사로부터 인터뷰 대상자에게 책임,의무를 알릴 수 있도록 유도.
2. 인터뷰 요청 공문 발송.
반드시 먼저 전화 통화로 고객에게 인터뷰 계획을 의논한다음 즉시, 팩스로
문서 공문을 발송해야 한다.
전화 통화시 녹음기 사용을 양해를 구하고 고객의 허락을 받아야한다.
녹취하지 않음으로써 수 많은 분쟁이 고객과 발생한다.
사실 브로커와 계약시에도 녹취는 훌륭한 도구가 된다.
인터뷰는 프로젝트 메니저 혼자하면 안되고 2명이 한다. 한명은 인터뷰를
다른 한명은 협의 내용을 기록한다.
3. 인터뷰 요청 공문의 형식
To: 이름,제목,소속부서 Date: 오늘날짜
From:이름,프로젝트명
인터뷰일자,시간,장소
목적
가능하면 프로젝트 요약설명, 인터뷰 주제
인터뷰 목적을 기술하고 항목 기술함
토의하기를 원하는 토픽 리스트
특정 질문
의문 사항이 있으면 저에게 전화부탁드립니다.
고객의 질문 사항시 연락처를 남김
* 마케팅 이윤의 책정 : 제조 30% + 판매 10%
// 도움이 되는 글들 //
* 고난이도의 프로젝트를 실행하기 위해서는 특별한 기획 및 실행기법이 필요하다.
* 프로젝트를 주어진 시간과 예산 범위 내에서 실행하지 못할 경우
이와 관련된 단기적 및 장기적 비용을 정확하게 산출해야 한다.
* 일은 스스로 만들어 하는 것이지 주어지는 것이 아니다.
* 일이라는 것은 솔선수범하여 '적극적으로 해 나가는 것'이지 결코 수동적으로 하는 것이 아니다.
*'큰 일'과 맞서라. 작은 일은 자기 자신을 작게 만든다.
*'어려운 일'을 목표로 하라. 이것을 이루어 내는 곳에 진보가 기다린다.
* 일단 맞붙으면 '놓아주지 마라' 목적을 완수할 때까지는 죽어도 놓아주지 마라.
*'일을 끌고 가라' 끌고 가는 것과 끌려 가는 것은 엄청난 차이가 있다.
* "계획"을 세워라. 장기적인 계획을 갖고 있으면 여유와 희망이 생기고 인내심도 갖게 된다.
*'자신'을 가져라. 자신이 없기 때문에 일에 대한 추진력도 끈기도 그리고 성의마저 없는 것이다.
* 두뇌회전은 언제나 '풀 가동'으로 하라. 한 치의 빈틈도 있으면 안 된다.
* 마찰을 두려워하지 말라. 마찰은 진보의 어머니요, 적극성의 비료이다.
마찰을 두려워 하는 자는 비굴하고 뒤쳐지게 된다.
// 프로젝트 완료 보고서 작성 요령 //
지금 설명 드리려고 하는 내용은 실무에서 사용된 내용이므로 그대로 사용하시면
안되고 독자가 알맞게 커스텀마이징하면 된다.
1. 기본 프로세스 흐름도.
2. 코드구성 : 시스템에 사용된 코드 목록.
3. 파일구성 : HDD상의 실제 디렉터리 이름 및 파일명 목록표
4. 테이블 구조. : E-R 다이어그램도
필드명칭+자료형태+NULL유무 형식으로 작성
5. 화면설명서
6. 사용자 매뉴얼.
7. 프로그램 소스코드.
8. 개발일정표 : 월별 개발일정표
9. 개발비 산정표.
프로그램 스텝 = 분류+소스코드파일명+세부기능+라인수 형식으로 작성
디자인 : 이미지(그래픽),
난이도+소스파일명+세부기능+총 수량 형식으로 작성
* 개발용역비 = 소프트웨어개발비 + 시스템운영환경구축비 + 데이터제작비 +
자료입력비 + 정보전략계획수립비
* 소프트웨어개발비 = 직접인건비 + 직접경비 + 제 경비 + 기술료
* 직접인건비의 산정 : 프로젝트형태 + 개발언어 + 규모 + 적용대상규정 +
정보처리형태에 따른 보정계수 산출
// PM직의 승낙 //
재무 구조가 튼튼한 기업에서 근무 중인 개발자가 PM직을 권유 받으면 승낙하시기
바란다. 일반적으로 PM직은 고도의 전문성을 요구한다. 그러나 이러한 PM직은
외국계 개발회사에 해당되는 일이고, 일반 기업에서는 명확한 기준이 없고
애매모호하다. 즉, PM직의 원래 기능보다는 거의 인력 관리 수준에 머물러 있다.
채용하고 짜르고 악순환이다.
// 윈도우 운영체제의 보안 //
윈도우 운영체제는 우리에게 경이의 대상이다. 너무 친숙해서 그런지 모른다.
hacker,decker,cracker 등 수 많은 사람들의 표적이 되었다.
아무튼 지금은 수 많은 보안 패치가 이루어 졌지만, 항상 보안 패치보다 침입이
앞서고 있다. 기상천외한 방법으로 윈도우 운영체제를 공격하지만 이 방법이란게
일반화 되지 않고 특수한 계층의 사람들만 알고 있다가 이것이 많은 사람들에게
알려지면 패치가 되어지곤 했다. 아마도 그 중의 하나가 윈도우 98의 공유 폴더에
대한 암호 해독이 그것이다.
요즘에 특이한 방법으로 윈도우 운영체제를 공격하는 방법으로는
님다 바이러스를 이용한 침입,
자사의 홈페이지 로그인 하는 유저들 대상으로 접속 클라이언트의 로그인 창을 클릭
햇을 때 클라이언트의 보안을 해제하는 방법,
스파이웨어 CuteFTP, FlashGet, GetRight, 또는 RealPlayer 등의 루트를 이용하여
재 침입하는 방법...
애플릿, 인터넷 익스플로러의 자바 스크립트, 비쥬얼 베이직스크립트를 이용한 침입방법,
그리고 보안 패치가 되었지만 쿠키를 이용한 침입이 유행하고 있다.
// 공장자동화와 산업용기기의 제어 //
공장 자동화 뿐만 아니라 각종 산업용 기기의 제어용 프로그램을 개발할 경우가 종종
생긴다. 주로 수요처는 자본금 1억 이하의 벤처기업이다.
혹은 특허 제푼의 시제품 제작을 위해 제어용 프로그램을 필요하게 되었다.
이 기업들은 개발자에게 개발 비용을 지불 할 능력은 없지만 산업용 기기 제어용
프로그램 개발이 필요하게 된다.
우리 개발자들도 생계를 위해서 이 분야도 공부해야 한다.
아무래도 전기/전자 전공자에게 유리하다 할 것이다.
동전교환기, 계수기, 바코드 프린터, 마우스, PLC 등등 많은 기기들은 주로 베이직,
어셈블리어, C언에 의하여 컴파일 된다. 베이직은 우리가 아는 비쥬얼 베이직이
아니라 초창기의 Z8086/8088A CPU를 위한 베이직으로서 예를 들면 MS의 QUICK BASIC
을 사용하면 매우 정교한 제어용 어플을 맹글 수 있다. 컴파일 옵션을 잘 사용하면
실행 파일의 크기를 많이 줄 일 수 있다. 음, 컴포넌트 기반이 아니면서 어셈블리어
수준으로 코딩이 가능하며 유지 보수하기도 쉽다.
베이직으로 게임의 종류인 아케이드를 코딩하신 경험이 있는 분들이라면 많이 공감하실
겁니다.
그러나 요즘은 마이콤 개발의 추세와 고속 제어 처리를 위해선 어셈블리어로
코딩하는 경우가 많으며 요즘은 C로 코딩하는 경우가 많아졋다.
많은 경우에 CPU 롬에 HEXA CODE를 기록 할 때, 롬 리이더가 읽지 못하게 혹은 개발
기술을 보호하거나 컴파일러 회사에 라이센스료를 지불하지 않기 위해 암호화하는
경우가 많아졌다.
// NL 차트의 이해 //
업무 분석 단계에서 사용된 도구는 여러 가지가 있다. 지금도 FLOW CHART(흐름도)를
사용하는 경우가 많다. 그러나, 조직화된 개발 팀에서는 일반적으로 MS의 VISIO2000를
사용하여 DFD(DATA FLOW DIAGRAM)를 그리고 이것을 통하여 개발자간 의사 소통을 한다.
그러나 이것도 프로젝트 일정 때문에 잘 지켜지지 않는다.
설계 없이 곧바로 구현하는 경우가 많고, 보고서 및 설계서, 제안서등은 거꾸로 구현이
완료된 뒤에 만들어지는 경우가 많다. 이것은 분명이 잘못된 것이다.
미국이나 인도의 개발자들은 프로젝트 메니저의 개발 설계서를 보고 의견을 나누거나
독특한 도구를 사용한다. 그럼, 실무에서 사용하는 이 도구는 무엇일까?
독자는 매우 궁금해 할 것이다.
이것을 설명드리기 전에 마인드 맵을 들어 보셨는지? 이것은 우리의 맘 속의 생각을
빠르고 용이하게 기술하기 위한 기법으로 서점에 가보면 관련 서적들이 많이 있다.
이것을 약간 응용된 것으로 먼저 핵심 시스템을 박스로 묶고 박스안에 시스템 명칭이나
고려 대상을 적은 다음에 이 박스에서 수직선을 그어 내린다. 마치 일정표 처럼
만들어 지는 데 수직선 사이에는 흘러가는 정보나 방법등을 기술한다.
글로 설명해 드리려하니 얼른 감이 잡히지 않을 것이다.
대형 팀 프로젝트 수행 경험이 있는 분이나 외국계 개발 회사에 근무한 경험이 있는 분은
곧 바로 제가 무엇을 설명하고 있는지 이해 할 수 있을 것이다.
편의상 필자가 이 도구를 NL 차트라고 이름을 붙였으나, 사용해 보면 여러모로 유익하다.
정보공학 산출물을 만드는 데도 매우 유익하다.
// 국내 소프트웨어개발기술의 동향 //
정확한 통계를 제시하지 못하지만 그 동안 경험으로 국내에서의 소프트웨어 개발 기술은
주로 LG-EDS TEAMS과 삼성SDS TEAMS 기술이 산재하여 있다는 것을 알 수 있다.
물론 대형 SI 업체의 기술이라 업체간의 협약으로 노하우 비밀유지 계약 때문에 일반
개발자에게 알려지는 것은 불가능한 일이다.
추측해 보면 상기 개발회사 출신의 개발자가 고용 안정이 되지 않아 자주 자리를
옮기는 것으로 풀이된다.
지금은 IMF 이후와 KOSDAQ 붐으로 인하여 개발 팀들이 많이 해체되어 버렸지만,
소프트웨어 개발 기술이 척박한 이 땅에 땀을 흘린 분들을 생각하며
유솔로몬이 끝없이 존경하는 마음을 표한다.
초창기 우리 개발자는 전산실의 서버 관리자로서 단순 업무 때문에 개발에 필요한
시간이 생겼지만 지금은 옛날 일이 되어 버리고 많았다. 대신에 일반 잡무가 개발자에게
부여 되었다. 기획, 일반사무, 하드웨어 유지보수 까지 등등...
고급 개발자로서 C나 어셈블리어로 펌웨어 즉 장치 구동드라이버 소프트웨어 개발하는
경우가 있는 데, 국내에서 20여명 안팍으로 추산된다. 이 분들의 동향은 주로 대기업이나
프리랜서, 혹은 자영업하는 경우가 있었다.
아주 특이한 경우를 보았는 데, 게임을 개발 할 때, 컴파일러를 사용하지 않고 HEXA 에디터를
사용하여 직접적으로 기계어로 코딩하는 경우를 보았다. 필자로서는 이해가 가지 않는 일이었다.
또 한가지는 유닉스 기반의 오라클 데이타베이스를 shutdown하지 않고 손상된 레코드를 백업을
사용하지 않고 그 손상된 모듈을 기계어로 코딩하여 붙이는 경우가 있었다. 경이로운 일이다.
// 최고 경영자가 삼성SDS 출신이거나 삼성SDS에서 분사한 벤처기업에 취업하려고 할때//
프로젝트 메니저로서 구인 공고를 하는 경우에는 프로젝트 메니저 자신에게 매우 유용하다.
일반 직원이 회사 인사 정책에 관여하는 경우는 매우 드물고, 회사에서 자신의 위치가
인사에 관여 할 정도가 되면 자기 개발에 매우 유용하다.
즉, 프로젝트 메니저란 위치가 회사를 위해서가 아니라 자기 개발을 위해서 매우 중요하다.
그 이유는 입사 지원한 고급 개발자중에서 특정 분야에 대한 개발 인력의 인적 사항을 확보가
가능하고, 프로젝트 메니저 스스로에게 취약한 기술 분야에 대하여 인터뷰를 통하여
동종 경쟁 업체의 기술을 빼낼 수도 있고, 광범위한 테크니컬 로드 맵을 그릴 수 있다.
그리고 정보 통신 흐름을 파악 할 수 있는 기회를 제공한다.
그런데 특이한 점은 이러한 사항을 최고 경영자는 모르는 경우가 많다는 것이다.
다음 사항은 여러 분이 프로젝트 메니저로서 입사 지원할 때 준비해야 할 일반적인 사항이다.
예시로 회사 규모로보면 직원 수 100명에 코스닥 등록업체인 경우로 설정했다.
여러분도 잘 아시는 바와 같이, 삼성SDS는 매우 보수적인 기업이다.
보수적인 기업이라 함은 공무원 사회와 정신적인 기조가 비슷하다는 의미이다.
물론 사무적인 기조는 최첨단이다.
삼성SDS 출신의 최고 경영자는 인사 문제에 있어서 매우 보수적인 성향을 따른다.
경영자 스스로 그것을 탈피하려 하지만 뼈속 깊이 잠재적으로 그 사상이 심어져 있다.
아마도 삼성SDS 사내의 인력양성 프로그램 영향으로 보인다.
삼성SDS 출신의 CEO는 인력 채용시 4단계 이상의 까다로운 절차를 거친다.
1. 서류전형
요즘 추세가 개발자의 사내 양성이 아니라 현장에 곧바로 투입 할 수 있는 인력을
찾기 때문에 실무 경력자를 우선시한다.
프리랜서인 경우에는 인력파견업체의 사장님이나 최종 사용자의 추천서를 받아두는 게
좋습니다.
추천서에는 추천인의 연락처를 명기하여 구인 업체에서 확인이 가능하도록
합니다.
2. 직무적성검사(프로그램머 직무능력검사)
삼성SDS 출신의 CEO는 이것을 매우 중요하게 생각합니다.
비록, 비경력자라도 적성검사에서 좋은 점수를 받게 되면 채용하는 경우가 많습니다.
적성 검사 방법으로는 현장에서 얻는 실시간 데이타 또는 표를 보구 이 자료를 이용하여
역으로 정보 가공 및 분석, 추론을 할 수 있는 능력을 평가합니다.
이것은 일반 개발자라면 쉽게 습득 할 수 있습니다. 연습하면 향상 됩니다.
즉, 전산 수치해석을 의미합니다.
이 검사는 한국SHL에 의뢰하여 실시하므로 한국SHL 홈페이지를 방문해 보는 것도
유익한 일이다.
삼성SDS에서 이것을 중요하게 생각하는 이유는 아더엔더슨 컨설팅 및 SAP등 외국계
개발회사에서 객관적 평가를 위해 이러한 질문지 도구를 사용하기 때문이다.
3. 면접
삼성SDS 출신의 CEO는 인사 문제에 대하여 정형화 되어 있습니다. 따라서 매우 보수적인
성향을 따릅니다. 첫 인상, 발표하는 태도, 성격, 입사햇을 때 다른 사원간의 인화력등을
살펴 봅니다. 역시 임기응변이나 융통성이 강한 것을 선호하기도 합니다.
4. 연봉
입사 지원자가 사규에 따라서 급여를 받겟다 하더라도 희망연봉을 물어봅니다. 아마도
급여로 인한 불만을 사전에 감쇄하려는 의도입니다. 사전에 입사하려는 회사를 탐방하여
급여에 대한 초급 급여, 인사제도에 대한 자세히 조사를 할 필요가 있습니다.
뛰어난 개발 능력을 보유하고 있더라도 고액 연봉을 요구하는 경우에는 수용하지 않는다.
5. 비지니스 영어
삼성SDS 출신의 CEO는 영어 실력을 매우 중요하게 생각합니다.
해외출장 갔을 때, 호텔에 체크인, 체크아웃하는 방법, 호텔 프런트에 남겨진 전화 메시지
독해하는 방법,정보통신 기술적인 사항을 미국인 개발자와 직접 논의할 정도의 회화구사능력
6. 기타사항
실제 채용 의사가 없으면서 프로젝트 위험 때문에 비상시 구인하기 위한 인적사항을
수집하는 경우도 상당히 많다.
사내 아이템이 동종 업계인 경우엔 상대편 회사의 기술을 빼내기 위한 인터뷰로
활용하는 경우가 많다. 이것은 제가 입사 지원시 저와 함께 집단 면접을 보신 분에게
상대 경쟁 회사의 규모, 시스템 구성에 대한 예리한 질문이 있었다.
// 면접시 예시문제 //
1. 당신이 전 직장에서 퇴직하는 사유가 무엇인가요?
2. 당신이 CEO라면 프리랜서를 어떻게 관리하겠습니까?
3. 3분동안 자기 소개를 해보세요?
4. 3분동안 자기 PR을 해보세요?
5. 영어로 자기 소개를 해보세요?
6. 영어로 컴퓨터의 보안에 대한 기술 사항을 외국인과 함께 논의 가능합니까?
7. 희망 연봉은 얼마입니까?
8. 지방으로 파견냈을 때 근무 의사가 있습니까?
9. 지금 발령을 낸다면 언제 출근이 가능합니까?
10. 당신은 연령이 많은 데, 나이가 적은 상사와 인화문제,
개발 과정에서 사고의 유연성에 대하여 어떻게 생각하는가?
11. 당신이 우리 회사에 입사한 동기는 무엇인가?
12. 당신은 지금 직장에 근무 중입니까?
13. 우리가 당신을 채용한다면 언제 근무가 가능합니까?
14. 당신의 현주소는 어디입니까?
// 개발 아키텍쳐의 개념 //
tier : 어플리케이션 아키텍쳐를 논리적으로 구분하기 위해서 사용하는 용어.
2-tier 아키텍쳐 : 클라이언트/서버 어플리케이션의 하나. 두 개의 tier로 구성.
주고 받는 것 : SQL, FTP, HTTP
클라이언트 : GUI(Graphical User Interface)를 담당. 비지니스 로직을 처리
서버 : DBMS나 기타 Legacy System에 해당하는 서버.
3-tier : 클라이언트 : GUI(Graphical User Interface).
Middle-tier : 비지니스 로직을 처리.
서버 : DBMS나 기타 Legacy System에 해당하는 서버.
TP (Transaction Processing) Monitor : Tuxedo(BEA), Encina(IBM)
CORBA (Common Object Request Broker Architecture)
OTM(Object Transaction Monitor) : M3(BEA사), OrbixOTM(Iona사),
Visibroker ITS(Inprise사), TPBroker(Hitachi사)
// 어플리케이션 서버의 정의 //
분산 객체, 분산 트랜잭션, Component 모델을 제공함으로써 N-tier 구조의
어플리케이션을 쉽게 개발하고 운용할 수 있도록 해 주는 소프트웨어
플랫폼이라고 할 수 있다.
어플리케이션 서버에서 어플리케이션은 보통 Component로 개발되기 때문에
어플리케이션이라는 용어 대신 Component라는 용어를 직접 이용하는 경우가 많다.
================================================================================
*********************************************************************
[입문자를 위한 ] 미니프로젝트실무
*********************************************************************
이 자료는 지적재산권 보호를 받습니다.
개인이 개발과 관련된 연구 목적 또는 자기 개발의 목적으로 활용이 가능하지만
무단으로 배포하거나 타 게시판에 게시하지 못하며,
상용이나 영리를 목적으로 인쇄 및 배포를 금합니다.
이 글 내용의 일부분 또는 전체의 무단 전제를 금합니다.
----------------------------------------------------------------------
이 글은 대한민국의 지적재산권, 저작권 관련법의 보호를
받습니다.
이 글을 델마당, 한국델파이개발자연합, 델파이코리아 등의 게시판에
게시했다하여,
상업적으로 이용 또는 부분 및 전체 복제를 허여하는 것은 아닙니다.
즉, 묵시적으로 허용하는 것이 아닙니다.
이것은 자유 게시판에 공개된 글이라도 상업적으로 이용 가능하다는 의미가
아니며, 어떠한 경우라도 상업적으로 이용이 불가함을 알립니다.
이 글의 저작권은 유 솔로몬에게 있습니다.
Copyrights,2002,By ds4byw, All rights reserved.
초 판 : 2000. 7. 6.
최종수정 : 2002. 6. 26.
유솔로몬 (ds4byw@hanmail.net Tel 011-645-9006)
******************************************************************************
이 문서는 텍스트 포맷이며 윈도우 보조프로그램 워드패드에 최적화 되어있습니다.
" 이 문서의 수정판은 델마당 개인게시판 메뉴에서 유솔로몬 게시판에 게시됩니다."
http://www.delmadang.com/solomone
******************************************************************************
유 솔로몬은 이 글 내용 및 기법을 이용하여 제작한 프로그램이 데이타 손실 및
파괴에 대하여 민형사상 책임지지 않으며 사용자의 책임임을 알립니다.
따라서,유 솔로몬은 어떠한 경우에도 귀하에게 보증을 드리지않으니 사용에
주의하시기 바랍니다.
이 글을 대한민국에서 소프트웨어 개발을 하시는 이름모를 개발자님들과
이미 늦어버린 나이에도 개발 기술을 취득할 기회를 허락하여 주신 존경하는
박사님들과 얼굴은 모르지만 전화를 통하여 아낌 없는 도움말과 조언을 주신
한국과학기술원 연구원님들 그리고 필자에게 실무에서 아낌 없이 지도 편달을
주신 개발팀장님들께 충심으로 감사 드리며 바칩니다.
********************************************************************************
대한민국의 소프트웨어 개발 분야의 진흥이 되길 빌며...
델파이란 가공할 만한 고성능의 툴에 아낌 없는 찬사를 보내며 ...
"우리는 델파이란 툴을 사랑합니다."
델파이란 툴을 개발한 볼랜드의 델파이 개발 TEAM에 겸손한 마음으로 경의를 표한다.
델파이가 설치된 컴퓨터에서 델파이를 실행한다음 about 메뉴를 클릭한다음
alt키를 누른 상태에서 TEAM이라고 타이핑 하면 TEAM 이름이 나온다.
델파이코리아 만세! 델마당 만세! 한델만세!
http://www.delphikorea.com
http://www.delmadang.com
http://www.delphi.co.kr
*********************************************************************
// 들어가는 말 : 이 글을 쓴 동기 ~ //
필자는 수 십년 동안 컴퓨터와 함께 하면서 직업적인 프로그램머가
되려고 하면서 기업에서 실무 경력자를 선호하는 현실과 벤처기업에
발자취를 남기며 실무 현장에서 평소에 느낀 점이 많았다.
개발자들이 현장 실무에서 느끼는 고뇌와 최악의 근로 조건에서 처절한
자기 자신과의 싸움 그리고 소프트웨어 공학과 정보공학의 개념에
낮설은 우리 나라에서 이치에 맞지 않는 역현상들이 많이 발생하여
이러한 점을 안타깝게 생각하여, 수 많은 사람과 접촉하고 인터뷰한
결과를 기술하는 마음으로 이 글에 담았다. 이의가 없는 한,
아더엔더슨 컨설팅 회사와 SAP라는 회사가 보유하고 있는 노하우가
소프트웨어 개발에 있어서 훌륭한 길잡이가 됨을 의심하지 않는다.
이 글을 길잡이 하여 초등학생으로 부터 대학교수 까지 손쉽게 소프트웨어
개발이 가능하길 바라며 지적재산인 소프트웨어 분야가 기술적으로
다른 나라에 종속되지 않기를 바라는 마음 간절합니다.
짧은 실무 경력이지만 초보 델파이 개발자에게 도움을 드리기위해 이 글을 씁니다.
초보자가 초보자를 위해 글을 쓰는 일은 부담되는 일입니다.
이 글은 초보자를 위해 쓰여지지만 표현이 난해하고 어려운 용어가 사용 될 수 있으며,
주관적인 생각들이 강하므로 이 글에 대한 댓글이나 질문은 정중히 사양합니다.
이 글과 관련하여 절대로 연락하지 마세요.
어떠한 질문이나 메일, 문의 등을 사절합니다.
필자는 이 글을 열람하시는 분들께 답변할 의무는 없으며,
귀한 시간을 거기에 투자해야 할 어떤 이유가 없습니다 .
이 글의 내용 중에 특별한 경우를 제외하고는 특별히 예시를
않더라도, 사용되는 용어는 각 회사의 등록상표임을 밝힘니다.
그리고,이 글을 열람하시는 독자분들께 연재 약속을 드리지
못합니다. 다만, 개인적인 흥미로 틈틈이 글을 쓰려고 합니다.
필자는 1985년 고3부터 프로그램밍을 취미로 처음 시작했으며, 공식 경력은 4년
비공식 실무경력 5년 이상의 개발자이며 현재는 IT 분야의 컨설턴트입니다.
제 나이가 우리나라 개발 문화에서는 황혼기라고 할까요.
항상 프로그램밍에 들어가면,필자가 실무 경력자이지만 착잡한 기분을 감출 수가
없습니다..
이 글의 만약 독자분이 30대이시고 마땅한 직업이 없어서 프로그램 개발에
도전하려고 한다면, 필자는 강경하게 만류하고 쉽습니다.
여러 가지 이유로 개발업체에서 고연령 개발자를 채용하는 것을
꺼리고 있으며 고등학교 혹은 대학교 졸업을 한 전산 전공자를
선호하고 있으며 21세 이상 30세 이하가 적정 연령인 것 같습니다.
많은 분들이 그렇듯이 30세 이상인 분은 전업이나 장래에 대한
계획이 필요합니다.
이 글에서는 정보공학에 대해서는 언급을 전혀 하지 않습니다.
정보공학이 실제로 단순한 코더 보다는 오히려 부가 가치가 높은 것인지도
모릅니다.
필자는 가난한 개발자입니다. 필자가 부자이고 넉넉한 마음으로
이 글을 쓰고 있다면 마음이 편했을 텐데 웬지 서글픈 마음이 드는 것은
왜? 일까요?
개발자가 되고 싶다고 해도,간단한 업무용 프로그램을
만들려고 해도,초보자에게는 모든 것이 힘들기만 합니다.
개발 기술은 개발 회사에서 보호되어 있고 시중의 참고 서적들은
도움이 되지 않습니다. 참으로 이상한 일입니다.
개발자에 입문한지가 어제 인듯하더니 순식간에 세월이
흘러가 버렸습니다. 어느 순간, 직업적인 개발자가 되어버린 모습에
스스로 놀라울 따름입니다.
하지만, 아직도 배울게 많고, 필요한 기능을 신속하게 구현 할 수
있는 능력을 갖도록 노력하려고 합니다.
이 글에 대한 조회수가 1000회가 넘은 것에 대하여 감사를
드리는 맘입니다. 물론,1년이란 기간 동안 조회한 숫자이지만 ,
허접한 글에 대하여 여러분들이 관심을 가져 주셔서 필자로서
고마울 따름입니다.
이 글은 현업에서 실무 중 느낀 점을 간략하게나마 기술한 것이므로
주관적인 생각이 강하고 객관성이 많이 결여 되어있는 것은 사실이지만
개발 전 분야에 걸쳐서 어려움이 많다는 것을 알려 드리고 싶습니다.
일반인들은 소프트웨어가 담긴 CD 한장에 1-3만원 정도란 것이 각인
되어 있습니다.
보통 불법 소프트웨어 카피본에 1만원에 거래되고, 정품 소프트웨어 가격이
저렴할 경우에는 8만원에서 15만원 사이입니다.
따라서, 소프트웨어 개발 비용이 일천만원 이상을 한다고 말하면 도무지
벌린 입을 다물지 못합니다.
무슨 CD 한장에 일천만원 까지 하냐고...사람을 놀리지 말라고...
여러 소프트웨어 개발 회사의 기술 수준은 차이가 있습니다.
아직까지 그것들과 비교해서 이 글에서 소개한 개발 기법에 대하여
강한 긍지를 가지고 있습니다.개발자는 철저한 생존을 위한 몸부림으로
항상 최적화된 개발 기법을 찾아야합니다.
비교적 팀 프로젝트에서는 시간적인 여유를 가지고 진행 할 수 있으나
프리랜서인 경우엔 모든 작업을 혼자 해야하기 때문에 최적화된 기법을
찾기에 힘써야 하며, 프로젝트 시작 전에 라이브러리가 미리 준비 되어
있어야 합니다.
라이브러리는 공통으로 사용된 함수의 모임이나 콤포넌트, 재사용 가능한 것을
말하며 개발 시간을 단축시키고 효율적으로 코딩을 하기 위함입니다.
******************************************************************************
개발된 소프트웨어의 이상적인 국내에서 판매 카피 수는 50만 장입니다.
******************************************************************************
비록, 개발 비용을 회수 못한다 하더라도 50만 카피는 브랜드로서 성공하신
것입니다. 여러분이 프로젝트 메니저 위치에서 이 글을 접하실 때면
필자의 의견에 동의 하실 겁니다.
이제 뜻 깊은 성탄절이 다가옵니다. 필자가 델파이라는 툴을 알기전에 무척이나
고생을 많이 했습니다. 뉴스 구룹에 의지해서 해답을 찾으려고 했던 기억이 납니다.
그리고 특이한 사실은 영어의 독해력이 개발자의 개발 기술과 자기 개발에 도움이
된다는 사실입니다.
===========================================================================
이 글에 소프트웨어 공학과 정보 공학에 대한 내용을 기술하기 위하여
문서명을 델파이프로젝트실무에서 미니프로젝트실무로 변경합니다.
현재 문서에 자바, 리눅스, MySQL, JSP에 대한 내용을 추가하려 한다.
그리고, 틈틈이 제품기획과 상품기획, 마케팅에 대한 내용을 담아서
프리랜서 여러분이 자영업 하시는 데 도움이 되려고 한다.
이러한 기술 문서가 의도하는 대로 우리 모두에게 유익했음 한다.
이 글을 쓰는 시점에 제가 대형 소프트웨어 업체처럼 큰 수익을 얻었으면
조으련만 그렇지 못하여 못내 아쉬움이 많다.
개발자로 있으면서 느낀 것이지만 개발자에게 도덕적인 면이 많이 요구 되는
것 같다. 데이타베이스를 다루다보면 개인 신용정보나 개인정보들 개발과
관련된 영업기밀 등을 누설하지 않아야 한다. 또한 해킹에 대한 역추적을
위하여 본의 아니게 타 전산망을 침투하는 경우도 발생한다.
현재는 급변하는 개발기술 발전에 따라 신 개발기술을 습득해야만 하는
개발자들에게는 많은 융통성을 필요로 한다.
많은 분들이 소프트웨어 개발관련 사업계획서 작성상의 어려움을 호소하고
있고, 정보공학 및 소프트웨어공학에 대한 문의가 많이 와서 여기에 다루고자 한다.
그러나, 이 문제를 다루긴 위해선 지적재산권 문제를 고민을 해야한다.
국내에는 많은 대형 SI업체들이 존재하고 합리적으로 개발 기술을 문서화하는
방법론이 거의 대부분 미국의 아더엔더슨 컨설팅과 여러분에게 유명한 SAP의
자체적인 노하우이기 때문이다.
아무리 개량하고 발전 시켰다 하더라도 상기의 두 회사의 개발 기법을 벗어나지
않는다. 상기의 개발기법을 이용하기 위해선 천문학적인 비용이 소요된다.
그래서 컨설팅을 위해선 기업의 연간 매출이 100억 이상이 되어야 효율적으로
이용 할 수 있다. 정보공학을 고려하면 심지어 오라클의 개발 방법론 까지도
전체적으로 똑 같지는 않지만 상기한 회사의 개발 방법론이 요소요소에서
비슷하거나 공통적인 요소로 인식 할 수 있다.
그럼 천문학적인 비용을 부담하지 않고 정보공학 프로젝트를 수행하는 방법은
없을까?
필자가 여기에 고심하다 중요한 사실을 알게 되었는 데 바로 국제규격이다.
국제규격은 표준화 하는 대신에 해당 기업에 라이센스료를 지불한다.
ISO에 따르면
1. 소프트웨어품질 인증에 대한 표준규격
2. 프로젝트 관리에 대한 표준규격 등이
있다. 매우 정교하고 합리적으로 기술되어 있다.
우리 개발자들이 국제 규격을 전용하면 프로젝트 실무 전반에 대한 문서화를
효과적으로 달성 할 수 있다.
따라서, 국제 표준규격을 전용하면 어느정도 저작권 문제에 말려들지 않을 수
있지만 그래도 세심한 주의를 해야한다.
현재 서울 소재의 델파이 툴을 사용하는 소프트웨어 개발회사에 따라
또는 프로젝트 메니저에 따라서 독자적인 방법론이 존재하지만,
가장 효율적인 것을 취사할 필요가 있다.
현재 실무 경력 3년차인 프로젝트 메니저까지도 확실한 개념이해의 기반 없이
마치 모래위의 성을 쌓은 분들이 너무 많은 게 사실이다.
사실 정보공학의 산출물은 가장 정교하고도 광범위한 지도이며 설계도이다.
따라서, 개발자는 이러한 산출물만 보고도 바로 자기의 프로그래밍 언어를
사용하여 신속하고 빠른 개발이 가능해야만 한다.
//////////////////////////////////////////////////////////////////////////////
// 구직 //
개발자에게서 안정적인 수입은 매우 중요하다. 초창기에는 서버 관리자로서 안정적인
프로그램 개발을 할 수 있는 시간적 여유가 있었다.
프로젝트 메니저가 개발인력이 부족하다는 말은 고급 개발자가 부족하다는 의미이며
경영자가 개발인력이 부족하다는 말은 임금이 저렴한 개발인력이 부족하다는 의미이다.
직업에 대하여 순수했던 저에게 기분을 상하게 했던 것은 경영자가 아니면서 또는
채용 할 의사가 없으면서 저의 이력서를 요청한 사실이다.
나중에 안일이지만 개발 능력보다 중요한게 인맥이다. 개발 능력이 부족해도 고급
개발자를 많이 알아두어 프로젝트에 따라서 단지 소개만 하여도 돈을 벌 수 있는 것
이다. 경영자 또는 개발 업체에서는 특정 분야에 대한 개발 인력이 필요 할 때
공급하는 능력을 매우 중요하게 생각한다.
프리랜서라함은 단어의 의미가 자유 계약직을 의미하지만, 개발직에 있에서는
전문 개발직을 의미한다. 아르바이트와는 별개의 문제이다.
고도의 전문 개발 기술을 습득한 실무 경력자를 의미한다.
그러나 우리 나라에서는 직업소개소, 인력 파견업체를 의미한다. 독자적인 프로젝트
수주가 불가능하고 다른 기업의 프로젝트와 관련하여 사람을 소개하는 정도이다.
이런 일련의 인력파견 업체로 인하여 많은 개발자들이 이직을 하거나 전업을 하거나
개발일에 대하여 환멸을 느끼는 경우가 생겼다.
// 프로젝트 시작 : 인터뷰 //
미니 프로젝트 수행의 어려움은 역시 의사 소통이다. 초기에 필자는 이 어려움을
필자의 사무직원으로서의 행정 업무에 재직 경험으로 보완 할 수가 있었다.
그러나 이러한 점은 프로젝트 수행에 좋은 점이라고 말할 수 없다.
최고 경영자의 협조 지시가 내려 왔는 데도 실무자의 협조를 얻기란 쉽지가
않다. 회사 기밀 보호라는 장벽도 그러하거니와 자기가 가지고 있던 업무상의
노하우를 공개하지 않으려는 잠재적인 것도 부정적인 변수가 된다.
우리 실제 생활 즉 자연 환경을 전산세계로 변환 시키는 작업은 고뇌와 노력
그리고 창의적인 노력을 필요로 한다.
이 해법을 위하여 실무에서는 비슷한 유형의 프로젝트와 비교하여 맵핑 시킨다.
그러나 비슷한 유형의 프로젝트라고 하더라도 항상 참인 것은 아니다.
경영자의 정보처리 가공의 초점이 개발자가 사소한 것이라고 여기는 사건이라면
개발된 소프트웨어의 만족을 가져 올 수 없다.
한가지 예로들면 우리나라 대형 가전업체의 판매 대리점에 대한 전반적인 시스템
구축이다. 결론적으로 말씀드리면 여기서 중요 사건은 고객의 가치에 대한 감동이다.
가전매장의 문을 들어선 고객은 이 시점에 제품을 구매 할 수도 있고 아닐 수도 있다.
제품 구입을 의도한다면 매장 상주 직원에게 제품에 대한 자세한 정보를 요청 할 수도
있다. 고객은 진열 라인에 따라서 고객 취향대로 진열 제품에 대한 시선을 고정시킬
것이다. ...중략
위의 기술한 예는 인간의 복잡하고 다양한 행동 양식을 표현한 것이다. 이것을 전산
세계로 구현하는 것은 입문자에게는 쉽지가 않다. 이러한 것을 실무에 반영하기 위해선
숙련된 시나리오 작성에 유의해야 한다. 우리 개발자는 일반적으로 시나리오는 게임
개발에만 적용하는 것으로 잘 못 알려져 있다.
그러나 외국계 개발 회사에서는 시나리오가 정보공학의 초석으로 산출물 중에서 중요한
위치를 가지고 있다.
"자료구조나 알고리즘(로직)이 중요한 이유는 특정 문제 해결을 위해서 실세계의 문제를
수학적 아이디어로 랩핑시켜 해결하는 요소이기 때문입니다.
실제 세계의 모델을 컴퓨터에 어떻게 효율적으로 구현할 수 있는지를 설계하고
그것을 실제로 구현해보는 것은 매우 중요합니다.
실세계의 문제를 수학 문제로, 그리고 수학적 개념을 프로그래밍 언어로 효율적으로
표현해내는 것은 매우 중요한 능력입니다.
알고리즘(로직)의 습득을 위해서는
- 로직을 스스로 생각해낼 수 있어야 합니다.(기존의 방법이 아닌 새로운 것)
-다른 로직과 효율을 비교할 수 있어야 합니다.
-로직을 컴퓨터 언어와 다른 사람이 이해할 수 있는 의사 코드로 표현해낼 수 있어야 합니다.
- 로직이 정상작동(correctness) 여부를 검증하여야 합니다.
개발 기술을 빠르게 습득하기 위해서는 코드 내에 주석을 최소화하되 코드의 가독성이
떨어지지 않도록(혹은 오히려 올라가도록) 노력합니다.
그리고 고도의 전문가와 함께 날 밤을 세며 짝 프로그래밍을 하면
강력한 만큼 빠른 개발 기술을 습득 할 수 있습니다.
로직 패턴을 공부할 때는 그 구조보다는 의미와 의도를 우선해야 합니다.
// 프로그래밍 언어와 개발자 //
필자는 고백하건데 파스칼 언어를 많이 싫어 했습니다. 필자는 어셈블리어와
c언어의 맹신자이자 열렬한 팬입니다. 물론 하드웨어 제어 측면에서 그렇습니다.
하지만 델파이란 툴이 파스칼을 조아하게 만들었습니다.
프로젝트 메니저로서 서로 다른 언어로 된 소스코드를 분석하고 로직을 읽을 수
있기 까지는 많은 시간이 흘러야 했습니다.
한 언어에 대하여 정통하다면 비록 문법을 모른다고 해도 함수 판독은 어렵지
않습니다.
// DB와 연동된 산업용 기기제어 프로그램 //
데이타베이스와 연동된 산업용 기기(PLC포함) 프로그램은 동기화와 빠른 처리를
필요로 합니다. 따라서, 데이터 베이스 처리를 하게 되면 약 10초 라는 지연
타임이 발생하게 됩니다. 그렇게 되면 프로그램에 대한 사용자의 신뢰성이
회손됩니다. 제어기기와 연동되어 데이타 베이스에 질의를 해야한다면 기기
제어전에 사전 질의를 하여 로컬에 텍스트 포맷으로 가지고 있다가
다시 불러들여 사용하고, 만약 실시간의 기기제어 사항을 데이타 베이스에
저장해야 한다면 소켓을 사용하여 사용자 화면에 결과를 먼저 보이고
데이타 베이스에 동시에 저장하도록 한다.
만약, 서버 클라이언트 환경이라면 정상적인 질의 보다는 소켓을 효율적으로
제어하는 것이 유익하다.
// 여성 CEO 아래의 개발자의 위상 //
요즘은 벤처기업 육성 정책에 따라 20대 후반의 아름다운 여성이 CEO가 되는
경우가 많다. 이런 회사에 입사한 개발자는 행복하지 않다.
이쁜 여성 사장님과 일을 하게 되서 기쁘다는 생각은 버리는게 좋다.
거의 대부분 여성 CEO도 다른 경영자와 마찬가지로 소프트웨어 개발에 대해서
잘 알지 모른다. 여성을 상사로 두면 직장 생활하기가 편하지 않다.
정말 피곤하다.
인간적인 유대관계를 가지기 위하여 진솔한 대화를 아니 의사 소통하기가
쉽지 않다. 세심하고 정확한 여성미가 때로는 개발자에게 수 많은 스트레스를
안겨준다.
// 개발자와 스트레스 //
개발자란 직업은 극도의 스트레스를 동반하는 직업이다. 이것을 해소하기 위한
나름데로의 개발자의 반응은 스포츠, 충분한 수면, 음란한 성인자료 감상,
스타크래프트 같은 게임, 음악감상, 섹스 등으로 스트레스를 풀려고 한다.
음란물 감상, 섹스, 게임 중독은 업무에 지장이 없도록 적절한 통제가 필요하다.
또한 개발팀에 여성이 포함되어 있다면 직장에서 우발적인 혹은 의도적인 성희롱
에 주의해야한다.
직장내 회식의 경우엔 여성 직원은 1차 회식이 끝나면 반듯이 귀가 시켜야한다.
만약 이것을 지키지 않는다면 이성이나 자제력이 흐려진 상황에서 직장 동료들
사이의 섹스는 결과적으로 프로젝트를 위협하므로 주의해야한다.
개발자가 회사 내에서 극한의 스트레스 해소 목적으로 음란물을 보는 경우도 있다.
사전에 프로젝트 메니저는 여성 개발자에게 사전 이러한 사실을 인지 시키고
동료 남자 직원의 컴퓨터에 접근하는 것을 삼가하도록 사전 교육을 실시한다.
// 프로젝트 메니저의 궁극적인 의미? 공학의 의미? //
공과대학에 입학하게 되면 학과 지도 교수로 부터 공학의 의미를 듣게 된다.
공학이란 관련 순수 기술 학문에 돈을 가미한 학문으로 순수한 학문에 경제적인
가치 창출 그러니까 최소 희생으로 최대의 경제적인 효과를 내는 것을
의미합니다.
프로젝트 메니저는 소프트웨어 개발에 있어서 공통적인 인자인 돈(가치)과 결부
하여 경제적인 수익을 내는 직책을 말합니다.
다시 말하면 프로젝트의 성공을 가져오는 것 뿐만 아니라 프로젝트 결과로 수익을
내는 직책을 말합니다. 비 실무자라면 프로젝트 성공적인 완료까지를 의미하지만
현장 실무에서는 반듯이 수익을 창출해 내는 직무를 수행하는 자를 말합니다.
또 다른 CEO라고 표현하면 적절할 겁니다.
만약, 경제 환경으로 프로젝트 성공을 하였지만 개발 결과로 수익을 내지 못했다면
프로젝트 메니저로서의 책임을 다한 것은 아닙니다.
이러한 이유로 프로젝트 메니저 채용시 반듯이 개발자 출신이 아니더라도 직무
수행이 가능하다고 컨설팅 합니다.
그러나 개발자가 프로젝트 메니저 직무를 수행하게 되면 전체적으로 프로젝트를
조감 할 수 있고 여러가지로 유익한 점은 부인하지 않겠습니다.
그러나 개발자 출신의 프로젝트 메니저가 주의 할점은 고정관념을 깨야합니다.
틀에 박힌 고정 관념은 프로젝트의 성공을 위태롭게 만듭니다.
프로젝트 메니저는 프로젝트 수행 기간동안 모든 변수를 파악하고 항상 돈과
관련을 짖고 판단해야 합니다.
// 곧 바로 투입되는 개발자 양성을 위해서는...//
전공 불문하고 전산 전공자이면 더 바랄 것이 없지만, 비 전공자라면 최소 1년
정도의 프로젝트 실무 과정 또는 컴퓨터 관련 학원에서 컴퓨터와 친숙하면 좋겟다.
이런 사회 초년 대졸자를 실제 프로젝트 실무에 투입하려면 소요 기간은 약2년이며
소요 비용은 약오천만원 정도이며, 이것은 개발자가 주야로 밤을 설치면서 노력했을
때의 이야기이다. 개발자 양성이 얼마나 어려운 일인가를 단적으로 표현하고 있다.
그리고 개발회사에서 실무 경력자를 선호하는 이유는 양성하려는 비용,
즉 위탁 비용을 기업에서 부담하지 않으려 하기 때문이다.
양성을 위한 위탁비용과 인건비로 인하여 이중 부담이 되기 때문이다.
// 개발자와 브로커 //
소프트웨어 개발 세계에는 브로커란 직업이 있습니다. 브로커가 나쁘단 이야기는
아닙니다. 아마도 필요악인듯 싶습니다. 프리렌서에게는 돈 줄이니까요...
이 분들은 개발자 출신도 있지만 개발과는 전혀 인연이 없는 영업맨인 경우가
많습니다. 정부 요직의 관료와 친분있는 자와 관공서 및 기업에 소모품 납품업자
하청 업자들이 주류를 이룹니다.
날밤을 세워 어렵게 프로젝트를 완료했으나 개발비를 한 푼도 받지 못한
경험이 있나요?
어렵게 프로그램 개발을 완료하였으나 개발회사가 부도나서 급여를 한푼도
받지 못한 경우가 있나요?
소프트웨어의 개발 회사의 최소 팀 인원은 5명정도입니다.
그런데, 최고경영자와의 신의를 저버리고
중간관리자가 사장을 배신하고 직원들을 대리고 퇴사하여 회사 기술로 다른
상용프로그램을 만들어 팔다가 이 사실을 전 사장이 추적하자 그 회사를 처분하고
사라져 버리는 것을 경험하셨나요?
브로커란 프로젝트 수요처를 파악하고 프로젝트 진행중의 난해한 솔류션 개발을
위하여 개발자를 수요처에 소개하고 거액의 사례비(소개비)를 챙기는 직업을 말합니다.
인력파견 업체도 브로커 성격을 가진 경우도 있습니다.
헤드헌팅과는 질적으로 다릅니다. 브로커는 거액의 돈을 중간에서 챙기게 됩니다.
보통 대형 SI업체에서 5억 정도가 소요되는 프로젝트에 대해서도 브로커는 단번에
일천만원 정도에 해결하려고 합니다. 나머지 금액은 브로커가 금액을 취하게 됩니다.
최초 정부 발주의 프로젝트는 브로커를 위한 게 아니라 개발자에게 돌아갈 금액입니다.
그러나 건설처럼 재하청에 재하청을 주는 악순환이 생기게 되었고, 발주자로선
누가 프로젝트 비용을 취하는 데 관심은 없고 프로젝트 성공 결과만을 바랄 뿐입니다.
자본금이 1억 정도 밖에 안되는 벤처기업에서, 정작 아이템에 필요한 소프트웨어
개발이 필요하게 되었을 때,개발 자금이 전혀 없는 데도 불구하고 5백만원선에서
해결하려 듭니다. 아마도 개발자를 속이려 드는 일이지요
귀하가 프리렌서인 경우라면 계약 할 때 세심한 주의를 해야하고 개발용역대가를
반듯이 나누어 받으셔야 합니다.
프로그램 개발 완료 후 청구하는 것은 이미 늦으므로, 개발 진행에 따라 나누어
받도록해야 합니다.
// 프로젝트 수주의 과정 //
원래는 정보화촉진기금 등 정보통신 분야의 진흥을 위하여 조성된 기금은
대형 SI 업체를 위한 것이 아닙니다.
말 그대로 정보통신 분야의 진흥을 위한 기금이죠.
정보통신 분야의 육성을 위한 각종 정부 투자 자금등은
결론적으로 말씀드리면 최하위에서 실제로 그 프로젝트를 수행하는 개발자가
지속적으로 개발을 촉진하기위한 자극제입니다.
이러한 정부의 의도와는 달리 결국은 수 많은 프로젝트는 대형 SI 업체에서
수주를 하였습니다.
예를 들면, 개발아이템이 무선모뎀 개발 및 드라이버 개발이라면 이 개발을 위해
하청에 재하청에 또 하청을 받아서 최종적으로 실제 개발 업무를 담당하는
개발자로 프리랜서를 고용하여 일억오천만원을 주기로 계약하고, 프로젝트
완료 기간을 6개월로 한정하였다면 실제 수주액은 오억원이 넘을 가능성이
있습니다.
그럼, 실제로 개발을 담당한 이 개발자가 오억원에 정부로부터 이 프로젝트를
수주 받는 것이 가능할까?
실제로 불가능합니다. 비록 이 개발자가 개발능력을 정부로부터 인정 받기는
쉽지 않으며, 인정 받더라도 각종 담보가 없으면 많은 어려움이 있습니다.
대형 SI 업체는 실제로 개발 능력을 보유하고 있지 않더라도, 우선 정보통신
업체로서 각종 정부의 기준에 대한 구비요건을 갖추고 있습니다.
정부가 발주하면서 바라는 것은 실제 개발 능력이 중요한게 아니라 요식행위
즉, 각종 시행 법령에 적합한 문서와 그 요건에 맞추어 버리면 됩니다.
미국과는 마니 다른 문화입니다. 건설 같은 경우에는 시방서라는 자세한
공정 사항이 기록되어 있는 경우가 있습니다. 미국은 합리적인 문화가 발달되어
있어서 문서화가 잘된 개발회사에서는 비록 전산 전공자가 아닐지라도 그 문서만
보고도 소프트웨어 개발이 가능하다고 합니다.
정부로 부터 프로젝트를 수주하기위해 대형 SI 업체에서는 실제 개발에 참여 할
개발자도 이력서를 통하여 연락처와 인적사항을 알고 있으면 된다.
자기 회사에 고용된 직원이 아니더라도 된다.
비록 개발능력이 없다고 하더라도 정보처리기사1,2급 등 관련 자격 소지자가
있다면 수주 받기가 용이하다.
결국은 이러한 악성 구조가 실제 현업에서 개발자의 수명을 단축하게 만들며
개발자란 직업을 버리고 다른 직종으로 이직하게 만듭니다.
현실에서는 개발자가 필요로 되는 경우에는 고액의 외화를 들여 인도나 미국에서
개발자를 수입하게 됩니다.
// 대형 SI 업체의 타업체 개발 기술을 훔치는 방법 //
예를 들면, 브랜드 가치가 10억이 넘는 업체 A사가 있다고 가정하면, 이 업체는
특정회사를 지칭하는 것이 아니므로 국내의 모 회사를 연상해서는 안된다.
이 글에서는 그냥 보기를 들었을 뿐입니다.
A사에서는 실제 개발 인력을 보유하고 있는 중소 업체들에게 공문을 통하여 제안서
요청을 합니다.
제안서 요청시 프로젝트와 관련있다고 하여 세부 스펙을 정해놓고 기술 사항까지
기술하도록 유도하게 됩니다. 중소 규모 업체들은 이것을 수주하기 위해 불필요한
회사의 개발 노하우까지 제안서에 기술하게 됩니다.
수주를 위해서 고육지책으로 이렇게 하는 것입니다.
A사의 입장에서 보면 방대한 기술 자료가 자동적으로 수집하게 됩니다.
프로젝트 수주에 응했던 중소 기업들이 연락이 오지 않아서, 어떤 기업이 수주하게
되었나 문의해보면, 프로젝트를 발주햇던 A사가 자체 개발하고 있음을 알게 됩니다.
물론,제출된 제안서 덕분에 스펙과 테크니컬 로드맵이 작성된것은 당연하구요.
그럼, 이러한 점을 막기 위해 어떻게 해야 할 까?
프로젝트 수행 제안서에서는 불필요한 개발 노하우까지 기술되지 않도록 주의해야
하며, 발주를 한 대형 업체의 최고 경영자와 직접 접촉 및 계약을 하거나
차라리 로비를 해야합니다. 물론 공개입찰 형식을 시행한다하더라도 내부적으로
결정되게 만들어야 합니다.
두번째 방법으로 타회사의 개발 기술을 훔치는 방법을 기술하겟습니다.
우선 프로젝트를 발주합니다. 발주하면서 특약 사항을 넣게 되는 데, 발주처에서
감독관이란 직책을 주어 자사 직원을 프로젝트 수행 개발자들과 함께 참여하도록
만듭니다. 프로젝트 진행기간 동안 관련 개발 기술을 모조리 훔쳐내게 됩니다.
이것을 막기위해 특약 사항을 만들기 전에 감독관 범위와 회사 노하우 보호를
위한 장치를 만들어야 합니다.
세번째 방법으로 이것은 영업 기밀 즉 노하우 보호와 밀접한 관련이 있습니다.
즉, 핵심 기술을 보유하고 있는 대리급 개발자에게 접근하여 거액 연봉 제시를 하여
별도로 기술적인 면접을 봅니다. 스카웃 내용에 대한 계약 이행에는 시간을 끌며
핵심적인 기술 사항에 대한 질문을 하여 개발 기술을 훔쳐 내게 됩니다.
종국에는 자사의 인사 위원회의 결정으로 스카웃이 백지화 되었다고 통보하게
됩니다.
거액 연봉 제시의 스카웃 제의로 핵심 노하우 유출이 너무 쉽게 됩니다.
영업 기술 유출은 친고죄로서 민사 및 형사상의 책임을 져야 합니다.
// JSP 환경의 구축 //
델파이 개발자가 다른 개발 언어에 관심을 갖는 것은 매우 흥미롭다.
JSP는 윈도우 환경에서 코딩하여, 컴파일 하고,
사용 할 때는 리눅스 서버에 적재하는 것이 이롭다.
물론 리눅스에서 VI 편집기로 코딩하는 것도 괜찮을 것 같다.
우선 코딩 플랫 폼은 윈도우 NT4.0/WINDOWS2000pro에서 하는 것을 추천한다.
윈도우 환경은 왠지 불편함을 느낀다.
*** EJB의 개념 ***
Enterprise Java Bean은 일종의 업무용 컴포넌트이다.
또한 wrapper class file이다.
재사용을 위한 것을 보면 라이브러리라고 해도 틀리지 않다.
윈도우 운영체제에서 공유 DLL은 런타임시 각 응용프로그램에서 동적으로 메모리에
적재하여 사용한다. 그리고 각 응용프로그램에서 공유하여 사용한다.
이런 개념에서 볼때에 자바빈은 자바 콘테이너 서버에서 실행시 동적페이지에
빈 테그를 사용하여 서브릿을 참조하게 된다.
어쩌면 공유DLL, 혹은 공유 라이브러리라고 이해하면 될 것 같다.
사실 데이타베이스 접근 및 업무용 질의어를 JSP 내에 코딩하게 되면
지루하게도 똑 같은 코드가 반복되며, 이와 관련된 JSP 파일을 클라이언트에서
다운로드 받게 되면 모든게 노출되어 보안상 이롭지 못하다.
물론 자바의 특성상 역컴파일이 가능하기 때문에 소스 코드의 노출 위험은 언제나
존재한다.
1. 선의 자바 사이트에 가보면 컴파일러를 다운 받아보려고 하면 수 많은 버전들이
존재하여 어떤 것을 다운 받아야 할지 어려움을 느끼게 된다.
물론 최신 버전을 다운 받으면 되겟지라는 생각은 금물이다.
우선 JDK 버전은 데이타 베이스 관련 서브릿 개발 환경이 목적이므로 반드시
JDK가 아닌 J2SDK-1_3_0_02 버전을 다운 받는 게 노하우이다.
2. 컨테이너를 다운 받으려고 자카르타 톰 캣 사이트에 가보면 무수히 많은
버전 때문에 당황하게 된다.
물론 최신 버전을 받으면 되겟지?라는 생각은 금물이다.
JAKARTA-TOMCAT-3.2.4를 다운 받아야 합니다. 그 이상의 버전을 다운 받으면
JSP와 서브릿을 지원하는 범위가 다릅니다. 그 이상의 버전을 다운 받아 압축을
풀어보면 라이브러리에 servlet.jar가 포함되어 있는지 확인하기 바란다.
3. mysql은 mysql-3.23.49가 무난하며,
mysql을 위한 ODBC 드리이버는 myodbc-2.50.39를 다운 받으며,
JDBC 드라이버는 mysql.jar 형태로 압축된 것을 다운 받아서 사용한다.
4. 각종 라이브러리 클래스 파일, 컴포넌트 클래스 파일, 그리고 이것을 JAR 파일
형태로 압축된 것을 c:\jdk1.3\jre\lib\ext로 copy한다. 물론, 사용자 마다
JSDK 설치 디렉토리가 다르게 된다. c:\jdk1.3\jre\lib\ext는 런타임시에
참조할 클래스패스상에 존재하는 디렉토리이다.
리눅스에서는 J2SDKSE1.2.2 + tomcat3.1
윈도우2000에서는 J2SDK1.3.0 + tomcat3.2.4
를 권장한다.
다음은
톰캣이 올바르게 설치되어 있는지 검사하는 소스코드이다.
파일명 :flowservlet
import javax.servlet.*;
import javax.servlet.http.*;
public class flowservlet extends HttpServlet {
public void init(ServletConfig sc) {
System.out.println("init() 가 호출되었습니다.");
}
public void service (ServletRequest reg, ServletResponse res) {
System.out.println("service() 가 호출되었습니다.");
}
public void destory() {
System.out.println("destory() 가 호출되었습니다.");
}
}
테스트는 것을 컴파일하면 flowservlet.class가 생성 되는 데 이것을
홈페이지 루트 디렉토리하위에 예론
c:\public_html\WEB-INF\classes 에 복사한다.
그 다음에 컨테이너 톰 캣을 실행하고나서
웹브라우저의 URL에
http://localhost:8080/servlet/flowservlet 을 입력하여
에러 없이 아무 화면이 안나오면 설치가 제대로 된 것이다.
소스 코딩 및 컴파일 작업은 윈도우 플랫폼에서 하고
실행은 클래스 파일을 FTP로 리눅스 서버로 넘겨서 한다.
리눅스 서버로 넘길 때는 압축파일로 넘기는 게 좋다.
// 프로젝트 메니저의 인력관리 //
프로젝트 메니저의 중요한 업무 중의 하나가 인력관리 라는 것을 아래 글에서
부연한바 있다.
개발인력의 급여 책정은 개발자의 급여의 3배 수익을 보고 결정합니다.
예를 들면, 개발자가 연봉 일천만원에 계약 했다면 그 개발자에게 1년에
약 3천만원 정도의 수익을 낼 것을 기대합니다.
1년 회사 경영에 예상 수익의 3분의 1정도에서 결정합니다.
쉽게 설명드리면 개발자가 자기가 받는 급여의 3배 정도를 벌어 드리기를
기대한다는 이야기입니다.
// 시리얼 통신 제어 프로그램 -- 프로그래밍 기법 //
여러분이 프리랜서 아니면 초보 개발자라 할지라도 가장 많이 코딩하게 되시는 것이
바로 산업용 시리얼 통신 기기의 제어입니다.
주로 컴퓨터와는 근거리 즉 2미터 이내의 케이블로 연결된 장치를 제어하게 됩니다.
보기를 들면 각종 POS 기기, 바코드 프린터, 터치모니터, 전광판, 카드 인식기기,
휴대폰, PDA 등 수 없이 많습니다.
우선 시리얼 통신 제어 프로 그램을 작성하기 위해선 시리얼 컴퍼넌트를 활성화
하는 부분을 try ~ except ~ end; 문으로 감싸야 합니다.
이렇게 하지 않으면 에러 발생시 컴퓨터가 먹통이 되는 경우도 생깁니다.
다른 어플에서 시리얼 포트를 사용 할 때 또 다른 어플이 같은 시리얼 포트를
사용하지 않도록 해야합니다.
우선 시리얼 제어용 유명한 상용 컴포넌트는 바로 터보 파워의 어씽크
프로페션널입니다. 가격은 아마도 일백만원대 일 것입니다.
이 컴포넌트는 우리에게 많이 알려져 있습니다.
어씽크 콤퍼넌트를 사용 할 때 주의 사항은 버전에 따라서 일회 전송 량이
8 바이트로써 ( 8 * 1024 ) 8바이트가 넘은 경우에는 8바이트 씩 나누어 가져옵니다.
그래서 stx := #02 + 전송 데이터 + etx := #03 형식으로 가져옵니다.
여기에서 전송 데이터가 20 바이트가 넘는 경우에는 어씽크에서는 두번 나누어서
가져오게 됩니다. 전송 이 벤트가 여러번 호출 된다는 의미입니다.
이것은 제어용 데이타가 산업용 제어기기에 전송 시점의 동기화가 필요 할 때는
무척 제어를 어렵게 만듭니다.
모든 시리얼 콤포넌트가 그렇듯이 char 타입으로 1문자씩 8비트로 가져옵니다.
보통 컴포넌트 이벤트에서 카운터 많큼 가져 옵니다.
var
i : integer;
read_data : string;
begin
for i := 1 to count do
read_data := read_data + getread();
end;
예를 들어 알파벳 A라는 문자가 전송 될 때,
STX - A - ETX 또는 [02] - A - [03] 이렇게 전송됩니다.
일단 컴포트로 전송된 데이터를 읽어 드려서 STX가 감지되면 지금 버퍼로 읽어 드리고
있는 중이고 ETX가 감지되면 전송이 끝났다는 것이 감지됩니다. 보통 이 때 데이터를
버퍼로 부터 읽어 들이고 난 다음에 다음 전송을 위해서 버퍼를 초기화 시킵니다.
로직을 자세히 설명드리면,
우선 컴포트 상태를 판별하기 위한 상수가 필요합니다.
stx := 02, etx:=03 으로 상수가 사전 정의 된다.
컴포트 작동을 콘트롤을 하는 판별자를 상태에 따라 변수에 배열 형태로 자료형을 정의하고
그 크기를 설정한다. 변수의 그 크기를 측정하고 그 크기만큼 0으로 채워서 배열 변수를
초기화 시킨다.
카운터가 0 이상이면 카운터 -1 만큼 변수에 읽어 드린 자료를 저장한다.
변수에 읽어드린 데이타를 검사하여 컴포트의 상태를 판별한다.
만약 STX가 인지되면 버퍼에 자료를 수신중임을 나타낸다.
읽어 드린 변수가 STX으로 인지되면 버퍼 변수를 초기화하고 컴포트 상태 판별자를
수신가능 상태로 설정한다.
읽어드린 변수 값에서 ETX가 판별되면 수신 데이타를 모니터 콘트롤에 표시하고
버퍼 변수는 초기화 시킨다.
///////
윈도우에서 클라이언트 프로그램을 설치하다 보면 설치 관리자 프로그램의 사소한
실수로 예론, path 설정 부분에 특수 제어문자 혼입으로, 환경 변수의 path가
먹혀들지 않아 곤란을 겪는 경우가 종종 있습니다.
window 95/98에서 autoexec.bat의 내용중에 path을 설정하는 방법입니다.
형식은 set path="절대경로"
다음줄에 set path="절대경로";"%path%";
형식은 set classpath="절대경로"
다음줄에 set classpath="절대경로";"%classpath%";
보통 autoexec.bat 파일을 편집기로 열어서 한줄에 이어서 적어주어야 하는 데
만약, 한 라인이 길경우에나 제어문자가 혼입되는 경우에 라인이 분리되어
path 설정이 안되는 경우가 많습니다.
이런 경우에는 한줄에 다 기록하지 말고 다음 라인에 기록을 해야합니다.
즉, 이미 설정된 환경변수 %path%를 이용하게 됩니다. 만약 편집이 잘 못되어
2라인으로 인식되면 환경변수를 저장할 공간이 부족합니다 라는 에러 메시지를
냅니다. 그래서 다음 보기와 같이 작성해야 합니다.
보기를 들면,
set path="c:\informix\bin"
set path="c:\other application\bin\;"%path%";
다음 보기를 들면
set path="c:\;c:\windows;c:\windows\command;";
set path="c:\first appl";"%path%";
set path="c:\second appl";"%path%";
위에서 보면 중요도가 높은 프로그램이 설정 부분의 제일 앞에 오도록합니다.
이방법 말고 레지스터리를 이용하면 더 손쉽게 경로 설정을 할 수 있습니다.
CPU가 특정 실행 프로그램을 찾으려 할 때 레지스터리를 이용하여 CPU에 알려주면
그만이다.
위와 같이 하더라도 " 환경변수 저장 공간이 부족합니다." 또는 "too many parameter"
메시지가 나오면 다음과 같이 처리하면 된다.
한글 MS- DOS 창을 연다.
최상단의 타이틀의 왼쪽의 DOS 아이콘에 마우스를 대고 오른 쪽 버튼을 누르게 되면
나오는 메뉴 중에서 등록 정보를 선택한다.
그 다음에 메모리 탭을 선택하면 상단의 기본 메모리에서 초기환경 부분을 자동에서
2816 바이트를 선택한다음 적용을 누르고 시스템을 재 시작하면 된다.
위의 경우엔 자동 실행 파일인 경우이고 만약, 현재 파일은 *.bat의 내용중에
환경 설정하는 부분이 있으면 환경변수가 부족하다는 에러 메시지를 만나게 된다.
이럴 경우에는 *.bat에 대한 *.pif 파일을 만들어 등록 정보에서 초기 메모리를
2816으로 잡아준다. 부연하면 *.bat의 등록 정보를 콘트롤 하면 자동적으로
*.pif가 생성된다.
환경 변수 설정의 확인은 MS-DOS 창에서
c:\echo %path%
로 확인한다.
리눅스에서는
# echo $path 으로 확인한다.
/////////////////////////////////////////////////////////////////////////
이 문서는 원래 델파이 개발자를 위한 것입니다. 그래서 델파이에 관련된 내용을
기술하려 했으나 본래 취지에 맞지 않게 리눅스, 자바, 오라클, 델파이, 마케팅
내용이 들어가서 송구합니다.
볼랜드 제품 군 중에 통합 환경(IDE)인 J빌더가 아닌 순수한 JDK 설치와 관련하여
몇 가지 고려 사항을 기술하려고 합니다.
콘 솔에서 자바 컴파일 명령은
# javac -classpath d:\myclass java_source_code.java
위와 같이 -classpath 옵션을 사용하여 참조할 클래스가 있는 절대 경로를
지정해 주는 방법이 있습니다.
그런데, 만약 시스템 환경변수에
예를 들면, 윈도우에서
# set classpath= .;
리눅스에선
export classpath=./:
위와 같이 추가하면 현제 디렉토리를 중심으로 하위 디렉토리를 클래스를 찾게
됩니다. 따라서 자바 소스코드가 있는 디렉토리 중심으로 참조할 클래스를 하위
디렉토리에 두게 되면 현재 디렉토리부터 하위 디렉토리로 찾아 가게 됩니다.
그리고 패키지 클래스를 임포트한 경우라면 패키지 기술을
A.B.C.D.* 로 한다면 현재 디렉토리 중심으로 .\A\B\C\D\* 으로 찾게 되므로
결과적으로 점연산자가 디렉토리 구분자 \로 맵핑된다.
점하고 디렉토리 구분자인 / 하고 일대일 매칭 된다고 생각하면 쉽습니다.
원래 점 연산자는 클래스에서 멤버를 기술 할 때 사용됩니다.
JDK 환경에서 자바 소스 코드 중심으로 임포트 할 클래스는 소스 코드 있는 곳의
하위 디렉토리에, 웹에서 실행 할 클래스 및 jar 파일은 WEB-INF/classes
하위에 두면 콘테이너인 자카르타-톰캣이 클래스 패스를 잡아줍니다.
여기에 자바 소스 파일을 보관하지 않도록 한다.
윈도우 2000/NT 에서
set classpath=.;c:\jdk\lib\tools.jar;c:\jdk\lib\servlet.jar
자바에서는 압축 파일 형식이 zip 형태이거나 리눅스의 tar 처럼 확장자가
*.jar 인 것은 실행 파일이 아니라 압축 파일 형태임을 의미합니다.
*.zip 이나 *.tar를 환경 변수에 클래스 패스에 파일명까지 설정해 놓으면
실행중에 자동으로 압축이 풀리면서 참조 된다.
// 리눅스와 오라클 //
노련한 프로젝트 메니저가 없다면 초보 상태에서 리눅스에 오라클을 설치하여
보기 바랍니다. 아마도 엄청난 시련이 밀려 올 것입니다.
오라클에 대한 자료는 인터넷에 많이 있습니다. 그러나 오라클 세팅과 설치에
많은 시간과 노력이 필요한 것은 사실입니다.
리눅스 배포판 모두에 오라클을 설치 할 수 있는 것은 아닙니다.
수세 리눅스 같은 겨우에는 수세 리눅스 개인판에 설치하려 하면 사후에 서버로
사용하기엔 어려움이 많다. 아무래도 제일 무난한게 레드핫 배포판을 사용하는 게
좋을 것 같습니다.
* 리눅스 배포판 버전과 설치 할 오라클 RDBMS 버전에 주의하여야 한다 .
특히 리눅스 커널과 glibc 버전이 매우 중요하다 .
* 리눅스를 서버로 사용하고자 할 때는 HDD의 파티션 나눌 때 주의해야 한다.
파티션을 효율적으로 나누게 되면 많은 사용자의 수용과 DB의 성능과 리눅스
운영체제가 최적의 성능을 유지하게 된다.
이미 리눅스가 설치 되었다면 다음 명령으로 HDD의 현재 구성하고 있는
리눅스 파티션 현황과 사용량을 알 수 있다.
# df -k
* 표준적인 파티션 용량
루트파티션 / 최소 150~200MB 최대 400~600MB
/usr파티션 /usr 최소 600~800MB 최대 1200~1500MB
/home파티션 /home 최소 150MB 무제한
/var파티션 /var 최소 200~300MB 최대 400~600MB
/tmp파티션 /tmp 최소 200 최대 300 이상
/swap파티션 /swap 최소 50~120MB 램의 두배이상
위와 같이 디렉토리와 파티션을 대응 시킨 이유는 파일 시스템이
손상 되었을 경우 복구가 용이하고 최소화하기 위함이다.
** 리눅스를 서버로 사용하고자 할 때는 파티션을 나눌 때
주의를 해야한다.
만약, HDD가 9GB라면 아래와 같이 나누면 된다.
실제적인 디렉토리가 별도의 파티션에 마운트되게 하면 관리 및 복구가 용이하다.
/boot sda1 16MB
/ sda8 256MB
/home sda6 3868MB
/usr sda5 3868MB
/var sda7 256MB
/swap sda9 489MB
* 오라클 RDBMS을 설치하기 전에 먼저 환경 변수를 설정해 줘야 한다.
기계적인 성능을 설정하기 위해서는 먼저
# vi /usr/src/linux/include/asm/shmparam.h
# vi /usr/src/linux/include/linux/sem.h
내용을 적절하게 편집을 한다.
레드핫 리눅스 배포판인 경우 bash를 사용 할 경우 프로그램 경로명과 관련된
환경 변수를 설정해 줘야한다. 이것은 .bash_profile에 추가한다.
시스템 환경변수는
# vi /etc/profile
계정 사용자 환경 변수는
# vi /home/oracle/.bash_profile
# 오라클 홈 계정에 퍼미션 설정을 위한 마스크 설정을 함
export UMASK=022
# 오라클이 설치된 호스트명을 설정함
export DISPLAY=host_names:0.0
# 오라클이 설치된 홈 디렉토리 oracle 사용자 계정 디렉토리가 아님
export ORACLE_HOME=/home/oracle/8i
# 오라클 실행 데몬이 있는 경로
export PATH=$PATH:$ORACLE_HOME/bin
#export PATH=$PATH:/home/oracle/app /IBMJava2-13/jre/bin
; 리눅스에서 사용자 계정인 오라클 홈을 의미한다
export ORACLE_BASE=/home/oracle
; 오라클 DB 구조를 가진 전역 객체 파일이다. 디비 서버임
export ORACLE_SID=ORCL
export LD_LIBRARY_PATH= "${LD_LIBRARY_PATH}:$ORACLE_HOME/lib"
; 다국어 설정 부분으로 디비 버전에 따라 설정 방법이 다르다.
export NLS_LANG=AMERICAN_ AMERICA.KO16KSC5601;
export ULIMIT=2113674
; 오라클 파일들의 소유자를 의미
export ORACLE_OWNER=oracle
#export ORA_NLS33= $ORACLE_HOME/ocommon/nls/admin/data
; 클래스 패스를 의미
export CLASSPATH=$ORACLE _HOME/JRE:$ORACLE_HOME/jlib
************************************************************
다른 디렉토리에 있는 압축 파일을 현재 위치의 디렉토리에 풀고자 할 때
압축 풀 디렉토리로 먼저 이동하여 명령을 내린다
# tar xvfz /mnt/windisk/oracle8iR2.tar.gz
# chown oracle.oistall XXX 또는 chown oracle.dba XXX
************************************************************************
해당 디렉토리 아래 모든 파일의 권한을 바꾸려면
# chown -R 소유권자 타겟_디렉토리명
# chown -R oracle /usrdir
***********************************************************
오라클 데이타베이스의 기동
; 리눅스 사용자 계정 중 오라클 계정으로 로그인을 하여 DB를 마운트한다.
; 리스너는 원격 컴퓨터에 설치되어 있는 DB 서버와 통신하기 위한
; 즉, 접근하기 위한 데몬이다.
; 리스너의 환경 설정 파일은 /home/oracle/8i/network/admin/listener.ora
; 오라클을 첨 설치할 때 설치되는 listener.ora를 사용하면 안되고
; ../samples에 있는 listener.ora를 복사해서 사용하도록 한다
; listener.ora 파일은 root 권한으로 설정한 # netcfg 값의 영향을 많이 받는다.
# netcfg 의 설정 방법은
127.0.0.1 localhost.localdomain localhost
210.113.114.7 localhost.localdomain dbserver
위에서 젤 오른 쪽이 호스명에 대한 알리아스 명이다.
위 내용은 /etc/hosts 파일에 기록 된다.
; listener.ora 파일을 편집한 경우에는 시스템을 리부팅하는 게 좋다
; tnslsnrctl start
# lsnrctl start
; DB 서버 관리자의 실행
# svrmgrl
; 명령문 마직막은 ;으로 표시한다
SVRMGR> connect internal;
; DB의 시작
SVRMGR> startup;
; 서버관리자의 종료
SVRMGR> quit
***********************************************************
오라클 데이타베이스의 종료
; 서버 관리자의 실행
# svrmgrl
; DB 서버 메니저에 연결
SVRMGR> connect internal;
; DB 서버의 종료
SVRMGR> shutdown;
SVRMGR> quit
; 리스너의 종료 tnslsnrctl stop
# lsnrctl stop
*********************************************************
오라클 디비 안의 사용자 계정에 대한 암호 변경
오라클을 설치하면 기본 계정과 암호는
# sqlplus system/manager
# sqlplus sys/change_on_install
입니다 . 이것을 변경하도록 합니다.
오라클 디비가 마운트 된상태에서
# sqlplus 엔터
# sql>user name : system 엔터
# sql>password: manager 엔터
# sql>password 엔터
# sql>old password : manager 엔터
# sql>new password : angel 엔터
# sql>Retry password : angel 엔터
# quit 엔터
# sqlplus 엔터
# sql>user name : system 엔터
# sql>password: change_on_install 엔터
# sql>password 엔터
# sql>old password : change_on_install 엔터
# sql>new password : angel 엔터
# sql>Retry password : angel 엔터
# quit 엔터
***********************************************************
* 오라클 데이타베이스의 질의
# sqlplus scott/tiger
************************************************************
BDE Administrator 설정
************************************************************
; 서버 네임은 원격 호스트 이름이 아니라 원격 호스트에 설치된
; 전역 객체인 DB 서버의 이름이다.
; 네트워킹에서 IP에 해당되는 호스명이 아닙니다. 즉,
; 리눅스에서 /etc/hosts 내용에서 그 호스명이 아니며 서버네임은 일종의
; 윈도우에서 보면 데이타베이스 구조를 가진 파일명을 의미합니다.
; 입문하신분들이 많이 혼동하는 부분입니다.
; 아래와 같이 설정하면 ORCL파일은 즉 SID는 오라클 구조와 형식을
; 가진 DB 깡통이다 이 안에 테이블을 생성하게 된다.
; 대부분의 관계형 데이타 베이스는 디비 서버 파일을 즉 전역 객체 파일을 제어하기
; 위한 실행 파일과 DB 구조를 가지고 있는 디비 서버 파일로 존제한다.
* SERVER NAME : ORCL
; 사용자 네임은 운영체인 리눅스의 사용자 계정이 아니고 오라클 DB 안의 DB 사용자 계정이다.
; 유저 네임은 운영체제에 즉 리눅스에 로그인 하기위한 계정이 아닙니다.
; 이것은 각각의 관계형 디비 안의 데이타베이스 사용자 계정입니다.
; 이 유저 네임은 데이타베이스 서버 관리자를 사용하여 생성 시킬 수 있다.
* USER NAME : scott
* 리눅스에서 사용자 계정 생성 방법 *
먼저 구릅을 생성하고 사용자 계정을 생성한다. 생성된 구릅에 사용자 계정을 추가한다.
# groupadd mysql
# useradd -g mysql mysql
***********************************************************************************
많이 사용되므로 주의 할 것
* 특정 디렉토리에 하위 디렉토리까지 권한을 설정하는 방법 *
# chmod 755 -R /usr/local/mysql
# chown -R root /usr/local/mysql
# chgrp -R root /usr/local/mysql
*************************************************************
오라클 데이타베이스의 풀 백업
; 먼저 oracle로 로그인한다음에
형식은
# exp system/시스템계정암호 file=/절대경로/백업파일명.dmp compress=n log=/절대경로/로그파일명.log full=y
# exp system/manager file=BACK_FILE.dmp compress=n log=BACKUP_FILE.log full=y
보기를 들면
# exp system/manager file=/data_backup/data/2001_0306.dmp compress=n log=/data_backup/data/2001_0306.log full=y
# exp system/manager file=/data_backup/20020305.dmp compress=n log=/data_backup/20020305.log full=y
* 자바 사이트 목록 *
;자바에 대한 기본적인 내용 문서
http://rtislab.chungnam.ac.kr/~java/j_lecture/home.html
;자바에 관련된 게시판,커뮤니티가 활성화 되어 있는 곳
http://www.javaservice.net
http://www.javastudy.co.kr
http://www.javasoft.com
;Java Develope site
http://java.sun.com
;Java marketplace at Sun.
http://www.javaworld.com
**** 기호식별 ***
# : 슈퍼유저의 의미 쉘스크립트에서 주석문 의미도 있음
; : 쉘스크립트에서 주석문을 의미함
* 쉘 콘솔로 진입하는 방법
boot: linux init=/bin/sh
* 리눅스로 진입
boot : linux
* 도스로 멀티부팅 :
boot : dos
* 루트디렉토리를 읽기 쓰기 가능한 상태로 마운트하기
# mount -o remount / -rw
* FTP 서버의 사용
1. FTP 서버 사용금지자 목록 파일에서 사용하고자 하는 계정 삭제
# vi /etc/ftpusers
2. 호스트 접근 가능한 계정 목록 파일 편집
# vi /etc/hosts.allow
in.ftpd : localhost
형식 : 데몬 : 호스트네임
3. FTP 서버 실행
# /usr/sbin/ftprestart
4. FTP 서버 실행 중지
# /usr/sbin/ftpshut
* 압축파일 푸는 법 :
# tar zxvf mysql.tar.gz
* 디렉토리 이동 :
# mv dir1 dir2
* 아파치 시작하기
아파치 서버는 다음과 같이 실행합니다.
# /usr/local/apache/bin/apachectl start
아파치 서버의 실행을 종료하고 싶다면,
# /usr/local/apache/bin/apachectl stop
아파치 서버를 재시작 하고 싶다면,
# /usr/local/apache/bin/apachectl restart
와 같이 합니다.
* 부팅할 때 자동으로 서버 실행되게 설정하기
# vi /etc/rc.d/rc.local
위 파일을 편집하면 된다.
파일의 맨 마지막에 아래의 명령어를 추가하면 됩니다.
* 현제 데몬의 확인
# ps -aux | grep daemon_nanme
# ps aux | grep daemon_nanme
* 데몬의 재실행
kill -HUP 1
* 삼바의 데몬 실행
# /etc/rc.d/init.d/smb stop
# /etc/rc.d/init.d/smb start
# SAMBA NetBIOS services (for PC file and print sharing)
netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd
netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd
* 구룹 소유자 변경
# chgrp -R root /root/etc
* 소유자 변경
# chown -R root /root/etc
* 시스템 종료
# shutdown -h
* 프로세스 종료
먼저 프로세스 확인
# ps aux | grep process_name
위 명령결과 포로세스 아이디 확인
# kill -9 process_ID
* 파티션 목록 보기
# fdisk -l /dev/hda
* 특별한 플래그 세팅 루트권한으로도 수정이 불가능하고 읽기만 가능하다
chmod 명령보다 상위 명령이다.
# chattr +i /root/etc
해제 : chattr -i /root/etc
* 디스크 오류검사
# fsck -a
# e2fsck -a
* msdos 파일 시스템으로 플로피 드라이브 마운트하기
형식: mount -t 파일시스템종류 물리적인마운트장치명 논리적인마운트될디렉토리
# mount -t msdos /dev/fd0 /mnt/floppy
* 시디롬 드라이브 마운트
# mount -t iso9660 /dev/cdrom /mnt/cdrom
* 언마운트 하기전에 /mnt/cdrom에 접근하고 있는 프로세스를 모두 죽이라는 명령
# fuser -km /mnt/cdrom
**** 만약 리눅스 부팅 중에 sendmail daemon 뛰우는 중에 오래 동안 멈춰 있다면 ****
콘솔로 부팅하여 다음을 시행한다
부팅 중에 sendmail이 오래 동안 멈추는 이유는 파일 시스템 손상도 있겠지만
가장 많은 경우는 /etc/hosts 파일의 내용이 최초 리눅스 설치시와는 다르게 변경 되었을
경우에 많이 발생합니다.
# vi /etc/hosts
127.0.0.1 localhost.localdomain localhost
210.112.113.7 localhost.localdomain fly
만약 sendmail 데몬이 필요하지 않으면 부팅시에 서비스를 죽이는 방법은 다음과
같이 처리한다.
# setup
화면에 나오는 메뉴를 커서로 이동하여 system service를 선택한다
첨 부팅할 때 띄우는 데몬들인뎅 여기에서 sendmail daemon를 해제한다
*********************************************************************
데이터 베이스 생성 즉, 테이블이 존제하지 않는 빈 깡통 생성 방법은
데이터 종류에 따라 약간은 다르지만 주로 각 데이타 베이스의 서버 메니저를
통하여 생성하게 된다
또한 서버 클라이언트 환경에서 다이렉트 콘솔이 아닌 원격으로 데이터 베이스르
콘트롤 할 때는 각종 프로토콜을 이용하여 제어하게 되는 데
각각의 데이터 베이스에 대한 클라이언트 프로그램이 존제한다
클라이언트 프로그램은 데이타베이스 서버에 접근하기 위한 환경 드라이버들을
제공해 준다.
***************************************************************************
// 게임 소프트웨어의 개발 //
게임 소프트웨어를 개발한 경험은 없습니다. 게임에 대해서 논의 하는 것은
부담스런 일입니다. 게임에서 가장 중요한 것은 바로 제품 디자인 측면에서
시나리오란 것입니다. 기술은 어느 정도 수준에 이르면 어렵지 않게
축적되지만 창의적인 면이 강한 부분이 바로 시나리오입니다.
게임 상품으로 성공한 소프트웨어 모두 훌륭한 시나리오가 기본이 되었습니다.
게임이 유명해서 시나리오가 뛰어나다고 한 것이 아니라 시나리오가 소비자를
이끈 것입니다.
// 제품 디자인과 기술의 비중 //
무릇 한 기업의 경영자는 상품의 디자인에 80% 기술에 20% 비중을 둡니다.
상품의 포장을 아무리 강조해도 지나치지 않다는 말이다.
경영자의 속성은 특정 기술과 개발자의 기술에 종속되려 하지 않는다.
사업상 꼭 필요한 기술이거나 희소가치가 높은 기술이라도 제 값을 주고 기술을
구매하려 하지 않는다.
비용을 줄이려고 노력하는 것이다. 프로그램 개발이나 기타 사업에서 기술지상주의적인
발상은 매우 위험한 생각이다.
자기가 속한 개발 회사의 소프트웨어 개발 기술이 다른 개발 회사에서 꼭 필요한 경우가
있다. 경쟁 업체로서가 아니라 사양 분야인데도 다른 기업에선 필요한 경우를 말한다.
그러나 개발 기술이 융통성 있게 확산 되기란 어렵다.
// 오픈 소스에 대한 유솔로몬의 생각 //
소스 코드는 개발자가 땀과 정열, 귀한 시간을 사용하여 낸 땀의 결정체입니다.
따라서 개발자에게 소스를 공개하라 공개하지 마라는 무례한 요구는 삼가 하셔야 합니다.
공개 여부는 전적으로 개발자의 권한입니다.
소스 코드는 " 고기를 잡는 것이 아니라 고기를 잡는 방법" 즉, 노하우를 알려 주는 것으로
부가 가치가 매우 높은 것입니다.
오픈 소스 코드를 활용하여 제3의 진보된 코드를 생산 하거나 그대로 답습할 것입니다.
개발자의 소중한 재산입니다.
상업적인 다국적 기업에게는 오픈 소스 정책이 금전적으로 위협적인 것이 됩니다.
예를, 들면 어떤 응용프로그램이 다량으로 배포가 되었을 때, 그 응용 프로그램의
사용 기업이 특정 부분을 사용하고자 할 때, 많은 부분을 금전적으로 소스코드 소유 기업에
종속되어 버립니다. 그 기업 아니면 해법이 없다는 독점 상태 같은 것 말입니다.
그러나 오픈 소스가 활성화 되면 특정 문제에 대한 해법을 위해 기술적으로 금전적으로
종속되지 않아도 됩니다.
개발자는 당신의 호기심을 충족 시키기 위하여 소스를 오픈 해야할 어떠한 이유가 없습니다.
유수의 대학 내에 비직업적인 개발자가 소스 코드를 오픈 하는 이유는 기술 공유와
기술 유전과 발전을 위한 배려인 경우가 많습니다.
// 외국계 개발기업 그리고 개발자 //
외국계 개발회사에서 개발 업무를 하고 있는 개발자를 바라보고 무척 부러워하고
선망의 눈 빛을 바라보는 경우가 있습니다.
여러분도 그러한 분들 만나게 되면 근무 환경에 대해서 질문 드려 보면 조을 것
같습니다.
그런데, 의외로 그 분들이 마니 힘들어 하는 답변을 하게 됩니다.
첫째로, 모든 프로젝트가 타이트합니다.
이러한 이유로 항상 긴장하고 어떤 분들은 이것에 적응을 못해서 퇴사하는 경우가
많습니다.
둘째로, 모든 업무가 시간관리 중심으로 이루어 집니다.
첫 번째로 인하여 개인 시간으로 배정된 시간 외에는 업무 시간 중에는 업무를 위해 사용
되어야 합니다. 우리나라 처럼 참고 서적을 보며 코딩하는 것은 쉬운 일이 아닙니다.
자칫 자기 개발을 위한 공부로 인식되어 최고 경영자의 눈에 뛰이면 사직서를 내어야 합니다.
세째로, 철저하게 일정표 대로 진행 됩니다.
경험적인 것 그대로 인정되지 않습니다. 모든 성과는 수치로 환산되어 관리됩니다.
// 프로젝트 메니저(PM)가 하는 일 //
<=============================================================================인용부시작
"다양한 프로젝트 경험을 토대로 유능한 PM이 되기 위해서는
첫째, PM역할에 대해 제대로 이해한다.
프로젝트란 목표를 가지고 일정기간 내에 제품이나 서비스를 수행해야 하는 것이며,
한정된 예산과 비용으로 일정 수준의 인력을 어떻게 효율적으로 활용하는가의 문제다.
흔히 프로젝트 관리를 일정관리를 하는 정도로 이해하는 경우가 있는데
프로젝트 관리의 성공에는 많은 변수가 작용한다.
PM은 프로젝트에 대한 범위·일정·비용·품질·인력·위험·조달을 관리하고 책임진다.
둘째, PM이 되기 위해서는 실전에서의 단계적인 연습이 필요하다.
실제로 전문분야에서 개발경험이 없는 사람이 이론적인 경험을 통해 프로젝트를 진두지휘할 경우
실전경험이 없어 예상치 못한 많은 변수를 만났을 때 프로젝트 관리 및 수행을 성공적으로
이끌 수 없는 가장 큰 걸림돌로 작용할 수 있다. 유능한 PM이 되기 위해서는
프로젝트 실전경험을 토대로 단계적인 연습이 필요하다.
셋째, PM과 관련된 체계적인 훈련을 기본으로 공인된 자격증을 확보한다.
전세계적으로 PMI(Project Management Institute)에서 공인하는
PMP (Project Management Professional) 자격증에 도전해
제대로 PM이 되기 위한 길을 준비하는 것도 한 방법이다.
넷째, 비즈니스와 관련된 업무지식을 확보하기에 힘쓴다.
IT기술 관련 전문성과 함께 귀중한 자산으로 쌓이는 것이 바로 비즈니스 프로세스와
관련된 업무 지식이다.
IT관련 개발 인력들의 허점은 단순 프로그래밍에만 집착하면서
전반적인 업무지식의 보유를 게을리하는 데 있다.
부분적인 요구사항의 수렴보다 큰 줄기를 바라보고 업무의 흐름을 파악하는 것이 중요하다.
다섯째, 영어 실력을 꾸준히 연마한다.
IT관련 각종 프로젝트 혹은 컨설팅 프로젝트가 선진기술을 보유하고 있는
해외 유수 업체들과의 합작 프로젝트로 행해지고, 국내에 상주하고 있는 해외 IT업체의 경우도
실제로 솔루션·서비스를 수행하기 위해 영어로 의사소통이 가능한 PM을 확보하려 하고 있다.
실제로 각종 협력 및 제휴관계로 외국 엔지니어 및 PM과 의사소통을 할 수 있는 기회는 많이 있다.
여섯째, 원활한 의사소통 능력 및 리더십을 갖추도록 한다.
프로젝트의 영역관리 중 한 부류로 간과할 수 없는 것이 바로 '프로젝트 의사소통 관리'다.
프로젝트와 관련된 내부 인력팀 혹은 시스템을 사용할 엔드 유저(end user)와의 긴밀한 의사소통,
나아가서는 외주업체의 IT 전문인력과의 원활한 의사소통을 통한 프로젝트의 진척성 파악,
정보공유 등을 통한 프로젝트의 의사소통 관리는 성공적인 프로젝트의 완결을 위한
성공 요소임을 인지해야 한다. "
<================================================================================================인용부 끝.
<==========================================================================전자신문 게재일자 : 2002/01/16
// 현제 폼에서 다른 폼 열기 //
방법은 여러가지가 있지만 특이한 코드라 여기에 적습니다.
먼저 uses 절에 참조 할 유닛을 첨가하고
procedure TForm1.Button1Click(Sender: TObject);
begin
with TForm2.Create( nil ) do Show;
end;
// 폼위 라벨의 이메일을 클릭했을 때 아웃룩익스프로세스의 실행 //
ShellExecute( 0, nil, PChar( 'mailto:' + TLabel( Sender ).Caption ), nil, nil, SW_SHOW );
*****************************************************************************삭제부시작
// HOOKING 기법 //
아무래도 후킹은 민성기님 여덕수님, 양병규님이 뛰어나게 구현하신 것 같다.
후킹을 사용 할 때에는 세심한 주의가 필요합니다.
윈도우 운영체제에서 메시지는 운영체제의 근간을 이룹니다.
정확이 알지 않고 임의로대로 메시지를 후킹하면 운영체제가 먹통이 되거나
올바른 동작을 하지 않을 수 있습니다.
개발자가 후킹을 제대로 구현하지 못한다 하더라도 결코 실력이 있거나 없거나
판단 기준으로 고려하지 않도록 프로젝트 메니저는 주의해야 합니다.
후킹에서 고려의 대상은 윈도우 운영체제에서 후킹 기법을 사용하는 응용프로그램이
2개 이상 실행 중일 때, 심각한 문제를 일으킬 수 있습니다.
후킹은 제한적으로 꼭 필요할 경우만 사용하도록 합니다.
복사 방지잠금 장치를 위해 사용자 정의에 메시지 후킹은 권장해드립니다.
다른 한편으로, 다른 여러가지 방법으로 각종 콘트롤 사이에 전역적으로 자료를
교환하고자 할 때는 사용자 정의의 윈도우 메시지와 메모리 맵을 사용하여
데이타를 교환하도록 합니다.
후킹에 대한 사용자 정의 함수는 최소화하여 꼭 필요한 함수만 DLL안에 포함시키고
다른 함수들은 별도 공통 유닛에 만들어 두고 uses 절에 포함 시켜 사용하시기
바랍니다.
사실, 전역적으로 데이터 자료 교환과 특정 메시지 없이는 응용프로그램이 실행되지
않도록 하고자 할때만 사용하도록 합니다.
후킹에 대해서는 구현 방법에 대해서 차후 기술 할 예정입니다.
많은 개발자분들은 후킹을 크랙이나 해킹에 사용된다고 부정적인 시각을 갖고 있습니다.
그러나 이용하기에 따라서 유용하게 사용됩니다.
물론 프로그램머 채널에 이용되기는 하지만...^^
제3자가 보기에 HOOK.DLL으로 이름을 설정하면 어플에서 후킹을 사용하는게 인지된다.
가능하다면 DLL 파일의 전혀 다른 이름을 사용하는게 좋습니다.
물론 메시지 스파이를 이용하면 금방 알아내겠지만...
*******************************************************************************삭제부 끝...
// DLL 파일의 처리 //
대부분 프리랜서들은 소스코드를 넘겨주는 계약을 할 때에 핵심적인
사용자 정의 함수를 *.DLL로 묶어서 배포합니다.
물론 이 DLL 파일은 디자인 타임이나 런 타임시에서도 공통적으로 사용됩니다.
그러나 디자인시에 DLL를 사용 할 때마다 임포트를 해주는 선언 할 때마다
귀찮은 작업이 반복된다.
이럴때는 별도로 DLL를 사용하는 유닛을 만들고 그 유닛의 *.dcu 파일을 다시
use문에 기술하면 됩니다.
// 입력 받은 문자열이 숫자인지 문자인지 판별하는 사용자 정의 함수
Function MySearch(S:String):Boolean;
var
find : Boolean;
i : Integer;
begin
find := True; // 판별자 초기화
// 입력 받은 문자열의 길이가 0 이상이면
if Length(S) > 0 then begin
// 글자열의 첫자 부터 문자열 길이까징 반복
for i := 1 to Length(S) do begin
// 입력 받은 문자열이 0에서 9가 아니면 판별자에 False를 설정
if not(S[i] in ['0'..'9']) then find := False;
end;
end else begin
find := False;
end;
Result := find;
end;
// 함수의 사용
var
Result:Boolean;
begin
Result := MySearch('123');