2025년 6월 19일, 상트페테르부르크에서 열린 PiterJS #79에 다녀왔습니다. 그날의 주제는 화려하지 않았고, 그래서 오히려 좋았습니다. 다음 기능을 어떻게 출시할지가 아니라 이미 만들어진 것을 어떻게 유지할지, 즉 monitoring, deployment, refactoring에 관한 이야기였습니다.
프로그램도 이 주제와 잘 맞았습니다. Pavel Shlykov는 오래된 모놀리스를 개선하는 방법을, Alexander Panfilov는 FrontOps를, Igor Antonov는 웹 애플리케이션 성능 지표를 다뤘습니다. 저는 세 주제 모두에서 실용적인 메모를 남겼습니다.
예상하지 못했던 부분은 Q&A였습니다. 세션 중 좋은 질문을 했다는 이유로 두 개의 상을 받았습니다. 기술적으로 대단한 성과는 아니지만, 오히려 그래서 그날 가장 기억에 남았습니다. 제가 여전히 오프라인 기술 밋업을 좋아하는 이유를 다시 확인했기 때문입니다. 준비된 발표를 듣는 데서 끝나는 것이 아니라, 발표자가 아직 같은 공간에 있을 때 자신의 이해가 맞는지 직접 확인할 수 있습니다.
유용했던 주제는 새로움이 아니라 유지보수였다
프론트엔드 행사는 쉽게 새 프레임워크, 새 API, 새 추상화의 연속이 되곤 합니다. PiterJS #79는 조금 더 현실적이었습니다. 공식적으로도 이미 존재하는 소프트웨어를 어떻게 지원할 것인가가 중심 주제였습니다.
이 점이 중요한 이유는 많은 엔지니어링 작업이 첫 번째 성공적인 릴리스 이후에 시작되기 때문입니다. 레거시 모놀리스라고 해서 자동으로 나쁜 시스템이 되는 것은 아니고, “현대화”가 자동으로 전면 재작성을 의미하지도 않습니다. 실제로 더 중요한 질문은 보통 좁습니다. 지금 시스템을 가장 힘들게 하는 제약이 무엇이며, 어떤 변경이 제거하는 위험보다 더 큰 위험을 만들지 않으면서 그 문제를 줄일 수 있는가?
세 발표가 서로 잘 이어진 것도 이 때문이었습니다. Refactoring은 코드를 바꿉니다. FrontOps는 프론트엔드를 어떻게 빌드하고, 패키징하고, 배포하고, 운영하는지를 바꿉니다. 성능 작업은 결과를 어떻게 측정하는지를 바꿉니다. 서로 다른 층이지만 결국 같은 문제를 다룹니다. 커진 실제 시스템을 계속 이해 가능하고 제어 가능한 상태로 유지하는 일입니다.
FrontOps는 Dockerfile보다 넓은 개념이다
밋업에서 적은 메모 중 하나는 Docker를 이용한 FrontOps였습니다. 여기서 중요한 구분은 Docker는 도구이지 FrontOps 자체의 정의가 아니라는 것입니다.
프론트엔드의 책임이 npm run build가 성공했다고 끝나는 것은 아닙니다. 프로덕션에서는 재현 가능한 빌드, artifact 패키징, 설정 전달, 릴리스 rollback, cache 동작, 장애 관찰 등을 여전히 누군가 고민해야 합니다. Container는 일부 과정을 더 예측 가능하게 만들 수 있지만, 운영상의 판단 자체를 대신하지는 않습니다.
이 구분은 흔한 오해를 바로잡는 데 유용합니다. 성공한 build가 증명하는 것은 build가 끝났다는 사실입니다. 애플리케이션이 올바르게 배포될 것인지, 프로덕션에서 올바르게 동작할 것인지, 문제가 생겼을 때 쉽게 복구할 수 있을 것인지까지 증명하지는 않습니다.
성능은 먼저 “느리다”의 의미를 정하는 데서 시작한다
성능 발표는 측정을 어떻게 바라볼지에 대해 특히 실용적이었습니다. 사전에 공개된 범위에는 로딩 속도에 영향을 주는 요소, 여러 프론트엔드 성능 지표, “느림”을 수치로 표현하는 방법, 그리고 최적화가 항상 필요한 것은 아닌 이유까지 포함되어 있었습니다.
마지막 부분은 생각보다 중요합니다. “더 빠르게 만들자”는 말은 객관적으로 들리지만, 지표와 사용자가 실제로 느끼는 문제가 없다면 비싼 추측이 될 수 있습니다. 유용한 성능 개선 과정은 무엇이 실제로 느린지 정의하고, 측정하고, 병목을 찾고, 관련 있는 한 가지를 바꾸고, 다시 측정하는 데서 시작합니다.
지표 하나가 곧 사용자 경험은 아닙니다. 하지만 논의할 수 있는 공통 단위를 제공합니다. 측정 없이 성능 작업을 하면 기술적으로 인상적인 변경을 많이 하고도 실제 중요한 문제가 나아졌는지 증명하지 못할 수 있습니다.
Q&A가 밋업의 가치를 바꿔 놓았다
나중에 녹화 영상을 보고 링크를 모으는 것은 가능했을 겁니다. 하지만 발표 주변에서 일어나는 상호작용은 그렇게 쉽게 재현할 수 없습니다. 좋은 질문을 하려면 자신의 불확실성을 다른 엔지니어가 답할 수 있을 만큼 구체적인 형태로 압축해야 합니다.
두 개의 상을 받은 것은 즐거웠지만, 더 중요한 교훈은 단순했습니다. 오프라인 밋업에 참여할 준비를 하고 가면, 그것을 실시간 YouTube 재생목록처럼 소비할 때보다 훨씬 많은 가치를 얻을 수 있습니다.
좋은 기술 질문에는 보통 맥락과 제약이 있습니다. “최고의 아키텍처는 무엇인가요?”보다, 팀이 레거시 시스템을 다시 작성할 수 없을 때 어떤 trade-off가 달라지는지, deployment가 backward-compatible해야 할 때 무엇이 달라지는지, 성능 지표는 좋아졌지만 사용자가 체감하는 이점은 없을 때 어떻게 판단해야 하는지를 묻는 편이 더 유용할 수 있습니다.
모든 질문이 영리할 필요는 없습니다. 중요한 것은 가정, 경계, failure mode를 드러내는 데 도움이 되는가입니다.
다음 기술 밋업에 가져가고 싶은 원칙
- 왜 이 발표가 나에게 중요한지 알고 들어간다. 시작 전에 실제 문제나 의문 한 가지를 적어 둡니다.
- 발표자의 경험과 내 시스템을 구분한다. 좋은 case study는 근거이지 보편적인 정답이 아닙니다.
- Trade-off를 묻는다. “언제는 이 방법을 쓰지 않겠습니까?”가 “어떤 도구가 최고입니까?”보다 더 많은 것을 보여줄 때가 많습니다.
- 후속 행동을 하나 남긴다. 밋업 이후 확인하거나 테스트하거나 읽어 볼 것이 연결될 때 메모의 가치가 커집니다.
- 설득력 있는 발표를 production proof와 혼동하지 않는다. 아키텍처, deployment, 성능 결정은 여전히 자신의 환경에서 검증해야 합니다.
결국 남은 것
한 번의 밋업이 모든 것을 바꿨다고 과장하고 싶지는 않습니다. PiterJS에서 보편적인 아키텍처 해답을 얻은 것도 아니고, 좋은 발표가 문서, profiling, test, production data를 대신하는 것도 아닙니다.
제가 실제로 가져온 것은 더 구체적이었습니다. 레거시 모놀리스 현대화, Docker를 활용한 FrontOps, 웹 성능 측정에 대한 유용한 메모, Q&A에서 받은 두 개의 상, 그리고 지역 개발자 커뮤니티에 직접 찾아갈 가치가 있다는 또 한 번의 확인입니다.
녹화 영상은 발표를 남길 수 있습니다. 가장 기록하기 어려운 것은 그 발표 주변에서 오간 대화입니다.