여러 사람이 일렬로 서 있을 때, 한 사람이 앞으로 한 발 나가면 다른 사람들보다 앞서게 됩니다.
그런데 가만히 있어도 나머지 사람들이 모두 뒤로 한 발씩 물러서면 결과는 같습니다.
그렇다면 나는 앞으로 나아가고, 나머지는 뒤로 물러선다면 어떨까요?
저는 장기적인 기술주 투자도 비슷하다고 생각합니다.
기술 발전으로 기업의 가치는 올라가고, 동시에 화폐의 구매력은 하락한다면 두 가지 효과가 겹치게 됩니다. 장기적으로는 그 차이가 복리적으로 벌어질 수도 있겠죠.
실제로 나스닥 상장 미국 기업들의 시가총액 합계는 2010년 약 3.9조 달러에서 2025년 약 37.5조 달러로, 15년 동안 약 9.7배 증가했습니다. 물론 신규 상장 등의 영향도 포함된 수치입니다.
sifma.org/wp-content/uploads…
하지만 중요한 것은 어떤 기술이고, 어떤 기업이냐는 겁니다.
그걸 판단할 자신이 없다면 그냥 나스닥100(QQQ)에 투자하는 것도 좋은 방법이라고 생각합니다.
최근 포트폴리오가 많이 하락해서 힘들어하는 분들이 많습니다.
하지만 자신이 선택한 기술과 기업에 대한 확신이 있고, 투자 근거도 여전히 유효하다면 그냥 기다려 보는 건 어떨까요?
반대로 확신이 없다면 QQQ에 투자해 놓고 기다리는 것도 방법입니다.
멘탈이 정말 강하고 레버리지 위험을 감당할 수 있다면 QLD나 TQQQ도 선택지가 될 수 있겠지만, 사실 그렇게 멘탈이 강하다면 지금 같은 하락장에 크게 흔들리지는 않았겠죠? ㅎㅎ
물론 레버리지는 단순히 멘탈만으로 버틸 수 있는 상품은 아닙니다.
결국 중요한 건 가장 많이 오를 종목을 찾는 것보다, 내가 확신을 가지고 오래 보유할 수 있는 투자를 하는 게 아닐까 싶습니다.
결국 투자는 멘탈과, 이를 제대로 파악하는 메타인지가 답인가요?
Quantum Security Deep Dive (1) — RSA, ECC, PQC, and AES: Digital Signatures, Key Establishment, Data Encryption, and Quantum Resistance
🇺🇸netcreat.substack.com/p/quan…
🇰🇷blog.naver.com/4-fire/224462…
Will quantum computers eventually break all encryption?
The answer is far more interesting than a simple yes or no.
RSA and ECC face a known threat from Shor’s algorithm.
But AES-256 is a completely different story.
And PQC is not a single magical encryption algorithm.
ML-KEM establishes shared secrets, while ML-DSA and SLH-DSA provide digital signatures.
Meanwhile, AES continues to protect the actual data.
Even quantum-resistant cryptography is not necessarily quantum-proof forever.
So which algorithms must be replaced, which can remain, and what happens if future mathematical breakthroughs change the rules?
In Part 1 of my Quantum Security Deep Dive, I break down the algorithms, their roles, their quantum vulnerabilities, and why crypto agility may be just as important as cryptographic strength itself.
Will Quantum Computers Break All Encryption? — A Beginner’s Guide
netcreat.substack.com/p/will…
There are three essential points.
Encrypt the data strongly.
Share and manage its secret keys securely.
Control access so that even when a system is compromised, the damage cannot spread.
$IONQ
Why did IonQ suddenly start talking about PQC?
🇺🇸netcreat.substack.com/p/why-…
🇰🇷 blog.naver.com/4-fire/224296…
What if IonQ’s real ambition isn’t to develop another encryption algorithm, but to control the security layer above it?
QKD, PQC, key management, Zero Trust, and trust orchestration may be pieces of a much bigger strategy.
I connected the dots in my latest deep dive.
Will Quantum Computers Break All Encryption? — A Beginner’s Guide
netcreat.substack.com/p/will…
There are three essential points.
Encrypt the data strongly.
Share and manage its secret keys securely.
Control access so that even when a system is compromised, the damage cannot spread.
$IONQ
Is QSPM's Real Competitive Advantage in Deployment Architecture Rather Than Detection Sensors?
Full report here.
🇺🇸netcreat.substack.com/p/is-q…
🇰🇷 blog.naver.com/4-fire/224461….
There’s a world of difference between having absolutely no blind spots and having even just a few.
PQC Detection: Could Existing Switches Be the Key?
Originally written and published in Korean on November 1, 2026.
Original Korean version: blog.naver.com/4-fire/224461…
✅ The Potential of Elisity
To prepare for the era of quantum computing, we must first find out which devices are using vulnerable cryptography. It is much like walking through an entire hospital to identify rooms still secured with old, outdated locks.
Surveying how cryptography is used and managing the order in which it should be replaced is the role of QSPM. However, discovering vulnerable cryptography and actually replacing it are two different tasks.
✅ 1. Why Does the Conventional Approach Leave Blind Spots?
A CCTV camera at the front entrance can show who enters or leaves, but it cannot see every hallway inside the building. Likewise, a network firewall can analyze only traffic that passes through the paths it monitors.
Zscaler primarily analyzes internet and SaaS traffic passing through its ZIA service, while Palo Alto analyzes traffic traversing its firewalls and other relevant products. Internal communications that never pass through those paths may go unseen.
Forescout uses SPAN or TAP to copy switch traffic for analysis by sensors. This can also provide visibility into internal networks, but expanding the number of monitoring points may increase sensor and analytics resource requirements as well as operational overhead. That is why monitoring only one point on the WAN is not enough.
✅ 2. Elisity’s Use of Existing Switches Could Offer a Solution
Elisity already uses an enterprise’s existing switches as policy enforcement points called VENs. The VE (Virtual Edge), which manages them, can run as an App Hosting container on certain Cisco Catalyst switches.
What if a lightweight PQC analysis program could be added to this setup? One could envision a process in which a switch mirrors traffic → an on-switch container examines TLS/SSH cryptographic methods → risk information is sent to IdentityGraph. It would be like setting up a small inspection room inside an existing building.
Where on-switch analysis is not possible, mirrored packets could be sent over ERSPAN to an analysis VM running on an existing server. Combining firewall logs, active scanning, and management APIs could also help fill some of the gaps that packet inspection alone cannot cover.
Of course, there is no evidence that Elisity currently offers this PQC analysis capability as a commercial product. Cisco’s IOx-based, switch-hosted sensors provide a useful real-world precedent, not proof that Elisity has completed such a product.
✅ 3. Why Would This Matter If It Were Actually Implemented?
Rather than installing new physical sensors throughout the network, this approach could reuse existing switches, containers, and VMs as much as possible, while examining a wider range of internal communications that existing security products may miss.
If Elisity’s IdentityGraph could associate discovered cryptographic risks with actual devices and, when necessary, use policy enforcement capabilities on existing switches, deployment and day-to-day management might also become simpler.
However, not every blind spot would disappear. Switch CPU, memory, and traffic-mirroring capacity; supported hardware models; communications contained entirely within VMs; and HSMs and other areas invisible to packet inspection would remain challenges to solve.
Ultimately, the real competitive advantage may depend less on simply having a “detection feature” and more on how much actual visibility and operational efficiency can be improved while minimizing additional hardware. We will examine the technical details and validation criteria in the next article.
📌 References
See Elisity’s Hardware Compatibility Matrix, the explanation of VE and VEN, and Cisco’s documentation related to switch-hosted sensors.
The integrated PQC detection architecture for Elisity discussed here is a hypothesis about technical feasibility.
netcreat.substack.com/p/elis…
PQC Detection: Could Existing Switches Be the Key?
Originally written and published in Korean on November 1, 2026.
Original Korean version: blog.naver.com/4-fire/224461…
✅ The Potential of Elisity
To prepare for the era of quantum computing, we must first find out which devices are using vulnerable cryptography. It is much like walking through an entire hospital to identify rooms still secured with old, outdated locks.
Surveying how cryptography is used and managing the order in which it should be replaced is the role of QSPM. However, discovering vulnerable cryptography and actually replacing it are two different tasks.
✅ 1. Why Does the Conventional Approach Leave Blind Spots?
A CCTV camera at the front entrance can show who enters or leaves, but it cannot see every hallway inside the building. Likewise, a network firewall can analyze only traffic that passes through the paths it monitors.
Zscaler primarily analyzes internet and SaaS traffic passing through its ZIA service, while Palo Alto analyzes traffic traversing its firewalls and other relevant products. Internal communications that never pass through those paths may go unseen.
Forescout uses SPAN or TAP to copy switch traffic for analysis by sensors. This can also provide visibility into internal networks, but expanding the number of monitoring points may increase sensor and analytics resource requirements as well as operational overhead. That is why monitoring only one point on the WAN is not enough.
✅ 2. Elisity’s Use of Existing Switches Could Offer a Solution
Elisity already uses an enterprise’s existing switches as policy enforcement points called VENs. The VE (Virtual Edge), which manages them, can run as an App Hosting container on certain Cisco Catalyst switches.
What if a lightweight PQC analysis program could be added to this setup? One could envision a process in which a switch mirrors traffic → an on-switch container examines TLS/SSH cryptographic methods → risk information is sent to IdentityGraph. It would be like setting up a small inspection room inside an existing building.
Where on-switch analysis is not possible, mirrored packets could be sent over ERSPAN to an analysis VM running on an existing server. Combining firewall logs, active scanning, and management APIs could also help fill some of the gaps that packet inspection alone cannot cover.
Of course, there is no evidence that Elisity currently offers this PQC analysis capability as a commercial product. Cisco’s IOx-based, switch-hosted sensors provide a useful real-world precedent, not proof that Elisity has completed such a product.
✅ 3. Why Would This Matter If It Were Actually Implemented?
Rather than installing new physical sensors throughout the network, this approach could reuse existing switches, containers, and VMs as much as possible, while examining a wider range of internal communications that existing security products may miss.
If Elisity’s IdentityGraph could associate discovered cryptographic risks with actual devices and, when necessary, use policy enforcement capabilities on existing switches, deployment and day-to-day management might also become simpler.
However, not every blind spot would disappear. Switch CPU, memory, and traffic-mirroring capacity; supported hardware models; communications contained entirely within VMs; and HSMs and other areas invisible to packet inspection would remain challenges to solve.
Ultimately, the real competitive advantage may depend less on simply having a “detection feature” and more on how much actual visibility and operational efficiency can be improved while minimizing additional hardware. We will examine the technical details and validation criteria in the next article.
📌 References
See Elisity’s Hardware Compatibility Matrix, the explanation of VE and VEN, and Cisco’s documentation related to switch-hosted sensors.
The integrated PQC detection architecture for Elisity discussed here is a hypothesis about technical feasibility.
netcreat.substack.com/p/elis…











