For years, my primary machine had been a MacBook Pro connected to a Thunderbolt monitor in clamshell mode. It handled all of my daily work without issue.

As agents began taking on longer-running tasks — generating code, running tests, analyzing repositories, and preparing reports — I added a Mac mini to my desk. The goal was simple: allow agents to work continuously on a dedicated machine while keeping my primary work environment responsive and uncluttered.

Adding a second computer turned out to be easy.

Finding a comfortable way to use two computers side by side was not.

Starting with SSH

My first approach was straightforward.

I assigned a static IP address to the Mac mini and connected via SSH. To ensure work continued even after disconnections, I used zellij to manage terminal sessions.

For terminal-based workflows, this worked remarkably well. Claude Code and Codex could run for hours, and I could reconnect at any time to check progress.

Over time, however, more workflows began requiring a graphical interface.

Claude Desktop introduced features such as Cowork, and many tasks increasingly relied on browser interactions. Agents were no longer operating solely inside terminal sessions. SSH alone was no longer sufficient.

Using HHKB Multi-Pairing

The next step was to use the multi-pairing capability of my HHKB Hybrid keyboard.

I kept a dedicated Magic Mouse connected to each machine and shared only the keyboard.

The setup worked, but frequent switching revealed its limitations.

Occasionally the keyboard would not switch on the first attempt. Bluetooth reconnection delays were usually only a few seconds, but when switching dozens of times throughout the day, those small interruptions became noticeable.

A Hybrid Wired and Wireless Setup

Since the HHKB also supports USB connectivity, I experimented with a hybrid configuration.

The keyboard remained connected to the MacBook Pro via USB while maintaining a Bluetooth connection to the Mac mini.

This improved responsiveness, but it still required conscious management of which computer currently owned the keyboard. The friction was reduced, but not eliminated.

Remote Desktop

I then tried controlling the Mac mini through remote desktop software.

On paper, this seemed like the cleanest solution. Everything could be done from a single machine.

In practice, the experience felt less ideal for development work.

Display quality was not quite the same as working locally, and input latency was always present to some degree. For occasional administrative tasks it was acceptable, but for day-to-day software development it felt noticeably less comfortable.

Synergy

Next, I experimented with Synergy.

The concept is appealing: move the cursor across the edge of one screen and seamlessly continue working on another computer using the same keyboard and mouse.

Initially it felt surprisingly natural.

The challenges appeared later.

One recurring issue involved Korean and English input methods. For example, the MacBook Pro might be in Korean input mode while the Mac mini remained in English mode. Switching between systems occasionally resulted in broken character composition or unexpected input behavior.

There were also occasional synchronization issues and intermittent glitches.

The idea was excellent, but I found the overall experience less predictable than I wanted.

Eventually, a Hardware KVM

After trying several software-based approaches, I reached a simple conclusion:

The problem was not really about software. It was about input devices.

Today I use an ATEN CS62KM KVM switch.

Both the MacBook Pro and the Mac mini are connected via USB, and switching is handled automatically based on keyboard activity.

Once configured, it largely disappears from daily attention.

• No noticeable switching delay
• No Bluetooth reconnection issues
• No input method synchronization problems
• Consistent and predictable behavior

My Magic Mouse devices remain separate because they connect directly over Bluetooth, so I still keep one mouse paired with each computer.

Even so, this has been the most reliable setup I have found.

JetKVM at Home

Separately, I also use a JetKVM at home.

JetKVM solves a different problem.

Unlike a traditional KVM switch, it functions more like a remote management appliance.

Its strengths are obvious:

• Access before the operating system boots
• BIOS and recovery-mode access
• Remote troubleshooting capabilities
• Secure connectivity through Tailscale

For managing remote machines, it is extremely useful.

However, I found it less suitable for everyday interactive work.

JetKVM operates through a web browser. While this enables broad accessibility, it introduces a limitation that is particularly noticeable on macOS: keyboard shortcuts involving the Command key.

Shortcuts such as:

• Cmd+C
• Cmd+V
• Cmd+Tab
• Cmd+Space

are often intercepted by the local machine before they can reach the remote one.

As a result, sending Command-key combinations frequently requires using JetKVM’s on-screen virtual keyboard.

For occasional maintenance tasks, this is perfectly acceptable.

For software development, where Command-key shortcuts are used constantly throughout the day, it quickly becomes cumbersome.

In that sense, JetKVM and a traditional KVM switch address different needs.

JetKVM excels at remote management.

A hardware KVM excels at day-to-day interaction.

Current Setup

Today, my workspace looks like this:

• MacBook Pro for primary work
• Mac mini dedicated to agent workloads
• HHKB Hybrid keyboard
• Two Magic Mouse devices
• ATEN CS62KM KVM switch

SSH and zellij are still part of the workflow, but they serve a different purpose. They keep long-running tasks alive. The actual experience of moving between machines is handled by the KVM.

One thing became clear through this process.

Adding another computer is easy.

Making two computers feel like a single workspace is considerably harder.

For now, a hardware KVM remains the simplest and most reliable solution I have found.

원래는 회사 업무용 MacBook Pro 한 대만 사용했다. MacBook Pro는 썬더볼트 모니터에 연결해 클램쉘 모드로 사용하고 있다.

에이전트가 장시간 작업을 수행하는 일이 늘어나면서 별도의 Mac mini를 추가했다. 에이전트에게 코드를 생성하게 하거나 테스트를 수행하게 하는 동안, 주력 업무 환경은 그대로 유지하고 싶었기 때문이다.

Mac mini를 도입하는 것은 어렵지 않았다. 예상보다 오래 걸린 것은 두 대의 컴퓨터를 자연스럽게 함께 사용하는 방법을 찾는 일이었다.

SSH로 시작

처음에는 가장 단순한 방법을 사용했다.

Mac mini에 고정 IP를 할당하고 SSH로 접속했다. 세션이 끊겨도 작업이 유지되도록 zellij를 사용했다.

이 방식은 터미널 기반 작업에는 충분히 만족스러웠다. Claude Code나 Codex를 실행해 두고 필요할 때 접속해 상태를 확인할 수 있었다.

하지만 시간이 지나면서 GUI 환경이 필요한 경우가 늘어났다.

최근의 Claude App은 Cowork 기능을 제공하고, 브라우저를 직접 사용하는 작업도 많아졌다. 에이전트가 단순히 터미널에서 실행되는 프로그램이 아니라 하나의 애플리케이션으로 동작하기 시작하면서 SSH만으로는 부족해졌다.

HHKB 멀티페어링

다음으로 시도한 것은 HHKB Hybrid의 멀티페어링 기능이었다.

마우스는 컴퓨터마다 하나씩 두고, 키보드만 공유했다.

기능 자체는 잘 동작했지만 사용 빈도가 높아질수록 불편함이 보였다.

기기 전환이 한 번에 이루어지지 않는 경우가 있었고, 블루투스 재연결에 몇 초 정도의 시간이 필요했다. 개별적으로는 작은 지연이지만 하루 동안 수십 번 반복되면 의외로 신경이 쓰였다.

유선과 무선 혼합 구성

HHKB는 USB 연결도 지원한다.

그래서 주로 사용하는 MacBook Pro에는 USB로 연결하고, Mac mini만 블루투스로 연결했다.

이전보다 나아지기는 했지만 근본적으로 해결된 느낌은 아니었다. 여전히 키보드가 어느 컴퓨터에 연결되어 있는지 의식해야 했다.

원격 데스크톱

Mac mini를 원격 데스크톱으로 사용하는 방법도 시도했다.

물리적으로는 하나의 컴퓨터만 사용하면 되기 때문에 가장 깔끔한 방법처럼 보였다.

실제로 사용해보니 개발 환경으로는 아쉬움이 있었다.

화면 품질이 떨어지고, 입력 지연도 있었다. 문서 작업 정도는 가능했지만 IDE를 사용하거나 여러 창을 오가며 작업하기에는 만족스럽지 않았다.

Synergy

다음으로는 Synergy를 사용했다.

마우스를 화면 경계로 이동하면 다른 컴퓨터로 넘어가는 방식이다.

처음에는 상당히 인상적이었다. 두 대의 컴퓨터가 하나의 작업 공간처럼 느껴졌다.

하지만 한영 입력기 문제가 발생했다.

예를 들어 MacBook Pro는 한글 입력 상태인데 Mac mini는 영어 입력 상태인 경우가 있었다. 이런 상태에서 전환하면 자음과 모음이 분리 입력되거나 예상하지 못한 입력 문제가 발생했다.

간헐적인 오동작도 있었다.

아이디어는 좋았지만 안정성 측면에서는 아쉬움이 남았다.

결국 KVM

여러 방법을 사용해 본 결과, 입력 장치 자체를 전환하는 편이 더 단순하다는 결론에 도달했다.

현재는 ATEN CS62KM을 사용하고 있다.

MacBook Pro와 Mac mini를 USB로 연결하고, 키보드 입력을 기반으로 자동 전환하는 방식이다.

설정 이후에는 특별히 신경 쓸 일이 거의 없다.

• 전환 지연이 없다.
• 블루투스 연결 문제도 없다.
• 입력기 관련 문제도 발생하지 않는다.

매직 마우스는 블루투스 장치라 KVM과 함께 사용하지 못한다. 그래서 마우스는 여전히 컴퓨터마다 하나씩 두고 있다.

그럼에도 지금까지 시도한 방법 중에서는 가장 만족스럽다.

집에서는 JetKVM

회사 환경과는 별개로 집에서는 JetKVM도 사용하고 있다.

JetKVM은 일반적인 KVM이라기보다 원격 관리 장비에 가깝다.

장점은 명확하다.

운영체제가 부팅되기 전 단계부터 접근할 수 있고, BIOS나 복구 모드에도 진입할 수 있다. Tailscale과 함께 사용하면 외부에서도 안전하게 접근할 수 있다.

원격 관리 용도로는 매우 유용하다.

반면 일상적인 작업에는 제약이 있다.

JetKVM은 브라우저를 통해 화면과 입력을 전달한다. 문제는 macOS의 Cmd 기반 단축키다.

Cmd+C, Cmd+V, Cmd+Tab 같은 단축키는 대부분 로컬 컴퓨터가 먼저 처리한다. 원격 컴퓨터로 전달하려면 JetKVM의 가상 키보드를 사용해야 한다.

가끔 사용하는 관리 작업에는 문제가 없지만, IDE와 브라우저를 오가며 지속적으로 작업하는 환경에는 적합하지 않았다.

현재 구성

현재는 다음과 같은 형태로 사용하고 있다.

• MacBook Pro: 메인 업무 환경
• Mac mini: 에이전트 작업 전용
• HHKB Hybrid
• 매직 마우스 2대
• ATEN CS62KM

SSH와 zellij도 여전히 사용한다. 다만 그것은 작업을 지속시키기 위한 도구이고, 컴퓨터를 사용하는 경험 자체는 KVM이 담당하고 있다.

Mac mini를 도입하면서 깨달은 점이 하나 있다.

컴퓨터를 한 대 더 추가하는 것은 어렵지 않다. 하지만 두 대의 컴퓨터를 하나의 작업 환경처럼 사용하는 것은 생각보다 많은 시행착오가 필요하다.

현재까지는 하드웨어 KVM이 가장 단순하고 안정적인 해법이었다.

First, building a system that retains great people matters more than hiring new ones. If you truly understand the time, cost, and effort required to recruit strong talent, it becomes obvious that retention is the real leverage point. Interestingly, a structure where great people choose to stay naturally becomes a place where other great people want to join.

Second, creating something new is not the only thing that drives success. In many organizations, people who chase new initiatives often receive the most visible recognition. But in reality, what makes a service successful is the work of those who steadily improve quality, resolve countless small and large issues, and keep the system running. Sustained operation and incremental improvement are what ultimately build real competitive advantage.

Finally, sustainability is key. Any process — whether reporting, reviews, or otherwise — must be simple enough to persist. If it feels burdensome, it will be ignored. Once a “broken window” appears, it must be fixed immediately. Allowing small issues to accumulate makes recovery far more difficult later.

In the end, the takeaway is straightforward: Build systems that don’t depend on individuals, win through sustainability rather than speed, and focus on creating real value — not just visible outcomes.

첫째, 좋은 멤버가 떠나지 않게 하는 시스템이다. 좋은 사람을 새로 채용하는 데 드는 시간과 비용을 생각하면, 결국 중요한 것은 ‘채용’이 아니라 ‘유지’다. 그리고 흥미로운 점은, 좋은 멤버가 떠나지 않는 구조는 자연스럽게 좋은 멤버가 오고 싶어지는 구조이기도 하다는 점이다.

둘째, 새로운 것을 만드는 것만이 성과는 아니다. 많은 조직에서 신규 과제만 쫓는 사람들이 더 눈에 띄는 성과를 가져가는 경우를 본다. 하지만 실제로 서비스를 성공시키는 것은, 묵묵히 품질을 개선하고 크고 작은 이슈를 해결하며 운영을 책임지는 사람들이다. 눈에 보이지 않는 유지와 개선이 결국 서비스의 본질적인 경쟁력을 만든다.

셋째, 지속가능성이다. 보고나 리뷰 같은 어떤 프로세스든 ‘지속될 수 있는 수준’이어야 의미가 있다. 번거로운 절차는 결국 무시된다. 깨진 창문이 하나 생기면 반드시 바로 고쳐야 한다. 한 번 무너지기 시작한 시스템을 다시 바로 세우는 일은 훨씬 더 어렵다.

결국 핵심은 단순하다. 사람이 아니라 구조로 버티고, 속도가 아니라 지속으로 이기고, 눈에 보이는 성과가 아니라 실제 가치를 만드는 것.

Psychological resilience.

As the years go by, there are moments when it becomes harder to fully agree with the idea that “experience equals competence.” The traces of failure can become insight — but they can also harden into bias and quietly block new attempts. As a senior, the starting point is neither glorifying nor ignoring past wounds, but looking at them objectively. Experience that hasn’t been processed does not automatically become an asset; if anything, it can turn into a constraint.

Flexible decision-making.

Most of the decisions we face are reversible. They are what people call “two-way doors.” You can step through, evaluate, and step back if needed. The real problem is treating every choice like a “one-way door.” If we reserve deep caution for truly irreversible decisions, and move quickly on the rest — executing and iterating through feedback loops — both individuals and organizations benefit. Speed is not recklessness; it is a way of increasing learning density.

A career is a jungle gym.

The ladder model — always climbing upward — oversimplifies reality. A career is closer to a jungle gym. You don’t only move up. Sometimes you move sideways. Sometimes you move down to strengthen a different axis. The distinction between individual contributor and manager matters less than the scope and depth of one’s influence. Instead of repeatedly applying past formulas for success, we sometimes need to let go of old mental models. Learning something new is important, but so is discarding what is no longer valid.

The value of healthy conflict.

I don’t believe a leader’s role is to eliminate conflict. When grounded in trust, intense debate can make a team stronger. Forced harmony simply postpones the problem. Feedback, too, is not a sophisticated technique; it is an honest conversation that clarifies the gap between expectations and observable behavior. Teams that avoid discomfort rarely grow.

Ultimately, failure is less about being right or wrong and more about direction. It is not a verdict but a signal calling for recalibration. To read that signal, however, we must not be exhausted. In a state of burnout, even a compass fails to point clearly. Managing oneself is part of professional maturity. Designing a sustainable rhythm — perhaps that, too, is part of what it means to be a senior.

‘실패는 성공의 어머니’란 말은 익숙합니다. 하지만 실제 삶에서 그 문장은 생각보다 단순하지 않습니다. 최근 시니어 엔지니어로서 커리어를 돌아보며 한기용 님의 『실패는 나침반이다』를 읽고 생각을 정리해 봅니다.

심리적 회복력. 연차가 쌓일수록 ‘경험이 곧 실력’이라는 말에 선뜻 동의하기 어려울 때가 있습니다. 실패의 흔적이 통찰이 되기도 하지만, 때로는 편향으로 굳어 새로운 시도를 가로막기도 합니다. 시니어라면 과거의 상처를 미화하지도, 외면하지도 않고 객관적으로 바라보는 일부터 시작해야 합니다. 치유되지 않은 경험은 자산이 되지 못하면 오히려 제약이 되기도 합니다.

유연한 의사결정. 우리가 마주하는 결정의 대부분은 되돌릴 수 있습니다. 이른바 ‘Two-way door’입니다. 실행해 보고, 아니라면 수정하면 됩니다. 문제는 모든 선택을 ‘One-way door’처럼 다루는 태도입니다. 정말 되돌릴 수 없는 결정만 신중하게 다루고, 나머지는 빠르게 실행하고 회고하는 편이 조직에도 개인에게도 이득입니다. 속도는 무모함이 아니라, 학습의 밀도를 높이는 방식입니다.

커리어는 정글짐. 위로만 올라가는 사다리 모델은 현실을 과도하게 단순화합니다. 커리어는 정글짐에 가깝습니다. 꼭 위로만 오르지는 않습니다. 옆으로 이동하기도 하고, 때로는 아래로 내려가 다른 축을 다지기도 합니다. 실무자냐 매니저냐의 구분보다 중요한 것은 영향력의 범위와 밀도입니다. 과거의 성공 공식을 반복하는 대신, 필요하다면 기존 사고방식을 과감히 내려놓아야 합니다. 새로운 것을 배우는 일만큼이나, 더 이상 유효하지 않은 것을 버리는 일도 중요합니다.

건강한 갈등의 효용. 리더의 역할이 갈등을 제거하는 것이라고 생각하지 않습니다. 신뢰를 전제로 한 치열한 논쟁은 오히려 팀을 단단하게 만듭니다. 억지 화합은 문제를 잠시 덮어둘 뿐입니다. 피드백 역시 거창한 기술이 아니라, 기대치와 실제 관찰 사이의 간극을 명확히 짚는 대화에 가깝습니다. 불편함을 감수하지 않는 팀은 성장도 더딥니다.

결국 실패는 정오의 문제가 아니라 방향의 문제입니다. 틀렸다는 판정이 아니라, 재조정을 요구하는 신호에 가깝습니다. 다만 그 신호를 읽어내려면 스스로가 지치지 않아야 합니다. 번아웃 상태에서는 나침반도 방향을 제대로 가리키지 못합니다. 자신을 관리하는 일 역시 전문성의 일부입니다. 지속 가능한 리듬을 설계하는 일까지 포함해서, 아마도 그것이 시니어의 역할이 아닐까 생각합니다.

Lately, much of the discourse around AI-assisted coding has centered on tactics:

which model to use for which task, how to structure sub-agents, how to engineer prompts for better results, and how to manage context windows effectively.

Observing this trend naturally brings to mind an earlier era of software development — when C compilers were far less capable than they are today. At the time, developers relied heavily on micro-optimizations: bit hacks, Duff’s device, and other clever tricks. Used well, they inspired admiration and sometimes delivered real performance gains. At the same time, many of these techniques were ad hoc, fragile, and difficult to maintain.

Fast forward to the present. How many developers still worry about such tricks? Very few. Modern compilers handle these optimizations far better than humans ever could, and developers are far more productive focusing on architecture, abstractions, and problem decomposition instead.

The current conversation around AI usage feels similar to that earlier phase. Much of what we see on social media is an intense focus on “how to handle a not-yet-smart-enough AI”: prompt recipes, agent choreography, and operational hacks. Meanwhile, foundational concerns — system design, problem definition, abstraction, and modeling — seem to receive comparatively less attention.

If we think of AI as a modern compiler that translates natural language into code, many of today’s popular tips are likely to be temporary. As models improve, these techniques will naturally fade away, just as manual micro-optimizations did with the rise of smarter compilers.

What truly deserves our attention is not which AI model to choose, but what we are trying to build, how we structure it, and whether we have clearly understood the problem we are solving in the first place.

This feels like a moment that calls for calm reflection — a time to step back and reconsider what really matters, and where our focus should be.

요즘 AI 코딩 관련 담론을 보면, 어떤 일에 어떤 AI 모델을 써야 하는지, 서브 에이전트를 어떻게 구성해야 하는지, 프롬프트에 어떤 구조로 작성해야 성능이 나오는지, 컨텍스트 관리를 어떻게 해야 하는지와 같은 이야기들이 주를 이룹니다.

이 흐름을 보며 자연스럽게 떠오르는 것은, 과거 C 컴파일러가 충분히 똑똑하지 않던 시절에 유행하던 각종 최적화 기법들입니다. 비트 해킹이나 Duff’s device처럼, 잘 쓰면 “우와” 소리를 듣고 실제로도 유용했지만, 동시에 편법적이고 잡다한 테크닉들도 적지 않았습니다.

컴파일러가 발전한 지금은 어떨까요. 대부분의 개발자들은 더 이상 그런 기법을 고민하지 않습니다. 컴파일러가 더 잘 처리해 주기 때문이고, 그보다 더 중요한 설계와 구조에 집중하는 것이 생산적이기 때문입니다.

최근 SNS에서 보이는 AI 활용 논의는 아직은 “덜 똑똑한 AI를 잘 다루기 위한 요령”에 지나치게 집중되어 있는 듯합니다. 반면, 시스템 설계나 문제 정의, 추상화와 같은 기본적인 사고에는 상대적으로 관심이 줄어든 것처럼 보입니다.

AI를 자연어를 코드로 변환하는 현대적 컴파일러로 본다면, 지금 유행하는 많은 팁들은 AI가 발전함에 따라 자연스럽게 사라질 가능성이 큽니다.

지금 우리가 정말 고민해야 할 것은 어떤 AI모델을 선택하냐보다, 무엇을 만들 것인지, 어떻게 구조화할 것인지, 그리고 어떤 문제를 풀고 있는지에 대한 명확한 사고 아닐까요.

조금 더 차분하게, 무엇에 집중해야 하는 시점인지 생각해볼 필요가 있어 보입니다.

“Rainbow Mansion” is the name of a shared house in Silicon Valley where the early founders and engineers who opened the New Space era once lived together. Anyone who likes the computer industry has probably encountered stories at least once about the Homebrew Computer Club of the 1970s, Apple’s early history, or hacker culture. In the space industry as well, starting with SpaceX in the 2000s, changes similar to those of the computer industry in the 1970s began to occur. This book is a record in which Ashlee Vance, a technology journalist, closely covered the companies over several years and interviewed founders and key figures, organizing the birth of New Space into a single narrative.

Planet Labs is a company that deploys many small and inexpensive satellites into low Earth orbit, photographs the entire Earth every day, and provides that data over the internet. This became possible thanks to technical choices such as using ordinary consumer electronic components instead of extremely expensive, space-grade parts, and using methods like exploiting differences in atmospheric drag to adjust orbits instead of fuel propulsion. The traditional space industry built large satellites with ultra-high-reliability, ultra-expensive components, spent more than ten years developing them, launched them into geostationary orbit at a cost of billions of dollars, and then used them again for more than ten years. But in an era where smartphones have become more powerful than mainframes, this approach has increasingly been questioned. Wouldn’t a model where you build something within a year for a few hundred thousand dollars, launch it for a million dollars, and replace it every two or three years be cheaper, faster, and allow you to use the latest technology? This question emerged, and that question became the starting point of New Space. Just as mainframes were replaced by PCs and smartphones, satellites began to undergo the same transformation.

Rocket Lab is an example showing that this change also occurred in the launch domain. Founded by Peter Beck from New Zealand, this company opened a market with Electron, a launch vehicle dedicated to very small satellites. He taught himself the necessary skills while working at appliance companies and yacht companies instead of going to university, and eventually succeeded in launching a rocket in New Zealand. Electron is much smaller than SpaceX’s Falcon 9, but this small rocket provided decisive value to small-satellite companies. Previously, small satellites had to be launched as secondary payloads on large satellites, so they could not choose their schedules or orbits, but Electron made it possible to launch alone into the desired orbit at the desired time. This was not merely a matter of cost but a matter of time and operational freedom, and for many startups it was in itself a factor that determined the success or failure of their business.

Firefly shows yet another reality. Technically, it succeeded in launching, but conflicts between founders and investors, geopolitical issues, and government regulations constantly shook the company. This story clearly reveals that space is not merely a romantic realm but an industrial space where capital, politics, and national interests are intricately intertwined.

Rainbow Mansion is an interesting story for those who have a romance about space, and it is also a good introductory book to the space industry of the 21st century. However, what this book shows is not only romance. Space is still an attractive domain, but that romance now operates not as the dream of hippies, but within a cold industry intertwined with startups and investors, governments and regulations.

‘레인보우 맨션’은 뉴스페이스 시대를 연 초기 창업자들과 엔지니어들이 함께 살던 실리콘밸리의 공동 주택 이름이다. 컴퓨터 산업을 좋아하는 사람이라면 1970년대 홈브루 컴퓨터 클럽이나 애플의 초기 역사, 해커 문화에 대한 이야기들을 한 번쯤 접해보았을 것이다. 우주 산업에서도 2000년대 스페이스X를 시작으로 컴퓨터 산업의 1970년대와 유사한 변화가 일어났다. 이 책은 기술 전문 기자인 애슐리 반스가 수년에 걸쳐 기업들을 밀착 취재하고, 창업자들과 핵심 인물들을 인터뷰하여 뉴스페이스의 탄생 과정을 하나의 서사로 정리한 기록이다.

플래닛 랩스는 수많은 작고 저렴한 위성을 저궤도에 배치해 매일 지구 전체를 촬영하고 그 데이터를 인터넷으로 제공하는 회사다. 이것이 가능해진 것은 우주 전용 초고가 부품 대신 일반 소비자용 전자 부품을 사용하고, 연료 추진 대신 대기 저항의 차이를 이용해 궤도를 조정하는 방식 같은 기술적 선택 덕분이다. 기존의 우주 산업은 초고신뢰성, 초고가 부품으로 만든 대형 위성을 10년 이상 개발하고 수십억 달러를 들여 정지궤도에 올린 뒤 다시 10년 이상 사용하는 방식이었다. 그러나 스마트폰이 메인프레임보다 강력한 성능을 가지게 된 시대에 이런 방식은 점점 의심받기 시작했다. 수십만 달러로 1년 안에 만들고, 백만 달러로 쏘아 올리고, 2~3년마다 교체하는 방식이 오히려 더 저렴하고 더 빠르며 더 최신 기술을 사용할 수 있는 것은 아닐까 하는 질문이 등장했고, 이 질문이 곧 뉴스페이스의 출발점이 되었다. 메인프레임이 PC와 스마트폰으로 바뀐 것처럼 인공위성도 같은 변화를 겪기 시작한 것이다.

로켓랩은 이 변화가 발사 영역에서도 일어났음을 보여주는 사례다. 뉴질랜드 출신의 피터 벡이 창업한 이 회사는 초소형 위성 전용 발사체인 일렉트론 로켓으로 시장을 열었다. 그는 대학 대신 가전 회사와 요트 회사 등에서 일하며 필요한 기술을 독학했고 결국 뉴질랜드에서 로켓 발사에 성공했다. 일렉트론은 스페이스X의 팰컨9보다 훨씬 작지만, 이 작은 로켓은 초소형 위성 기업들에게 결정적인 가치를 제공했다. 이전에는 소형 위성이 대형 위성에 얹혀 발사되어야 했기 때문에 일정과 궤도를 선택할 수 없었지만, 일렉트론은 원하는 시기에 원하는 궤도로 단독 발사를 가능하게 만들었다. 이는 단순한 비용 문제를 넘어 시간과 운영 자유도의 문제였고, 많은 스타트업에게는 그 자체로 사업의 성패를 좌우하는 요소였다.

파이어플라이는 이와는 또 다른 현실을 보여준다. 기술적으로는 발사에 성공했지만, 창업자와 투자자 간 갈등, 지정학적 문제, 정부 규제 같은 요소들이 회사를 끊임없이 흔들었다. 이 이야기는 우주가 단순히 낭만적인 공간이 아니라 자본과 정치, 국가 이해관계가 복잡하게 얽힌 산업 공간이라는 사실을 분명하게 드러낸다.

‘레인보우 맨션’은 우주에 로망을 가진 사람에게는 흥미로운 이야기이고, 21세기 우주 산업의 입문서로도 읽기 좋은 책이다. 다만 이 책이 보여주는 것은 로망만은 아니다. 우주는 여전히 매력적인 공간이지만, 그 로망은 이제 히피들의 꿈이 아니라 스타트업과 투자자, 정부와 규제가 얽힌 냉정한 산업 속에서 작동하고 있다.