본문 바로가기

전체 글

 (338)
사례로 보는「MDA 도입의 장단점」 새로운 IT 패러다임이 등장할 때마다 현기증을 느낀다. 특히 소프트웨어 개발 업계에 막 입문한 사람보다는 나름대로 경험과 노하우를 가지고 있고 실질적으로 새로운 작업을 추진할 만한 위치에 있는 엔지니어일수록 그런 현상이 더욱 심한 것 같다. 국내의 가장 전형적인 SI 업체의 R&D 팀에 소속된 필자의 경우도 꼭 그런 상황이다. 이 글에서는 최근 이슈가 되고 있는 MDA를 필자가 속한 회사가 전문 개발 영역인 ‘인사관리 업무’ 도메인에 도입해, 그것을 조직의 소프트웨어 개발 생산성 향상으로 접목시키려고 노력하고 있는 과정에서 겪었던 그리고 앞으로 겪을 것으로 예상되는 문제점들과 그 해결 방안을 담담히 정리해 본 것이다. 현재 필자가 근무하는 회사에서는 지난 2003년을 전후해서 제대로 만들어진 컴포넌트든 ..
UML은 무엇을 위해 있는 것일까? 내가 UML을 처음으로 본 것은 1999년, 자바 프로그래밍을 시작했던 시기였다. 당시는 아직 별로 보급돼 있지 않았고,「UML이란 무엇인가」「무엇을 위해서 사용하는가」「방법을 잘 모르는 채 우선 사용하는 것은 아닌가」라는 의문이 있는 정도에 지나지 않았다. OMG(Object Management Group: 객체 지향 기술의 표준화를 행하는 단체)가 정식으로 UML을 인정하고 나서 약 10년이 된 최근에는 시스템 개발에 종사하는 사람 중에서 ML이라는 말을 들은 적이 없다는 사람은 거의 없는 게 아닐까. 실제로 개발 현장에서 UML 자체를 설명해야 하는 경우는 거의 사라졌고, 사용할 수 없어도 읽을 수 있다는 사람은 꽤 늘어난 것으로 생각한다. SNS나 웹 2.0과 같이 시스템 업계와 관련 없는 사람이..
주목받는 SW 개발방법론「비교 분석」 소프트웨어 발전 방향을 미리 예견하기는 무모하거나 용감한 작업이 될 수 있다. 선배의 말을 빌리자면 차세대 채택되는 패러다임을 예측하기란 현재 학계나 커뮤니티에서 논의되고 있는 패러다임을 제비로 접어서 통에 넣어 흔든 후 하나를 뽑는 것과 같다고 한다. 그만큼 장담하기 힘들고 어려운 부분이다. 하지만 그것은 학계에서 발표되는 패러다임 101 버전의 얘기이지(이번 특집의 주제인 MDA만 하더라도 3년 전에 발표된 내용이다). 실제 산업에서 사용할 수 있는 수준의 차세대 패러다임을 점친다는 것은 메이저 벤더들의 제품 비전만 보더라도 쉽게 알 수 있다(대형 밴더들이 그런 고민은 다 해준다). 물론 ‘시장에서 채택될 것인가?' 하는 아주 복잡하고 우연적인 변수를 제거했을 때 말이다. 또 다른 방법이 있다 약간의..
소프트웨어 개발 방법론 충격진화「MDA」 우리가 현재 살고 있는 산업사회에 있어서 가장 중요한 것은 무엇인가? 혹자는 믿음이라고 답할 것이고, 혹자는 밥이라고 답할 것이며, 어떤 사람은 그저 애니메이션이나 실컷 보면서 살 수 있으면 그만이라고 말할 것이다. 무엇이 되었든 개인에게 있어서 틀린 답은 아니겠으나 산업사회의 발전을 위해서 가장 중요한 사회학적인 요인을 하나만 선택하라고 하면 그것은 곧 ‘생산성(productivity)’이 될 것이다. 소위 우리가 말하는 ‘산업혁명’이라는 것도 기실은 생산성의 폭발적인 증대로 귀결될 수 있다. 소프트웨어를 개발하는 입장에서도 이 생산성의 문제는 무척이나 중요하다. 같은 수준의 완성품을 만드는 데 있어서 가능하면 적은 시간과 적은 노동력과 원자재만을 이용하는 방법을 연구하는 것은 그런 측면에서 커다란 의..
[UML 제대로 알기] ⑤ 표준 넘나드는 UML의「적절한 사용」 UML은 표준 표기법으로써 그 자리를 확고히 했다. 이제는 한 걸음 더 나아가 UML을 보다 효과적으로 사용할 수 있는 방법을 생각해 볼 때이다. 음계를 이용하여 아름다운 음악을 작곡하듯이 UML을 이용하여 좋은 소프트웨어를 개발하는, 이른바 UML 사용의 베스트 프렉티스를 생각해야 한다. 간혹 베스트 프렉티스가 UML 표준을 준수하지 않는 경우도 있는데 중요한 것은 표준 준수 여부가 아니라 어느 것이 더 효과적이냐는 것이다. 성공적인 소프트웨어 개발을 위해서라면 표준을 넘나들 수도 있어야 한다. 이에 이번 글에는 유즈 케이스를 중심으로 UML을 잘 표현하기 위한 시맨틱을 제대로 정리하고 사용하는 방법에 대한 고찰해 보겠다. * UML에서 유스케이스는 액터, 유스케이스, 유스케이스 다이어그램 등을 모두 ..
[UML 제대로 알기] ④ 닷넷 환경 UML 툴 활용 가이드 케이스 도구는 양날의 검이다. 활용도에 따라서 소프트웨어를 죽일 수 도 있다. 래쇼날 로즈(이하 로즈) 같은 케이스 도구는 능숙하게 다룰 수 있어야 되기까지 많은 학습 곡선을 필요로 한다. 능숙해진 다음에도 여전히 불편하다. 하지만 IDE와 통합된 케이스 도구는 코드의 자동 생성 등의 많은 편리한 도구를 제공한다. IDE와 통합된 케이스 도구는 UML이라는 것에 너무 얽매이지만 않고 자유롭게만 사용한다면 아주 훌륭한 프로젝트 도우미가 될 수 있다. 전통적으로 MS의 개발 플랫폼에서 사용하는 개발 도구는 MS가 100% 독점하다시피 해 왔다. STL이나 MFC를 개발하거나 사용하는 도구는 거의 비주얼 C++가 독점적이었고, COM 기반의 개발을 위해 사용되는 도구는 거의가 비주얼 베이직이었다(COM 개발을..
[UML 제대로 알기] ③ 개발 프로세스에 따른 UML 실전 모델링 UML과 개발 프로세스라는 것이 만나게 되면 각 프로세스 별로 UML을 활용하여 모델링을 하는 방법이 약간씩 달라지기 때문에 사용상 주의가 필요하게 된다. 이와 더불어 웹 애플리케이션 개발을 위한 UML 모델링은 어떻게 하면 좋은지에 대해서도 생각해볼 필요가 있다. 이번 글에서는 지금까지 UML을 이용하여 소프트웨어 개발을 수행하면서 느꼈던 개념상의 모호함과 모델링 시 주의할 점에 대해 살펴보고자 한다. 약 7년 전 필자는 UML에 관하여 세미나를 하려고 어느 업체를 방문한 적이 있었다. 세미나를 막 시작하려고 하는 순간 어느 분께서 'UML이 이번에 새로 나온 XML의 한 종류인가 보죠?'라고 질문을 했다. 과연 이 난관을 어떻게 헤쳐 나가야 할지 막막한 순간이 UML에 관한 이야기를 하려고 하면 지금..
[UML 제대로 알기] ② 초보자를 위해 다각도로 살펴본 UML 7년 전 필자는 UML이라는 단어조차 들어본 적 없었다. 국내에서는 그래도 꽤 잘하는 비주얼 베이직 프로그래머라고 자부했는데 당시 봇물같이 쏟아지던 약어들에 질려 UML이라는 알파벳 세 글자로 이루어진 '신규어'에 별 신경을 쓰지 않았다. 몇 년이 지난 후, 필자도 객체지향이라는 무림 강호에 몸을 던지지 않을 수 없는 시점에 이르러서, 그 몇 년 전에 들었던 UML이라는 것이 무림에 출사표를 던지기 위한 필수 무공이었다는 사실을 깨달았다. 그리고 그 이름도 원망스러운 디자인 패턴! 비주얼 베이직이라는 한물간 초식에서는 ‘꽤’ 강자라고 생각했던 필자는 객체지향이라는 드넓은 무림에 발을 들여서는 초고수가 되어야 되겠다는 결심을 했고, 높은 내공을 쌓기 위한 필수 비급이라는 UML과 디자인 패턴을 익히기 시작..

티스토리툴바