새퍼 양파의 런던 일기

아래 글 쓰고 나니까 문득 생각나서.

프로그래머들의 미학 + 연애

(글구 일도 하기 싫고 히히)

----------------------------------

공돌이 성격은 타고나는 것이므로 인문계 남자인척 해보려 해도 소용없다. 아예 상대방을 철저히 공대식으로 이해해서 접근하는 쪽이 성공률이 높다.

애인와의 관계 역시 갑/을 관계로 비교하면 훨씬 간단해진다. 늘 시간은 없고, 예산은 부족하고, 입만 살았지 일은 안 하는 매니저/영업 쪽 사람들은 그저 노력부족이라고 생각한다. 설명하려고 해도 안 통한다.

그나마 같은 회사의 상관이나 영업쪽 사람이면 견딜만 하다. 정말 힘든 건 고객과의 관계다. 죽어라 코딩해서 보여주면 그제서야 자신의 원하는 프로그램은 이게 아님을 깨닫는 인간들이 고객이다. 요구분석 다 해서 사인 받아봤자 해 놓은 거 맘에 안 든다고 투정부리기 마련이고, 돈 받으려면 어떻게든 처리 해야 한다. 정성껏 잘 해준다고 해서 해결되지도 않는다. 괜히 기대치만 높이면 피보기 마련이기 때문에 고객의 기대치 관리 (expectation management) 도 중요하다.

연애에 비교해보자. 상대방, 특히 여자가 원하는 요구사항은 확실하지 않다. ** 때문에 섭섭하다 할 때 **만 고치면 될 거 같은데 그렇지 않다. 자신이 뭘 원하는지는 잘 모르지만 (요구사항 불확실 및 지속적으로 변경) 하여튼 섭섭하다고 하는 건 고객과 하나 다를 바 없다. 처음에 성심껏 잘 해줬다가 '요즘엔 영 성의가 안 보인다'란 말 한마디에 사람 힘빠지게 하는 것 역시 비슷하다. 그야말로 하라는 대로 해도 안 되고, 그렇다고 안 하면 더 문제고, 차라리 요구사항이나 확실하게 해 달라고 해도 불가능한, 고객중에서도 최악의 진상 고객에 해당한다.

이럴 때엔 이공계의 제1법칙을 적용한다. 바로 '요구사항 트리니티'이다. 저렴, 신속, 품질중에 두 가지만 선택할 수 있다는 법칙이다. 저렴하고 신속하면 품질이 개판일 수 밖에 없고, 신속하고 품질이 좋으면 저렴할 수가 없으며, 저렴하면서도 품질까지 좋으면 신속한 처리가 불가능하다. (Fast, Cheap, Good rule).

연애에서는 이 세가지가 약간 변형된다. 연애의 트리니티는 효율성, 만족도, 진실성이다. 진실로 좋아해서 애인의 만족도를 높인 경우는 몸으로 때우는 노가다를 했다는 말이다. 이런 방식은 효율적이지가 않다. 지속하기도 힘들다. 처음에야 정말 계속 보고 싶어서 하루에 스무번 전화하고 문자 백통 주고받았을지 모르나 6개월 후에도 그럴 수는 없다. (우리 보통 다 전화 싫어하지 않는가.) 그리고 지속도가 떨어지면 고객의 기대치 관리는 빵점이다. '처음에는 잘 하더니 이제 날 사랑하지 않나봐' 소리 듣기 마련이다. 초반부터의 조심스러운 계획이 필요하다.

효율적으로 대처하며 진실성까지 있으면 애인 만족이 불가능하다. 이는 '네가 하루에 한 번 전화해주기를 원하니까 내가 한 번씩 전화할게'라고 말하는 시나리오에 해당된다. 진실성으로 만족도 성취를 원하는 애인님은 효율적인 대처에 대한 (공대스러운) 좋은 평가 대신 효율성 추구를 사랑의 부족으로 해석한다.

그러면 마지막 시나리오에 닿는다. 효율적으로 대처하면서 애인님의 만족도까지 성취하려면 진실성을 희생해야 한다. 어쩔 수 없다. 시간 투자가 최소면서 효과는 최대인, 요구사항의 80% 를 시간 투자 20% 로 이끌어 낼 수 있는 방법을 연구하여 실행하되 그 공대적인 대처방침은 비밀로 해야 하는 것이다. 게다가 애인을 사랑하는 것이 거짓이 아닌 이상 '진실성'은 아주 희생한게 아니라 우길 수도 있겠다.

자, 그러면 어떻게 (애인에게 들키지 않으면서) 80% 만족도를 쉽게 이끌어내고, 계속 지속시킬 수 있을까?

제 1 조 거짓말을 한다.

아무리 고객이 진상이라도 '아잇 진상 고객님, 고객님 불만 처리를 위해서 어쩔 수 없이 제가 거짓으로라도 사과 드리겠습니다. 그러면 되겠지요?' 라고 하지 않는다. 애인을 대할때에도 똑같은 방침을 적용한다. 밑도 끝도 없는 요구사항 늘어놓는 것을 나름대로 열심히 요구분석하여 '이렇게 해결하면 될까요?' 라고 대처방안을 제시했는데 버럭 하는 애인님들, 원래 그렇다. 그냥 그렇다고 이해하자. '난 최대한 이 상황에 논리적/합리적으로 대처하려고 하는데 넌 왜 그러냐, 뭘 바라냐'란 말은 하지 말자.

예:

앤님: "난 네가 날 사랑한다는 느낌이 안 들어. 꼭 관리당하는 느낌이야."

하지 말아야 할 말: "'너의 투정'이란 상황을 지금 어떻게 처리해야 하나 고민하고 관리하려는 건 맞아."
모범답안: "그렇게 느꼈다면 정말 미안해. 내가 너 사랑하는 거 알지?"

앤님: "네가 좀 관심을 보여주었으면 좋겠어."

하지 말아야 할 말: "내가 어떻게 하면 관심을 보인다고 네가 느끼겠어?"
모범답안: "사랑해. 앞으로 내가 내 마음 더 보여주려고 노력할게.

여기에서 요구사항을 받아내려는 노력은 여러가지로 위험하다. 왜냐하면 1) 앤님은 '사랑받지 못한다'는 느낌이 들었다는 것이 주요 불만사항이다. 그 상황에서 받아낸 요구사항은 다 차후 변경 가능하다고 보면 된다. 그리고 해결 불가능한 요구사항을 늘어놓을 수도 있으므로 주도권을 잡는 의미에서도 요구사항 말해보라는 대처방법은 피하는 쪽이 좋다. 모범답안은 무조건 "미안해" + "노력할게" 이다. 물론 공돌/공순으로서 내가 잘못한 거 없는데 미안하다고 하려면 장이 꼬이며 피가 터져나갈 거 같은 마음 잘 안다. 그러나 이 정도는 "진상 고객을 패고 싶더라도 끝까지 마음에 없는 사과" 하는 걸로 생각하자. (사실 이거 하기 싫어서라도 공돌/공순들 사람들 대해야 하는 직업을 피하는 거지만, 애인님 딱 한 명 대하는 건데, 이 악물고 참자.)

이 방법의 최고 장점은 "노력할게"에 있다. 이것은 "해결 방안은 내가 생각해서 내가 이행한다"란 말이다. "미안해"는 "불만 접수 되었다"는 말이고, "노력할게"는 "그럼 내가 좀 생각해 보지"이다. 보시다시피 하루에 열 번 전화, 혹은 이벤트, 혹은 선물 등의 요구사항보다 훨씬 더 선택의 폭이 넓다. 고객에 비하자면 "웹사이트를 어떤 언어와 프레임워크로 구현해드릴까요?" 물었다가 J2EE/ERP 껴안고 피토하는 대신 그냥 내 편한 언어 php 등등으로 후다닥 만들어서 주는 방법이라 할 수 있다.

또 애인님과의 대화에서 유의해야 할 점은, 그들의 요구사항은 행동변경 지침이 아니라 '감정적인 상태 전달'이란 것이다. "네가 100일/생일/그 외 기념일 잊어버려서 섭섭해" 라 할 때 "네가 100일/생일/그 외 기념일 잊어버려서 섭섭해" 가 아니라 "네가 100일/생일/그 외 기념일 잊어버려서 섭섭해" 이다. cause - effect 로 생각해선 안 되고, 증명으로 생각해서도 안 된다. 100일까지 챙겨야 하냐, 기념일 챙겨야 하냐, 그걸로 뭐가 섭섭하냐로 싸우면 안 된다는 말이다. 애인님이 '섭섭한 이유지적 및 시정요구'를 바로 하지 않는 이상은 뒤의 "섭섭해" 파트에 집중하자. 우선 그걸 해결한 다음에 애인님 마음이 풀렸으면 혹시 원하시는 특별한 행동변경 사항이 있는지 확인하면 된다. "난 원래 생일 안 챙긴다"라고 답하면 벼락맞는다. 그러나 참회하고 회개함으로 애교를 떨어 섭섭함을 다 푼 다음에 난 원래 생일 안 챙기나, 네가 원한다면 앞으로 기억하겠다고 하면 된다. 보험금 지급 안 되어서 신경질 내는 고객에게 먼저 사과하고 달래놓은 다음에 정관 여기여기에 따르면 지급 안 되는 거라고 차분히 설명하듯이 말이다.

제 2조. 약간의 진실성 희생으로 만족도를 높이는 효율적 모범답안....은 나중에 더 쓸게요. 글이 길어지네요.