새 창을 열다

지난 10월 21~22일에 제13회 소프트웨어 품질관리 심포지엄이 섬유센터에서 있었습니다.
무려 10만원이나 하는 세미나였는데, 사장님의 특별(?)지시로 다녀올 수 있었습니다. 품질에 관한 세미나가 10회 이상씩 지속적으로 열리고 있었다는 것을 미쳐 모르고 있었는데 나름 고무적이었습니다. 하지만 대부분의 세션이 문제점만 이야기하고 해결방안은 내놓지 못하는 발표가 많아 아쉬었습니다. 물론 문제를 이야기하기란 쉽지만 역시 해결책을 내기는 어렵다는 것을 알지만요.

개발자 입장에서 참여하는 개발 세미나와 QA 입장에서 참여하는 품질 세미나는 느낌이 살짝 달랐습니다. 지극히 개인적인 느낌이지만 말이니다. 품질 또는 개발은 지식이 아니라 관리 이슈라는 말도 와닿았습니다. 관리되지 않은 모듈과 소스코드는 없는 것이나 마찬가지이기 때문이지요.

또한, 대부분의 회사에서 수행하고 있지못하는 자동화, 정적분석, 화이트박스 테스트 등에 대해 먼저 시행하면서 어려웠던 점과 좋았던 점을 고루 나눌수 있었던 것 같습니다. 많은 세션이 있었지만 그중에 기억에 남는 세션 몇개만 정리했습니다.

Issues and Challenges in S/W Development & quality - 유인경 원장(LG전자 기술원)

     ♣  구체적인 해결방법을 제시하지 못해서 아쉬움, 개발자의 높은 개발 능력이 요구됨을 어필

 

IT/SW융합에서의 품질 확보를 위한 테스팅 방안 - 최병주 교수(이화여대)

• 카 인포테인먼트 시스템 테스트 자동화 도구 AMOS 개발

  • 분석 로봇이 시스템 구조 분석을 통해 테스트 위치(리스크존)을 식별하고 테스트 결과 분석, 결과를 내주는 시스템

  • 짧은 개발 기간과 개발 후반에 테스트가 집중되는 문제

    • Interface Based Test (개발 모듈의 인터페이스화 선행)
    • 블랙박스 테스트 하되, 화이트 박스 테스트로 확인
    • SW 개발자는 최초의 테스터

      ♣  자동화 도구를 개발하여, 결함의 원인을 분석하며, 코드 레벨의 화이트박스의 좋은 예.

 

IT차량 분야 임베디드SW 테스트 프레임워크 구축 및 시범 적용 사례 - 정태하 수석(오토에버시스템즈)

• V-모델(Multiful V-모델) 에 근거한 테스트 프레임워크를 구축함.

• Verification & Validation의 각 레벨의 세부 활동 정의

  • Verification 

    • 사양서 Inspection
    • 설계서 Walkthrough
    • 소스코드 Static Analysis : 자동화 도구 활용

  • Validation

    • 단위 Test : Fuction 단위의 기능성 검증, 자동화 마련, 단위함수레벨의 테스트 커버리지 측정
    • 통합 Test : 구성요소의 Integration Set에 대해서 기능시험, 자동화
    • 시스템 Test : 요구사항기반의 테스트

    ♣ 개발 이전의 사양서, 설계서, 소스 레벨의 테스트가 이뤄지며 모두 자동화되어 있음.
    ♣ 문서 및 사용 변경에 대한 업데이트미 미비하며, 시간이 오래걸린다는 단점이 잇음
    ♣ 테스트 케이스를 소스 코드 기반에서 추출하고 개발자 리뷰를 같이 하는 것으로 보안 노력.

 

국내  SW QA시장 활성화를 위한 소루션 배포 및 기술지원 방안

• 외산 솔루션의 문제점

  • 국내 현실과 다른 프로세스
  • 언어 문제
  • 고가의 도입과 유지보수 비용

•  소프트웨어 테스트 관리시스템 WATT(와이즈와이어즈)

  • 요구 사항관리
  • 테스트케이스관리
  • 결함관리
  • 보고서 기능
• 무료 다운로드 : http://watt.wisewires.com

    ♣ 자사 툴 선전하는 시간이었으나, 외산 툴의 장단점을 소개하고 현실을 이해시키는 세션이었음.

 

ITNHN Quality Practice 적용 사례

• QP(Quality Practice) 도입하여 개발 단계의 Defect Prevention을 강화하고, 품질 활동을 정령화 시킴

  • 도입배경

    • 개발 라이프 후반에 몰아 닥치고, 제대로 테스트 되지않은 모듈이 QA 단계로 넘어옴
    • 단순 기능 테스트 위주의 검증과 버그는 QA가 잡는다는 안일한 마인드가 팽배
    • 개발 품질보다는 개발 진척도에만 관심을 가짐.

  • Quality Practice 활동

    1. Coding Convention : 코드이 가독성 및 유지 보수성 향상을 목표

       • 신규/수정되는 코드에 코딩표준을 준수시키도록 함

    2. Unit Test Coverage

       • 구현단계에서 필수 수행 Unit Test 대상 정의(QA불가한 기능,DB쿼리,데이터가공 등)
       • Unit Test Coverage를 QA 테스트의 Entry Criteria로 사용
    3. Code Inspection : 대상 소스에 대한 리뷰, 공통 협업도구 제공
    4. Static Code Analysis : 결함 사전 제거

    5. Code Complexity : QA 테스트 단계의 Entry Criteria로 지정

       • Critical한 정적 분석 결함을 모두 제거

• Quality Practice 적용 절차
  1. 개발자

  • 코딩 표준 준수
  • Unit Test

  2. 개발팀

• 주기적인 통합빌드
• 5가지 QP 항목 필수적

3.QA

• 구현 단계 말 코드 품질 확인하여 QA 가능 수준인지 판단
  중점적으로 테스트할 부분 식별

• Quality Practice 활동 지표 수립

  • 대시 보드를 구성하여 품질지표를 정량화 하여 표현(Gold, Green, Yellow 등으로 시각화하여 잘하고 있는지 여부를 표시)
  • 수준과 목표를 설정하여 개발자 스스로 도전하게 동기부여
  • KPI 등에 반영하지 않으므로 반발 감소시킴

• 개선 효과 측정 방법

  • QA 단계 완료 및 릴리즈 이후 안정화 시점에서 3가지 빌드 품질 지표를 측정하여 개선효과를 검증
  • 사내 BTS을 이용하여 Build Quality를 측정
  • Quality Practice 활동을 한 소스와 하지 않은 소스를 비교하여, 추후 장애 심각도 등을 측정

• 조직차원의 지원활동

  • 표준 환결 설정, 교육, 기술지원
  • 자동화 도구 지원
  • 커뮤니케이션 강화 및 피드백 활동(사내 Q&A, FAQ, Best Practice 공유)

• 기타 (사용하고 있는 툴 등 구두로 소개해 줌)

• • Style checker
  • Google Test Frameworks
  • Visual Studio tools
  • JUnit, CPPUnit
  • Clover(code coverage tool) : http://www.atlassian.com/software/clover/
  • Hudson : 오픈 소스 CI 서버

    ♣ 구현단계의 품질을 위해 애씀, 전사적인 지원과 노력을 엿볼 수 있음
    ♣ 유/무료 도구의 적극적인 이용과 통합적인 관리가 돋보임

이 글은 스프링노트에서 작성되었습니다.

제7회 임베디드 소프트웨어 산업협의회의 정례기술 세미나 다녀왔습니다. 강남역까지 버스를 타고 가니 의외로 지하철보다 빨리 도착할 수 있었습니다. 역시 낮에 돌아다니는 건 기분 좋은 일이더군요. 싱싱 달리는 버스를 타고 여유롭게 행사장에 도착했습니다. 항상 조금씩 늦는 저로서는 흔한 일이 아니랍니다. 헤~ 테스팅 분야에서는 처음으로 참석해 본 세미나였는데요. 주로 임베디드 분야의 테스팅에 대한 이야기가 주제였습니다. 

STA 컨설팅의 권원일 대표님이 'SW 테스팅의 실체'라는 주제로 전반적인 이야기를 해주셨는데요. 현실적으로 리스크에 기반한 테스팅이 이루어져야 한다는 점. 그리고 V-모델 컨셉이 잘 반영되어 있는지 생각해보라는 말씀이었습니다.

고려대학교 최진영 교수님의 발표는 'SW 테스팅 해외 사례'가 주제였는데, 사례는 별로 없었고 임베디드 소프트웨어의 특징들- 플랫폼 다양함, 시간 제약이 큼, Reactive(외부환경과 지속적으로 상호작용), 동시성, 하드웨어와의 종속성-때문에 테스팅이 더 어렵다는 사실에 초점이 맞춰진 발표였습니다.






잠시 커피 브레이크 타임!~ 아침 밖에 안 먹고 간지라 무지 배고팠는데요. 편의점에서 잽싸게 샌드위치 하나 먹었습니다. 우연히 만나 모회사 팀장님이 사주셔서 무지 고마웠지요^^


마지막은 LG전자 김효영 책임께서 '전자 제품 분야에서의 SW 테스팅 사례' 발표가 있었습니다. 정적테스트에서 '베테랑 리뷰'가 이루어지고 있다면서 "강제적으로 시작한 기술 전문가들의 리뷰가 큰 효과"를 거두고 있다는 얘기가 기억에 남습니다. 그리고 자동화된 정적 분석을 하고 있다는 점, 상용 툴과 자체 개발한 툴로 결함 관리를 한다는 점에서 품을를 위해 많은 애쓰고 있구나라는 생각이 들었습니다. 하지만 모든 부서의 이야기가 아니라고 하시면서 "이런데도 있고 저런데도 있어요"~라는 식으로 들려 다소 집중이 안되기도 했습니다. 끝나고 질문이 쏟아지더군요.;;

소프트웨어 테스팅이 많은 연구를 통해 수준이 높아져가고 있고 많은 기법이 소개되고 있는 것처럼 임베디드 소프트웨어 분야의 테스팅도 그 중요성을 점점 인식해가고 있구나라는 생각이 듭니다.

저도 한동안 많이 쉬었으니 이제 슬슬 움직여봐야겠지요?

자료다운로드

5월의 마지막주 금요일..
삼성 섬유센터에서 다음 UI DevDay 행사가 열렸습니다.
등록할 때는 추첨에서 떨어질까바 걱정했는데 다행이 참가자 목록에 있어서 다녀올 수 있었지요. 맨 처음의 키노트는 제가 조금 늦은 관계로 뒷부분만 들을 수 있었습니다. 다음의 개발 지식을 공유하고 문화를 퍼뜨려 결과적으로 대한민국 웹의 발전을 이루고자 한다는 점, 또한 엔지니어는 마술과 같은 일을 한다는 말씀이 마음에 와닿더군요. TV에서 보는 마술사가 멋진 매직쇼를 보여주듯이 UI엔지니어도 사용자에게 마법을 보는 듯한 경험을 주다는 면에서 꼭 맞는 비유라는 생각이 들었습니다.

마술사가 되십시오

<JRIA Widget 구현의 핵심>
Javascript 기반의 RIA를 JRIA라고 하더군요. 발표자는 위젯은 이미 트렌드라고 말하면서 사용자, 개발자, 자바 프레임웨크 간의 상호작용이 중요하다는 이야기를 전해주었습니다. 저는 JRIA 개발시 고려사항을 보면서 OOP나 디자인패턴과 같은 개념과 서서히 일어나 적용되면서 RIA도 점점 발전한다는 생각이 들었습니다.


<액션스크립트 3.0에 대한 개발자들의 호기심>
"자연을 모방할 수 있습니다." - 발표자는 플래시가 내가 있는 장소,자연, 공감을 만들어 낼 수 있는 면에서 큰 매력이 있는 기술임을 이야기 햇습니다. Front-End의 특징은 서비스나 프로그램의 대표성을 가진다는 것과 사용자 이벤트 중심으로 이루어져있다고 할 수 있을텐데요. 이것을 가장 잘 표현할 수 있는 기술이 플래시가 아닐까하는 생각이 듭니다.
무비클립 때문에 무겁다는 인식이 많아 왔던 것도 사실이지만, 타임라인 없이 스크립트만으로도 구현이 가능하고, 엔터플레이즈 솔루션 개발에도 충분히 쓰일 수 있는 기술이라는 견해를 주셨습니다.

<RIA와 Silverlight>
플래시 이야기가 나왔으니 다음은 Silverlight 이야기가 나왔습니다. 실버라잇이 WPF의 서브셋이라는 점, 지금 나온 버전 등에 대한 얘기를 쭉~ 해주셨습니다.

<AJAX 채팅 어플리케이션 구현>
채팅 프로그램을 개발해보는 것은 서버 구성과 알고리즘, 클라이언트까지 다양한 고민을 해볼 수 있는 프로젝트가 될 수 있을 것이라는 격려를 해주셨습니다. 채팅 어플리케이션을 구현하기위해 사용하신 방법 중 Client Polling 방법과 Server Push 방법을 장단점과 해결점을 리뷰해 주셨지요.

<써드파티 Web Application 개발> 
Firefox Extension과 Opera Widget을 개발하는 방법을 상세하게 알려주셨습니다. 말로 설명을 듣는 것보다 직접해보면서 들은 내용을 확인해보고 싶은 마음이 불뚝 솟아오르기도 했었답니다. 또한 알려주신 Opera Dragonfly 라는 디버깅 툴이 유용했다는 정보도 감사했습니다.

<Font-End 성능향상 Tip> 
이 부분은 듣지 못하고 다른 세션으로 옮겨가서 아래 세션을 들었습니다;;;

<한메일 익스프레스 iphone 버전 개발>
개인적으로 아이폰 터치를 가지고 있고 다음달에 아이폰이 국내 출시가 된다고 하여 옆 세션으로 자리를 옮겼습니다. 처음부터 다 듣지는 못햇지만 아이폰에서 실행되도록 구현하는데의 고려사항과 몇가지 팁을 얻을 수 있었습니다.

마지막 순서는 경품 추첨!~이번에는 로또 프로그램을 만드셨는지, 종이를 뽑지않고 프로그램을 돌려서 화면에 추첨번호를 보여주시더군요. 안타깝게 경품 추첨에는 들지 못햇습니다. 멀리까지 갔는데 말이죠.ㅡㅡ;어쨌든 오랜만에 개발관련 세미나를 듣고오니 한동안 잊고있었던 코딩을 다시 한번 해보면 어떻까하고 마음이 동(動)하는 것이 느껴집니다.^^*

4월 30일 강남 토즈에서 네이버 OpenAPI카페(http://cafe.naver.com/openapi.cafe) 모임이이었습니다.
NHN의 선행기술개발랩에서 주최로 이번 행사는 올해 들어 두번째 진행되고 있다고 합니다. 이런 행사들로 지금까지 활발하지 않았던 카페가 요즈음 이런 행사 등으로 조금씩 생기를 찾아가고 있는 듯합니다.

발표가 있기 전에 자기소개가 있었습니다. 주로 자바개발자 전문가 과정을 수강하고 계신 학생들이 많았고 대학생이나 취업준비생들이 많이 참석해주셨습니다. 젊고 활기찬 분들이 새로운 트렌드를 익히려고 늦은 시간 강남까지 찾아온 것만으로도 귀감이 되었습니다.

먼저 NHN의 선행기술개발랩에서 네이버 OpenAPI Library를 소개해주셨습니다. Connection을 맺고 Parsing 등을 하는 부분들을 간단히 함수 하나 호출로 해결할 수 있는 라이브러리를 만들어 사용 예를 알려주셨습니다. 주로 검색 API였고 PHP 언어로 이루어졌지만, 추후에 다른 API나 다른 언어로도 라이브러리화 해서 제공할 예정임을 알려주셨습니다. 만드느라 야근 많이 하셨다는데 감사합니다.

그 이후에 카페 회원들의 발표가 이어졌습니다. 직접 만드신 지도 API 사용예를 데모해 주셨는데, 네트워크 상태가 양호하지 못해 다소 아쉬웠습니다. 역시 발표와 데모에는 예외적인 상황이 발생할 수 있다는 것을 항상 염두해두어야 한다는 사실을 다시금 깨닫게 하는 순간이라고나 할까요;;

또한 렌탈마켓(http://www.rentalmarket.co.kr)의 기술책임을 맡고 계신 개발자께서 현업에서 바로 사용하신 예를 즉석해서 시연해주셨습니다. 렌탈이라는 특성상 지도가 꼭 필요하다는 것을 생각해볼 때 API의 좋은 사용예라는 생각이 들었습니다.

늦은 시간에 먼 곳에서 열려 미쳐 뒷풀이까지 참석하지 못해 아쉬웠습니다. 항상 세미나 가기 전에는 갈까말까 고민하기도 하고 귀찮기도 합니다. 하지만 막상 자리에 가서 같은 고민을 가진 사람들을 만나고 대화하다보면 그들의 열정에 나 또한 힘이 솟는 것을 느낍니다. 또한 돌아오는 길은 가는 길처럼 멀게 느껴지지 않고 뿌듯함으로 가득차곤 합니다. 앞으로 이런 세미나에 종종 찾으렵니다. 카페에 올라오 사진 몇장 첨부하고 리뷰를 가름하렵니다.

1. 어떻게 오랜 시간 엔지니어로 일할 수 있었는가? 어려운 점은 없었는지, 롱런하는 비결은 무엇인가?

     김지영 부장

• 독하다는 소리를 들을 정도로 열심히 일했다고 생각하다. "여자라서"라는 소리를 듣기 싫어해서 열심히 했고"여자라서 잘한다"라는 소리를 듣길 원했다.
• 운7기3이라는 말처럼 운도 실력이다. 기회가 있을 때 준비가 되어 있어야 한다.

     조인순 부장

• 신입으로 처음 시작했을 때 원하지 않는 일을 하게 되었고 스스로 하지 못하는 스타일인데다가 누군가 코칭해주길 계속 바랬던 것 같다. 결국은 때려쳤다. 아니다 싶을 때는 회사를 옮기는 것도 해답이 될 수 있었다.
• MS 입사 이후에는 많은 기술을 지원(170여가지가 넘는 제품군과 기타 흔히 알려지지 않은 서버 등등)하고 공부하는 것이 힘들었다. 극복하는 원동력은 좋은 친구, 동료들 덕분에 즐겁게 일했다(좀 빤한가?)

     김문정 부장

• 엔지니어로 취급되지 않는 곳에 입사햇다. 커피 심부름, 책상닦기를 당연 시 하는 분위기였다. 정보를 놓치지 않기위해 흡연실도 따라다녔고 회식도 4차, 5차까지 참석했다. 이것이 정답이라고 할 순 없지만 남자와 다르지 않다는 것을 보이려고 했다.
• 3년차에 기획을 해보고싶어 2년동안 기획일을 했다. 후에 다시 개발로 돌아가고 싶었지만 정통 개발이 아닌 다른 것을 해보고 싶었다. 그 때 MS의 테스트 분야를 모집한다고 하여 들어오게 되었다.
  전세계 테스터들과 함께 극한 경쟁을 느꼈지만 자신에게 잘 맞는 일이라 즐거웠다. 어릴 때부터 옷에 결점도 잘 찾고 길거리에 죽은 쥐도 혼자 볼 만큼 관찰력이 뛰었던 것을 보면 자신에게 잘 맞는 일을 찾는 것도 중요했다.

2. 모두 관리자 역할도 하고 계신데, 나이 직책 등으로 인해 팀원을 핸들링하는데 에로사항은 없었는지,또 어떤 직원이 바람직하다고 생각하는지?

     김문정 부장

• 동료로서 같이 나아가는 관계가 되려고 노력한다. 개발자들은 고집이 세서 잘하는 점은 충분히 인정한다. 또한 관리자로서 자신이 잘못하는 부분이 있기 때문에 그 역시 인정하여 같이 발전하도록 한다.
• 또한 팀원들이 하나의 일을 꼭 해서 스스로 발전하도록 해준다.

     조인순 부장

• MS의 1:1 면담 시간을 충분히 활용한다. 이 시간을 위해 미리 준비시키고 그에 대한 답변을 준다. 팀원에게 매니저가 잘한다고 생각하는 점과 본인이 잘하는 점, 또한 매니저와 본인이 잘못하는 점이 무엇인지 미리 써오도록하고 그것을 보고 함께 충분히 이야기 한다. 특히 남자직원들 처럼 회식 등으로 풀지 못하는 점이 많이 이 방법이 유용했다.

3. 회사에 신입사원이 없다. 자신이 과장인데 아직도 막내이다. 키우다가 도망가고 지쳐버리는 후배도 많이 보았다. 이 점에 대해 어떻게 생각하시는가?

• MS도 높은 직급의 사람들은 많다. 모르는 사람에게 기술지원하라고 할 수 없어서 신입을 뽑지 않았었지만 이래서는 오래가지 못하겠다고 생각하여 신입을 뽑아 교육을 시키고 있다. 문화적인 차이도 있고 우리도 이런 교육을 시켜본 경험이 없어서 어려웠다. 오히려 업무가 늘어나는 양상을 보이기도 한다.
• 초년생들에게 사회가 원하는 사람이 되도록 준비해달라고 부탁하고 싶다.

4. 자기계발은 어떻게 언제 하시는지?
     
     김문정 부장

• 끊임없이 공부해야한다. 하지 않는 순간 도태된다.
• 철저하게 자기 관리 스케줄을 잡아라.

     조인순 부장

• 70% 업무, 20% 동료, 10% 교육이나 책에서 배운다.
• 일을하면서 배우는 것이 가장 좋다. 일을 하되 좀 더 신경쓰고 깊게 보자.

     김지영 부장

• 그룹 세미나, 스터디, 시험 등을 목표로 공부했었다. 남편의 지원이 큰 도움이 됬다.

     윤현경 차장

• 집안일 다하고 공부못한다. 포기 할 건 포기해야한다.(웃음)

5. 목표를 어떻게 정확하게 잡을 수 있나?

     조인순 부장

• 자기가 하고 싶은 것에 대해 정의해야 한다. 그것은 누가 해줄 수 있는 것이 아니라 스스로 해야하는 것이다. 그것조차 없다면 할 말이 없다. 그리고 자신이 잘 할 수 있는 것을 찾는 것도 방법 중에 하나이다.
  

6. 결혼? 출산? 육아 해야하는가?
     
     김지영 부장

• 키워줄 아이디어만 있으면 낳아라. 출산은 정말 소중한 경험이다. 일만 성공하면 반만 성공이라고 생각했다.
  요즘 아이들은 성숙해서 잘 이해해 준다. 그 대신 주말은 온전히 가정에 충실히 한다.

     조인순 부장

• 결혼 초에 칼퇴하는 남편에게 모든 걸 맞추려고 해서 힘들었다. 혼자 힘들게 맞추려 하지 말고 남편과 대화로 조율하려는 노력이 필요했다.
  아이가 고민하게 만드는 순간을 만들기는 하지만, 일하는데 장애는 결코 아니다.

     김문정 부장

• 성순된 나를 만들고 책임감있는 나를 만드는데 아이의 존재는 크다. 또한 아이가 있다면 상대방을 이해하는 폭이 넓어진다.

7. 마지막으로 후배들에게 조언

     김지영 부장

• 여기 모인 분들은 부지런하고 이쁘다. 목표가 있는게 좋았다. 목표를 세워라. 경험도 많이 쌓아라. 코딩만 하는 사람이 개발자는 아니다.
• 직군마다 블루오션이 있다. 선구자로써 나아가라. 그리고 기회되면 잡아라.

     조인순 부장

• 첫째, 매너를 갖춘 멋진 여성이 되라. 주변사람이 좋은 인상을 얻게 되고 좋은 인적 네트워크가 생긴다.
• 둘째, 긍정적인 사람이 되라. 부정적인 사람이 내는 성과와 긍정적인 사람이 내는 성과는 다르다.

     김문정 부장

• 어디서 일하든 열정을 갖고하면 남들이 뭐라고 하던 자기가 만족하는 순간이 온다.
  성공하길...
  
  
   

몇번의 이벤트 도전 끝에 참석할 수 있었던 미래의 인터넷 경제 컨퍼런스의 후기를 적어볼까합니다. 여느 때와 마찬가지로 많은 용어가 튀어나오고 정의하고 설명하기도 했지만, 그저 Web2.0 이 무엇인지, Web3.0 이 무엇인지에 대한 정의를 내리고만다기 보다는 미래의 웹이 어떻게 나아갈지 함께 고민해보고 방향을 잡으려는 노력을 볼 수 있는 자리였습니다. 오전에는 Keynote 3개가 진행되었고 오후에는 3개의 트랙으로 나누어졌습니다. 중요한 키노트들과 다른 트랙들은 같이 참석해 주신 분들이 전파해 주실 것이라고 믿고(?)  저는 제가 들은 트랙 중에 공유하고 싶은 강의 하나를 소개합니다.

제가 들은 트랙은 RIA, Silverlight, Mashup 등 기술적인 트렌드 요소가 강한 트랙이었는데요. 그 중에 가장 인상깊었던 강의는 오랜만에 뵙는 전정환 이사님의 "HCI/RIA를 통한 미래가치 창출"에 대한 강의였습니다. 다음 한메일 Express를 개발하면서 겪게된 어려웠던 점과 개선을 위해 들인 노력이 지금의 우리의 모습과 많이 닮아있어 이렇게 엔블로그를 통해 사내 전달하고 싶습니다.

  한메일 Express는 처음에 프로젝트를 할지 말지를 고민하는 상황이었다고 하네요. 그 때 종이 프로토타이핑부터 해보셨다고 합니다. 실제 개발이 아니라 종이에 그리고 접어 만든 프로토타입으로 개발 시간과 노력을 줄이고 프로그램을 쉽게 시뮬레이션 해볼 수가 있었다고요~ 이 방법은 우리 개발실에서도 하는 방법인데요. 원하시면 READY(개인화된 콘텐츠 배포 시스템)의 종이 프로토타이핑이 완성되면 공개해 드릴수도 있을 것 같네요.^^

  두번째로는 디자인이 포함되지 않은 상태에서의 기민한 개발입니다. 여기서 디자인은 프로그램 설계가 아닌 그래픽컬한 디자인을 말하는 것이지요, 디자인이 처음부터 입혀져 있으면 보기엔 예쁘지만 개발의 기민성은 떨어집니다. 개발자분들은 공감을 하시겠지요? ^^ 그래서 디자인 입히는 것을 뒤로 미루어 두는 것이지요. 하지만 무조건 미룬다는 것은 아닙니다. Closed Beta 처럼 기능적인 요소가 마무리 된 후에는 당연히 그래픽 작업이 입혀져야 하겠지요.

  세번째는 피드백입니다. 팀원들(프로젝트 구성원이라고 할 수도 있겠지요.) 간에 자신을 업무를 떠나서 서로에게 많은 피드백을 주는 것입니다. 프로그램의 궁극적 목표는 사용자에게 좋은 경험을 주는 것, 좋은 가치를 주는 것이지요. 그래픽 디자이너가 제품 기획에 대해 이야기할 수도 있고, 개발자가 디자인에 대해서 이야기할 수도 있지요. 또한 팀원들 뿐아니라 사용자의 피드백을 받는 것도 중요합니다. 제품이 출시되고 나서가 아니라 프로젝트 초기에 사용성 테스트가 이루어져야 합니다. 그래야 실제 사용자가 원하는 기능, 만족, 경험을 줄 수가 있겠지요.

  피드백과 기민한 개발이 이루어지기 위해서는 반복적인 개발을 할 수 있어야 합니다. 한번 정해진 코드나 스펙을 되돌릴 수 없는 폭포수가 아니라 요구사항, 설계, 구현, 테스트, 디자인이 평가를 통해 다시 이루어질 수 있는 별(star) 모양이 되어야 앞에서 이야기 한 것을 이룰 수가 있습니다. 많은 피드백을 받아 제품에 반영시키고 다시 피드백을 받는 작업은 자칫 재작업이라는 느낌을 주기가 쉽지요. 이런 생각에 대한 공감대가 팀 구성원간에 협의되야 합니다. 반복적인 개발 방법은 재작업이 아니라 사용자에게 만족을 주기 위한 제품을 만들기 위한 노력의 일환인 것이지요.

제가 너무 이야기기 길어진 것 같습니다. 강의를 간략하게 MindMap으로 정리하며 들은 내용을 곱씹어봅니다.

이 글은 스프링노트에서 작성되었습니다.