본문 바로가기

sCRAP

Agile Development... and UI Designing

전에 CHI 2008에 갔다가, HCI 모임에서 애자일 개발 방법론(agile development process)을 몇 명이나 언급하는 걸 보고 좀 유심히 들여다 본 적이 있다. 이전에도 관련학회의 논문 내용 중에 잠깐씩 언급된 적은 있었지만, 아예 제목에서부터 'agile process'나 'extreme programming'을 언급하고 있는 경우가 무려 6건이나 된다. 그 6건 중에 정작 정식논문(paper)로 발표된 경우는 하나도 없고 죄다 case study, panel, workshop 등의 형태로 발표됐다는 사실은 한편으론 '별 거 아닌가' 싶기도 하고, 한편으론 막 떠오르는 이슈가 보이는 전형적인 모습이기도 하다.


애자일 방법론 자체에 대해서는 위의 링크들과 동영상에 잘 설명되어 있지만, 그냥 간단히 무식용감하게 내지르자면 "회의/문서작업 좀 그만하자. 그냥 후딱 만들어 보고 문제 있으면 수정하는 게 차라리 빠르겠다"는 거다. (내지르고 나서 보니 참으로 과도한 축약이다 -_-; 어쨋든) 요즘은 UI라고 하면 대부분 software UI를 말하기 때문에, 이 '빨리빨리' 방법론이 UI 업계에도 영향을 미치고 있는 것이다. CHI 2008에서의 발표 내용은 대부분 아래 질문에 대한 것이었다.

How do extreme programming and user-centered design fit together?

게다가 재미있는 것은, UI 부서가 늘상 주장하던 (안 그랬다면 문제있다 -_-a ) "프로토타이핑"과 "평가", 그리고 주장하진 않았지만 어쩔 수 없는 숙명 같았던 "반복적 개선"이 이미 이 방법론에도 적용되어 있다는 것이다. 개발하다보면 자연스럽게 자리가 잡히는 개발문서에 시간을 쓰기 보다 그게 잘 만들어졌는지를 검증하는 평가방법론 쪽에 무게가 실렸기 때문이다. 위 그림에서도 노란 영역은 원래의 애자일 프로세스(중간에 쌓여있는 부분이 test & iteration에 대한 부분)이고, 푸르딩딩하게 표시된 UI 부분은 단지 그 프로세스의 흐름에서 이를 막지 않고 '단지 거들뿐'으로 제시되고 있다. (출처: Probing Agile Usability Process, CHI 2008)

사실 학회에 다녀와서 개인적으로 내린 결론은, 원래 논리를 맞추는 직업인 UI 디자인에서는 이미 이 방법론대로 충분히 의사소통을 해오고 있었고, 어차피 시간을 많이 주질 않으니 최대한 빨리 만드느라 별짓을 다 해왔고, 기회만 있다면 어떻게든 사람 앉혀놓고 평가해서 반복/개선하려고 노력했으니... 뭐 딱이 달라질 건 없다는 생각이다.

단지 이게 '굳이' 쓸모가 있다면, 애자일 방법론의 시류에 편승해서 조직 내에서 UI 부서의 입지를 굳혀보자는 정도일까나.... ㅡ_ㅡ+ (번쩍)

아마 학회에서 이 발표를 쫓아다니면서 들은 사람들은 모두 비슷한 생각이었던 것 같다. 질문도 뭔가 애자일 자체에 대한 것보다 개발팀과의 언쟁이 좀 줄더냐. UI 담당자들이 각 애자일팀(scrum)으로 분산되어서 일하면 hit rate가 떨어지지 않느냐. 뭐 그런 내용이었다. 발표장에 흐르는 묘한 동료의식. ㅎㅎㅎ



그러더니, 지난 달에 Jacob Nielsen이 <Agile Development Projects and Usability>라는 제목의 컬럼을 올렸다. 뭐 비록 '좀 더 자세히 보려면 유료 보고서를 참조하시라'는 식으로 끝맺긴 하지만, 그래도 이 장삿꾼 아저씨도 CHI 2008이나 다른 관련학회(아마도)의 흐름이 그냥 예사로 보이진 않았던 모양이다.

컬럼의 내용은 뭐 일반적인 애자일의 UI 실무 입장의 장점 외에도, 조심해야 할 점(애당초 개발자의 발상이기 때문에 설계를 들여다볼 짬이 없으니, 되도록 짧고 빠르게 개발과 병행할 수 있는 UCD 방법론을 선택해야 한다.. 정도?)을 나열하고 있다. 맨날 어차피 바뀔 기능 스펙만 보면서 열심히 개발하고 UI 한다거나, 결국 개발팀에서 개발완료를 해야 들여다보든 테스트하든 할 수 있는데 그래봐야 수정일정 따위 주어지지 않았고 바로 출시일이라든가, 그래서 한방에 제대로 된 사용성 평가 좀 하겠다면 예산과 일정 때문에 택도 없다든가... 이런 UI 실무의 현실이 애자일 방법론의 유행(?)과 더불어 조금 나아지지 않을까 하는 생각이다.

결국 위 컬럼의 맺음말처럼 "기회가 좋으니 열심히 하자"는 거다. ^o^/



(드디어 다 썼다~!!! 도대체 몇주를 쓴거야... orz... 인터넷은 내년 초에나 들어온다고 하고... 점심시간은 짧을 뿐이고... 블로깅 야근은 우울할 뿐이고... OTL... )

  • Favicon of http://www.hanchuljung.com hanchul 2008.12.18 14:23

    먼가 있을듯 싶어서 조금 공부해 봤는데요. Agile Development의 코어인 Extreme Programming(XP)에서 설명하는 test-driven development와 형이 말한 평가(test)의 개념이 조금 다른 것같아 보이네요. 글에서 '개발문서에 시간을 쓰기보다 그게 잘 만들어졌는지 검증'에서의 검증은 이미 만들어 놓은 것에대한 평가를 의미하는 듯 한데(그것이 RP인듯), agile development에서의 (programmer) test는 코딩 시작전에 먼저 test를 작성하여 테스트가 통과될 수 있도록 코딩을 하자라고 이해됩니다. 결국 디자인 프로세스에 있어서 problem definition이나 design specification과 비스무레한 개념인듯 한데요... 아닌가요? 아님 말고..
    거기 살기 좋아요?ㅋ

    • Favicon of http://interaction.tistory.com/ Stan1ey 2008.12.18 18:25

      개발문서보다 검증문서에 시간을 쓴다는 건 알았지만 (무엇보다 지금 하고 있어서 ;ㅁ; ) 테스트에 통과될 수 있도록 코딩을 하자는 방향이었군요. 실제로 좀 극단적이네요. ㅎㅎㅎ ... 그런데 사용성은 휴리스틱스나 가이드라인 외에는 딱이 테스트 기준이랄만한 게 없고 "좋으면 좋다"는 주의니까 참 맞추기 어렵네요. ㅎㅎ

      ps. 와주고 있었구나! 아이폰으로 네 블로그 들어갔더니 아이폰용 UI가 뜨더라는. 멋지구리. 연락 자주 하자.

  • creep 2008.12.19 11:16

    자세히 들여다본 적은 없지만.. 대충 보고 '잉? 지금 회사에서 개발하고 있는 방법과 다른게 뭐지?'라고 접었던 기억이 나네요. 근데, 한국 가셨나요? 뜸하시네요. 한철이 블로그도 있나요? 알려주면.. 심심한 나날에 도움이 될 듯 ;-)

    • Favicon of http://interaction.tistory.com Stan1ey 2008.12.19 17:05

      내 경우에는 방법보다 그걸 어떻게 전략적으로 활용할 지가 먼저 떠올랐던 걸 보면 확실히 회사에서 못된 것만 배운 듯... ㅠㅠ 전에도 올렸지만 집에서 인터넷이 안 되서 글 쓸 시간이 없답니다. -_-;;;;

      아 그리고 블로그는 글쓴이 이름에 링크되어 있습니다.

  • htruth 2008.12.22 18:05

    그걸 전략적으로 쓰기 위해 벌써 한철을 괴롭히고 있는 1인

    • htruth 2008.12.22 18:06

      그러나 Stan1ey 님의 전략과는 좀 많이 다른 의미의 전략이겠지요? ^^
      - 근데 정말 살만한가요?

    • Favicon of http://interaction.tistory.com/ Stan1ey 2008.12.23 05:56

      아... 연구소-센터 역할 구분만 좀 확실히 된다면 뭐 문제 없겠죠. 하지만 왠지 한철 지못미. ㅠ_ㅠ

      그나저나, 왼쪽에 사진 올리는 거 종종 보면, 꽤 잘 살고 있습니다! 정말. :)

  • Favicon of http://dobiho.com dobiho 2008.12.27 16:58

    저도 CHI2008 의 애자일 관련 패널토의를 들었는데요, CHI 가 학술대회임에도 재미 있는 것은 이렇게 아직 학문적으로 자리잡기 전의 실무적인 이슈들을 패널토의 등을 통해서 논의를 하게 하는 것 같습니다. 방법론이니 실증적인 논문이 나오기 어렵겠지만 아마도 몇년 후에는 케이스 스터이 형식의 논문 같은 것이 나올 수도 있을 것 같습니다.

    CHI에서 얘기되는 애자일 방법론을 보노라면 과연 제품 전체 개발 방법론은 누가 오너쉽을 가지고 있는 것일까가 궁금해지더군요.

    • Favicon of http://interaction.tistory.com/ Stan1ey 2008.12.28 09:04

      보통은 영업과 제조, 영업은 기획과 홍보, 제조는 다시 설계와 양산, 설계는 외장과 내부설계, 양산은 제작과 검수, ... 이런 식으로 획장하다 보면 이 와중에 UI에서 오너쉽을 고민하는게 좀 허망할 때도 있더군요.

      가끔은 그냥 각자 담당 분야의 전문성과 책임을 인정하면서 잘 굴러가주면 좋겠는데 말입니다. UI에게는 사용자로서의 고객 입장을 대변한다는 소중한 역할이 있으니, 그걸 굳이 너무 강조하거나 부서를 늘려 세를 키운다는 거 없이 역할에 충실하는 거죠. ㅎㅎ

      현실적으로는 그렇게 소극적(?)으로 운영할 수도 없는 노릇이 니 어쩔 수 없을지도 모르겠습니다. ^_^a