Hyperledger Fabric를 설치후 처음 실행해보며 느낀 점을 요약해보았습니다.

 

1. 블록체인은 수정/삭제가 안되는 조회/추가만 가능한 데이터베이스와 비슷한 느낌이다.

  • 이것은 블록체인의 핵심 특성인 불변성입니다. 데이터베이스와 비교하자면, 블록체인은 추가 전용 원장이라고 할 수 있습니다. 기존 데이터를 직접 수정하거나 삭제하는 대신, 변경된 내용을 새로운 트랜잭션으로 기록하여 원장에 추가합니다. 조회 시에는 가장 최신의 트랜잭션을 기반으로 현재 상태를 파악합니다. 이 불변성 덕분에 블록체인은 투명성, 신뢰성, 위변조 방지라는 강력한 장점을 가집니다.

2. 스마트 컨트랙트 기능은 마치 기존의 데이터베이스 프로그램에 존재하던 PL/SQL과 비슷한 느낌이다.

  • 스마트 컨트랙트(체인코드)는 블록체인 원장 위에서 실행되는 비즈니스 로직을 정의한 프로그램이라는 점에서 기존 데이터베이스의 저장 프로시저(Stored Procedure)나 PL/SQL과 유사한 역할을 합니다.
    • PL/SQL: 데이터베이스 내에서 데이터를 조작하고 비즈니스 규칙을 적용합니다.
    • 스마트 컨트랙트: 블록체인 원장(분산 원장) 위에서 트랜잭션을 처리하고 원장의 상태를 변경하며, 미리 정의된 규칙에 따라 자동으로 실행됩니다.

둘 다 특정 조건이 충족되면 미리 정의된 로직을 실행한다는 공통점이 있습니다.

3. 블록체인은 Docker의 실행이 필수적이다. (도커 인스턴스 하나가 네트워크의 하나의 참여자, 기여자를 의미하는것 같다.)

Hyperledger Fabric과 같은 많은 현대 블록체인 플랫폼은 컨테이너화된 아키텍처를 채택하고 있습니다.

  • 필수적인 이유: Fabric 네트워크를 구성하는 피어(Peer), 오더러(Orderer), 인증기관(CA), 상태 데이터베이스(CouchDB) 등 각 핵심 구성 요소는 독립적인 도커 컨테이너로 실행됩니다. 이는 환경 격리, 쉬운 배포, 일관성 유지, 그리고 효율적인 리소스 관리를 가능하게 합니다.
  • 참여자/기여자: 각 도커 컨테이너는 네트워크 내에서 특정 역할을 수행하는 논리적인 '노드' 또는 '참여자'의 인스턴스로 볼 수 있습니다. test-network에서 peer0.org1.example.com이나 orderer.example.com이 각각 별도의 도커 컨테이너로 실행되는 것이 그 예시입니다.

 

1. 인터넷 자산 보존의 필요성

우리는 디지털 시대에 무수히 많은 정보를 생산하고 소비하며 살아갑니다. 개인의 소중한 기록, 창작물, 그리고 인터넷을 통해 생성되는 다양한 형태의 디지털 흔적들은 단순한 데이터 이상의 가치를 지닙니다.

 

그러나 현재의 인터넷 환경은 이러한 자산들을 안전하게 보존하는 데 있어 한계를 가지고 있습니다.

기존의 중앙 집중형 웹 서비스는 다음과 같은 문제점을 내포합니다.

  • 데이터 유실 및 서비스 종속성: 특정 플랫폼이나 서비스가 중단되거나 정책을 변경하면, 그 안에 쌓아 올린 소중한 데이터와 콘텐츠가 예고 없이 사라지거나 접근 불가능해질 위험이 있습니다. 이는 개인이 자신의 디지털 자산에 대한 진정한 소유권을 주장하기 어렵게 만듭니다.
  • 불투명한 관리: 중앙 관리자에 의해 데이터가 임의로 변경되거나 검열될 가능성이 있으며, 이러한 과정을 사용자가 투명하게 감시하기 어렵습니다.

이러한 문제에 대한 대안으로 분산 원장 기술(Distributed Ledger Technology, DLT)은 데이터의 불변성, 탈중앙화된 신뢰, 그리고 투명성을 통해 디지털 자산 보존의 새로운 가능성을 제시합니다. DLT는 단일 실패 지점(Single Point of Failure)이 없어 데이터 유실 위험을 최소화하고, 모든 기록이 암호화되어 분산 저장되므로 조작이 거의 불가능합니다.

 

본 문서는 이러한 배경하에, 인터넷 자산의 로그 및 포인터 보존이라는 본 프로젝트의 목표를 달성하기 위한 최적의 DLT 솔루션으로 하이퍼레저 패브릭(Hyperledger Fabric)을 선택한 이유와 그 신뢰성에 대해 설명합니다.


2. 왜 하이퍼레저 패브릭인가?

본 프로젝트가 추구하는 "인터넷 자산의 생성 일시와 같은 로그 데이터와, 해당 자원의 원본 데이터가 존재하는 웹 서비스를 가리키는 포인터(주소)를 분산 원장에 기록하고, 이를 열람하기 좋은 형태로 웹 서비스를 제공하는 것"이라는 목표에 하이퍼레저 패브릭이 가장 적합한 이유는 다음과 같습니다.

2.1. 법적 및 규제적 안정성

  • 가스 토큰 부재 및 비증권성: 하이퍼레저 패브릭은 이더리움이나 폴리곤처럼 시장에서 거래되는 자체 가스 토큰을 기본적으로 가지고 있지 않습니다. 이는 본 프로젝트가 블록체인 상에 직접적인 금전적 가치를 가진 자산을 발행하거나 취급하지 않으므로, '가상자산 사업자 등록 의무'나 '증권성' 논란으로부터 자유로울 수 있다는 강력한 이점을 제공합니다. 개발 및 테스트 과정, 그리고 향후 서비스 운영 시 발생할 수 있는 잠재적인 법적, 재정적 위험을 최소화할 수 있습니다.
  • 허가형 네트워크 특성 및 규제 유연성: 하이퍼레저 패브릭은 '허가형(Permissioned)' 블록체인으로서, 네트워크 참여자를 명확하게 식별하고 통제할 수 있습니다. 이는 다음과 같은 장점을 제공합니다.
  • 데이터 프라이버시: 민감한 로그 정보나 특정 포인터가 모든 대중에게 공개되지 않도록 접근 권한을 세밀하게 설정할 수 있습니다.
  • '잊힐 권리' 대응: 원본 데이터는 오프체인에 존재하고 블록체인에는 포인터와 로그만 기록되므로, 사용자가 원본 콘텐츠를 삭제하고자 할 경우, 블록체인에 기록된 '존재 증명'은 유지하되 실제 콘텐츠는 삭제하여 '잊힐 권리'와 데이터 불변성 사이의 균형점을 찾을 수 있습니다. 이는 규제 당국의 요구사항에 유연하게 대응할 수 있는 기반이 됩니다.

2.2. 기술적 우수성 및 유연성

  • Node.js (JavaScript) 개발 지원: 하이퍼레저 패브릭은 스마트 컨트랙트(체인코드) 개발에 JavaScript(Node.js)를 공식적으로 지원합니다. 이는 JavaScript에 익숙한 개발자에게 매우 친숙하고 효율적인 개발 환경을 제공하여, 핵심 아이디어 구현에 집중할 수 있도록 돕습니다.
  • WSL 환경 구축 용이성: Windows 운영체제 사용 시, WSL(Windows Subsystem for Linux) 환경을 통해 리눅스 기반의 하이퍼레저 패브릭 네트워크를 손쉽게 구축하고 개발할 수 있습니다. 이는 개발 환경 설정의 장벽을 낮추고 효율적인 개발 워크플로우를 가능하게 합니다.
  • 고성능 및 확장성: 기업 환경을 위해 설계된 패브릭은 퍼블릭 블록체인 대비 훨씬 높은 트랜잭션 처리량(TPS)과 낮은 지연 시간을 제공합니다. 이는 대량의 인터넷 자산 로그를 효율적으로 기록하고 관리하는 데 유리합니다.

2.3. 개발 및 구현의 자유

  • 무료 개발 및 테스트: 가스비가 없다는 특성은 개발 및 테스트 과정에서 발생하는 비용 부담을 완전히 제거합니다. 이를 통해 개발자는 무한정 테스트 트랜잭션을 발생시키고, 다양한 개념을 자유롭게 실험하며 아이디어를 빠르게 프로토타입으로 만들고 개선할 수 있습니다.
  • 네트워크에 대한 완전한 통제권: 하이퍼레저 패브릭은 '설계도' 또는 '프레임워크'이므로, 개발자는 자신만의 프라이빗 네트워크를 구축하고 운영할 수 있습니다. 이는 네트워크의 합의 방식, 노드 구성, 데이터 정책 등 모든 측면을 완전히 제어할 수 있는 자유를 제공하며, 본 프로젝트의 독창적인 아이디어를 가장 순수하고 이상적인 형태로 구현할 수 있도록 지원합니다.

3. 하이퍼레저 패브릭 선택의 근거

본 프로젝트에서 하이퍼레저 패브릭을 선택하고 그 기반 위에서 개발하는 것이 신뢰할 만한 결정임을 뒷받침하는 공식적인 근거는 다음과 같습니다.

3.1. 리눅스 재단(The Linux Foundation) 산하 LF Decentralized Trust의 관리

  • 리눅스 재단의 공신력: 리눅스 재단은 리눅스 운영체제와 같은 세계적으로 중요한 오픈소스 프로젝트들을 성공적으로 관리해 온 오랜 역사와 공신력을 가진 기관입니다. 이들의 관리 아래 있다는 것만으로도 프로젝트의 중립성, 투명성, 그리고 안정적인 장기 운영에 대한 신뢰를 가질 수 있습니다.
  • LF Decentralized Trust로의 확장: 하이퍼레저 재단은 2024년 9월, 블록체인 및 분산 신원 기술 등 광범위한 탈중앙화된 신뢰 시스템의 발전을 위한 상위 조직인 LF Decentralized Trust 아래로 통합되었습니다. 이는 하이퍼레저 패브릭이 단순한 블록체인 프레임워크를 넘어, 미래 디지털 신뢰 인프라의 핵심 축으로서 더욱 중요하고 안정적인 위치를 확보했음을 의미합니다. 하이퍼레저 패브릭은 여전히 LF Decentralized Trust 산하의 핵심 프로젝트로 유지됩니다.

3.2. IBM의 초기 기여 및 지속적인 참여

  • 엔터프라이즈 솔루션 개발 경험: 하이퍼레저 패브릭은 IBM에서 초기 개발을 주도하고 리눅스 재단에 기부한 프로젝트입니다. IBM은 수십 년간 글로벌 대기업들을 위한 미션 크리티컬 시스템을 구축해 온 경험을 가지고 있으며, 이러한 경험이 패브릭의 아키텍처와 코드 품질에 깊이 반영되어 있습니다.
  • 코드 품질 및 보안 설계: IBM의 참여는 패브릭이 엔터프라이즈 수준의 요구사항(고성능, 보안, 확장성, 안정성)을 충족하도록 설계되고 구현되었음을 보증합니다. IBM은 현재도 패브릭 프로젝트의 주요 기여자이자 유지보수자로 활발하게 활동하고 있습니다.

3.3. 오픈소스 커뮤니티의 투명성과 활발한 개발

  • 코드 공개를 통한 투명한 검증: 하이퍼레저 패브릭의 모든 소스 코드는 대중에 완전히 공개되어 있습니다. 이는 누구나 코드를 검토하고 잠재적인 취약점을 발견할 수 있음을 의미하며, 특정 주체에 의해 코드가 조작될 위험이 없다는 강력한 투명성을 제공합니다.
  • 전 세계 개발자들의 기여: 하이퍼레저 패브릭은 특정 회사의 전유물이 아니라, 전 세계 수많은 개발자, 연구원, 그리고 다양한 기업들이 코드 개발, 버그 수정, 기능 제안 등에 활발하게 기여하는 커뮤니티 주도의 프로젝트입니다. 이러한 집단 지성은 코드의 품질과 안정성을 지속적으로 향상시키는 원동력입니다.
  • 정기적인 업데이트 및 장기 지원 (LTS): 하이퍼레저 패브릭은 약 4개월마다 새로운 기능과 개선 사항이 포함된 릴리즈를 발행하며, 특정 버전은 장기 지원(LTS) 버전으로 지정되어 안정적인 운영을 위한 지속적인 업데이트와 보안 패치를 제공합니다.

3.4. 실제 산업 적용 및 사용 사례

  • 하이퍼레저 패브릭은 전 세계 금융, 공급망, 의료, 정부 등 다양한 산업 분야의 유수 기업 및 기관에서 실제 비즈니스 문제 해결을 위해 성공적으로 도입되어 운영되고 있습니다.

4. 결론

본 문서는 인터넷 자산 보존이라는 아이디어를 구현하기 위한 분산 원장 기술로서 하이퍼레저 패브릭이 안전하고 유연한 선택지 중 하나임을 보여줍니다.

가스 토큰이 없어 비용 부담 없이 자유롭게 개발하고 테스트할 수 있으며, 리눅스 재단과 IBM이라는 배경을 바탕으로 높은 보안성과 꾸준한 업데이트를 기대할 수 있습니다. 또한, 이 프레임워크를 통해 프라이빗 네트워크를 구축하여 프로젝트의 여러 측면을 효과적으로 제어할 수 있습니다.

 

본 프로젝트는 하이퍼레저 패브릭이라는 견고한 기반 위에서 인터넷 자산 보존이라는 아이디어를 실현하고, 궁극적으로는 디지털 시대의 데이터 관리 방식에 긍정적으로 기여하는 것이 목표입니다. 제시된 자료들을 통해 본 기술 선택의 타당성을 직접 확인하고 구현할 예정입니다.

 

'Virtual-World Assets > 개요 & 목표' 카테고리의 다른 글

인터넷 자산에 대한 고민  (1) 2025.06.29
인터넷의 흔적들, 분산 원장에 기록될 미래의 자산

 

 

최근 블록체인 기술이 현실 세계의 자산(RWA)과 융합되고, 스테이블코인이 제도권으로 편입되는 흐름을 보면서, 저는 우리가 블록체인 네트워크와 현실 자산이 어우러지는 과도기적 시대를 살고 있다고 느낍니다. 이는 단순히 한쪽이 다른 쪽을 흡수하는 형태가 아니라, 서로의 단점을 보완하며 미래 금융 시스템의 핵심 요소로서 현대 자본의 약점을 보완하고 강화하는 방향으로 나아갈 것이라는 생각이 듭니다. 물론 이러한 예측이 현실이 될지, 아니면 아직 너무 이른 미래의 이야기일지는 아무도 알 수 없습니다.

 

하지만 개발자로서 이러한 변화의 흐름 속에서 한 가지 아이디어를 얻게 되었습니다. 그것은 바로 인터넷 세상에 존재하는 게시물, 창작물, 과거의 기록들, 그리고 흩어져 있는 인터넷 자산(저는 이들이 충분히 가치 있는 것이기에 '자산'이라고 부르고 싶습니다)을 분산 원장에 기록하고, 이를 열람하기 좋은 형태로 웹 서비스를 제공하는 것입니다.

 

 

왜 이러한 생각을 하게 되었을까요?

 

저는 어린 시절부터 인터넷을 접하며 살아온 세대입니다. 하지만 정보를 얻기 위해 검색을 하다 보면 생각보다 과거의 기록이나 데이터를 찾아보기 어려운 경우가 많습니다. 이는 아마도 검색 엔진이 최신 데이터를 기준으로 검색 결과를 보여주기 때문일 수도 있고, 과거의 웹 서비스나 사이트들이 문을 닫았거나 기술 발전으로 인해 레거시 시스템과 호환되지 않아 검색에서 제외되는 복합적인 문제 때문일 것입니다. 심지어 서비스 중단이나 호환성 부족으로 인한 데이터 유실도 빈번하게 발생하고 있습니다.

 

만약 특정 플랫폼이나 웹 서비스에 종속되지 않고, 제가 노력하여 만든 창작물이나 게시물들이 분산된 체인 위에 존재할 수 있다면 어떨까요? 그리고 그 체인 위의 데이터 호환성을 높여 기존 플랫폼이나 웹 서비스와 연동되는 동시에 데이터 유실을 막고 저만의 토큰화된 데이터로 남겨놓을 수 있다면, 이는 분명 의미 있는 일이 될 것입니다.

 

저는 제가 시간을 들여 기록하거나 만들어낸 자료들, 흔적들, 창작물들이 쉽게 흩어지지 않기를 바랍니다. 물론 지금도 쉽게 흩어지지는 않지만, 특정 플랫폼에 종속된 자료라면 언제든 예기치 못한 사고로 사라질 수 있습니다. 온프레미스 데이터센터의 사고, 재난, 또는 서비스를 운영하는 주체의 정책 변경이나 서비스 종료로 인해 데이터가 사라진다면 그때는 소유권을 주장하기도 어려울 것입니다.

 

그렇기에 개인이 소유했어야 할 이러한 데이터들을 보존하고 분산된 체인 위에 보존시키는 것이 현재 저의 꿈이라고 할 수 있습니다. 다만 이것이 꼭 블록체인이어야 하는지, 아니면 다른 형태여도 좋은지는 아직 확신할 수 없습니다.

 

 

'잊힐 권리'와 데이터 보존의 딜레마

 

'잊힐 권리'라는 개념도 존재합니다. 개인의 자료들을 불변성을 지닌 블록체인 위에 보존하게 되면 개인의 입장에서는 까다로운 문제가 발생할 수 있습니다. 그렇다면 무엇이 블록체인에 올라가야 할지, 미래에 어떤 결과를 불러올지, 누가 어떻게 기준을 정하고 블록체인에 기록해야 할지에 대한 깊은 고민이 필요합니다.

 

블록체인(꼭 블록체인이 아니더라도 불변성을 지닌 분산 네트워크)에 보존되어야 하는 것은 인터넷 자산의 생성 일시와 같은 로그 데이터와, 해당 자원의 원본 데이터가 존재하는 웹 서비스를 가리키는 포인터(주소)만 남겨두어야 할까요?

 

그렇다면 최종적으로 인터넷 자산의 로그를 보존하는 블록체인 네트워크와, 그 블록체인 네트워크에 기록된 각 인터넷 자산의 포인터가 향할 수 있는 웹 서비스가 존재하게 됩니다. 이것이 과연 어떤 의미를 가질까요?

 

 

코어 네트워크와 페깅 네트워크의 분리

 

블록체인 네트워크 중에는 안정성과 가치를 보존하고 조절하기 위해 코어 네트워크와 페깅 네트워크가 분리되어 쌍으로 존재하는 경우가 많습니다. 기술력이 뛰어나다면 단일 네트워크로 존재해도 상관없겠지만, 이는 일종의 안전장치이자 추후 확장을 위한 코어 네트워크와의 분리라고 생각합니다.

 

제 아이디어를 여기에 적용한다면, 코어 네트워크 자체에는 직접적인 데이터를 보존하지 않고 로그나 포인터 주소만 보존하는 방식을 생각해 볼 수 있습니다. 그리고 이와 연동되어 있는 쌍 네트워크는 코어 네트워크만큼의 극도의 보존성이나 견고함을 요구하지 않고, 옵티미스틱 접근법 같은 낙관적인 방법론을 통해 확장성을 높이는 방식으로 활용하는 것입니다.

 

코어 네트워크의 포인터 자체를 변경할 수는 없지만, 그 포인터가 향하는 인터넷 자산 자체는 소속된 웹 서비스에서 삭제할 수 있도록 합니다. 이렇게 되면 코어 네트워크의 포인터를 변경하지 않아도 되며, 포인터가 가리키는 인터넷 자산은 삭제하거나 수정하는 것이 허용됩니다. 대신, 그 위치와 관련된 로그를 충분히 남겨 데이터의 주권이나 존재 증명 시스템을 갖추는 것을 목표로 삼아야 할 것입니다.

 

결국 이러한 시스템이 현재의 인터넷과 크게 다르지 않다고 말할 수도 있을까요? 아니면 이 자체로도 어떠한 장점이나 현대 인터넷의 단점을 보완한다고 말할 수 있을까요? 만약 코어 네트워크에서 직접적인 데이터가 아닌, 시스템 자체적으로 데이터베이스처럼 기록할 수 있는 구체적인 시간대나 그 자료가 저장된 공간(시간-공간 데이터)을 기록하는 것이 맞다고 한다면, 이것이 가치를 지닐만한 네트워크로 확장될 수 있을까요?

 

레이어 2 네트워크나 서비스 구현에 대해서는 이후에 낙관적으로 구현해도 괜찮을 것입니다. 저는 우선 이러한 기반이 될 코어 네트워크의 구성과 목표, 그리고 방법론에 대해 좀 더 깊이 고민해봐야 할 것 같습니다.

 


 

첫걸음, 그리고 장기 목표

 

장기적으로 이러한 목표가 어떤 결과를 가져다줄지는, 그리고 시간이 지나 이 개념이 낡거나 약점이 많은 것으로 판명될지는 알 수 없습니다. 그러나 저는 이것이 충분히 가치 있는 일이라고 생각합니다.

 

물론 이 전체 시스템을 구현하려면 거대한 오픈소스 프로젝트의 지원이나 거대 기업의 참여가 없이는 현실적으로 자원이나 시간이 부족할 것입니다. 전체 구현이 100%라면, 저는 현재 0.001% 정도의 결과물을 만들어내는 것을 목표로 하고 있습니다. 하지만 이 작은 결과물이 확장되거나 계속 발전했을 때 100%까지 나아갈 수 있도록, 이러한 개념을 실현할 수 있는 가장 작은 구현체(MVP)를 빠른 시간 내에 구현하고 검증하고자 합니다.

 

이 아이디어에 대해 어떻게 생각하시나요? 여러분의 의견도 궁금합니다.

 

본 글은 EC2 Amazon Linux 2(AL2) 인스턴스 생성 및 연결된 이후의 백엔드 배포 과정입니다.

 

[EC2] Amazon Linux 2 인스턴스 생성하고 연결하기

AWS 아마존리눅스2 인스턴스 생성하고 브라우저로 접속 확인까지의 과정을 정리했습니다. 1. ec2 인스턴스 생성 2. 인스턴스 유형 선택 3. 네트워크 설정 선택 4. 스토리지 구성 선택 5. 연결하기 6. E

rexondex.tistory.com


 

1. 제가 배포할 express 서버는 5050포트를 사용하므로 5050 포트 Anywhere IPv4 인바운드 규칙 추가했습니다

5050포트를 Anywhere IPv4로 추가

 

 

2. 깃허브에 푸시돼있는 프로젝트를 내려받기 위해 Git을 사용할 것입니다. Git을 설치합니다.

sudo yum install git -y

 

 

3. 깃허브에 업로드돼있는 저장소를 git clone해서 AL2에 받아옵니다.

 

 

4. 처음에는 node와 npm이 안깔려있어서 설치합니다

# NVM 설치 (Node Version Manager)
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

# NVM 로드 (터미널 재시작하거나 아래 명령 실행)
source ~/.bashrc
# 또는
source ~/.profile

# 최신 LTS 버전 Node.js 설치
nvm install --lts
nvm use --lts

# Node.js 및 npm 설치 확인
node -v
npm -v

# 버전이 출력되면 설치완료

nvm 설치중...

 

 

5. 이제 npm install을 사용할 수 있습니다.

클론한 프로젝트 루트로 이동하고 npm install 합니다.

npm install

 

 

6. 프로젝트를 빌드합니다.

npm run build

 

 

7. npm start해서 실행되는지 확인합니다

제 경우 `Server listening on port 5050`이 출력되는 것을 확인했습니다.

Server listening on port 5050

 

 

8. 퍼블릭IP주소를 복사합니다.

퍼블릭 주소는 여기에 있습니다.

 

 

9. 주소창에 [퍼블릭IP주소]:[포트번호] 로 접근 가능합니다.

접속되는지 확인해봅니다.

에러났지만 접속은 확인됐습니다

 

 

10. 배포 성공입니다

에러가 있지만 AL2 서버에 접속은 성공 (환경변수 미설정으로 DB연결오류가 원인이었습니다)

 

'배포 & 운영 > AWS' 카테고리의 다른 글

[EC2] Amazon Linux 2 - 인스턴스 생성하고 연결하기  (0) 2025.06.23

Amazon Linux 2

AWS EC2 - AL2 인스턴스 생성하고 브라우저로 접속 확인까지의 과정을 정리했습니다.


 

1. ec2 인스턴스 생성

amazon linux를 선택하고 기본값 AMI(프리티어사용가능) 골랐습니다

 

 

2. 인스턴스 유형 선택

t2.micro(프리티어사용가능) 선택하고 키페어 생성했습니다 - 기본값 그대로 사용

 

 

3. 네트워크 설정 선택

보안그룹생성했습니다(기본값 그대로 했습니다)

 

 

4. 스토리지 구성 선택

기본값 그대로 스토리지 구성했습니다

 

 

5. 연결하기

인스턴스 체크하고 연결버튼 누릅니다

 

 

6. EC2 인스턴스 연결

[EC2 인스턴스 연결]로 브라우저환경에서 연결했습니다.

 

 

7. 백엔드 서버 구성하고 실행하기

EC2 콘솔에 express 서버를 설치하고 실행했을때의 화면입니다.

 

[EC2] Express서버를 AmazonLinux2에 첫 배포 완료한 과정

0. EC2 AmazonLinux2 인스턴스가 생성 및 연결된 이후의 과정입니다. 1. 저의 express 서버는 5050포트를 사용하므로 5050 포트를 Anywhere IPv4로 인바운드 규칙 추가했습니다 2. 백엔드 소스를 내려받기 위해

rexondex.tistory.com

(참고) Express 서버 AmazonLinux2에 클론하고 설치한 과정을 정리해두었습니다

 

 

8. `[퍼블릭IP주소]:[포트번호]` 로 접근 가능합니다.

연결 성공 but 환경변수 설정을 안해 DB연결 실패했습니다

 


 

AWS EC2 Amazon Linux 2 인스턴스 생성하고 웹서버를 올려 브라우저에서 접속 확인까지 마쳤습니다.

 

'배포 & 운영 > AWS' 카테고리의 다른 글

[EC2] Express.js 서버를 AL2에 첫 배포한 과정  (0) 2025.06.23

이 프로젝트(Aizen)를 시작하게 된 계기는 ...

 

# AI는 개발자의 의도를 가끔 잘 못알아듣는 것 같았습니다.

 

 

그래서 요구사항을 잘게 쪼개어 순서대로 입력시키면 코딩을 잘 할까 싶어

 

# 요구사항을 잘게 쪼갰습니다.

잘게 쪼갠 요구사항과 구체적인 프로젝트 문서화(API명세&스키마 포함)

 

 

프로젝트를 문서화하고 목표를 명확히 설정하여 구체적인 구현방법을 생각해보았습니다.

 

# 그리고 그것을 수행할 수 있는지 AI에게 물어봅니다.

 

 

 

Gemini AI는 그 문서화 한 대로 자신에게 단계별로 할일을 제시하면 가능하다고 했습니다. 그래서

# AI가 가능한 영역의 코딩이라는 확신이 들었습니다.

 

 

 

그리고 문서화 자료를 토대로 Gemini에게 프롬프트를 전달하며 코드를 출력하도록

# 진행했습니다.

 

 

 

처음엔 너무 밋밋한디자인이어서 강렬한 색(노랑,파랑,빨강,초록)을 섞은 블랙 테마를 요구했습니다. 곧

# 디자인까지 맡겼습니다.

 

그러나 제가 생각했던 것 보다는 훨씬 더

 

# 결과가 좋아 보였습니다.

기능도 또 디자인도요.

 

 

Gemini에게 프롬프트를 먹여주기 위해

# 요구사항을 잘개 쪼개어 프로젝트의 목적과 기능을 명확히 했습니다.

 

실수하면 귀찮을 것 같았습니다. 그래서 준비를 더 열심히 했습니다.

 

 

 

# 가장 먼저 설계한건 스키마와 API 명세였습니다.

스키마와 API명세가 구체적이면 실수를 해도 다시 복구할 확률이 높다고 판단했습니다.

 

 

몽고DB는 무모하다는 Gemini

 

# 스키마와 API 명세를 기반으로 프로젝트의 중심을 잡았습니다.

 

요구사항을 하나하나 입력해가며 잘게 쪼갠 기능들과 js파일들을 하나하나 완성해가며 이어붙였습니다.

 

 

 

이번 시도에 대해서는,

# 이제껏 AI와 수행했던 사이드 프로젝트 중 가장 결과물이 합리적이고 좋았다고 생각합니다.

 

그 이유는 프로젝트를 문서화 할 때,

프로젝트의 목표와 요구사항을 언제, 누가 봐도 알 수 있을 정도로 기록하고자 했으며

 

 

API와 스키마를 중심으로 프로젝트의 기반을 다진 덕에 오류가 나도 흐트러지지 않고 기능을 계속 구현해나갈 수 있었습니다.

 

 

Aizen 이라는 네이밍도, 콘셉트도 꽤 마음에 드는 사이드 프로젝트를 진행할 수 있어서 재밌었으며

Vercel, Next.js, Supabase를 사용하여 개발환경(로컬 dev)에서만 작동하는 어플리케이션이 아니라

 

 

Vercel

 

GitHub - Vercel - Supabase로 이어지는 흐름을 확립하여 1일차라는 짧은 시간에 배포(deploy)환경에서도 원활히 동작하는 어플리케이션을 빠르게 구현할 수 있었던 이유 중 하나라고 생각합니다.

 

 

GitHub Aizen 레포지토리 커밋 기록

 

 

이상입니다. 읽어주셔서 감사합니다.

 

🚨경고: 현재 테스트 중인 버전입니다. DB와 연동되어 있으니 실제 민감 정보를 절대 입력하지 마세요. 🚨

‼️주의: 본 플랫폼은 개발 단계에 있으며, 서비스 안정성 및 보안이 보장되지 않습니다.‼️

 

# 로그인 했을 시

로그인 시 헤더 메뉴가 변화

 

# 로그인 안 했을 시

이렇게 로그인,회원가입,카드 탐색만 가능합니다

 

 

# 로딩중일때 스피너 적용

[카드 탐색] 클릭 시 페이지 로드 스피너가 적용된 모습 (vercel 배포환경 테스트)

 

 

# URL 쿼리 파라미터 기반 페이지네이션 구현

쿼리 파라미터를 통해 페이지네이션을 구현

 

 

# 아트 카드 상세 정보

카드를 클릭하면 카드 고유 ID를 기준으로 상세 정보 확인 가능

 

!! 여기서 개선되어야 할 점 !!

상세 정보에서 이미지를 원본 크기로 볼수 있게 하거나 사이즈를 조절하여 최대한 원본에 가깝게 보이도록 화면에 보이는게 목표인데 현재 상세정보에서 이미지가 보이지 않는 오류가 있습니다.

 

디버깅 이후 상세화면에서도 이미지가 제대로 보이도록 개선 예정입니다.

 

# 회원가입 하기

회원가입 하기

 

# 로그인 하기

로그인 하기

 

DB는 Supabase의 PostgreSQL 사용했습니다.

Prisma 사용하여 DB 작업을 수행했습니다.

 

Supabase에 설계된 ERD 모습

 

# 새 카드 생성하기

카드 생성 화면(이미지 URL을 기준으로 허용된 도메인에 대해서만 사진 보여주기가 가능합니다 - 자체 이미지 서버를 사용해야 할지 고민이 들었습니다.)

 

# 내 정보 보기

헤더의 내정보에서 ID와 포인트 정보, 로그아웃 등 이용가능합니다

 

 

랜딩페이지 시연
랜딩페이지 스크린샷

 

🚨경고: 현재 테스트 중인 버전입니다. DB와 연동되어 있으니 실제 민감 정보를 절대 입력하지 마세요. 🚨

‼️주의: 본 플랫폼은 개발 단계에 있으며, 서비스 안정성 및 보안이 보장되지 않습니다.‼️

 

배포 주소: aizen-rouge.vercel.app

 

Create Next App

 

aizen-rouge.vercel.app

 

깃허브: https://github.com/rakaso598/aizen

 

GitHub - rakaso598/aizen

Contribute to rakaso598/aizen development by creating an account on GitHub.

github.com

 

+ Recent posts