암호화폐 지갑 개발: 보관, 흐름, 보안을 올바른 순서로 구축하기

지갑 개발에 포함되는 것

빠른 테스트: 한 줄로 답하세요: 누가 키를 보관하나요? 답이 불분명하다면 설계할 준비가 되지 않은 것입니다.

암호화폐 지갑 개발은 사용자가 귀하의 서비스를 통해 디지털 자산을 사용할 수 있도록 하는 제품 결정과 소프트웨어를 포함합니다. 계획에는 지갑 인터페이스, 키 관리 방식, 거래 및 스왑 흐름, 체인 지원, 통합, 백엔드 서비스 및 모니터링이 포함될 수 있습니다. 우리는 첫 번째 릴리스에 어떤 요소가 포함되어야 하고 어떤 것이 나중에 기다려도 되는지 정의합니다.

지갑은 단순히 잔액을 표시하는 화면이 아닙니다. 사용자는 자신이 승인하는 내용, 작업 후 어떤 일이 발생하는지, 거래가 예상대로 작동하지 않을 때 어디서 도움을 받을 수 있는지 이해해야 합니다. 이러한 요구는 기능 목록만큼이나 흐름 설계를 결정합니다.

시작 시 다음을 매핑합니다:

• 지갑을 사용할 사람과 그들이 가장 먼저 해야 할 일.
• 제품이 수탁형인지 비수탁형인지.
• 제품에 적합한 납품 형식: 브라우저 확장 프로그램, 모바일 또는 Telegram Mini App.
• 계획에 포함된 체인, 거래 유형 및 스왑 흐름.
• 제품에 필요한 백엔드, 모니터링 및 운영 지원.

지갑이 더 넓은 제품의 일부인 경우, dApp 개발 또는 더 넓은 Web3 개발 계획과 조정할 수 있습니다. 결과물은 실용적인 기능 계획과 아키텍처 방향이며, 모든 가능한 통합이 첫 번째 릴리스에 포함되어야 한다는 약속이 아닙니다.

지갑 유형과 플랫폼은 어떻게 선택하나요?

제품이 감당할 준비가 된 책임에 따라 지갑 유형을 선택하세요. 수탁형 지갑은 서비스의 일부로 키 운영을 관리하는 반면, 비수탁형 지갑은 사용자가 자신의 키를 제어하도록 설계되었습니다. 이러한 차이는 사용자 경험, 기술 아키텍처 및 운영 모델에 영향을 미치므로 인터페이스 세부 사항이 확정되기 전에 결정해야 합니다.

수탁형 제품의 경우, 법률 자문을 조기에 대화에 참여시키세요. 규제 분류는 법적 문제이며, 제품 계획은 출시 전에 자문의 지침을 반영해야 합니다. 비수탁형 제품의 경우, 사용자가 지갑을 생성, 액세스 및 복구하는 방법을 명확히 하고 인터페이스가 이러한 작업을 쉬운 언어로 설명하는지 확인하세요.

납품 형식도 작업을 변경합니다:

지갑은 둘 이상의 체인을 지원할 수 있지만, 목록은 실제 제품 요구 사항을 따라야 합니다. 연결된 Telegram 제품의 경우, Telegram 봇 및 Mini App 개발과 지갑 요구 사항을 조정하고, 독립형 휴대폰 경험의 경우 모바일 앱 개발을 고려하세요.

계획해야 할 거래 흐름 및 통합

통합을 기술 목록이 아니라 사용자 작업 중심으로 계획하세요. 각 흐름에 대해 사용자가 보는 것, 확인하는 것, 지갑이 다음에 수행하는 작업, 제품이 이후에 표시하는 상태를 지정하세요. 이렇게 하면 구현 시작 전에 누락된 요구 사항을 식별하기가 더 쉽습니다.

정의해야 할 일반적인 영역은 다음과 같습니다:

• 선택한 제품 형식 내에서 지갑 연결 또는 열기.
• 관련 잔액 또는 자산 세부 정보 보기.
• 자산 보내기 및 받기, 확인 전에 사용자가 검토해야 하는 정보 포함.
• 자산 교환이 제품의 일부인 경우 스왑 흐름.
• 멀티체인 탐색 및 요청된 작업을 사용할 수 없을 때 명확한 피드백.
• 백엔드 책임, 모니터링 요구 사항 및 운영 지원.

통합은 제품의 보관 모델과 의도된 사용자 여정에 맞을 때만 유용합니다. 흐름 검토 중에 각 제안된 연결이 명확한 목적, 정의된 담당자 및 구현을 추정할 수 있는 충분한 제품 컨텍스트를 가지고 있는지 확인합니다. 또한 체인 우선 순위나 거래 동작과 같이 팀의 결정이 필요한 세부 사항을 식별합니다.

연결된 스마트 계약 기능의 경우, 지갑 계획을 스마트 계약 개발과 조정하세요. 공개 제품 설명과 지갑 내 지침을 일관되게 유지하세요. Web3 웹사이트 및 랜딩 페이지는 인터페이스를 어수선하게 만들지 않고 지갑 작동 방식을 설명하는 데 도움이 될 수 있습니다.

빌드 중 받게 되는 것

경험 법칙: 더 적은 체인, 더 적은 기능, 하나의 릴리스. 실제 사용자가 시도한 후에 나머지를 추가하세요.

합의된 제품 요구 사항에 연결된 지갑 구현 계획을 받게 되며, 그 다음 계획에 정의된 개발 작업 및 검토 활동이 이어집니다. 정확히 받게 되는 것은 선택한 형식, 보관 모델, 통합 및 릴리스 요구 사항에 따라 다릅니다. 구현 전에 합의되어 양 팀이 포함된 내용을 알 수 있습니다.

일반적인 계약은 다음을 포함합니다:

• 선택한 지갑 형식에 대한 요구 사항 및 사용자 흐름 매핑.
• 보관, 체인, 거래 및 스왑 요구 사항에 대한 아키텍처 결정.
• 합의된 기능에 대한 인터페이스 및 구현 작업.
• 제품에 필요한 통합 작업 및 백엔드 구성 요소.
• 보안 검토 및 필요한 경우 외부 감사 자료 준비.
• 납품된 계획 및 다음 제품 결정에 대한 인계 노트.

우리는 지갑 흐름 검토로 시작합니다: 의도된 사용자 작업을 살펴보고, 아키텍처를 변경할 수 있는 결정을 식별하고, 열린 질문을 명확한 계획으로 전환합니다. 그런 다음 빌드 순서를 합의하고, 구현을 진행하고, 계획에 대해 결과를 검토합니다. 제품 브리프, 의도된 사용자, 보관 선호도, 대상 형식, 체인 우선 순위 및 기존 기술 또는 규정 준수 지침을 공유하여 준비할 수 있습니다.

지갑이 더 큰 납품의 일부인 경우, 관련 Web3 개발 작업과 경계를 조정합니다. 이렇게 하면 종속성이 표시되고 팀이 지갑을 테스트하거나 릴리스하기 전에 무엇이 준비되어야 하는지 결정하는 데 도움이 됩니다.

지갑 보안 및 출시 위험 처리

지갑 보안은 아키텍처 선택, 신중한 흐름 설계 및 합의된 계획과 일치하는 검토 계획을 통해 처리됩니다. 우리는 민감한 작업과 키 관리 책임을 조기에 식별한 다음, 필요한 경우 납품 계획에 보안 검토 및 감사 준비를 포함합니다. 이렇게 하면 팀이 검토된 내용과 여전히 전문가의 주의가 필요한 부분을 이해하는 데 도움이 됩니다.

개발 전에 기존 기술 문서, 알려진 통합 요구 사항 및 수탁형 제품에 대한 자문의 지침을 준비하세요. 검토 중에 키 관리 방식, 거래 처리, 백엔드 책임 및 문제 모니터링 방법에 대한 명확한 설명을 요청하세요. 외부 감사의 경우, 누가 수행할지, 어떤 자료가 필요한지, 결과를 어떻게 처리할지 명확히 하세요. 감사 준비는 독립적인 감사와 동일하지 않습니다.

수탁형 분류는 출시 전에 자문과 확인해야 하며, 어떤 개발 팀도 외부 감사자의 결과, 타사 통합의 가용성 또는 플랫폼의 검토 결정을 통제할 수 없습니다. 우리는 합의된 구현 및 문서화된 작업에 전념할 수 있지만, 그러한 외부 결정은 빌드 팀의 통제 밖에 있습니다.

유용한 인계를 위해 팀이 합의된 지갑 계획, 완료된 검토 작업, 해결되지 않은 결정 및 운영 책임을 식별할 수 있는지 확인하세요. 이는 공개 릴리스 전에 해결해야 할 구체적인 항목이며, 암시적으로 남겨둘 세부 사항이 아닙니다.

지갑 계획을 위한 7가지 체크리스트

개발 시작 전에 다음 7가지 질문에 답하세요. 처음 두 가지에 답할 수 없다면, 빌드 전에 짧은 발견 단계로 시작하세요.

• 키를 누가 보관하는지 결정: 사용자 또는 서비스.
• 플랫폼 선택: 확장 프로그램, 모바일 또는 미니 앱.
• 출시 시 체인 및 토큰 목록 작성.
• 3가지 핵심 흐름 매핑: 받기, 보내기, 스왑.
• 복구 및 문제 발생 시 사용자에게 표시되는 내용 계획.
• 출시 전에 보안 검토 예약.
• 시장에 대한 법적 규칙 확인.

용어 한 줄 요약

수탁형 지갑은 서비스가 사용자를 위해 키를 보관하는 지갑을 의미합니다.

비수탁형 지갑: 사용자만 키를 보관하는 지갑입니다.

맞춤형 지갑이 적합한 경우

맞춤형 지갑은 표준 지갑 경험이 제품의 요구되는 보관 모델, 사용자 여정 또는 통합을 지원하지 않을 때 적합합니다. 또한 지갑 작업이 dApp, 모바일 제품 또는 Telegram 경험의 핵심이고 나중에 추가하는 것이 아니라 해당 제품의 일부로 설계되어야 할 때도 적합할 수 있습니다.

빌드를 의뢰하기 전에 다음 질문에 답하세요:

• 첫 번째 릴리스에서 사용자가 무엇을 할 수 있어야 합니까?
• 키 운영 및 사용자 지원은 누가 담당합니까?
• 출시 시 필수적인 체인 및 거래 유형은 무엇입니까?
• 제품에 브라우저 확장 프로그램, 모바일 앱, Telegram Mini App 또는 조합이 필요합니까?
• 이미 선택된 통합은 무엇이며, 아직 조사가 필요한 것은 무엇입니까?
• 출시 전에 어떤 보안 검토 및 법적 지침이 준비되어야 합니까?

보관 또는 첫 릴리스 질문에 아직 답할 수 없다면, 미완성 기능 목록을 사양으로 취급하지 말고 계획된 발견 대화로 시작하세요. 우리는 브리프를 결정으로 전환하고, 종속성을 식별하고, 합리적인 빌드 순서를 개요하는 데 도움을 줄 수 있습니다. MarketingExtra에 제품 설명, 선호 형식, 보관 가정 및 알려진 통합을 보내세요. 우리는 자료를 검토하고 지갑 계획 정의를 위한 다음 단계로 응답할 것입니다.

3가지를 보내세요: 보관 선택, 대상 플랫폼, 체인 목록.

이용 방법

1. 제품 브리프 공유지갑이 누구를 위한 것인지, 사용자가 무엇을 해야 하는지, 선호하는 납품 형식이 있는지 알려주세요. 기존 기술 또는 법적 지침이 있으면 포함하세요.
2. 보관 및 사용자 흐름 검토구현 계획을 권장하기 전에 주요 제품 결정, 거래 요구 사항 및 열린 질문을 매핑합니다.
3. 아키텍처 및 계획 합의개발 시작 전에 팀이 제안된 형식, 체인 요구 사항, 통합, 백엔드 요구 사항 및 보안 작업을 검토합니다.
4. 합의된 지갑 구축계획된 경험과 통합을 구현하고 진행 상황과 결정을 팀에 공개합니다.
5. 검토 및 인계 준비합의된 계획에 대해 납품된 작업을 확인하고, 미해결 항목을 문서화하고, 릴리스 또는 감사를 위한 다음 단계를 준비합니다.