<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://blog.sciencebro.kr/feed.xml" rel="self" type="application/atom+xml" /><link href="https://blog.sciencebro.kr/" rel="alternate" type="text/html" /><updated>2026-06-21T19:57:13+09:00</updated><id>https://blog.sciencebro.kr/feed.xml</id><title type="html">Shaan Blog</title><subtitle>blog of software develop and business log  문제 해결을 위한 수단을 연구하며 기록합니다</subtitle><author><name>Shaan Lee</name></author><entry><title type="html">쿠버네티스 서비스의 외부 노출</title><link href="https://blog.sciencebro.kr/software/k8s-packet-jumping-with-iptables/" rel="alternate" type="text/html" title="쿠버네티스 서비스의 외부 노출" /><published>2026-06-21T12:00:00+09:00</published><updated>2026-06-21T12:00:00+09:00</updated><id>https://blog.sciencebro.kr/software/k8s-packet-jumping-with-iptables</id><content type="html" xml:base="https://blog.sciencebro.kr/software/k8s-packet-jumping-with-iptables/"><![CDATA[<h2 id="클러스터-구성">클러스터 구성</h2>

<p>클러스터는 쿠버네티스 환경을 구성하는 네트워크 중 가장 큰 단위를 말한다.</p>

<p>노드라고 부르는 개별 서버들의 합집합이 클러스터(K8s pool)이며, 쿠버네티스 안에서 실행되는 각 Pod의 자원 총량은 클러스터 자원을 넘을 수 없다.</p>

<p>클러스터는 여러 노드를 연결해 하나의 네트워크를 형성하며, 논리적으로 로컬 네트워크와 같이 각 Pod가 소통할 수 있도록 한다.</p>

<p>예) Service(서비스, svc)라는 개념으로 묶인 Pod 간에 통신할 때, 외부 네트워크라면 고유한 IP 또는 도메인을 이용해 호출해야 하는 과정을 K8s 네트워크 안의 고유한 Service 이름으로 호출할 수 있다.</p>

<h3 id="pod">Pod</h3>

<p>Pod는 K8s 안에서 사용하는 가상 환경 단위이다.</p>

<p>하나의 Pod 당 하나의 가상환경을 가지고, 이미지를 실행한다.</p>

<p>이미지는 docker에서도 사용하는데, 사전 구성된 실행 명령어와 실행 파일을 가진 채 배포할 수 있는 파일을 말한다.</p>

<p>개별 Pod는 고유한 ID를 가지고 클러스터 안에서 실행된다. <em>{svc name}-{Pod ID}</em></p>

<h3 id="svc">svc</h3>

<p>svc는 여러 개의 Pod를 하나의 단위로 묶어 사용할 수 있도록 하는 개념적 집합체다.</p>

<p>svc는 같은 목적으로 실행된 여러 Pod를 논리적으로 포함하며, svc 이름으로 수신된 요청을 하위 Pod들이 자원을 효율적으로 사용할 수 있도록 로드밸런싱 한다.</p>

<h2 id="노드-ip와-클러스터-ip">노드 IP와 클러스터 IP</h2>

<p>노드 IP는 각 하드웨어가 가지는 외부 IP를 말한다.</p>

<p>다만 K8s 안에서 각 하드웨어 서버를 <strong>노드</strong>라고 부르기 때문에 노드 IP라는 이름으로 표현한다.</p>

<p>Cluster IP는 K8s 네트워크 내의 svc가 가지는 고유한 가상 IP를 말한다.</p>

<p>이 IP는 노드 IP와는 다르고, 클러스터 내부 자원에 접속하기 위해서 사용한다.</p>

<p>노드 IP만으로는 별도의 포트포워딩 없이 클러스터 내부 자원에 접속할 수 없다.</p>

<h2 id="클러스터-내부로-요청-전달">클러스터 내부로 요청 전달</h2>

<p>클러스터 내부 자원인 svc 호출을 위해서는 클러스터 IP를 이용한 호출이 필요하다.</p>

<p>다만, 클러스터 IP는 외부 IP가 아니기 때문에 로컬 네트워크가 아닌 환경에서 호출할 때 제약이 생긴다.</p>

<p>이 문제를 해결하기 위해서 외부 IP를 가진 노드를 이용해 요청을 수신하고, 클러스터로 전달하는 과정이 필요하다.</p>

<p>아래 설명되는 iptables를 이용해 노드로 수신된 요청을 클러스터로 전달하게 되는데, PREROUTING 과정을 통해 요청의 목적지가 클러스터 내부 Pod IP로 변환된다.</p>

<p>PREROUTING 과정에서 요청의 목적지가 변환되면, iptables의 FORWARD 과정을 거쳐 Pod로 요청이 전달된다.</p>

<h3 id="iptables">iptables</h3>

<p>iptables는 커널 수준에서 사전 정의된 IP로 보내거나 받는 요청을 조율할 수 있다.</p>

<p>iptables는 규칙을 저장해 어떤 IP를 목적지로 하는 요청에 어떤 조율을 할지 정의하며, 실제 요청을 가공하는 작업은 netfilter가 수행한다.</p>

<p>iptables로 지정할 수 있는 규칙은 <strong>[ACCEPT, DROP, REJECT, LOG]</strong> 등이 있으며, 규칙을 적용하는 대상을 구분하는 종류는 <strong>[PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING]</strong>, 작업을 구분하는 종류는 <strong>[filter, nat, mangle, raw]</strong> 이 있다.</p>

<p>iptables 규칙과 별개로, INPUT 단계에서 호스트로 전달된 요청의 port를 호스트가 허용하지 않는 경우 요청은 거절된다.</p>

<div class="language-markdown highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ACCEPT : 패킷 통과 허용, 요청에 대한 응답 정상 반환
DROP : 패킷 폐기, 송신 클라이언트는 폐기 사실을 모른 채 응답을 대기하게 됨
REJECT : 패킷 거부, 송신 클라이언트는 거부 사실을 반환받음
LOG : 패킷 기록, 별도의 작업 없이 해당 패킷을 syslog에 기록함

PREROUTING : 네트워크 도착 즉시 실행됨, 목적지 주소를 바꾸는 용도로 사용
INPUT : 최종 목적지가 현재 서버인 경우 실행됨, 응답을 변환하거나 송신 클라이언트 필터 등에 사용
FORWARD : 목적지가 현재 서버가 아니며 다른 서버로 전달되는 경우 실행됨, 서버를 거치는 요청을 기록하는 용도에 사용
OUTPUT : 현재 서버에서 바깥 네트워크로 송신되는 요청에 실행됨, IP 블랙리스트 호출을 거절하거나 요청 전송 전 정보를 변환하는 용도에 사용
POSTROUTING : 네트워크 작업이 완료된 후 반환되는 시점에 실행됨, 응답 정보 변환하는 용도에 사용

filter : 패킷 허용, 거부, 폐기 등을 결정
nat : IP, 포트 주소 변환
mangle : 패킷 헤더의 정보 변환
raw : 별다른 작업이 없는 순수 요청
</code></pre></div></div>

<p>iptables로 처리되는 요청은 아래와 같은 순서를 거친다.</p>

<div class="language-markdown highlighter-rouge"><div class="highlight"><pre class="highlight"><code>외부 -&gt; 내부
<span class="p">-</span> raw(PREROUTING) -&gt; mangle(PREROUTING) -&gt; nat(PREROUTING)
  a. mangle(INPUT) -&gt; filter(INPUT) : 현재 서버가 목적지인 경우
  b. mangle(FORWARD) -&gt; filter(FORWARD) -&gt; mangle(POSTROUTING) -&gt; nat(POSTROUTING) : 서버를 거쳐 다른 목적지로 전송하는 경우

내부 -&gt; 외부
<span class="p">-</span> raw(OUTPUT) -&gt; mangle(OUTPUT) -&gt; nat(OUTPUT) -&gt; filter(OUTPUT) -&gt; mangle(POSTROUTING) -&gt; nat(POSTROUTING)
</code></pre></div></div>]]></content><author><name>Shaan Lee</name></author><category term="software" /><category term="kubernetes" /><category term="network" /><summary type="html"><![CDATA[노드 IP가 노출된 로컬 쿠버네티스 환경에서 어떻게 각 요청이 쿠버네티스 Cluster IP로 연결될까?]]></summary></entry><entry><title type="html">현대적인 업무 방식</title><link href="https://blog.sciencebro.kr/lifestyle/modern-office-type/" rel="alternate" type="text/html" title="현대적인 업무 방식" /><published>2026-05-26T12:00:00+09:00</published><updated>2026-05-26T12:00:00+09:00</updated><id>https://blog.sciencebro.kr/lifestyle/modern-office-type</id><content type="html" xml:base="https://blog.sciencebro.kr/lifestyle/modern-office-type/"><![CDATA[<h2 id="산업혁명-시대의-근로">산업혁명 시대의 근로</h2>

<p>산업혁명 시대에는 물품들이 공장에서 제조되기 시작하며 생산 속도와 생산량에 큰 변화가 나타났다.</p>

<p>공장에서 생산되는 물품들은 일정한 공장 가동 주기에 맞춰 작업자가 재료를 투입하거나 완성품을 출하하는 등 기계와 수많은 사람들의 유기적 협력이 필요했다.</p>

<p>이러한 협업 방식이 고정된 시간제 형태로 굳어지며 9시 출근, 6시 퇴근 방식인 <strong>‘9to6’</strong> 가 업무 방식으로 이어져 내려오고 있다.</p>

<h2 id="현대의-근로">현대의 근로</h2>

<p>현대에 들어서며, 공장에서의 직접적인 생산 근로는 기계의 빠른 발전으로 점차 줄어드는 동시에 기계를 관리하는 의사결정 및 업무 조율을 위한 사무 인력이 늘고 있다.</p>

<p>기계와 사람의 동시 협력이 줄어가는 지금, 왜 우리는 아직 이전의 업무 방식인 9to6를 유지하고 있는 걸까?</p>

<h3 id="관리-집단의-관성">관리 집단의 관성</h3>

<p>현대의 디지털 환경을 어릴 때부터 접하며 자라온 젊은 세대와 달리 공장 생산을 경험한 기성세대는 처음 접한 업무 방식이 9to6이며, 오랜 기간 이 방식에 익숙해져 왔다.</p>

<p>이전의 업무 방식에 익숙한 기성세대가 경력이 쌓여 현재 사무 관리직 또는 경영 책임자로서 이전 규칙을 선호하고 유지하려 한다.</p>

<p>이러한 현실적 제약 때문에 우리는 아직 9to6 방식을 주요한 업무 방식으로 이용한다.</p>

<h3 id="협업-구조의-제약">협업 구조의 제약</h3>

<p>9to6가 아닌 10to7, 8to5 등 시차 출근을 채택하는 업무 방식도 존재한다.</p>

<p>다만 이 경우에도 앞뒤 몇 시간을 변동적으로 이용할 뿐, 오후 1시부터 오후 10시까지 근무하는 등 업무 시간의 대폭 변경을 찾기 어렵다.</p>

<p>기존 근무 시간에서 크게 변화를 만들기 어려운 이유는 다른 집단의 근무 시간에 맞춰 소통해야 하기 때문이다.</p>

<p>본인이 오후 1시에 근무를 시작하더라도 거래처는 이미 오전부터 근무를 시작해 각종 안건에 대해 결정을 내리고, 오전 중 회신을 기대한다.</p>

<p>이미 거래처의 결정이 오전에 끝난 상황에서 오후에 출근한 본인은 의사결정 과정에 의견 반영을 기대하기 어렵고, 협업 속도가 느려져 생긴 손해를 감수하게 될 수도 있다.</p>

<p>업무 시간의 변동으로 감수해야 하는 불이익으로 인해 기업의 목적 달성이 늦어지거나 어려워지기 때문에 <strong>‘9to6’</strong> 는 강력한 표준 근로 환경으로 작동하고 있다.</p>

<hr />

<p>우리는 현대 사회의 유연한 소통 방식과 네트워크를 이용해 자율적인 업무 환경을 기대한다.</p>

<p>하지만 업무를 위해 소통하는 다른 집단과의 원활한 교류를 위해서 업무 환경 타협이 필요하다.</p>

<p>결국 9to6라는 구조는 산업혁명 시대에 고정되어 사회적 타협으로 작동하며 지금까지 이어지고 있다.</p>]]></content><author><name>Shaan Lee</name></author><category term="lifestyle" /><category term="service" /><summary type="html"><![CDATA[9 to 6는 왜 만들어졌고, 아직도 사용되는가?]]></summary></entry><entry><title type="html">직업의 변화, 정보 우위</title><link href="https://blog.sciencebro.kr/lifestyle/define-job-about-human/" rel="alternate" type="text/html" title="직업의 변화, 정보 우위" /><published>2026-05-07T12:00:00+09:00</published><updated>2026-05-07T12:00:00+09:00</updated><id>https://blog.sciencebro.kr/lifestyle/define-job-about-human</id><content type="html" xml:base="https://blog.sciencebro.kr/lifestyle/define-job-about-human/"><![CDATA[<h2 id="기술과-문화의-발전에-따라-직업도-변해왔다">기술과 문화의 발전에 따라 직업도 변해왔다</h2>

<p>과거에는 시간에 맞춰 첨탑의 종을 울려 마을 전체가 공통적인 생활을 할 수 있도록 돕는 직업이 존재했다.</p>

<p>이 직업은 기계의 발전과 동력 기관 비용이 저렴해짐에 따라 더 정확하고 편리한 기계식 알림 방식이 확산되며, 현재는 일부의 이벤트성 문화로 남아 종사하는 사람이 매우 적어졌다.</p>

<p>우리는 앞으로 발전하는 기술로 인해 어떤 변화를 맞이하게 될지 고민해 직업을 선택해야 한다.</p>

<h3 id="육체-노동과-지식-노동">육체 노동과 지식 노동</h3>

<p>직업은 특정 노동에 종사하는 사람들의 유형을 분류하여 “업”이라는 기준으로 표현한 방식을 말한다.</p>

<p>노동의 종류에는 <strong>육체 노동</strong>과 <strong>지식 노동</strong>이 존재한다.</p>

<ul>
  <li>육체 노동의 종류
    <ul>
      <li>물품의 전달, 분류</li>
      <li>원료를 가공하여 물품 생산</li>
    </ul>
  </li>
  <li>지식 노동의 종류
    <ul>
      <li>정보를 가공하여 기록</li>
      <li>지식을 표현하여 확산</li>
      <li>지식을 이용한 대행</li>
    </ul>
  </li>
</ul>

<p>우리 사회는 과거 육체 노동이 주요한 문화에서, 정보통신의 발전으로 점차 지식 노동이 주요한 문화로 변화했다.</p>

<p>하지만 최근 인공지능의 발전으로 과거 지식 노동의 많은 부분이 사람에서 기계로 대체되고 있다.</p>

<p>이에 대해 매체에서는 육체 노동으로 직업을 전환하는 사례를 부각하고 있는데, 이는 지식 노동과 인공지능을 이해하지 못함으로 인해 생기는 일부 사례의 과대 해석이다.</p>

<h3 id="인공지능의-작업-방식">인공지능의 작업 방식</h3>

<p><strong>인공지능은 과거의 지식 노동 산물을 이용한 도구</strong>이다.</p>

<p>인공지능은 과거 기록을 분석해 통계적 패턴을 찾아 <strong>같은 유형의 작업</strong>을 효율화하고, 기록 간의 연관성을 표현한 정보를 이용해 새로운 정보가 연관된 기록을 <strong>확률적</strong>으로 찾아내는 작업을 수행한다.</p>

<p>위 내용에 대해 고민해보면, 새로운 유형의 작업과 이전 기록에서 연관성을 충분히 표현하지 못하는 정보에 대해서는 인공지능 작업이 불가하거나 확률이 낮다고 유추할 수 있다.</p>

<p>현재 기술적으로 많은 관심이 있는 <strong>생성형 인공지능</strong> 또한 위의 기준에서 벗어나지 않는다.</p>

<p>사전 모델 학습 과정에서 과거의 방대한 기록을 서로 연관지어 표현하고, 새로운 정보(질문)에 대해 확률적으로 연관성이 높은 기록을 반환하는 것이 주요 기능이기 때문이다.</p>

<p>이미지나 음성을 만드는 작업 역시 과거의 기록을 연관지어 표현한 상태에서 각 단위(픽셀)을 확률적으로 연관성이 높은 기록으로 반환하여 조합하는 것이다.</p>

<p>반면, 사람의 작업 방식은 인공지능과 다른 점이 존재한다.</p>

<p>사람의 학습 및 일상을 통해 다른 정보를 받아들여 주관적인 표현으로 재구성하는 과정이 유사하지만, 사람은 <strong>무모한 도전</strong>으로 보이는 새로운 시도로 자신의 주관적 가치로부터 <strong>고찰</strong>을 통해 새로운 기록을 만들 수 있다.</p>

<p>이전 기록으로부터 연관성이 없는 여러 정보를 조합해 통계적으로 무의미해 보이는 작업에 도전하여 새로운 기록을 만들어낼 수 있다는 점이 인공지능이 대체할 수 없는 사람의 지식 노동 영역이다.</p>

<h3 id="인공지능으로-대체되어-사람이-가지지-않게-될-직업">인공지능으로 대체되어 사람이 가지지 않게 될 직업</h3>

<p>인공지능이 사람보다 효율적인 직업으로 현대 사회에서 선호되는 <strong>기업 사무</strong> 직업이 있다.</p>

<p>기업 사무에서는 전형적인 <strong>Bottom-up</strong> 방식으로 정보를 조합하고, 정리하여 보고하는 방식이 작업량의 대부분을 차지한다.</p>

<p>이 작업은 주관적 판단보다는 사실의 전달으로 현상을 효율적으로 판단하는 것이 주요하기에 사람보다 많은 정보를 빠르게 조합하고 표현할 수 있는 인공지능이 효율적이다.</p>

<p>서로 다른 기업의 사무에 대해 조율이 필요한 경우에도, 합리적 결과 도출을 위한 정보 수집 과정은 인공지능이 효율적이다.</p>

<p>사람은 인공지능이 수집한 정보를 이용한 제안 작성, 결과에 대한 의사 집행을 수행하는 작업에 강점을 가진다.</p>

<p>이성적으로는 인공지능이 도출한 결과가 바로 집행되어야 효율적이지만, 기업 간 사무에 앞서 사람 간의 일에서는 <strong>관계</strong>가 존재하기에 관계의 성격에 따라 제안과 합의 과정이 달라지기 때문이다.</p>

<h3 id="사람에게-필요한-도구">사람에게 필요한 도구</h3>

<p>앞선 내용대로 사람이 새로운 기록을 만들어내는 영역에서 직업을 가지는 경우에는 새로운 기록을 효율적으로 표현하고, 기록을 보호하는 도구가 필요해진다.</p>

<p>인간의 영역에서 만들어낸 기록들을 저장하고, 외부와 구분된 영역에서 인공지능이 기록 간의 연관성을 표현하여 또 다른 새로운 기록을 만들기 위한 도구로 활용되는 방식이다.</p>

<p>앞으로의 직업에서는 <strong>사람의 고찰</strong> 결과를 어떻게 표현하고, 다른 기록과 연관지을 수 있는가에 대한 방법이 중요해진다.</p>

<p>공개된 정보의 열화 및 핵심 정보의 보안으로 인해 범용 인공지능의 한계가 명확해지고, 이후의 작업은 개인의 기록 내부에서 수행되는 인공지능을 활용하게 되는 경우가 내가 생각하는 미래의 모습이다.</p>

<p>가치가 낮은 범용 정보로부터 작은 영감을 얻고, 고찰을 통해 기록을 만들어낸 뒤 개인 기록 안에서의 연관성을 이용한 새로운 영감을 얻는 방식이다.</p>

<p>미래에는 정보 우위가 따라잡을 수 없는 효율성의 차이를 만들어내 사회적 지위, 부의 기준으로 표현될 것이다.</p>

<hr />

<p>나는 미래 직업에서 필수적인 도구이자 범용 정보의 질을 높이기 위한 플랫폼을 만들고 있다.</p>

<p><strong>STRIGIFIC</strong>, 개인이 창출한 기록 소유를 증명하는 동시에 외부와 격리된 환경에서 인공지능을 활용할 수 있도록 한다.</p>

<p>개인의 영감으로 고찰을 이어가 관철한 정보에 대해서는 플랫폼 내의 범용 기록으로 공개하여 내부의 지위를 확보하고, 기록 공유를 통한 새로운 영감의 촉매로 이용되도록 한다.</p>

<p>추후 아래 도메인을 통해 서비스를 제공할 예정이다.</p>

<p><a href="https://strigific.com">STRIGIFIC 정보 소유 플랫폼</a></p>]]></content><author><name>Shaan Lee</name></author><category term="lifestyle" /><category term="service" /><category term="ai" /><summary type="html"><![CDATA[미래에 사람의 직업은 어떻게 변하고, 어떤 강점이 관계의 우위를 만드는가]]></summary></entry><entry><title type="html">이더리움의 계정 추상화, 네이티브 계정 추상화</title><link href="https://blog.sciencebro.kr/software/ethereum-native-acount-abstract/" rel="alternate" type="text/html" title="이더리움의 계정 추상화, 네이티브 계정 추상화" /><published>2026-04-22T12:00:00+09:00</published><updated>2026-04-22T12:00:00+09:00</updated><id>https://blog.sciencebro.kr/software/ethereum-native-acount-abstract</id><content type="html" xml:base="https://blog.sciencebro.kr/software/ethereum-native-acount-abstract/"><![CDATA[<h2 id="계정-추상화">계정 추상화</h2>

<p>계정 추상화는 프로그래밍 함수를 포괄적으로 사용할 수 있도록 기능을 일반화할 때 사용하는 <strong>추상화</strong>와 같은 의미로 계정을 변환하는 방식을 말한다.</p>

<p>추상 계정은 특정 목적으로 사전 정의되어 있는 기능 외에 상황에 따라 요구하는 추가 기능을 사용할 수 있는 유연한 기능 범위를 가지게 되어 <strong>프로그래밍 가능한 계정</strong>으로 변화한다.</p>

<p>예를 들면, 자산의 보관 및 전송을 위한 개인 지갑 계정을 추상화하는 경우 기존에 염두에 두지 않은 NFT 발행 기능을 사용하기 위해 새로운 외부 함수를 호출하는 등의 변화가 가능해진다.</p>

<h3 id="모듈식-계정">모듈식 계정</h3>

<p>모듈식 계정은 위에서 설명한 새로운 기능 추가를 편리하게 수행할 수 있도록 기능 단위를 모듈화하여 배포한 외부 컨트랙트를 사용하는 방식을 말한다.</p>

<p>모듈식 계정에서 계정 본체는 최소한의 계정 기능만을 가진 OS를 배포하고, 그 외의 계정 기능은 모두 외부 컨트랙트에 배포 후 계정에서 호출 권한을 부여하는 트랜잭션에 서명하여 사용한다.</p>

<p>프로그래밍 시 npm, pip 과 같은 라이브러리 사용을 생각할 수 있다. 라이브러리 설치 도구에 명령어를 입력해 해당 라이브러리를 프로젝트에서 사용하도록 설정하고, 프로젝트에서 라이브러리 기능 사용을 위해 바로 호출할 수 있는 것처럼 모듈식 계정 역시 외부 기능 설치 후 호출 방식을 이용한다.</p>

<h3 id="양자-내성-암호-사용을-위한-계정-추상화">양자 내성 암호 사용을 위한 계정 추상화</h3>

<p>최근 양자컴퓨터의 상용화 가능성을 두고 많은 주제가 화두에 오르고 있다.</p>

<p>블록체인 서명 체계의 양자 공격 취약성을 경고하며 빠른 대처를 요구하는 의견도 매우 활발하게 논의되고 있는데, 현재 이더리움 네트워크 및 계정 추상화를 지원하는 네트워크는 상대적으로 양자 공격에 대한 대비가 많이 진행되었다고 볼 수 있다.</p>

<p>계정 추상화를 지원하지 않는 네트워크의 경우에는 서명 검증 기능에서 양자 내성 암호를 사용하기 위해 네트워크 전체를 변경하는 <strong>하드포크</strong>가 필수적이며, 그 과정에서 네트워크 내부 계정들은 새로운 기능 사용을 위해 주소가 다른 새로운 계정으로 자산을 이전하는 등의 방식이 필요하다.</p>

<p>하지만, 계정 추상화를 지원하는 경우에는 네트워크 수준에서 <strong>양자 내성 암호 검증 알고리즘 모듈</strong>을 추가하는 상대적으로 작은 업데이트와 각 계정의 자율적인 기능 수정으로 양자 내성을 갖출 수 있다는 점에서 양자공격이 일부 대비가 진행중이다.</p>

<p>계정 추상화는 이런 대규모 변화에 대해서도 유연하게 대처 가능한 선택지를 제공하며, 네트워크의 업데이트와 별개로 각 계정의 자율적인 모듈 사용으로 기능을 추가할 수 있다는 점이 특징이다.</p>

<h3 id="추상-레이어의-구분">추상 레이어의 구분</h3>

<p>계정 추상화 방식에 대해서 네트워크 내부의 추상화 지원, 외부 컨트랙트의 추상화 지원으로 구분할 수 있다.</p>

<h4 id="플러그인-추상화">플러그인 추상화</h4>

<p>EIP-4337을 이용한 UserOp, EntryPoint를 이용한 계정 추상화를 플러그인 추상화라고 표현한다.</p>

<p>EIP-4337은 계정 외부 컨트랙트가 계정을 관리할 수 있는 <strong>스마트 컨트랙트</strong> 기능을 추가하는 제안이다.</p>

<p>이 방식은 외부 컨트랙트가 제출된 UserOp를 EntryPoint라는 신뢰되는 컨트랙트에 전달하여 트랜잭션 실행을 의뢰하는 방식으로 작동한다.</p>

<p>블록체인 네트워크 내부에서는 데이터의 저장, 컨트랙트 간의 소통에 발생하는 비용을 <strong>가스비</strong>라고 지칭하는데 위의 EntryPoint와의 소통에서 가스비가 발생하여 추상 과정이 없는 단순 트랜잭션에 비해 비용이 높다.</p>

<h4 id="네이티브-추상화">네이티브 추상화</h4>

<p>EIP-8141의 프레임 트랜잭션을 이용한 네트워크 빌더 수준에서의 계정 추상화를 네이티브 추상화라고 표현한다.</p>

<p>EIP-8141은 네트워크 빌더 수준에서 <strong>Frame</strong> 단위 동작을 수행 기능을 추가하는 제안이다.</p>

<p>이 방식은 네트워크 내부 엔진에서 동작을 단위별로 구분하고, 실행하기 때문에 외부 컨트랙트와의 소통 없이 실행되어 트랜잭션 비용이 저렴하다.</p>

<p>Frame을 이용한 추상화로 UserOp로는 여러 개의 요청으로 분리되어야 하는 동작을 하나의 요청으로 수행할 수 있게 되었다.</p>

<p>UserOp는 내부에 동작을 위한 CallData가 하나 포함되어 전달되기에 하나의 UserOp 당 하나의 동작을 수행하여 복잡한 동작을 수행하기 위해서는 여러 개의 UserOp를 이용해야 하는 점에서 높은 비용을 요구한다.</p>

<p>Frame은 내부에 배열 형태로 여러 동작을 순차적으로 요청할 수 있어 순서 관계를 통한 복잡한 동작을 수행하기에 유리하다.</p>

<h2 id="eip-8141">EIP-8141</h2>

<p>EIP-8141 프레임 트랜잭션은 <strong>프레임 모드에 따른 권한 분리</strong>가 특징이다.</p>

<p>프레임 모드는 <strong>[VERIFY, DEFAULT, SENDER]</strong> 가 존재한다.</p>

<ul>
  <li>VERIFY : 트랜잭션의 서명 및 진위 여부를 검증하는 프레임 모드를 의미한다. 이 모드의 프레임이 실패하거나 반려되는 경우 트랜잭션 실행 권한이 없다는 의미가 되어 트랜잭션이 무효 처리된다. (블록이 생성되지 않고 노드에서 무효 처리)</li>
  <li>DEFAULT : 트랜잭션에서 수행하는 상태 변경 로직이나 외부 컨트랙트와의 소통 로직을 포함하는 프레임 모드를 의미한다. 이 프레임이 실패하거나 반려되는 경우 실행 단위의 실패를 의미하며 이후 프레임을 수행하지 않고, 트랜잭션이 실패가 된다. (블록이 생성되어 실패 이력 기록)</li>
  <li>SENDER : 트랜잭션을 수행하는 계정의 자산에 관여하는 프레임 모드를 의미한다. 이 모드의 프레임은 자산의 전송 관련 로직을 포함하며, VERIFY 모드에서 sender_approved 상태를 반환하는 경우에만 실행 가능하다.</li>
</ul>

<p>각 프레임은 트랜잭션 내부에 배열의 요소로 입력되고, 배열 순서에 따라 index 0 부터 순차적으로 실행된다.</p>

<hr />

<p>블록체인 생태계는 양자컴퓨터라는 새로운 기술에 대응하기 위해 사용자의 자율성을 확대하며, 자연스러운 데이터 이전이 가능한 <strong>계정 추상화</strong>를 진행하고 있다.</p>

<p>네트워크마다 채택하는 양자 내성 대응 방식이 다양하지만, 이미 네트워크 활성 유저가 많은 대규모 프로젝트에서는 계정 추상화를 이용한 검증 방식 변경이 우세하며 이외의 네트워크에서는 설계 단계부터 양자 내성을 염두에 둔 경우도 존재한다.</p>

<p>양자컴퓨터로 인해 블록체인이 무력화된다는 의견과는 달리 양자컴퓨터 개발 분야에서의 정보 공유를 통해 보안을 강화하는 방향으로 생태계가 발전하고 있으므로 고전적인 네트워크 시스템보다 안전하다.</p>]]></content><author><name>Shaan Lee</name></author><category term="software" /><category term="software" /><category term="blockchain" /><summary type="html"><![CDATA[양자 내성과 계정 추상화의 관계, 플러그인 추상화와 네이티브 추상화의 차이]]></summary></entry><entry><title type="html">기록의 중요성과 유의미한 기록</title><link href="https://blog.sciencebro.kr/lifestyle/importance-of-history/" rel="alternate" type="text/html" title="기록의 중요성과 유의미한 기록" /><published>2026-04-17T12:00:00+09:00</published><updated>2026-04-17T12:00:00+09:00</updated><id>https://blog.sciencebro.kr/lifestyle/importance-of-history</id><content type="html" xml:base="https://blog.sciencebro.kr/lifestyle/importance-of-history/"><![CDATA[<p>인간은 이전의 기록을 보고, 간접 경험을 통해 다음 세대가 발전하는 과정을 거쳐왔다.</p>

<p>기록은 현재의 가치를 정리해 미래로 전달하는 방법이다.</p>

<h2 id="기록의-중요성">기록의 중요성</h2>

<p>우리는 다른 사람에게 정보를 전달하기 위해 기록하는 경우가 많다.</p>

<p>{보고서, 제안서, 편지, 채팅, 논문, 블로그} 등의 형식을 띠는 기록이 다른 사람에게 정보를 전달하는 목적이다.</p>

<p>스스로 생각을 정리하거나 잊지 않기 위해 기록하는 경우도 있다.</p>

<p>{일기, 브레인스토밍, 필기} 등의 형식을 띠는 기록이 스스로를 위해 정보를 정리하는 목적이다.</p>

<p>최근에는 생성형 인공지능의 발달로 위의 두 기록 간 형식 구분이 크게 의미가 없어졌다.</p>

<p>스스로 정보를 정리한 필기를 인공지능을 이용해 보고서 형태로 재구성하는 일이 매우 쉬워졌고, 반대로 복잡한 전문용어를 이용한 논문을 내가 이해하기 쉽게 구어체로 재구성하는 일도 가능하다.</p>

<hr />

<h2 id="기록을-다루는-방식의-변화">기록을 다루는 방식의 변화</h2>

<p>이전 세대에서 역량이 뛰어난 사무 인력은 기록을 <strong>보기 편하게</strong> 작성하는 사람을 말했다.</p>

<p>퍼져있는 기록을 인용하여 하나의 매체로 정리하고, 기록을 직관적인 시각자료로 표현하는 일은 과거 사무 업무의 큰 부분을 차지했다.</p>

<p>현재는 사무 인력의 보고서 작성 능력이 이전에 비해 덜 중요해졌다.</p>

<p>같은 사람이 작성해도 때에 따라 달라지는 단어 선택과 문맥과 달리, 정규 양식을 사전 학습한 인공지능은 항상 일정한 수준의 결과물을 기대할 수 있기 때문이다.</p>

<p>이 시점에서 우리는 <strong>어떤 기록이 중요하며, 어떻게 기록해야 의미를 전달할 수 있는지</strong> 고민해야 한다.</p>

<p>인공지능은 과거의 기록을 학습해 얻어낸 <strong>기록의 산물</strong>이다.</p>

<p>과거의 기록을 찾아내는 능력에 대해서는 사람이 인공지능보다 비효율적이다.</p>

<p><strong>사람은 기록을 찾는 일이 아닌, 새로운 기록을 만들어내는 능력이 인공지능에 비해 효율적</strong>이다.</p>

<p>새로운 기록은 이전의 파편 정보를 하나로 엮어내는 일을 뜻하지 않는다.</p>

<p>새로운 기록은 개인이 보유한 고유의 발상을 이용해 기존 기록으로부터 파생한 것을 의미한다.</p>

<p>사람은 인공지능이나 다른 방법을 이용해 정리한 기록으로부터 <strong>새로운 사실을 밝혀내기 위해 고민하는 방식으로 기록을 다뤄야 한다.</strong></p>

<hr />

<h2 id="새로운-기록을-위한-기록-방법">새로운 기록을 위한 기록 방법</h2>

<p>기존 기록을 바탕으로 새로운 사실을 밝혀내는 활동을 위해서는 <strong>유의미한 기록</strong>들을 쉽게 모아보고, 골라내는 작업이 중요하다.</p>

<p>유의미한 기록은 아래 기준을 따른다.</p>

<ol>
  <li><strong>기록의 초점이 명확</strong></li>
  <li><strong>개인의 의견을 담은 것</strong></li>
</ol>

<p>기록의 초점이 명확하더라도 의견을 포함하지 않은 것은 유의미한 기록이라기보다는 <strong>사실</strong>이나 <strong>관찰 결과</strong>에 가깝다.</p>

<p>우리는 사실과 관찰을 바탕으로 새로운 가능성을 찾아 정리한 <strong>유의미한 기록</strong>을 해야 한다.</p>

<p>초점이 명확하고 의견을 포함한 기록을 다시 확인하기 위해서 <strong>분류</strong>를 해야 한다.</p>

<p>분류 방법은 아래 내용에 부합하는 태그를 이용하는 것을 추천한다.</p>

<ul>
  <li><strong>핵심 주제</strong> : 기록이 다루는 사실과 관찰 결과에 대한 정보</li>
  <li><strong>발상 방법</strong> : 정보를 어떻게 연결하고 해석하는지에 대한 정보</li>
</ul>

<p>예를 들면 핵심 주제가 “데이터베이스 설계” 라면 바탕이 되는 사실은 데이터베이스의 종류와 특징, 저장 가능한 형태 등일 것이다.</p>

<p>이에 대한 발상 방법은 “고차원 정보 저장을 위한 벡터 분리” 등이 될 수 있다.</p>

<ul>
  <li><strong>{데이터베이스 설계, 고차원 정보 저장을 위한 벡터 분리}</strong></li>
</ul>

<p>위의 두 정보를 조합해 내용을 유추하면, 고차원 벡터 정보를 저장하기 위한 데이터베이스 종류와 효율적인 용량 관리 및 조회를 위한 데이터 분리 방법이 있을 것이다.</p>

<p>우리는 이런 정보를 만들어 기록하고, 미래의 자신 또는 타인이 같은 주제에 대해 더 빠르게 사실을 습득하고 더 깊은 고민을 할 수 있도록 해야 한다.</p>]]></content><author><name>Shaan Lee</name></author><category term="lifestyle" /><category term="history" /><category term="logging" /><summary type="html"><![CDATA[왜 기록을 해야하고, 어떻게 기록해야 의미 있는가?]]></summary></entry><entry><title type="html">이더리움 L2 네트워크의 운영 안정성</title><link href="https://blog.sciencebro.kr/software/ethereum-subchain-stability/" rel="alternate" type="text/html" title="이더리움 L2 네트워크의 운영 안정성" /><published>2026-04-14T12:00:00+09:00</published><updated>2026-04-14T12:00:00+09:00</updated><id>https://blog.sciencebro.kr/software/ethereum-subchain-stability</id><content type="html" xml:base="https://blog.sciencebro.kr/software/ethereum-subchain-stability/"><![CDATA[<h2 id="이더리움-layer-2-블록-증명-방식">이더리움 Layer 2 블록 증명 방식</h2>
<p>이더리움 Layer 2 네트워크는 각 목적에 따라 Optimistic, Validity 등의 블록 검증 방식을 이용한다. <br />
이전에 소개한 zkSync Era는 Validity 검증 방식 중 boojum 이라는 증명 알고리즘을 이용하는 예시다. <br />
이 글에서는 Layer 2 네트워크의 블록 증명 방식에 따른 운영 안정성을 고려하기 위한 내용을 다룬다. <br /></p>

<h3 id="optimistic">Optimistic</h3>
<p>Optimistic 검증 방식은 <strong>낙관적 블록 생성</strong>방식이다. <br />
블록에 오류가 없을 것으로 추정하고, Layer 1으로 블록을 제출하여 약 7일간의 <strong>이의제기 기간</strong>을 대기한 후 블록을 확정하는 방식이다. <br />
이 방식은 별도의 블록 검증 없이 바로 Layer 1으로 제출하기에 네트워크 처리 연산량이 적다는 장점이 있지만, 블록 오류가 있는 경우 치명적인 네트워크 혼란이 생길 수 있다. <br />
블록 오류가 <strong>이의제기 기간</strong> 내에 발견되면 Optimistic 네트워크는 오류 블록의 등록을 취소하고, 해당 블록 기록자에 대한 페널티를 부여하는 방식으로 네트워크 신뢰를 확보한다. <br />
오류 블록이 취소됨으로 인해서 해당 블록이 포함하는 트랜잭션 작업이 무효가 되는 것은 아니다. <br />
초기 방식에서는 문제를 발견한 블록에 대해서 큰 비용이 필요하지만 신뢰도를 보장하는 Layer 1에서 다시 블록 내부 작업을 수행 후 정정된 블록을 기록하는 방식으로 오류를 해결했다. <br />
최근에는 문제 블록 내부에서 오류의 원인이 되는 트랜잭션을 찾은 뒤 최소 실행 단위만 Layer 1에서 다시 실행 후 블록을 정정하는 방식도 이용되고 있다. <br />
<br />
Optimistic의 <strong>이의제기 기간</strong> 방식으로 인해 DeFi 서비스 또는 실시간 확정이 필요한 서비스는 불편을 겪을 수 있다. <br />
DeFi 서비스의 경우는 자금 인출이 블록 확정까지 지연되는 점, 실시간 확정이 필요한 서비스는 트랜잭션 실행 결과에 대한 신뢰를 보장할 수 없는 점이다. <br /></p>

<h4 id="bold">BoLD</h4>
<p>악의적인 이의제기로 인해 블록 확정이 무한정 지연되는 문제를 해결하기 위해 검증자 중 올바른 검증을 제출하는 1건의 경우를 이용해서 다른 이의제기를 무효화하는 Optimistic 세부 알고리즘이다. <br /></p>

<h4 id="opfp">OPFP</h4>
<p>내부적인 이더리움 가상 머신(EVM)을 이용한 검증 방식이다. 오류 발생 시 Layer 1에서 실행한 EVM을 이용해 블록을 다시 연산하고, 정정한다. <br /></p>

<h4 id="op-kailua">OP Kailua</h4>
<p>블록의 오류 발생 시에만 영지식 증명(ZK)를 이용해 정정하는 방식이다. Optimistic의 빠른 Layer 1 제출의 강점을 이용하고, 블록 확정 지연시간을 줄이기 위해 ZK로 블록을 검증한다. <br /></p>

<hr />

<h3 id="validity">Validity</h3>
<p>Validity 방식은 각 블록에 대해 Layer 2에서 검증 후 Layer 1으로 제출하는 방식이다. <br />
Layer 2 네트워크 내부에서 블록 검증 연산이 실행되기 때문에 네트워크 부담 연산량이 늘어나고, 검증 연산 후 Layer 1으로 블록이 제출되기 때문에 블록의 미확정 시간이 검증 대기열 상태에 따라 변동되는 점이 특징이다. <br />
블록 검증을 위해 영지식 증명(ZK)를 이용해 각 작업 단위를 검증하는 것이 기본 방식이다. <br />
ZK는 연산 방식에 따라 SNARK, STARK로 구분된다. <br />
현재 이더리움 메인넷이 채택한 ZK 는 SNARK 방식이지만, 일부 Layer 2는 메인넷과 별개로 STARK를 채택하여 검증하는 경우도 있다.(대표적인 Layer 2 starknet) <br />
최근 구글의 양자컴퓨터 연구로 확산된 양자내성증명 방식은 STARK 방식이다. <br />
STARK 방식과 SNARK 방식은 기본 알고리즘의 채택이 완전히 달라 서로 다른 특성을 가진다. <br />
SNARK 방식은 각 데이터를 타원곡선 암호를 이용해 암호화하는 방식으로, 양자컴퓨터의 쇼어 알고리즘에 취약한 타원곡선 암호로 인해 양자 위협에 노출된다. <br />
STARK 방식은 각 데이터를 해시 변환을 이용해 암호화하는 방식으로, 양자컴퓨터의 쇼어 알고리즘이 역산하기에 어려운 방식을 이용하여 양자 내성을 가지지만 해시 데이터의 크기로 인해 증명 데이터 용량이 SNARK에 비해 매우 커서 네트워크 연산 부담이 크다. <br /></p>

<h4 id="stwo">Stwo</h4>
<p>STARK 방식의 증명을 경량화해 네트워크 부담을 낮추는 방식의 증명 방식이다. <br /></p>

<h4 id="linea">Linea</h4>
<p>격자기반 암호를 이용하는 증명 방식이다. <br /></p>

<h4 id="boojum">Boojum</h4>
<p>STARK 방식의 고성능 증명 방식이다. <br /></p>

<h4 id="openvm">OpenVM</h4>
<p>별도의 지정 증명 방식 없이 연산 도구만 제공하는 방식이다. <br />
채택 네트워크가 별도로 증명 알고리즘을 지정한다. <br /></p>

<hr />

<h2 id="전용-rpc-노드">전용 RPC 노드</h2>
<p>이더리움 Layer 2의 사용으로 블록 생성 부담이 줄어 네트워크 가용성이 확보되었지만, 사용자의 체감 가용성은 트랜잭션을 처리하는 RPC 노드의 최대 처리 속도 제한으로 개선이 필수적이다. <br />
높은 처리 속도와 낮은 지연 시간을 요구하는 경우, 트랜잭션 처리 중 노드 오류를 최소화하기 위해 <strong>전용 RPC 노드</strong>를 사용한다. <br />
RPC 노드는 네트워크를 구성하는 각 노드를 의미하며, 사용자는 임의의 RPC 노드에 트랜잭션을 제출하며 RPC 노드가 로컬에서 트랜잭션 오류 확인 후 다른 노드와 공유하여 저장하는 방식으로 네트워크에 트랜잭션 결과가 저장된다. <br />
<strong>전용 RPC 노드</strong>는 특정 목적을 위해 RPC 노드를 인증된 사용자만 이용할 수 있도록 제공하는 방식이다. <br />
일반적인 RPC 노드는 다수의 사용자가 제출하는 트랜잭션 처리를 위해 최대 처리 속도가 낮게 설정되는 반면, 전용 RPC 노드는 인증된 소수의 사용자가 제출하는 트랜잭션만 처리하기에 높은 처리 속도를 가진다. <br />
또한, 전용 RPC 노드는 노드 오류로 인한 트랜잭션 지연을 보상하는 구조가 설계되어 있어 기업 서비스에서 트랜잭션 처리 신뢰도를 높이기 위한 수단으로 이용된다. <br /></p>

<hr />

<h2 id="web3-서비스를-위한-고려사항">Web3 서비스를 위한 고려사항</h2>
<p>Layer 2로의 네트워크 확장으로 다양한 RPC 노드가 필요해졌다. <br />
그 이유는 각 네트워크의 블록 생성 방식의 다름으로 네트워크 특화 노드가 필요하고, 블록 증명이 Layer 2 네트워크에서 수행되는 경우 노드의 연산 부하가 블록 생성 속도에 비례해 늘어나기 때문에 연산 능력의 향상이 요구되기 때문이다. <br />
따라서 <strong>안정적인 Web3 서비스 운영과 블록 신뢰도</strong>를 위해 Validity 방식의 블록 생성 네트워크를 채택하며, 양자내성 네트워크를 고려하는 경우를 고려하면 <strong>전용 RPC 노드를 적극 활용</strong>해야 한다. <br /></p>

<p>사용 목적에 따른 블록 생성 방식을 제안한다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: left">사용 목적</th>
      <th style="text-align: center">블록 생성 방식</th>
      <th style="text-align: left">특징</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: left"><strong>실시간 반응형</strong>(게임, 소셜 네트워크)</td>
      <td style="text-align: center">Optimistic</td>
      <td style="text-align: left">빠른 Layer 2 기록으로 데이터 송수신 속도 최적화</td>
    </tr>
    <tr>
      <td style="text-align: left"><strong>데이터 검증형</strong>(전자계약, 자산 송금)</td>
      <td style="text-align: center">Validity</td>
      <td style="text-align: left">Layer 2에서의 블록 검증을 통한 빠른 블록 확정, 서비스 신뢰를 ZK 증명 방식의 무결성으로 확장</td>
    </tr>
  </tbody>
</table>

<p>서비스에 사용할 네트워크 선정 시 참고할 수 있는 사이트를 아래에 기재한다. <br />
<a href="https://l2beat.com/scaling/summary">L2Beat</a> <br /></p>]]></content><author><name>Shaan Lee</name></author><category term="software" /><category term="software" /><category term="blockchain" /><summary type="html"><![CDATA[이더리움 시스템을 복제하여 운영하는 Layer 2 체인의 운영 안정성과 전용 RPC 노드의 필요성]]></summary></entry><entry><title type="html">이더리움 L2 네트워크와 ZKsync Era 소개</title><link href="https://blog.sciencebro.kr/software/introduce-ethereum-layer2-zksync-era/" rel="alternate" type="text/html" title="이더리움 L2 네트워크와 ZKsync Era 소개" /><published>2026-03-21T12:00:00+09:00</published><updated>2026-03-21T12:00:00+09:00</updated><id>https://blog.sciencebro.kr/software/introduce-ethereum-layer2-zksync-era</id><content type="html" xml:base="https://blog.sciencebro.kr/software/introduce-ethereum-layer2-zksync-era/"><![CDATA[<h2 id="ethereum">Ethereum</h2>
<p>이더리움은 이전 포스트의 내용처럼 <strong>지분 증명</strong> 방식을 이용한 블록체인 네트워크다. <br />
이더리움은 작업 증명 방식의 네트워크에 비교했을 때 빠른 블록 생성 속도를 강점으로 가지지만, 대용량 트래픽 환경에서는 한정적인 자원으로 인해 사용자 체감 속도가 원활하지 않을 수 있다. <br />
이더리움 네트워크 안에서 블록을 압축해 기록하는 방식으로 특정 계약의 블록 효율을 높이는 시도가 있지만, <br />
이 방식은 네트워크 자체의 속도 향상이 아닌 특정 스마트 컨트랙트 동작을 위한 사전 작업으로 <br />
오프체인에서 데이터를 압축하는 과정이 포함되기 때문에 기술적 숙련도를 요구되며, 압축 과정에서의 변조될 위험이 존재한다. <br /></p>

<h3 id="layer-2">Layer 2</h3>
<p>이더리움 네트워크에서 <strong>Layer</strong> 개념을 이용해 블록 생성 속도 향상, 비용 절감 및 특수 기능을 목적으로 하는 Layer 2 네트워크가 존재한다. <br />
Layer 2에 속하는 네트워크는 자체 네트워크(Layer 2)에서 블록을 생성한 뒤 여러 블록을 모아 이더리움 메인 네트워크(Layer 1)에 블록을 생성하는 방식을 이용한다. <br />
Layer 2 방식을 이용하면 메인 네트워크의 블록 생성 대기열과 별개로 블록을 생성하여 속도 향상을 누릴 수 있고, <br />
Layer 1 의 높은 네트워크 비용을 여러 트랜잭션이 나누어 부담하기에 비용 절감 효과를 누린다. <br />
데이터 무결성과 추적에 대해서는 Layer 2의 트랜잭션 추적과 Layer 1에 기록된 블록 정보를 이용할 수 있으므로 결과적인 보안성은 이더리움 메인 네트워크와 같다. <br /></p>

<h3 id="zksync-era">ZKsync Era</h3>
<p>이 포스트에서는 한국 기술 블로그에 잘 소개되지 않은 ZKsync Era 네트워크의 개념을 소개한다. <br />
ZKsync Era는 <strong>Zero-Knowledge proof, ZK(영지식 증명)을</strong> 이용하는 이더리움 Layer 2 네트워크다. <br />
영지식 증명은 해시값 비교와 다른 방식으로 데이터를 검증한다. <br />
해시값 비교는 검증자가 원본 데이터를 직접 해시로 변환 후 블록체인에 기록된 데이터 해시와 비교하는 방식을 이용해야 해당 데이터의 변조를 확인할 수 있다. <br />
데이터 검증 과정에서 검증자가 원본을 확인해 민감정보가 유출되거나, 검증자의 조작에 의한 데이터 변조 가능성 문제가 존재하여 영지식 증명 방식이 보안 측면에서 유리하다. <br />
<br /></p>

<ul>
  <li>영지식 증명은 하나의 키 쌍, 데이터 해시를 이용해서 데이터를 기록하고 검증한다. <br />
기록과 검증 과정에서 원본 데이터는 데이터 소유자 외에는 노출되지 않는 점이 보안 측면의 이점이다. <br />
    <ol>
      <li>키 쌍 중 <strong>검증 키</strong>와 <strong>데이터 고유값</strong>을 블록체인에 기록한다. <br /></li>
      <li>데이터 검증 시점에서 <strong>증명 키</strong>와 <strong>원본</strong>을 조합해 <strong>증명</strong>이라는 수학적 결과물을 생성한다. <br /></li>
      <li>블록체인에 기록된 <strong>검증 키</strong>를 이용해서 앞서 생성한 <strong>증명</strong>을 검증한다. <br /></li>
      <li><strong>검증 키</strong>의 검증 결과가 “참”이며 데이터 해시와 일치하는 경우 블록체인에 기록된 정보와 소유자의 제출 정보의 무결성을 확인할 수 있다. <br />
<br /></li>
    </ol>
  </li>
  <li>ZKsync Era의 특징은 영지식 증명 외에도 <strong>Abstract Account(AA)</strong> 개념이 네트워크의 기본 설정인 점이다. <br />
AA를 이용하면 트랜잭션 당사자와 수신자 외의 3자가 네트워크 비용을 대납하거나, 트랜잭션의 조건을 설정하는 등의 복잡한 계약 조건을 이용할 수 있다. <br />
이 특징을 이용하여 ZKsync Era 내부에서는 가스비 대납자(Paymaster)를 구현하기에 편리하며 WaaS의 프로세스 설계가 편리하다. <br />
WaaS의 대표 Paymaster를 사용자 지갑 AA가 사용하도록 설정하고, AA에는 특정 조건을 충족하는 데이터만 트랜잭션에 포함할 수 있는 로직을 이용하면 <br />
서비스의 프로세스에서 벗어나는 엣지 케이스를 줄이는 리스크 완화가 가능하다. <br /></li>
</ul>]]></content><author><name>Shaan Lee</name></author><category term="software" /><category term="software" /><category term="blockchain" /><summary type="html"><![CDATA[이더리움의 검증 능력을 차용하며 비용과 속도 측면의 사용성을 높이는 Layer 2 네트워크, 영지식 검증 방식을 이용해 데이터 검증 능력을 극대화하는 ZKsync Era]]></summary></entry><entry><title type="html">블록체인과 스마트 컨트랙트</title><link href="https://blog.sciencebro.kr/software/block-chain-and-smart-contract/" rel="alternate" type="text/html" title="블록체인과 스마트 컨트랙트" /><published>2026-03-09T12:00:00+09:00</published><updated>2026-03-09T12:00:00+09:00</updated><id>https://blog.sciencebro.kr/software/block-chain-and-smart-contract</id><content type="html" xml:base="https://blog.sciencebro.kr/software/block-chain-and-smart-contract/"><![CDATA[<h2 id="블록체인">블록체인</h2>

<p>블록체인은 각 데이터 간의 연결고리를 만들어 데이터의 외부 개입에 의한 위변조를 방지하는 기술이다. <br />
외부에서 임의로 기존 데이터 사이에 새로운 데이터를 삽입하거나 기존 데이터를 변조하면 블록체인 규칙에 의해 저장된 검증 데이터가 모두 바뀌기 때문에 검증 시점에서 위변조를 탐지할 수 있다. <br /></p>

<h3 id="작업증명">작업증명</h3>

<p>블록체인의 연결고리 방식 중 작업증명이 있다. <br />
작업증명 방식은 높은 부하를 가진 연산을 통해 작업의 위변조를 증명할 수 있는 노드를 선정하는 방식이다. <br />
위변조를 증명하기 위한 후보 노드들은 증명 대상 데이터를 모아서 해시 알고리즘을 연산한다. <br />
다만, 데이터를 단순히 해시로 변환하는게 아닌 일종의 검증 문자인 ‘nonce’를 추가해서 연산한다. <br />
nonce는 임의의 숫자이며 해시 알고리즘의 특성 상 데이터의 극히 일부가 변경되어도 해시 문자열 전체가 바뀌기 때문에 nonce의 규칙을 이용해서 검증하는게 아닌, 생성된 <strong>해시 문자열이 규칙에 부합하는 경우가 연산의 성공이며 증명 노드가 되는 방식</strong>이다. <br />
nonce를 계속 변경하며 규칙에 맞는 해시를 생성해야 하는 특성으로 인해 작업증명 방식은 증명 노드에 요구하는 연산량이 매우 높고, 변조를 위해서는 네트워크에 기여하는 모든 노드보다 높은 연산량을 가져야 하는 <strong>자본적 해자</strong>를 가진다. <br /></p>

<h3 id="지분증명">지분증명</h3>

<p>블록체인의 연결고리 방식 중 지분증명도 있다. <br />
지분증명 방식은 작업증명과 달리 연산을 통해 위변조 증명 노드를 선정하지 않는다. <br />
해당 네트워크에 자산을 예치하고, 네트워크에 대한 <strong>지분을 이용해 위변조 증명 노드를 선정</strong>한다. <br />
지분이 큰 노드가 증명 노드가 될 확률이 높고, 증명 노드는 해시 블록 생성 대가로 추가로 자산을 배분받아 자산이 점점 늘어난다. <br />
작업증명 방식과 달리 증명 연산의 부하가 작아 블록 생성에 필요한 시간이 적은 편이다. <br /></p>

<h2 id="스마트-컨트랙트">스마트 컨트랙트</h2>

<p>스마트 컨트랙트는 블록체인 안에서 실행되는 함수와 같다. <br />
특정 조건이 충족되면 사전 정의된 작업을 실행하는 방식으로, <strong>작업이 미리 정의된 상태로 블록체인에 저장되어 조건 변경이 불가능</strong>하다. <br />
사람 사이의 계약은 당사자 간의 의견 차이나 계약 위반을 대비해서 공증 과정이 필요하지만, 스마트 컨트랙트는 생성 시점에 조건을 설정하고 조건 충족 시 자동으로 작업이 실행되어 <strong>공증 없는 P2P 계약</strong>이 가능하다. <br />
스마트 컨트랙트의 투명성과 작업 실행을 이용하면 여러 기능을 구현할 수 있다. <br /></p>

<h3 id="가스비-대납">가스비 대납</h3>

<p>가스비 대납은 트랜잭션 생성 시 발생하는 <strong>네트워크 가스비를 트랜잭션 생성자 외의 제3자가 지불</strong>하는 방식을 말한다.<br />
이 방식은 특정 서비스 안에서 발생하는 트랜잭션 비용을 서비스가 대신 납부하기 위해 사용한다. <br />
사용자는 가스비를 직접 낼 필요가 없기 때문에 트랜잭션 생성에 대한 확인을 마치면 바로 전송하며, 해당 트랜잭션은 가스비 대납 스마트 컨트랙트에서 서비스 계정에 가스비를 청구한 뒤 네트워크에 기록한다. <br /></p>

<h3 id="자동-토큰-발행">자동 토큰 발행</h3>

<p>자동 토큰 발행 방식으로도 스마트 컨트랙트를 활용할 수 있다. <br />
기본적인 구조가 A 충족, B 실행 이므로 조건으로 자산 입금, <strong>실행으로 토큰 반환을 설정하면 내가 생성한 토큰을 다른 자산과 일정 비율로 자동 교환</strong>할 수 있다. <br />
이 방식은 거래소의 Convert 기능 등으로 이용할 수 있다. <br />
거래소는 예비로 보유중인 토큰을 사용자가 제출하는 토큰과 시장가 또는 자체적인 기준으로 교환하여 반환하는 스마트 컨트랙트를 이용하여 빠른 속도로 사용자가 요청한 토큰을 전달한다. <br />
사용자는 스마트 컨트랙트가 실행되어 조건 충족 시 자동으로 교환 대상 토큰이 반환될 것을 기대할 수 있기 때문에 거래소의 신뢰도 영향을 줄이며 거래할 수 있다. <br /></p>]]></content><author><name>Shaan Lee</name></author><category term="software" /><category term="software" /><category term="blockchain" /><summary type="html"><![CDATA[블록체인 안의 함수, 스마트 컨트랙트]]></summary></entry><entry><title type="html">양자내성암호와 보안</title><link href="https://blog.sciencebro.kr/software/quantum-computer-and-post-quantum-crypto/" rel="alternate" type="text/html" title="양자내성암호와 보안" /><published>2026-02-26T12:00:00+09:00</published><updated>2026-02-26T12:00:00+09:00</updated><id>https://blog.sciencebro.kr/software/quantum-computer-and-post-quantum-crypto</id><content type="html" xml:base="https://blog.sciencebro.kr/software/quantum-computer-and-post-quantum-crypto/"><![CDATA[<h2 id="양자컴퓨터의-개발과-보안의-두려움">양자컴퓨터의 개발과 보안의 두려움</h2>

<p>양자컴퓨터는 고전컴퓨터와 달리 <strong>양자의 중첩을 이용해 동시에 여러 경우를 계산</strong>할 수 있는 점이 특징이다.<br />
2개의 비트가 있다면 고전컴퓨터는 [00, 01, 10, 11] 4개의 경우 중 하나를 골라 계산하지만 양자컴퓨터는 4개의 경우를 중첩하여 계산 후 가장 확률이 높은 경우를 골라낸다.<br />
양자의 중첩을 이용해 각 경우를 확률로 존재하는 상태에서 가장 높은 확률을 가진 경우를 찾아내는 것이다.<br />
수조에 여러 개의 모래성을 쌓은 뒤 물을 채우면 가장 높은 성이 마지막까지 잠기지 않는 것과 같이 확률이 높은(높이가 높은) 경우를 남기고 나머지는 지우는(물속에 가라앉히는) 과정이다.<br />
<br /></p>

<h3 id="양자컴퓨터를-이용한-암호-풀이">양자컴퓨터를 이용한 암호 풀이</h3>

<p>양자컴퓨터를 이용하면 기존의 비대칭 암호를 풀이하는 시간이 매우 짧아지는 점이 양자내성암호를 개발해야하는 이유다.<br />
고전컴퓨터를 기준으로 고안된 비대칭 암호는, 공개키와 비밀키를 사용하여 공개키 정보로부터 비밀키를 알아내기 위해서 매우 오랜 시간이 필요한 함수를 사용한다.<br />
하지만 양자컴퓨터는 다양한 경우를 한 번에 계산하여 가장 확률이 높은 경우를 찾아내기 때문에, 비밀키를 알아내기 위해 필요한 연산 시간이 기하급수적으로 짧아진다.<br />
<br /></p>

<h3 id="양자컴퓨터로-풀기-어려운-암호">양자컴퓨터로 풀기 어려운 암호</h3>

<p>다양한 경우를 동시에 연산할 수 있는 양자컴퓨터의 특징에도 불구하고 모든 문제를 해결할 수 있지는 않다.<br />
현재 양자내성암호로 가장 활발히 개발중인 암호는 <strong>격자 기반 암호</strong>인데, 이 암호는 격자 데이터 안에 비밀 정보를 숨겨서 전달하는 방식이다.<br />
단순히 모래 속에 진주알을 숨기는 암호라면 양자컴퓨터가 쉽게 진주알(비밀 정보)의 특징을 찾아낼 수 있지만, 격자 기반 암호는 모래알에 쓰레기를 섞어 진주알을 찾기 어렵게 만든다.<br />
기술적으로는 격자를 비틀어서 격자의 규칙성을 어긋나게 만드는 것이다.<br />
격자를 비트는 노이즈로 인해 양자컴퓨터는 다양한 경우를 동시에 연산해도 월등히 높은 확률을 가지는 특정한 경우를 찾기 어려워진다.<br />
비밀 정보는 격자의 규칙에서 살짝 옮겨진 곳에 저장되는데, 원래 격자 규칙을 안다면 비밀 정보가 규칙과 다른 것을 알 수 있지만 격자가 비틀린 상황에서는 규칙을 유추하기 어렵고, 규칙을 찾더라도 비틀린 정보들로 인해 진짜 비밀 정보가 아닌 정보들도 규칙에 맞지 않아 보여 비밀 정보를 찾기 위해 수 많은 후보군을 다시 검토해야 한다.<br />
<br /></p>

<h2 id="양자내성암호의-사용-분야">양자내성암호의 사용 분야</h2>

<p>양자내성암호가 개발되어도, 모든 암호를 양자내성암호로 대체하지는 않는다.<br />
우리가 많이 사용하는 https를 예로 들면 가장 처음의 터널 생성 과정에서 클라이언트와 서버가 공유하는 대칭키 전달 과정에서 양자내성암호를 이용한 뒤, 이후의 통신에는 대칭키 암호를 이용한다.<br />
대칭키 전달에만 양자내성암호를 사용하는 이유는 비대칭 암호와 달리 대칭키 암호 방식은 양자컴퓨터가 유추하는데에 오랜 시간이 필요하기 때문이다.<br />
비대칭 암호는 공개키가 비밀키를 유추할 수 있는 힌트가 되지만, 대칭 암호는 아무런 힌트 없이 256개 이상의 문자열 조합을 맞춰야 한다.<br />
문자열 조합의 정답 여부는 실제 데이터를 복호화 시도해야 알 수 있기에 양자컴퓨터의 장점인 <strong>동시에 연산</strong>을 하지 못하고 한 번에 하나씩의 경우를 대입해야 한다.<br />
<br /></p>

<h3 id="데이터베이스에-양자내성암호-적용">데이터베이스에 양자내성암호 적용</h3>

<p>데이터베이스에 저장된 데이터 역시 양자컴퓨터를 이용한 공격에 대비해 보안을 강화해야 한다.<br />
데이터를 암호화하여 저장하고, 필요 시 복호화하여 사용하는 현재 방식과 크게 다르지 않은데, 복호화를 위한 키를 양자내성암호로 보호한다.<br />
같은 서버 안에서 복호화 키를 보관하면 서버 공격 시 데이터베이스와 함께 복호화 키도 탈취하여 데이터 보호에 실패할 수 있다.<br />
서버 공격에 대비하기 위해 복호화 키를 데이터베이스와 격리된 다른 서버에 보관하여 필요 시 데이터베이스 서버로 정보를 전달하도록 한다.<br />
양자내성암호는 복호화 키 전달 시 이용된다. 복호화 키가 통신 과정에서 유출되지 않도록 보호하여 서버 간 통신을 암호화한다.<br />
데이터베이스는 복호화 키를 저장하지 않고, 필요 시 서버에 요청 후 바로 삭제해 복호화 키를 보호한다.<br />
<br /></p>]]></content><author><name>Shaan Lee</name></author><category term="software" /><category term="software" /><category term="secure" /><summary type="html"><![CDATA[양자컴퓨터를 이용한 해킹 방어 암호, 하지만 모든 보안이 양자내성암호를 사용할 필요는 없다?]]></summary></entry><entry><title type="html">투자는 서비스 개발에 필요한가?</title><link href="https://blog.sciencebro.kr/business/is-investment-necessary-to-service/" rel="alternate" type="text/html" title="투자는 서비스 개발에 필요한가?" /><published>2026-02-09T12:00:00+09:00</published><updated>2026-02-09T12:00:00+09:00</updated><id>https://blog.sciencebro.kr/business/is-investment-necessary-to-service</id><content type="html" xml:base="https://blog.sciencebro.kr/business/is-investment-necessary-to-service/"><![CDATA[<h2 id="서비스-개발-단계에서-투자는-필수적인가">서비스 개발 단계에서 투자는 필수적인가?</h2>

<p>흔히들 스타트업은 투자를 이어가며 기업을 운영하는 방식이 필수적이라고 생각한다.
내 생각에는 ‘필수가 아니다’를 넘어 <strong>기피해야 한다</strong>는 입장이다.
이전에 투자 유치 플랫폼에 기재한 정보를 통해 한 투자자가 미팅을 요청했다.
인증된 플랫폼을 통한 접근이지만, 해당 투자자는 자신이 밝힌 소속 홈페이지에 정보가 없고 메일 주소 역시 소속과 관계 없었기에 투자자를 사칭한 사기를 의심했다.
이에 대한 내 대처는 해당 소속에 투자자 신분 확인을 요청하는 것이었다.
신분 확인을 위해 투자자에게도 통보 혹은 승인 차 연락이 갔는지, 온라인 미팅은 <em>투자자의 레퍼런스를 체크하는 건 무슨 경우인가요?</em> 라는 질문으로 시작된 불편한 시간이었다.
<br /></p>

<p>물론, 본인 동의 없는 레퍼런스 체크에는 불쾌할 수 있다.
하지만 이후의 태도까지 종합하면 이 투자자의 태도가 창업자에게 비협조적임을 알 수 있다.
<br /></p>

<p>주요 발언을 일부 인용한다.</p>
<ul>
  <li>투자를 받고 싶다면 이런 태도로는 힘들겁니다.</li>
  <li>본인 입맛에 맞는 투자자를 찾고 싶은거 같은데, 투자는 그렇지 않습니다.
<br /></li>
</ul>

<p>이전에도 투자의 필요성에 대해 회의적인 시선을 가지고 있었지만, 단 한 명의 투자자가 내 생각에 쐐기를 박았다.
나는 투자를 통해 우위를 점하려는 행위에 동조하지 않을 것이다.</p>

<h2 id="스타트업에-투자하는-이유">스타트업에 투자하는 이유</h2>

<p>스타트업에 투자하는 이유는 몇 가지가 있다.</p>
<ol>
  <li>미래 가치에 대한 지분 확보</li>
  <li>서비스 개발 기간 단축으로 확보한 기업 지분의 가치 제고</li>
</ol>

<p>위의 두 가지 이유를 보면, 투자자와 창업자 관계에서 투자자는 우위에 있지 않다.
오히려 투자를 받거나 거절할 수 있는 창업자가 우위에 있다고 보는 편이 상황에 맞다.</p>

<h2 id="투자자와-창업자의-관계-역전">투자자와 창업자의 관계 역전</h2>

<p>왜, 많은 투자자는 창업자보다 본인이 우위에 있다고 생각하고 심지어 자금의 운용자가 아닌 <strong>심사역</strong>까지도 이런 생각을 할까?
<br /></p>

<p>내가 생각하는 이유는 창업자가 투자를 유치하는 상황에 있다.
많은 창업자가 투자를 유치하기 위해 노력하는 시점이 재정적인 압박이 큰 상황이기 때문이다.
위 상황의 창업자는 기술이나 서비스를 개발하며 많은 자본을 사용하고, 매출 발생 없이 투자금을 소진한다.
이후 투자금이 소진되는 시기에 맞춰, 새로운 투자를 유치하지 못하면 회사를 이어갈 수 없는 상태가 되면 새로운 투자자를 만나 투자를 위해 주도적 위치를 상실한다.
<br /></p>

<p>과연 이런 행동이 <strong>스타트업</strong> 방식의 기업 운영이 맞을까?
적어도 내가 생각하기에는 위 방식은 <strong>파산 회피를 위한 뻥튀기</strong> 방식의 기업 운영이다.
<br /></p>

<p>기업을 운영하며 본인이 운영하는 기업이 투자가 필요한지 먼저 판단하고, 필수적인 투자 이후 다음 투자 없이 기업을 이어갈 계획을 세워야 진짜 <strong>스타트업</strong>을 운영할 수 있다.</p>]]></content><author><name>Shaan Lee</name></author><category term="business" /><category term="investment" /><category term="service" /><summary type="html"><![CDATA[서비스 개발 단계에서 투자는 필수적인가?]]></summary></entry></feed>