플러그인처럼 동작하다보니 파워포인트의 모든 기능을 사용하며 추가적인 위젯을 끼워넣을 수 있다는 것이 장점입니다. 라이브러리를 보니 기존 그리기 도구의 도형들을 결합해서 그룹화한 아이콘들이 많습니다. (물론 개개인이 이걸 일일이 손으로 한다면 꽤 오랜 시간이 걸렸겠지요.)

파워포인트 기본 도형으로 만들던 목업을 보조해주는 정도로 생각하는게 좋을 듯 합니다.

펜션 대문앞 우체통입니다.

정원 안쪽에서 본 모습입니다. 사장님이 정원 끝에 나무로 쉼터를 만들고 계시더군요. 아이들이 잔디밭에서 뛰노는걸 엄마들이 앉아서 볼 수 있는 용도라고 하시네요. 저 자리는 사실 노을에 물드는 석양을 바라보기 좋은 자리이기도 합니다.

전날 비가 와서 그런지 공기도 더 맑은듯하고…

철쭉이 곱게 졌습니다.

안채 뒷편 언덕아래 벤치입니다. 느긋하게 앉아서 완만한 언덕위를 바라보면 꽃과 나무, 건물과 하늘이 그림처럼 펼쳐져 보이는 자리입니다.

LOVE… 보이시죠? ㅎ

색이 참 곱던 꽃인데 이름을 모르겠습니다.

작업실같은 곳 문이 열렸길래 들여다 봤더니 창문이 이렇게 꾸며져있네요. +_+

원두막 카페에서 찍은 잔디밭입니다. 저쪽 건너편에 한창 쉼터 공간이 만들어지고 있네요. 결국 이날 저녁에 사장님은 이 쉼터를 완성하시더군요.

수풀속 그네입니다. 여자분들이 특히 좋아하신다고…

오후 늦게 근처 바닷가로 나갔습니다. 차로 3분쯤 되는 거리에 있는 조그만 바닷가입니다. 저 멀리 탄도항과 오른쪽에 누에섬이 보입니다. 물이 빠지면 누에섬까지 걸어갈 수 있고 섬에 있는 전망대와 전시관을 구경할 수 있지요. 가는길 중간에 승마장이 있습니다. 구경하는건 공짜에요~ ^^

물이 빠지니 잘 포장되어 있는 길이 나타납니다. 끝이 보이면 좀 걸어갔다 오려고 했는데 한도 끝도 없어보여서 그냥 중간까지만 걸어갔다 왔습니다. 예전에 누에섬 전망대에서 보니 갯벌 중간까지 트럭이 사람들을 태우고 갯벌체험하러 들어오던데 그때 쓰는 길이 아닌가 조심스레 짐작만 해봅니다.

해가 기울기 시작하고 그림자는 조금씩 길어지기 시작합니다.

ㅎㅎ 위에서 본 그네의 앞쪽 모습입니다. 느긋하게 그네에 몸을 맡기면 ‘으허허 좋다…’소리가 절로 납니다.

객실이 있는 건물과 잔디밭, 그리고 안채입니다. 맨발로 잔디밭 걸어다니기 참 좋을 때 입니다.

펜션 정문에서 잔디밭으로 가는 길에 볼 수 있는 하트모양 바닥입니다.

식당 공간과 그릴 준비하는 곳입니다. 다양한 크기의 그릴이 준비되어 있네요. 왼쪽에 보이는 큰 그릴, 저도 한번 써 봤는데요. 꼬치(스큐어)요리와 훈제바베큐가 한번에 기가막히게 되더군요. 오른쪽에 보이는 조그만 지붕이 그네 위치입니다.

때깔이 고와서 찍어봤습니다. 꽃과 나무며, 왼쪽 해가 있는 밝게 빛나는 하늘과 오른쪽 해가 없는 반대쪽 하늘이 반사된 푸르스름한 색깔…

이것도 색이 이뻐서 찍은 사진입니다. 바닥 물통에도 몇개의 꽃이 떨어져있는데 자연스럽고 곱더라고요. 어렸을때 보던 포푸리 꽃주머니 색깔 같기도 하고…

그네 뒷편으로 돌아가면 해뜨락카페가 있습니다. 셀프로 차 가져다가 마시면 됩니다. ㅎ

1층의 또 다른 한쪽 면입니다.

펜션 밖 길가 산책하다 찍은 질경입니다. 인근에 포도밭도 있고 길가 조그만 공간마다 여러 작물들이 심어져 있어서 산책하다가 쭈그리고 앉아서 구경하는 재미가 솔솔합니다.

그 다음에 여러개 링크 중에서 가장 중요하다고 생각하는 기사 한두개만 맨 위로 올려서 서너줄 정도 요약을 한 형태로 한번 바뀌었고…

그렇게 한 몇달 했나보다. 이달초부터 신입사원 몇명이 팀에 새로 들어왔고 누군가 한명이 기사 스크랩 업무를 넘겨받았다. 처음 며칠은 이전 메일과 다르지 않고 같은 모양으로 메일을 보냈다.

지난주부턴가 메일 양식이 확 바뀌었는데 여태까지 위에서 아래로 목록처럼 구성된 페이지를, 업계소식, 서비스 소식, 응용 서비스 소식 이렇게 세 컬럼으로 구성된 표로 바꾸고 표의 각 칸에는 기사제목과 링크, 주요 키워드를 포함한 내용 일부 그리고 자신이 생각하는 중요도에 따라 매긴 별점을 넣어서 보내오고 있다. 메일의 맨 아래에는 각 구분에 대한 설명, 별점 기준에 대한 꼬리말도 꼼꼼하게 붙여놓았다.

확실히 기존 스크랩 메일보다 눈에도 잘 들어오고 읽기 편해졌다. 반복적인 일상업무를 가치있게 만들고 평범했던 일을 중요하게 만드는 것은 쉽지 않은 일이다. 막내 신입사원은 그걸 시도하고 있고 가시적인 반응을 이끌어 냈으니 이게 바로 그토록 자주 언급되는 “작은 성공의 경험”을 가지게 된 셈이다.

스크랩 메일은 어차피 귀찮은 일이다. 그러니 그러한 포맷의 업무를 신입에게 시켰던 것일테고. 그러나 다른 편으로 생각해보면 아침마다 팀 전체에게 메일을 쏠 수 있다는 건 작지만 일종의 미디어를 갖고 있다는 것이다. 여기에 무엇을 어떻게 담느냐에 따라 이 메일의 가치는 더 높아질 수 있고 결국 자신의 메일을 받아보는 모든 팀 동료와 상사 들에게 자신의 역량과 관심사를 자연스럽게게 어필할 수 있는 기회가 된다는 이야기다.

지금은 야밤이나 휴일에 급하게 사원증으로 사무실 열고 들어올 일은 없어도 그때의 습관이 남아있나보다. 휴일에 놀러나갈 때 새 바지를 갈아입어도 사원증은 왼쪽 앞주머니에 항상 옮겨놓으니.. ㅎ;

이벤트를 열려고 한다는 것은 서비스 제공자가 요구하는 행동 (응모, 참여, 구입 등…)을 한 사용자에게 선착순이든 추첨이든 경품을 지급할 대상과 기준을 정하는 것을 뜻합니다. 이벤트에 몇명이 참여할지는 아무도 모릅니다. 주최측이 정하는건 당첨자의 숫자이고 그에 맞는 예산을 확보한 후 유,무형의 경품을 당첨자들에게 나눠줄 실무적인 준비를 하는 것입니다. 그런데 이벤트 당첨자의 숫자를 제한하지 않는 경우가 있습니다. 종종 우리가 보는 100% 당첨 어쩌고 하는 경품들의 예죠. 이런 경품은 당첨 경품이 추가적인 마케팅 수단으로 활용되는 경우입니다. 다음 구매시 10% 할인권이라든가, 얼마 이상 구매시 사용할 수 있는 쿠폰이라든가 재구매,재방문,신규회원가입 등의 조건을 거는 것들이지요.

그런데 이러한 고려없이 당첨자 숫자를 무제한으로 열어두는 경우, 특히 참여자가 들여야하는 노력이 간단하고 그에 반해 경품이 매력적인 경우에는 경품 응모자가 예상외로 폭주할 수 있습니다. 각종 경품 카페와 커뮤니티를 통해 이벤트 정보는 순식간에 전파가 되며 이벤트 참여자가 몰려들고 경품 당첨자는 처음 예상했던 당첨자의 수십배, 수백배 규모로 커질 수 있습니다. 이렇게 되면 예산은 물론 당첨자 선정문제, 경품 지급 문제, 고객불만 처리등의 문제들이 생겨나게 되며 처리해야 하는 업무량은 산술적인 차이보다 더 커지게 되는데요 이것은 마치 80kg짜리 역기를 5번 들 수 있는 사람이라고 해도 400kg 짜리 역기는 꿈쩍도 할 수 없는 상황과 비슷합니다. 복잡도는 기하급수적으로 증가하며 적은 수로 예상했었던 당첨자의 경우에는 존재하지 않았을 문제들이 새로이 만들어지기도 합니다.

사실 이렇게 부작용이 생겨도 서비스에 긍정적인 영향을 끼치면 좋긴 한데 대개 이벤트로 생겨난 트래픽의 99%는 이벤트가 끝남과 동시에 아주 빠르게 예전 트래픽을 회복합니다. 이벤트 카페,게시판, 경품 정보 사이트를 보면 하루에도 수백개의 이벤트가 올라오고 당첨정보가 공유됩니다.

진행하려는 이벤트가 경품만을 목적으로 빠르게 이벤트 과제만을 완료하고 서비스를 빠져나가는 사람들에게 장악되지 않을 수 있는지 세심하게 고민할 필요가 있습니다.

이벤트를 기획할 때에는 “경품걸고 배너 노출하면 사용자들은 오겠죠” 가 아니라 지금 하는 이 이벤트가, 목표로 하고 있는 성과를 위해 의미있는 내용인지, 이 이벤트가 목표로 하고 있는 사용자들은 누구이며 그들은 어떤 식으로 이 이벤트를 알게 되고 무슨 생각으로 참여한 후, 주위에 왜, 어떻게 알릴 것인지 “말이 되는 이야기”가 있어야 합니다.

여기서 사이트를 제거하기 위해선 robots.txt 로 수집 및 노출을 제어할 수 있습니다. 다만 웹호스팅을 이전했을 때 로봇파일 설정을 깜빡했다거나 (이건 짐작입니다만) 로봇텍스트 파일을 설정할 수 없는 서비스, 그러니까 도메인은 설정할 수 있게 해주지만 로봇텍스트에 대한 설정을 제공하지 않는 서비스를 이용하게 되면 다시 예전 사이트 내용이 나타날 가능성이 있습니다.

인터넷아카이브 팀에 문의하니 도메인 소유자의 삭제 의사가 명확하고 이걸 몇가지 방법으로 자기네가 확인할 수 있다면 웨이백 머신에서 삭제가 가능하다는 회신을 받았습니다. (사실 완전히 데이터를 지우는지 아니면 다만 표시하지 않기로 한 것인지에 대해서는 묻지 않았습니다.)

전 whois로 확인 할 수 있는 도메인 소유자의 이메일로 삭제 의사를 보낸 후, 해당 서버의 소유자만이 파일을 작성할 수 있는 곳에 삭제의사를 거듭 명시한 텍스트 파일을 만들어서 이 URL을 보내주었습니다.

첫번째 그림은 robots.txt 로 접근제어 하였을 때의 화면이고 두번째 그림은 삭제요청하여 제거된 후의 화면입니다. 메세지가 서로 다르다는 것을 확인할 수 있습니다.

[robots.txt 사용했을 때 조회 화면]

[도메인 소유자의 제거요청 후 조회 화면]

예전부터 국내 전자서점들이 지원하는 단말기들도 고려해봤었는데 보고싶은 책은 늘 전자책으로 없더군요. 마치 옷가게 문 열고 XXL사이즈 옷이 있는지를 먼저 물어보고나서 그 치수가 나오는 디자인의 옷만 사야하는 것처럼… (이건 zip파일 뭉탱이로 돌아다니는 무협지나 수필류의 txt 파일도 마찬가지고요. )

그럴바에는 (우스꽝스럽긴 하지만) 마음편하게 전자책으로 책보는건 아예 포기하고 다른 컨텐츠를 채우기로 했습니다. 그걸 지원하는 다양한 내외부 서비스가 있는 킨들을 선택한 것이고요.

구독하는 블로그들이 요즘보면 업데이트가 예전보단 뜸해졌지만 그래도 꾸준히 글을 쓰시는 분들이 계시고 잊지않고 새 글이 올라오면 찾아가서 읽곤합니다. 그러나 바쁘다는 핑계로 RSS리더기(구글리더)를 잘 안열게되고 구독목록에는 안읽은 글이 수십개, 심지어 1000+ 라는 표시가 늘어갑니다.

그래서 킨들을 블로그리더기로 활용하기로 했습니다.

이용한 서비스는 두가지인데요. 하나는 kindlefeeder.com 입니다. 여기는 무료는 12개까지 블로그를 등록할 수 있고 피드를 긁어모아 킨들 메일 계정으로 쏴줄 수 있습니다. 아시다시피 그러면 킨들이 네트워크에 물렸을 때 자동으로 다운받게 되지요. 유료버젼은 연20불인데 피드를 70개까지 등록할 수 있고 요일별로 원하는 시간에 자동으로 킨들 메일계정으로 발송해줍니다. 아, 첨부된 이미지도 더 많이 보내준다는군요. 무료버젼은 첨부이미지가 몇개 안나옵니다. 글씨 위주 블로그면 무료버젼도 충분할 것 같은데 이미지가 여럿 들은 블로그들이라 유료로 쓰고 있습니다. 아침 5시에 피드 수집 후 발송되도록 해놓고 6시에 일어나서 와이파이 켜놓고 씻고 오면 하루동안 새로 올라온 블로그 글들이 킨들에 들어와 있습니다. 여긴 주로 인문,사회 블로그, 컬럼등을 등록해두었습니다.

( calibre로도 RSS를 킨들로 변환할 수 있는 듯한데 매일 컴 앞에 앉아서 그 작업을 하고 싶진 않았고요. )

그리고 점심시간 등엔 RSS 리더기로 정보성 블로그에 새로 올라온 글들의 목록과 대충 내용을 훑어보고, 자세히 봐야겠다 싶은 것들은 sendtoreader.com 으로 보냅니다. 북마클릿(도 된다고 하는데 전 동작하지 않더군요.) 또는 브라우저 플러그인을 설치해서 원하는 페이지에서 보내기 버튼을 누르면 이 또한 현재 글을 킨들에서 읽기 편한 구성으로 바꾼 후 킨들로 전송될 수 있도록 킨들 메일 쪽으로 쏴줍니다.

아이폰도 있고 아이패드도 갖고는 있는데 아침 지하철에서 블로그 보기에는 하나는 너무 작고 하나는 너무 크고 무거웠습니다. 왼손에 가방들고 오른손에 킨들들고 엄지로 딸깍 딸깍 페이지 넘기면서 글 읽기는 정말 편안하고 좋습니다.

아, 그리고 아직 킨들 케이스는 따로 안샀는데 킨들은 다른 디지탈기기보다는 편하게, 험하게(?) 다룰려고 합니다. 가볍고 얇아서 산건데 케이스를 붙이면 그 장점이 사라질까봐 걱정도 되고요. 전자잉크 특성상 따로 전원 끄지 않아도 되니 전철에서 책 읽다가 내릴 때 되면 가방 옆 주머니에 넣고 내리는건 좋네요. 가격도 스마트폰이나 태블릿에 비해서는 꽤 싼 편이니 그 비율만큼 덜 긴장하고 덜 조심하면서 써도 되지 않을까 생각하고 있습니다.

참조 : 킨들(Kindle)을 사용하는 몇 가지 방법들 (많은 도움을 받았습니다.)

lexon 가방 특징 중 하나가 알루미늄 소재의 손잡이라서 겨울에 손시려울것 같은데 이 녀석은 가방 손잡이 재질이 고무로 되어있어서 한결 나을듯 하다. 여기저기 수납공간도 깔끔하게 여러개 있고. 무엇보다 반한 것은 어깨에 둘러메었을 때 손잡이가 가방 안으로 저절로 스르르~ 들어가서 완전히 숨겨진다는 것.

다만 한가지 애매했던 것이, 가방의 소재가 촘촘한 패턴의 매끈한 신규원단이라고 하는데 주위에서 이 원단에 대한 평이 좋질 않았다. 꺾이는 부분이 잘 헤진다는 것. 그런데 매장에 가서 실제로 보니 다른 가방들은 홈페이지에서 본 새 원단이었는데 이 가방만큼은 다행이도 기존 원단이었다.

가방이 큼직한 편이라서 도시락이며 책, 헤드폰까지 넣고 다녀도 충분할 듯 하다. ㅎㅎ 위 링크는 교보 핫트랙 매장으로 걸어놨지만 실제 구입은 서울역 CONCOS에서 샀다. 여기 lexon 매장은 항상 그러는지 모르겠으나 갈때마다 늘 5% 할인 판매중…

1. 비상등.

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

2. 손인사

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

3. 전조등 끄기

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

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

서비스를 만들고 운영하다보면 다양한 형태의 어뷰저들을 목격할 수 있습니다. 대체 뭘 어떻게 해야 어뷰저인가,라는 것은 서비스마다 다를 수 있습니다. 같은 행동을 하더라도 어느 서비스에서는 어뷰징이라고 판단할 수 있지만 다른 서비스에서는 그 정도는 용납할 수 있다고 볼 수도 있습니다. 심지어 보는 관점에 따라 어뷰징일수도 있고 서비스가 (기획한 방향과는 다를 수는 있지만) 새로운 방향의 활성화 신호일 수도 있습니다.

각 서비스마다 제공하는 기능과 추구하는 가치가 다른만큼 무엇이 어뷰징이다 하고 한마디로 규정하기는 어려운데요, 경험상 보면 서비스의 정상적인 이용과 관계없이 다량의 데이타를 넣거나 빼는 행위, 다른 사용자의 이용을 방해하거나 불쾌감을 주고 서비스의 품질을 떨어뜨리는 행동 등을 들 수 있습니다.

게시판에 수백개의 글을 쓴다거나, 대용량 이미지 파일을 올리고 조회수 많은 외부 사이트에서 핫링크하여 사용하는 것, 위치기반 서비스에서 하루사이에 수백군데 장소에서 체크인 하는 것도 어뷰징의 범위에 포함될 수 있습니다. 물론 스팸,광고 댓글이나 음란,악플성 댓글도 어뷰징으로 볼 수 있습니다.

각 서비스 별로 어뷰징에 대한 정의와 관점이 다른 만큼 어뷰징에 대한 대응도 다를 수 있습니다. 그러나 무작정 방치하게 되면 선의의 사용자들에게 피해가 가고 서버,회선 관리비용의 증가 그리고 애초 기획했던 서비스의 성장,발전 방향에 차질이 생길 수 있으니 마냥 바라만 보고 있을 수는 없습니다.

어뷰징으로 보이는 행동이 관찰되면 가장 먼저 할 일은 이것이 해킹(크래킹, 보안상 구멍)이냐 아니면 정상적인 서비스 접근과 이용의 결과냐 하는 것을 알아내야 합니다. 정상적으로 컨텐츠를 작성하는 경로를 따르지 않고 이른바 뒷구멍(?)으로 임의의 데이타를 쏨으로써 서비스에 글,컨텐츠를 전송하고 있다면 이건 무엇보다 시급하게 고쳐야할 큰 문제입니다.

해킹이 아니라 정상적인 경로로 접근한 사용자라면 다른 해결 방법을 찾아봐야 합니다. 먼저 살펴볼 것은, 어뷰징을 해서 이 사용자가 얻으려는 이익이 무엇인가를 관찰하는 것입니다. 단지 자료저장창고로 쓰려는 것인지, 일시적인 호기심이나 과시욕인지, 다른 어뷰징을 위한 테스트로 삼고 있는 것인지, 많이 뭐뭐하시면 추첨을 통해 상품을 드립니다 하는 이벤트 응모를 위한 것인지 등등이 이유가 될 수 있겠지요. 어뷰저의 목적에 따라 정말, 그냥 하루이틀사이에 그 난리법석이던 어뷰저가 흔적도 없이 영문도 모르게 사라져버릴 수도 있습니다.

가장 먼저 시도해 볼 수 있는 대응방법은, 빨리 실행할 수 있고 비용도 가장 낮고 쉽지만 한편으로는 어려운 방법인 “직접 접촉” 입니다. 서비스내에서 제공하고 있는 쪽지,메일등을 이용해서 지금 하고 있는 행동이 다른 사용자에게 피해를 주고 있고 서비스에도 지장이 있음을 알리고 자제해주길 부탁하는 것입니다. 여기에 약관을 들먹이며 이용에 제약이 있을 수 있다는 것을 언급하는 것은 약이 될수도, 독이 될 수도 있습니다. 뭐라고 권하기는 어렵네요. (무책임-_-;;) 우회적으로 완곡하게 표현하거나 아니면 다음번 쪽지에 언급하는 정도가 어떨까 싶습니다.

쪽지나 메일을 쓸 때는 정중하게, 쪽지와 메일은 상대방에 의해 언제든 공개될 수 있다는 점을 염두에 두고 작성해야 합니다. 기계적이거나 강압적이지 않고 인간적인 대응을 한다는 점에서 의외로 효과가 있을 수 있습니다. 물론 어뷰저가 읽지 않거나 무시해버릴 수도 있겠지요. 슬퍼하진 마시고…

그 다음으로 시도해볼 수 있는 방법은 어뷰징으로 인한 이익을 제거 또는 축소시키는 방안이 있습니다. 많은 글이나 데이타를 올렸을 때 서비스에서 얻을 수 있는 포인트, 레벨, 순위를 산술적인 수량 위주 계산법을 사용하지 않는 것입니다. 굳이 계량화를 해야겠다면 컨텐츠의 질로, 그로 인해 얻을 수 있는 다른 사용자, 방문자의 호응, 평판으로, 전체적인 서비스의 활성화와 사용자들이 그로부터 얻는 가치에 기여하는 항목을 찾아서 그에 대한 보상을 하는 것이 낫습니다.

서비스상에 실시간 컨텐츠를 최근순부터 타임라인으로 배치하는 것은 잘 관리되고 있을 때에는 괜찮은데 그렇지 않을 경우에는 원치않는 글이 무더기로 노출되고 심지어 쓰레기 전시장이 될 수 있다는 점을 염두에 두어야 합니다. 물론 서비스가 활성화되지 않아 며칠이고 일주일이고 같은 글이 “최신글” 항목에 고정적으로 보여지지 않는다는 확신이 먼저 있어야겠지요.

기술적으로 어뷰징에 대한 제한을 만드는 것은 가장 마지막으로 해야할 방법입니다. 이것은 정상적인 서비스 사용자 중 열성적인 사용자(이른바 헤비유저)도 불편해질 수 있습니다. 어뷰저인지 아닌지를 판단하기도 어려운데 어뷰저와 정상적인 유저의 행동을 구분해서 여기까지는 여뷰징, 여기까지는 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의 제목줄을 더블클릭하면 노래제목 정보가 나오니 노래 파일을 받고 싶으면 이 정보를 참고하면 되겠지요.

결국 이베이에서 주문. 18.9$ 주었습니다. 배송비 5$이 아까워서 이왕 주문하는 김에 2개 주문했고요. 지난주 화요일에 주문하고 오늘 받았으니 8일 걸린 셈입니다.

샛노란 뽁뽁이 봉투에 담겨올 줄 알았는데 의외로 상자입니다. 2개라서 그런가봅니다.

각각 원래의 개별포장에 비닐봉투에 한번씩 더 넣어서 왔습니다. 별도의 완충재는 없었는데 다행이 파손이나 흠집은 없었습니다.

개별 포장입니다. 트레이싱지 같은 느낌이 나는 띠지가 한겹 둘러있습니다.

박스 아래쪽 띠지에 인쇄된 내용입니다. 이러저러한게 들어있다고 합니다.

포장케이스의 양옆 두군데 스티커를 떼어내면 뚜껑이 열립니다. 반투명이고 무광입니다.

이런이런. 이렇게 얇나요? 조금 과장해본다면 케이스라기보다는 케이스형태를 한 두툼한 일체형 보호필름으로 봐야하지 않나 싶습니다. 에어자켓도 얇지만 두께는 핀로 슬라이스3 쪽이 체감할 수 있을만큼 더 얇습니다.

아이폰에 끼운 모습입니다. 사진엔 두툼하게 나왔는데 실제론 무척 얇습니다. 보시다시피 버튼마다 딱 맞춰서 구멍이 파여있기 때문에 아이폰4와 4s용 잘 알아보고 사야합니다.

물론 얇다보니 떨어뜨렸을 때 충격보호 효과는 두툼한 케이스보다는 떨어질것으로 예상합니다. 그래도 두툼한 고무재질 케이스 아닌 다음에야 아스팔트 바닥에 철푸덕 떨어지는데는 장사없다는 생각이고요. ㅋ

아이폰4 케이스는 무조건 얇아야한다는 생각을 하는 분들께는 추천할만한 제품입니다. 에어자켓은 매끈한 표면이었는데 이 녀석은 무광이 보여주는 느낌만큼의 미세한 표면질감이 있습니다. 손톱으로 꾹 눌러서 긁어보면 지나간 자국이 바로 남네요. 전 이 정도는 감수할 수 있을만큼 얇은 두께에 만족해하는 중입니다.

[업데이트]@2011/12/14 08:00

같이 들어있는 보호필름 사진을 빼먹었네요. 제품 포장안에 들은 흰색 얇은 상자를 꺼냅니다. 저 안에 보호필름이 들어있습니다.

붙이기전에 아이폰을 닦는 천, 보호필름, 기포제거용 플라스틱조각 그리고 케이스 분해방법을 설명한 쪽지가 들어있습니다. 오른쪽 아래, 왼쪽 아래 순서로 들어내라는군요. 필름 품질은 그냥저냥~

한글자 한글자 꾹꾹 눌러 써서 감사한 마음을 전하는걸 잊어선 안되는 분들이 있다.

서비스나 회사 특성상 내부 조직에서 할 수도 있고 별도의 외부 전담부서에서 진행할 수도 있습니다. 대상이나 방법론 역시 각 서비스마다 고유한 양식을 갖고 있을 겁니다. 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과정, 스트레스 어차피 받으시겠지만 그러려니 하고 모든 실력과 품성을 최고조로 발휘해서 즐겁게 잘 하시기 바랍니다. ^^;