제안작업하기 #1

금융기관에서 RFP가 발송됩니다.

어떻게 발송할까? 나한테 보내주나? 전화오나?


이것도 기관마다 방식이 다릅니다. 자사 홈페이지에 게시하는 경우도 있고, 공공기관인 경우 나라장터에 올라오는 경우도 있습니다만, 일반적으론 제안 설명회를 엽니다.

00은행 00프로젝트 구축 제안설명회를 다음과 같이 개최하오니 몇날 몇시에 00빌딩 00층으로 모이삼...

식으로 공문을 보냅니다.

그곳에 가면 RFP 문서를 프린트해서(요걸 하드카피라고들 표현하죠.) 나눠줍니다.
그리고는 프로젝트 담당자가 간략한 설명을 진행합니다. 담당자는 IT담장자일 수도 있고, 현업일수도 있습니다.
15분~30분정도 설명이 진행된 후, 질의 응답 할 시간이 주어집니다.
이 자리에서 질의 응답은 크게 두가지로 분류됩니다.

1. 제안과정에서 필요한 계약, 서류, 자격, 전달 방법 등 영업부 Role에 관한 것
2. 제안내용에 관한 기술적인 혹은 업무적인 사업부 Role에 관한 것

그래서 보통 영업부, 사업부 각 1명씩 참석하는 것이 일반적입니다.

표현이 애매하거나 뭔가 이상하다고해서 이자리에서 꼬치꼬치 물어보면 안됩니다.
답변하는 분이 RFP를 작성한 장본인인데, RFP를 잘못쓴 것처럼 보이면 안되니까요.
그래서 이메일이라는게 있는겁니다. RFP 어딘가에 보면 문의안내 란이 있습니다.

계약관련은 김총무에게, 업무관련은 최비즈에게 문의하세요.

그래서 보통 질의 응답은 특별한 이슈 없이 간단하게 넘어갑니다.
그다음엔 각 업체에서 RFP 수령해갔다는 사인을 합니다.

마지막으로, 업체 사람들끼리 인사를 합니다. 매번 보는 얼굴이 그 얼굴이니 별로 안친해도 인사는 합니다.(안하는 경우도 있지만, 한번 안하면 매번 인사할까말까 어색하니 되도록 하십시다.)


자, 이제 RFP를 받았으니 각자 회사로 돌아가서 제안 작업을 시작합니다.

가장 먼저 할 일은 RFP를 분석하는 일입니다. 

누가? 아까 그 둘이. 사업부랑 영업부.

자.. 분석 들어갑니다.

분석하면서 고민해야할 주요 포인트는 다음과 같습니다.

RFP분석 포인트 1. 이 프로젝트가 우리 회사에 어떤 의미(향후 발전가능성)가 있는가.

 은행 SI프로젝트의 경우, '의미'를 잘 파악해야합니다. 이번 프로젝트가 10억이라고해서 그게 다가 아닌겁니다. 이유를 살펴보겠습니다.

예를들면, 국내 최초 스마트폰 뱅킹 프로젝트라 칩시다. 어떤의미가 있을까요?

스마트폰뱅킹같은 사이트는 A은행이 만들면 다른은행도 만듭니다. 그럼 다음번 B은행의 스마트폰뱅킹 프로젝트 제안할땐 A은행을 수주했던 업체만이 유일하게 레퍼런스 사이트를 갖게됩니다. 그러면, B은행의 제안 경쟁시 다른 업체보다 우위를 점할수 있는것이죠.

* 레퍼런스(Reference)?
사전적인 의미로는 '참고 할 수 있는 어떤 것' 쯤이 됩니다.
일반적으로 이바닥에서는 

"게들 레퍼런스 있어?" 이려면,  

"말씀하신 업체에서 전에 이와 유사한 프로젝트를 경험한 적이 있나요?"  라는 뜻입니다.

 금융IT 세계에서 레퍼런스(유사사이트 경험)란 엄청난겁니다. 사람을 뽑아도 경력에 '은행'들어간사람만 뽑습니다. 금융권 프로젝트 경험이 없는 IT회사가 은행 사이트 수주하기란 낙타가 바늘 구멍 들어가기입니다.

내가 뭘 어쨌다고 그 구멍에 들어가라는거야.jpg

모험을 할 수 없는 금융회사 특성상 처음보는 회사에게 큰 프로젝트를 준다는게 어렵다는건 미루어 짐작할 수 있습니다. 달리보면 시작이 어렵지 한번 파고나면 비교적 쉽다는 뜻도 되겠습니다.

RFP분석 포인트 2. 이 프로젝트가 수익성이 있는가.

먼저 RFP에 명시된 구현 대상 업무 목록과 사업기간을 파악하고(RFP에 사업기간은 없을 수 도 있습니다. 그럼 알아서 산정해야합니다.), 필요한 공수를 MM(맨먼스:Man Month)단위로 산정합니다. 영어 좀 했다고 맨먼뜨 이러면 안됩니다. 말은 알아들으라고 하는 거지 잘난척하라고 하는게 아니니까 그냥 맨먼스로 합시다.

*MM(Man Month)이란,
1명이 1달동안 일하는 것을 의미합니다. 2MM 이면, 1명이 2달, 혹은 2명이 1달 일하는 것이죠. 이런 식으로 산정해서 견적의 근거로 제출합니다.
대부분이 이런 방식으로 프로젝트 규모를 산정합니다만, 이 부분이 많은 오해와 부작용을 유발하고 있습니다. 이를 대체하기 위한 방법으로 펑션포인트(function point: 기능점수)라는 것도 있습니다만, 단가가 올라간다는 이유로 아직 널리 사용되지는 않고있습니다. 자세한건 다음기회에 다루기로 하고, 호기심이 많은 분들은 '맨먼스 미신 (The Mythical Man-Month)' 이라는 책을 읽어 보시길 바랍니다.

그 다음은 하드웨어 산정이 필요합니다. 고객사에서 처리하고자하는 시스템 성능을 만족하기위한 하드웨어 스펙을 뽑는 것인데요. 이때 가장 많이 사용되는 단어가 '티피엠씨(tpmC)'입니다.

tpmC(Transaction Per Minute type C)?
TPC(Transaction Processing Performance Council: http://www.tpc.org/)에서 제공하는 벤치마킹 자료중에 OLTP(on-line transaction processing)를 의미하는 C Type의 트랜잭션을 tpmC라고 합니다.

제 블로그에 설명하는 용어는 이 업계에서 표준어처럼 사용되는 단어들입니다. 그럼에도 불구하고 많은 사람들이 정확한 뜻을 모르고 사용합니다. 이 글을 읽는 분들은 정확한 뜻을 알고 사용했으면 하는 바램이며, 약어를 외울때에는 전체 뜻을 알고 외우는것이 오래갑니다. 또한, 그래야만 나중에 잘난척할 수 있습니다. 

명심하시길.

삼천포로 빠질뻔 한것을 극적으로 돌려서..

고객은 '최대 동지 접속자 000명 혹은 하루 처리 건수 000건을 만족해야함.'이런식으로 RFP에 성능 요구 조건을 기재합니다. 그러면, 이 데이터를 바탕으로 필요한 tpmC 산정을 하는데요, TA님들이 사용하는 일반적인 공식이 있습니다.(최대 피크치를 계산해고 듀얼 구성일 경우 한대가 죽었을때를 대비하여 곱하기 2를 합니다. 주어진 수치에서 예상할 수 있는 가장 큰 값으로 계산하는 것이 일반적입니다. 그래서, 낭비적인 면도 있죠.) 

이렇게 용량 산정 작업이 끝나면,

'이정도의 트랜잭션을(몇 tpmC를) 처리하기 위해서는 하드웨어가 이런 것들이 필요해'라는 결론이 나옵니다. 그 다음 하드웨어 납품 업체에게 견적을 의뢰합니다. 그럼 장비 구입 금액이 나오겠죠.

서버 기종은 어떻게 선택하나요? 

국내 은행권의 90%는 IBM계열의 UNIX 서버를 사용합니다. 한번 IBM제품을 쓰면 계속 IBM 제품을 사용합니다. 고급스럽게 표현하면 '고객 선호 제품'이라고 합니다. 하지만, 이면에는 이런 뜻이 있습니다.
 1.시스템 관리자가 IBM 겨우 배워놨는데, HP 장비 들어오면 관리하기 힘드니까.
 2.IBM 서버 관리 업체랑 계약 맺어놓은게 있으니, IBM이 들어와야 서비스 받을 수 있어.
여하튼 대부분 IBM-AIX로 구성되어있습니다. 예전엔 간혹 HP장비도 보곤했는데, 최근들어 영 보기 힘듭니다. SUN장비는 금융권 서버실에서 만난적이 한번도 없습니다. 제 경험으론 그렇습니다.
이런상황에서 무턱대고 SUN장비 제안하면 어떻게 되겠습니까? 기술점수에서 낙제점 받습니다.
그렇다면, 무조건 IBM서버군으로 제안하시나요?
아니요. 그런게 어딨겠습니까, 객관적인 자료를 바탕으로 가장 합리적인 제품을 선별해야지요. 라고 말하고싶지만, 실상은...
'여긴 규모가 작으니, P520 2Core 정도 들어가면되겠네.'
'나중에 커질 사이트야. P795 급은 되어야해'
이런식으로 말씀들 하십니다.

P520, P795이란, P는 IBM 프로세스 중 Power시리즈를 의미하며, 529, 795는 서버 모델 번호입니다. 한마디로 IBM 서버 모델명이죠. 헌데 이 모델명이 모든 서버군의 등급번호인듯이 말씀들 하십니다.

'사고에 민감하고 보수적인 금융이관이다보니'라고 밖에는 설명이 안됩니다.

하드웨어에 처바를 돈, 개발비에 투자해야하는데... 

여튼, 이동네의 90% 이상은 IBM장비 기준으로 작업합니다.

 최근들어 하드웨어는 따로 발주하는 경우가 많습니다. 프로젝트별로 구매하는 것이 아니고, 각 프로젝트 제안시에는 필요한 용량만 산정하고 하드웨어 발주는 고객사가 직접 하는 것이지요. 즉, 제안서에는 시스템 구성도와 필요 tpmC를 기술하면, 그 구성에 적합한 하드웨어를 고객사에서 직접 삽니다. (물론 IBM제품이겠죠.)

다음은 소프트웨어 산출입니다. 인터넷뱅킹 기준으로 생각나는 것을 말해보자면,

WEB(HTTP Server),WAS, DB, 프레임워크, 보안모듈, 리포팅 툴, 백업솔루션, 모니터링 솔루션... 대충 이정도 입니다. 소프트웨어 목록이 도출되면, 역시 각 업체에 견적을 의뢰합니다.

이런 작업은 누가 하나요?

좋은 질문자 입니다. 하드웨어 용량 산정을 위해서는 먼저 시스템 아키텍처가 확정되어야 합니다. 시스템 아키텍처라는 단어만으로도 2박3일을 꼬박 얘기해야 '아...이게 그거구나'라고 느끼게 할 수 있을 것 같습니다만, 간단히 말해보자면,

 인터넷망이 1차 방화벽을 통해서 들어오고 DMZ 구간에 웹서버가 있어야하고, 2차방화벽이 있고, WAS 서버가 있고, TCP 통신을 해야하는데, 보안이 어떻게되고, DB는 이쯤에 있고, JDBC는 여기서 연결이 되어있고.. 등등

이런 구성을 그림 한장에 그립니다. 이 그림이 하드웨어 구성도입니다. 

하드웨어 구성도, 시스템 구성도, 네트워크 구성도 세가지 이름 모두 유사한 형태입니다.

(단, 간혹 시스템 구성도라는 말은 포괄적인 논리구성까지 포함하는 경우도 있습니다.)

그담엔, 각 박스에 탑재되어야할 소프트웨어를 그립니다. 이 그림이 소프트웨어 구성도입니다. 

마지막으로 인터페이스 구성도가 필요합니다. 각 서버간 연결관계, 통신방법 등을 기술하여 데이터의 흐름을 표현하는 겁니다.

여기까지가 시스템 아키텍처라고 볼 수 있습니다. 이 세가지만 잘 되어있으면 이제 업무 구현방안만 고민하면 됩니다. 만약, 시스템 아키텍처가 잘못되면 프로젝트의 방향이 잘못되고, 프로젝트가 실패할 수도 있습니다. 

아무나 할 수 없는 대단히 중요하고 외롭고 고독하고 리스키한 작업이죠.

그래서! 이러한 작업은 모든 사업에 관여하는 TA(Technical Architect)라 불리우는 사람이 수행합니다.

아키텍트는 본인이 명함에 'Architect'라고 찍는다고 되는 게 아닙니다.제안요청서 제목만 봐도 머리속에는 그림이 딱 그려질 정도로 경험도 많고 지식도 많아야합니다. 본인의 생각이 옳다는 것을 설명하고 납득시키고 그릴 수 있어야합니다. 그래서 남들이 아키텍트라고 불러줘야 비로소 아키텍트가 되는 겁니다. 다른사람이 중요한 결정을 해야할때 찾고 믿고 의지하는 사람이어야 합니다.
 IT업계에선 자리가 사람을 만들 수 없습니다. '당신이 이제부터 아키텍트 하시오'해봤자 안되는사람은 안됩니다. 내 직함이 아키텍트이오니 그냥 따라오세요.식으로 일하는 사람입니다.

내가낸데 어따대고 질문이야 닥치고 그냥 하삼.jpg

기술력과 인격이 적절한 비율(7:3)로 장착되면 자연스레 사람들이 모이고, 어느순간 아키텍트가 되어있는 겁니다.

기술과 인격에 대한 이야기는 다음 기회로 미루고  다시 본론으로 돌아갑니다. 

하드웨어견적+소프트웨어견적+인건비. 이정도면 필수 견적은 도출되었습니다. 

이 외에도 추가로 발생할 수 있는 비용이 있으면 산정해서 더합니다.(각종 컨설팅 비용, 사무실 임대 비용 등)

이제 다 됐습니다. 이제 이 돈만 있으면 프로젝트를 수행 할 수 있습니다. 이 자료를 바탕으로 제안할때 제출할 견적서를 작성하는데요, 여기서 중요한 건 견적서보다도 사업 타당성입니다. 그래서 본 자료를 바탕으로 수익성 분석 자료를 작성합니다.

자, 이제 이 사업에 대한 의미와 수익성이 도출되었습니다. 본 자료를 바탕으로 이 사업을 제안 할 것인가 말것인가를 결정합니다. 이 결정에는 최고 의사 결정자인 CEO가 참여하는 경우가 많습니다. 그런데 말이죠...

고객님께서 친히 RFP를 보내주신 이 성스러운 사업을 Cool하게 안하겠다고 내던져버리면 어떻게 될까~요?

사실 고객님들께서 의미도 없고 수익성도 없는 사업을 발주할 리도 없지 않겠습니까?

결국 특별한 일이 없으면 이제부터 고생길  제안작업 시작입니다.

작업 순서는 다음과 같습니다. 다음편 예고쯤으로 보시면 됩니다.

1. RFP를 보고 목차를 작성한다.
2. 필요한 인력들이 모여 전체적인 방향 및 일정을 공유한다.
3. R&R을 정한다.
4. 각자 자리로 돌아가(혹은 한데 모여) 각자의 분량을 작성한다.
5. 다시 모여 같이 리뷰를 진행하면서 수정사항을 도출한다.
6. 각자 작성
7. 다시 리뷰(2차리뷰)
8. 각자 작성
9. 다시 리뷰(최총리뷰)
10. 제안서 완료
11. 제안서를 바탕으로 설명회 자료 작성

본격적인 제안작업은 다음편에서 계속...

금융IT 프로젝트의 서막

 금융기관의 프로젝트는 어떻게 시작할까요?

프로젝트를 진행하기 위해서는 돈이 필요합니다.
그래서 예산이 먼저 잡힙니다.


예산이 잡히는 프로세스는 기관마다 다르긴 하지만, 보통은 하반기에 진행되는데요,
내년에 어떤 일을 하겠습니다..라고 IT부서(혹은 현업부서)에서 기안을 올립니다.

Q : IT부서는 뭐고 현업 부서는 뭔가요? 

A : IT부서는 개발.운영을 담당하는 개발조직이고, 현업부서는(사전적인 의미하고는 다르게 쓰이는 경향이 있습니다) 상품을 기획하고 업무요건을 발휘하는 조직입니다.

금융기관 조직에 대한 자세한 이야기는 다음기회에... 

이 시기엔 대충 올립니다.

예를 들면, 스마트폰뱅킹을 할건데 이거 하려면 얼마가 있어야하오..라고 문서를 작성하죠.
이 문서가 통과되면 '예산이 잡혔다.' 라고 말합니다.

이 시기에 정보전략계획(ISP;Information Strategic planning)이라 부르는 컨설팅 작업을 수행하고 그에 수반한 자료를 토대로 예산 프로세스가 진행되는 경우도 있습니다만, 

이런 경우는 아주아주 큰 프로젝트에만 해당됩니다. 역시 다음에 기회가 되면 언급하기로하고 일단 패스.

이러면 뭔가 하겠다는 계획이 선 것이고, 그 다음해가 되면 IT부서에서 약속했던 프로젝트를 수행해야합니다. 


 연초엔 이래저래 놀다가 여름휴가 지나서쯤... 아... 내가 그거 한다고했지. 젠장.. 준비해야겠네. 추석지나고해야지.. 이러면서 준비합니다. (이건 맨날 연말에 프로젝트 몰리니까 제가 추측해보는 겁니다.) 


그럼 무엇을 준비하느냐.


그거슨 바로.  제안요청서(RFP; Request For Proposal)!!!


사전적인 의미는 인터넷에서 찾아보시고, 한마디로 이런거 만들어야하니까 만들사람 덤비삼.. 할때 보여주는 문서입니다.
 제안요청서를 잘 작성해야 개발업체들이 제안서를 잘 작성하고, 프로젝트 준비(인력 세팅 및 아키텍처 설계.. 정도?)를 잘 해오는 것이고, 결국 프로젝트의 성공으로까지 이어집니다.
 RFP는 작성하는 개개인마다 혹은 기관마다 많은 차이가 있으나, 일반적으로 관련 업계 사람이 딱 보면 '이런걸 하는거구나. 이렇게 하라는 거구나' 정도는 알 수 있어야합니다. 
그런데,,, 보통 금융기관에서 RFP를 작성할 수 있느냐. 


그렇게 꼼꼼하게 아키텍처 설계할 수 있으면 비싼돈 들여 외부 개발업체한테 맡기겠습니까. 
능력의 문제가 아니라 역할이 다르니까요.

그래서 RFI(Request For Information) 작업을 합니다. RFP를 위한 사전작업이라고 보면됩니다.
(역시 사전적인 의미는 인터넷에서...)
좀더 자세하게 말하면, 
제안요청서를 받을 개발업체들한테 '우리 이런거 만들어야하는데 정보 좀 주시오.'라고 요청을 합니다.
개발업체 입장에서는 땡큐죠. 
한두명정도가 달라붙어서 제안서를 만들기 위한 자료도 제공해주고, 방안도 잡아주고 하는  컨설팅 작업을 수행합니다.
보통 이 과정에서 자사에 유리한 쪽으로 방향을 잡습니다.
(이게 옳다그르다를 떠나서 일반적으로 그렇다는 겁니다. 저는 세계 평화를 목표로 RFI 작업을 합니다.)


RFI 작업을 꼭 한 업체에만 맡기는 건 아닙니다. 사실 그래서도 안되구요.
RFI 작업 과정에서 '이 업체는 안되겠구나. 탈락' 이런 사태도 발생합니다.
그럼 RFP를 못받겠죠?


 이런 이유로, RFI작업은 정말 똑똑한 사람이 해야합니다. 기술적인 지식도 많아야하고, 경험도 많아야하고, 말도 잘해야하고, 문서도 잘 만들어야합니다. 거기에 고객사에서 '저 사람이랑 또 일하고싶어.'라는 생각이 들 정도로 성실하고 매력도 있고 아무튼 막 그래야합니다.

그렇다고 RFI 작업하는사람들이 다 이런건 아닙니다. (저도 이런사람을 아직 만나보진 못햇습니다. 저 빼곤..)

그저 문서 대행작업 내지는 자료 조사원 정도의 역할만 수행하고 생 노다가만 하다가..
(심지어는 이런 역할 수행도 거지같이 합니다. 쓸모없는 자료만 생산하는 거죠)


정작 RFP가 딱 나오면...

이러고 있습니다..


이런 얼굴 안하려면 RFI 작업 해달라고할때 유능한 사람 보내야합니다.


이것보다 더 안좋은 상황은 멍때리고있는데 RFP 나왔으니까 수령하라고 연락오는 겁니다.
이렇게되면, RFP 받고나서 

성경공부해야죠. 이런 무슨 의미지? 왜 이런 말투로 썼지? 이건 어쩌라는건가? 이러면서말이죠.
이러다보면 고객이 의도했던 것과는 영 딴판으로 제안서를 작성하는 경우도 생기죠.


역시 RFI 작업이 중요하다는 것을 알 수 있습니다.


RFP 발송 이후 진행은 다음에 계속....

올바른 회사 생활

아마 5년주기인 것 같다.  내가 '올바른 회사생활'이라는 주제로 고민하는게...

그 처음은 입사하고 몇일 안되서였다.
이유는 잘 기억안나지만,  윗분에게 크게 혼난적이 있었다. 그때 이런말을 들었다.

"회사가 뭘 믿고 너한테 투자를 해야되냐? 여기가 학교냐?" 

혼났다는 건 문제가 아니었지만, 참 많은 생각을 하게 만들었다.

 '그동안은 내 돈을 소비하며 사회에 일원이 되며 살았지만, 이곳은 나에게 돈을 주는 곳이다.'

'이곳에선 열심히 한다고 창찬받지않는다. 잘해야한다.'

'내가 쓸모가 없으면 돈을 받을 수 없고, 결국 난 이곳의 일원일 수 없다.'

며칠 짬나는데로 생각한 결과였다. 
덕분에 난 수능시험볼때보다도 더 긴장했고, 집중했다.

그다음 5년이 흘렀다.

'난 그를 책임질 의무가 없어. 여긴 회사니까'

이 말에 난 반론할 수 없었다. 그저 머리를 한대 쾅 맞은 기분으로 멍하니 서있었다.
분명 시작할땐 내 논리가 이길 것 같았는데, 그 말이 틀린게 없었다. 입은 다물고 있었지만, 고개는 끄덕거렸다.

'그렇지, 이사람은 아빠나 형이 아니지. 그사람을 책임질 의무는 없지.'

그러자 새로운 질문이 생겼다.

'조직에는 팀이 있고, 부서가 있고, 윗자리 아랫자리에 사람들이 있다. 난 그들과 얼만큼 가까워져야하며, 얼만큼 의지해야하며, 얼만큼 책임져줘야하는가.'

이 질문에는 아무런 답을 얻지 못했고, 


그저 '누군가가, 혹은 누군가를 책임져주지않아도 되는 상태'를 유지하자'라는 잠정적인 결론을 내렸다.


덕분에 조금은 풀어져있던 긴장이 다시 조여왔고, 내 모든 행동과 결정은 내가 책임진다는 생각으로 내 이름이 들어가는 모든 일에 오점이 없으려 노력했다.

그리고 또 5년이 흘렀다.








이젠 나를 둘러싼 상황이 많이 변했고 지난 두번의 5년동안은 보이지않았던 새로운 모습이  날 고민하게 한다.

'참...고맙게도 잊을만 하면 일깨워주는 구나. 그래그래, 여긴 아직 회사다. 정신차리자.'

이번에도 몇일이 지나면 나름대로의 결론을 내리고 다시 집중하지않을까싶다.

다만, 다음 5년 후엔 좀 더 따뜻한 생각이 들었으면 하는 바램이 든다.

나이를 먹을 수록 시간이 빨리 가는 이유

전 어릴때부터 계획세우는 걸 좋아했습니다.

그 시작은 초등학교 방학숙제였던 큰 원을 그려 시간별로 무얼 할지 적는 것이었죠.

중.고등학교땐 공부계획이 주를 이뤘습니다.

짧게는 하루를 쪼갠 계획이었고, 길게는 일주일. 한달을 쪼개 공부하는 계획을 세웠죠.

까먹을 것을 대비해, 처음 공부했던건 마지막에 한번더 해주는 꼼꼼함까지...

24살이던 해. 어쩌다보니 회사를 들어가게되었습니다. 
사회에 발을 딛인 기념으로 전 예전의 일주일.한달보다 훨씬 큰 규모의 계획을 세웠습니다.

'앞으로 3년동안 회사생활을 하면서 사업준비를 하고, 

서른 전에 원없이 일을 벌려본 다음 결혼을 하자.'

큰 틀은 이랬더랬습니다.

그런데 시간이 지날 수록 이 계획이 조금씩 차질을 빚기 시작했습니다.

하나씩 생각해보면 딱히 늦춰진 요소가 없는데도, 이상하게 진도가 안맞는겁니다.

왜그럴까 곰곰히 생각한 끝에 드디어 해답을 찾았습니다.










바로바로바로..

"일년이라는 시간은 내 나이 분에 1 (1/내 나이) !!!!!!" 이였다는 겁니다!!

즉 24살때의 일년은 1/24 이고, 25살이되면 1/25 로 줄어든다는 거죠.


20살때의 일년은 1/20, 10살때의 일년은 1/10, 두살의 일년은 1/2...

이렇게 생각하고나니 제법 설명이 됩니다.
이래서 내가 계획한 일들이 생각했던 기간안에 끝나질않았던 겁니다.


내가 계획했을땐 1년은 1/24였는데, 실행할땐 1/25, 1/26 이니까말이죠.

이젠 내게 일년이 고작 1/35 밖에 안되는 시간이고,

내년의 일년인 1/36 이라는 시간은 얼마나 짧은지 조차도 잘 모르겠습니다.

그래서 계획을 세우고 실천한다는게 점점 힘들어질 것 같다는 생각이 듭니다.

그럼에도불구하고, 지금 이시점에서 다시 계획이란것을 세워보려고합니다.

그간 해오던 것 보다 조금 더 빡빡하게 짜면 엇비슷하게는 지킬 수 있지 않을까 하는 기대를 해봅니다.

달빛 놀이터

몇살때였을까

밝은 낮에만 존재하는 놀이터가 밤에도 건재하다는 사실을 직접 확인한 날.

무슨 경사스런 날이었던건지

집안까지 펑펑 거리던 폭죽소리에 창밖을 보니 까만 밤하늘에 성대한 불꽃놀이가 한창이었다.

부모님께 졸라 겨우겨우 밖으로 나갈수있었다.

황홀했던 불꽃놀이가 끝나고 쳐들었던 고개를 바로하자,

저 멀리 파란 달빛에 비친 놀이터가 보였다.

항상 낮에만 뛰어놀던 그 놀이터 안엔 꼬마녀석들이 웅성이고있었다.

워낙 어둡고 멀어서 형체만 가까스로 보였으나, 체구의 크기만으로 동네친구들이라는 것을 알 수 있었다.

놀이터에 가까워지면서 피부를 스치는 스산한 바람.

연두색 페인트가 띄엄띄엄 벗겨진 미끄럼틀 기둥의 차가운 냄새

환한 달빛을 반사하는 파란 모래밭.

따가운 햇볕아래 치열한 놀이를 펼치던 그 놀이터가 지금의 이 공간이라고는 생각할 수 없었다.

이제야 누군지 알아보여지는 친구들.

미끄럼틀의 맨 아래에 걸터눕자

별이 보인다.

차가운 모래냄새가 난다.

꽤 여러명이 그곳에 걸터누웠던 기억으로 미루어 우린 무척 조그마했었나보다.

달빛에 취한 우리는 그저그런 수다였음에도 특별한 파티를 한 듯한 기분이 들었다.

사소한 이야기 거리로도 그 시간은 하염없이 이어졌다.

짙은 파란빛 놀이터에서 소곤대던 우리 이야기는 저 달에까지도 들렸으리라.