[2026 SUMMER DEV] 동아리의 모든 서비스를 한 곳에서 보는 플랫폼 ‘ECO-KNOCK’, Keyring팀

프로젝트 소개

Keyring팀은 에코노베이션의 모든 서비스와 부서 지원, 동아리방 정보를 한번에 확인할 수 있는 플랫폼 “ECO_KNOCK”을 개발했습니다.

팀원 소개

Keyring팀은 FE/BE 선주님, PM 봄님, BE 수랑님, BE 준희님, AI 해서님으로 구성되어 있습니다.

인터뷰

Q. 프로젝트를 소개해주세요!

수랑 : ECO-KNOCK은 흩어져 있던 동아리 프로젝트나 자주 쓰는 링크를 한 곳에 모아, 신입도 쉽게 동아리 활동을 시작할 수 있도록 돕는 종합 플랫폼입니다. 프로젝트를 둘러보고, 동방의 공기질을 실시간으로 확인하며, 관심 있는 부서에 지원까지 할 수 있습니다.

Q. 프로젝트 하면서 어떤 문제를 겪었나요?

봄 : 처음에는 동방 문을 내부에서 열어주는 장치를 직접 설계하고 초인종 기능도 만들어 보자는 쪽으로 기획을 했었습니다. 하지만 현실적으로 보안 관련하여 한계를 느꼈고, 기획을 조금 변경하여 동아리 모든 링크를 모아주는 프로젝트로 변경했습니다. 결과적으로는 동아리의 모든 것을 한 눈에 확인 할 수 있게 되어 더 좋았던 것 같습니다.

Q. 프로젝트를 하기 전 후 달라진 점이 있다면?

준희 : 프로젝트 시작 전에는 블록체인의 기본 개념과 스마트 컨트랙트의 역할은 알고 있었지만, 이를 실제 서비스의 백엔드 및 사용자 계정과 연결해 본 경험은 없었습니다.

이번 프로젝트를 통해 스마트 컨트랙트 구현과 배포 뿐만 아니라 사용자별 지갑 생성, 온체인 잔액 조회, 사용자 데이터 암호화, 보상 정산 및 지급까지 하나의 흐름으로 연결하는 경험을 할 수 있었습니다. 특히, 블록체인 위에서 동작하는 컨트랙트만 잘 작성한다고 해서 전부가 아니라는 것을 체감하였습니다.

트랜잭션의 비동기성, 토큰 중복 지급 방지, 가스비를 지불하는 운영 지갑 관리 등 중앙 서버와 운영 환경에서 함께 고려해야 할 요소가 많았습니다. 이를 통해서 개별 기능의 구현보다 전체 데이터 흐름과 예외 상황을 먼저 생각하고 설계하는 습관을 가져야 된다는 생각을 하게 되었습니다.

또한, 이전에는 블록체인 서비스를 프로젝트에 도입할 경우, 사용자에게 별도의 지갑 생성과 등록 과정을 요구해야 하며, 이 과정은 서비스의 진입 장벽이 높이는 문제라고 생각했습니다.

이번 프로젝트에서는 중앙 서버가 사용자별 지갑을 자동으로 생성하고 관리하는 방식을 직접 설계하고 구현함으로써, 사용자가 블록체인이나 지갑에 대한 사전 지식이 없어도 온체인 서비스를 이용할 수 있도록 설계하였습니다. 이 경험을 통해 향후 다른 프로젝트에 블록체인을 도입할 때에도 지갑 사용으로 인해 발생하는 진입 장벽을 고려하여 사용자 편의성과 보안을 모두 충족하는 구조를 보다 수월하게 설계할 수 있게 되었습니다.

Q. 프로젝트를 시작하는 팀에게 전해줄 꿀팁을 말해주세요!

해서 : 프로젝트를 처음 시작할 때는 막막하기도 하고, ‘내가 할 수 있을까?’ 하는 불안이 생길 수도 있습니다.

하지만 처음부터 현실적인 제약이나 구현 가능성만 생각하기보다는, 우선 팀원들과 정말 해보고 싶은 주제가 무엇인지를 자유롭게 찾아보았으면 좋겠습니다. 하고 싶은 주제를 찾고난 뒤, 기획 단계에서 구현하고 싶은 기능들을 정리하고 우선순위를 정해 MVP부터 차근차근 만들어가는 방식으로 진행하면, 주어진 시간과 팀원 개개인의 역량에 맞춰 자연스럽게 프로젝트의 범위를 설정할 수 있는 것 같습니다.

구현 과정에서는 AI를 적극적으로 활용하는 것도 좋은 방법이라고 생각합니다. 다만 AI가 제시하는 답을 그대로 받아들이기보다는, ‘왜 이렇게 구현되는지’, ‘더 나은 방법은 없는지’를 스스로 계속 생각하고 고민해보는 과정도 함께 가져갔으면 좋겠습니다.

문제가 생겼을 때도 AI를 활용해 다양한 해결 방법을 찾아볼 수 있지만, AI와 함께 고민해도 해결되지 않는 부분은 혼자 붙잡고 있기보다 팀원들과 공유해보는 건 어떨까요? 저는 팀원들과 이야기를 나누는 과정에서 새로운 해결책을 찾는 경우가 많았습니다. 마지막으로, 데브까지 우리에게 주어진 시간은 약 4~5개월입니다. 처음부터 모든 것을 완벽하게 해내려고 하기보다는, 목표를 세우고 하나씩 꾸준히 만들어가다 보면 분명 좋은 결과물을 완성할 수 있을 것입니다. 팀원들과 함께 차근차근 프로젝트를 만들어가셨으면 좋겠습니다!

Q. 사용자 경험(UX) 및 사용자 인터페이스(UI) 디자인에 대한 고려 사항이 어떠했나요? 사용자들의 피드백을 어떻게 수용하였나요?

봄 : 우리가 만들고 있는 어플 버튼 하나하나의 쓰임을 생각해보면서, 시중에 나와있는 어플들 중 가장 비슷하다고 생각되는 어플 UX/UI를 참고하려고 노력했습니다. 예를 들면 부서 모집 페이지는 “열품타” 스터디그룹 가입 페이지를 참조했습니다. 최대한 깔끔하고 난잡해보이지 않으며 가독성(?)이 좋게 보이게끔, 많은 색을 사용하지 않고 글자 크기를 통일하는 등의 신경을 썼던 것 같습니다.

제가 디자인을 하면 팀원들이 디자인을 살펴주시면서 더 다양한 의견을 수용할 수 있었습니다. 그리고 사용자들의 피드백을 확인하기 위해 한 어플에서도 UX/UI가 업데이트 되어 어떻게 바뀌었는지 등을 찾아보려고 노력했습니다.

Q. 프로젝트의 기술적인 도전 과제나 혁신적인 부분은 무엇이었나요?

준희 : 가장 큰 기술적 도전은 블록체인에 익숙하지 않은 사용자도 별도의 노력 없이 온체인 토큰을 받을 수 있도록 만드는 것이었습니다. 일반적으로 블록체인 서비스를 이용하려면 사용자가 직접 지갑을 생성하고 서비스에 등록해야 하지만, 이러한 과정은 일반 사용자에게 높은 진입 장벽이 될 수 있다고 판단했습니다.

이를 해결하기 위해 회원이 처음 가입하면 중앙 서버가 사용자별 EVM 지갑을 자동으로 생성하고 각각의 회원 정보와 매핑하는 방식을 적용했습니다. 생성된 지갑의 개인키는 AES-256-GCM 방식으로 암호화하여 일반적인 데이터베이스에 저장함으로써 사용자 편의성과 보안을 함께 고려했습니다.

보상 지급 과정에서는 블록체인 트랜잭션의 비동기적인 특성과 중복 지급 가능성을 해결해야 했습니다. 서버가 트랜잭션을 전송하더라도 즉시 성공 여부를 알 수 없으며, 장애나 재시도로 같은 요청이 반복되면 보상이 중복으로 지급될 가능성이 존재했습니다. 이를 방지하기 위해, 날짜별 정산 요청마다 고유한 식별자인 batchId를 부여했습니다.

예를 들어, 2026년 1월 1일의 보상 요청에는 daily-reward:2026-01-01과 같은 문자열을 해싱한 값을 batchId로 사용합니다. 스마트 컨트랙트는 processedBatches라는 저장 공간에 각 batchId의 처리 여부를 true 또는 false로 기록합니다. 동일한 날짜의 지급 요청이 다시 전달되더라도 processedBatches[batchId]가 이미 true라면 해당 요청을 즉시 중단하게 됩니다.

반대로, 아직 처리되지 않은 요청이라면 보상을 지급하고 처리 상태를 true로 변경합니다. 또한, 지급 도중 오류가 발생한다면 트랜잭션 전체가 취소되어 처리 상태 변경과 토큰 전송이 모두 원상 복구됩니다. 이를 통해 서버에서 동일한 트랜잭션을 재시도하더라도 실제 보상은 단 한 번만 지급되도록 설계하였습니다. 보상 지급 과정에서는 블록체인 트랜잭션의 비동기적인 특성과 중복 지급 가능성을 해결해야 했습니다.

서버가 트랜잭션을 전송하더라도 즉시 성공 여부를 알 수 없으며, 장애나 재시도로 같은 요청이 반복되면 보상이 중복으로 지급될 가능성이 존재했습니다. 이를 방지하기 위해, 날짜별 정산 요청마다 고유한 식별자인 batchId를 부여했습니다. 예를 들어, 2026년 1월 1일의 보상 요청에는 daily-reward:2026-01-01과 같은 문자열을 해싱한 값을 batchId로 사용합니다. 스마트 컨트랙트는 processedBatches라는 저장 공간에 각 batchId의 처리 여부를 true 또는 false로 기록합니다.

동일한 날짜의 지급 요청이 다시 전달되더라도 processedBatches[batchId]가 이미 true라면 해당 요청을 즉시 중단하게 됩니다. 반대로, 아직 처리되지 않은 요청이라면 보상을 지급하고 처리 상태를 true로 변경합니다. 또한, 지급 도중 오류가 발생한다면 트랜잭션 전체가 취소되어 처리 상태 변경과 토큰 전송이 모두 원상 복구됩니다. 이를 통해 서버에서 동일한 트랜잭션을 재시도하더라도 실제 보상은 단 한 번만 지급되도록 설계하였습니다.

추가로, 중앙 서버에는 트랜잭션 해시와 처리 상태를 저장하여 지급 과정을 추적할 수 있도록 하였으며, 트랜잭션이 온체인에서 확정된 이후에만 사용자의 지급 이력을 생성하도록 설계하였습니다.

WhozIn에서 제공하는 재실 데이터를 실제 온체인 보상으로 연결하는 과정 역시도 주요 도전 과제였습니다.

WhozIn 측에서 제공하는 API를 통해 회원별 재실 시간을 가져오고, 이를 중앙 서버의 회원 및 지갑 정보와 연결한 뒤, 출석 보상과 시간별 보상으로 계산해야 했습니다. 이후, 계산 결과를 여러 사용자의 지갑 주소와 지급량으로 변환하여 RewardDistributor 스마트 컨트랙트에 일괄 전달하도록 구현하였습니다. 이를 통해, 재실 기록 조회부터 보상 계산, KRT 지급, 트랜잭션 확정 및 지급 이력 저장까지 하나의 흐름을 구축할 수 있었습니다.

이번 프로젝트를 통해 서버 관리형 지갑, 개인키 암호화, 중복 지급 방지 및 트랜잭션 상태 추적을 함께 구현하면서 블록체인 기능을 실제 서비스에서 운영하기 위해 필요한 요소들을 경험할 수 있었습니다.

Q. 개발자로서의 역량 향상을 위해 어떤 노력을 기울였으며, 이 프로젝트를 통해 어떤 기술적 성장을 이루었나요?

수랑 : 개발할 때는 기능을 구현하는 것에 그치지 않고, “이 방식이 데이터가 늘어난 뒤에도 괜찮을까?”를 한 번 더 확인하는 습관을 기르려고 노력했습니다.

이 프로젝트에서는 동방 공기질 데이터를 약 1초마다 수집합니다. 처음에는 데이터를 그대로 조회해도 문제가 없었지만, 시간이 쌓이면 하루나 한 달 단위의 기록을 확인할 때 데이터베이스에 부담이 될 수 있다고 생각했습니다. 그래서 원본 데이터는 저장하면서도, 조회할 때는 시간 단위로 미리 정리된 데이터를 활용하도록 구성했습니다.

또한 단순히 적용하는 데서 끝내지 않고, 원본 데이터를 직접 조회하는 방식과 비교해 보고, 실제로 데이터가 안정적으로 갱신되는지도 지속적으로 확인했습니다. 아래처럼 시간 단위별 데이터 갱신 시간을 모니터링하면서, 조회를 빠르게 만드는 방식이 운영 환경에 과도한 부담을 주지 않는지도 함께 살폈습니다.

이 경험을 통해 기능 구현 전부터 데이터 규모와 사용 상황을 함께 고려하는 관점을 배웠습니다. 앞으로도 “동작하는 기능”을 넘어, 오래 안정적으로 사용할 수 있는 기능을 만드는 개발자가 되고 싶습니다.

Q. 문제에 대한 개선 방향은 어떤 것이 있을까요?

해서 : 저는 팀 프로젝트에서 에코노베이션 동아리 챗봇을 개발하는 역할을 맡았습니다. 동아리 관련 문서를 수집해 RAG 구조를 구축하고 Gemini API에 연결하여, 사용자 질문이 들어오면 문서 검색이 필요한지를 판단한 뒤 필요한 경우 RAG를 통해, 그렇지 않은 경우 Gemini의 일반 답변으로 응답을 생성하도록 했습니다.

개발 과정에서 동아리원 설문 결과를 바탕으로 한 질문들과 기본적인 질문들로 테스트를 반복하며 예상치 못한 문제들을 발견했고, 이를 하나씩 해결해나갔습니다. 데이터 수집, 검색 품질, 프롬프트 등 여러 레이어에서 문제가 나타났는데, 그 중 프롬프트 설계 개선 과정을 공유해보겠습니다

초기에는 단순하게 설계한 단일 프롬프트를 사용했습니다. 팀원들의 피드백을 통해 이 방식이 일관된 답변을 보장하지 못한다는 문제를 인식했고, 프롬프트 고도화의 필요성을 깨달았습니다.

사용자 질문을 분석해보니 세 가지 경우로 나눌 수 있었습니다. 문서가 필요하고 관련 문서가 있는 경우, 문서가 필요하지만 관련 문서가 없는 경우, 문서가 필요하지 않은 일반 대화인 경우입니다. 각 경우에 맞는 프롬프트를 별도로 설계해 적용했습니다.

개선의 핵심 목표는 답변의 일관성 확보였습니다. 수정 사항을 적용할 때마다 정확도와 일관성을 함께 검증했고, 기준에 미치지 못하면 다시 수정하는 과정을 반복했습니다. 주요 적용 사항으로는 프롬프트를 세 가지로 분리, 벡터 유사도 점수(score)를 활용한 “모르는 것”의 기준 일관화, system_instruction으로 지시 강도 조절, 각 경우에 따른 temperature 차등 적용, 경계 케이스에 대한 예시(few-shot) 추가 등이 있습니다.

이 경험을 통해 문제를 발견했을 때, 세밀한 테스트로 원인을 특정하고, 해결 방법을 조사한 뒤, 하나씩 적용하며 검증해나가는 일련의 문제 해결 프로세스를 체득할 수 있었습니다.

지금까지 동아리 서비스를 한 눈에 볼 수 있는 통합 플랫폼 “ECO-KNOCK”을 제작한 Keyring팀이었습니다!