본문 바로가기

개발자

훌륭한 아키텍처란 (2010 버전)? 훌륭한 아키텍처에 대한 물음에 답하기 위해서 우리는 평가를 해야 하고 평가를 위해서는 기준이 있어야 한다. 너무나 간단한 이야기 같지만 아키텍처 평가 문제는 바로 이 기준이 없거나 애매모호 하다는 사실로부터 시작된다. 아키텍처 평가를 위한 기준이라고 할 수 있는 것을 찾기가 어렵다. 아키텍처 설계 과정에서 수행하는 일련의 의사결정은 옳고 그름에 관한 것이 아니라 얼마나 객관적으로 타당한 것인가에 대한 것이다. 따라서 너무나 일반적인 느낌이 드는 그래서 아무도 이의를 제기하지 못하는 두가지 기준 또는 관점을 생각해 보자. 1.아키텍처 설계 원칙을 지켰는가? 2.아키텍처 요건을 만족했는가? 1.아키텍처 설계 원칙을 지켰는가? 목표 시스템 주변에는 여러 이해관계자들이 있다. 이들은 서로 다른 관심사(conce.. 더보기
넥스트리, 그 가슴설레이는 이름... 이제는 넥스트리 라는 이름으로 척박한 대한민국의 소프트웨어 토양 위에 당당히 서 있습니다. 미래를 꿈꾸면서... “넥스트리소프트”의 이전 이름은 ”e-BizOn(www.e-bizon.com)”이었습니다. 그 당시는 인터넷 광풍과 함께 회사의 이름 앞에 “e”가 들어가는 것이 유행하던 시절이었습니다. ebay가 대표적인 예입니다. 그 때 회사가 외쳤던 슬로건은, “여러분의 e-비즈니스를 “On” 시켜드리겠습니다.” 였습니다. 하지만, 아쉽게도 그렇게 많이 “On”시켜드리지는 못했습니다. 초기에 회사가 로고를 여러 차례 변경했었지만 마지막 버전은 참 보기 좋았습니다. 당시 열 명도 안되는 회사가 무슨 수로 남의 비즈니스를 “On”시켜준다고 했을까 하는 재미나는 의구심도 듭니다. 어쨌든 그 때의 이름으로는 상.. 더보기
소프트웨어 엔지니어 버전(Version) 이런저런 이유로 발표할 기회가 많은 편이다. 대체로 간단하게 나를 소개한 다음 발표를 시작한다. 이름, 회사, 분야, 주요 경력과 같은 내용을 소개한다. 참여하신 분들의 이해도 돕고 발표내용 관련 컨텍스트도 나누기 위해서이다. 적어도 내가 무엇을 했으며 무엇을 하고 있는 지를 전달하고 나면 발표가 한결 편하다. 다음은 자기 소개자료 페이지의 한 부분이다. 그런데, 다른 소개자료에는 없는 정보가 하나있다. 소개할 때 이 내용을 빼지 않고 설명을 한다. 하지만 여유가 없을 경우, 이 내용은 그냥 지나친다. 그럴 경우, 발표가 끝나면 누군가는 꼭 물어온다. “아까 소개자료에 있던 Ver 4.6은 무엇을 의미하죠?” (Ver은 Version을 줄여놓은 단어이다. 우리말로 판(版)이라고 해야하나 엔지니어 동네에서.. 더보기
개발자, 그대는 영원한 TF 며칠 있으면 차세대라고 부르는 대형 프로젝트가 시작된다. 차세대 프로젝트 추진 태스크포스 팀은 정신없이 바쁜 나날을 보내고 있다. 프로젝트 룸 여기저기에 자극적인 구호를 담은 플래카드가 내걸리기 시작한다. 며칠 후면 단합대회를 겸한 프로젝트 킥오프 워크샵이 있을 예정이다. 프로젝트를 추진 TF팀은 프로젝트 추진 방안을 토의하기 위해 회의실에 모였다. TF 팀장이 이야기 한다. 비장하다. “이 프로젝트에 회사의 미래가 걸려있습니다. 이 프로젝트의 성공만이 회사의 미래를 보장할 수 있습니다. 시장점유율 1위, 고객만족도 1위라는 거대한 목표는 바로 이 프로젝트에 달려있습니다. 이 프로젝트에 여러분의 뼈를 묻으십시오. 이 프로젝트를 위해 여러분의 모든 시간과 에네지를 투자하십시오.” 시간이 지날수록 TF 팀장.. 더보기
목표 대비 진척률 98% 월요일 아침, 프로젝트 회의가 열린다. 각 팀의 부문 PM들은 돌아가면서 현재 진척현황을 기능, 이슈, 진척을 기준으로 보고한다. 먼저 주문개발 팀의 부문 PM이 보고한다. - - 지난 주 저희 팀은 00 기능과 00 기능에 대한 설계를 완료했습니다. 이번 주는 00 기능에 대한 분석을 시작하겠습니다. - - 지난 주 저희 팀의 이슈는 인력지연투입 이었고, 협력업체에게 초강력 조치를 통한 결과 목요일 오후에 예정된 3명의 중급 개발자가 모두 긴급 투입된 상태입니다. - - 지난 주 저희 팀의 목표 대비 진척율은 98%입니다. 진척율 세부사항은 어쩌고 저쩌고 ~ (총괄 PM은 세부 내용은 잘 모르겠고, 오직 98이라는 숫자가 무척 맘에든다. 그의 안면은 흐뭇한 미소로 가득차 있다.) 다음은 배송개발 팀의 .. 더보기
소프트웨어 프로젝트에 대한 또다른 메타포 우리는 소프트웨어 프로젝트와 프로젝트 수행방식에 대한 아주 오랜 메타포인 폭포(Waterfall)를 만났으며, 만나고 있으며, 불행하게도 계속 만날 것 같다. 누군가 새로운 메타포로 끝없이 저항하고 철저히 무력화시켜주지 않는다면 계속 만날 것 같다. 폭포(Waterfall) 메타포가 선언되고 오랜 세월이 흐른 지금 우리는 잘못된 메타포가 우리를 얼마나 힘들게 하는지 온몸으로 느끼고 있다. 소프트웨어 프로젝트의 본질에 대한 오해 정도는 아무것도 아니다. 그러한 메타포를 기반으로 개발 프로세스가 정의되었다는 사실은 우리의 희망을 빼앗아 간다. 폭포 메타포는 선언한 직후에, 메타포가 잘못되었다고 스스로 선언했다. 그럼에도 폭포 메타포 추종세력은 절대로 죽지 않고 끝없이 살아나는 강시처럼 IT 업계 여기저기서 .. 더보기
기기묘묘한 아키텍트의 역할 소프트웨어 엔지니어 K가 어느 차세대 시스템 구축 프로젝트에 아키텍트 역할로 참여했다. 프로젝트 규모는 200억대라고 하는데, 프로젝트 끝부분이라 그런지 아키텍트라고는, 중급 엔지니어 한 명뿐이라고 한다. 어느날 K가 괴로워 한다는 소식을 전해듣고, 영업대표가 달려갔다. 그리고는 남아있는 작업목록이란 것을 들고왔다. [아키텍트 K의 남아있는 작업목록] 찬찬히 작업 목록을 훑어보던 나는, 답답함으로 가슴이 먹먹해 진다. 개발서버 구축, 배치서버 구성, 운영서버 전환, 에러코드 정의, 마이플랫폼 매핑 유틸 개선, 오즈 리포트 수동 설치, 통합빌드 배포, 서버 운영매뉴얼 작성, ... 모두 세어 보기도 벅찬 목록, 아무리 보아도 공통성이 없는 작업목록, 중급 엔지니어 한 명 데려다 두고, 이 모든 것을 하기 .. 더보기
소멸차트(Burn down chart) 예술의 경지에 오르다. 어쩜 이렇게 아릅답게 떨어질까... 집중도도 42.3%나 된다... (일반 SI 프로젝트 팀의 경우 20% 미만의 집중도를 보여준다.) [비젠드 메소다(Vizend methoda)의 소멸차트(Burn down chart)] 넥스트리의 화훼서비스 플랫폼 개발팀(일명 747 플라워팀)의 소멸차트를 지켜보다가 만세를 불렀다. 이런 결과를 얻기위해 얼마나 오랜 시간을 투자했던가. 팀원들의 끝없는 노력의 결과이다. 이 팀의 팀웤은 절정에 이르렀음을 알 수 있다. 이 팀은 이제부터, 정시퇴근, 5일 근무와 같은 직장인들이 꿈꾸는 어떤 형태의 근무조건을 가져가도 된다. 왜냐면 충분한 생산성이 보장되기 때문에 회사와 개인이 윈-윈 하는 상태로 돌입했다. 이 팀에 새로운 개발자를 투입하면 한 두차례 출렁거림이 있은 후 .. 더보기