가방 새로 하나 구입

배낭도 메보다가 크로스백(?)도 메보다가 영 마음에 안들길래 몇달간 고민끝에 새로 산 가방. LEXON LN 652 모델. lexon 가방 특징 중 하나가 알루미늄 소재의 손잡이라서 겨울에 손시려울것 같은데 이 녀석은 가방 손잡이 재질이 고무로 되어있어서 한결 나을듯 하다. 여기저기 수납공간도 깔끔하게 여러개 있고. 무엇보다 반한 것은 어깨에 둘러메었을 때 손잡이가 가방 안으로 저절로 스르르~ 들어가서 완전히 숨겨진다는 것. 다만 한가지 애매했던 것이, 가방의 소재가 촘촘한 패턴의 매끈한 신규원단이라고 하는데 주위에서 이 원단에 대한 평이 좋질 않았다. 꺾이는 부분이 잘 헤진다는 것. 그런데 매장에 가서 실제로 보니 다른 가방들은 홈페이지에서 본 새 원단이었는데 이 가방만큼은 다행이도 기존 원단이었다. 가방이 큼직한 편이라서 도시락이며 책, 헤드폰까지 넣고 다녀도 충분할 듯 하다. ㅎㅎ 위 링크는 교보 핫트랙 매장으로 걸어놨지만 실제 구입은 서울역 CONCOS에서 샀다. 여기 lexon 매장은 항상 그러는지 모르겠으나 갈때마다 늘 5% 할인 판매중...

매너좋은 운전자 소리 듣는 팁 3가지

매너좋은 운전자 소리 듣는 팁 3가지. 1. 비상등.

• 끼어들기 한 후 끼어들기, 차선변경을 마친 후 여유가 되면 오른손을 가볍게 들어서 뒷유리를 통해 볼 수 있도록 해주는 편이 더 인간적이긴 하지만, 워낙 유리창에 이른바 썬팅을 진하게 하고 다니는 차들이 많아서 손을 들어도 뒷차에서는 잘 안보인다. 급하게 끼어든 경우는 물론 내가 끼어들어서 차간거리가 꽤 좁아졌다면 비상등 또는 수신호로 감사의 뜻을 전하자. 당신(뒷차)의 존재를 알고 있고 내 끼어들기를 방해하지 않아서 고마우며 결과적으로 차간거리가 좁아졌으니 주의하라는 의미다. 수신호 또는 비상등 중 편한것으로. (딴 얘기지만, 면허 처음 딴 날 차 끌고 나왔는데 내 앞으로 끼어든 택시가 고맙다고 비상등 켜다가 자기 앞차가 급정지한걸 못보고 박은 일이 있다.-_-;; )
• 교차로,횡단보도 앞 급정거 시 황색신호에는 교차로에 새로 진입하면 안되지만 내 뒷차는 얼른 진입해서 지나가야겠다고 생각할 수 있다. 교차로가 가까워지면 언제 황색불로 바뀌더라도 급정지 할 수 있도록 준비하는게 좋다. 만약 교차로 진입전에 황색신호로 바뀌어 (급)정지를 하게 되었다면 룸밀러로 신속하게 뒷차가 있는지 확인한 후 거리가 가깝거나 속도를 충분히 늦추고 있지 않다면 추돌방지를 위해 감속과 함께 비상등 켜도록 하자.

2. 손인사

• 마주 지나칠 때 양보한 차에게. 골목길을 지날 때 먼저 상대편이 나 먼저 지나가라고 골목 입구 한켠에 차를 붙여주는 경우에, 내가 그 차를 지나치면서 창문 내리고 손바닥을 들어서 인사해주자. 아니면 그냥 고개를 꾸벅 하고 지나가도 괜찮다. 물론 이때 전방주시에 방해받아서는 안되겠지만.
• 끼어드는 차에게. 차가 많이 밀려있고 큰길로 합류하려는 차는 좁은 차 틈 사이로 끼어들기 위해 진땀 빼고 있을 것이다. 이때 내 앞으로 끼어들라는 의미로 상대방 운전자와 눈 마주치고 손을 상대방이 보이는 위치 (조수석 창문쪽 또는 앞유리쪽)으로 뻗어서, 내 앞으로 들어오라고 손짓해주면 된다.
• 내가 끼어들어야 할 때 끼어들려고 하는 쪽의 차가 깜빡이만으로 거리를 벌려주지 않을 때는 창문을 내리고 손을 가볍게 들어서 보여주면 정말 놀랄만큼 높은 비율로 끼어들 공간을 마련해준다. 경험상 좌측 차선으로 끼어들 때 창문으로 손내밀어서 양해를 구했을 때 이를 무시하고 들이미는 차는 거의 없었다.

3. 전조등 끄기

• 야간, 내리막길 또는 코너에서 마주쳐 지나갈 때 좁은 골목길에서 마주쳐 지나갈 때, 깜깜한 국도에서 내가 안쪽 높은 코너에서 바깥쪽으로 오는 상대방 차를 비추며 마주쳐 지나갈 때 전조등을 미등 또는 잠깐 안개등으로 바꿔서, 상대방으로 하여금 강한 불빛에 현혹되지 않도록 배려해줄 수 있다.
• 주차장에서 주차 또는 출차중인 차와 마주칠때 야간이나 지하 주차장 이용시 주차장 통로를 지나갈 때 통로를 막고 주차 또는 출차중인 차와 마주칠 수 있는데 이때 전조등을 꺼주면 좁은 주차구역 내에 주차하려는 차는 조급하지 않게 차량을 조작할 수 있다. 환하게 불을 비추고 있으면 빨리 통로를 비켜줘야한다는 압박감에 긴장하여 예기치않은 실수를 할 수도 있다. 느긋하게 기다릴테니 안전하게 주차 또는 출차하시라는 의미로 전조등을 잠시 꺼주는 것이다.

이 사진은 예전에 찍은 사진인데, 앞 검정차량 운전자가 차 양쪽 뒷문을 모두 열고 뒷좌석 먼지와 쓰레기를 치우는 도중 왼쪽 주차하는 회색 RV차량이 계속 전조등을 켠 채로 앞뒤로 왔다갔다 주차하느라 검정 승용차 운전자가 눈부셔서 결국 청소하던 것을 멈춘 상황.

어뷰징(abusing), 어뷰저에 대한 생각

abuser, 영어사전에서 찾아보면 악용하는 사람, 남용하는 사람이라고 나와있습니다만 이 글에서는 어뷰저라고 부르고 그런 행동은 어뷰징이라 하겠습니다. 서비스를 만들고 운영하다보면 다양한 형태의 어뷰저들을 목격할 수 있습니다. 대체 뭘 어떻게 해야 어뷰저인가,라는 것은 서비스마다 다를 수 있습니다. 같은 행동을 하더라도 어느 서비스에서는 어뷰징이라고 판단할 수 있지만 다른 서비스에서는 그 정도는 용납할 수 있다고 볼 수도 있습니다. 심지어 보는 관점에 따라 어뷰징일수도 있고 서비스가 (기획한 방향과는 다를 수는 있지만) 새로운 방향의 활성화 신호일 수도 있습니다. 각 서비스마다 제공하는 기능과 추구하는 가치가 다른만큼 무엇이 어뷰징이다 하고 한마디로 규정하기는 어려운데요, 경험상 보면 서비스의 정상적인 이용과 관계없이 다량의 데이타를 넣거나 빼는 행위, 다른 사용자의 이용을 방해하거나 불쾌감을 주고 서비스의 품질을 떨어뜨리는 행동 등을 들 수 있습니다. 게시판에 수백개의 글을 쓴다거나, 대용량 이미지 파일을 올리고 조회수 많은 외부 사이트에서 핫링크하여 사용하는 것, 위치기반 서비스에서 하루사이에 수백군데 장소에서 체크인 하는 것도 어뷰징의 범위에 포함될 수 있습니다. 물론 스팸,광고 댓글이나 음란,악플성 댓글도 어뷰징으로 볼 수 있습니다. 각 서비스 별로 어뷰징에 대한 정의와 관점이 다른 만큼 어뷰징에 대한 대응도 다를 수 있습니다. 그러나 무작정 방치하게 되면 선의의 사용자들에게 피해가 가고 서버,회선 관리비용의 증가 그리고 애초 기획했던 서비스의 성장,발전 방향에 차질이 생길 수 있으니 마냥 바라만 보고 있을 수는 없습니다. 어뷰징으로 보이는 행동이 관찰되면 가장 먼저 할 일은 이것이 해킹(크래킹, 보안상 구멍)이냐 아니면 정상적인 서비스 접근과 이용의 결과냐 하는 것을 알아내야 합니다. 정상적으로 컨텐츠를 작성하는 경로를 따르지 않고 이른바 뒷구멍(?)으로 임의의 데이타를 쏨으로써 서비스에 글,컨텐츠를 전송하고 있다면 이건 무엇보다 시급하게 고쳐야할 큰 문제입니다. 해킹이 아니라 정상적인 경로로 접근한 사용자라면 다른 해결 방법을 찾아봐야 합니다. 먼저 살펴볼 것은, 어뷰징을 해서 이 사용자가 얻으려는 이익이 무엇인가를 관찰하는 것입니다. 단지 자료저장창고로 쓰려는 것인지, 일시적인 호기심이나 과시욕인지, 다른 어뷰징을 위한 테스트로 삼고 있는 것인지, 많이 뭐뭐하시면 추첨을 통해 상품을 드립니다 하는 이벤트 응모를 위한 것인지 등등이 이유가 될 수 있겠지요. 어뷰저의 목적에 따라 정말, 그냥 하루이틀사이에 그 난리법석이던 어뷰저가 흔적도 없이 영문도 모르게 사라져버릴 수도 있습니다. 가장 먼저 시도해 볼 수 있는 대응방법은, 빨리 실행할 수 있고 비용도 가장 낮고 쉽지만 한편으로는 어려운 방법인 "직접 접촉" 입니다. 서비스내에서 제공하고 있는 쪽지,메일등을 이용해서 지금 하고 있는 행동이 다른 사용자에게 피해를 주고 있고 서비스에도 지장이 있음을 알리고 자제해주길 부탁하는 것입니다. 여기에 약관을 들먹이며 이용에 제약이 있을 수 있다는 것을 언급하는 것은 약이 될수도, 독이 될 수도 있습니다. 뭐라고 권하기는 어렵네요. (무책임-_-;;) 우회적으로 완곡하게 표현하거나 아니면 다음번 쪽지에 언급하는 정도가 어떨까 싶습니다. 쪽지나 메일을 쓸 때는 정중하게, 쪽지와 메일은 상대방에 의해 언제든 공개될 수 있다는 점을 염두에 두고 작성해야 합니다. 기계적이거나 강압적이지 않고 인간적인 대응을 한다는 점에서 의외로 효과가 있을 수 있습니다. 물론 어뷰저가 읽지 않거나 무시해버릴 수도 있겠지요. 슬퍼하진 마시고... 그 다음으로 시도해볼 수 있는 방법은 어뷰징으로 인한 이익을 제거 또는 축소시키는 방안이 있습니다. 많은 글이나 데이타를 올렸을 때 서비스에서 얻을 수 있는 포인트, 레벨, 순위를 산술적인 수량 위주 계산법을 사용하지 않는 것입니다. 굳이 계량화를 해야겠다면 컨텐츠의 질로, 그로 인해 얻을 수 있는 다른 사용자, 방문자의 호응, 평판으로, 전체적인 서비스의 활성화와 사용자들이 그로부터 얻는 가치에 기여하는 항목을 찾아서 그에 대한 보상을 하는 것이 낫습니다. 서비스상에 실시간 컨텐츠를 최근순부터 타임라인으로 배치하는 것은 잘 관리되고 있을 때에는 괜찮은데 그렇지 않을 경우에는 원치않는 글이 무더기로 노출되고 심지어 쓰레기 전시장이 될 수 있다는 점을 염두에 두어야 합니다. 물론 서비스가 활성화되지 않아 며칠이고 일주일이고 같은 글이 "최신글" 항목에 고정적으로 보여지지 않는다는 확신이 먼저 있어야겠지요. 기술적으로 어뷰징에 대한 제한을 만드는 것은 가장 마지막으로 해야할 방법입니다. 이것은 정상적인 서비스 사용자 중 열성적인 사용자(이른바 헤비유저)도 불편해질 수 있습니다. 어뷰저인지 아닌지를 판단하기도 어려운데 어뷰저와 정상적인 유저의 행동을 구분해서 여기까지는 여뷰징, 여기까지는 OK라고 구분하기는 더 어려운 일이지요. 어뷰저를 막으려다가 서비스를 이끌어가고 있는 열성 사용자들을 떠나게 만들 수도 있습니다. 또한 사용자의 행동마다 이것이 허용범위를 넘었는지 안넘었는지를 체크해서 허용,비허용 또는 제한적 허용(나는 어뷰저가 아니오, 라는 증명을 하도록 허들을 뛰어넘게 하고 장대높이뛰기를 시키는 행위들)은 시스템에 부하를 줘서 서비스 성능을 떨어뜨릴 수 있습니다. 사용자가 많아지게 되면 이 과정은 서비스 사용자 모두를 불편하게 할 수 있습니다. 또한 기술적인 어뷰징 방지 대책은 가장 비용이 많이 드는 대응이기도 합니다. 기존 진행하던 업무 시간을 빼서 사용자가 하는 주요한 행동에 어뷰징을 막기 위한 과정을 추가하고 검증하고 실서버에 배포하는데 많은 시간과 기회비용이 들어가게 됩니다. 그럴만한 가치가 있다고 충분히 판단될 때에 사용해야할 방법입니다. 어뷰저에 대한 대응은 생기고 나서 하는것보다 어뷰저가 생기지 않도록 미리 주의깊게 서비스와 시스템을 구성하는 것이 가장 좋습니다. 어뷰징에 대한 대응이라는 것은 어떻게든 제약을 만들고 기존에는 가능했던 것을 불가능하게 또는 불편하게 만드는 것이므로 어느정도의 사용자 불만을 감수할 수 밖에 없습니다. 애초부터 "서비스 오픈했습니다. 우리 서비스는 이런 서비스입니다."하는 것과 "우리 서비스는 오늘부터 이거는 안되고 이거는 100번까지만 되도록 바뀌었습니다." 하는 것은 설령 그 기능을 하루에 10번만 썼던 사용자라 하더라도 뭔가 손해본다는 느낌을 받곤 합니다. 사용자 커뮤니티에서 자연스럽게 필터링이 되거나 자정작용이 일어나도록 서비스를 만드는 것도 중요한 어뷰징 해결방법일 수 있습니다만 "사용자 커뮤니티"를 만든다는 것이 말이 쉽지 어뷰징 막는것보다 1000배는 어려운 일이니 여기서는 일단 빼고 이야기를 하였습니다. (비슷한 용어로 생태계, 선순환 등이 있습니다.) 마지막으로, 어뷰저에 대한 대응을 할 때 잊지 말아야할 것은 이 대응이 이용약관, 개인정보보호정책 및 관계법령을 위반하지 않는 범위에서 해야 한다는 것입니다. 어느 사용자가 하루에 현실적으로 불가능한 데이타를 서비스에 써 놓고 있다하더라도, 비공개댓글로 누군가에게 악플을 달고 있다하더라도 운영자가 자사 서비스라는 이유로 이 데이터를 임의로 열어보고 사용자를 추적하는 용도로 사용할 수는 없습니다. 법무팀, 고객서비스팀 등에 문의하여 이러한 정보를 열람하는데 필요한 절차를 밟아서 법적으로 문제가 없는지를 늘 확인하고 진행하여야 합니다. 해당 회원에 대해, 또 해당 어뷰징 행동에 대한 제약을 할 때도 마찬가지로 약관,정책, 공지사항등에서 규정하고 보장하고 있는 회원의 권리를 침해하지 않도록 충분히 검토하고 실행하여야 합니다. 방치하면 저절로 해결될수도(응?), 서비스를 운영자가 예측하지 못한 새로운 방법으로 활성화를 시킬수도 있고 반면 서비스를 완전히 난장판으로 만들어서 사용자들을 떠나게하고 서비스를 망가뜨릴 수도 있는 어뷰징. 열심히 만든 서비스, 어뷰저에 대한 적절한 대책으로 잘 운영해나가시길 바랍니다.

전주 한옥민박 갔다가 외풍 제대로 체험했습니다.

지난 주말 전주에 갔다가 숙소는 한옥마을에 잡았습니다. 전주시청 홈페이지에 여러 한옥 민박집이 소개되어 있더군요. 숙박비도 저렴했고 한옥의 운치도 느낄 수 있겠거니 싶어서 정한거였는데요. 결론적으로는 요 몇년사이 어딘가를 여행가거나 숙소를 잡았던 선택 중에서 가장 큰 실수였습니다. 누우면 등은 뜨거우나 외풍이라고 하는, 밖에서 새어들어오는 바람이 콧잔등을 시리게하고 이불밖으로 팔 꺼내놓으면 팔,어깨까지 서늘하게 식습니다. 이불 속에 팔 넣으면 땀나고 그래서 팔 빼면 어깨 시리고, 이러지도 저러지도 못할 상황에서 엎드렸다 누웠다 하면서 이리저리 뒤척이며 잠을 설쳤네요. 어렸을 때 할머니댁에서 겪어본 외풍이 생각나면서 아, 왜 진작 이 생각을 못했을까... 후회해봤지만 이미 늦었지요. 덕분에 이번주 내내 코감기에 몸살까지 얹혀서 고생중입니다. 혹한기에는 한옥에 숙소 구하실 때는 외풍은 없는지 미리 충분히 확인하시고 묵으시길 바랍니다.

요즘 음악 듣는 방법

유료 음악 스트리밍, 다운로드 서비스도 써보고 이러저러한 스트리밍 라디오 방송도 들어보다가 요즘 컴 작업중엔 주로 이렇게 듣습니다. 필요한 준비물은

1. 음악 재생 플레이어 winamp
2. 방송국 선곡을 위해 shoutcast.com
3. 플레이어와 방송국을 쉽게 실행시키기 위한 launchy

먼저 윈앰프를 설치합니다. 만약 *.pls 를 재생할 수 있는 다른 플레이어가 있다면 그걸 설치해도 상관없을겁니다. 그리고 shoutcast.com 에서 마음에 드는 방송국을 선택합니다. 방송국 이름을 클릭하면 웹브라우저상에서 바로 방송을 들을 수 있으니 어느 방송국이 취향에 맞는지 들어보고 결정합니다. 결정했다면 방송국 이름을 마우스 오른쪽버튼으로 클릭하여 다른이름으로 대상을 저장 합니다. 재생목록을 저장하는 파일인 *.pls 파일로 저장이 될 것입니다. 저장된 이름을 그대로 두어도 되지만 알아보기 전 알아보기 편하게 "올드팝.pls" 이런식으로 이름을 바꿔두었습니다. 그리고 키보드로 프로그램을 실행시키는 launchy를 설치합니다. launchy는 손에 익으면 원하는 프로그램을 실행할 때 마우스로 시작버튼을 누르고 프로그램을 찾는 과정없이 1초내로 원하는 프로그램을 실행시킬 수 있습니다. launchy를 불러내기 위해 ctrl + space 를 누르면 화면 중간에 launchy 입력창이 나오는데 여기에 인덱싱 된 프로그램 이름의 일부를 쳐 넣으면 해당 프로그램이 실행됩니다. launchy를 설치한 후에 설정메뉴 (위 캡춰에서 오른쪽 위 톱니바퀴 모양 아이콘)을 눌러서 calalog 에 아까 저장해둔 pls의 폴더와 확장자를 추가하여 인덱싱 시킵니다. 이 다음부터는 올드팝 방송을 듣고 싶으면 ctrl + space 를 누르고 올ㄷ 까지만 쳐도 올드팝.pls 가 미리보기로 추천되는데 엔터를 치면 바로 음악재생 프로그램이 실행됩니다. 버퍼링 시간 포함해도 어떤 컴퓨터 작업을 하고 있더라도 5초 남짓이면 지정한 shoutcast 방송국을 재생시킬 수 있게 됩니다. 방송을 듣다가 마음에 드는 곡이 나오면 winamp의 제목줄을 더블클릭하면 노래제목 정보가 나오니 노래 파일을 받고 싶으면 이 정보를 참고하면 되겠지요.

아이폰4용 핀로 슬라이스3케이스, 얇긴 얇네요.

전에 써오던 아이폰 케이스인 에어자켓이 깨져서 새 케이스를 찾아봤습니다. 에어자켓이 케이스 중에서는 얇은 편에 속하는 녀석이었는데요 두어번의 추락에서 나름 아이폰 흠집을 잘 막아주었습니다. 얇은 케이스를 선호하는지라 더 얇은 녀석이 없나 찾다가 발견한 Pinlo의 슬라이스(slice) 3. 두께 0.35mm 라고 합니다. 국내에서도 팔긴하는데 일부 색상만 수입이 되었습니다. 제가 찾는 검정반투명은 없더군요. 결국 이베이에서 주문. 18.9$ 주었습니다. 배송비 5$이 아까워서 이왕 주문하는 김에 2개 주문했고요. 지난주 화요일에 주문하고 오늘 받았으니 8일 걸린 셈입니다. 샛노란 뽁뽁이 봉투에 담겨올 줄 알았는데 의외로 상자입니다. 2개라서 그런가봅니다. 각각 원래의 개별포장에 비닐봉투에 한번씩 더 넣어서 왔습니다. 별도의 완충재는 없었는데 다행이 파손이나 흠집은 없었습니다. 개별 포장입니다. 트레이싱지 같은 느낌이 나는 띠지가 한겹 둘러있습니다. 박스 아래쪽 띠지에 인쇄된 내용입니다. 이러저러한게 들어있다고 합니다. 포장케이스의 양옆 두군데 스티커를 떼어내면 뚜껑이 열립니다. 반투명이고 무광입니다. 이런이런. 이렇게 얇나요? 조금 과장해본다면 케이스라기보다는 케이스형태를 한 두툼한 일체형 보호필름으로 봐야하지 않나 싶습니다. 에어자켓도 얇지만 두께는 핀로 슬라이스3 쪽이 체감할 수 있을만큼 더 얇습니다. 아이폰에 끼운 모습입니다. 사진엔 두툼하게 나왔는데 실제론 무척 얇습니다. 보시다시피 버튼마다 딱 맞춰서 구멍이 파여있기 때문에 아이폰4와 4s용 잘 알아보고 사야합니다. 물론 얇다보니 떨어뜨렸을 때 충격보호 효과는 두툼한 케이스보다는 떨어질것으로 예상합니다. 그래도 두툼한 고무재질 케이스 아닌 다음에야 아스팔트 바닥에 철푸덕 떨어지는데는 장사없다는 생각이고요. ㅋ 아이폰4 케이스는 무조건 얇아야한다는 생각을 하는 분들께는 추천할만한 제품입니다. 에어자켓은 매끈한 표면이었는데 이 녀석은 무광이 보여주는 느낌만큼의 미세한 표면질감이 있습니다. 손톱으로 꾹 눌러서 긁어보면 지나간 자국이 바로 남네요. 전 이 정도는 감수할 수 있을만큼 얇은 두께에 만족해하는 중입니다. [업데이트]@2011/12/14 08:00 같이 들어있는 보호필름 사진을 빼먹었네요. 제품 포장안에 들은 흰색 얇은 상자를 꺼냅니다. 저 안에 보호필름이 들어있습니다. 붙이기전에 아이폰을 닦는 천, 보호필름, 기포제거용 플라스틱조각 그리고 케이스 분해방법을 설명한 쪽지가 들어있습니다. 오른쪽 아래, 왼쪽 아래 순서로 들어내라는군요. 필름 품질은 그냥저냥~

연하장을 보낼 때다.

친구들과 한 해 동안 일어난 기쁜 일과 고생한 일을 서로 나누며 술잔을 기울일 궁리도 물론 해야하지만;; 한글자 한글자 꾹꾹 눌러 써서 감사한 마음을 전하는걸 잊어선 안되는 분들이 있다.

기획자,PM 입장에서 본 QA

유,무선을 막론하고 인터넷 서비스를 오픈하기 전 내부적으로 검수를 받는 QA (Quality Assurance) 서비스나 회사 특성상 내부 조직에서 할 수도 있고 별도의 외부 전담부서에서 진행할 수도 있습니다. 대상이나 방법론 역시 각 서비스마다 고유한 양식을 갖고 있을 겁니다. QA는 서비스 품질 관리상 필수적인 절차이면서도 버그가 발견되면 오류 수정과 그로 인한 실서버 적용 일정에 차질을 빚을 수 있으므로 (즉, 일정 연기의 부담 또는 부득이한 야근 등) 서비스 실무부서에서는 심한 스트레스를 받는 과정이기도 합니다. QA를 진행하는 부서, 테스터 입장이 아닌 QA를 받는 기획, PM 입장에서 그동안 겪은 QA를 바탕으로 몇가지 생각을 정리해 봅니다. 위에서도 말했지만 QA는 회사마다,서비스마다 규모와 절차가 다르니 아래 내용은 읽는 분의 상황에 따라 맞지 않을 수도 있음을 염두에 둬 주세요. 1. QA 전

• TC(Test Case) 작성 테스터들이 실제로 테스트를 진행해야하는 각각의 항목을 명시한 표를 말합니다. TC는 서비스 규모에 따라 적게는 수십개 항목에서 많게는 수백개, 수천개가 되기도 합니다.
• TC를 작성할 때는 테스트 하는 내용과 규모에 따라 다릅니다만 보통 서비스의 핵심 과업 및 메뉴구조에 따라 서비스가 제공하는 기능과 화면 메세지, 오류 처리 방법을 명시합니다. 메뉴를 사이트맵이나 트리구조처럼 늘어놓고 각각의 메뉴에서 제공하는 기능과 메세지를 정리하여 빠지는 기능이 없도록 TC를 작성합니다. 물론 개선,변경된 부분이 있으면 그 부분에 대해서만 QA를 할 수도 있고 그 부분 때문에 다른 쪽에서 오류가 발생할 수도 있기 때문에 전체를 다 QA하는 경우도 있습니다.
• 명확한 테스트 케이스와 결과 표시 TC를 작성하면서 자주 저지르기 쉬운 오류는 TC의 내용과 결과물을 명확하게 서술하지 않는 것입니다. 기획자나 개발,운영 등 해당 서비스에 관여하고 있는 사람이 서비스를 이해하는 정도와 QA조직에서 해당 서비스를 이해하는 정도는 서로 다릅니다. 예를 들어 "A라고 써 있는 버튼을 눌렀을 때 ㄱ의 세부 내용이 잘 표시되는가?" 라고 쓰면 테스터들은 "잘 표시"가 어떤 내용이 어떤 방식으로 화면의 어디부터 어디까지 얼마동안 표시되어야하는지 알 수가 없습니다. 오랫동안 서비스를 들여다본 사람 입장에서는 당연하다고 생각하는 항목이 다른 사람에게는 전혀 그렇지 않을 수 있지요. 예를 들어 화면에 텍스트를 표시할 때 화면을 넘치는 글을 줄바꿈할지, 점(...)으로 표시할지, 왼쪽으로 천천히 스크롤 시킬지, 그냥 잘라내버릴지, 어떤 화면이 과연 "잘" 나오는 것인지 알 수 없습니다. 올바른 출력 예를 화면 캡춰그림과 함께 보여주면 좋습니다.
• 테스터용 환경 셋업 (네트워크, 위치정보, 로그인 정보, 호스트 정보 ) 테스터들이 사용할 장비, 네트워크, 프로그램, 로그인 계정, 호스트 정보들을 미리 정리하여 테스트에 문제가 없도록 준비해야 합니다. 특히 QA조직이 다른 네트워크, 다른 위치에 있는 경우는 각별히 조심해야 합니다. 대부분의 개발서버는 외부에서의 접근을 차단 또는 제한하고 있으므로 테스터가 QA도중 서비스 접속이 안되거나 잘못된 서버로 연결되어 엉뚱한 결과를 얻을 수 있습니다. QA조직에서는 그래서 QA 전날 또는 당일 오전 일찍 QA환경점검을 하기도 합니다만 이 단계에서 전체적인 서비스 테스트 환경을 모두 체크하기는 어렵습니다. 서비스의 구조와 동작방식을 알고 있는 서비스팀과 개발조직에서 테스터들의 QA환경에서도 문제가 없는지 미리 점검해야 합니다.
• 주요 오류에 대한 사전 점검 TC 작성과 아울러 QA전에 충분한 사전 테스트를 하는 것이 매우 중요합니다. 각 메뉴별로, 각 기능별로는 물론 주요 사용자 스토리별로도 테스트를 해봅니다. 서비스를 개편했거나 기능을 개선한 것이면 해당 기능 자체는 물론 영향을 받을 수 있는 다른 기능에 대해서도 주의를 기울여 살펴봐야 합니다. 이 점에 대해서는 개발자에게 사전에 의견을 들어보는 것이 좋겠지요.
• 놓치지 말고 체크해야할, 자주 나오는 오류케이스
  • 입력칸에 잘못된 값(html태그, 특수문자, 비정상적으로 긴 문자열, 빈 공백, 큰 이미지 첨부 등)을 넣었을 때에 대한 처리를 빼먹었을 때
  • 브라우저 메뉴에서 뒤로와 앞으로를 반복할 때 페이지의 전체 또는 일부 영역이 제대로 표시되지 않는 경우 (폼 입력값 위주로)
  • 사용자가 URL을 직접 치고 들어 올 때에 대한 준비 미흡
  • 초기에 아무런 데이타도 들어 있지 않은 경우와 서비스에 오류가 났을 때 출력할 화면 준비 미흡. (오류시 서버가 내뱉는 오류메세지를 그대로 화면에 출력하는 경우를 "내장이 튀어나왔다"고 할 정도로 부끄러워하는 기획자들도 있습니다.)
  • 레이어가 서로 잘못 얹혀지거나 위 레이어가 아래 레이어 영향을 끼쳐 기능이나 화면 표시가 겹치거나 가리는 현상

2. QA 진행중 QA중엔 테스트 중 문제가 보고되진 않는지 만약 그렇다면 어떤 문제인지에 대해 여러 부서. 담당자와 시간을 다투며 문제를 파악하느라 정신이 없습니다. 일시적인 문제일 수도 있고 개발이나 디자인 과정에서의 오류가 있을 수도 있습니다. 그러나 짜증내고 누구를 질책할 일이 아닙니다. QA에서 나오는 오류에 대한 책임은 꼼꼼하게 챙기지 못한 기획자와 PM에게 있다고 생각합니다. 손발은 바쁘지만 마음은 도를 닦는 자세로 침착하게 상황을 판단하고 이슈들을 정리해나가시길 바랍니다.

• 기능 질의에 대한 대답 테스터들은 기획서와 TC를 참고로 테스트를 합니다. 그런데 실제로 서비스를 만들다보면 애초 기획서와 달라지는 부분이 생길 수 있습니다. 이걸 다시 기획서에 반영을 해놓으면 좋은데 그러지 못하는 경우가 종종 있죠. 이러면 테스터들은 기획자에게 해당 현상을 문의하게 됩니다. 기획서에는 디자인 한겹 올린 예쁜 오류메세지가 그려져 있는데 실제로는 시스템 기본 경고 오류상자가 나온다든가 말이죠. 이게 오류인지 아니면 일정상 또는 기술적인 문제로 제외된 기능 (이른바 Spec out이라고 하는) 것인지에 대해 바로바로 대답을 해주어야 합니다. 물론 그보다는 QA전에 미리 이러한 점에 대해 정리를 해서 테스터들에게 공유를 하는 편이 더 좋습니다. 마치 책 오탈자에 대해 뒷표지 안쪽에 정오표를 첨부하는 것 처럼.
• 진짜 문제가 나타났다. 이렇게 현상에 대해 설명 또는 정의를 하면 되는 간단한 경우외에 진짜로 문제가 생기는 경우들이 있습니다. QA중 이상 현상이 나오면 테스터는 재현되는 현상인지를 확인한 후에 PM에게 직접 또는 QM이라는 QA책임자를 통해 담당기획자에게 이 현상에 대한 문의를 하게 됩니다. 기획자(또는 PM)은 이 현상의 원인을 파악하여 알려줘야 하는데, 원인을 찾는 과정이 쉽지 않습니다. 기획단계에서 그렇게 동작되도록 한 것인지 아니면 정말 오류인지, 오류라면 프로그램상의 문제인지 API 문제인지 네트워크 문제인지 그것도 아니면 또 다른 문제인지를 파악하기 위해서 해당 서비스의 기획자,개발자, 디자이너,UI개발자, 네트워크 엔지니어 등과 빠르게 문제점을 파악하여 회신하여야 합니다. 이것은 테스트에 소요되는 시간에 대한 문제이기도 하고 오류판정의 등급에도 영향을 끼치는 일입니다. 이 과정 때문에 QA가 진행되는 시간 동안에는 서비스에 관계된 실무자나 실무책임자와 계속 연락이 되는 상태를 유지해야 하고 그러기 위해선 미리부터 QA일정을 통보하고 이에 대한 협조를 구해야 합니다. 만약 PM이 이들에게 QA 일정에 대한 공유를 하지 않았다면 당사자가 QA날에 휴가를 냈어도 할 말이 없는거죠.

3. QA를 마치고

• 판정 등급에 대한 검토와 어필 QA가 끝나면 QA과정에서 발견된 문제점을 정리하고 이 문제가 심각한 문제인지 아니면 사소한 문제인지 QA담당부서에서 등급을 매겨 옵니다. 화면에 나와야할 글자가 나오지 않았다면 CSS 오류일 수도 있고 DB 입출력에 문제가 있을 수도 있고 아니면 API에서 값을 못 불러왔을 수도 있겠지요. 사실 사용자 입장에서 보면 글씨가 나오지 않았다는 것이 중요하지 우주전쟁으로 외계인이 데이타센터에 들어와서 서버운영요원들을 납치해가는 바람에 장애가 생겼는지는 상관할 바가 아니긴 하지요. 테스터들은 그 문제가 생긴 원인의 심각성 보다는 사용자 입장에서 겪는 오류와 주요 과업의 실패에 대해 중요하게 생각하는 듯 합니다. 그런데 이 오류라는 것의 심각성이 QA담당자가 생각하는 정도와 기획자가 생각하는 정도가 서로 다를 수 있습니다. 예를 들어 입력칸에 아무것도 넣지 않고 글 작성 완료 버튼을 눌렀는데 "내용을 입력해주세요"라는 오류메세지 없이 그냥 제목없는 결과물이 나왔다고 칩시다. 테스터들 입장에서는 이 오류를 심각한 오류로 판단할 수 있습니다. 일반적인 경우에선 오류일 수 있습니다. 그러나 새로운 모든 서비스들이 기존 서비스들의 평균적인 인터페이스를 제공해야만 하는 것은 아닙니다. 예를 들어 비공개 개인 다이어리에서 제목이 없는 경우 본문의 앞부분을 제목처럼 사용하는 기능을 도입했을 수 있습니다. 이 경우에는 오류가 아니겠지요. 스마트폰에서 사진등을 자기 자신에게 메일 첨부파일로 보내는 경우가 있는데 이렇게 자신에게 메일 첨부를 보낼 때에 한해서 제목없는 메일에 대한 경고문 없이 바로 보내는 경우도 생각해 볼 수 있습니다. 기획자는 "우리 서비스에서는 이러저러한 이유로 그렇게 하기로 했다"고 이야기할 것이고 QA에서는 "고객이 혼란스러울것이다.(또는 오류라고 볼 것이다, 또는 실수할 수도 있을 것이다.) 그러니 제목없이 작성완료 버튼을 눌렀을때에는 경고창을 띄우는 것이 좋겠다."고 제안을 할 수 있을 것입니다. 합당한 제안이라면 수락하면 될 것이고 그보다 더 중요하게 생각하는 명분이나 실익이 있다면 다시 설득을 해 볼 수 있겠지요. 적당한 선에서 포기하느냐, 다른 절차를 밟아서 이를 관철 또는 조정하느냐는 각각 회사마다, 경우에 따라 또 사람에 따라 다를 것이기 때문에 어떻게 하는게 맞다고 말하긴 어렵습니다. 경험상 QA 마무리 단계에서 의견충돌이 있기 마련이고 조정 과정에서 극심한 스트레스를 겪게 되곤 하더군요. 그러나 서로 회사로부터 부여받은 권한과 의무에 따라 각자의 일을 하고 있는 것임을 잊지말고 공식적인 절차에 따라 (쉽진 않지만) 차분하게 설명하고 우아하게 설득하는 자세가 필요합니다.

곰곰히 생각해보면 기획자,PM으로서 QA를 할 때 가장 중요한 것은 서비스와 기능에 대한 충분한 이해와 문서화 능력, 그리고 각 QA 및 유관부서 담당자와의 원활한 대화능력이라고 생각합니다. QA는 필요악이 아니라 반드시 필요한 당연한 과정입니다. 다만 내가 검토해서 오류가 없다고 확신한 항목, 또 미처 살펴보지 못한 부분에 대한 오류들이 검출되고 또한 서비스를 만들면서 옳다고 생각했던 세계관에 대한 반론이 들어오는 것에 대한 대응 과정이 상당히 스트레스 받고 피곤한 과정이어서 힘든 것입니다. 서비스가 세상에 나오기 전 마지막 산고 단계인 QA과정, 스트레스 어차피 받으시겠지만 그러려니 하고 모든 실력과 품성을 최고조로 발휘해서 즐겁게 잘 하시기 바랍니다. ^^;

머리로 정리하기 어려우면 눈으로 보면서 하기

엊그제 앱에서 일부 프로세스를 정리할 일이 있었습니다. 두가지 항목에 대해서 각각 참일때와 거짓일때 조합 즉 4가지 경우에 대해서 그리고 두번째 항목의 값은 나중에 거짓에서 참으로 바꿀 수 있어서 거기에 대한 고려도 해야 했습니다. 대충 순서도로 분기할 지점과 동작에 대해서 연필로 그려봅니다. 분량과 복잡도, 익숙한 정도에 따라 마인드맵으로 해도 되고 메모장의 들여쓰기 내어쓰기로 해도 됩니다. (첨부한 사진들은, 회사 일이다보니 어느정도 흐릿하게 하였습니다. 대략 분위기만 봐주세요.) 순서도로 대충 파악한 다음엔, 실제로 표시될 화면을 캡춰해서 프린트한 후 1,2,3,4 번호를 매기고 얼럿,메세지 창에는 A,B,C라고 이름을 붙였습니다. 순서도를 하나하나 따라가보면서 1-A 2-A 이런식으로 경우의 수를 그려나갑니다. 그런데 이렇게 해놓고 보니 화면의 이름도 아니고 숫자와 알파벳으로 이루어진 프로세스는 눈에 들어오질 않네요. 헷갈리고 정신이 없습니다. 결국 필요한 화면과 메세지를 캡춰도 하고 그림으로 그려서 여러벌 프린트해서 잘라 놨습니다. 각각의 경우에 따라 화면에 표시되는 페이지와 메세지를 따로따로 만들어보려고 합니다. 빈 A4용지에 재접착이 가능한 풀칠을 하고 화면을 하나하나 붙여나갔습니다. 경고창이나 확인/취소 창도 풀칠해서 화면위에 덧붙였습니다. 영역이 더 필요하면 빈 용지를 붙여나갔습니다. 분기할 지점에서는 아래쪽에 새 옵션에 따른 화면을 그려나가고 색색 견출지로 선택한 옵션을 써서 붙이고 필요하다면 포스트잇으로 설명도 붙입니다. 이렇게 붙여놓으니까 좀 정리가 되네요. 프리젠테이션 도구로 그렸으면 한 화면에 볼 수 있는 공간의 제약으로 일목요연하게 정리하기 어려웠을 겁니다. 물론 개발자에게 저 이어붙인 A4용지를 주며 개발을 부탁할 수는 없는 일이죠. 전체 구조를 하나의 화면에 작게 그리고 메세지와 확인/취소창의 위치를 표시해줍니다. 위 페이지에서 경우에 따라 표시될 화면 이름과 메세지의 구조를 파악했다면 실제로는 어떤 화면인지를 그린 화면을 첨부해서 이해를 돕도록 했습니다. 서로 같이 일하고 있어서 무슨 페이지라고 하면 서로 모를리 없지만 만에 하나 서로 다르게 알고 있는 경우도 있을 수 있으니 명확한 화면을 명시해서 서로 공유하는게 좋죠. 가끔 이렇게 아날로그적인 방법을 사용해보면 훨씬 일이 수월해지기도 합니다.

아이폰 잠금화면에 긴급연락처를...

아이폰에 잠금화면에 긴급 연락처를 적어두길 제안하는 글을 읽고 얼른 만들어 보았다. 지금 쓰고 있는 배경화면에 글씨를 올릴 영역을 반투명 레이어로 올리고 아내의 전화번호를 적어두었는데 알림창이 나오면 글자가 서로 겹칠 수 있으므로 가리지 않는 적당한 곳에 자리를 잡았다. 세상살이. 별일없이 잘 살길 바라지만 행여나 내 뜻대로 되지 않는 안좋은 상황이 일어나게 될 때엔 사랑하는 사람이 빨리 알아야 하지 않겠나... 물론 이런 상황이 오면 안되겠지만 말이다. 게다가 이렇게 번호 적어두면 핸드폰 잃어버린걸 누가 주워서 돌려주려고 할 때에도 유용할게다.