티스토리

글쓰는 프로그래머

검색하기

블로그 홈

글쓰는 프로그래머

swarchi.tistory.com/m

글쓰는 프로그래머

구독자: 0

방명록 방문하기

주요 글 목록

소프트웨어 설계가 완벽할 수 없는 다섯 가지 이유 소프트웨어 설계란 개발을 위한 초석이며, 설계자가 고객 또는 개발자와 커뮤니케이션하기 위한 도구이다. 소프트웨어 설계는 분명 다른 공학의 설계와는 다른 특성을 갖고 있으며 소프트웨어 설계는 다음의 몇 가지 이유 등으로 인해 완벽할 수 없다. 첫째, 소프트웨어 설계는 일반 공학의 설계가 아닌 시나리오다. 일반 공학, 예를 들어 건축공학에서, 건축 설계의 최종 목적물은 건축물에 대한 스틸 사진이다. 그러나 소프트웨어 설계의 최종 목적물은 시간의 흐름에 따라 혹은 외부의 이벤트에 어떤 행위 즉 기능을 해야 하는 지를 계획하는 것이다. 이 점에서 오히려 영화의 시나리오에 가깝다. 이것은 소프트웨어 설계를 위해 흔히 사용하는 UML이 영화 시나리오를 도식화하기 위해 꽤나 적합하다는 것에서도 알 수 있다. 거꾸로 .. 공감수 26 댓글수 39 2020. 10. 15.
프로젝트 M을 논하다 – 1. 들어가며 당신에겐 하찮아 보일지 모르는 이 프로그램을 만들기 위해, 우린 수많은 시간을 치열하게 일해야 했습니다. - 이채성 목차 1. 들어가며 2. 프로젝트 M은 어떤 녀석인가? 3. 프로젝트 M, 왜 힘들었나? 4. 프로세스 M을 다시 한다면 들어가며 이 글은 M 프로젝트를 겪으면서 보고 느꼈던 것에 대한 개인적으로 정리한 글이다. 결코 누구의 잘잘못을 가리기 보다는 이러한 프로젝트를 통해 겪은 내용을 함께 함으로써 또 다른 M 프로젝트에 다소 나마 도움을 주기 위함이다. M 프로젝트에 처음엔 프로젝트 PMO로 프로젝트에 참여했다가, 프로젝트가 어느 순간 무너지면서 본사 담당 Sub-PM, WAS 서버 관리자, Java 개발자로서 생활했다. 내용은 프로젝트를 관리하는 입장에서 서술되었으며, 최대한 객관적으로 .. 공감수 3 댓글수 9 2019. 2. 22.
NetZ 이야기 - 1. 1999년 7월 序 NetZ는 98년부터 2003년까지 개발했던 작은 프로그램이다. 이 이야기는 NetZ를 개발하면서 그리고 개발한 후에 겪어야 했던 일들에 대한 기억의 편린이다. 이제는 말할 수 있다? ㅎㅎ 그래, 10여 년의 세월이 지나서, 이제는 아무런 감정의 기복없이 담담히 나를 회상할 수 있을 때가 되어, 그 때에 있었던 일들을 어디엔가 남기고 싶었다. 지금은 비록 프로그램 개발보단 무슨 무슨 계획서를 작성하느라 세월을 보내고 있지만 내게도 프로그래머로 한 칼이 있던 시기가 있었다. 그 때를 추억한다. 2011.11.07 1999년 7월 "MIS지원팀 이채성입니다" "이채성씨죠?" "예. 전데요" "여긴 본사 경영기획팀인데요. 이채성씨가 AutoAuto라는 프로그램을 개발했나요?" "예." "여권이 있나요?" .. 공감수 4 댓글수 5 2019. 2. 19.
최저 비용으로 기업 내 커뮤니케이션 활성화 하기 조직 내 커뮤니케이션 활성화란 명목으로 기업용 SNS 를 도입하거나 이런저런 많은 것을 만든다. 하지만 기업의 커뮤니케이션의 활성화는 단순히 IT시스템의 도입으로 되지 않으며 결국 그러한 것을 사용하는 조직의 문화가 커뮤니케이션의 활성화를 좌지우지 한다. 진정 커뮤니케이션 활성화를 원한다면, CEO스스로가 바뀌어야 한다. CEO 스스로가 듣고 싶은 말만 듣기를 원한다면 커뮤니케이션 활성화를 위해서 IT적으로 아무리 많은 투자를 한다고 하더라도 진정한 커뮤니케이션이 되지 않는다. CEO는 직원들이 어떤 생각을 하고 있는지 알고 싶어하면서도 막상 그것이 본인의 생각과 반하는 생각이라면 귀를 막고서 듣지 않고자 한다. 이런 이중적인 모습에 직원들은 쉽사리 실망하고 만다. 회사에 대한 비방적인 글이 올라왔다고 .. 공감수 5 댓글수 1 2019. 2. 19.
NetZ 이야기 – 2. NetZ 개발하기 NetZ 개발하기 NetZ. 지금 생각해도 뭔가 애틋한 느낌으로 떠오르는 이름이다. NetZ는 개인형 웹 에이전트 프로그램이다. 신문 뉴스도 보여주고, 그룹웨어도 연결하고, 간단한 메시지도 전달했던. 개발을 시작했던 게 98년 2월. 내 나이 28에 시작했던 프로그램이었다. IMF가 시작된 지 얼마 안되어서 회사와 관련된 중요한 뉴스에 관심을 갖고서 하루에도 몇 번씩이나 인터넷을 뒤지면서 뉴스 기사에 관심을 갖던 시기였다. 하루는, 맨날 이렇게 찾아가면서 볼게 아니라 작업표시줄에 표시될 수 있으면 좋겠다는 생각을 했다. 당시엔 push 기술이 유행하던 시기였다. Marimba & Tango 뭐 이런 솔루션이 있었고, push 기술을 통해 화면보호기를 통해서 뉴스 등의 정보들을 보여주던 프로그램이 유행했다.. 공감수 3 댓글수 0 2010. 11. 7.
NetZ 이야기 – 3. 프로그램의 가치 프로그램의 가치 프로그램 소스를 보내라는 얘기를 무시하고 1주일인가를 버텼더니 서울에서 다시 전화가 왔다. 왜 소스를 안 보내냐고. "제가 회사에 속해 있긴 하지만 이 프로그램은 제가 개인적으로 만든 건데 프로그램의 저작권이라는 것이 회사 소유라는 게 도저히 납득이 가지 않아서요." "그럼 어쩌면 좋겠어요?" "만약 프로그램을 회사차원에서 쓰고자 하신다면 제게서 프로그램을 사 주세요" 전화기 넘어 황당하다는 듯한 표정이 보이는 듯 했다. 그다지 유쾌하지 않은 얘기가 좀 오래 계속 되었다. 결국엔 프로그램을 얼마로 생각하느냐? 란 질문에 "그건 생각하고서 다시 말씀 드리죠" 라는 답변과 함께 전화를 끊었다. 한번도 생각해 보지 않았던 프로그램 대가에 대해서 고민을 시작했다. 지금은 FP로 많이 측정을 하고.. 공감수 1 댓글수 0 2010. 11. 7.
NetZ 이야기 – 4. 사장님 보고 사장님 보고 추석을 보내고 10월이 되었다. 프로젝트가 이제 막바지였다. 팀 별로 배부된 경비금액이 안 맞아서 끝까지 고생을 했다. DW에 대한 기술지원을 하러 왔던 강대리가 "Dataware-Housing에 ing가 괜히 붙는 게 아녜요. 끝이 없거든요." 정말 끝까지 데이터 크린징 때문에 고생을 해야 했다. 내 다시는 DW 프로젝트 하나 봐라. 데이터 ETT툴에다가 썼다. '제발 다시는 DW 프로젝트에 투입되지 않게 해 주세요.' 그 와중에 사장 보고자료, 본부장 보고자료, 기획팀장 보고자료, 비슷비슷한 내용을 늘였다가 줄였다가 하면서 별별 문서를 다 만들었다. 10월 중순경에 팀장한테 프로젝트 때문에 보고를 하러 갔다. 한참 얘기를 하다가 팀장이 고객사 기획팀장이 불러서 내려가는 바람에 팀장 책상 .. 공감수 0 댓글수 2 2010. 11. 7.
NetZ 이야기 – 5. 퇴사하기 퇴사하기 10월말에 사장님 보고를 하고 11월이 되었다. 지긋지긋 했던 프로젝트도 완료가 되어 사용자 교육을 하였다. 영업사원 100여 명을 모아놓고 교육을 하노라니 감회가 새로 왔다. 고객사의 사장님도 참석을 하셨는 데 교육이 끝난 후 강평말씀 중에 "프로젝트에 수고가 많았다. 교육 중에 개인별 매출액 등을 확인 할 수 있는 화면이 보이던데 이러한 기능이 영업사원 개개인을 평가하는 자료로 쓰여선 안되겠다" 란 말씀을 하셨다. 그 때 그 말씀이 무척이나 기억에 남는 데, 그 순간, '내가 개발한 프로그램이 누군가를 쪼이는 수단으로 쓰일 수도 있구나'란 생각을 했다. 널리 사람을 이롭게 하진 못할 망정 쯔쯔. ㅎㅎ 며칠이 흘렀다. 서울에 기획팀에서는 아무런 소식이 없었다. 사내 벤처팀에서도 아무런 소식이 .. 공감수 3 댓글수 43 2010. 11. 7.
NetZ 이야기 - 6. 파란만장했던 포탈 프로젝트 파란만장했던 포탈 프로젝트 며칠 쉬지도 못하고, 옷가지 몇 가지만 달랑 챙겨 서울행 기차에 몸을 실었다. 서울에 가면 부산에 있을 때보다 훨씬 많은 기회가 있을 거란 친구의 말이 귓가에 맴돌았지만 글쎄? 이렇게 서울로 올라가는 것이 내게 도움이 될지, 아니면 해가 될지…… 온갖 생각에 서울로 가는 5시간여 동안 한숨도 자지 못했다. 아. 다시 서울로 올라왔구나. 대학을 가려고 서울역 앞에 섰을 때만큼은 아니었지만, 서울역 앞에 서니 왠지 모를 두근거림에 가슴 벅찼다. 동생이 서울에서 학교를 다니면서 자취를 하고 있어서, 우선 동생네 자취방에 기거하면서 집을 알아보기로 했다. 집을 구하게 되면 그때에 맞춰서 와이프랑 애기가 서울로 올라오기로 했다. 12월6일. 첫 출근을 했다. 친구가 같은 팀에 있던 터라.. 공감수 2 댓글수 0 2010. 11. 7.
NetZ 이야기 – 7. 사업화 그리고 벤처 사업화 그리고 벤처 3월6일, 첫 출근을 했다. 지난 번 회사에 대한 인상이 워낙 그래서 그런지 훨씬 안정적이고 체계가 잡혀 보였다. 첫날 저녁에 6시 30분엔가 상무님이 자리에 와서 "이채성씨, 무슨 일 있어요?" "아뇨, 무슨 시키실 일이라도?" "그럼 왜 아직 퇴근 안 해요?" 직장 생활 4년 만에 6시30분에 퇴근 안 하냐고 물어봐 준 분은 처음이었다. 그래 이런 회사를 다녀야 해…… ㅎㅎ 입사 후 며칠 동안 업무 인수인계 하느라고 왔다 분주했다. NetZ에 본격적으로 손을 댈 수 여유도 찾았다. 프로그램이 조금씩 업그레이드 되어 가니 예전만큼 기능추가를 하는 데 빨리빨리 하지 못했다. 이걸 하면 저게 문제였고, 저걸 하면 이게 문제였다. 고민해야 하는 게 점점 늘어갔다. 꾸준히 메일도 왔다. 이.. 공감수 1 댓글수 0 2010. 11. 7.
NetZ 이야기 – 8. 그 후 그 후 그 후, 혼자서 NetZ에 매달렸다. InfoStick이라는 이름이 처음에도 맘에 들지 않았던 터라 이름을 다시 Mesticker라고 바꿨다. 꾸준히 새벽녘에까지 프로그램을 짰다. 조금만 고치던 프로그램이 덩치가 커지니까 손대기가 너무 복잡해져서, 소위 말하는 refactoring도 했다. refactoring하는 데만 두어 달을 그냥 까먹었다. 프로그램을 업그레이드 하면서 광고를 담아서 다만 얼마라도 매출을 일으켜 보고 싶었지만 – 돈을 받고 판다면 아무도 사지는 않을 거 같았다 – 그 마저도 여의치 않았다. 돈을 벌어보고 싶다기 보다는 그저 내가 이 프로그램을 계속 유지보수 해야 하는 뭔가 뚜렷한 의미를 찾고 싶었다. 유사한 프로그램에 묻혀, 그리고 포탈, 메신저들의 정말 수많은 기능에 묻혀 .. 공감수 6 댓글수 44 2010. 11. 7.
프로젝트 M을 논하다 – 2. 프로젝트 M은 어떤 녀석인가? 목차 1. 들어가며 2. 프로젝트 M은 어떤 녀석인가? 3. 프로젝트 M, 왜 힘들었나? 4. 프로세스 M을 다시 한다면 프로젝트 M은 어떤 녀석인가? 프로젝트 배경 프로젝트 M은 본사와 계열사의 회계 및 MIS 시스템을 개발하는 프로젝트이다. 발주처는 본사이며, 지난 2000년 구축된 회계 및 구매시스템의 업그레이드를 원했으며 아울러 계열사의 오래된 레가시 시스템 즉 회계, 인사, 구매 및 관련시스템의 업그레드에 대한 Needs가 있었다. 사실, 계열사 관련된 Needs는 본사가 계열사의 시스템에 대한 Needs의 성격이 강하며 계열사는 이미 고유의 자체 시스템이 있기에 업그레이드를 절실히 원하지는 않고 있었다. 발주처는 수 십 년 동안 굉장히 안정적인 사업구도하에 성장하여 왔으며 그 조직내의 조직원들.. 공감수 1 댓글수 0 2010. 8. 8.
프로젝트 M을 논하다 – 3. 프로젝트 M, 왜 힘들었나? 목차 1. 들어가며 2. 프로젝트 M은 어떤 녀석인가? 3. 프로젝트 M, 왜 힘들었나? 4. 프로세스 M을 다시 한다면 프로젝트 M, 왜 힘들었나? 30여년간 프로젝트 관리자로서 생활한 PM에게 물었다. "신참 PM에게 해 주고 싶은 얘기가 있다면 무엇입니까?" "Good Luck" - 티모시 리스터, 피플웨어 중에서 SI 프로젝트가 갖는 일반적 문제점 우리나라 환경에서의 SI 프로젝트가 갖는 문제점을 나열하자면 여러 가지가 있겠으나 고객과 SI업체, 개발자(프리랜서)의 측면에서 본다면 다음과 같은 것을 꼽을 수 있을 것이다. 고객측면 고객 스스로가 무엇을 원하는 지 모른다. SI업체가 오면 무엇이든지 다 해 줄 수 있는 것으로 생각한다. 개발업체측면 고객의 요구사항이 명확치 않으므로 고객의 업무량을 .. 공감수 1 댓글수 13 2010. 8. 8.
프로젝트 M을 논하다 – 4. 프로젝트 M을 다시 한다면 목차 1. 들어가며 2. 프로젝트 M은 어떤 녀석인가? 3. 프로젝트 M, 왜 힘들었나? 4. 프로세스 M을 다시 한다면 프로젝트 M을 다시 한다면 프로젝트는 쇼부다 - 염진섭 일정과 인력과 예산이 절대적으로 부족한 프로젝트에 참여하도록 회사에서 강요한다면 할 수 있는 일은? 퇴사 처음부터 극단적으로 퇴사를 고려해선 안 되겠지만, 무리한 프로젝트에 참여하는 것은 결코 바람직한 일이 아니다. Trouble 프로젝트에 참여하면서 죽을 고생을 다했다는 사람을 흔히 보곤 한다. 아니 일상적으로 본다. 그리고 아주 가끔은 너무나도 과중한 스트레스로 자살을 했다는 소식도 접한다.(PDA의 효시격인 애플의 Newton개발자가 스트레스로 자살을 했다는 얘기는 잘 알려진 얘기중의 하나다). 과연 그 프로젝트가 가정의 행.. 공감수 3 댓글수 18 2010. 8. 8.
Martin Fowler – 설계와 개발의 분리 원문 http://www.martinfowler.com/articles/newMethodology.html#SeparationOfDesignAndConstruction 소프트웨어 개발 방법론은 흔히 토목공학 혹은 기계공학과 같은 공학분야에서 비롯된다. 이들 공학은, 작업을 시작하기 전, 계획단계를 주로 강조한다. 엔지니어들은 무언가를 만들기 위해 무엇이 필요한지, 필요한 것들이 서로 어떻게 조합되어야 하는지를 아주 정교하게 보여주는 일련의 설계도를 그린다. 다리에 가해지는 부하를 어떻게 해결해야 하는 지와 같은 수많은 결정이 이러한 설계도를 작성하는 과정에서 이뤄진다. 이렇게 작성된 설계도는 다른 그룹, 종종 다른 회사에 전달되어 설계도에 따라 다리를 만들게 된다. 시공을 하는 동안 몇 가지 문제에 부딪.. 공감수 2 댓글수 1 2010. 7. 17.
너희가 프로젝트를 아느냐? – 1. 프로젝트 예측 이카루스의 날개를 제외하면, 소프트웨어는 인간이 만든 가장 조악하게 만들어지고, 신뢰할 수 없으며, 유지하기 어려운 기술적 산물이다. - Paul A. Strassmann 목차 0. 들어가며 1. 프로젝트 예측 2. Mythical Man-Month 3. 프로젝트의 크기가 미치는 영향 4. 프로세스에 대한 오해 5. 프로젝트 생산성 6. 진정 하고 싶은 말 7. 인용 자료 들어가며 숲 속에서 숲을 바라보기가 어려운 것처럼, 우리가 항시 수행하고 있는 소프트웨어 개발 프로젝트이지만 프로젝트의 실체에 대한 바라보기란 쉽지 않다. 그러나 우리는 프로젝트에 대한 아무런 정보 없이도, 그 프로젝트가 제 날짜에 끝나지 못한다고 자신 있게 예상할 수 있다. 프로젝트가 제 날짜에 끝나지 않고, 프로젝트팀이 지속되는 야.. 공감수 5 댓글수 6 2009. 11. 26.
너희가 프로젝트를 아느냐? – 2. Mythical Man-Month 목차 0. 들어가며 1. 프로젝트 예측 2. Mythical Man-Month 3. 프로젝트의 크기가 미치는 영향 4. 프로세스에 대한 오해 5. 프로젝트 생산성 6. 진정 하고 싶은 말 7. 인용 자료 Mythical Man-Month 프로젝트와 개발자 관계에 관해서 흔히 하기 쉬운 착각 중에 하나가 개발자를 공장의 생산 기계로 생각한다는 것이다. 따라서 생산량이 부족하면 증산을 위해서 생산 기계를 하나 더 들여놓으면 되는 것으로 단순하게 생각한다. 그러나 프로그램의 개발은 공장에서 제품을 생산하는 단계가 아닌 제품을 개발하는 단계와 같으며, 앞서 프로젝트 비용과 일정에서 설명한 바와 같이, 결코 그림6과 같은 등식은 성립될 수 없음을 유념해야 한다. 그림 6 프로젝트 일정과 투입인력 관계 (DeMar.. 공감수 4 댓글수 1 2009. 11. 25.
너희가 프로젝트를 아느냐? – 3. 프로젝트의 크기가 미치는 영향 목차 0. 들어가며 1. 프로젝트 예측 2. Mythical Man-Month 3. 프로젝트의 크기가 미치는 영향 오류에 미치는 영향 생산성에 미치는 영향 개발활동에 미치는 영향 그외 미치는 영향 4. 프로세스에 대한 오해 5. 프로젝트 생산성 6. 진정 하고 싶은 말 7. 인용 자료 프로젝트의 크기가 미치는 영향 프로젝트가 커질수록 필요한 비용 – Man-Month 등 – 에 대해 영향이 있을 뿐 아니라 오류, 생산성, 개발활동 등에도 영향을 미치게 된다. 오류에 미치는 영향 프로젝트의 크기가 증가할수록 개발이 아닌 요구사항과 설계상의 오류가 증가하게 된다. 그림 10 프로젝트의 크기와 오류가 발생하는 단계 (McConnel, Code Complete, 2004, p. 895) 프로젝트의 크기는 오류가.. 공감수 1 댓글수 0 2009. 11. 25.
너희가 프로젝트를 아느냐? – 4. 프로세스에 대한 오해 목차 0. 들어가며 1. 프로젝트 예측 2. Mythical Man-Month 3. 프로젝트의 크기가 미치는 영향 4. 프로세스에 대한 오해 5. 프로젝트 생산성 6. 진정 하고 싶은 말 7. 인용 자료 프로세스에 대한 오해 소프트웨어 프로세스는 소프트웨어 개발을 위한 생산적인 절차이다. 이 소프트웨어 프로세스에는 요구사항의 문서화, 요구사항에 대한 변경추적, 버전관리 툴을 통한 소스코드 관리, 결함 추적 등이 있을 수 있다. 흔히 프로세스에 대한 오해, 즉 프로세스가 실제 개발을 위한 생산적인 업무를 저해한다는 생각을 갖기 쉬우나, 프로젝트가 진행될수록 프로세스의 중요성을 사건이 터질 때 마다 한번씩은 느끼게 된다. 예컨대, 소스코드의 정기적인 백업, 버전관리 툴을 통한 소스코드 관리 등의 프로세스 부.. 공감수 1 댓글수 0 2009. 11. 25.
너희가 프로젝트를 아느냐? – 5. 프로젝트 생산성 목차 0. 들어가며 1. 프로젝트 예측 2. Mythical Man-Month 3. 프로젝트의 크기가 미치는 영향 4. 프로세스에 대한 오해 5. 프로젝트 생산성 생산성과 근무시간 개인별 업무 능력 프로젝트 도구와 생산성 개발자의 동기와 일정압력 6. 진정 하고 싶은 말 7. 인용 자료 프로젝트 생산성 생산성과 근무시간 소프트웨어 개발에 참여했던 사람들이 모여서 하는 얘기 중 하나가, 자기가 참여했던 프로젝트가 얼마나 힘들었었는지, 휴일 없이 얼마나 오랜 시간 쉼 없이 일했는지를 자랑스럽게 얘기하곤 하는 것이다. 그러나 이것은 그들이 참여했던 프로젝트가, 대부분의 불운한 프로젝트와 마찬가지로 프로젝트 크기에 대한 일정과 비용 추정이 잘못되었던지, 그들 고객의 마음이 갈대와 같았던지 혹은 그들의 역량이 보.. 공감수 2 댓글수 0 2009. 11. 25.
너희가 프로젝트를 아느냐? – 진정 하고 싶은 말 목차 0. 들어가며 1. 프로젝트 예측 2. Mythical Man-Month 3. 프로젝트의 크기가 미치는 영향 4. 프로세스에 대한 오해 5. 프로젝트 생산성 6. 진정 하고 싶은 말 7. 인용 자료 진정 하고 싶은말 수십 년간, 수많은 학자들이 소프트웨어 공학을 연구하였으며, "소프트웨어 위기"라는 말이 나온 지도 40여 년이 흐른 지금의 우리에게도, 40여 년 전 세대의 소프트웨어 종사자들이 겪었던 문제가 그대로 답습되고 있다. 한 세대를 풍미했던 수 많은 방법론, 그 방법론이 나왔을 땐 마치 모든 문제를 해결할 것만 같았던 - 구조화 프로그래밍, 객체지향 프로그래밍, CBD, 최근의 SOA까지 - 정말 그럴 듯 했던 그 많은 방법론을 적용하여 왔지만 왜 아직도 이 모양일까? 아직 시도해 보지 못.. 공감수 2 댓글수 11 2009. 11. 24.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.