기본 콘텐츠로 건너뛰기

핀다 앱 베타 버전 사용 후기

지난 달 핀다라는 서비스에서 안드로이드 앱의 베타 테스터를 모집하는 글을 보고 무슨 서비스인가 홈페이지에 들어가보니 카드나 P2P 투자, 대출 등을 추천해주는 서비스이더군요..

그렇잖아도.. 유리지갑인 팍팍한 직장인의 눈꼽만한 여유자금이라도 조금이라도 이자가 높은 곳에 투자하고 나에게 좀 더 좋은 혜택이 있는 카드를 추천 받을 수 있으면 좋을 것 같아 낼름 신청해봤습니다.

그리고 1월 30일 베타 테스트 앱의 출시와 함께 사용해 봤습니다.

우선은 전 성격이 모나서 좋은 점보다는 불편한 점이 더 먼저 눈에 띄더군요..

먼저 베타테스트 앱을 사용해보기 전에 홈페이지에 가입을 시도해 봤습니다.

그런데 기능으로는 분명 페이스북으로 가입과 로그인이 있는데.. 안되더군용.. 췟..

그래서 여러번 시도하다가 그냥 메일로 가입했습니다. 지금도 여전히 저에게는 페이스북으로 가입하거나 로그인 하는 기능은 안되네용.. 췟..

이때부터 이미 기분은 조금 상해 있었습니다.

앱을 다운로드 받으려고 하니 에러가 뜹니다.. 어떻게 어떻게 앱을 받았습니다. (얼마지나지 않아 다운로드 경로가 잘못되었다고 메일이 하나 더 날아오긴 하더군요.. 뭔지 모르게 잔망한 실수들이 많아지니 슬슬 기분이 달아오르지 않습니다. 뭔가 새로운걸 쓸때는 기뻐야 하는데 말이죠..)

앱을 실행하니.. 이미 홈페이지에 가입이 되어 있는데.. 또 가입하랍니다.. 아니 왜?

그런데 가입을 하고 나니 베타 테스트 하는 사람에게는 핀다 코인이라는걸 100코인 준다고 했던것 같은데.. 안주네용..

아마 홈페이지 가입한것때문에 안주나봅니다. 앱으로만 가입해야 주는거였나봅니다.

나이가 들어서 눈이 어두워진건지 머리가 나빠진건지 그냥 베타 테스트 하면 주는걸로 이해했는데 아닌가 봅니다.

앱은 베타테스트 기간이라서 그런지 기능이 많지 않습니다.

소비계획이라고 가계부의 예산 기능과 비스무리한 기능이 있는데.. 한땀 한땀 수작업 입력을 해야하고 이미 기존 사용하는 가계부도 있기 때문에 쓸거 같지는 않아서 한번 들여다보고 패스 했습니다.

금융정보 기능은 정식 출시 이후에 사용가능하다고 봉인되어 있더군요.

나름 핵심이라 생각되는 추천 기능은 카드 추천받기와 대출 추천받기가 구현되어 있습니다.

저는 P2P 투자 추천이 있었으면 했는데 없네용.. 킁..

대출은 관심이 없어서 카드 추천받기를 사용해봤는데.. 요즘 유행하는 봇이랑 대화하는 형태를 취하고 있습니다. 그런데, 처음 시작할 때 제가 입력한게 아니라 이미 입력된 대화가 제가 쓰는것처럼 출력되는데 웬지 기분이 나쁩니다. 그래도 나름 신선하고 재미는 있네요.

그런데 여러 선택 가능한 조건이 많지 않고(예를 들며, 특정 조건에 연회비가 면제되거나 이벤트로 연회비가 면제되는 경우도 있는데 그런건 안찾아주네요.), 결과 자체도 단순 나열식이라서 좀 아쉽네요.

추천된 카드를 서로 비교하거나 카드 내용을 한 화면에서 깔끔하게 보여주지는 못하네용.. 오히려 결정 장애가 옵니다. 그냥 느낌이 내가 추천해준거 닥치고 신청하라는 느낌입니다.

도와주는 느낌이 아니라 영업 사원이 강매하는 느낌이 듭니다.

이 카드가 어떻게 나에게 추천되었는지 좀 더 친절하게 설명해주거나 조금 귀찮더라도 사용자의 소비습관이나 성향등을 고려해서 추천해주는게 더 낫지 않나 싶습니다.

베타 서비스라 그런지 기능이 많지 않아 둘러볼만한게 많지 않네요. 그냥 안쓸것 같습니다. 뭐랄까.. 계륵같은 느낌입니다. 필요는 한데.. 끌리지 않는 느낌..

원래 베타 테스트 이벤트로 후기 적으면 일만코인 준다고 했는데.. 원래 그런건 좋은 이야기만 적어야 할것 같은데.. 뭐랄까.. 2% 부족한 느낌에 뭐랄까.. 딱히 추천하고 막 그러고 싶지는 않은 서비스라서.. 혹시 관심 있으시거나 필요하신 분은 핀다라는 서비스를 한번 둘러보시는 것도 좋을 것 같습니다.

앱이 아닌 웹에서는 둘러보면서 P2P투자 서비스 몇군데 더 가입해보기는 했습니다. 분산 투자는 중요하니까요..

카드나 대출이나 요즘은 정말 종류가 많은데.. 결정 장애로 힘드신 분들은 한번 둘러보심도 좋을 듯 합니다.

댓글

이 블로그의 인기 게시물

합성 사용자(Synthetic Users)의 5가지 유형과 AI 테스팅 현장에서의 활용법

AI와 생성형 모델 기술이 발전하면서, 사용자 경험(UX) 연구와 테스팅 현장에서 가상 퍼소나를 활용해 테스트 데이터를 수집하거나 사용성을 평가하려는 시도가 급격히 늘고 있습니다. 이를 흔히 '합성 사용자(Synthetic Users)'라고 부릅니다. 하지만 막연히 "AI에게 사용자 역할을 시켜 테스트를 돌린다"고 할 때, 그 가상 사용자가 어떤 방식과 데이터로 생성되었는지 명확히 구분하지 않으면 자칫 왜곡된 결과에 빠질 위험이 있습니다. UX 및 사용성 리서치 분야의 권위 있는 기관인 MeasuringU에서 이 합성 사용자의 개념을 명쾌하게 분류한 아티클을 공개했습니다. 바로 "What Are the Different Types of Synthetic Users?"라는 글입니다. (출처: MeasuringU - What Are the Different Types of Synthetic Users? / Jeff Sauro, PhD & Jim Lewis, PhD) https://measuringu.com/what-are-the-different-types-of-synthetic-users/ Jeff Sauro와 Jim Lewis 박사는 합성 사용자를 단순히 하나의 개념으로 뭉뚱그리지 않고, 생성 기술의 근거와 데이터 기반에 따라 크게 5가지 유형으로 깔끔하게 정리해 줍니다. 첫째는 규칙 기반(Rule-Based) 합성 사용자입니다. AI 모델이 아니라 사전 정의된 조건문, 정규식, 시나리오 스크립트에 따라 움직이는 전통적인 형태의 가상 사용자입니다. 예측 가능하고 정확하지만, 인간 사용자의 복잡한 정서나 미묘한 변수를 반영하진 못합니다. Selenium, Playwright, K6 같은 도구를 통해 지정된 경로대로 버튼을 누르고 데이터를 입력하는 방식을 들 수 있습니다. 둘째는 퍼소나 기반 LLM(Persona-Based LLM) 합성 사용자입니다. 생성형 AI에게 "너는 50대 비테크놀로지 사용...

QA 부서는 필요한 것인가?

많은 프로젝트 관리 방법론과 조직론에서 항상 얘기하는 것이 QA 부서를 독립적으로 두는것에 대해 강조하는 편이다. 테스트 역시 테스트 조직을 별도로 두는 것에 대해 강조하는 편이다. 이러한 QA 부서 또는 테스트만을 전담하는 조직이 꼭 별도로 존재해야 하는 것일까? 테스트의 경우에는 개발자와 다른 시각을 가진 사람들의 테스트의 필요성을 강조하기 위해서 테스트 조직을 별도로 두는 것을 강조하는 편이다. 만약 테스터가 개발이나 영업, 운영과 같은 조직의 하부 조직이 되다 보면 정치적인 독립성에 따라 자신만의 독립적인 시각이나 의견을 피력하기 힘든 점이 있기 때문이다. QA 부서는 어떨까? 여기서 먼저 생각해 볼 것이 있다. 그것은 QA 부서가 과연 무슨 일을 하는 부서인가? 하는 문제이다. 여러분의 회사에서 QA 부서는 과연 어떤 일을 하는가? 여러분은 QA 부서에 대해 얼마나 호감을 가지고 있는가? 펼쳐두기.. 회사마다 회사의 정책이나 전략에 따라 QA 부서의 역할은 매우 판이하다. 그리고 그 역할에 따라 회사 내에 QA 부서의 호감도도 매우 달라지는 편이다. 만약 여러분이 QA 부서에 대한 호감도가 낮다면 아래와 같은 문제가 있는 것은 아닌지 한번 고민해 보시고 댓글이나 트랙백등으로 의견을 주셨으면 하는 바람이다. 먼저 일반적으로 QA 부서가 하는 일은 제품의 품질을 측정하고 제품의 품질을 향상시킬 수 있는 모든 활동을 계획하고 제어하는 일을 한다. 그런데 문제는 소프트웨어의 품질이 문제가 된다. 먼저 공장과 같은 하드웨어를 제조하는 회사의 경우에는 품질 부서가 독립적으로 존재한다. 이 품질 부서에서 제품의 품질을 측정하고 제품의 품질을 개선하기 위해 집중하는 곳은 하드웨어 그 자체이다. 하드웨어는 각각의 부붐의 품질이 100인 제품이 모여서 하나의 제품을 구성하게 되었을 때 그 제품의 품질은 역시 100이다. 이것은 매우 명확한 사실이다. 소프트웨어를 만드는 회사의 조직과 관리 방법 역시 이러한 하드웨어를 만드는 회사의 조직과 관리 방법을 ...

AI 에이전트의 환각과 프롬프트 폭증을 막는 '컨텍스트 엔지니어링(Context Engineering)'과 아키텍처의 미래

AI 코딩 에이전트나 생성형 LLM을 소프트웨어 개발에 접목하는 시도가 늘어나면서, 엔지니어들이 마주하는 가장 큰 기술적 병목 중 하나는 바로 '컨텍스트(Context)'의 관리입니다. 저 역시 최근 AI와 바이브 코딩(Vibe Coding)을 활용해 여러 프로젝트를 진행하고 있는데, 하나의 대화창(세션)을 오래 켜둔 채 작업을 계속 이어가다 보면 AI가 초기 맥락을 잊어버리거나 이전에 지켜달라고 했던 제약조건을 놓치며 실수를 저지르는 경우를 자주 겪곤 합니다. 그래서 저는 목적별로 대화창을 명확하게 분리해서 작업하거나, 어느 정도 작업 단계가 진행되면 지금까지의 구현 내용과 의사결정을 요약 정리한 뒤 새 대화창에서 AI에게 이를 다시 학습시키는 방식으로 맥락을 관리하고 있습니다. 그렇다면 엔지니어링 아키텍처 차원에서는 이 문제를 어떻게 접근하고 있을까요? InfoQ의 발표 아티클 "Architecture / Context Engineering"에서는 바로 이 지점, 즉 단순한 프롬프트 엔지니어링을 넘어 시스템 아키텍처 수준에서 컨텍스트를 제어하는 '컨텍스트 엔지니어링(Context Engineering)'의 필요성과 구체적인 프레임워크를 다루고 있습니다. (출처: InfoQ - Architecture / Context Engineering) https://www.infoq.com/presentations/architecture-context-engineering/ 발표자들은 코딩 에이전트나 자율형 에이전트가 현장에서 실패하는 가장 큰 이유로 '비대해진 컨텍스트 윈도우(Bloated Context Windows)'와 무분별하게 채워진 프롬프트(Stuffed Prompts)를 꼽습니다. AI에게 너무 많은 정보를 한 번에 주면, 모델의 주의력(Attention)이 분산되거나 논리적 우선순위를 놓치는 현상이 발생합니다. 마치 인간 엔지니어에게 백과사전 수십 권을 던져주고 "이거 다 읽고 10초 ...