이쪽에 있다보면 자주들리는 용어들(철저하게 주관적인ㅋㅋ 느낌으로 썼음. 까먹지 말라고 남기는거라 순서도 없음. 귀에 들리는 대로 올릴 예정)
여기서 주로 쓰는 시스템들은 대부분 c기반이라 다른데 돌아다니다가 자바기반 프레임워크관련된 용어들은 나도 생소함.(얼른 배워둬야 할텐데..)


SI(System Integration)
- 시스템 통합. 대형기관에서 사용하는 업무들을 전산적으로 통합하는 작업. 흔하게는 엔터프라이즈 시스템이라고 부르고. 공공기관, 대기업, 금융권 등의 업무들을 전산화 또는 기존의 시스템들을 통합하여 이전보다 나은 업무프로세스 및 성능개선을 통해 공공 또는 기업의 이익을 추구하는 작업.
이라고 말하고 노가다라고 부르면 적당함.

SM(System Maintenance)
- 보통 SI프로젝트가 끝나면 그 시스템에 대한 유지보수를 말함. 어디서는 Maintenance가 아니라 Management라고 부르는 쪽도 있음.

BP(Business Process) 서버?
- 몇번 듣다보니 뭐하는 건지는 알았는데 뭔 약자인지 한참 찾은 용어. 접속서버(중계서버)라는 말로도 사용하고 보통 클라이언트가 엔터프라이즈시스템에 직접 연결되는 것이 아니라 중간에 중계서버를 둔다.
실제 클라이언트와의 커넥션을 담당하며 보안적인 측면에서 망을 분리하는 효과 뿐만 아니라 L4장비와 함께 로드밸런싱을 담당하기도 함.



CDC(Change Data Capture)
- 말 그대로 변경된 데이터에 대한 이미지를 생성. 어떤 데이터가 어떻게 변경되었다라는 history를 가질 뿐만 아니라 백업용도로 미러링기능을 가지고 있음.
대부분의 솔루션들이 DB의 아카이브모드를 사용하는 듯.



BCV(Business Continuance Volume)
보통 백업용도로 사용하며 디스크의 볼륨단위를 그대로 미러링한 카피본이라고 보면 된다.
데이터나 시스템의 특성에 따라 사용방법이 조금씩은 다를 수 있다. 순간처리건이 많은 경우는 단순히 백업용도로 사용할 수 도 있고. 시스템 장애시 백업받은 디스크 볼륨을 그대로 복구처리해 장애에 대처하는 경우도 있다.
일반적으로 백업을 위해서 따로 작업을 해두는게 아니라 항상 마스터 볼륨과 Sync를 맞추고 있다가 백업순간 Sync를 끊는다.

On Demand Batch
- 배치작업을 스케쥴링에 의해 실행하는 것이 아니라 사용자가 요청시에만 동작하는 배치작업.
사용자의 요건에 따라 발생된 대량처리건을 처리하기 위해 사용.

CenterCut
- On Demand Batch 와 마찬가지로 사용자에 요건에 따라 발생된 대량처리건을 처리하는 아키텍쳐
On Demand Batch와 다른 점은 배치프로그램이 동작하는 것이 아니라 각 처리건을 온라인서비스로 처리하는 것이 차이점이다.
배치를 추가로 만들지 않고 기존의 서비스로 처리하는 것과 부하에 대한 유량제어로 시스템이 부하를 받지 않도록 처리가 가능한 장점이지만 센터컷 자체 아키텍쳐 구축이 쉽지 않다. 센터컷 아키텍쳐는 유량제어, 각 처리건에 대한 결과 및 에러시 복구 및 장애 대책을 가지고 있어야 한다.
대량의 데이터를 개별서비스단위로 쪼개는 작업도 만만치 않다.
* OnDemandBatch하고 CenterCut 기술들이 자바프레임워크를 쓰는 동네에서는 어떻게 보이는지 잘 모르겠다.

DryRun
- 시운전, 리허설 정도로 해석하면 될 듯.

RFI(Request For Information)
- 보통 정보요청서로 부르며 아래 나오는 RFP 전에 작성된다. 프로젝트를 진행하려는 측에서 내부적인 기준으로 선정한 업체들에게 우리 이러이러한 프로젝트를 하려고 하는데 정보 좀 보내달라. 뭐 이런 용도의 문서다. 프로젝트를 진행하려는 측에서는 프로젝트에 적용될 기술이나 업계동향, 프로젝트의 진행방식 등 시스템 구축에 필요한 컨설팅단계를 진행한다. 주로 컨설팅 업체는 RFI 작성시작부터 참여하게 되며, RFI를 받은 업체들도 이때부터 프로젝트 수주에 대한 본격적인 작업에 돌입한다.

RFP(Request For Proposal)
- 프로젝트를 진행하려는 측에서 내부적인 기준으로 선정한 업체에 RFI를 보내면 각 업체들은 해당 프로젝트 성격에 맞게 우리는 이러이러하게 프로젝트를 진행하겠다고 자신들의 솔루션과 노하우, 이전 프로젝트 사례등을 담은 RFP를 작성해 제출한다. RFP를 받은 갑은 자 이제 어디까지가 구라고 누가 싸고 어떤게 좋을지 이리 저리 재보고 프로젝트를 수행할 업체를 정한다.

Turn-Key
- 본래는 공장기기설비쪽에서 나온 용어로 알고 있음. 개발완료와 동시에 즉시 가동가능한 상태로  인계할 수 있도록 하나의 주사업자가 모든 공정을 책임지고 처리하는 방식.

In House 방식
어떤 프로젝트에 대해서 개발을 외주인력이 아닌 내부인력으로만 처리하게 되면 In House라 함.

M/M(Man/Month)
- 프로젝트의 일정을 산정할 때 자주 사용되는 단위. 한사람이 한달간 일할 분량.
이런 계산법이 만능은 아니지만 일정의 공수산정을 위해 이거만큼 수치적으로 간단한 단위는 아직 못봤음.
그래서 아직도 자주 사용됨.
10M/M(1Man * 10Month) = 10M/M(10Man * 1Month)... 수치적으로는 같을진 몰라도 실제로 이런 경우는 없음.



SSO(Single Sign On)
- 한번의 로그인으로 여러 시스템을 이용할 수 있게 해주는 솔루션. 웹기반으로는 세션키를 공유하는 방식으로 일반 서버/클라이언트 모듈에서는 agent를 사용한다. 대기업이나 금융권같은 곳은 사용하는 시스템이 기존의 레거시까지 포함하는 경우 SSO를 통해 한번의 로그인으로 사용자를 인증하고 해당 사용자에게 시스템을 이용가능하게 서비스를 제공한다.


EAM(Extrnet Access Management)
- 어디서는 Enterprise Access Management 라고 부르는 곳도 있고 Extranet Access Management라고 부르는 곳도 있다.
통합인증, 권한관리 시스템으로 SSO시스템에 권한관리, 자원관리 등이 포함된 개념으로 이해하면 될 듯.

IAM(Identify Access Management)
- EAM이 개별사용자에게 권한부여 하는 방식이 자동화되어 있지 못한 반면 IAM은 이를 자동화 처리가능하게 한 시스템이라 줏어들었음. 포괄적인 개념으로 SSO < EAM < IAM 정도로 생각하면 될듯.(넘 날로 먹나?)



EAI(Enterprise Application Integration)
- 통신프로토콜이나 테이터 타입, OS등 각기 다른 환경에서 동작하는 애플리케이션들에 대해 상호 연동할 수 있는 기능을 제공하는 솔루션. 파일, 온라인서비스, DB등 각기 다른 데이터를 주기적 혹은 준실시간(Defered Onlinle)으로 처리함.
이런 EAI를 사용하는 이유는 각 시스템별로 비지니스적으로 다른 처리를 하고 있지만 각 시스템간에 공통된 영역을 효율적으로 연동하기 위해서 사용함.

MCI(Multi Channel Integration)/MCA(Multi Channel Architecture)
- 채널통합. 기업이나 기관에서 다양한 채널과 통신하는 경우가 많은데 각 채널마다 통신방식이나 전문들이 상이한 경우가 많다. 코어시스템입장에서는 이를 동일한 규격으로 통일할 필요가 있으며 이러한 기능을 제공하는 것이 MCI혹은 MCA 솔루션이다.
있다보면 간혹 EAI와도 중복되는 개념으로 사용되기도 한다.

FEP(Front-End Processor)
- 원래는 메인프레임의 통신제어를 위한 전용 시스템을 말하는데 현재는 굳이 메인프레임에 국한하고 있지 않은듯 하다. 개인적인 판단으로는 OSI7 Layer에서 세션이나 프리젠테이션 계층까지 담당하는 것으로 보인다.
보통 기관 대 기관 연결이 FEP로 연결되어 있는 경우가 많다.

ESB(Enterprise Service Bus)
- 통합된 서비스구조를 통해 효율적인 시스템 구축 및 유지보수가 용이한 구조라고 하는데 아직까지 뭐가 ESB다 라고 명확하게 나온걸 본적이 없다.
SOA의 핵심사상중에 하나인데 SOA라는 것 자체도 추상적이고 개념적인 내용들이 더 많은게 아직까지의 현실인듯 하다.
말이야 이렇게 하면 뭐에 좋고 이게 좋고 다 말은 하지만 실제 시스템에서 이런걸 구축하려 하면 배보다 배꼽이 더 커지는 경우도 있다.

SCM(Software Configuration Management)
- 형상관리. 개발을 하다 보면 수백 수천 수만개의 소스와 관련 리소스를 관리하게 된다. 이런 리소스들의 날짜별 시간별 히스토리 및 이전 버전과의 비교, 브랜치 관리, 머징 등을 위한 관리시스템을 형상관리시스템이라고 부른다. CVS, SVN, GIT, Mercurial 같은 툴들이 있으며 엔터프라이즈환경에 맞춘 커스텀 솔루션들도 있다. 오픈소스에서 요즘 GIT가 대세인듯..

SOA(Service Oriented Architecture)
- 서비스지향아키텍쳐. 간단하게 말하면 각 단위작업이 서비스로 이루어진 구조를 말한다. 핵심적인 개념은 각 단위작업이 타 서비스에 영향을 미치지 않고 독립적으로 실행된다는 점과 이런 구조로 인해 서비스의 재사용성이 높다는 것인데. 개인적으로는 SOA라고 해서 다 저런 특징을 가지는 것도 아니고 굳이 SOA가 아니더라도 저런 특징을 가질수 있게 만들 수 있다. 결국은 설계단계에서 개발단계에서 이러이러한 구조로 개발을 해야 효율적이겠다 라고 설계하는 것과 크게 다르지 않은 느낌이 든다.

BPM(Business Process Management)
- 비지니스 프로세스를 개선하기 위한 작업을 뜻한다. 개념적으로 보면 그룹웨어가 BPM의 하위개념? subset 정도 될듯 하다. 보통 기업 또는 기관들이 정해진 업무만 처리하는 것이 대부분이지만 신규시장, 신규사업 등 새로운 업무활동을 위해 새로운 프로세스를 수립하게 되는데 이런 일에 사용되는 것이 BPM이다.

MOM(Message Oriented Middleware)
- 메시지 기반 미들웨어. 메시지를 기반으로 비동기식으로 통신하는 미들웨어이다. 기존의 미들웨어는 클라이언트나 타 시스템과 직접연결되어 데이터를 주고 받은 반면 메시지기반 미들웨어는 내부적인 Message Pool 과 같은 개념의 공간을 두고 통신을 한다. 이러한 개념은 커넥션이 끊기면 통신자체가 중단되는 기존 동기방식의 미들웨어와는 달리 한쪽의 통신이 끊기는 것에 크게 영향을 받지 않는다. 개념상 어떻게 처리하느냐보단 뭘 보내느냐가 초점이 맞춰져있는듯 하다. 솔루션으로는 IBM MQ시리즈, BEA Message Q, J2EE의 JMS 등이 있으며 최근들어 비중이 조금씩 높아지는 추세이다.


EDW(Enterprise Data Warehouse)
- warehouse 란 단어가 창고라는 의미를 가진 것과 같이 EDW 는 데이터의 창고라 할 수 있다. 단순하게 자료를 담는 DB의 레벨을 넘어 유효성있는 정보로 가공하기 위한 또는 가공된 정보가 저장된 공간 및 처리하기 위한 기반 시스템을 말한다.
흔히 원장이라고 불리는 애들은 OLTP성으로 실시간으로 데이터가 저장이 되며 EDW에서는 이렇게 실시간으로 쌓인 정보들을 분석, 가공하여 이를 이용자에게 제공한다.

CCF(Computer to Computer Facility)
- 말 그대로하면 컴퓨터간의 시설? 설비? 정도로 해석할 수 있는데 간단히 말하면 프로토콜의 한 종류? 아니면 특정업무를 위한 전문집합(message set)로 보면 된다. CCF라는 용어를 쓰는데는 우리나라에서는 예탁결제원, 구글을 뒤져봐도 미국의 예탁기관인 DTC. 이 정도 기관에서만 사용하는 듯 하다.(더 찾아보면 나오겠지만)


ETL(extract, transform, load)
ODS(Operational Data Store)
OLTP OLSP

업무 아키텍처(BA)
데이터 아키텍처(DA)
응용 아키텍처(AA)
기술 아키텍처(TA)
보안 아키텍처(SA)
SRDF(Symmetrix Remote Data Facility)

WBS

BRD : Business Requirement Definition (Document)
  요건정의서. 현업이 작성하고 SI 업체에 넘겨준다.

FS : Funtional Specifications
  기능설계서. 개발에 관련한 각종 문서. DB설계서등을 포함하기도 하며, 개발 완료시점의 예상 화면덤프등을 포함하기도 한다.

SIT : System Interstration Test
  코딩 및 테스트를 포함한 개발 과정을 포함한다.

UAT : User Acceptance Test
  실제 오픈 전 테스트.

MQC : Mecury Quaility Center ( = T/D : Test Direction )
  테스트툴 또는 전체 page 오류구간 정리 검사 (툴을 이용하기도 함) 등을 통해서 최종 품질 검사 작업. (PMO조직의) 비니지스 담당자들이 작업한다.

간추린 요약..

1. 요건 발생
2. 데이터 모델링의 교과서적으로 테이블을 설계 하고 개발함.(테이블 대략 30개)
3. 범용성까지 고려해서 입력되는 항목을 별도의 테이블로 관리.
4. 잘 쓰고 있었음..
5. 갑자기 보고서를 만들어 달라는 요구사항이 나옴.
6. 보고서를 만들라고 보니 저 범용성이라는 놈이 제대로 발목잡음..

입력되는 항목들에 대해 범용성을 추구하다 보니 유형별로 입력건수가 모두 다르다.
그런데 실제로 유형별로 80%는 가지고 있는 공통적인 필드가 있었다.
이걸 보고서로 보여달라고 하는건데.. 저 데이터가 사방에 흩어져 있으니 꺼내다가
한줄로 보여주기가 여간 난해한게 아니다.
보고서로 1줄 보여주기 위해 서브쿼리가 3중 4중으로 들어가고 온갖 중첩된 뷰테이블에다가..
like 검색조건으로 빠지는 케이스 일일이 손으로 찾아봐야하는 상태..

그냥 정규화 무시하고 마스터내역테이블에 주로쓰는 있는 컬럼 없는 컬럼 다 달아놓고 쓸라면 쓰고 말라면 말아라 해놨으면 select 쿼리 한줄이면 끝날 것을..

이 업무에서 사용하는 테이블만 약 30개..
결국 이론적인 모델링 방법이 답은 아니라는 걸 새삼느꼈다.

닭하나 잡는데 소잡는 칼썼다가 닭도 제대로 못잡고 있다.

병풍
- 국어사전 정의
[명사]
 바람을 막거나 무엇을 가리거나 또는 장식용으로 방 안에 치는 물건.
[북한어]
음흉한 목적을 가리기 위하여 쓰는 수단을 비유적으로 이르는 말.

- 오픈사전 정의
[명사]
 별 존재감 없는 사람을 가리키는 신조어.

- 이 동네 정의
[동사] 병풍치다.
 사고를 친 사람에게 여러 사람이 뒤에 달라 붙어 있는 "뭐가 문제야"를 반복하는 상태.


사고 한번 쳐보면 안다. 뒤에 병풍친 느낌이 어떤 느낌인지.
두 번 다시 겪어보고 싶지 않은 경험이다.

뭘 더 써야 할까 썼다 지웠다 반복하다. 남길 말은 이거 밖에 없다.

"좀 더 신중히 행동하자."

천성이 게을러먹어 그런건지 일을 쌓아놓는 스타일이다.
일이 생기면..(급한게 아니면) 일단 쌓아놓고 논다..(뭐 마냥 놀기만하는건 아니고 소스도 좀 훑어보고 디비도 끄적거리고 서버들어가서 뒤적뒤적 그렇게 시간 때운다.)
그러다가 어느날 갑자기 일이나 해볼까 하고 시작하면 미친듯이 일만 한다. 집중될 때만 일한다.
맨날 이렇게 집중해서 일할 수 있다면 얼마나 좋겠냐먀는 그렇지 않은게 현실(이렇게 말하지만 현실은 핑계)

그닥 좋은 습관은 아닌데 그래도 여태까지 크게 일을 빵구낸적은 없으니 그거하나 맘에 위로를 삼는다.
이렇게 일하게 된 원인을 가만 보니 내가 했던 일들이 대부분 다른 영역과 관계없이 독립적으로 동작하는 모듈개발이 대부분이었다.
두번째로는.. 아직은 말단인 나에게 order를 내려주는 사람은 있으나.. 체크하는 사람이 없다. 일단 order가 떨어지면 일단 나는 검토해보겠습니다. 하고 자리에 앉는다.. 그리고는 한 반나절 이면지에 그림 그려가면서 어느정도 일정이 나올지 계산해보고 보고한다. 대부분은 그대로 가는데 그 중간에 날 터치하는 사람이 없다.
좋게 보면 믿어주는거고, 나쁘게 보면 날 버려두는거다.

이야기가 딴데로 샜다.

일을 쌓아놓는 버릇에 대한 변명아닌 변명을 하자면 개발이건 어떤 일이던간에 그 일을 처리하는데 절대적으로 필요한 시간이 있다. 막상 일시작하고 열혈모드로 키보드를 두드리는 시간이 10시간이라고 하면 실제로 그일은 최소 50시간의 시간이 필요한 일이다.
그럼 나머지 40시간은 어디갔냐.. 일단 시작할때 그림그려가며 개념잡고 레거시가 있으면 소스도 좀 보고.. 디비 레이아웃도 보고 하는데 몇시간 잡아먹고 설계하는데도 시간이 절반정도 그럼 나머지 20시간은 ???

숙성..
일을 시작하고 파악하고 분석해서 설계하고 그대로 바로 개발에 들어가면 경험상 항상 탈이 났다. 원인은 설계시에 빼먹은 부분들이 꼭 있었다. 그런데 설계와 개발 사이에 텀이 좀 있으면 이런일이 좀 줄어든다.
이걸 난 정보의 숙성이라 부른다. (거창하지 않은가)

일을 쌓아놓는건 결국 저런 숙성과정인거다. 이런 생각을 확고하게 된 계기는 마크 헌트의 실용주의 사고와 학습 이란 책을 보면서였다. 인간의 뇌는 정보를 처리모드가 직관적이고 비선형적인 모드와 계산적이고 선형적인 모드로 나뉜다.(흔하게는 좌뇌/우뇌 이렇게 부르기도 함)
어쨌건 이런 기간동안에 '아!' 하고 뭔가 떠오를 때가 있다. 이게 숙성에 핵심이다.

그런데 하나 중요한건 숙성기간에 그냥 놀아재끼면 다 까먹는다. 그럼 그건 숙성이 아니라 망각이 되버린다. 가끔씩 안까먹게 refresh 해줘야 된다.

그럼 refresh는 어떻게 하는가?
1. 가끔 심심하면.. 이면지에 첨 끄적거렸던거 다시 한번 본다.
2. to-do list를 작성한다.. 그리고 다시 접어둔다.
3. 상상한다. (뭐든 좋다 그 일에 대한 어떠한 상상도 좋다.)

이런 방식으로 처리할 만한 일거리에 분량은 경험상 짧게는 3~4일에서 길게는 2~3주 정도 걸리는 일들에 적당하다. 하루 이틀 걸리는 일들을 이렇게 해버리면.. 욕 좀 먹겠지??
일이란게 한번에 하나만 처리하는게 아니니 버닝모드로 들어가는 스케쥴만 잘 맞추면 이 방법이 나한테 잘 맞는것 같다.

ps. 일하는게 먹는것도 아니고 숙성에다 비유를... 거참 일안하고 노는 핑계 한번 거창하다.ㅋㅋㅋㅋ
     그러면서 지금도 놀고 있다.(근데 주말에 출근해서 뭐하는거냐..)

내가 겪은 프로젝트.. 또 내가 가까이 볼 수 있었던 다른 프로젝트 중에 최초 예상했던 오픈일에 오픈한 프로젝트를 한번도 본적이 없다.

짧게는 2~3주. 길게는 1년, 한두달 정도 오픈이 연기되는건 성공한 축에 속한다.
원래 IT프로젝트의 속성이라고 하기에는 뭔가 문제가 있지 않나 싶다.
답을 알면.. 남들은 바보도 아니고 왜 그렇게 안했을까..
서점에만 가도 프로젝트 관리에 대한 수많은 책들이 보인다. 최근에는 그런 서적의 종류가 배로 늘어난 느낌이다.
번역서의 종류도 많이 늘어난 느낌이 든다.
뭐 그책들을 다 보지는 못했지만 대채적으로 프로젝트 실패 혹은 연기의 주요 원인으로

1. 초기의 분석/설계의 미흡으로 인해 개발/테스트 단계에 문제가 생기는 경우
2. 각 개별 파트간의 커뮤니케이션 부재
3. 관리자의 관리능력 부재
4. 설계/개발자의 시스탬의 이해 부족

뭐 대충 이런 이야기들을 한다.

아닌걸 알면서 왜 그렇게 갈까?
내 경험을 비추어보면 내쪽일이 복잡해진 경우는 분석/설계단계에서.. 요구사항이 다 안나왔다.
그게 다인줄 알았는데 개발하다 보니 조금 꼬인 케이스도 있었다. 뭐 이건 큰 구조변경이 없어서 다행이었지만
요구사항이 추가되는데... 기존의 설계를 우회하거나 뒤엎어야 하는 케이스도 있었다.
이런걸 미리 알고 설계에 반영할 수는 없나?
개발 모델이 폭포수라 그런거다 라고 이야기 할 수도 있겠지만..  내생각에는 그보다는 근본적인 문제가 있다.

어떠한 개발모델이던 프로젝트에 적용이 되려면 그 개발모델이 이상적인 모델의 장점을 프로젝트에 최대한 적용할 수 있는 방안과 해당 모델의 문제점을 파악해서 보충할 방법을 찾아놔야 한다.
개발모델만 가지고 프로젝트가 진행되는 것은 아니지만.. 그런 모델들에서 진행상에 발생할 난제들을 예측하는 것도 능력이다.

그런데 경험상 이런 개발모델이나 방법론이 프로젝트의 성공여부에 미치는 영향은 그닥 많지 않다.
원래 그런 모델이나 방법론 자체가 말만가지고 노는(?? 오해의 소지가 있을 수 있다..) 동네다 보니 누가 봐도 그럴싸 해보인다. 그리고 요즘나오는 프로젝트에서 이야기하는 방법론들은 상식적으로 뭔가에 크게 벗어나는 게 별로 안보인다.(개인적인 생각일런지 모른다.)

제일 문제는 프로젝트를 진행하고 있는 사람들의 시스템 혹은 결과, 목표에 대한 이해가 조금씩 다르다.
고객은 자신이 원하는 것을 뒤늣게 빼먹고 이야기 하는 경우 개발자 입장에선.. 저런...~~~~~ 이래버리고
역으로 고객은 당연히 되는거 아냐? 왜안되는데? 이런식으로 나오면.. 백이면 백 프로젝트 망한다.

적어도 이런 프로젝트를 하는 사람들이라면.. 개발자건 고객이건 컨설팅을 하는 사람이건 모두가 그 프로젝트가 원하는 큰 그림은 알고 있어야 한다고 생각한다.
결국 프로젝트의 구성원 모두 같은 모양의 결과물을 바라보고 있어야 한다.
그리고 그 단계가 프로젝트의 시작단계, 즉 요건분석/설계단계에는 완료되어야 한다.
이거 자체가 쉬운일이 아니다. 어쩌면 불가능한 일일지도 모른다. 지금까지 인류의 역사자체가 저랬던 적이 흔치 않기에 오히려 당연하게 보일런지도 모르겠다.
프로젝트를 리딩하는 사람들에게 가장 중요한 목적이 아마도 이게 아닌가 싶다.

IT라는 것 자체가 원래 IT자체를 위해 발생한 기술이 아니다. IT이외의 현실세계에서 필요한 작업들을 처리하기 위해 발생한 기술이다. 그 목적이 군사적이건, 경제적이건 어떠한 목적이건간에.
소프트웨어라는 말을 쓴지도 대략 50~60년은 되었지만 다른 분야에 비하면 그 역사가 턱없이 짧지 않나 생각한다. 무슨 책에서 아직 소프트웨어 공학은 공학이라고 불릴만큼 성숙한 분야가 아니라고 했다. 미국 어디주에서는 IT쪽에 기술자.. 그러니까 엔지니어라는 공식적인 직함?을 부여하는데 부정적인지 불법이라고 했는지 그런 이야기를 본적이 있다.

어쨌건 IT관련 프로젝트는 아직도 활발히(?)진행 중이며 원래의 공정기간을 맞추지는 못했더라도 테스트 후 큰 문제가 없으면 그 시스템은 오픈하기 마련이고 우리는 그 시스템들을 잘(???) 어쨌건 이용하고 있다.

주저리 말이 많아졌는데.. 결론은 과정에 문제가 있어 지연되었지만 결과적으로 쓰고 있는 시스템이다.. 그러니 그 과정을 줄일 여지가 남아있다.
그 여지 중 하나가 프로젝트 구성원들이 프로젝트 초기에 같은 목표.. 같은 그림을 바라보고 있어야 한다. 끝..(다 아는 얘기만 한듯..)

짬이 안되다 보면 어떤 의사결정을 내릴때 힘을 내지 못하는 경우가 생긴다.
뭐 결국은 능력의 부족인데 저건 아닌데 하면서 결국엔 그 결정을 따르는 일이 있다.
그러다보면 나중에 문제가 생기는 경우가 있는데
이런 원인은 그 문제에 대한 시선의 차이로부터 시작된다.
그럼 무엇이 그런 시선의 차이를 만들까?

개인의 경험?
맡은 업무의 needs?
자신에게 떨어질 일의 양?
전문가적인 직관?
만인이 공감할 상식?
기존의 틀을 깨는 획기적인 해결법?
기타 등등..

이중에 항상 어떤 것이 정답일 수는 없다. 그 상황에 맞는 케이스가 존재할 뿐이다.
그럼 사람들이 항상 상황에 맞는 케이스를 찾는가? 라는 질문에는 누구도 그렇다 라고 대답하지 못할 것이다.

가장 비관적으로 봤을때 자신에게 할당될 일의 양을 고려한 시선으로 문제를 바라본다 하더라도 그게 꼭 오답이 아닐 수도 있다.

또 상식적인 수준에서의 문제 해결방법이 오히려 독이 될 수도 있다.

좀 극단적인 케이스이기는 하지만 그것들이 항상 100%정답이 아닐 수 있다라는 것이다.

이 동네에 있다보니 별별일을 다 겪게 되는데 시간이 지나보니 그때 한사람이 주장하던 의견이 결국엔 맞는 경우가 있었다. 그 사람 이외 관련자 전부가 반대했었고 결국 그 의견은 당시에 받아드려지지 않고 다른 방향으로 처리되었다. 결국엔 그 방식이 문제가 생겨서 그 사람의 의견대로 다 뜯어 고치는 웃지못할 사태가 벌어졌다.

그 사람은 어떻게 되었을까? 그 건 때문은 아니지만 상황이 좋지 않아 사태가 벌어지기전에 다른 직장으로 이직해버려 그 뒤 사정을 모른다.

그럼 그때 그 의견에 반대했던 사람들은 바보였던건가? 나름 IT 짬밥 10여년 이상 경력자들이고 프로젝트도 수십번 이상 했던 양반들과 고객사 직원도 업무경력 20년이 다되가는 고참들이었다.

소프트웨어 공학에서 말하는 리스크라고 하는건 아마도 이런 것들을 리스크라고 하는 듯 하다. (물론 일정 및 범위, 기간, 공수 산정의 리스크도 있지만..)

그럼 원점으로 돌아가서 처음에 의견을 제시한 그 사람이 이런 사태가 벌어지지 않게 하려면 어떻게 해야하나?
자신의 의견이 맞다고 증명을 해야 하는데 그 의견이라는 것 자체가 위에서 언급한 문제에 대한 시선의 원인(?) 중 하나라는 것이다. 이런식으로 간다면 결국엔 그 의견도 정답인지 아닌지는 모른다는 것이다.

좀 괘변이긴 하지만 결국 닭이 먼저냐 달걀이 먼저냐 같은 문제이기도 하다.

가장 중요한 것은 이런 물고 물리는 악순환의 고리를 끊어내야만 한다. 결국은 뻔한 이야기다..

결론은.. 지지말자. 지지 않도록 무장(?)하자. 자신의 의견을 철저하게 객관적으로 검증부터 하자. 그리고 나서 우겨라...(ㅋㅋㅋ) 그럼 니가 생각하는게 맞다.

ps. 혹시나 이거 보고..(볼 사람도 없지만) 그러는 당신은 얼마나 잘났소? 라고 물어보시면 전 할말 없습니다..... 아직 하산하려면 멀었습니다.

언젠가 화면개발메인을 맡은 적이 있었다.
써본(신입교육 이틀) 사람이 나밖에 없다는 이유로
일반 화면개발하는 사람들 서포트 및 안되는게 있으면 코딩으로 뚫어주고
메인화면 만들어 연결하고 메뉴구성하고 서비스 헤더, 메시지 연동, 공통 컴포넌트
같은 일을 한 두어달 했었다.

다 재미는 있었는데 게중에 제일 귀찮았던 일이 메뉴구성이었는데
레거시들을 보니 다 고정depth에 파일로 구성되있었다.
max depth는 4, 매뉴 갯수는 약 4000개

순서 바꿔달라. 메뉴구성 다시 해야된다. 뭐 잘못됐다. 뭐 없어졌다..
짜증이 솟구쳐서 메뉴구성 시스템을 만들기 시작했다.
근데 짜려고보니 욕심만 많아져서 그런지
depth 제한도 없고 orderring에 alias(동일한 메뉴가 필요에 따라 2~3군데 이상보이게)
기능까지 추가하려다 보니.. db로 해야되나 xml로 해야하나 고민만 하다가
하루이틀이면 될 줄 알았는데 생각보다 일이 커졌다
결국엔 일정에 쫒겨 반도 채 못만들고 사이트에 파견나와버렸다.(다 핑계다. 결국엔 귀찮았던 게야)

근데 여기도 업무화면개발을 하고 있는데.. 메뉴구성이 역시나 파일이다.
뭐 좀 있을 줄 알았더니 그딴거 없더라.
뭐하나 변경하려면 신청서까지 올려서 결제받아야된다.
이 동네 형상관리엔 저게 포함 안되나보다.

형상관리 이야기가 나와서 말인데
뭐 운영서버에 올라갈 애들은 당연히 관리대상이지만
개발서버에 올라가는 애들은 대상이 아니다. 뭐 형상관리 테스트하면서 적용하기는 하지만
개발툴에 리소스들은 거의 관리 안된다.
특히나 이 동네 화면툴.. 버전관리 절대 안된다. 서버에 파일 쓰기권한이 다 있어서
아무나 지울수도 있다. 2~3일에 한번 꼭 폴더 한번씩 말아먹는 사고가 터진다.
svn만 연동해도 이런 머리아픈 상황은 안겪을 텐데.
뭐 우리회사 솔루션도 아니고 하니 뭐라 할 수 있는 상황은 아닌데
우연찮게 밥먹다 그 이야기가 나와서 얘기 했더니
팀장님 왈, "보통 그런거 할 수 있어도 일부러 안해주는 거다."
왜요? 그랬더니 "그런 관리까지 자기들이 맡아버리면 피곤하니 니들이 알아서 해라. 우린 솔루션만 제공한다."
이런 마인드란다..

이런 동네서 뭔가 만들고 오픈해서 돌아가는게 신기할 정도로 좀 아니다 싶은 경우가 간혹 있다.
이런거 보면 만사가 귀찮아진다.

군대서도 짬이 안되면 온갖 잡일을 하기 마련
사회라고 군대보단 덜하지만 짬이 안되면 역시나 잡일을 하게 되있다.

잡일1. 명패 붙이기
프로젝트 투입된지 얼마 안되 위치가 변경되고 새 사무집기들이 들어왔다. 사람도 좀 늘어서 명패를 달라는 하명이.. 문구점가서 명패사고 프린터로 길이 맞춰서 출력하고 칼질하고 자리배치도 가서 붙여주고..

잡일2. 회식(?)준비
달에 한번씩 생일 혹은 우수사원시상같은걸 하는데 거기 먹을걸 장봐야했다.. 뭐 배달해주니 들고 올일은 없지만 오면 세팅하는게 일.. 먹고 나서 뒷치닥거리 역시..

잡일3. 상황판, 대형 자리배치도
프로젝트 전체 간트차트같은 걸 출력해서 붙여야 하는데 사이즈가 애매해서 출력소가서 애먹었다. 접착코팅으로 출력해서 화이트보드에 다는데 왠 기포들이 잔뜩 생겨서 빼는데 고생..

잡일4. 프로젝트 슬로건(?)만들기
이런건 보통 위에서 어떻게 하자 이렇게 내려와야 정상인데.. 생각좀 해보라고 해서 알아서들 하라고 쌩까고 있었는데 갑자기 압박을.. 몇개 만들어 보여주니.. 그 자리에서 저거 인쇄소가서 현수막 만들어오라고 함

잡일5. 워크샵준비
1박2일 일정으로 100여명이 워크샵을 가는데 갈 장소를 내가 정했다.(내가 도대체 왜!!) 뭐 예약까지하고 나중에 고객이 위치를 변경했지만.. 워크샵이 오후에 출발인데 오전에 출발에서 자리잡고 세팅하고 술과 먹을 거리를 사고 나니 사람들이 하나둘씩..

금융권이 다른 동네보다 보수적인 동네라 윗사람들에게 보여주기식에 일들이 많이 있는데 군대하고 비슷하다.
어느날 갑자기 천장에 부서 명패 박아놓고 몇십만원짜리 화분이 5~6개 들어오더니 내일 회장님이 오신다고..

물론 저 일들을 다 혼자한건 아니고 같이 일하던 친구와 사업관리하시는 분과 같이 했지만.. 어느 정도 잡일은 이해가 갔다만 아직도 내가 만든 슬로건이 현수막에 걸려있는걸 보면.. 좀 웃기기도 하다.

그때는 프로젝트 초반이라 나와 같은 직급을 가진 사람이 거의 없었다. 회식이라도 갔다가 노래방가면.. 앉아있을 수가 없었다.
지금은 그때보다 사람도 더 늘고 사업관리하시는 분께 부사수(?)가 생겨 이젠 저런 일 안하고 개발만 한다.

사람 설득 시키는 것도 능력이다.

flow가 좀 복잡한 프로세스를 설계하고 개발하고 있는데

보통 업무들이 단위 서비스로 처리되는 반면 이건 여러개 서비스와 단말화면이 혼합되어 있다.

구조상 서비스를 날린 화면에서 트랜잭션이 끝나도 화면에 lock을 걸고 다른 트랜젝션이 진행되고 완료되면
sendtocli 형식으로 lock을 푸는게 내가 봤을땐(뭐 나뿐만 아니라 우리 팀사람 모두) 최선에 방식이라 생각하고 있는데
갑의 생각은 뭔가 다른가보다.

갑 : 하나에 트랜잭션으로 처리하자
나 : 프로세스 구조상 하나에 트랜젝션으로 처리가 불가능하다.
갑 : 그럼 폴링은 어떠냐
나 : 폴링 쓰는 동네가 어디 있나?(물론 이렇게 말하진 않았다.) 폴링은 미들웨어 단에서 문제가 발생할 수 있다.
제안한 방식이 다른 동네서도 주로 쓰는 방식이다.
갑 : 에러 포인트가 생기면?
나 : 에러 발생하면 죽는건 다른 애들도 매한가지다. 거래는 롤백처리되고 에러전 기록은 남아있다. 재처리도 가능하다.
갑 : 구조가 복잡하다. 나중에 운영들어 갔을 때 문제 발생하면 처리가 곤란할거 같다.
나 : ... 그럼 폴링이나 1 트랜젝션 말고 다른 방안이 있으면 말해달라.
갑 : 알았다. 검토해보겠다.

일부러 저부분은 손안대고 있었는데 원안대로 개발했으면.. 다 뒤엎었을지도 모르는 일이었다.

어쨌건 몇일안에 결정나겠지만 칼자루 쥐고 있는 사람 하나 설득하는게 쉽지 않다. 능력부족인가?

어디에서든 마찬가지지만 말한마디가 전체를 좌우하는 경우가 있다.

얼마전 일을 진행하는데 느낀 점이 하나 있다.

그 전까지의 상황은

A라는 업무를 진행하려고 하는데 고객은 A라는 업무를 a1, a2, a3로 나누고 있었고 기존 시스템이 저렇게 따로 분리 되어 있는 상황이었다.
우리쪽에서 들고 있던 모델은 그중에 a1인데 약간의 변경을 가하면 a2, a3도 커버 가능한 모델이다.

나는 이러한 상황을 이미 알고 있었고 고객측에 설명을 할 때는 a1이 주가 되는 분위기로 이야기를 했다. 당연히 반응은 좋지 않았고 처음 의도와는 다른 방향으로 흘러가는 느낌을 받았다.

그러다 결국 일정이 딜레이된다는 윗선에 지적에 부랴부랴 테스크포스 비스므리한게 꾸려지고 회의가 진행되었는데 한방에 일이 정리되었다.

회의를 정리하신 분은 내가 a1이 메인인것 처럼 말했던것과는 달리 전체적인 모델을 그려놓고 a1, a2, a3 모두 다 커버 가능하다. 라고 말했다.

당연하게 이렇게 말했어야 하는 걸 이제 알았다. 왜 이런 생각을 안했을까 하는 자책?자괴감이 들기도 했다.

거창하게 고객감동 어쩌구하는 소리는 집어치우고 저쪽이 뭘 원하는지 파악을 해야되는건데 파악을 못한거다.
이럴때 마다 내공이 부족한 걸 느낀다.