한두푼에 연연할때가 아니져

이런회사는 이미지가 생명인데...

백만을 이틀만에요? ㅋㅋㅋ

@커피마신 상식적으로 입력한정보가 구라가 아닌지 계정정보확인 머지머니 잔액확인 후 엑셀기입 자동계산나온 환불금 환불 입력 이 과정을 거쳐야하는데 이틀만에 정말 가능하시다구요?

@Sukokoko 계좌에 돈만 있으면 입력폼 양식 지킨 것들 처리하는 건 순식간입니다.

@능글 입력폼에 금액 입력된거 없어서 금액 하나하나 다 찾아가며 입금 해야 하는데요?

@능글 그건아는데 제댓 보셨는지요 1차적으로 계정정보 db에서 확인해야합니다...머지잔액봐야죠 이 과정을 생각안하시네요 

@커피마신 이틀만에 ㅋㅋ

@Sukokoko 앞에 전제조건 달았잖아요 '유효성 체크'하고

@별을보자 데이터만 뽑으면 은행에서 엑셀양식으로 입금처리하는 기능 다 있습니다.

@유우우 핀테크 시대에 누가 일일히 그렇게 금액 찾아가면서 하나요.

지금 어차피 금액 사용도 못하는거 실시간 체크도 아니고, 미리 데이터 뽑아놓고 엑셀에만 넣으면 됩니다.

@Sukokoko DB 개념 아시니 더 쉽겠네요.

데이터 조건 걸어서 찾으면 금방 찾습니다.

@유우우 환불받는 사람이 백만인가요?

사용자가 백만으로 아는데 확신하세요?

@커피마신 
가능은 하죠 걍 막 보내면 누군들 못하나요....
대신 후폭풍은 본인이 보낸사람이 감당하는 거 맞죠?

@모르겟다아 결론은 머지가 할수있음에도 안하고 있다는겁니다..

수단은 다 있어요.

여기 위에분들 보면 진짜 그냥 모르시는 분들 같아서 하는말이에요.

@유우우 그걸 누가 계정마다 일일이 수작업하나요? 환불신청계정 사용중지한 다음 DB에서 액수 긁어오죠.

@커피마신 

제 말은 못한다는 소리에요

애초에 핀테크 스타트업이라 개발부서 인력도 많지 않을거고

새로 개발하는 서비스이고

실제로 고객에게 반영되는 서비스라 검증작업을 철저하게 해야합니다.

금액 규모가 같다는 가정하에 일반적으로

내부 거래보다 이번처럼 고객에게 직접 송금되는 금전성 거래는

검증절차가 엄청 까다로워집니다.

여기에 오프라인 환불로 인한 수기 작성건이 있다는 점과

계좌확인을 수기로 하고있다고 밝혔으니까 속도가 느려질 여지가 더있죠

그래도 이번에 한번 환불 절차 밟았으니까 자동화 할 수 있는 부분은 개발 끝났을거고

오류 있었는지 검증 한번 더하고 업무 최적화해서 개선하길 바래야죠

@커피마신 

저도 다량 데이터 취급해본 경험으로 말씀드리면,

1.기초 데이터야 있으니 2-3일 바짝 매달리면 사실 대부분의 환급자료는 맞출 거예요.

2,근데 제 생각과 맞겠지..심지어는 작년에 사용했던 쿼리니까 그대로 해도 맞겠지..하고 수만개의 데이터를 돌려보면 생각지도 못한 오류가 어딘가 나오고요.

구입시점마다 판매가격이 다른 상황에서 최대한 회사에 유리하게 쿼리를 짜야할 상황이라(증정포인트 등을 사용안한 걸로 처리 등) 실제 금액과 차이나는 부분, 손가락 하나까딱 잘못 놀려서 환급액 계산에 오류가 발생할지도 모를 부분..

숨어있는 연산오류 때문에 잘못 계산하고 송금하면 그거 어떻게 감당하실려고요?

10만명 인당 평균 천원만 차이나도 1억 물어주셔야해요.

착오송금기능 사용할 것도 아니고.

개인파산으로 갚으시게요?

커리어를 걸고 '금전책임이 오가는 데이터' 다뤄보신 적이나 있어요?

1원 손해에 눈뒤집어지는 악성거지 만나면 앞이 캄캄할껄요.

님보면 진짜 그냥 모르시는 분 같아서 하는말이에요.

@-익명을요구했습니다- 

지금도 현업에 있고, 더 그래서 머지의 행보가 이상하다는 겁니다.

강성고객이 많다는 뜻은 지연될수록 그만큼 민원도 거세진다는 것인데, 적어도 제가 다니던 기업들에서는 금전이 걸릴수록 인력 갈아넣어서 빠르고 정확하게 해결하려고 하지 저기 위에서 말한것처럼 일일히 대조하는 식으로 일처리 안한다는 얘기입니다.

숨어있는 연산 오류요?

그럼 평소에 유지보수나 운영 안한다는 의미로 받아들여도 되나요?

그리고 머지가 구매가로 환불해준다는 의미는 등록 데이터마다 고유값 부여해서 관리한다는 의미입니다.

 평소에도 환불해줄때 구매가의 90%로 어떻게 해주겠어요..

@-익명을요구했습니다- 

구매가가 아니라 고객마다 동일하게 머지잔액의 74.592% 환불 중인데요? 복잡한 부분이 전혀 없습니다. SQL 개발자 부족해도 엑셀은 다룰 거고요. 기초데이터를 엑셀로 작업해도 충분히 가능해요. 어려운 수식 안 나옵니다.

- 금전책임이 오가는 데이터 몇십만 줄 다룹니다.

@커피마신 

1.당연히 데이터는 있겠죠.

이벤트 머니, 구입한 머니, 구입을 했다면 구입한 머니에 대한 실제 입금액. 이건 없으면 말도 안되고, 평소 사용하고 수시로 검증도 할테니 틀릴 일도 없다고 봅니다.

2.문제는 애시당초 전산개발하시는 분들이

전체환불을 가정하고 전산을 짰을 가능성이 훨씬 적을 거란 겁니다. 머지가입할때 환불계좌를 사전에 받은 적 없잖아요?

3.설사 쿼리가 있다손 치더라도 수십만의 데이터가 100%맞는지는 금전이 오가는 시점에선 2-3번 체크해야하는거 맞고요. 그간 써먹을 일도 없었을텐데.

4.환불시점이랑 실제 포인트 차감시점이 시차가 있어서 포인트가 남아있다는 후기만 봐도 대규모의 환불을 가정한 전산개발은 없었거나, 개발 후 이 부분은 유지보수 거의 안했을 것 같습니다.

5.숨어있는 연산 오류요?

그럼 평소에 유지보수나 운영 안한다는 의미로 받아들여도 되나요?

 => 인력갈아서 움직이는 회사인데, 미개발 또는 평소 사용할 일 없는 부분까지 유지보수를 해야할 여유가? 미개발이면 더더욱.

6.평소에도 환불해줄때 구매가의 90%로 어떻게 해주겠어요.. 

 => 데이터 몇 개 올라오는건 검증금방하죠. 하루평균 1개도 안될텐데요.

@능글 

1.우선 단가별로 환불하지는 않내요. 이건 제가 잘못파악한듯.

2.무상제공된 포인트 선순위 제외할거고, 그 외 평소 자료관리를 어떻게 했느냐에 따라 숨은 버그도 얼마든지 있을 수 있고요. 대량환불에 대한 전산개발은 애시당초 염두에 두지도 않았을테니.

3.저같은 경우는 데이터 다루다보면 '여기서 왜 이런 오류가?','이런 쓸데없는 구문을 왜 심어놨을까?' 같은 생각지도 못한 오류가 나오더라고요.