본문 바로가기

SW 현장통신

훌륭한 아키텍처란 (2010 버전)? 훌륭한 아키텍처에 대한 물음에 답하기 위해서 우리는 평가를 해야 하고 평가를 위해서는 기준이 있어야 한다. 너무나 간단한 이야기 같지만 아키텍처 평가 문제는 바로 이 기준이 없거나 애매모호 하다는 사실로부터 시작된다. 아키텍처 평가를 위한 기준이라고 할 수 있는 것을 찾기가 어렵다. 아키텍처 설계 과정에서 수행하는 일련의 의사결정은 옳고 그름에 관한 것이 아니라 얼마나 객관적으로 타당한 것인가에 대한 것이다. 따라서 너무나 일반적인 느낌이 드는 그래서 아무도 이의를 제기하지 못하는 두가지 기준 또는 관점을 생각해 보자. 1.아키텍처 설계 원칙을 지켰는가? 2.아키텍처 요건을 만족했는가? 1.아키텍처 설계 원칙을 지켰는가? 목표 시스템 주변에는 여러 이해관계자들이 있다. 이들은 서로 다른 관심사(conce.. 더보기
소프트웨어 엔지니어 버전(Version) 이런저런 이유로 발표할 기회가 많은 편이다. 대체로 간단하게 나를 소개한 다음 발표를 시작한다. 이름, 회사, 분야, 주요 경력과 같은 내용을 소개한다. 참여하신 분들의 이해도 돕고 발표내용 관련 컨텍스트도 나누기 위해서이다. 적어도 내가 무엇을 했으며 무엇을 하고 있는 지를 전달하고 나면 발표가 한결 편하다. 다음은 자기 소개자료 페이지의 한 부분이다. 그런데, 다른 소개자료에는 없는 정보가 하나있다. 소개할 때 이 내용을 빼지 않고 설명을 한다. 하지만 여유가 없을 경우, 이 내용은 그냥 지나친다. 그럴 경우, 발표가 끝나면 누군가는 꼭 물어온다. “아까 소개자료에 있던 Ver 4.6은 무엇을 의미하죠?” (Ver은 Version을 줄여놓은 단어이다. 우리말로 판(版)이라고 해야하나 엔지니어 동네에서.. 더보기
1인 개발자의 꿈 어느 날 갑자기, 스마트폰은 앱을 거느리고 혜성처럼 다가온다. 앱스토어 1위 개발자의 돈 번 이야기가 신문지면을 장식한다. 수익의 70%를 개발자에게 돌려준다고, 이제 개발자가 진정 실력으로 높은 수익을 올릴 수 있는 시대가 왔다고, 과거의 기업 중심의 개발 생태계를 깨고 개발자 중심의 생태계로 진화하고 있다고. 신문들은 그렇게 대서특필한다. 개발자는 꿈에 젖어든다. 십수년 전에 선배들이 가졌던 기회를 이제 가질 수 있게 되었다고, 번뜩이는 아이디어로 한 건만 대박을 치면 큰 돈을 벌 수 있다고, 조직의 굴레를 벗어나 개인의 자유 속에서 일을 할 수 있다고. 그래서 회사문을 박차고 나가서 1인 개발자의 꿈을 향해, 알토란 같은 적금을 털어 흰색 컴퓨터를 사들고 골방으로 들어간다. 정부는 앱 개발자로서 1.. 더보기
개발자, 그대는 영원한 TF 며칠 있으면 차세대라고 부르는 대형 프로젝트가 시작된다. 차세대 프로젝트 추진 태스크포스 팀은 정신없이 바쁜 나날을 보내고 있다. 프로젝트 룸 여기저기에 자극적인 구호를 담은 플래카드가 내걸리기 시작한다. 며칠 후면 단합대회를 겸한 프로젝트 킥오프 워크샵이 있을 예정이다. 프로젝트를 추진 TF팀은 프로젝트 추진 방안을 토의하기 위해 회의실에 모였다. TF 팀장이 이야기 한다. 비장하다. “이 프로젝트에 회사의 미래가 걸려있습니다. 이 프로젝트의 성공만이 회사의 미래를 보장할 수 있습니다. 시장점유율 1위, 고객만족도 1위라는 거대한 목표는 바로 이 프로젝트에 달려있습니다. 이 프로젝트에 여러분의 뼈를 묻으십시오. 이 프로젝트를 위해 여러분의 모든 시간과 에네지를 투자하십시오.” 시간이 지날수록 TF 팀장.. 더보기
목표 대비 진척률 98% 월요일 아침, 프로젝트 회의가 열린다. 각 팀의 부문 PM들은 돌아가면서 현재 진척현황을 기능, 이슈, 진척을 기준으로 보고한다. 먼저 주문개발 팀의 부문 PM이 보고한다. - - 지난 주 저희 팀은 00 기능과 00 기능에 대한 설계를 완료했습니다. 이번 주는 00 기능에 대한 분석을 시작하겠습니다. - - 지난 주 저희 팀의 이슈는 인력지연투입 이었고, 협력업체에게 초강력 조치를 통한 결과 목요일 오후에 예정된 3명의 중급 개발자가 모두 긴급 투입된 상태입니다. - - 지난 주 저희 팀의 목표 대비 진척율은 98%입니다. 진척율 세부사항은 어쩌고 저쩌고 ~ (총괄 PM은 세부 내용은 잘 모르겠고, 오직 98이라는 숫자가 무척 맘에든다. 그의 안면은 흐뭇한 미소로 가득차 있다.) 다음은 배송개발 팀의 .. 더보기
소프트웨어 프로젝트에 대한 또다른 메타포 우리는 소프트웨어 프로젝트와 프로젝트 수행방식에 대한 아주 오랜 메타포인 폭포(Waterfall)를 만났으며, 만나고 있으며, 불행하게도 계속 만날 것 같다. 누군가 새로운 메타포로 끝없이 저항하고 철저히 무력화시켜주지 않는다면 계속 만날 것 같다. 폭포(Waterfall) 메타포가 선언되고 오랜 세월이 흐른 지금 우리는 잘못된 메타포가 우리를 얼마나 힘들게 하는지 온몸으로 느끼고 있다. 소프트웨어 프로젝트의 본질에 대한 오해 정도는 아무것도 아니다. 그러한 메타포를 기반으로 개발 프로세스가 정의되었다는 사실은 우리의 희망을 빼앗아 간다. 폭포 메타포는 선언한 직후에, 메타포가 잘못되었다고 스스로 선언했다. 그럼에도 폭포 메타포 추종세력은 절대로 죽지 않고 끝없이 살아나는 강시처럼 IT 업계 여기저기서 .. 더보기
기기묘묘한 아키텍트의 역할 소프트웨어 엔지니어 K가 어느 차세대 시스템 구축 프로젝트에 아키텍트 역할로 참여했다. 프로젝트 규모는 200억대라고 하는데, 프로젝트 끝부분이라 그런지 아키텍트라고는, 중급 엔지니어 한 명뿐이라고 한다. 어느날 K가 괴로워 한다는 소식을 전해듣고, 영업대표가 달려갔다. 그리고는 남아있는 작업목록이란 것을 들고왔다. [아키텍트 K의 남아있는 작업목록] 찬찬히 작업 목록을 훑어보던 나는, 답답함으로 가슴이 먹먹해 진다. 개발서버 구축, 배치서버 구성, 운영서버 전환, 에러코드 정의, 마이플랫폼 매핑 유틸 개선, 오즈 리포트 수동 설치, 통합빌드 배포, 서버 운영매뉴얼 작성, ... 모두 세어 보기도 벅찬 목록, 아무리 보아도 공통성이 없는 작업목록, 중급 엔지니어 한 명 데려다 두고, 이 모든 것을 하기 .. 더보기

티스토리툴바