본문 바로가기

기획107

아키텍트 이야기 독서 후기 아키텍트 이야기 - 야마모토 케이지 지음, 이지연 옮김, 이용원 외 감수/인사이트 이 책을 읽으면서도 아키텍트의 역할이 무엇인지 잘 납득이 가지 않았다. 그만큼 우리네 IT 프로젝트에서 PM(프로젝트 관리자)이 중구난방으로 하는 일이 많다고 본다. 3장을 넘겨 보면서도 '이런 거 PM 단에서 다했는데.'라는 생각이 머릿속에서 떠나질 않았다. 그러다 SAP의 BC를 떠올려 보니 아키텍트가 어떤 존재인지 대략 감이 잡혔다. SAP의 BC(Basis Component)라는 직무(모듈)는 SAP ERP, BI 등의 서버와 DB 등의 기반 구축을 담당한다. SAP 프로젝트만큼은 우리나라의 다른 프로젝트와는 달리 PM이 아닌 BC가 기술 환경, 그러니까 아키텍처 구축을 주도하는 편이다. 그렇다 하더라도 SAP 환경.. 2008. 9. 9.

이뻐 죽겠네 한메일 사용자로 자잘한 파일 몇 개를 회사로 가져 갈 일이 생겨 메일로 날렸다. 아뿔싸! 보낼 때 귀찮아서 파일들을 압축하지 않고 그냥 블록 지정해서 올렸는데 받으려고 보니 일일이 클릭해서 받아야 했기 때문이다. 하지만 이런 건 옛날 얘기. 메뉴를 자세히 보니 '모두 저장'이라는 버튼이 있었다. 눌렀더니 한메일 서버에서 알아서 압축한 후에 내려 준다. 기획자와 개발자가 누굴까? 하마터면 몇십 번을 클릭할 뻔했는데 그저 고마울 뿐이다. 이런 걸 보니 웹 메일이 아웃룩의 편리함이라는 아성을 무너뜨릴 날도 머지 않은 듯하다. *** 한메일 담당자가 혹시라도 보신다면, 나중에 여건 되실 때 체크 박스 인터페이스를 추가해 주시는 것도 좋겠습니다. 2008. 8. 25.

회손녀 사태로 보는 보안 위협 회손녀 사태는 언급하기에 깔끔한 사례가 아니지만 보안 위협이라는 관점을 놓고 봤을 때 시사점이 있어서 글을 올립니다. 회손녀가 '크래커'들에게 당당하게 나섰음에도 크래커들의 공격 성과가 시원찮았던 이유는 회손녀에 대한 정보가 극히 적었기 때문입니다. 회손녀의 개인정보를 캐고 싶었던 크래커들도 싸이월드 미니홈피에 나타나는 실명과 생년만으로는 할 만한 게 적었지요. 기업의 보안도 마찬가지입니다. 외부로 시스템 내부의 정보를 내보이는 걸 막아야 합니다. 그런데 꽤 많은 웹사이트들이 각종 에러 메시지들을 통해 시스템 정보를 외부에 노출 시키는 게 현실입니다. 시스템 관리자에게 충분한 시간을 주거나 프로젝트를 만들어서 노출된 부분을 전부 닫는 게 좋습니다. 회손녀의 첫 번째 실수는 친구들을 공개했다는 것입니다. .. 2008. 8. 18.

프리젠테이션 젠 독서 후기와 slideshare 경연 참가작 공개 프리젠테이션 젠 - 가르 레이놀즈 지음, 정순욱 옮김/에이콘출판 에이콘 출판사의 '프리젠테이션 젠' 출간 이벤트에 당첨되어 읽은지 꽤 됐는데 이제서야 후기를 올립니다. 그간의 명성을 들었기에 파워포인트 사용법이 없어도 당황하지 않았죠. ^^ 이 책은 MS Word와 PowerPoint를 진정 구분하지 못했다면 꼭 봐야 합니다. 기본적인 마음가짐부터 잡아 주는 만큼 그간 접해 왔던 파워포인트 설명서는 잠시 접어 두고 프리젠테이션의 도를 깨우치기 위해 산을 오르는 심정으로 읽는 게 좋겠습니다. 다행히도 이 책의 저자인 가르 레이놀즈 선생은 밥 짓고 나무 하기를 시키지 않기 때문에 생각보다 쉽게 도에 접근할 수 있습니다. 다만 너무 쉽기 때문에 '이건 우리나라와 안 맞아.'라며 쉽게 단정 짓게 하지는 않을까 .. 2008. 8. 1.

전산 서비스의 지속성 유지 제목이 어렵기는 한데 요지는 어떻게 하면 전산 서비스를 끊기지 않고 계속 제공하는가에 대한 얘기입니다. 혼동하시면 안되요. 전산 '시스템'을 끊기지 않게 하는 게 아니라 '서비스'를 끊기지 않게 하는 겁니다. 보통 쓰는 방법이 미러링이니 클러스터링이니 해서 예비 서버를 더 두는 겁니다. 그러니까 성능 문제로 서버를 하나 더 두는 것이 아닌 혹시 몰라서 한 대를 더 두는 것이지요. 물론 요즘은 기술과 기법이 많이 발달해서 예비 서버도 놀리지 않고 씁니다. 최초에 돈이 좀 더 들기는 하지만요. 문제는 경영진의 이해도입니다. 애초에 설명이 잘 됐으면 모르겠지만 대부분은 서비스 지속성에 돈을 들여야 하는 이유를 모릅니다. 그러면서 주장하지요. 시스템에 결함이 없으면 될 거 아니냐? 결함만 고치면 끊기는 일은 없.. 2008. 5. 30.

보안 이전에 보안 의식 얼마 전까지 IT 기획 업무를 해서 DRM(전자 문서 보안) 벤치마킹을 다닌 적이 있었다. 그 때 나왔던 얘기 중 하나가 당연히 중요한 도면이 많을 조선업체 몇 군데에 제안을 했는데 전혀 필요 없다는 답변만 들었다는 영업사원의 경험담이었다. 이유는 반 정도 수긍이 갔다. 중국 경쟁업체에 도면이 노출되도 그들에게 구현할 능력이 없단다. 효율을 따지자면 굳이 DRM을 도입할 필요가 없다는 결론이다. 굳이 싫은 소리 하기 싫어서 따지지 않았는데 참 헛점 많은 논리였다. 물론 중국 조선업체의 기술력 부족은 사실이겠지만 필요한 도면을 수시로 본다면 발전 가속도는 크게 증가하는 게 당연하지 않은가. 10년 차이를 5년으로만 줄여도 매출의 차이, 시장 점유율의 차이는 급속도로 줄어든다. 당장은 생산 능력 이상의 주문.. 2008. 5. 19.

생산성 극대화라는 개념의 발전 비주얼 베이직은 C++이나 C#에 비교 당하며 비웃음 당하곤 했던 적이 있습니다. 비주얼 베이직으로 3D 게임을 만들지 못한다는 태생적인 약점 외에도 C 포인터에 능숙한 개발자들에게 특유의 메모리 관리 같은 답답함(?)은 제약으로 느껴지기도 했을 것입니다. SAP에서 만드는 패키지 솔루션의 기본 언어인 ABAP은 비주얼 베이직보다 더합니다. 이 녀석은 배열 조차 없습니다. 메모리에 임시 테이블을 만들어 loop를 돌리는 게 일반적이지요. 아시다시피 이 두 언어는 생산성 극대화라는 목적에 충실합니다. 덜 빠르더라도 덜 이쁘더라도 기본을 갖춘 개발자들이 납득할 만한 성능과 UI로 비즈니스 요구를 충족하는 업무 어플리케이션을 뚝딱뚝딱 만들고 시연하고 고치는 게 가능합니다. 인터넷이 아닌 인트라넷을 염두에 두는.. 2008. 4. 25.

ERP와 인력 감축 ERP 구축 같은 대형 프로젝트는 ROI를 세세히 따지기 마련입니다. 그러나 ERP 같은 밑단 작업의 ROI를 산출하기란 쉽지 않지요. 그러다 보니 꽤 많은 제안 및 컨설팅 업체에서는 별 수 없이 투자 효과로 인력 감축을 드는 편입니다. 몇 사람 줄이는 게 가능하니 연간 얼마 이익이라는 얘기입니다. 다행히 경영진도 바보는 아니라 곧이곧대로 듣고 컨설팅에서 제시한 수만큼 자르려 하지는 않지만 꽤 많이 자르고 싶은 유혹은 상당히 받는 듯 합니다. 만약 경영진이 이때다 싶어서 ERP를 핑계로 최대한 사람들을 잘라 버리면 그 해악의 피해는 고스란히 고객이 받습니다. 대개 핑계 김에 사람을 자를 때에는 ERP에서 효율을 내는지 여부에 대한 기준보다는 정치력에 좌우되는 때가 많기 때문입니다. ERP의 한국형 변태 .. 2008. 3. 25.

ROI에 관한 상념 한반도 대운하를 반대하는 입장입니다. 대운하를 찬성한다는 자칭 전문가들 말에 의하면 우리 기술이라면 못 할 게 없다는 식인데, 한 마디로 전문가 자격이 없다고 하겠습니다. 조령터널이든 무슨 엘리베이터든 결국 만들 수야 있겠죠. 문제는 ROI(Return of Investment, 투자 대비 수익률)입니다. 상식적으로 생각하면 됩니다. 10억 들여서 1억을 버는 게 낫겠습니까? 100억 들여서 2억 버는 게 낫겠습니까? 어려운 개념이 아닙니다. 대운하 만드는 데 들일 돈이면 경부고속도로를 복층으로 짓든지 철도선을 이중화(?)하든지 하는 일들을 하고도 남습니다. 자기들도 민망한지 관광 수입을 얘기하는데요. 이것도 말이 안되요. 경인운하 공사 현장. 평지에 가까워도 이런 판국에 산으로 가는 운하는 어떨까요. .. 2008. 2. 14.

메뉴 인터페이스로서의 플래시 몇십 명이 사용할 인트라넷 서비스를 만들 때도 이쁜 걸 좋아하기 마련인 현업 사용자의 요구에 의해 플래시로 메뉴를 만들 때가 있습니다. 그림을 움직이게 하고 링크를 걸지요. 제가 있는 회사에는 업무 특성 상 시각 장애인 사원이 없기 때문에 마우스 클릭 이벤트 설정으로 끝내면 충분합니다. 하지만 인터넷 서비스는 절대 이렇게 만들어서는 안 된다고 봅니다. 플래시 메뉴라면 특히 시각 장애인에 대한 배려가 필요합니다. 다행히 Adobe 사는 플래시 메뉴라도 키보드로 제어하거나 스크린 리더 프로그램이 인식하는 통로를 만들어 둔 것으로 압니다. 하지만 국내 인터넷 서비스 사이트에서 이런 부분에 신경 쓰는 모습은 거의 보지 못했습니다. 노력이 많이 드니까요. 경제 논리(?)에 의해 시각 장애인은 메뉴는 물론 배너 광.. 2007. 10. 29.

10/20/30 규칙과 친숙함 10장의 슬라이드를 20분 동안 발표 하되 30px로 글씨 크기를 유지하라 요즘 예산철이라 PPT만 줄창 만집니다. 그러다 보니 PT 자료 작성에 대한 여러 경구들이 다시금 머리 속을 휘젓네요. 위의 10/20/30 규칙은 가이 가와사키의 PT에서 처음 본 제언입니다. (저로서는) 상당히 인상 깊었습니다. 워드와 프리젠테이션을 제대로 구분 못 하던 시절에 봐서 더욱 그랬을 것입니다. 그런데 제가 사는 세상은 그걸 받아들이지 못하더군요. 제가 요점을 콕콕 집어내지 못해서이겠습니다만. 다행히 PT에 대한 여러 상식들이 많이 퍼진 관계로 10/20/30 규칙 중 10/20은 모두가 받아들이는 듯 합니다. 하지만 12 포인트를 자주 써야 하는 상황은 변하지 않았습니다. 무슨 광고회사 PT가 아닌 이상은 슬라이드.. 2007. 10. 9.

기업 블로그의 실수 완충 방법 기업이 자기 이름을 걸고 블로그를 운영하는 건 번거로운 일입니다. 블로그의 특성 상, 개인 블로거만큼은 아닐지라도 기업 관련 이슈가 있을 때 잽싸게 동참해야 합니다. 만약 3 ~ 4단계의 결재를 거치다 보면 관련 이슈는 기업의 의사와는 상관 없이 발전할 것입니다. 그렇다고 빨리 빨리 이슈에 동참하다 보면 실수할 수도 있는데 이 또한 기업이 바라는 바가 아닐 겁니다. 기업 관련 이슈에 재빨리 동참하면서 실수에 대한 수습을 할 수 있는 방법은 이미 통용되고 있는 게 몇 개 있습니다. 기업 블로그가 아직은 생소한 이 시점에도 말이죠. 첫째는 당연한 얘기지만, 결재 과정을 없애고 홍보팀이나 관련 부서에서 마감 시한을 정하고 후닥닥 브레인스토밍하여 수위를 조정하는 겁니다. 머리가 여러 개면 실수도 적겠지요. 둘째.. 2007. 6. 30.

제한 받는 소비자는 미련하다 정확히 표현하자면, 제한 받는 소비자는 미련할 수 밖에 없습니다. 네이버에서 '부동산 버블'을 입력하는 절대 다수의 평범한 사용자는 MS 인터넷 익스플로러를 잘 쓰고 있습니다. 탭 브라우징 같은 복잡한 것(^^)도 잘 모릅니다. 이런 상황은 결코 나쁜 게 아닙니다. 이해를 돕기 위해 다른 얘기부터 해야겠네요. 작고 경제적인 자동차 티코를 샀다 칩시다. 동사무소 가는 거나 은행 가는 거나 불편이 없습니다. 그런데 살다 보니 짐을 좀 실을 필요가 있어서 SUV인 소렌토를 샀습니다. 그런데 소렌토를 몰고 동사무소나 은행을 들어갈 수가 없었습니다. 주차장으로 들어가는 길이 너무 좁았기 때문입니다. 그런데 카페리를 타고 일본에 갔는데 못 가는 데가 없었다고 치죠. 이런 경우 소렌토가 잘못 된 건가요? 우리나라 정.. 2007. 5. 20.

기업 블로그 = 기업 아바타 기업이 블로그를 활용하는 방법은 내부적으로는 지식/정보 축적을 들 수 있고 외부적으로는 마케팅/홍보를 들 수 있다고 봅니다. 서양 기업에서는 블로그 붐이 일었는지, Sun 같은 회사는 거의 모든 직원이 블로그를 갖고 있고 MS의 SharePoint 제품군에서는 사내에 블로그 생성을 할 수 있게 지원하고 있습니다. 더불어 직원들에게 블로그 작성 지침을 내려서 혹시 모를 사고를 방지하고 있습니다. 무조건 막는 것이 아닌 긍정적인 활용을 기대하는 것이지요. 국내에서 내부적인 지식/정보 축적 목적으로 블로그를 운영하자는 공감대가 형성되려면 시간이 많이 필요하겠지만 외부적인 활용은 검토하는 기업이 이미 많다고 봅니다. 특히 B2C 기업이라면 생각을 하고 있을 겁니다.이미 싸이월드 미니홈피나 블로그를 운영하는 사례.. 2007. 5. 16.

관리자 권한 부여의 남발 관리자 권한을 적절히 나누는 것은 무척 중요한 일입니다. 업무 효율과 보안의 두 마리 토끼를 모두 잡아야 하니까요. 업무 속도를 중시해서 관리자 권한을 일임하고 중복 분배하면 온갖 폐혜가 다 생깁니다. 쇼핑몰 같은 웹 사이트라면 고객 정보를 누군가가 몇십만 원 받고 팔아넘겨도 알 수 없는 노릇이고요. 보통 기업이라면 내부의 기밀 정보를 유출당할 수 있다는 얘기입니다. 악의를 가진 관리자의 창의성에 따라 해악의 파급도가 달라집니다. 그렇다면 왜 관리자 권한을 여럿이 갖고 있을까요? 첫 번째로는 보안 의식 수준이 낮아서 그렇고 두 번째로는 빨리빨리 문화 때문입니다. 완성도보다는 속도를 중시하는 문화말입니다. 서구의 예를 들자면 우리나라와 반대입니다. 계정 생성/관리 업무 등 관리자의 업무에 보안을 중시하다 .. 2007. 5. 13.

고객의 소리를 넘으려면 (2) 지난 번 포스트 고객의 소리를 넘으려면 (1)을 쓴지 시일이 꽤 지났습니다. 애초에 속으로는 결론을 낸 상태에서 1, 2부로 나눈 것이라 금방 쓸 수도 있었지만 왠지 주저되어 차일피일 미루고 있었습니다. '노인네'라면 뒷방 신세여야 한다고 생각하는 게 큰 문제 "Another satisfied customer!" --Allan 출처: http://flickr.com/photos/strph/92448337/ 고객이 공식적인 VOC 외에 Under the VOC를 말하는 일은 앞으로도 없을 겁니다. Under를 under로 만든 사람들이 자발적으로 공식화 하기를 바라는 건 합당치 못합니다. 특히나 기업 고객(전산실 이라면 현업)은 자신의 성과 평가에 얽힌 것이기 때문에 더더욱 숨길 수 밖에 없습니다. 공식적.. 2007. 3. 28.

고객의 소리를 넘으려면 (1) 양군 블로그: 고객의 소리(VOC)를 넘어서~ http://yjhyjh.egloos.com/956401 위 글을 읽고 느낀 게 많았습니다. 현업의 말에 귀를 기울이면서도 때로는 현업을 이끌어 나가야 함을 머리로는 아는데 실제 상황에 맞닥뜨리면 양 갈래 길에서 어떻게 해야 할지 갈피를 잡을 수 없었던 때가 있었거든요. 저걸 그냥 들어주면 몸이 편하고 책임질 일도 없겠지만 그렇게 해서는 안 될 것 같은데 마땅히 제시할 의견이 없는 그런 상황을 아시는 분은 아실 겁니다. 위 글은 그런 상황에 대한 적절한 분석을 제시해 주었습니다. 1. VOC: 고객이 공식적으로 말하는 요구사항 2. Under the VOC: 고객이 당연하다고 생각하거나 귀찮거나 불리하다고 생각해서 직접적으로 말하지 않는 요구사항 3. Ove.. 2007. 3. 28.

이전 1 ··· 3 4 5 6 다음

티스토리툴바