블로그 이미지
그기 아이라 카드만 앱팀장

카테고리

.COM SENSE (139)
TEXT (30)
VIEW (23)
MOVIE (9)
LIFE (9)
SPORTS (5)
ISSUE (8)
SHORT (10)
WORDS (9)
DOCS (8)
KNOWLS (27)
Total
Today
Yesterday

KLAS

TEXT / 2008. 5. 7. 09:29
KLAS independently monitors vendor performance through the active participation of thousands of healthcare organizations. KLAS uses a stringent methodology to ensure all data and ratings are accurate, honest and impartial. Research results are offered to healthcare providers through:


http://www.klasresearch.com/Klas/Site/About/Company.aspx

미국 방문시 문화 충격을 받았던 회사 각 벤더들의 시스템 수준을 조사하여 사용자에게 제공하고
사용자의 정보를 조사하여 벤더에게 제공하는 회사

언젠간 우리나라에도 이런회사들이 생겨나지 않을까? 하는 기대를 가져본다
Posted by 앱팀장
, |

Program Visuality

TEXT / 2008. 3. 21. 13:11
- 작성중
Posted by 앱팀장
, |
무엇인가?
Domain Knowledge
: 일반적으로는 사람또는 컴퓨터 활동의 영역에 미리 선별되는 유효하고 직관적인 지식들을 말한다.
software engineering에서는 시스템 운영의 환경에 대한 지식을 이야기 한다. - wikipedia
즉, 다시말해 software 개발시 개발내용에 대한 업무적인 배경지식이라 이야기 할 수 있다.
Technical Knowledge
: 전공지식을 이야기 하며 software engineering에서는 IT 자체의 지식을 의미한다고 할수 있다.

언제 습득하나?
Domain Knowledge
: 말그대로 엔지니어의 Domain이 정해지면서 부터 습득되기 시작하며 조직 내에서 리더 역할이 커질수록 올라갈것으로 예상된다
Technical Knowledge
: 사람마다 다르긴 하겠지만 그래프를 그린다면 critical point는  아마도 학교를 다니면서 혹은 직장을 다니기 시작하는 때가 아닐까 싶다

왜 생각해야 하나?
습득의 시기가 다르기 때문에 서로간의 balance를 조절할 필요가 있다. 따지고 보면 Technical Knowledge은 습득하여야 하는 것이고 Domain Knowledge는 습득되는 것이기때문에 이해배타적일 가능성을 내제하고 있는 것이다. 허나 분석을 위해서는 Domain Knowledge가 역할을 해야 하며 설계를 위해서는 Technical Knowledge가 역할을 해야 한다. 비중을 어느쪽으로 두느냐에 따라 회사의 색깔을 결정한다고 생각할 수 있겠다.

어떻게 할것인가?
software engineer중 양쪽 다 높은 수준의 밸런스를 가지고 있는 사람이 있을까?습득 시기로 따졌을때 프로그램에 대한 기초가 튼튼한 사람이 꾸준한 기술적인 자기계발을 한 상태로 하나의 업무영역에서 지속적으로 일한 경우에 해당한다 할 수 있겠다. 알다시피 우리나라 엔지니어들은 적당한 나이가 되면 코드작업에서 손을 떼게 되므로 비율로 따졌을때 극소수의 사람만이 달성한다고 생각된다. 하지만 balance를 맞추는 것은 가능하다. 정답은 바로 "신뢰성 협업"이다. 각각의 지식을 가진 사람이 약속된 방법으로 프로젝트를 진행함에 있어 서로의 밸런스를 조절하는 것이다. 그러기 위해서는 일단은 "존중의 미학"이 필요하지 않을까? 아마도 둘은 상생의 관계이며 양립해야할 가치 요소일 것이다.

사용자를 만족시키고 프로그래머들도 만족할 수 있는 프로그램은 존재할 수있는 가능성이 있을 거라 생각한다.
Posted by 앱팀장
, |
사용자 삽입 이미지

CDSS(Clinical Decision Support System)의 고도화가 전체 스테이지를 대변하고 있는듯한 형세
Posted by 앱팀장
, |
사용자 삽입 이미지

프로그래밍 언어의 차원에서는 시간이라는 도메인에 대한 value가 존재하는 것일까요?
C언어의 여전한 강세와 C#의 지속적인 성장이 나타나는 것 같네요.

저는 이런 차트보다는 언어별 개발자 만족도 조사나 언어별 개발자 행복도 조사를 기회가 된다면
한번 연구해보고 싶습니다.

무슨 언어가 당신은 만족시키나요? 혹은 무슨 언어가 당신의 팀에 최적화 되어있나요?
어떤 언어로 개발할때 가장 행복한가요?

왜냐면 다른 분야보다는 소프트웨어분야가 " 사람 = 자원 "이라는 공식이 성립하는 직업이기 때문입니다.

이글을 읽고 계신분들 "어떤 언어로 개발할때 가장 개인의 퍼포먼스를 낼수 있나요? 그리고 그것을 위해
무엇을 하고 있고 당신의 회사에서는 어떤 방법으로 지원하나요?"
Posted by 앱팀장
, |
할말이 특별히 없을때 억지로 화제를 찾아내려고 초조해할 필요는 없다.
그럴 때는 들어주는 쪽을 선택하면 된다.
                                                    - 끌리는 사람은 1%가 다르다

"말을 잘하는 사람 => High Performer
잘 들어주는 사람 => High-Skilled Partner"
의 관계에 대입해보면 즐거운 사무실이 될거라고 생각한다.

좋은 리더에 다수의 상급 서포터...
단지 High Performer의 가치에 대한 우리의 "인식상의 경영"이 없으므로
현실상으로는 불가능해보지만 말이다.

"평범한 사원이 회사를 살린다"라는 책 제목에서 보듯
평범한 사원은 평범한데로 역할이 있다.
IT회사 직원들이여 "High-Skilled Partner"를 선택해보라.
직장에 대한 관점의 변화의 첫발일지도 모른다
Posted by 앱팀장
, |

가벼운 어플리케이션

TEXT / 2008. 3. 4. 22:31
사용자 삽입 이미지
출처: Gartner Research

그림풀이
초기의 어플리케이션은 모든 기능을 가지게끔 구성되었다.
하지만 DBMS가 개발되면서 데이터 운용에 관한 기능들을 데이터베이스에 내어주고
DBAdapter를 이용하여 이를 이용하였다.
하지만 룰엔진이 개발되면서 비지니스 룰이 분리되었으며
프레임워크의 출시로 인해 프로세스도 분리되었다.
그리고 SOA를통해 서비스도 분리되게 되었다.
Posted by 앱팀장
, |

HIMSS 학회 KeyNote

TEXT / 2008. 3. 4. 18:41

사용자 삽입 이미지
                                                                  <HIMSS 학회 등록장 앞에서 회사사람들과 찍은 사진>

현재 의료 시스템은  위기에 처해 있음. 대권싸움에서 의료시스템이 정치적 전망으로 볼떄 2가지 문제를 가지고 있음. Medicare 2019년경에 파산이 될것이고 20년이 지나면 사회보장 제도도 파산이 날것임.차기 정부에서 이슈를 삼아야 함. 연방 소비 지출은 2030년경에 모든 예산을 갉아 먹을 것임. 고령화되고 메디케어 수령자가 늘어나고 일할 사람은 줄어들 것이다 모든 정당은 변화에 대한 요구를 알아야 하며 다른 방안을 가져야 함.  공화당은 의료비용의 감소와 연방 정부의 늘어나는 역할을 조심해야 함. 민주당은 비보험자의  혜택을 확장시켜야 함. 환자 중심의 가치 있는 의료제도를 바탕으로 해야 하며 연방 정부의 역할은 문제 해결자가 아닌 enabler가 되어야 함. 연방 정부가 개혁을 주도하지는 않고 소비자가 개혁을 주도할것이다. 의료 IT전문가들이 의료 시스템의 개혁을 위한 백본이 되어야 하며 IT화의 적용 확장의 장애물은 privacysecurity, 비용 문제라고 언급함. 이 회의에 참석한 모든 전문가의 책임성 중요강조, 미래에는 의료 과학화와 기술에서 의료IT가 기본적인 역할을 하게 될 것 이다.

빌은 정치적인 전망으로 객관적인 접근방안을 제시하였음.

Posted by 앱팀장
, |

Read The Greate Code

TEXT / 2008. 3. 3. 05:23

작가들은 흔히들 질문을 받고는 한다.
"어떤 책이 당신에게 가장 큰 영향을 주었나요?"

우리도 질문을 받아야 한다.
"무슨 방면에 일하고 있나요?" 혹은 "요즘 하는 프로젝트는 무엇인가요?" 대신
"어떤 코드가 당신에게 가장 큰영향을 주었나요?" 라는 질문을 말이다.

명작을 통해 얻을 수 있었던 것은 필자에겐 두가지 정도가 있었던거 같다.
자신의 작품에 대한 모티브을 제공받고 명작이 쓰인 시대상을 벗어나고자 하는 사상을 제공받게 된다.

1. 자신의 작품에 대한 모티브을 제공
 - 나에게 가장 영향을 많이 주었던 코드는 무엇이었을까? 다시 말해 살면서 가장 많이 읽었던 코드는 무엇일까?
라는 질문이 아닐까? 그렇게 보니 역시나 win32를 배우던 시절의 "first.cpp"와 "Socket 프로그램" 코드였던거 같다. 둘다 아직도 코딩중 잘 풀리지 않을때 작은 창을 열어두고는 업무에 열중하는 척하며 연습하는 코드들이다.
 코드를 짜다보면 비지니스단이나 프레임워크단에서 헤메이는 경우가 많다. 하지만 개발툴을 잡고 있는 시간만 길뿐 아무것도 하지 않는 경우가 대부분인데 이럴때 메모장을 열어두고 가장 자신있는 코드를 적어나가다 보면 해결점을 찾아 낼때가 많다. 가장 자신있던 그 시절의 그 코드를 코딩하던 느낌이 살아나기 때문이 아닐까 생각해본다.

2. 시대상을 벗어나고자 하는 사상
회사를 다니면서 3~5년차 선배들에게 가장 많이 듣는 이야기가 있다. 그것은 바로 "현재 시스템은 다 뜯어 고쳐야해"라는 말이다. 시스템주기가 5년이라고들 한다 하지만 운영되고 있는 시스템이 3년이상되면 이미 만료를 바라보고 새로운 시스템에 대한 설계가 준비 되어야 한다. 이럴때 대게는 사용자 불만이나 시스템 결함이 나올때까지 개기고(?) 회사의 여유 정도에 따라 SI를 감행한다. 필자의 생각은 발등에 불이 떨어졌을때 움직이는 것 보다는 미리 SI팀을 모집하고 모집된 인원들의 역할을 분담해주고 역할에 대한 시스템 리뷰를 한후 팀을 새로운 기술교육을 받게 한 후에 SI를 시작하는게 이상적이라 생각한다. 현 시스템의 비지니스 레이어는 유지한채 기술적으로 새로운 접근을 시도 했을때 시스템의 진정한 리뉴얼이 가능하지 않을까?

최근에 리눅스 커널소스를 다시 읽는 경우가 빈번히 생기는 거 같다. 지금은 .NET 계통의 일을 하고 있지만 한때 공부했던 커널소스에 대한 향수병이 일어 주말에 읽던 책을 놓고 코드를 읽고는 감탄사를 토해내고는 한다.

Posted by 앱팀장
, |

기대충족의 비용

TEXT / 2008. 3. 1. 07:04
사용자 삽입 이미지
                                                                                              <2008년 2월 미국출장 주요 활동지>
 - 도입의 작업장
"작년의 화두는 조직이었다. 다름의 답을 찾고 올해의 화두는 소통..  
그런데 그것에 대한 답을 찾으려하니 이제는 자꾸 내게 파고 들게된다.
조금 더 근본을 찾으니 교육이 나오고 조금 더 근본은 환경...

각설하고..
올해의 화두는 소통이다."     - http://adaypuppy.tistory.com

2008년 2월 말 드뎌 미국출장을 다녀오게 되었다.
미국에 대한 기대와 호기심으로 무장한 나에게 있어
"경험지식자원의 룰"을 업그레이드 할 수 있는 좋은 기회가 되었던거 같다.

- 본론의 작업장

"기대충족의 비용"
활자로 치장하고 보니 대단해 보이지만 "소개팅은 잘 될 가능성이 낮다"라는 것과 같은 맥락이다.
출장 동안 미국에 거주하면서 미국인들의 인사법에 대해 놀람을 금하지 않을 수 없었다.

출장 첫날 호텔 앞에 나와 서성 거리고 있으니
미국인 할아버지 한명이 나에게 "Hi, how are you, today?" 라고 말을 걸었다.
다음 사람, 다음 사람, 다음 사람 전부 마찬 가지 였다.
새로운 문화였다. 낯설다(혹은 다르다)가 나쁘다(혹은 무섭다 혹은 부끄럽다)라는 식의 우리나라와는 반대였다.
가벼운 인사로 시작하지만 인사뒤엔 항상 날씨 혹은 자신의 이야기 들로 이어가며 생각의 다리를
사람들 사이에 놓게 되었으며 그를 통해 공통 분모를 쉽게 가질수 있었다.
아시다 시피 공통 분모를 가지게 되는 순간 부터는 일명 "친한 사람"인 것이다.

결론부터 말해서 "이야기하는데 돈 드는게 아니니 그냥 이야기 하자"라는 것이었다.
쉽게 인사를 나누고 쉽게 이야기하고 쉽게 전문 지식을 나눌 수 있는 기대충족의 비용이 낮은 미국인들이었다.

우리는 어떤가? 학교나 직장을 다니면서 "이것 밖에 못해?", "열심히해", "다음엔 더 잘해"라는 이야기를
제외하고는 재미를 위한 경우들이 많다. 그러한 교육적 환경때문에 아이들은 항상 사람들의 기대를 충족해야
한다는 강박관념을 가진채 살아가다 어른이 되어서 상대방이 가진 기대를 충족하기 위해서
과도한 행동이나 말투를 가지게 되는 것 같다.

그러나 커뮤니케이션의 양이 충분치 못하기 때문에 기대치에 대해 마음속으로 산정을 해야하고
그러한 것에 대해 상대방에게 물어보는 것 자체가 부끄러운 이이기 때문에 상상력에 의존해
접근할 수 밖에 없다. 그러나 상상력이라는게 생각보다 과도한게 사실이다.
그래서 사람들은 무리해서 행동하고 기대치를 충족 못할때는 실망하고 상대방이 나에게
실망감을 가질까봐 걱정하게 되는 모양이다.

- 필자의 가설
소통의 기본은 경계를 없애는 것이다. 최적의 타이밍에 경계를 최소화 하는 기회를 만들었을때
비로소 낮은 비용의 커뮤니케이션이 발생하며 기대충족의 비용 또한 감소한다


Posted by 앱팀장
, |

최근에 달린 댓글

글 보관함