'2009/04'에 해당되는 글 11건

  1. 2009.04.25 성냥불 제대로 땡겨주는 - 일본전산 이야기 (3)
  2. 2009.04.16 코드 검색기
  3. 2009.04.12 (배치 고도화) 1. 자바로 엔터프라이즈 배치를? (18)
  4. 2009.04.08 벌써 받았던 것들을 돌려줄 나이가.. (2)
  5. 2009.04.08 (EA/ISP) 1. ISP 프로젝트에서 TA의 역할 (1)
마징가, 철인, 물개.. 야근을 즐기고, 툭하면 밤을 새는 업무 스타일 때문에 붙여졌던 지난 별명들입니다. 그런 스타일 때문에 미련하게 일한다며 놀림도 많이 받았습니다. 그런 제 스타일에 딱 맞는 자기 계발서 하나를 읽고 있습니다. 일본전산 이야기라는 책입니다.

예전에 서점에서 얼핏 훑어봤을 때는 이런 책이 왜 베스트셀러에 올라와있지? 싶을 정도로 관심 밖이였습니다. 하필 훑어본 부분이 아끼는 직원일수록 호되게 나무란다라는 챕터였는데요, 예전에 읽었던 상사가 귀신같아야 부하가 움직인다라는 책과 별반 다른 내용이 없었기 때문입니다.

아침에 신문을 읽다가 감동깊게 읽었던 이기는 습관 2편이 나왔다고 해서 들른 서점에서, 옆 자리에 놓인 일본전산 이야기를 또 다시 보게 되었습니다. 자꾸 눈에 띄니 인연인가 보다하고 같이 사서 나왔는데요, 이 책을 읽느라 원래 읽으려고 샀던 책은 뒷전이 되고 말았습니다. 오랜만에 마음 한 켠에 있는 제 열정에 성냥불을 제대로 댕겨주는 책을 읽었습니다. 몇 가지 내용만 소개해 볼까요?

경계대상 1호

자신을 온전히 불태워 헌신하지 않고, 어떻게 하면 '날로 먹을 방법은 없을까?" 궁리하며 쉽게 얻으려 하는 것. 조금 더 시간과 노력을 투자하는 것이 힘드니까, '안되는 이유를 찾아 열심히 짜 맞추어 둘러대는 것' 그리고 그런 패턴이 회사 내에서 쉽게 통용되는 문화가 바로 '경계 대상 1호'다.

'되는'일에만 집중해도 모자랄 시간에, '안되는' 이유를 쓰느라 시간을 허비할 필요가 어디 있는가?

어느샌가 열정없이 그저 할 수 있는 것들만 하려는 고정 관념에 사로잡혀 있게 된 것은 아닌지 돌아보게 만드는 글입니다. 되는 방법을 찾기위해 진심으로 노력하기 보다 짧은 경험과 얕은 지식으로 "이것 봐, 안되쟎아.."라는 생각에 시간을 허비하지 않도록 노력해야겠다고 결심하게 되네요.

지적 하드워킹

진정한 프로가 된다는 것은 남들에게는 '보이지 않는 곳'까지 생각이 미치는 것이다. 똑똑한 것과는 다르다. 자신의 생각을 끊임없이 확장시키고, 문제가 생기면 책임지고 해결하려는 습관을 들인 사람만이 프로가 될 수 있다.

근무 시간 8시간을 '몸'으로 하는 노동이라고 가정한다면, 나머지 시간에는 '생각'으로 일을 한다는 말이다. 이렇게 '생각으로 일하는 시간'을 많이 내는 사람일수록, 조직에서 더 좋은 성과를 내는 것은 당연하다.

개발자의 학습과 자세에 관한 좋은 글들을 많이 올라오는 애자일 이야기에서 읽었던 학습의 복리 효과에 관한 글이 떠오릅니다. 사이트에 나가 있는 동안은 바쁘다는 핑계로 자기 계발을 멀리하는 것을 당연히 여긴 것을 반성하게 됩니다. 지적 하드워킹에서 한걸음 더 나아가, 업무를 최대한 집중해서 수행하고 지적 Capacity를 늘리는 방향으로 꾸진히 증진할 수 있도록 노력해야 겠다는 생각이 듭니다.

이 밖에 3부에서도 참 좋은 글들이 많았는데요, 안 읽어 보신 분들은 꼭 한번 읽어보시길 추천합니다. 금요일 퇴근 길에 영회가 소개해준 "전략사고 컴플리트북"의 서문이 떠오르네요. 베이비붐 세대가 지난 요즘의 직장은 더 이상 주어진 일만 잘 해내는 것으로는 미래를 보장할 수 없으며, 전략적 사고를 지닌 개인이 직장에 어떤 가치를 줄 수 있을지를 고민하는 경영자 형태로 발전했을 때만이 자신의 미래와 회사의 가치를 높일 수 있다는 내용이였는데요, 안정적인 직장으로의 이직을 생각하던 제게 토비가 해준 "너를 안정되게 하는 것은 안정된 직장이 아니라 네가 가진 실력이다"라는 말과도 중복되는 것 같습니다. 일본전산 이야기라는 책에서는 "임원을 꿈꾸지 않는 직원은 필요없다"는 말로 표현하고 있기도 하죠.

채찍을 아끼지 않는 상사분들 밑에서, 내가 타오를 때 주저 없이 함께 타올라 주는 동료들과, 너무나 가치있는 소중한 경험들을 쌓아나갈 수 있는 지금이 너무나 행복합니다. 이 글을 읽는 지인분들도 행복하시길 바랍니다.
저작자 표시 비영리 변경 금지
신고

코드 검색기

이전글/2009 2009.04.16 13:12
좀전에 후배 녀석이 전화로 안부를 묻다가 어떤 알고리즘을 구현하고 있는데 오랜만에 다뤄서 기억이 잘 안난다는 말을 하더군요. 급하게 만들어야 된다고 투덜대서 Krugle을 한번 뒤져보지 그래? 라고 했더니 그게 뭔지를 모르네요. 대중화된지 꽤 오래 되었는데도 의외로 코드 검색기를 사용해보지 않은 분들이 꽤 많은 것 같아, 철지난 이야기지만 소개해볼까 합니다.

많이 알려진 코드 검색기는 Koders, Google Code Search, Krugle 등이 있습니다.

1. Koders (http://koders.com)

Koders의 장점은 다양한 IDE 지원인 것 같습니다. 이클립스나 비쥬얼 스튜디오 등과 연계해서 동작하기 때문에, 개발 도중에 특정 코드를 검색해서 검색 결과를 바로 개발에 사용할 수 있는 장점이 있습니다. (Koders의 이클립스 플러그인 다운로드)

2. Google Code Search (http://www.google.com/codesearch)

구글 코드 검색기의 장점은 정규식(Regular Expression)을 지원해서, 보다 정교한 검색이 가능하다는 것입니다. 정규식이 어렵다면 고급 코드 검색 기능을 이용해도 좋겠네요. 숙련되면 사용하기 편할 것도 같지만, 저는 개인적으로 인터페이스가 편하게 느껴지진 않았습니다.

3. Krugle (http://krugle.org/)

Krugle은 가장 먼저 알았던 코드 검색긴데요, 3년전에 토비랑 TDD 수련을 할 때 남들은 그 문제를 어떻게 풀었는지 궁금해서 찾아보면서 사용했던 기억이 납니다. Krugle을 이용해 마방진을 검색해 들어가면 아래와 같은 결과 화면을 볼 수 있는데요, 전체적인 배치나 검색 결과 등에서 나름 만족하며 썼습니다.


코드 검색기는 자주 사용할 일은 없지만, 가끔은 아주 요긴하게 사용할 수 있는 툴인 것 같습니다. 요즘은 코드를 검색해 본 일이 없어서, 어떤 코드 검색기를 사람들이 선호하는지는 모르겠네요. 아직도 이런 것들을 사용하겠죠?
저작자 표시 비영리 변경 금지
신고

배치 고도화 컨설팅을 의뢰받아 수행한 경험이 있습니다. 처음은 소프트웨어 아키텍트로 고도화를 위한 방안을 수립하는 역할이였고, 그 다음은 배치 어플리케이션 개발 프레임워크 구축 프로젝트의 PM 역할이였습니다. 실미도에 들어갔다며 블로깅을 멈추게 한 주범이 그 프로젝트죠. 정말 쉽지 않은 프로젝트였고, 업계를 떠나고 싶다는 생각이 들만큼 모든 열정을 다 불사르고서 겨우 성공할 수 있었습니다. 개인적으로도 많은 것들을 배우고 경험하는 뜻깊은 기간이였습니다. 

되돌아보면 명확한 목표 설정(Visioning), 적절한 커뮤니케이션(Communication)과 변화 관리, 잘 계획된 반복(Iteration)의 실천, 도메인 특성을 반영한 설계, 터프함을 견뎌낼 수 있었던 팀웍이 프로젝트를 성공으로 이끈 핵심 요소입니다. 정리하고 보니 뻔한 얘기네요 :)

그 뻔한 얘기의 일부를 정리해서 올해 열린 자바 개발자 컨퍼런스에 "차세대 배치 시스템 구축 성공 전략"이란 이름으로 발표를 했습니다. 본사에서 한참 제안 작업을 하던 때라, 중간에 참석해서 잠깐 발표만 하고 와버렸죠. 아래 사진도 구글링을 통해 greenapple 님의 블로그에서 가져온 것입니다. (발표 자료는 JCO 홈페이지에서 내려 받을 수 있습니다.)


짧은 발표 시간과 참석하시는 분들의 관심사 등을 고려해서 Spring Batch 확장과 같은 기술적인 얘기들을 주로 해서 아쉬움도 많았습니다. 정작 그 프로젝트를 통해 느끼고, 전달하고 싶었던 내용들은 그런 게 아니였는데 말이죠.

굴곡이 많았던 프로젝트를 몇 장의 PT로 정리하기는 아쉬움이 남습니다. 다시 블로깅을 시작할 만큼 활력을 찾은 지금, 시간이 허락하는 대로 틈틈이 하고 싶은 얘기들을 정리해 나갈 겁니다. 뻔한 얘기들이지만, 제게는 전혀 뻔하지 않았던 그런 얘기들 말이죠.[각주:1]

  1. 깨달은 바를 실천하기 위해 일부 내용을 삭제했습니다. [본문으로]
저작자 표시 비영리 변경 금지
신고

벌써 받았던 것들을 돌려줄 나이가 되었다는 것이 왠지 서글퍼지는 주말입니다.

최근 직함에 시니어(Senior)란 말이 붙여지면서, 새롭게 주어진 역할이 동료에 대한 멘토링입니다. 불행히도 누구에게 멘토링을 할 수준의 역량을 갖추지 못한 상태라, 멘토링을 할 때마다 불편한 마음이 듭니다. "궁하면 통한다"는 말이 있지요. 주역에 있는 "궁즉변(窮則變), 변즉통(變則通), 통즉구(通則久)."란 말에서 유래되었다고 합니다. 한계에 다다르면 변하게 되어 있고, 변하면 통하게 되어 있으며, 통하면 오래간다는 뜻이죠. 작년 한해 동안 궁함을 면하기 위해 무던히도 애를 썼고, 그 덕분에 이제 조금 통할 줄 알았는데, 금새 다시 궁해지는걸 보면.. 제대로 변하지 못한 모양입니다.

멘토링은 어떻게 하는 걸까요? 꽤 오랜 기간 지도(Coaching)와 교육(Teaching)을 해본 경험은 갖고 있습니다만, 멘토링은 전혀 다른 영역인 듯 합니다. 선배란 이유 하나만으로 제 스타일을 강요할 수도 없을 뿐 아니라, 괜한 간섭으로 더 커나갈 수 있는 그 사람의 가능성을 덮어버릴까 두렵기도 합니다. 그래도 최선을 다해 한번 부딪혀 볼 생각입니다. 제가 꿈꾸는 일을 해내기 위해서는 저 뿐 아니라 동료들도 반드시 함께 성장 해야만 하고, 성장을 위한 한 귀퉁이를 제가 책임져야 한다는 것을 알기 때문입니다. "도와주세요, 팀장이 됐어요"란 책에 등장하는 구루처럼, 제가 경험했던 것들을 세련되게 알려주지는 못하더라도 말이죠.

다행히 저는 멘토라고 부를 수 있는 친절한 선배를 세 명이나 만났고, 지금도 계속해서 관계를 유지하고 있습니다. 그 분들을 스스럼없이 멘토라고 부르게 된 이유를 생각해보면, 첫번째는 저를 얼마나 아끼는지 알고 있고, 두번째는 제가 따를만한 충분한 실력을 함께 일하는 동안 보아왔기 때문입니다. 정리하고 보니 따르지 않을 이유가 없었네요. :)

저도 그 친구들에게 따를만한 충분한 실력을 보여줬는지는 잘 모르겠습니다. 슬럼프에 빠져있을 때의 저를 기억한다면 별 장점이 없는 사람처럼 보았을 수도 있고, 한참 집중 모드로 일할 때의 저를 기억한다면 뭔가 배울만한 것이 있는 사람이라고 생각할 수도 있겠죠. 우선 급한 것은 서로에 대해 마음을 여는 일인 것 같네요. 기술적인 면에서는 충분히 스스로 일어 설 수 있는 능력을 가진 친구들이니, 선배들이 제게 해준 마음을 움직이는 얘기들을 제 경험을 통해 전달해 보려 노력해볼 요량입니다. 그 친구들에 대해 점점 호기심이 강해집니다. 좋은 징조인 것 같습니다. 

마침 제가 그 친구들 중 한명에게 해주고 싶은 얘기들이 담긴 책이 "겸손한 개발자가 만든 거만한 소프트웨어"라는 책이 출간됐네요. 기술적 소양이 뛰어난 한 친구에게 해주고 싶던 얘기들이 잘 정리되어 있는 것 같습니다. 몇 권 사서 저도 읽고,  다음 주 그룹 미팅 때 그 친구들에게도 전해줘야 겠습니다. 제 수고를 덜어준 hani님께 감사드립니다.



덧붙임-04.16 어제 서점에 가서 책을 사려고 집어 들었는데요 기대했던 내용들로 채워져 있었지만, 다른 책을 골랐습니다. 최근에 비슷한 책을 너무 많이 사본 것 같아 식상한 느낌도 좀 들고. 그러고 보니, 처음에 Pragmatic Programmer나 소프트웨어 공학의 오해와 진실, 조엘 온 소프트웨어 같은 책들을 읽었을 때는 신선하고, 본질에 대한 통찰력을 공짜로 얻을 수 있는 기회인 것 같아 열광했었는데요, 결국 책을 읽을 때 뿐이고, 본인이 고민하고 경험하지 않으면 자기 것이 되지 못하는 것 같아요.

신고
TAG 멘토링,

ISP 프로젝트가 뭐야?

정보화 전략 계획(ISP: Information Strategy Planning)은 경영 전략을 달성하고 환경 변화에 대응하기 위해 업무를 효과적으로 가능하게 하는 전사 수준의 정보 전략을 수립하고 구체적인 실행 계획을 수립하는 경영 활동을 말합니다.

2005년부터 정부가 국가 정보화 사업의 중복 투자를 방지하고 IT를 체계적으로 관리하기 위해 ITA(정보기술 아키텍처)를 법제화하기 시작하면서 금융권에서 EA(엔터프라이즈 아키텍처)를 수립하는 붐이 일었는데요, 제가 ISP에 투입되던 2~3년 전에는 차세대 시스템 구축을 목적으로 EA 기반의 정보화 전략 계획 수립 프로젝트가 많았습니다. 고객 입장에서는 하나의 프로젝트를 통해  정보화 전략 계획도 수립하고, 동시에 기업의 비즈니스/어플리케이션/데이터/기술/거버넌스 아키텍처를 수립하는 두 가지 효과를 얻겠다는 속셈이지만, 투입되는 컨설턴트의 입장에서는 3~4개월의 짧은 기간에 해내기에 벅찬 일을 요구받는 셈입니다. 아키텍처의 수준을 진단하고, 목표하는 방향을 드러낼 수 있는 수준에서 EA가 그려진다고 하더라도 말이죠. 

최근 ISP란걸 잊고 살았는데 회사에서 모회사의 ISP 프로젝트에 참여하게 되어, 동료 한 분이 제가 예전에 그랬던 것처럼 힘든 경험을 하게 되었습니다. 그래서 몇 번 되지 않는 ISP 경험이지만, 몇 달 동안 어떤 일들이 일어났는지를 정리해보고 싶었습니다. 방식이 바뀔 수는 있겠지만, IT 시스템이 존재하는 동안은 ISP와 같은 프로젝트가 없어질리는 없을테고, 누군가는 이 글을 읽고 도움을 받을 수도 있을테니까요. 물론 정리하는 저 자신에게도 도움이 될 테구요.

우선 엄살을 좀 부리자면 ISP는 정신적, 육체적으로 매우 힘든 프로젝트입니다. 컨설팅 결과에 따라 기업의 전략 방향이 결정되고, 프로세스가 바뀌고, 조직 구조가 변경되고,  기술 구조가 확정되며, 몇 백억의 예산이 언제 어떤 식으로 사용될 지가 결정되기 때문에 문구 하나를 갖고 투입된 컨설턴트들끼리 몇 일을 싸우기도 하고, 거버닝 메시지 2줄을 쓰기 위해 몇 시간을 고민하기도 합니다. 매일같이 야근이 이어지고, 주말은 당연히 없고, 폭탄주가 이어지는 독특한 여의도의 회식 문화를 감당해야 하며, 회식 다음 날 중요한 보고를 위해 밤을 세워야 하는 상황도 심심치 않게 찾아옵니다. 가끔씩 중요한 결정을 내려야 할 때는 이해 관계가 얽힌 고객들 사이에서 은근한 협박과 회유에 시달리는 경우도 있구요. 하지만 종료 보고를 마친 회식 자리에서 고객들의 박수를 받고, 술잔을 부딪히며 "보고서가 정말 잘 나왔다. 고맙다. 수고 많았다"는 인사를 들을 때면 더할 나위 없는 보람을 느낄 수 있습니다. 고생을 많이 하는 만큼, 보람도 큰 프로젝트라고나 할까요?

ISP 프로젝트에서 TA는 어떤 일을 해야 하지?

단순한 보람 말고도 ISP 프로젝트 경험을 통해 얻을 수 있는 것이 몇 가지 더 있습니다. 첫번째는 크고 넓게 보는 시야이며, 두번째는 IT 프로젝트의 본질에 대한 통찰력입니다. ISP는 일반적으로 (1) 환경 분석 (2) AS-IS 아키텍처 분석 (3) 비전 및 원칙, 개선 방향성 수립 (4) TO-BE 아키텍처 설계 (5) 차세대 이행과제 도출/상세화 및 추진 로드맵 설계의 5가지 작업 단계로 구성됩니다. 기업이 처한 환경과, 가고자 하는 목표, 전체 비즈니스 구조와 업무 프로세스, 어플리케이션, 데이터, 기술, 조직 구조에 이르기까지 전체를 아울러 보다 보면 자연스럽게 시야가 넓어집니다. EA는 그걸 좀 더 체계적으로 이해하게 하는 도구죠. 또한 비즈니스 목표를 이해하고, 그에 따라 업무, 어플리케이션, 데이터, 기술, 조직을 설계하는 과정에서 정보 기술을 이용해서 만들어지는 시스템, 그 시스템을 구축하기 위한 프로젝트의 본질을 보다 더 잘 이해하게 됩니다. 몇 백억의 투자가 제대로 가치를 발휘하기 위해 정말 중요한게 무엇인지, 각각의 품질 속성들이 왜 필요한지와 같은 것들 말이죠.

그러나, 그런 것들을 얻기 위해서는 많은 노력이 필요합니다. 보통 비즈니스 전문가, 어플리케이션 전문가, 데이터 전문가, 기술 전문가, 조직 전문가 등으로 구성된 7~12명 수준의 컨설팅 팀이 ISP를 진행하는데요, "난 TA(Technical Architect)롤로 들어왔으니까 연계되는 어플리케이션이나 데이터 구조에 대해서만 이해하면 되지"라는 안일한 생각으로는 확장된 시야와 본질에 대한 통찰력이라는 귀한 능력을 키울 수 없습니다. 업무와 조직 특성을 정확히 이해하지 못하고 설계한 아키텍처가 무슨 큰 쓸모가 있겠습니까. 따라서 다른 영역의 산출물을 이해하고, 이슈 해결에 함께 참여하는 적극적인 자세가 필요합니다. 물론 해당 전문가의 영역을 침범해서는 안되는 것이죠. 그렇게 컨설팅 팀 스스로가 EA에서 얘기하는 유기적인 모습을 갖출 때, EA 기반의 ISP 프로젝트도 목표한 산출물을 낼 수 있고, 참여한 개인도 발전할 수 있다는 것을 명심해야 합니다.

ISP의 각 단계에서 TA는 다음과 같은 업무를 수행합니다.

(1) 환경 분석 : 환경 분석 단계에서 TA는 IT 동향 분석을 담당합니다. 제 경우는 금융정보 시스템과 차세대 시스템 구축 동향을 분석하고, 사전에 정의한 기술 영역 별 기술 동향을 파악하며, 특별히 깊게 조사할 필요가 있는 요소 기술을 선별하여 요소 기술 별로 좀 더 깊게 조사하는 작업을 했습니다. 요소 기술은 상품 팩토리나 SOA, 코어뱅킹, ALM, CRM, EDW, MCA, 금융 ERP, 리호스팅, 프레임워크 같은 것들이죠. 각종 선진 사례에 대한 분석도 함께 진행 합니다.

(2) AS-IS 아키텍처 분석 : AS-IS 아키텍처 분석 단계에서는 EA 구분에 따라 기술 아키텍처 영역에 대한 분석을 담당합니다. 관련 자료 수집 및 인터뷰 등의 활동을 통해 주요 Fact를 도출하고, 이해 관계자들과 협의해서 어떤 관점으로 분석할 것인지에 대한 품질 속성을 결정하고, 그 기준에 따라 기술 기반을 진단한 다음, 이슈 사항과 시사점을 도출하는 것으로 단계를 마무리합니다.

(3) 비전 및 원칙, 개선 방향성 수립 : 비전 수립 단계에서는 전체 방향성을 수립할 때 참여하고, EA 원칙 중에서 기술 아키텍처 원칙을 수립하는 역할을 합니다. 산출물은 제일 간단하지만, 제일 고민을 많이 해야 하는 단계죠.

(4) TO-BE 아키텍처 설계 : TO-BE 아키텍처 설계 단계에서는 크게 TRM/SP 정의와 개념/논리/물리 수준의 TO-BE 기술 아키텍처를 수립합니다. 좀 더 풀어서 얘기하자면, 전사 시스템을 식별하고, 각 시스템이 사용할 기술 구조를 결정하고, 인터페이스 방안을 수립하고, 용량을 산정하는 등의 일을 하게 됩니다. 인터페이스 방안, 대외계 구축 방안, 보안, 개발 환경, 24x365 전략, Staging 시스템, 하드웨어 플랫폼 결정, 재해복구시스템 구축 등이 모두 이때 논의되는데, 각 영역 별로 다양한 대안들이 존재하기 때문에 고객들이 선택할 수 있는 대안을 객관적으로 설명하고, 선택을 어려워 할 때 논리적인 근거와 함께 추천 방안을 알려주고, 필요하다면 전체 동의를 얻어내기 위한 교육이나 설득 작업이 진행되기도 합니다.

(5) 차세대 이행과제 도출/상세화 및 추진 로드맵 설계 : 이행과제 도출 및 추진 로드맵 단계에서는 이행 과제 도출에 참여하고, 기술과 관련된 이행 과제를 상세하게 정의하게 되는데, 기술적인 배경과 동향, 구축 목적, 기대 효과, 구축 일정, 소요 예산 등을 과제 별로 정리합니다. 그렇게 도출된 과제들을 모아서 우선 순위를 부여하고, 단계별 추진 전략을 수립하게 되는데 TA는 이 과정에서 솔루션이나 플랫폼 결정과, 구축 비용 조사 등을 위해 솔루션 업체나 벤더들을 만나서 인터뷰하고, 예산을 받아 정리하는 등의 일도 해야 합니다.

이런 과정을 거치고 나면 도출된 TO-BE 모델로 나아가기 위해 업무 프로세스를 개선하기 위한 BPR 프로젝트 등이 이어지고, Pre-PMO 활동을 통해 PoC/BMT/업체선정 등이 이뤄진 다음, 차세대 프로젝트 또는 기업 상황에 따라 시급한 프로젝트를 단계별로 발주하는 정보계 프로젝트, IFRS 프로젝트, 리스크 관리 프로젝트 등의 개별 프로젝트에 대한 RFP가 SI 업체로 날아가게 됩니다. 

이번 글에서는 ISP 프로젝트에서 TA가 수행해야 하는 업무를 전반적으로 정리했는데요, 다음에는 주요 단계 별 업무를 수행하는데 필요한 스킬과 주의 사항 위주로 글을 적어볼까 합니다.[각주:1]

  1. 앞으로 점심 시간을 활용해 글을 정리할 생각인데, 예상보다 15분이나 초과했습니다. 예전의 생산성이 나오지 않네요. 차차 나아지겠죠.. [본문으로]
신고
1 2 3 

글 보관함

카운터

Total : 242,282 / Today : 21 / Yesterday : 13
get rsstistory!