내 2025

발행: 2주 전 (2026년 1월 2일 오전 03:04 GMT+9)

14 min read

원문: Dev.to

Source: Dev.to

번역할 텍스트를 제공해 주시면, 요청하신 대로 한국어로 번역해 드리겠습니다.

2024 – 내가 만들고, 빠르게 배우며, 지속적으로 배포할 수 있음을 증명하기

2024년은 내가 만들 수 있고, 빠르게 배울 수 있으며, 프로젝트를 지속적으로 배포할 수 있다는 것을 스스로에게 증명하는 해였습니다.

코드를 프로덕션에 배포했습니다.
실제 실패를 경험했습니다.
결과를 초래하는 아키텍처 결정을 내렸습니다.
어떤 튜토리얼도 가르쳐줄 수 없는 교훈을 얻었습니다.

이 교훈들은 읽어서 얻은 것이 아니라 실천을 통해 얻은 것이었습니다.

2025 – 소프트웨어를 실제로 만드는 것이 무엇을 의미하는지 이해하기

2025년은 화려하지 않았다. 프레임워크나 유행어를 중심으로 돌아가지 않았다. 혼란스럽고 실용적이며 때때로 불편했다.

개인적인 이정표

고등학교를 졸업했다.
화면 너머의 “진짜” 기술 세계를 탐험할 자유 시간을 얻었다.

첫 번째 기술 축제 – GDG Ranchi 주최 DevFest

“서류상으로는 작아 보일지 모르지만, 나에게는 전환점이었다.”

개발자, 발표자, 학생들이 같은 물리적 공간에 모인 모습을 보면서 온라인 학습으로는 절대 느낄 수 없었던 무언가가 깨달아졌다.

DevFest 이전: 기술은 혼자 하는 일처럼 느껴졌다 – 나와 내 PC, 그리고 인터넷 연결뿐.
DevFest 이후: 나는 소프트웨어의 인간적인 면을 보았다: 사람들이 실패를 공유하고, 결정을 토론하며, 실제로 프로덕션에서 부숴놓고 고친 시스템에 대해 이야기하는 모습.

가장 큰 놀라움은 행사 규모가 아니라 내가 그곳에 속한다는 깨달음이었다. 나는 “너무 이르다”거나 “준비가 부족하다”는 것이 아니었다. 논의된 문제들을 이해했고, 더 좋은 질문을 했으며, 더 확고한 방향성을 가지고 떠났다.

“학습은 코드만으로 이루어지는 것이 아니라 노출을 통해서도 이루어진다.”

실제로 무언가를 만드는 사람들과 같은 방에 있는 것은 나에게 기준을 높이고, 더 나은 소프트웨어를 배포하며, 더 책임감 있게 생각하고, 프로젝트를 일회성 실험으로 여기지 않게 만들었다.

Freelancing & the Reality of Production

Thanks to the habit of writing blogs, I secured my first clients as a freelance web developer and took my skills to the real world.

From “Shipping = Finish Line” to Production Discipline

Old mindset: If the app worked locally, deployed successfully, and didn’t crash immediately, it was done.
New reality: Real users, real bugs, and edge cases that manual testing missed forced me to confront production‑grade quality.

Key Takeaways

Every decision carries weight.
Logs, rollbacks, and downtime matter.
Small changes feel heavier when real users depend on them.

In casual projects, mistakes are learning opportunities. In production, mistakes are responsibilities. A broken feature isn’t just “oops”; it interrupts workflows, jeopardizes deliveries, can affect data, and erodes trust.

Mindset Shift

You think twice before deploying.
You test flows you previously ignored.
You plan for failure instead of assuming success.

The biggest change wasn’t technical—it was psychological. I stopped asking “Will this work?” and started asking “What happens when this breaks?” and “What other ways can a user break this?” These questions alone made me a better engineer.

보안 – 사후 생각에서 기본으로

2025년 가장 불편했던 교훈 중 하나는 작은 애플리케이션조차도 얼마나 노출될 수 있는지를 깨달은 것이었습니다.

나는 보안은 사용자가 생긴 뒤에야 중요하다고 믿었습니다.
사용자 기반이 작음에도 불구하고 내 앱을 다운시킨 CVE를 포함한 주요 취약점들이 드러났습니다.

잊지 않을 강력한 규칙

프로덕션에서 절대로 애플리케이션을 root 사용자로 실행하지 마세요 — 절대.
모든 서비스가 스캔, 탐색, 테스트될 것이라고 가정하세요.
보안은 “엔터프라이즈 문제”가 아니라 기본적인 책임입니다.

보안은 2025년에 나에게 추상적인 개념이 아니게 되었습니다. 개인적인 문제가 되었고, 한 번 그렇게 되면 다시는 같은 방식으로 구축하지 않게 됩니다.

복잡성에 직면하게 만든 프로젝트들

1. 식료품 배달 앱 (Blinkit 영감)

표면: 사용자, 제품, 장바구니, 주문.
현실: 시간에 민감한 워크플로우, 상태 전이, 운영 압박.
교훈: 주문은 단순한 데이터가 아니라 약속이다. 늦은 업데이트, 일관성 없는 상태, 혹은 누락된 엣지 케이스는 즉시 신뢰 붕괴로 이어진다.

2. 라이브 스트리밍 및 비디오 처리

초점: 트랜스코딩 파이프라인, 인코딩 포맷, 지연 시간, 자원 사용량.
교훈: 비디오 시스템은 인프라 문제이며, 단순히 프론트엔드 문제만은 아니다. 이는 성능과 확장성에 대한 나의 사고 방식을 재구성했다.

3. Finflow – 나의 지출 추적기

간단한 웹 앱으로 시작했으며, 주요 … 원본에서 내용이 잘렸음 로 발전했다.

Closing Thoughts

2025년은 프로덕션 소프트웨어는 사고방식의 전환을 요구한다는 것을 가르쳐 주었습니다:

배포하기 전에 두 번 생각하세요.
이전에 무시했던 흐름을 테스트하세요.
성공을 가정하지 말고 실패를 계획하세요.

가장 큰 변화는 심리적인 것이었습니다: “이게 작동할까?”에서 “깨졌을 때 무슨 일이 일어날까?”로 전환하는 것이었습니다.

이 글을 읽고 같은 흥분과 불편함을 느낀다면, 올바른 길을 가고 있다는 것을 알아두세요. 지저분하고 불편한 순간이 진정한 성장의 순간입니다. 🚀

# 2025 – Lessons Learned

Updates and a Flutter mobile app that synced data with the web taught me that shared state is one of the hardest problems in software.  
The UI is forgiving — data corruption is not.

When GitHub Actions were blocked for me, I didn’t wait. I built a simple CI/CD pipeline myself. It wasn’t fancy, but it worked — and, more importantly, it forced me to understand deployments at a lower level. When the tooling disappeared, the learning multiplied.

Payments were another major theme. I integrated multiple payment gateways, explored different verification patterns, callback flows, retries, and failure handling. Payments taught me that **correctness matters more than elegance**. You don’t optimize for beauty when money is involved — you optimize for certainty.

I briefly explored Flutter more deeply, but eventually realized my long‑term focus was better aligned with Expo and JavaScript‑based ecosystems. That detour wasn’t wasted — it clarified my direction.

By the end of the year I was building something bigger: a platform‑style app inspired by Hago and WePlay. Not just a game, but a system — users, sessions, state, and real‑time interaction.

Every project added a new layer to how I think. Not “how do I build this?” but **“what breaks first, and why?”**

Vibe‑Coding Mini‑Project

긍정적인 메시지를 전 세계에 퍼뜨리면서 vibe‑coding을 시도하기 위해 간단한 앱을 코딩했습니다. 이것은 Hacktoberfest 기간에 티셔츠만을 위해 참여하는 가짜 참여자를 비판하기 위한, 거의 풍자적인 작은 프로젝트였습니다.

앱은 복잡하지 않았습니다. 새로운 아키텍처적 도전을 도입하지 않았지만 목적을 달성했습니다: 의견이 뚜렷하고, 빠르며, 정직한 무언가를 폴리시나 메트릭에 신경 쓰지 않고 만들 수 있었습니다. 이것은 예상보다 더 큰 의미가 있었습니다.

ReadmeHub

ReadmeHub는 빌딩이 여전히 즐거울 수 있고, 모든 프로젝트가 제품이 될 필요는 없다는 것을 일깨워 주었습니다. 어떤 프로젝트는 단지 무언가를 말하거나, 아이디어를 탐구하거나, 가려운 곳을 긁기 위해 존재합니다.

책임감, 프로덕션 압박, 그리고 실제 결과가 뒤따르는 한 해 속에서, 이 작은 프로젝트는 내가 처음 빌딩을 시작한 이유와 다시 연결될 수 있게 도와주었습니다. 확인해 보세요:

핵심 요점

소프트웨어는 책임 있는 행동이다. 프로덕션에서의 실수는 단순한 실수가 아니라, 당신이 책임져야 할 실제 문제이다.
일단 프로덕션에 배포되면, 그것은 “당신의 코드”가 아니라 다른 사람들이 의존하는 것이 된다. 이 변화는 당신이 생각하고, 테스트하고, 배포하고, 문제가 발생했을 때 대응하는 방식을 바꾼다.
의도 없이 빠르게 진행하면 취약한 시스템이 된다. 엔지니어링에서의 성숙함은 종종 더 인상적인 것을 만들 수 있음에도 불구하고, 더 단순하고 안전한 옵션을 선택하는 모습으로 나타난다.
성장이라는 것은 얼마나 많이 배포하느냐가 아니라, 배포한 것이 가져올 결과를 얼마나 깊이 이해하느냐이다.

그 사고방식이 모든 것을 바꾸었다.

2026 – 목표 및 우선순위

2025년이 경험을 통한 학습이었다면, 2026년은 그 경험을 공개적으로 공유하고 더 견고한 소프트웨어를 만드는 해가 될 것입니다.

내가 하고 싶은 일

더 많은 콘텐츠를 만들기 — 트렌드를 쫓는 튜토리얼이 아니라, 무엇이 잘 작동했는지, 무엇이 깨졌는지, 그리고 다르게 할 수 있었던 점에 대한 솔직한 글쓰기.
코드 자체만이 아니라 코드 뒤에 있는 결정들을 문서화하기.

2026년 나의 우선순위

덜 만들되, 더 잘 만들기
프로덕션을 신성하게 대하기
계속 배우되, 현실을 잊지 않기
결과만이 아니라 여정을 공유하기

2025년은 소프트웨어가 얼마나 취약할 수 있는지를 알려주었습니다. 2026년은 더 많은 주의를 기울여 소프트웨어를 구축하고, 다른 사람들도 동일하게 할 수 있도록 돕는 해입니다.

여러분의 2025년이 저만큼이나 놀랍고 멋졌길 바랍니다. 앞으로도 모두에게 행복한 2026년이 되길 기원합니다! 🎉