이스오타 : 신뢰의 중요성
중소기업 5년 ~ 11년의 이야기
온라인 사수
개발자는 코딩할 때 궁금한 점이나 개념을 이해하고자 구글 검색을 많이 한다.
예를 들어 뭔가 코딩을 하다가 생성자를 이렇게 쓰는 게 맞나? 생각이 들면 구글에 "hashmap 생성" 이런 식으로 검색을 해서 글을 들어가진 않고 summary처럼 글이 시작되는 요약 글로 몇 줄 나오는 부분을 자주 본다.
실무적으로 개발 관련하여 예전 경력 3년쯤 DB(DataBase) 관련 한 시간 알려주셨을 때 나에겐 단순 select가 아닌 신세계를 본 이후에 DB 관련 글을 많이 찾아보았다.
DB Index도 쉽게 생각하면 책의 목차라는 개념 말고 좀 더 테이블 형식으로 보고 싶었다.
검색하던 중 개인 사이트 같은데 이해하기 쉽게 정리가 잘되어 있는 사이트를 발견하였다.
사이트 자체가 강의 자료 같기도 하면서 도식화된 자료가 많아서 좋았다.
사이트 운영하시는 분은 DBA(DataBaseAdministrator) 이면서 시간강사도 하시는 분 같았다.
나는 DB 이론적인 거보다 WorkingSmart라는 카테고리의 글을 더 좋아했다.
업무적으로 똑똑하게, 영리하게 할 수 있는 방법에 관한 글이 너무 재밌고 힘들 때마다 들어가서 본 것 같다.
나에겐 온라인상의 사수라고 생각했었다.
2015년에(경력 7년) 과장으로 진급하고 사이트 방명록에 감사의 글을 남겼었다.
4년간 사이트 글 보면서 많이 성장했다고 존경하고 감사하다고 글을 올린 적이 있다.
댓글 답변이 어리둥절하지만 도움 돼서 기쁘다며 오늘은 기분이 벅차고 행복할 것 같다고 올려주셨다.
경력 17년 차인 지금도 생각날 때마다 사이트에 접속을 한다.
신뢰의 방정식
위에서 언급한 자주 들어가는 사이트에 신뢰를 얻는 방법에 대한 글을 보았다.
T = (C + R + I) / S
* T: 신뢰(Trust)
* C: 믿음(Credibility)
* R: 예측 가능성(Reliability)
* I: 친밀감(Intimacy)
* S: 이기적 성향(Self-Interest)
신뢰(Trust)는 전문성과 정직함에서 오는 믿음(Credibility)과 약속과 이행이 연결된 경험의 반복, 즉 일관성에 의한 예측 가능성(Reliability),
그리고 감정적인 믿음, 즉 친밀감(Intimacy)을 합한 값을 자기중심성, 즉 이기적 성향(self-interest)으로 나눈 값으로 산출된다.
T = (C+R+I)/S 가 바로 신뢰 방정식이다.
- 데이비드 마이스터, ‘신뢰의 기술’에서
신뢰를 얻으려면 믿음과 예측 가능성은 그만한 실력을 갖추고, 친밀감은 인간성을 갖춰야 된다고 생각을 했다.
이기적 성향은 각자의 성향이니 내가 노력한다고 얻어지는 부분이 아닌 것 같았다.
나에겐 신뢰에 관하여 참 많은 생각을 하게 된 흥미로운 글이라고 생각했다.
말은 참 쉽다.
어느 날 콜센터 팀장인 안B에게 요청이 들어왔다.
요청 사항은 회원사 검색 리스트에 상담내역을 입력하는 작은 영역이 있었는데, 만약 이 부분에 리스트 조회와 별도로 회원사를 팝업으로 검색하고 상담내역을 입력하면 등록과 동시에 회원사가 검색되었다 치고 회원사를 클릭했다 치고 상담내역 탭을 클릭했다 치고 화면 이동을 해달라는 요청이었다.
이게 뭔.. 말도 안 되는 요청인가
말은 참 쉽다.
요청의 요점은 상담내역 등록하면 바로 해당 업체 상담내역 탭 화면으로 이동하게 해달라는 부분이었다.
요청의 이유는 거래 관련 문의라서 예민한 회원사가 통화를 시작하면 마구 쏟아붓는데 업체를 검색해서 자세히 화면을 들어가서 상담내역 화면을 들어가서 상담내역의 이력을 확인하고 대응해야 하는데 상담내역 탭 화면까지 들어가는 동안 회원사가 통화로 얘기하는 일부를 까먹기 일쑤였기 때문에 가능하면 해달라는 내용이었다.
우리 메인 거래 사이트는 기존 ASP에서 Java, Jsp로 정말 리뉴얼한 상태였지만, 백오피스(관리 시스템)은 ASP 구조였고 필요에 따라서 Jsp를 혼용으로 쓰고 있는 상태였다.
말도 안 되는 요청입니다. 딱 잘라 거절해도 될 사안이었지만
순간 신뢰의 방정식이 생각이 났다.
안B와는 믿음, 예측 가능성, 친밀감 모두 높았기 때문에 개인적인 성향인 나의 성향만 높게 생각하면 안 D와의 신뢰를 생각했을 때 해줘야겠다는 생각이 들었다.
참고로 우리 개발팀은 콜센터 여직원들이랑 항상 친하게 지내왔었다.
재입사 했을 때도 안B가 제일 반겨주셨다.
일도 잘하고 요청에 대한 정리도 잘한다고 항상 나를 좋아해 주셨다.
우리 독수리 오형제중 첫째 퇴사한 상태였지만 진D, 넷째인 최D(나의 선배) 콜센터 여직원과 사내커플로 연애를 하다가 결혼까지 했었다.
월말엔 거래가 많아서 콜센터 팀과 개발팀은 항상 지옥처럼 바빴기 때문에 안돼도 되게 해주고 싶었다.
우선 안B에게 소스 파악하고 가능한지 일주일의 시간을 달라고 하고 거의 5년 만에 ASP 소스를 분석하기 시작했다.
우선 ASP와 Jsp 문법의 차이와 화면 이동에 대한 로직들을 분석하고 정리하였다.
상담내역을 등록하는 시점의 화면 이동이기 때문에 DB Transaction이 일어나는 화면엔 보이지 않는 뒷담 파일에서 화면 이동 시점을 잡아야 하기 때문에 소스 분석이 필요했다.
요청 사항 그대로 클릭했다 치자 하면서 특정 화면에서 클릭했을 때를 가정하여 이동하는 건 개발자로서 용납이 되지 않았고 등록하는 시점에 값들을 찾아서 명확하게 상담내역 탭으로 전달하면 문제가 없어 보였다.
보름 정도에 요청 사항 그대로 구현해 주었다.
콜센터 팀장님부터 콜센터 직원들까지 너무 좋다고 칭찬을 많이 받은 것 같다.
해당 기능이 생기고 나서 회원사 검색 화면에서 대충 상담내역 입력해서 바로 상담내역 탭으로 넘어가서 확인하니 전화 응대 대응이 훨씬 편해졌다고 다른 팀에게도 칭찬을 해주었다.
만약 내가 안B를 신뢰하지 않았다면, 꿈꾸는 기획자(이전글 참조)가 해달라고 했다면 절대 안 해줬을 것 같다.
서로 간의 이해와 존중이 바탕으로 형성된 신뢰가 있었기에 말도 안 되는 요청도 해결할 수 있었던 것 같다.
