재그지그의 개발 블로그

나는 하루 5분만 바꾸기로 했다

Tue, 07 Apr 2026 00:00:00 GMT

햇볕이 따스하니 책 읽기 좋은 날씨였다

날씨가 좋았던 지난 주말, 올해의 첫 책을 읽었습니다. 마포에 있는 채그로라는 북카페였는데, 창문으로 보이는 한강 전망이 참 예쁘더라고요.

이 책은 예전 글또에서 만났던 지환님께 선물받은 책입니다. 이 책을 받은 건 아마 3년 전쯤이었던 것 같아요. 당시 글또 운영진 모임에서 비슷한 주제로 고민을 나눴고, 그때 지환님이 이 책을 소개해 주셨던 것으로 기억합니다.

이 책을 다시 읽게 된 계기는 작년에 연말 회고를 쓰면서입니다. 회사 업무가 바빠지기도 하고 자기 계발을 할 시간이 줄어들다 보니 내가 바라는 모습을 잘 지키지 못하고 살아가고 있다는 느낌을 많이 받았습니다. 운동이나 책 읽기, 글쓰기처럼 노력을 들여야 하는 활동의 우선순위가 밀리니까 스스로가 게을러지지 않았나 싶은 생각이 들었습니다.

사실 기존에도 루틴 관리를 유지해 보려는 시도가 있었지만, 언젠가부터 매너리즘을 느꼈는지 루틴을 꾸준히 지키고 최신화하려는 노력을 잘 이어가지 못했습니다. 회고를 정리하다 보니 그 공백이 한꺼번에 크게 느껴지더라고요.

그래서 올해 세운 목표 중 하나가, 바로 노력을 들여야 하는 습관을 붙들 수 있는 보상 체계를 제대로 고민해 보는 일이었습니다. 작게라도 매일 이어지는 루틴과, 그걸 유지하게 만드는 동기 부여가 어떻게 맞물려야 하는지 다시 정리해 보고 싶었습니다.

이번 포스트를 통해 삶의 계획을 세우긴 하지만 이를 잘 지키지 못하고 무너지는 분들께 도움이 되었으면 좋겠습니다.

책 소개

이 책은 루틴 관리 앱 마이루틴의 대표 옥민송 님이 쓴 책입니다. 목표나 계획을 세우더라도 이것을 꾸준히 지키는 것은 매우 힘든데, 이를 사소한 성취로부터 시작해서 점차적으로 쌓아 가는 방법을 소개하는 자기 계발서입니다.

책은 총 4장으로 나뉘어 있으며, 다음과 같은 내용을 다루고 있습니다.

1장: 루틴의 필요성 알기

2장: 아주 작은 루틴으로 시작하기

3장: 뼈대 루틴 세우고 가지 루틴 쌓기

4장: 루틴 세트 유지하기

분량은 약 270쪽 정도로, 여유롭게 시간을 내어 읽으면 하루 만에도 부담 없이 완독할 수 있는 정도의 분량이었습니다. 자기계발서인 만큼 별도의 사전 지식은 필요하지 않고, 저자의 경험과 사례를 중심으로 이야기가 전개되기 때문에 편안하게 읽을 수 있었습니다.

그럼 지금부터 각 장에서 인상 깊었던 내용을 정리해 보겠습니다.

루틴의 필요성 알기

이 책을 읽은 이유는 작년에 연말 회고를 하면서 내가 바라던 모습을 잘 지키지 못하고 있다는 생각이 들었기 때문이라고 말씀드렸습니다. 그래서 루틴 관리를 통해 내가 얻을 수 있는 것이 무엇인지에 대한 호기심이 있었는데, 이를 1장에서부터 짚고 넘어갑니다.

내가 삶의 고점에 있든 저점에 있든, 치열하게 살든 느긋하게 살든 나를 위한 작은 행동을 실천하고 마음에 드는 순간을 늘려가고 있다. 하루하루 작은 성취감을 쌓아가는 일상에 감사하고 덕분에 힘든 순간이 와도 스스로를 잘 받아들일 수 있다. … 내 삶을 잘 살아가기 위해서는 자기 신뢰가 필요하다. 나를 믿을 수 있을 때 일상은 보다 여유로워지고 위기는 덜 두려워지니까.

- 55p

저자는 루틴의 필요성 중 하나로 자기 신뢰의 구축을 이야기합니다. 누구나 삶을 살아가다 보면 힘든 시기가 오기 마련인데, 루틴은 그럴 때마다 자신을 믿고 지탱해 줄 수 있는 근거가 된다는 내용입니다. 지금까지 루틴은 목표를 향해 나아가는 수단으로만 생각했는데, 이 부분을 읽으면서 루틴이 일종의 심리적 안전망 역할도 할 수 있겠다는 생각이 들어 흥미로웠습니다.

작은 루틴은 오래 했을 때 큰 힘을 발휘한다. … 목표를 달성하는 방법은 하나가 아니니까 자신에게 맞는 방법을 찾을 때까지 짧게 짧게 시도해보는 게 좋다. 남들에게는 어렵지만 내게는 쉬운 게 있다. 남들에게는 재미없지만 내게는 즐거움을 주는 것도 있다.

- 63p

보통 새해 목표를 세우게 되면 욕심이 생겨서 자기 자신을 루틴에 맞추게 되는 경우가 많습니다. 하지만 저자는 내가 이미 습관적으로 하고 있는 행동을 루틴화하고 이를 기반으로 루틴을 확장해 나가는 방법을 제안합니다. 한 번 세운 루틴을 끝까지 지키려고 하기보다는, 나에게 맞는 방법을 찾기까지 꾸준한 수정과 시도가 필요하다고 강조합니다.

정리하고 나니 하루에 몇 시간씩, 한 달 만에 다 끝내버리고 싶은 욕심이 생겼지만 참았다. 결국 성공하지 못할 테니까. … 이 루틴은 100일만 하기로 마음먹었다. … 막연히 늘어지는 것보다는 마무리를 정해야 지속할 수 있을 것 같았다.

- 69p

저는 어떤 일을 할 때 한꺼번에 끝내려고 하는 경향이 강합니다. 그리고 어떤 목표를 세우면 꾸준히 해야 한다고 생각합니다. 그렇지만 시간이 갈수록 이를 잘 지키지 못하는 경우가 많아졌고 스스로를 게으르다고 생각하곤 해서 이 부분을 읽으면서 좀 찔렸네요.

나는 성장이 필요한 매 순간 시험 기간처럼 살았다. … 머릿속에 자리 잡은 강박이 몸도 마음도 불편하게 만들 뿐이었다. … 그래서 요즘은 성장에 대한 조급함이 생기면, 5분만 써서 무엇을 할지를 정한다. … 성장에는 시간이 걸린다.

- 72p

루틴이 강박이 되지 않도록, 그리고 조급한 마음이 들면 조그마한 무언가라도 해보는 것을 추천하는 부분입니다.

나는 무리하는 시기에는 모든 것을 챙기려고 하지 않는다. … 동시에 아무리 힘든 시기에도 어떤 선 아래로 떨어지지 않도록 노력한다. … 내가 좋은 시기에도, 힘든 시기에도 변함없이 나를 챙기고 있다는 증거가 되기 때문이다. 삶의 오르막에서도 내리막에서도 내가 스스로를 챙기고 있다는 사실 자체가 주는 안정감이 있다.

- 91p

루틴을 아주 엄격하게 지킬 필요는 없지만, 그렇다고 해서 루틴을 완전히 놓아버리지는 말라는 내용입니다. 저는 사실 루틴을 만들었지만 내려놓았던 적이 많았거든요. 제게 이 부분은 마치 상방과 하방이 있는 루틴 세트를 관리하는 느낌으로 읽혔습니다. 좋은 시기에는 루틴을 확장해 나가고, 힘든 시기에는 루틴의 바닥을 지키는 식으로요.

감정 일기를 쓰다 보면 스트레스 받을 때의 행동 패턴이 보인다.

- 93p

본인의 일상에 대한 메타 인지가 있어야 루틴도 잘 관리할 수 있다는 내용입니다. 메타 인지를 중요하게 생각하는 저에게도 와닿는 부분이었습니다.

가끔 넘어지면 많은 생각을 하지 않고 잘 주저앉아 있다가, 잘 일어나려 한다. … 매일 기본 루틴을 지키다 보면 지금 이 순간도 지나가는 시간임을 느낀다. 기본 루틴이 나의 바닥을 높여주었고 그 바닥에서 빠져나오는 것을 도와주었다.

- 96p

어느 정도 반복되는 말이지만 루틴이 일종의 심리적 안전망 역할을 한다는 점이 다시 한 번 강조되는 부분입니다.

원하는 게 있는데 아무리 생각해도 쉬운 방법이 떠오르지 않거나 빠른 시간 안에 해야 한다면 할 수밖에 없는 환경을 세팅한다.

- 102p

큰 목표만 세워 두고 매일의 실행이 비어 있으면, 결국 언젠가 해야지 로 남기 쉽다는 이야기가 1장 전체에 깔려 있는 메시지처럼 느껴졌습니다. 제가 올해 고민하고 있는 보상 체계도 결국 매일 조금이라도 움직이게 만드는 장치 에 가깝기 때문에 와닿았습니다.

아주 작은 루틴으로 시작하기

2장에서는 내 일상으로부터 루틴을 시작하는 방법에 대해 알아봅니다. 나를 루틴에 맞추는 것이 아닌, 루틴을 나에게 맞추는 것으로부터 시작합니다.

루틴 관리를 더는 미룰 수 없다고 결심하고 제일 먼저 한 것은 일상 돌아보기였다. … 나는 아침부터 저녁까지 하루 일과를 돌아보며 아침에 눈 떠서 밤에 잠들 때까지 어떤 행동을 하는지, 그 중 반복하는 활동이 있는지, 앞으로도 계속 하고 싶은 행동이 있는지를 살펴보았다.

- 112p

내가 무의식적으로 하는 행동 중에서 루틴으로 삼을 수 있는 행동이 무엇인지 살펴보는 과정을 소개합니다.

루틴을 기록할 때는 루틴만 나열하지 말고 언제 할지 함께 기록하자. … 성공 가능성을 극대화하고 싶다면 하나 더 신경 쓸 게 있다. 바로 ‘언제 할지’를 정하는 것이다. … 이 시작 행동이 단단한지 체크해야 한다. 다시 말해 기준이 되는 상황이나 행동이 매일 있어야 그 상황과 행동에서 이어갈 새로운 루틴도 잘 챙길 수 있다.

- 125p

개인적으로 아주 중요하다고 생각하는 부분입니다. 루틴을 꾸준히 유지하기 위해서는 그 행동이 일어나는 계기, 트리거(trigger) 가 단단하고 명확해야 한다는 점을 강조합니다. 트리거는 행동의 촉매 역할을 하기 때문입니다.

작은 루틴 하나 한다고 뭐가 달라질까? … 더 중요한 사실은 좋은 행동이 좋은 행동을 부른다는 것이다.

- 135p

이렇게 해서 작고 사소한 내 일상을 루틴화했을 때, 당장 내 일상이 바뀌는 일은 없지만 긍정적인 생각과 행동이 이어지는 선순환이 시작된다는 내용입니다.

첫째, 시작 루틴은 무조건 쉽고 간단하게 만든다. … 둘째, 내가 이미 하고 있는 활동에서 시작하자. … 셋째, 기존 행동 중 반복하고 싶은 게 없다면 매일 반복되는 일에 루틴을 추가해보자. … 넷째, 일단 시작하자.

- 137p

제목처럼 하루 5분 같은 단위로 시작하자는 메시지가 여기서 구체화됩니다.

뼈대 루틴 세우고 가지 루틴 쌓기

3장에서는 루틴을 확장하는 방법에 대해 알아봅니다. 작은 루틴에서 시작해서, 그 루틴을 뼈대로 삼아 가지 루틴을 쌓아 나가는 방법입니다.

사람들에게 무엇을 하고 싶냐고 물었을 때 가볍게 떠오르는 루틴은 지향하는 지점이긴 하지만 진지하게 열망하지는 않을 가능성이 크다. 그래서 자주 언급하면서도 잘 지키지 못하는 것이다.

- 174p

솔직히 말해서 찔린 부분입니다. 연말마다 회고를 하며 연간 목표를 세우지만, 그 목표를 정말 진지하게 열망하면서 세웠다고 생각하지는 않거든요. 목표를 이룰 만한 동기와 간절함의 부족은 루틴의 실패에도 영향을 준다는 내용입니다.

잘 지키고 있는 뼈대 루틴 다음, 이미 반복되는 일상 행동 다음, 시간이 확보되는 시점, 없애고 싶은 안 좋은 습관이 시작되려는 순간이 루틴을 하기 좋은 때다.

- 182p

루틴의 또 다른 구성 요소인 동기입니다. 나의 일상에서 불만족스러운 부분을 발견했을 때, 이를 동기 부여로 삼아 루틴을 시작하는 계기로 만들라는 이야기죠.

시작 루틴의 핵심은 책을 펴기만 해도, 운동복을 입기만 해도 달성으로 보는 것이다. 정말 하기 싫은 날이라면 책을 펴기만 해도, 운동복을 입기만 해도 괜찮다. 그것만으로도 책을 읽기 위해, 운동을 하기 위해 노력한 것이며 오늘은 못 했지만 앞으로 계속할 거라는 시그널을 스스로에게 준 것이다.

- 187p

이 부분은 새롭게 느껴졌는데, 어떤 루틴을 정말 하기 싫은 날에는 루틴의 시작 행동만 해도 달성으로 인정한다는 내용입니다! 루틴의 달성 자체는 관대하게 인정하되, 그 루틴을 유지하려는 노력은 계속하라는 메시지로 이해했습니다.

3장은 하나의 굵은 루틴을 축으로 두고, 거기에 얹을 작은 루틴들을 정리하는 파트였습니다. 모든 걸 동시에 늘리지 말고 뼈대를 먼저 세우라는 말이, 제가 너무 많은 루틴을 여러 개 동시에 잡았다가 무너져 본 경험과도 잘 맞아떨어졌습니다.

루틴 세트 유지하기

4장은 루틴 세트를 유지하는 방법에 대해 알아봅니다. 루틴을 끝까지 지속하는 방법에 대해 설명합니다.

사람의 행동은 세 가지 요소에 의해 일어난다. 계기, 동기, 그리고 능력. 다시 말해 어떤 행동을 해야 한다는 걸 기억해내고, 그 행동을 하고자 하는 동기가 있고, 그 행동을 할 수 있는 능력이 있다면 행동하게 되는 것이다.

- 207p

루틴의 구성 요소를 설명합니다. 이렇게 보니 뭔가 3대 영양소(?) 설명하는 것 같네요.

무엇을, 언제까지, 왜 해낼지를 명확히 하는 것. 이 세 가지가 모두 중요하다. 해내야 하는 것이 무엇인지 모르면 애초에 해낼 수가 없고, 기간이 명확하지 않으면 한없이 미뤄지며, 이유가 명확하지 않으면 동기가 약해졌을 때 되살리지 못하고 포기해버린다.

- 245p

루틴을 왜 해야 하는지를 아는 것은 나의 능력과 동기를 동시에 끌어올리는 데 도움이 된다는 내용입니다.

루틴을 하는 행동을 쉽게 만드는 것이다. … 매일 퇴근 후에 책을 읽기로 했다. 그런데 퇴근하고 피곤한 몸으로 침대에 쓰러져 ‘아, 책 읽어야 하는데’라고 생각할 때와 피곤한 몸으로 침대에 쓰러졌는데 옆에 책이 펼쳐져 있을 때 중 언제 더 책을 읽기 쉬울까?

- 226p

내가 지키고 싶은 루틴은 어떤 환경이 갖춰져 있을 때 더 쉽게 지킬 수 있을까에 대한 고민을 해보게 되었습니다.

목표, 기간, 이유, 루틴이 명확해졌다면 그 다음 할 일은 회고 일정을 잡는 것이다. … 막연한 계획이 아니라 날짜와 시간까지 명확하게 정해야 한다. 마치 약속을 잡듯 시간, 장소까지 정해 기록해두는 것이 좋다.

- 248p

이 부분도 인상 깊게 느낀 부분인데, 루틴 진행에 대한 스스로의 회고 일정을 마치 약속처럼 잡으라는 내용입니다. 저도 최근에는 월간 회고를 진행하고 있는데, 스스로의 다짐이지만 이것을 캘린더에 기록하면서 마치 약속과 동일하게 취급한다는 개념이 신선하게 와닿았습니다.

루틴 자체로 동기 부여가 잘 안 된다면 더 잘할 수 있도록 보상 혹은 벌칙을 정하는 것도 방법이다. … - 255p

저의 목표 달성을 방해하는 유혹들에게 지지 않도록 보상과 벌칙에 대한 부분도 고민하며 읽었습니다. 게임과 SNS 같은 도파민성 유혹도 있고, 귀찮음과 게으름 같은 인간 내면의 본질적인 유혹도 잘 관리하고 싶었거든요.

기간이나 횟수 정하기

공개적으로 실천하기

보상 혹은 벌칙 마련하기

같이 하기

준비 루틴 정하기

목표를 명확히 하기

최종적으로 루틴을 유지하기 위한 방법들을 정리한 부분입니다. 내용 자체는 어느 정도 다 아는 내용이지만 이런 루틴의 실행을 돕는 환경들이 제 주변에서 꽤 멀어졌구나 새삼 느끼게 되었습니다.

마치며

메모와 아이패드를 통해 루틴 계획을 진지하게 짜는 중

인용구가 굉장히 많다는 점에서 느끼셨겠지만, 루틴에 대한 저자의 관점과 생각에서 많은 부분이 와닿았습니다. 루틴을 꾸준히 지키는 것이 왜 중요한지, 루틴을 어떻게 시작할 수 있는지, 그리고 루틴을 어떻게 유지할 수 있는지에 대한 저자의 생각이 제 고민과 잘 맞아떨어졌기 때문이겠죠.

저는 개발자다 보니까 제가 가진 사전 지식을 바탕으로 이 내용을 이해하게 되더라고요. 내가 하루에 허용할 수 있는 루틴의 쿼터는 얼마인지, 루틴을 유발하는 트리거는 무엇인지, 이루고 싶은 루틴을 백로그에 넣어 관리한다든지, 일상을 다이어그램 또는 유한 상태 머신으로 나타낸다든지 하는 식으로요.

이런 식으로 루틴을 관리하는 앱을 내가 만든다면 어떻게 UI를 구성했을까? 를 상상하면서 읽으니 꽤 재밌었습니다. 시각화 방법에 고민하고 있는 부분이 있어서 아직 완성하지는 못했지만, 나중에 결과물을 한 번 공유해볼게요.

내용의 깊이감은 사실 특별할 것 없이 무난했지만, 저에게 생각할 거리를 많이 던져준 책이라서 개인적으로는 재미있게 읽었습니다.

Safari에서 그라데이션 배경에 트랜지션이 적용되지 않았던 이유

Wed, 14 Jan 2026 00:00:00 GMT

프론트엔드 개발자라면 한 번쯤은 이런 상황을 겪어보셨을 겁니다. “Chrome에서는 분명히 잘 되는데, Safari에서만 안 되네요?” 네, 오늘도 어김없이 Safari입니다.

요즘 회사 프로젝트 QA 기간 막바지라 크로스 브라우징 테스트를 열심히 하고 있는데요, 역시나 Safari 이슈가 저를 반겨주더라구요. 아직 해결하지 못한 몇몇 이슈들이 남아있어서 요즘 글쓸 소재가 넘쳐나는 호사(?)를 누리고 있습니다.

그라데이션과 트랜지션을 조합하면 세련된 느낌을 얻을 수 있다

이번에 마주한 이슈는 Safari 18 이하 버전에서 CSS currentColor 값을 이용해 구현된 그라데이션 트랜지션을 적용했음에도 불구하고 제대로 적용되지 않는 현상입니다. 원인을 파악하고 나니 브라우저 엔진 자체의 렌더링 최적화 과정에서 발생한 버그였고, 이를 해결하는 방법도 찾아서 공유해보려고 합니다.

이번 포스트를 통해 CSS 그라데이션에 트랜지션 효과를 적용하는 방법이 궁금하신 분들, 그리고 Safari에서 해당 트랜지션이 동작하지 않는 이슈를 겪고 계신 분들에게 도움이 되길 바랍니다.

TL;DR

CSS 그라데이션 배경은 background-image 속성에 linear-gradient() 등의 CSS 함수를 사용하여 구현함

background-image는 기본적으로 트랜지션이 적용되지 않는 불연속(discrete) 속성이지만, linear-gradient() 내부에 currentColor를 사용하면 color 속성의 트랜지션에 따라 그라데이션 색상도 자연스럽게 전환됨

그러나 특정 Safari 버전에서는 color 값이 변경되어도 background-image 내부의 currentColor가 업데이트되지 않는 버그가 있음

이는 Safari(WebKit)가 background-image 내 CSS 함수로 참조된 currentColor 변경을 감지하지 못해 리페인트가 트리거되지 않기 때문

이를 해결하기 위해서는 background-color: currentColor와 같은 리페인트를 유도하는 속성을 추가하는 방법을 고려할 수 있음

그라데이션 트랜지션 구현하기

그라데이션 트랜지션의 동작 예시, 1번은 호버 시 트랜지션, 2번은 버튼 클릭 시 트랜지션

우선 그라데이션 배경의 색상이 자연스럽게 변하는 정상적인 상황을 재현한 예시를 제작해보았습니다.

위 영상에는 그라데이션 배경이 적용된 <div>가 2개 보이는데요, 첫 번째는 호버 시 트랜지션, 두 번째는 버튼 클릭 시 트랜지션을 적용한 예시를 볼 수 있습니다. 그라데이션이 예쁘게 잘 전환되네요!

이러한 그라데이션을 구현하기 위해서는 어떻게 CSS를 작성해야 할까요? 만약 아래와 같은 코드를 작성하면 의도한 대로 트랜지션 효과가 적용될까요?

.box {
  /* 초기 그라데이션 배경 */
  background-image: linear-gradient(135deg, #ff6b6b 0%, #4ecdc4 100%);

  /* 트랜지션 효과 */
  transition: background-image 0.5s ease;
}

.box:hover {
  /* 호버 시 그라데이션 배경 */
  background-image: linear-gradient(135deg, #9b59b6 0%, #4ecdc4 100%);
}

의도한 대로 나오지 않는다

위 코드를 그대로 적용하면 트랜지션 효과가 전혀 적용되지 않고 색상이 뚝 끊기듯이 변하는 것을 볼 수 있습니다. 그 이유는 바로 background-image 속성은 트랜지션을 적용할 수 없는 불연속(discrete) 속성이기 때문입니다. 그래서 일반적으로 그라데이션 배경에 트랜지션을 적용하기 위해서는 약간의 트릭을 사용해야 합니다.

투명도 조절으로 구현하기

가장 일반적인 방법은 ::before 혹은 ::after 를 사용해 전환할 그라데이션 배경을 만들고, 가상 요소의 opacity 값을 조절하는 것입니다. 구글에 검색해보았을 때 레퍼런스도 가장 많고 간단한 방법입니다.

Transitioning Gradients

Animating Gradients: A Guide to Smooth Transitions in CSS

.box {
  position: relative;
  /* 초기 그라데이션 배경 */
  background-image: linear-gradient(135deg, #ff6b6b 0%, #4ecdc4 100%);
}

.box::after {
  /* box를 덮는 가상 요소 */
  position: absolute;
  content: '';
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  /* 호버 시 그라데이션 배경 */
  background-image: linear-gradient(135deg, #9b59b6 0%, #4ecdc4 100%);
  /* box를 덮는 가상 요소의 투명도를 조절하여 그라데이션 배경을 표시 */
  transition: opacity 0.5s ease;
  /* 초기 가상 요소의 opacity는 0 */
  opacity: 0;
}

.box:hover::after {
  /* 호버 시 가상 요소의 opacity를 1로 변경 */
  opacity: 1;
}

의도한 대로 나온다!

이 방법은 단순히 레이어의 투명도 조절을 통해 그라데이션 배경을 전환하는 방법이기 때문에 대부분의 브라우저에서 잘 동작합니다. 하지만 이와 같은 방법을 사용하기 어려운 경우에는 다른 방법으로도 트랜지션을 구현할 수 있는데, 바로 currentColor를 활용하는 방법입니다.

`currentColor`로 구현하기

currentColor는 CSS에서 현재 요소의 color 속성 값을 참조하는 키워드입니다. 이를 통해 다른 속성이 color 속성 값에 따라 자동으로 변경될 수 있게 하는데요, 즉, color: red로 설정하면 currentColor도 red가 되는 거죠.

이를 활용하면 background-image 속성 내부에서 linear-gradient가 currentColor를 참조하게 하는 경우, color 속성을 변경하는 방식으로 그라데이션의 트랜지션을 쉽게 구현할 수 있습니다.

.box {
  /* 초기 color 값 */
  color: #ff6b6b;

  /* color에 transition 적용 */
  transition: color 0.5s ease;

  /* currentColor를 사용한 gradient, currentColor는 현재 요소의 color 속성 값을 참조 */
  background-image: linear-gradient(135deg, currentColor 0%, #4ecdc4 100%);
}

.box:hover {
  /* 호버 시 color 값 변경 */
  color: #9b59b6;
}

위 방법도 잘 된다! 무엇보다 코드가 매우 간결함

이 키워드를 활용하면 color 속성 하나만 변경해도 연관된 모든 스타일이 함께 바뀌기 때문에 유지보수가 편리합니다. 또한, color 속성은 인라인 스타일을 통해 외부에서 쉽게 주입할 수도 있기 때문에, 그라데이션 구성 요소가 동적이어야 하는 경우의 트랜지션을 더욱 쉽게 구현할 수 있습니다.

Safari의 렌더링 최적화 문제

좌측은 Safari 18, 우측은 Safari 26. 똑같은 코드인데 왜 여기서만 안 될까?

Chrome에서 테스트했을 때는 그라데이션 트랜지션이 의도한 대로 완벽하게 동작했습니다. 그런데 Safari에서 확인해보니… 색상이 아예 변하지를 않더라구요. 몇 번의 삽질(?)과 테스트를 통해 정확하게 Safari 18 이하의 버전에서 해당 코드가 동작하지 않는 것으로 범위를 좁혀낼 수 있었습니다.

Chrome과 Safari 26 버전에서는 마우스를 올리면 빨간색에서 파란색으로 0.5초에 걸쳐 자연스럽게 전환됩니다. 하지만 Safari 18 이하에서는 색상이 뚝 끊기듯이 변하거나 아예 색상 변경이 일어나지 않는 경우도 있었습니다.

정확한 원인을 파악하기 위해, Safari 브라우저의 개발자 도구를 통해 렌더링 타임라인을 살펴보았습니다.

정상 케이스

우선 정상적으로 동작하고 있던 Safari 26에서의 타임라인을 보면, 트랜지션이 발생할 때 브라우저의 페인팅 단계가 매 프레임마다 잘 발생하는 것을 볼 수 있었습니다.

문제 케이스 1: 색상 변경이 아예 발생하지 않는 상황

반면 문제가 되는 케이스에서는 iOS Safari와 PC Safari에서 서로 다른 증상을 보였습니다. iOS Safari에서는 색상 변경이 아예 발생하지 않는 상황을 마주할 수 있었습니다. 실제로 페인트 단계가 전혀 발생하지 않은 것을 확인할 수 있었습니다.

문제 케이스 2: 트랜지션 없이 그라데이션 변경이 뚝 끊겨 발생하는 상황

반면 PC Safari에서는 트랜지션 없이 그라데이션 변경이 뚝 끊겨 발생하는 상황이 있었습니다. ‘스타일 무효화됨’ 과 ‘스타일 재검토됨’ 이 반복될 뿐, 실제 페인트 단계는 트랜지션의 마지막 프레임에서만 발생한 것을 확인할 수 있었습니다.

이를 통해 문제의 원인을 확실히 파악할 수 있었습니다.

“구 버전 Safari 브라우저의 중요 렌더링 경로에서 리페인팅 단계가 누락되어 발생한 문제구나!”

왜 이런 현상이 발생하는 걸까요? Safari 렌더링 엔진의 내부 동작이라 정확하게 알 순 없었지만, 다음과 같이 추론해보았습니다.

일반적으로 color 속성이 변경되면 브라우저는 해당 요소와 연관된 스타일을 다시 계산하고 화면을 갱신(repaint)합니다. 그런데 Safari에서는 linear-gradient() 내부의 currentColor에 대해서는 이 과정이 정상적으로 동작하지 않았습니다.

색상 변경이 아예 발생하지 않는 상황에 대해서는, 아무래도 Safari에서 linear-gradient() 함수가 처음 렌더링될 때 currentColor를 실제 색상 값으로 해석한 뒤, 이를 정적 값으로 캐싱하기 때문으로 보입니다. 이후 color 속성이 변경되어 currentColor의 참조 값이 바뀌더라도, linear-gradient() 입장에서는 이미 캐싱된 값을 사용하기 때문에 변경을 감지하지 못하는 것이죠.

트랜지션 없이 그라데이션 변경이 뚝 끊겨 발생하는 상황에 대해서는, Safari 개발자 도구의 프레임 별 메시지를 통해 그 단서를 추측해볼 수 있었습니다. currentColor의 값이 바뀌는 순간 기존의 리페인팅을 취소하고 새로 들어온 값을 기준으로 그라데이션을 계산하려고 하는데, 이것이 매 프레임마다 발생해서 연쇄적으로 취소가 이어진 현상으로 보입니다.

해결 방법

자, 이제 해결책을 알아볼 차례입니다.

강제 리페인트 유도

가장 간단한 해결책은 리페인트를 강제로 유도하는 것입니다. 페인트가 일어나지 않아서 생긴 문제니까 페인트를 일으키는 속성을 추가하면 되겠죠.

결과물에 영향을 주지 않으면서 강제 리페인트를 유도하기 위해서는 background-color: currentColor를 함께 추가하는 것을 고려할 수 있습니다.

.box {
  color: #ff6b6b;
  transition: color 0.5s ease;
  /* background-color 속성에도 currentColor 속성을 추가하여 강제 리페인트를 유도 */
  background-color: currentColor;
  background-image: linear-gradient(135deg, currentColor 0%, #4ecdc4 100%);
}

강제 리페인트 유도

이게 왜 동작할까요? background-color 속성의 currentColor는 Safari에서도 정상적으로 리페인트를 트리거합니다. 그리고 background-image가 background-color 위에 렌더링되기 때문에, 추가한 background-color는 시각적으로 보이지 않습니다.

background-image 렌더 시 background-color를 같이 설정해두는 것이 좋다는 권장 사항도 있다

결과적으로 color가 변경되면 background-color의 변경으로 인해 리페인트가 발생하고, 이 과정에서 background-image의 그라데이션도 함께 다시 그려지는 거죠.

`@property`로 CSS 변수 애니메이션

저는 위의 방법으로 문제를 해결했는데, 글을 작성하면서 새로운 방법으로 문제를 해결하는 법도 알게 되어 이를 소개해보고자 합니다. 바로 CSS의 @property 규칙을 사용하는 것입니다.

/* gradient-color 변수 정의 */
@property --gradient-color {
  syntax: '<color>';
  initial-value: #ff6b6b;
  inherits: false;
}

.box {
  --gradient-color: #ff6b6b;
  /* --gradient-color 변수에 transition 적용 */
  transition: --gradient-color 0.5s ease;
  background-image: linear-gradient(
    135deg,
    var(--gradient-color) 0%,
    #4ecdc4 100%
  );
}

.box:hover {
  --gradient-color: #9b59b6;
}

@property로 CSS 변수 애니메이션

이 방법이 동작하는 이유는 @property로 정의된 변수는 브라우저가 명시적으로 추적하는 대상이 되기 때문입니다. currentColor 처럼 다른 속성으로부터 참조되는 값이 아니라, 직접 변경되는 값으로 취급됩니다. 이로 인해 Safari에서도 @property 변수의 변경을 정상적으로 감지하고 올바르게 리페인트를 트리거합니다.

마무리

어쩌다 보니 새해 첫 기술 포스트도 Safari와 함께…

오늘은 이렇게 해서 구 버전 Safari의 렌더링 최적화 과정에서 발생한 버그를 해결하는 과정에 대해 다루어보았습니다. 문제의 해결 방법은 간단했지만, 브라우저의 중요 렌더링 경로에 대한 이해가 없었더라면 아마 쉽게 해결하지 못했을 것 같아요. 새삼 기본기(?)를 잘 닦아두는 게 중요하다는 생각이 듭니다.

혹시 비슷한 문제를 겪고 계신 분들께 이 글이 도움이 되길 바랍니다.

다섯 마리의 토끼를 쫓았던 2025년 회고

Wed, 31 Dec 2025 00:00:00 GMT

어느덧 2025년도 끝을 향해 가고 있습니다. 매년 연말마다 써 온 연간 회고도 올해로 벌써 일곱 번째가 되었네요. 연말 회고를 쓰다 보면 휴대폰 앨범과 인스타그램 스토리를 뒤적거리게 되는데, 그러다 보면 추억에 젖어서 시간이 금방 가더라구요.

토끼 사냥

2024년 회고의 컨셉은 도전이었고, 2025년의 컨셉은 다섯 마리의 토끼입니다. 작년은 도전을 통해 다양한 영역에서 새로운 시각을 얻을 수 있었던 해였는데요, 올해는 그 시도를 바탕으로 일과 삶의 균형을 잘 챙기고자 했던 한 해였습니다.

다섯 마리의 토끼를 모두 놓치지 않겠다는 마음으로 1년을 시작했지만, 한꺼번에 모든 것을 다 챙기려다 보니 결과적으로는 약간의 아쉬움이 남는 한 해였던 것 같습니다. 한 영역에 집중을 하다 보면 다른 영역에서 소홀해지는 일들이 있었거든요.

나의 에너지 총량은 유한하고, 모든 영역에서 항상 최상의 컨디션을 유지할 수는 없다는 것을 다시 한번 깨닫는 한 해였습니다.

이번 회고에서는 작년에 세운 목표의 달성률을 점검하고, 올해 있었던 주요 사건들을 되짚어본 뒤, 새해 목표를 세워보는 순서로 정리해 보려 합니다.

2024년에 세웠던 목표

우선 작년 회고글에서 세웠던 목표들을 다시 한번 살펴보겠습니다.

일과 삶의 균형을 잘 맞추기

점수: ⭐⭐⭐

일과 삶의 오각형

작년에 세웠던 목표를 이상적으로 잘 챙기지 못했다는 아쉬움이 있어서 3점을 주었습니다. 일과 삶이라고 뭉뚱그려 이야기했지만 여기에는 일, 취미, 연애, 건강, 자기계발이라는 다섯 가지의 카테고리가 있었습니다. 연애는 너무 개인사라서 제외하고 말하자면…

일: 상반기에는 번아웃이 와서 힘든 시간을 보냈지만, 잘 극복해냈고 하반기부터는 업무에 완전히 몰입하면서 좋은 마무리로 이어졌습니다.
취미: 다른 영역에서의 몰입도가 취미 활동의 의욕에도 영향을 끼쳤습니다. 연초에는 의욕이 많이 떨어졌지만, 연말에 밴드 공연이라는 성취를 이루면서 좋은 마무리로 이어졌습니다.
건강: 상반기에는 꾸준한 운동 습관을 유지했지만, 시간이 갈수록 운동 강도와 빈도 면에서 게을러졌다는 점을 부인할 수 없을 것 같네요. 연말부터는 운동에 대한 의욕을 못 느껴서 행동으로 옮기지 못했던 시간이 길었습니다.
자기계발: 역시 상반기에는 글쓰기에 꾸준한 노력을 들였으나, 중간에 공백기가 꽤 있었고 목표로 했던 글 개수를 채우지 못해서 아쉽습니다.

한 영역에서 느낀 부정적 감정이 다른 영역에도 영향을 끼치게 되는 경험을 하면서 ‘삐뚤한 오각형’ 으로 지냈던 시간이 많았던 것 같습니다. 모든 영역에서 항상 완벽함을 유지할 수는 없다는 생각도 들었고, 현실적인 균형에 더 신경 써야겠다는 결론을 내리게 되었습니다.

회사에서 1인분 이상의 몫 해내기

점수: ⭐⭐⭐⭐

사두용미

회사 업무에서는 4점을 주었습니다. 초반에는 업무에 대한 의욕이 많이 떨어졌지만 이를 잘 극복해내고 하반기에는 몰입해서 좋은 결과물들을 낼 수 있었기 때문입니다.

연초에는 번아웃이 찾아왔습니다. 그 이유는 갑작스러운 스펙 변경으로 인해 기존에 (꽤 열심히) 구현해둔 부분들이 많이 폐기되기도 했고, 공감할 수 없는 의사 결정들이 이어지면서 점점 무기력해지는 느낌이 들었기 때문입니다. 게다가 1월 증후군도 겹치면서 스트레스가 상당하던 시기가 있었습니다.

출근하는 게 싫다고 느껴질 정도로 힘든 시기였지만, 다행히 팀원들과 솔직하게 감정을 나누고, 시간의 흐름과 업무에 대한 책임감을 바탕으로 서서히 회복할 수 있었습니다. 이후에도 프로젝트 출시일이 여러 차례 연기되거나 기획이 자주 바뀌는 등 개발 외적인 변경 상황이 계속 이어졌는데, 한 번 면역이 생긴 덕분(?)인지 크게 멘탈이 흔들리지 않고 잘 대처할 수 있었습니다.

좋게 이야기하자면 외부의 변경과 자극에 덜 민감해졌다고 이야기할 수도 있지만, 나쁘게 말하자면 이해하기 어려운 의사결정에 대해서 적극적으로 반박하지 않고 수용하게 되는 태도가 생겼다고도 볼 수 있는 것 같습니다.

물론, 개발의 결과물에 대해서는 여전히 주인의식과 책임감을 가지고 있습니다! 주어진 스펙을 최대한 좋은 결과물의 코드로 구현하기 위해 매일 결과물을 다듬고 개선하는 데에 집중하고 있거든요.

다만 대기업이다 보니 상위 레벨에서 결정된 사항에 대해서는 개발자 개인의 레벨에서 타협하기 힘든 부분이 있다 라는 점을 받아들이게 된 것 같습니다. 이게 말로 이해하는 건 쉽지만, 실제 상황에서 받아들이는 것은 쉽지 않은 일이더라구요. 😅

한편으로, 올해 회사에서 개발한 업무의 큰 줄기를 정리해 보니 다음과 같았습니다.

회원 가입과 댓글/대댓글, 미디어 자동 재생, 소셜 로그인 등의 스펙 구현
1차·2차 QA 대응
인터렉션이 포함된 페이지 구현 및 인터렉션 패턴의 일반화·추상화 작업

스펙 구현에 있어서 결과물은 훌륭한 퀄리티로 완성했다고 자부할 수 있지만, 종종 작업 방향의 갈피를 정확히 못 잡고 헤맨 적이 있어서 조금 아쉬움이 남습니다. QA 기간 때에는 야근을 많이 해서 체력적으로는 힘들었지만 등록된 티켓을 하나씩 처리해나가는 것은 나름 의미있게 느껴졌구요. 작년에 이어서 복잡한 인터렉션 작업도 여전히 처리하게 됐는데, 이건 정말 할 때마다 어렵고 힘든 일이라는 걸 느낍니다.

4분기에는 TF를 통해 평소 글또와 커피챗을 통해 알고 있던 준일님과 같은 프로젝트에서 협업하게 되었는데 그 경험이 인상 깊었습니다. 낯선 코드베이스임에도 불구하고 능숙하게 적응해 나가는 모습, 적극적인 기술 공유 해주시는 모습, AI를 업무에 적극적으로 활용하고 계시는 모습이 멋있고 대단하게 느껴졌습니다.

그러다보니 올해는 개인적으로 제가 팀 내 기술 공유에 적극적으로 참여하지 못한 것이 아쉽게 느껴져서, 이를 내년의 목표로 삼아보려고 합니다.

데일리 크리에이티브 책 완독하기

점수: ⭐

3트도 실패, 이 책을 읽는 것은 왜 이리 힘든 것일까…

올해 3월까지는 책 읽고 느낀점 메모하기를 유지했지만 그 이후로는 흐지부지되고 말았고 결국 완독하지 못 했네요. 요즘 들어 노력을 들여야 하는 습관이 얼마나 지키기 힘든 것인지를 새삼 깨닫고 있습니다.

일기 쓰기

점수: ⭐⭐

상반기에는 월간 개인 감정 기록 정리도 시도했고, 하반기부터는 업무 일지를 쓰기 시작했습니다. 이를 잘 유지하고 싶어서 개인적으로 리마인더도 쓰고 있는데, 꾸준한 습관으로는 잘 이어지지 않고 있는 것 같아서 2점을 주었습니다.

데일리 크리에이티브 책 완독의 실패 이유도 노력을 들여야 하는 습관 의 어려움 때문인데, 이를 잘 극복하기 위해서 보상 체계를 한 번 잘 짜봐야 할 듯 합니다.

분야와 상관없이 새로운 도전 시도하기

점수: ⭐⭐

사실 작년에 많은 도전을 했었는데요, 그러다 보니 올해는 경험의 폭을 넓히는 것보다는 깊이를 쌓는데 더 신경을 썼던 한 해였습니다. 새로운 도전의 깊이도 크지는 않다 보니, 이것저것 다양한 체험 들을 했다는 느낌이 더 많이 드는 것 같아서 2점을 주었습니다.

개인적으로는 장거리 운전도 해보고, 새로운 밴드 팀에도 들어가고, 혼자 해외를 가보기도 하고, AI를 통해 좀 더 아웃풋을 내보려고 하는 등 여러 방면에서 소소하지만 의미 있는 시도를 했다고 생각합니다.

블로그 테마 오픈소스로 공개하기

점수: 🌧️

블로그 테마 관리에 대한 우선 순위가 지금은 많이 낮아진 상태라서 요 목표도 잠정적으로는 중단을 하고자 합니다.

2025년 타임라인

아래는 2025년에 있었던 주요 사건들을 타임라인 형식으로 정리한 것입니다.

유니코드 문자열 정규화

normalize 메서드를 이용해 유니코드 문자열 정규화하기

결합 문자가 포함된 글자를 어떻게 정렬할 수 있을까?

회사 업무 중 유니코드 문자열 정규화의 필요성을 느끼게 되어 작성한 글입니다. 시기 상으로 정확하게는 작년 12월 말에 작성한 글인데요, 작년 회고 글 이후에 작성한 글이라 요번 회고에서 제일 먼저 다루게 되었습니다.

문제를 해결하는 코드를 ChatGPT로부터 알게 되었는데, 정확한 동작 원리에 대해서는 알지 못해서 이를 정리해보고자 글을 작성했습니다. 그런데 해당 스펙이 제거되는 바람에 실제 업무에서는 사용하지 못하게 됐다는 후문이… 😅

글빼미 고도화

AI를 이용한 피드백을 받을 수 있다

1월 1일을 기점으로, 글또 활동 중에 개발한 봇 글빼미의 AI 피드백 기능을 오픈했습니다. 글빼미는 기존에 글또 참여자들이 제출한 글의 어뷰징을 방지하는 목적만 있었는데, 이번 업데이트를 통해 제출한 글에 자동으로 피드백을 남겨주는 기능을 추가했습니다.

이 기능을 1월 1일에 배포하기 위해 작년 12월부터 지훈님과 퇴근 후 짬짬이 논의를 하면서 AI를 활용한 블로그 자동 피드백 시스템 개발을 시작했습니다.

성윤님이 블로그에서 언급하길, 이것을 꿈의 실현이라고 말씀주신 점이 개발자 입장에서 매우 보람찼다

글또 운영자이신 성윤님이 많이 기대해주셨고, 좋아해주신 기능이어서 상당히 뿌듯했습니다. 추후에는 글또의 공식 블로그에도 『글또의 제출 글 검수 자동화 봇: 글빼미를 소개합니다!』라는 제목으로 시리즈 글을 게시하기도 했습니다.

이번 회고에 달린 피드백

여담으로 현재 회고에 대해 제가 받은 피드백은 위 사진과 같습니다.

글또 운영진 모임

1월 초에는 글또 운영진 모임에 참석했습니다. 글또 운영진 크루 별 활동 내역 공유와 남은 기간 동안의 방향성을 정리하고 네트워킹을 진행하는 자리였습니다.

남은 기간동안 무엇을 해보면 좋을까?

저는 이 자리에서 남은 기간동안 글빼미의 피드백 강도 설정 기능 추가 구현을 하겠다 고 약속했고…

요 작업 이후에 실제로 글빼미 피드백 강도 설정 기능을 구현했다

지훈님과의 협업을 통해 실제로 피드백 강도 설정 기능을 추가했습니다. 또한 해당 기능의 구현 과정을 글또 블로그에도 정리해서 올렸습니다.

럭키 드로우에서 1등했다. 성윤님~ 이거 잘 쓰고 있어요…!

여담인데 이날 럭키 드로우에서 1등 상품인 구글 픽셀 버즈에 당첨되었습니다. 마침 쓰던 무선 이어폰이 고장나는 바람에 요거로 교체해서 잘 쓰고 있습니다. 😅

독서

리액트 훅을 활용한 마이크로 상태 관리

회고를 하면서 알게 된 사실인데… 올해는 기술 서적을 한 권밖에 읽지 않았습니다. 작년에는 네 권 읽었는데, 의식적으로 독서하려는 노력을 안 했더니 결과적으로는 아쉬운 한 해가 된 것 같네요. 😢

『리액트 훅을 활용한 마이크로 상태 관리』 는 회사에서 스터디 목적으로 구매한 책이었는데, 실제로 추후에 전역 상태 관리 라이브러리를 도입하는 과정에서 책을 읽은 경험이 많은 도움이 되었습니다. 결론적으로 저희는 팀에서 Zustand 를 도입해서 잘 사용하고 있습니다.

평소에도 독서를 많이 하는 스타일은 아니긴 한데, 내년에는 독서 습관을 좀 더 의식적으로 챙겨봐야겠다는 생각이 듭니다. 그래도 분기 별로 한 권을 읽어보는 것을 목표로, 그리고 유튜브를 보는 시간 대신 책 읽는 시간을 늘려보는 것을 목표로 삼아보려고 합니다.

갤럭시 S25

갤럭시 S20은 자신의 후임자 사진을 촬영하는 것을 마지막으로 그 임무를 마쳤다

2월 초에 새 스마트폰을 구입했습니다. 원래 쓰던 스마트폰은 갤럭시 S20, 이번에 구입한 스마트폰은 갤럭시 S25입니다.

저는 원래부터 계속 갤럭시를 써온 사람이라 이번에도 갤럭시 시리즈로 넘어가게 되었습니다. 저는 스마트폰을 웬만하면 고장날 때까지 쓰는 편이라서(?) 거의 5년만에 바꿨습니다.

그래도 기왕 사는 김에 저렴하게 사고 싶어서 사전 행사 정보를 열심히 찾아보느라… 살짝 피곤했던 기억이 나네요.

프론트엔드 반상회

모임은 즐겁다

2월 초에는 글또 프론트엔드 반상회를 다녀왔습니다. 주최자나 발표자가 아닌 그냥 참석자로 다녀와서 편하고 즐겁게 네트워킹을 하고 왔습니다. 퀴즈 대회에서 1등 상품도 받아서, 같은 조였던 분들과 후속 커피챗 약속도 잡고 좋은 추억을 남겼습니다.

번아웃

어느 날, 무기력이 찾아왔다

시지프스가 된 기분

2월 초에 작성한 글로, 연초에 왔던 번아웃에 대해 분석하고 정리한 글입니다. 아무래도 제 블로그에서 평소에 다루지는 않았던 부정적 감정에 대한 포스트인만큼 인상깊게 봐주신 분들이 많았습니다.

사실 이 글을 작성할 때까지만 하더라도 완전히 번아웃이 해소된 것은 아니었지만, 나의 부정적 감정을 글로 정리하고 공유하는 과정을 통해 외부의 자극이나 변화에 있어 더 의연하게 대처할 수 있는 방법을 찾을 수 있었습니다. 그런만큼 저에게 있어서는 당시의 감정을 글로 정리하는 과정이 멘탈 회복에 있어서 많은 도움이 되었던 것 같습니다.

크롬에서의 뷰포트 단위

안드로이드 크롬에서 CSS vh 단위가 이상하게 동작했던 이유

크롬에서 뷰포트 단위가 이상하게 동작하는 이유

3월 초에 작성한 글로, 안드로이드 크롬에서 CSS vh 단위가 이상하게 동작하는 이유를 정리한 글입니다. 사실 예전에 링크드인에 간단히 해당 내용을 정리해서 올린 적이 있었는데, 이를 블로그에도 포스트로 정리해 보았습니다.

도쿄 워케이션

도쿄 베이스캠프에서 찍은 사진

3월 말, 회사에서 추첨으로 진행하는 워케이션에 당첨되어 도쿄를 다녀오게 되었습니다.

회사에서 숙소와 조식을 지원해주고 퇴근 후에는 자유롭게 시간을 보낼 수 있는 만큼, 경쟁이 엄청 치열한데 정말 운 좋게 당첨이 되었습니다! 사실 확률로 봤을 때는 미당첨이 당연한 만큼 결과 확인도 안 하고 있었는데, 당첨이 되었다는 사실을 나중에 알고는 정말 크게 놀랐죠.

일본을 두 번 가보긴 했지만 도쿄는 처음 가보는 곳이고, 혼자서 해외로 나가보는 것도 처음이라서 설레기도 하고 긴장도 되었습니다. 항공권은 직접 예매해야 했는데 그때가 하필 벚꽃 개화 시즌이라서 상당히 비쌌다는… 후문이 있긴 합니다.

업무에 몰입 및 집중할 수 있도록 지원을 정말 잘 해주어서 좋았다

워케이션은 정말 만족스러웠습니다. 우선은 조식이 정말 잘 나왔습니다. 제가 아침을 잘 챙겨먹는 스타일은 아닌데 정갈하게 차려진 조식이 마음에 들어서 매일 일찍 일어나서 먹었던 기억이 나네요.

또한 숙소 내에 업무 공간이 잘 갖추어져 있어서 업무에도 잘 몰입할 수 있었습니다. 각 방마다 허먼 밀러 의자와 모니터가 있고, 공용 공간에서도 넓은 라운지가 있어서 분위기를 환기할 수도 있었습니다.

다른 워케이션 참가자들과의 네트워킹도 지원해서 시간이 맞는 분들과는 같이 점심 또는 저녁을 먹기도 했고, 근처에 있는 명소를 같이 돌아보기도 했습니다. 일하러 돌아가는 길조차 여행이 될 수 있다 는 표현이 참 적절하게 느껴지더라구요.

다만 개인적으로 저는 디지털 노마드 의 삶과는 잘 안 맞는다는 걸 깨달았습니다. 그냥 쉴 때 쉬고, 일할 때 일하는 게 좋은 스타일인 것 같더라구요. 일 하는데 자꾸 놀고 싶은 마음(?)이 들더라구요. 😅

숙소 근처에 돈카츠 집이 있어서 갔는데 존맛

TMI지만 개인적으로 이번 일본 워케이션에서 가장 맛있었던 음식은 돈카츠였습니다. 사진 보니까 또 먹고 싶네요… 😋

아무튼 해외를 다녀온 만큼 워케이션 후기에 대해서 네이버 블로그에 글을 써볼 예정입니다.

글또 회고

나의 청춘을 함께한 커뮤니티, 글또를 졸업합니다

글또는 10기를 마지막으로 공식적인 활동이 종료되었다

5월에 작성한 글로, 글또가 10기를 끝으로 공식적인 활동을 종료하게 되었는데 이를 졸업에 비유하여 회고를 작성한 글입니다.

회고를 작성하는 과정에서 휴대폰 앨범 속 사진과 예전에 작성한 글을 계속 찾아보게 되었는데, 당시에 겪고 있던 여러 불안감과 고민, 추억들이 자꾸 떠올라서 감상에 잠기게 되더라구요.

아직도 200명 가까운 분들이 슬랙에서 활동을 이어나가고 계심

글또의 활동이 끝난 지 벌써 반 년이 넘게 지났지만, 아직도 많은 분들이 슬랙에서 활동을 이어나가고 있습니다. 비공식적으로 글쓰기를 계속 이어나갈 수 있는 모임도 유지되고 있고, 대나무숲에는 아직도 하루에 2~3건 씩 새로운 고민들이 올라오고 있습니다. 생일 축하 글도 계속 유지되고 있구요.

열정 넘치는 사람들이 자발적으로 활동을 이어나가고 있다는 점을 보면서 글또의 영향력이 여전히 우리에게 남아있다는 것을 느꼈습니다.

글드컵

AI와 함께하는 글쓰기 토너먼트 대회, 글드컵 진행 후기

6월 말, 글또 내에서 진행한 글쓰기 토너먼트 대회, 글드컵의 진행 후기를 정리한 글입니다.

글드컵은 글또 10기 활동 기간 동안 참여자들이 작성한 글 중 최고의 글을 가려내는 토너먼트 대결 이벤트로, 글쓰기 배틀이라는 독특한 아이디어에 AI가 심판으로 참여했다는 점 덕분에 많은 분들이 흥미를 느끼고 뜨거운 반응을 보내주셨습니다.

AI를 아주 적극적으로 활용한 행사였는데, 포스터 제작부터 홍보 문구 작성, 대진표 구성, 그리고 행사의 핵심인 평가 프롬프트 작성에 이르기까지, 거의 모든 과정에서 AI의 손길이 닿지 않은 곳이 없었죠.

AI와 함께 행사를 성공적으로 이끌며, 우리 일상과 업무에 AI를 어떻게 실용적으로 접목할 수 있는지에 대한 새로운 통찰을 얻을 수 있었습니다.

소셜 로그인 구현하기

클라이언트 환경에서 안전한 소셜 로그인을 구현하는 핵심 메커니즘, OIDC와 PKCE 알아보기

OIDC와 PKCE로 안전한 소셜 로그인 구현하기

7월 말에 작성한 글로, 당시 회사 프로젝트에서 페이스북 소셜 로그인을 구현하는 업무를 맡게 되었는데, OAuth 전반적인 개념에 대한 이해가 부족해서 공부한 내용을 정리한 글입니다.

OAuth 도메인 자체를 많이 다뤄보지 않았고, 그러다 보니 낯선 개념들이 많아서 글 작성보다도 학습을 하는 데에 시간이 꽤 걸렸던 기억이 나네요. 나름 기술 포스트인만큼 데모 영상도 촬영하면서 작성에 공을 많이 들였던 글이기도 합니다.

유럽 여행

7박 9일 미친 동선

9월 말에는 가족 및 친척과 함께 유럽 여행을 다녀왔습니다. 아무래도 어른들과 함께 가는 여행이다 보니 패키지 여행으로 다녀왔고, 7박 9일 동안 스페인과 포르투갈을 둘러보는 일정으로 다녀왔습니다.

저는 유럽도 처음, 패키지 여행도 처음이었는데 생각보다(?) 일정이 빡셌습니다. 1일 1도시를 둘러보는 버스 투어였는데, 버스로 이동하는 시간이 하루에 네다섯 시간 정도는 되는 것 같더라구요.

그리고 패키지 여행 특성 상 시간 약속을 칼같이 지켜야 했는데, 관광지에서도 남은 시간을 따져가며 촉박하게 둘러볼 수 밖에 없었던 것이 아쉬웠던 기억이 나네요.

강가 절벽을 바라보며 여유로움을 즐길 수 있었던 포르투

그럼에도 불구하고, 낭만 하나 만큼은 제대로 느낄 수 있었던 여행이었습니다. 기억에 남는 관광지로는 몬세라트, 성 가족 성당, 구엘 공원, 알함브라 궁전 등등 정말 많았지만 개인적으로 가장 좋았던 곳은 포르투였습니다. 여유와 편안한 분위기, 사람들의 친절한 태도 덕분에 가장 즐거운 기억이 남는 곳이었습니다.

해외 여행을 다녀오고 나서 네이버 블로그에 여행 포스트를 남기려고 하는데, 이번 년도의 여행기는 아직 작성하지 못했습니다. 그래서 내년 초에는 꼭 여행기를 작성해보려고 합니다.

강의

『실용주의 기술 블로그 글쓰기』 수강 후기

11월 초에 작성한 글로, 예전에 8월 쯤 인프런에서 수강했던 『실용주의 기술 블로그 글쓰기』 강의 수강 후기를 정리한 글입니다.

8~10월은 제 기술 블로그의 공백기입니다. 사실 7월 이후에 이런저런 일로 인해 글쓰기에 대한 열정이 식었었거든요. 그런데 이 강의를 다시 듣고 후기를 작성하면서 글쓰기에 대한 열정과 자신감을 되찾을 수 있었습니다.

결론적으로 올해에는 9개의 글을 작성해서 1년 동안 12개의 글을 쓰겠다 는 목표를 달성하지는 못 했습니다. 하지만 강의를 정리하면서 얻은 노하우를 바탕으로 글쓰기 템포를 다시 정상화한 만큼 내년에는 꾸준한 글쓰기를 진행할 수 있을 것 같습니다.

iOS 브라우저의 버그

iOS 브라우저에서 스크롤과 좌표 계산 API를 함께 썼더니 생긴 일

11월 말에 작성한 기술 포스트입니다. 당시에 회사 프로젝트의 2차 QA가 진행 중이어서 이것저것 다양하고 황당한(?) 버그들을 많이 만날 수 있었는데요. 그 중에서도 기억에 남는 버그였어서 글로 정리해보았습니다.

이미 겪었던 문제의 해결 과정을 서술하는 글이기도 하고, 버그의 데모도 재현하고 확인하는 과정을 거쳐서 작성했기 때문에 더 확실한 이해를 도모할 수 있었던 글이기도 합니다. 이러한 형식의 글은 글쓰기의 무게감이 너무 무겁지 않아서 글을 쓰는 입장에서도 부담스럽지 않고 작성하기가 편한 것 같습니다.

이것 외에도 하나 더 작성하고 싶은 버그 해결 과정이 있는데, 요거는 내년 초에 작성해보는 것을 목표로 하고 있습니다.

밴드 활동

사내 밴드 동아리 연말 파티에서 이소라 밴드 공연을 했다

12월에는 밴드 공연을 했습니다. 작년에 이어서 총 세 번째 공연이네요.

올해 초에 업무 번아웃이 겹치면서 사실 밴드 활동에 대한 의욕도 잃었었는데, 충분한 여유를 갖고 꾸준히 합주를 하면서 다시금 밴드 활동에 대한 재미를 느낄 수 있었습니다. 아무래도 공연이라는 목표를 잡으니 동기부여가 더 잘 되었던 것 같구요.

다만 연습과는 별개로 공연 당일에는 긴장도 많이 되고 실수도 해서 완성도 면에서는 아쉬움이 남긴 합니다. 그렇지만 제가 음악에 있어서는 완벽보다는 완성에 의미를 두는 만큼 이번 공연도 개인적으로는 즐거운 경험이 되었던 것 같습니다.

공연을 마치고 집에 돌아오는 길에 작년에 같은 팀으로 공연을 했던 분과 만나서 이런저런 이야기를 나누었는데요, 연주하는 기타와 곡들이 잘 어울리고 작년보다 많이 성장한 모습이 인상적이라고 칭찬해주셔서 기분도 좋고 뿌듯했습니다.

올해를 한 마디로 정리하자면

다섯 마리 토끼를 한 번에 다 잡으려다 보니 아쉬움이 남는 한 해

일과 삶의 균형을 잘 맞추고자 했던 한 해였지만, 다섯 마리 토끼를 한꺼번에 다 잡으려다 보니 완벽하게 챙기지 못한 점이 아쉬움으로 남는 한 해였습니다. 현실적으로 모든 영역에서 완벽함을 유지할 수는 없다는 것을 깨달았기도 하구요.

그런 만큼, 정말 각 분야에서 지키고 싶은 최소한의 기준선을 정해놓고 집중력을 유연하게 옮겨가면서 조절하는 시간을 보내봐야겠다는 생각이 듭니다.

또한 한 분야에서 느낀 감정이 다른 분야에도 영향을 끼치는 경우가 있다고 느꼈는데요, 나쁜 영향은 전염되지 않도록 격리할 수 있는 방법을 고민해보려고 합니다.

새해 목표 다짐을 한 마디로 정리하자면

유연한 오각형으로, 천천히 꾸준하게

올해 아쉬움의 포인트는 모든 영역에서 완벽함을 유지하려다 보니 느낀 점이라는 것을 깨달았습니다. 그래서 내년에는 너무 거창한 목표를 세우기보다는 소소하지만 현실적으로 달성할 수 있는 목표들을 세워보려고 합니다.

또한, 보다 현실적인 목표 달성을 위해 구체적인 숫자를 포함해서 목표를 세워보려고 합니다. 이를 통해 목표 달성률을 측정할 수 있어 더 현실적인 연간 계획을 세울 수 있을 것 같더라구요.

내년에는 달성하고 싶은 목표와 습관 유지를 위해 필요한 최소한의 노력을 정의해두고, 나머지의 집중력과 몰입도는 유연하게 조절하면서 효율적으로 시간을 보내보려고 합니다.

일과 자기 계발

사이드 프로젝트 1개 완성하기
블로그에 포스트 12개 작성하기
책 4권 이상 읽기
팀에 기술 공유 세션 2회 진행하기
노력을 들여야 하는 습관의 보상 체계를 고민해보기
매달 말에 목표 달성률 점검하기

삶과 취미

밴드 공연 1회 이상 하기
올해 다녀온 해외 여행 포스트 작성하기
운동 습관 되살리기 (일단 주 1회부터…!)

iOS 브라우저에서 스크롤과 좌표 계산 API를 함께 썼더니 생긴 일

Sat, 29 Nov 2025 00:00:00 GMT

애플 타도! iOS 타도! Safari 타도!

프론트엔드 개발자라면 누구나 크로스 브라우징 이슈를 겪게 마련입니다. 그 중에서도 iOS 환경 대응은 악명이 높기로 유명하죠.

최근에 회사에서 QA 업무를 하다가 이러한 iOS 이슈를 여러 개 처리하게 됐는데, 그 중에서도 정말 황당하고 어이없는 케이스가 있어서 이렇게 글로 정리하게 되었습니다. (이 억울함을 나만 알 수는 없다!)

제가 담당한 이슈는 iOS Safari 브라우저에서 댓글 입력 중 멘션 기능을 사용할 때 발생했습니다. 사용자가 @를 입력하면 멘션 레이어가 표시되는데, iOS에서만 이 레이어가 화면을 뚫고 나가버리는 것이 문제였죠.

알고 보니 모바일 브라우저에서 스크롤 위치를 고정하기 위해 사용하던 API와 멘션 레이어 위치를 계산하기 위한 API가 연달아 사용되었더니 좌표 계산이 정상적으로 동작하지 않는 것이 문제더라구요.

그런데 그 원인과 해결책을 알고 나니 참… 마음이 참 그렇더라구요. 😂 혹시나 했는데 역시나 여서 WebKit 개발자한테 좀 섭섭하다는 감정도 들었네요.

아무튼 오늘은 해당 버그를 소개하고 그 해결책까지 알아보는 시간을 가져보려고 합니다. 이번 글을 통해 iOS와 Safari(정확히는 WebKit)에 고통받고 있는 프론트엔드 개발자 분들께 도움이 되길 바랍니다.

TL;DR

iOS Webkit 기반 브라우저에서 발생하는 문제로 Window.scrollTo API 와 Element.getBoundingClientRect 를 동시에 쓰는 경우에 발생함

Window.scrollTo API를 호출할 때 실제 스크롤 가능한 영역보다 더 크거나 작은 값으로 호출을 하면 이것이 절삭된 값으로 반영되는 것이 아닌, Element.getBoundingClientRect 를 통해 얻어오는 좌표에도 영향을 주는 현상이 있음

따라서 스크롤 직후 좌표를 얻어오는 로직을 작성해야 한다면:

setTimeout 을 이용해 브라우저에게 레이아웃 재계산을 위한 여유 시간을 주거나

실제 스크롤 가능한 영역까지 최대/최소값으로 절삭하는 로직을 직접 추가해주는 방식을 고려할 수 있음

문제의 발견

좌측은 페이스북, 우측은 인스타그램. 대충 이러한 멘션 기능(?)을 만들고 있었다.

제가 받은 티켓의 내용을 간단하게 설명하자면, 댓글 입력창에 @를 입력하면 멘션 기능이 활성화되는데 그 멘션 레이어가 iOS에서만 화면을 뚫고 나간다는 이슈였습니다.

멘션 레이어는 사용자가 입력한 @ 글자 바로 위/아래에 나타나야 했기 때문에, 해당 글자의 위치를 좌표로 알아내야 했고 이를 getBoundingClientRect API를 사용해 해결하고 있었습니다.

그런데 저는 예전에 분명히 화면을 뚫고 나가지 않도록 해당 요소의 좌표를 계산해서 최대 높이 제한을 해둔 적이 있었거든요. 그리고 해당 버그가 기존 iOS에서 이미 발생한 적이 있었어서, “아~ iOS에서는 스크롤 직후 좌표 계산 시 타이밍 이슈가 있구나~” 라고 생각하고 이미 setTimeout 을 적용해 해결한 적도 있었습니다.

코드를 좀 더 살펴보니 setTimeout 을 적용한 부분이 리팩토링을 하면서 사라진 것을 확인했고, 다시 해당 코드를 복원하는 방식으로 간단하게 해결하려고 했습니다.

그런데… 로직의 연관된 부분을 찾아보다가 뭔가 이상한 걸 발견했습니다. 모바일 브라우저에서는 가상 키보드가 떠오르기 때문에 인풋 위치를 키보드 위로 고정시키기 위해 매 타이핑마다 스크롤 API를 호출하고 있었는데요. 이 스크롤 값을 이리저리 조절해보니… 어떨 때는 정상적으로 동작하는 경우가 있는 것이었습니다.

호기심이 생겨 조금 더 살펴보았더니 문제는 바로 스크롤 값이 음수로 설정되고 있는 경우 에만 발생하는 것이었습니다. 이 음수 스크롤 값이 뭔가 이상한 일을 일으키고 있었던 거죠.

실제 데모

직접 만든 데모 페이지

이것이 실존하는 문제인지를 명확하게 보여드리기 위해 Next.js로 간단한 데모 페이지를 만들어봤습니다.

우선 제일 위에 있는 핑크색 상자는 getBoundingClientRect를 이용해 뷰포트 최상단으로부터의 top 값을 보여주도록 설정했습니다.

또한 아래에 있는 세 개의 회색 버튼은 클릭 시 scrollTo API와 getBoundingClientRect API를 연달아 호출합니다. 첫 번째는 0, 두 번째는 -1000, 세 번째는 -5000만큼 Y값을 조정하도록 했습니다. 그리고 반환된 DOMRect의 top 을 별도 상태에 저장하게 했죠.

불필요한 스타일 등을 제거하고 핵심 로직만 남긴 코드는 다음과 같습니다.

const [top, setTop] = useState(0);
const divRef = useRef<HTMLDivElement>(null);

const handleClick = (top: number) => {
  // top으로 스크롤 이동
  window.scrollTo({ top });

  // 그 직후 divRef의 top 값을 상태에 저장
  setTop(divRef.current?.getBoundingClientRect().top ?? 0);
};

return (
  <>
    <div ref={divRef}>getBoundingClientRect.top: {top}px</div>
    <div onClick={() => handleClick(0)}>window.scrollTop(0)</div>
    <div onClick={() => handleClick(-1000)}>window.scrollTop(-1000)</div>
    <div onClick={() => handleClick(-5000)}>window.scrollTop(-5000)</div>
  </>
);

좌측이 PC Chrome, 우측이 PC Safari

PC Chrome과 Safari에서는 두 번째, 세 번째 버튼을 눌러도 getBoundingClientRect로 얻어온 top 값이 그대로 유지됩니다. 왜냐하면 우리가 스크롤을 아무리 음수로 설정한다고 해도, 실제로 스크롤이 0보다 작아질 수는 없다는 것을 직관적으로 알고 있으니까요.

이는 사실 scroll 스펙에도 명시된 내용입니다. 실제 스크롤 가능한 영역보다 더 크거나 작은 값을 넣으면 절삭(clamp)되는 것이 DOM API에 정의된 브라우저의 기본 동작이거든요.

분명히 브라우저 자체에서 min/max 처리가 되어야 함. 그래야만 하는데…

그런데 똑같은 코드를 iOS에서 실행해보면…

스크롤을 음수로 설정하면 그 값이 실제 좌표에도 영향을 주는 것을 확인할 수 있었습니다. 즉, scrollTo({ top: -5000 }) 을 호출하게 되면 실제 스크롤은 0 까지만 이동하지만, 핑크색 상자의 top 좌표는 5098px 로 측정이 됩니다.

이 현상은 양수 방향으로도 적용되더라구요. 즉, y를 10000, 20000 같은 큰 값으로 설정하면 top 좌표가 음수 방향으로 -9902px, -19902px 로 측정이 됩니다.

해결 방법

자, 이제 문제는 확인했으니 해결책을 찾아야겠죠. 이러한 문제가 발생하는 것 자체는 브라우저의 버그이기 때문에 어쩔 수가 없는 것이고… 어쨌든 사용자에게 버그처럼 보이지 않도록 우리가 직접 해결해야 합니다. 제가 찾은 해결방법은 총 2개입니다.

`setTimeout` 으로 여유 시간 주기

scrollTo API 호출 직후에 해당 문제가 발생하기 때문에, 레이아웃을 재계산할 시간을 브라우저에게 충분히 부여하는 방법입니다. 저는 setTimeout을 적당히 주었더니 문제가 발생하지 않더라구요.

const handleClick = (top: number) => {
  window.scrollTo({ top });

  setTimeout(() => {
    setTop(divRef.current?.getBoundingClientRect().top ?? 0);
  }, 100); // 적당한 지연 시간
};

setTimeout 으로 적당한 시간 주기

다만 이 방법은 순간적이긴 하지만 화면에 깜빡임을 발생시킬 수 있다는 단점이 있습니다. 또한 setTimeout의 지연 시간을 얼마나 줘야 하는지도 명확하지 않아서 약간 불안정할 수 있어요.

스크롤 값에 min/max 직접 적용하기

조금 더 확실한 방법은 스크롤 불가능한 영역으로 API가 호출되지 않도록 직접 최대/최소값 절삭 로직을 추가하는 겁니다. 브라우저가 자동으로 해줘야 하는 걸 우리가 직접 하는 거죠.

스크롤 범위를 직접 제한

저는 음수 방향의 스크롤만 고려해서 일단 최소값이 0이 되도록 설정해두었는데요, 만약 양수 방향의 스크롤도 함께 고려한다면 아래와 같이 작성하시면 됩니다.

// 최소값: 페이지 최상단
Math.max(
  0,
  // 최대값: 페이지 최하단 - 뷰포트 높이
  Math.min(top, document.body.scrollHeight - window.innerHeight)
);

두 방법 중에서는 방법 2가 더 안정적입니다. setTimeout은 타이밍 이슈가 있을 수 있지만, 직접 값을 절삭하는 방식은 확실하게 문제를 방지할 수 있거든요.

최종 결론

혹시나 해서 이 문제가 iOS 내 다른 브라우저에서도 발생하는지 확인해봤습니다. 결과는… 예상대로 iOS Chrome에서도 동일한 문제가 발생하더라구요. 단순히 Safari만의 문제가 아니라는 뜻이죠. 이는 곧 두 브라우저에서 공통으로 사용되는 브라우저 엔진인 WebKit의 문제라고 볼 수 있습니다.

실제로 WebKit 버그 트래커에서 비슷한 오류 제보를 찾을 수 있었는데, 아직까지 대응이 되지 않은 걸 보니 당분간은 직접 해결해줘야 할 것 같습니다.

꿀밤펀치

프론트엔드 개발자 입장에서는 이런 브라우저 엔진 버그까지 직접 처리해야 한다는 게… 참 답답한 일입니다. 그래도 이걸 수정하는 PR을 올리고 팀원분들께 설명드렸더니 다들 경악하시면서 공감해주셔서 나름의 위로를 얻었습니다. 😂

하지만 어쩔 수 있나요, 이게 프론트엔드 개발자의 숙명이니까요. 혹시 비슷한 문제를 겪고 계신 분들께 이 글이 도움이 되길 바라며 글을 마칩니다.

『실용주의 기술 블로그 글쓰기』 수강 후기

Sun, 02 Nov 2025 00:00:00 GMT

7월에 마지막으로 글을 쓴 후, 자의 반 타의 반으로 한동안 글쓰기를 쉬게 되었습니다. 아무래도 글또가 끝나다 보니 강제로라도 글을 쓸 동기가 없어진 데다, 회사 일과 개인사 때문에 글쓰기에는 다소 소홀했던 것 같네요.

문득 올해 작성한 글의 개수를 세어보니 6개밖에 안 되더라구요. 이전에 비하면 많이 줄어든 숫자이기도 하고, 한 달에 하나의 글을 쓰는 것이 목표였는데 그것을 달성하지 못한 점도 아쉬웠습니다. 노력이 필요한 습관 은 유지하는 것이 참 어렵다는 것을 느꼈고, 지금이야말로 글쓰기에 대한 동기 부여가 다시금 필요한 시점임을 깨닫게 되었습니다.

강의를 구매하게 된 계기

사실 저는 올해 8월에 글또 운영자이신 성윤님이 만드신 강의 『블로그 페이지뷰 300만이 알려주는 실용주의 기술 블로그 글쓰기』를 수강했습니다. 성윤 님의 노하우가 가득 담겨 있을 것 같은 제목(?)이라 흥미로웠고, 당시에 인프런에서 할인 중이어서 단돈 1,000원에 구매할 수 있었죠. (내돈내산! 😎) 저는 회사 점심시간에 틈틈이 강의를 들으면서 공감이 가는 부분들과 배울 점들을 비교하면서 들었던 기억이 나네요.

지금처럼 글쓰기에 대한 동기 부여의 필요성을 느낀 상황에서 해당 강의에 대한 리뷰를 작성하는 것이 도움이 될 것 같아 이번 글을 작성하게 되었습니다. 단순히 강의 내용을 요약하기보다는 해당 강의를 들으면서 제가 느낀 점과 배운 점들을 중심으로 공유하고자 합니다.

인프런에서 수료증 같은 걸 발급해 주길래? 일단 받아놨다

이번 글을 통해 기술 블로그 글쓰기에 대한 강의에서는 어떤 내용을 다루고, 강의를 수강한 입장에서 후기가 궁금하신 분들께 도움이 되었으면 좋겠습니다.

강의 개요

강의 프로필

강의 『블로그 페이지뷰 300만이 알려주는 실용주의 기술 블로그 글쓰기』는 데이터 사이언티스트 변성윤 님이 제작한 기술 블로그 운영 노하우를 담은 강의입니다. 성윤님은 데이터 분석을 주로 다루는 기술 블로그 어쩐지 오늘은 을 8년째 운영 중이십니다.

강의는 기술 블로그를 시작하는 분부터 이미 운영 중인 분들까지 모두에게 도움이 되는 실용적인 내용으로 구성되어 있습니다. 단순하게 글쓰기의 기법을 다루는 것에 그치지 않고, 동기 부여와 기술 블로그의 운영 노하우와 글쓰기 파이프라인 구조화 등 기술 블로그를 꾸준히 운영하는 데에 필요한 다양한 주제를 포괄적으로 다루고 있습니다.

현재 기준으로 약 3,000명 이상의 누적 수강생과 4.8점이라는 높은 강의 평점을 기록하는 등 많은 분들께 사랑받고 있는 강의이기도 합니다.

저 역시 2018년부터 기술 블로그를 운영하면서 나름의 노하우를 쌓아왔는데요, 이 강의를 통해 제 경험을 객관적으로 돌아보고 다른 사람의 시각에서 바라본 새로운 인사이트를 얻을 수 있었습니다.

강의 커리큘럼

강의는 10개의 섹션으로 구성되어 있는데, 이 중에서도 인상 깊었던 주제를 간략히 소개하고 제가 느낀 점을 덧붙이도록 하겠습니다.

기술 블로그 글쓰기의 어려움

기술 블로그를 운영하고자 하는 개발자는 많지만, 이를 꾸준히 실천하는 것은 매우 어려운 일입니다. 그 이유에 대해, 강의자는 ‘저항’ 이라는 개념을 통해 이를 설명합니다.

기술 블로그를 꾸준히 운영하는 것이 어려운 이유는 저항이 발생하기 때문

저항은 더 높은 차원으로 발전하려고 할 때 발생하는 마음가짐으로, 두려움이 클수록 저항도 커짐

따라서 두려움을 인정하고 이를 극복하려는 결심과 행동이 필요

강의자는 이런 저항을 만드는 유형을 다음과 같이 분류했습니다.

꾸준히 쓰는 것이 어렵다

글의 만족스럽지 않다

글의 소재가 떠오르지 않는다

글을 썼지만 사람들의 반응이 없다

글을 쓸 심리적 여유가 부족하다

자신감이 없다

그리고 이러한 저항을 극복하고 꾸준함을 유지하기 위한 핵심 요소로 다음과 같은 공식을 제시합니다.

꾸준함 $=$ 글을 쓰는 물리적 환경 $\times$ 동기 부여 (내적, 외적) $\times$ 실행 (루틴)

저는 이 섹션에 깊이 공감이 갔습니다. 지식 정리와 포트폴리오를 목적으로 기술 블로그를 처음 시작했을 때, 처음 몇 주는 높은 열정으로 글을 썼지만 시간이 지날수록 저항감이 커져서 꾸준함을 유지하기 어렵다는 느낌을 받았거든요. 퇴근 후에는 피곤해서 침대에 눕고 싶었고, 어떤 글을 써야 할지도 막막했습니다.

저는 이런 어려움을 글또 라는 글쓰기 모임을 통해 극복할 수 있었습니다. 글쓰기를 해야만 하는 환경 을 만들어, 매주 마감에 맞춰 글을 쓰고 다른 사람들과 공유하면서 자연스럽게 루틴이 형성되었죠. 하지만 글또 활동이 끝난 후, 제가 최근에 다시 느낀 글쓰기 저항감이 위 카테고리와 정확히 일치한다는 걸 깨달았습니다.

꾸준히 쓰는 것이 어렵다 $\rightarrow$ 글을 강제로 쓰게 만드는 환경이 사라졌다

글의 만족스럽지 않다 $\rightarrow$ 내가 만족할 만큼의 퀄리티를 위한 노력과 시간을 들이는 것이 체력적으로 조금 부담스럽다

글의 소재가 떠오르지 않는다 $\rightarrow$ 최근에는 개발적인 이슈나 새로운 기술에 대해 관심을 크게 기울이지 않았다

글을 썼지만 사람들의 반응이 없다 $\rightarrow$ AI 영향인지 기술 블로그 조회수가 전반적으로 줄어든 것 같다

글을 쓸 심리적 여유가 부족하다 $\rightarrow$ 회사 일과 개인사로 최근에 여유가 없었다

일단 이 강의를 수강하는 사람이 기술 블로그 운영과 글쓰기에 어려움을 느끼는 사람일 가능성이 높기 때문에, 이렇게 공감대 형성을 하고 시작하는 부분에서 작은 위로(?)를 받게 되어서 좋았습니다.

또한 제가 느끼고 있는 불확실한 감정을 명확하게 정의해 주니, 이를 극복하기 위한 방향성을 찾을 수 있겠다는 생각과 함께 다음 파트가 더 궁금해졌습니다.

글의 독자 설정 및 좋은 글에 대한 정의 설정하기

다음 섹션에서 강의자는 글쓰기의 목표와 대상 설정에 대해 설명합니다.

글의 독자: 기본적으로 나를 위한 글

미래의 나는 다른 사람

일단 기본적으로 자신이 잘 이해하는 걸 목표로 하기

완벽주의 지양하기

좋은 글: 자기가 생각하기에 좋은 글의 특징을 구체적으로 정의하기

이 부분에 대해서도 공감이 갔는데, 기본적으로 저도 글을 쓸 때 ‘미래의 나’ 를 독자로 상정하고 글을 씁니다. 지금 당장 이해하기 어려운 개념이라도, 시간이 지나서 다시 읽었을 때 이해할 수 있도록 정리하는 것이 목표이기 때문이죠. 그래서 나중에 문득 저의 예전 글을 찾아볼 때, ‘내가 이 때는 이런 지식도 알고 있었구나!’ 하는 생각도 종종 하거든요.

‘좋은 글에 대한 정의를 구체적으로 정한 적이 있는가?’ 에 대해서도 고민해 보았는데, 생각해 보니 글또 10기에서 큐레이션을 운영했던 경험이 떠올랐습니다. 수백 개의 글 속에서 하다 보니 어떤 기준으로 좋은 글을 선별해야 할지 고민한 적이 있었거든요. 명확한 대상 독자 설정과 내용의 깊이뿐만 아니라 글의 배치와 시각적 요소 등 독자 친화적인 다양한 요소를 고려했던 것들이 떠올랐습니다.

제가 생각하는 좋은 글에 대한 정의는 인터뷰로도 정리한 적이 있어서, 관심 있는 분들은 참고하시면 좋을 것 같습니다.

글쓰기 파이프라인

글쓰기 파이프라인은 기술 블로그에 소재를 찾는 것에서부터 글을 발행하기까지의 전체 흐름을 정리한 것입니다. 파이프라인을 구성하면 내가 글쓰기의 단계 중에서 어느 위치에 있는지, 그리고 어려움을 겪고 있다면 어느 부분에서 문제가 발생하는지 명확히 알 수 있습니다.

글쓰기에 집중할 수 있는 환경을 조성하기

공개 선언하기, 불안한 환경 만들기, 같이 하기…

환경을 분석해서 해결 방법을 모색하고 움직일 수밖에 없는 환경을 만들기

소재를 찾을 때는 공부 파트와 글쓰기 파트를 분리

AI 잘 활용하기

내적 동기와 외적 동기를 잘 활용하기

글쓰기에 대한 기술적 파이프라인 구축 자체는 『기술 글쓰기를 통해 개인 브랜딩을 구축하는 나만의 방법』이라는 글에서 다룬 적이 있어서 아주 크게 새로운 내용은 아니었지만, 글쓰기 환경 조성 에 대한 부분이 최근에 느꼈던 결핍 중에서 비중이 컸던 것 같아 다시 한번 생각해 보게 되었습니다.

사실 이번 글도 이번 주말 내에 완성하고 싶어서, 인스타 스토리에 공개 선언하기 방법을 썼다

루틴을 만들겠다는 목표를 세우면 어렵고, 무언가를 하고 싶어서 루틴이 필요하다고 생각하기

완벽보다는 완성을 목표로 삼기

이 파트에서 가장 인상 깊었던 부분은 목표 설정 방식이었습니다. 저는 그동안 ‘한 달에 하나의 글을 쓰자’ 라는 루틴을 만들었는데, 최근에는 이게 그저 억지로 만든 규칙처럼 느껴졌거든요.

강의를 듣고 목표를 ‘1년에 12개의 글을 쓰고 싶다’ 로 바꿨는데요. 수치상으로는 똑같지만, 느낌이 완전히 달랐습니다. 특히 그동안 글을 못 쓴 시간을 생각하면 남은 기간 동안 더 열심히 해야겠다는 동기부여가 확실히 되더라구요.

글쓰기 세부 과정 소개

이 부분은 글을 쓰는 과정 중 활용할 수 있는 기술적인 방법을 다룹니다. 강의자는 글쓰기 과정 중에서 다음과 같은 방법들을 활용해 글을 작성한다고 설명합니다.

예상 독자 설정

목차 구조 잡기

빠른 초안 작성 후 내용 보강

셀프 피드백 (소리 내며 읽기, 일단 배포하고 읽기, 자고 읽기 등등)

이미지 도식화하기

이 부분 역시 전의 파트에서 언급한 글에서 다룬 적이 있어서 크게 새로운 내용은 아니었지만, 셀프 피드백 에 대한 구체적인 방법론이 제가 실천하고 있던 방법이라서 반가웠습니다.

Napkin AI를 활용해 위 개념을 도식화 해보았다

또한 Napkin AI를 활용한 이미지 도식화 방법은 해당 강의를 통해 처음 알게 됐는데, 텍스트로 된 개념을 시각적으로 쉽게 표현하는 데에 큰 도움이 될 것 같아 앞으로 종종 활용해보고 싶다는 생각이 들었습니다.

SEO와 글 발행 전략 및 사례 공유

다음 섹션에서 강의자는 SEO 전략과 글 발행 전략에 대해서 설명합니다.

SEO 전략: 검색 엔진에서 내 글이 잘 노출되었으면 좋겠다

글 발행 전략: 사람들이 내 글을 많이 읽었으면 좋겠다

이 파트에서 SEO 전략은 다음과 같은 네 가지 유형으로 나눌 수 있다고 설명합니다.

온 페이지 SEO: 웹 페이지 내 HTML, 키워드 요소 등 최적화

테크니컬 SEO: 웹 사이트 내 기술적 측면 최적화

오프 페이지 SEO: 웹 사이트 외부 접근 관점에서의 최적화

에디토리얼 SEO: 콘텐츠 품질 중심의 최적화

프로그래머틱 SEO: 자동화된 도구와 기술을 활용한 최적화

이 부분에 대한 지식도 예전에 『기술 블로그를 위한 SEO』라는 글로 정리해 둔 내용이 있고, 그 내용과 크게 다른 부분이 있지는 않아서 복습한다는 느낌으로 들었습니다.

FAQ

강의의 마지막 부분에서는 일반적으로 자주 묻는 질문(FAQ)에 대한 답변을 다룹니다. 여기서는 다음과 같은 주제들이 포함되어 있습니다. 정답이 없는 질문에 대해 강의자의 식견과 노하우가 담긴 답변을 들을 수 있던 파트여서 좋았습니다.

적절한 글의 분량은 얼마인가요

블로그 플랫폼을 옮기고 싶어요

블로그를 종류 별로 나누거나 합치고 싶어요

회사에서 배운 지식을 글로 써도 될까요

글의 문체는 어떻게 해야 하나요

본문에 이미지를 첨부하는 방법은 어떤 것이 좋을까요

위 질문에 대한 저의 생각은 아래와 같습니다.

적절한 글의 분량은 얼마인가요 $\rightarrow$ 저는 TTR(Time To Read) 기준으로 10분 내외 분량을 선호합니다.

블로그 플랫폼을 옮기고 싶어요 $\rightarrow$ 저도 SEO 관점에서 블로그를 너무 자주 옮기는 것은 좋지 않다고 생각합니다.

블로그를 종류 별로 나누거나 합치고 싶어요 $\rightarrow$ 저도 기술 블로그는 GitHub Pages에, 여행 후기는 네이버 블로그를 활용하는 등 주제 별 블로그를 운영하고 있습니다.

회사에서 배운 지식을 글로 써도 될까요 $\rightarrow$ 회사의 정책에 따라 다르겠지만, 일반적으로 허락을 구하고 작성하려 합니다.

글의 문체는 어떻게 해야 하나요 $\rightarrow$ 저는 딱딱한 문체보다는 친근한 구어체를 선호해서 이렇게 작성하고 있습니다.

본문에 이미지를 첨부하는 방법은 어떤 것이 좋을까요 $\rightarrow$ 저는 GitHub 리포지토리에 이미지 파일과 문서를 함께 형상 관리 하고 있습니다.

개인적으로는 이 부분에서의 질문 수가 더 다양했으면 좋았겠다는 생각이 들긴 했습니다. 궁금하긴 하지만 어디 가서 물어보기엔 애매한 질문들, 사실 기술 블로그도 콘텐츠 창작자인 만큼 ‘애드센스를 이용한 콘텐츠 수익화에 대한 질문도 간단히 언급했다면 어떨까?’ 하는 생각도 들었구요. 또한 작년에 나온 강의지만 기술 블로그에 AI를 잘 활용하는 방법이 있었다면 어떨까 하는 생각도 들었네요.

글쓰기 레벨

글쓰기 레벨이라는 개념을 통해 정리해 주심

이 파트는 강의가 발매되고 난 후 추후에 추가된 내용인데요, 글쓰기에 대한 레벨을 정의해서 스스로가 어떤 단계에서의 글쓰기 방식에 있는지, 더 영향력 있는 글쓰기를 위해서는 어떤 관점에서 노력을 해야 하는지에 대해 설명하는 내용입니다.

그 내용을 간단하게 요약하자면 다음과 같은데요.

Lv1: 책, 강의 등 이미 정리된 지식을 스스로 기록하면서 정리하는 단계

Lv2: 기술 기반의 문제 해결법을 정리하는 단계

Lv3: 경험 기반의 문제 해결법을 정리하는 단계

Lv4: 생각의 구조화와 통찰을 제시하는 단계

재미있는 점은 레벨이 높아질수록 기술적인 내용의 비중은 오히려 낮아진다는 점입니다. 물론 기술 블로그인 만큼 기술적 깊이도 중요하지만, 더 높은 단계로 갈수록 본인만의 관점과 통찰이 더욱 중요해진다고 합니다.

제가 이해하기에 레벨이 높은 글을 작성한다는 것은 다음과 같은 과정으로 나아가는 길이라고 생각했습니다.

처음에는 어떤 도구를 잘 쓰는 법에 집중

점차 그 도구를 활용해서 문제를 해결하는 법에 집중

그 도구를 사용하는 스스로의 모습으로부터 특징을 찾아내고, 최적화, 패턴화, 그룹화, 추상화 등을 통해 통찰을 얻음

결론적으로는 그 도구로부터의 물리적 거리는 멀어지지만, 그 도구를 활용하는 사람과 집단에 더 큰 가치를 제공할 수 있게 되고 이것이 더 큰 영향력을 발휘하게 됨

이런 관점은 꼭 기술 글쓰기뿐만 아니라 사업, 교육, 투자 등 다른 분야에서도 적용할 수 있는 개념인 것 같아서 흥미롭게 읽었습니다.

실무자 입장에서 작성할 수 있는 세세한 고민도 좋지만, 거시적인 시야를 위해서는 다양한 레벨을 오가면서 글을 쓸 수 있어야 한다고 생각하는데요. 그렇다면 제가 최근에 블로그에 쓴 글 중에서는 이러한 레벨별 비율이 어느 정도 될까요?

후기글을 제외한 최근 10개의 글을 기준으로 대략적으로 나눠보면 다음과 같습니다.

3:2:3:2로 나름 적절한 비율을 유지 중

다행이게도(?) 나름 적절한 비율을 유지 중이네요. 앞으로 작성할 글의 방향도 한 분야에 너무 치우치지 않게 의도적인 노력을 해보려고 합니다.

갑자기 만난 익숙한 제목의 글

여담이지만 글에서 Lv2 좋은 글 예시로 제 글을 언급해주셔서 뭔가 뿌듯했습니다. 해당 글이 궁금한 분들은 아래 링크에서 읽어보실 수 있어요.

JavaScript 번들러로 본 조선시대 붕당의 이해

JavaScript와 ECMAScript는 무슨 차이점이 있을까?

강의 후기

식어버린 글쓰기 열정을 되살릴 수 있도록 도움을 준 강의

강의를 전체적으로 들으면서 느낀 점은 단순히 글쓰기 기술만 다루는 것이 아니라, 블로그 운영 전반에 대한 깊은 통찰을 제공한다는 것이었습니다. 특히 제시된 프레임워크와 접근 방식들은 기술 블로그뿐만 아니라 다른 분야의 글쓰기나 프로젝트에도 활용할 수 있을 것 같았습니다.

기술 블로그에 입문하는 분들께도 물론 많은 도움이 될 내용이지만, 특히 저처럼 기술 블로그를 운영하지만 슬럼프를 경험하고 있는 분들께도 큰 도움이 될 것 같다는 생각이 들었어요. 비슷한 입장에서 공감할 수 있는 내용도 많았고, 같은 문제를 바라보는 성윤 님의 색다른 관점을 통해 아하! 하는 순간들도 많았거든요.

또 하나 재미있었던 점은 제가 이미 실천하고 있던 많은 방법들이 글또 활동을 통해 배운 것들이라는 걸 새삼 깨달았다는 것입니다. 이를 통해 글또 활동이 제 글쓰기 여정에 얼마나 큰 영향을 미쳤는지 다시 한번 실감할 수 있었구요.

무엇보다도 저에게는 글쓰기에 대한 동기가 떨어져 있던 시기에 이 강의를 다시 들으면서 글쓰기의 즐거움과 의미를 되찾을 수 있었다는 점이 가장 큰 수확이었습니다. 혹시라도 나중에 글쓰기에 대한 열정이 떨어지거나 슬럼프를 겪는다면, 이 강의를 다시 한번 들어보면서 스스로를 다잡아야겠다는 생각이 들었습니다.

마지막으로 강의의 마지막 부분에서 제시한 액션 아이템들을 점검하며 글을 마무리하고자 합니다.

✅ 블로그를 운영하는 이유를 명시적으로 남겨두기: 글쓰기 매니페스토 문서를 작성함

✅ 내가 생각하기에 좋은 글 분석하기: 글또 10기 큐레이션 경험을 통해 정리한 바 있음

☑️ 글쓰기 프로세스 점검: 기존의 글쓰기 파이프라인이 잘 동작하지 않은 만큼 재점검이 필요해 보이니 개선할 부분을 찾아보자

☑️ 글을 작성할 환경과 전략 만들기: 1년 12개의 글 작성이라는 목표를 설정했으니, 남은 기간 내 목표 달성을 위한 전략을 구체적으로 세워보자!

☑️ 꾸준한 실천: 매주 일정 시간을 확보해 글쓰기에 집중하자

클라이언트 환경에서 안전한 소셜 로그인을 구현하는 핵심 메커니즘, OIDC와 PKCE 알아보기

Thu, 31 Jul 2025 00:00:00 GMT

흔히 마주칠 수 있는 소셜 로그인, 그 이면에 숨겨진 보안 메커니즘에 대해 생각해보기

최근 프로젝트에서 페이스북 소셜 로그인 기능을 구현하는 업무를 맡게 되었습니다. 기존에는 구글과 애플 로그인이 이미 구현되어 있었고, 서버에서 nonce 와 state 값을 발급받아 사용하는 하이브리드 플로우 방식을 사용하고 있었습니다. 그래서 저는 페이스북 역시 동일한 방식으로 구현할 수 있을 것이라 예상했죠.

하지만 페이스북 공식 문서를 확인해보니, 예상과 달리 클라이언트에서 추가적인 보안 조치를 적용해야만 액세스 토큰을 얻을 수 있다는 점을 알게 되었습니다. 바로 PKCE가 적용된 OIDC 인증 방식이 필요하다는 것이었습니다.

물론 클라이언트에서 추가 인증 과정을 생략하고 액세스 토큰을 받아오는 방법도 있었지만, 이는 보안상 취약점이 있어 권장되지 않는 방식이었습니다. 그래서 가능하다면 PKCE가 적용된 OIDC 인증 방식을 써야 한다는 점을 알게 되었죠.

사실 OAuth의 전체적인 흐름에 대해 잘 알지 못했던 터라, 낯선 용어들을 접하니 막막함이 느껴지더라구요. 그렇지만 회사 업무인 만큼 팀 동료들에게도 이 개념을 잘 설명할 수 있어야 했기에 학습에 대한 동기부여로도 이어졌습니다. 그래서 본격적인 기능 구현에 앞서 열심히 자료를 찾아보며 해당 개념을 이해하려고 노력했고, 결과적으로 코드 리뷰도 잘 마치고 기능 구현까지 성공적으로 완료할 수 있었습니다.

그래서 오늘은 제가 직접 경험한 페이스북 로그인 구현 사례를 바탕으로, OIDC와 PKCE를 활용해 클라이언트 측에서 어떻게 안전하게 사용자 인증을 구현할 수 있는지 알아보고자 합니다. OIDC와 PKCE의 개념을 이해하고 실제 적용 방법이 궁금하신 분들께 도움이 되기를 바랍니다.

개념 정리

PKCE가 적용된 OIDC 방식의 소셜 로그인을 다루는 만큼, 필수적으로 등장하는 개념인 OAuth 2.0, OIDC (OpenID Connect), 그리고 PKCE (Proof Key for Code Exchange) 에 대해 간단히 정리해보겠습니다.

OAuth 2.0

OAuth 2.0 시퀀스 다이어그램, 출처는 여기

OAuth 2.0 은 권한 부여(Authorization)에 사용되는 프로토콜로, 클라이언트(애플리케이션)가 사용자를 대신하여, 또는 애플리케이션 자체가 특정 자원에 대해 제한된 접근 권한을 얻을 수 있도록 하는 역할을 합니다.

구글 드라이브에 접근 권한을 요구하는 SNS 서비스를 이용하는 시나리오를 한 번 떠올려봅시다.

철수는 SNS 웹 사이트의 구글 로그인 버튼을 클릭합니다.

웹 사이트가 구글의 권한 허용 페이지로 리다이렉트되며, 이 액세스에 대한 동의를 제공하라는 메시지가 표시됩니다.

철수는 동의 버튼을 클릭합니다.

그러면 SNS로 리다이렉트가 되는데, 이때 SNS는 구글로부터 권한을 부여받는 과정을 거칩니다.

SNS는 구글로부터 액세스 토큰을 받아, 철수가 구글 드라이브에 올린 사진첩에 접근할 수 있게 됩니다.

이처럼 우리는 소셜 로그인을 시도할 때, 내 구글 계정의 ID와 비밀번호를 해당 서비스에 직접 입력하는 것이 아니라, 구글의 권한 동의 페이지로 리다이렉트되는 경험을 해보셨을 겁니다.

여기에서 동의 버튼을 누르게 되면 해당 서비스는 구글로부터 해당 권한을 실행할 수 있는 액세스 토큰(Access Token) 을 받게 되는데요, 서비스는 그 토큰을 이용해서 비로소 내가 가진 자원에 접근할 수 있게 되죠.

이처럼 사용자는 자신의 구글 ID와 비밀번호를 해당 사이트에 직접 제공하지 않고, 구글을 통해 안전하게 자원에 접근할 권한을 위임합니다. 이 흐름이 바로 OAuth 2.0의 핵심입니다.

이 과정에는 네 가지 핵심 개념이 등장합니다.

자원 소유자(Resource Owner): 사용자 본인

클라이언트(Client): 우리가 개발하는 애플리케이션 (구글 로그인을 연동하려는 서비스)

권한 부여 서버(Authorization Server): 사용자를 인증하고 클라이언트에게 액세스 토큰(Access Token)을 발급해주는 서버,

자원 서버(Resource Server): 사용자의 정보(자원)를 실제로 보유하고 있는 서버 (예: 페이스북, 구글)

그리고 OAuth 2.0에는 액세스 토큰을 발급받기 위한 인증 흐름의 종류를 정의하는 권한 부여 유형(Grant Type) 도 네 가지가 존재합니다.

권한 코드 인증(Authorization Code Flow): 클라이언트가 권한 코드를 요청하고, 이 코드를 액세스 토큰으로 교환하여 발급받는 방식

암묵적 인증(Implicit Flow): 클라이언트가 직접 액세스 토큰을 요청하고 발급받는 방식

리소스 소유자 비밀번호 자격 증명 인증(ROPC): 사용자의 아이디와 비밀번호를 클라이언트가 직접 받아 OAuth 서버에 전달해 토큰을 발급받는 방식

클라이언트 자격 증명 인증(Client Credentials Flow): 클라이언트 시크릿을 사용하여 액세스 토큰을 발급받는 방식

그 중에서도 권한 코드 인증 플로우라는 녀석이 오늘 이야기할 PKCE와 관련이 깊으니 기억해둘 필요가 있습니다.

여기서 중요한 점은 OAuth 2.0은 인증(Authentication) 이 아니라 권한 부여(Authorization) 를 위한 프로토콜이라는 점입니다. 즉, OAuth 2.0은 사용자가 누구인지에 대한 정보를 확인하지 않습니다.

OIDC

OIDC 시퀀스 다이어그램, 출처는 여기

이러한 이유로 등장한 OIDC(OpenID Connect) 는 OAuth 2.0 위에 구축된 프로토콜로, 사용자 인증을 위한 표준화된 방법을 제공합니다. OIDC는 사용자 인증과 ID 정보를 액세스 토큰과 함께 ID 토큰(ID Token) 형태로 제공합니다.

그런데 OIDC는 왜 필요한 걸까요? 단순히 OAuth 2.0으로 발급받은 토큰으로 로그인한 계정의 정보를 API로 조회하면 충분하지 않을까요?

이는 OAuth 2.0의 근본적인 목적과 관련이 있습니다. OAuth 2.0의 액세스 토큰은 특정 자원에 접근할 수 있는 권한만을 증명할 뿐, 그 토큰을 사용하는 사람이 정말 토큰의 주인인지는 보장하지 않습니다. 만약 공격자가 액세스 토큰을 탈취한다면, 다른 사람인 척하며 자원에 접근할 수도 있겠죠. 이처럼 액세스 토큰과 프로필 API의 조합만으로는 인증된 사용자가 접근한다는 사실을 온전히 보장하기 어렵습니다.

즉, OAuth 2.0의 액세스 토큰과 프로필 API는 사용자의 리소스 접근 만 보장할 뿐, 사용자가 인증되었고 누구인지 는 보장하지 않습니다. 그래서 ID 토큰이라는 추가적인 인증 정보가 필요하며, 이 정보를 ID 토큰 형태로 제공하는 것이 OIDC의 핵심입니다.

ID 토큰은 JWT 형식으로 만들어집니다. 덕분에 클라이언트 애플리케이션은 구글, 페이스북 등 여러 제공자를 OIDC로 연동하더라도, 각각의 사용자 정보를 일관된 방식으로 안전하게 처리할 수 있다는 장점이 있습니다.

PKCE

PKCE의 표준을 정의한 RFC 7636

PKCE(Proof Key for Code Exchange) 는 OAuth 2.0의 권한 부여 유형 중 권한 코드 플로우(Authorization Code Flow)에 추가되는 보안 강화 확장 으로, “픽시” 라고 발음합니다.

권한 코드 플로우는 서버로부터 액세스 토큰을 바로 전달받는 것이 아니라, 토큰을 교환하기 위한 권한 코드(Authorization Code) 를 먼저 발급받고, 이 코드를 사용하여 액세스 토큰을 요청하는 방식입니다. 비유하자면 액세스 토큰 교환권 을 발급해서 전달하는 것과 같죠. 이를 통해 액세스 토큰이 URL에 직접 노출되지 않도록 할 수 있다는 것이 장점입니다.

그런데 문제는 이 권한 코드도 URL을 통해 전달되기 때문에, 코드 자체가 탈취될 경우 해당 코드로 액세스 토큰을 발급받을 수 있다는 점입니다. 액세스 토큰이 쉽게 탈취되지 않도록 액세스 토큰 교환권 을 발급했는데, 이 교환권이 탈취당한다면 결국 액세스 토큰을 탈취당하는 것과 마찬가지라 조삼모사와 같은 상황이 되는 셈이죠.

만약 별도의 서버를 구축해 클라이언트별 고유값인 시크릿(Client Secret)을 안전하게 숨길 수 있다면 문제가 없지만, 모바일 앱이나 브라우저에서 실행되는 SPA(Single Page Application) 등에서는 이 시크릿이 쉽게 노출될 수 있다는 문제가 있습니다.

좀 더 구체적인 시나리오를 살펴보자면…

악성 브라우저 확장 프로그램: 사용자가 설치한 브라우저 확장 프로그램은 웹 페이지의 내용을 읽거나 수정할 권한을 가지므로 악의적으로 제작된 확장 프로그램은 페이지가 리디렉션될 때 URL에서 권한 코드를 쉽게 빼낼 수 있음

프록시 서버 또는 악성 Wi-Fi: 사용자가 신뢰할 수 없는 프록시 서버나 공용 Wi-Fi를 사용할 경우, 공격자는 사용자의 모든 웹 트래픽을 들여다볼 수 있으므로 권한 코드가 탈취될 수 있음

서버 로그: 웹 서버(Nginx 등)나 클라우드 서비스(Cloudflare Workers 등)는 일반적으로 모든 요청 URL을 로그로 기록하므로, 로그 파일 접근 권한이 공격자에게 넘어가면 권한 코드 또한 탈취될 수 있음

Referer 헤더 유출: 사용자가 권한 코드가 포함된 URL로 리디렉션된 후, 해당 페이지에 있는 링크를 클릭하여 다른 사이트로 이동하면 HTTP의 Referer 헤더에 이전 페이지의 URL(권한 코드 포함)이 담겨 넘어갈 수 있음

XSS 공격: 앱에 XSS 취약점이 존재하는 경우, 악성 스크립트가 클라이언트의 권한 코드를 탈취할 수 있음

Open Redirect 취약점: 공격자가 redirect_uri 가 악성 URI로 변조된 링크를 클릭하도록 유도하면 공격자가 권한 코드를 탈취할 수 있음

결국 모든 문제의 원인은 바로 권한 코드가 클라이언트의 URL에 노출되어 탈취당할 위험이 있기 때문입니다. 그렇기 때문에 PKCE에서는 액세스 토큰은 URL 로 전달되는 게 아니라, 주로 별도로 마련된 토큰 조회 API 를 통해서 발급됩니다. HTTPS 프로토콜을 사용해 통신하기 때문에 이 토큰은 TLS 암호화로 보호되죠.

따라서 토큰을 제대로 발급받기 위해서는, 인증을 요청한 클라이언트가 토큰을 요청한 클라이언트와 동일한 주체임을 인증 서버에 증명해야 합니다. ‘인증을 요청한 것도 나고, 이 코드를 전달받은 것도 나니까 진짜 액세스 토큰을 내놔!’ 라고 요청하는 것이죠.

PKCE의 시퀀스 다이어그램, 출처는 여기

이를 위해서 PKCE는 보증 키(Proof Key) 라는 개념을 사용합니다. 이를 통해 클라이언트가 권한 코드를 요청할 때, 해당 코드가 실제로 이 클라이언트에 의해 요청되었음을 증명하죠. 이 과정은 다음과 같이 진행됩니다.

클라이언트가 증명을 위한 임의의 비밀 문자열 code_verifier 을 생성

code_verifier를 특정 방식(주로 SHA256)으로 해싱하여 code_challenge를 생성

클라이언트는 로그인 요청 시 code_challenge 를 권한 부여 서버(예: 페이스북)로 전송

권한 부여 서버는 이 code_challenge 를 저장한 뒤, 권한 코드를 클라이언트에게 발급

클라이언트는 발급받은 권한 코드와 함께, 원본 비밀 문자열인 code_verifier 를 권한 부여 서버에 보내 액세스 토큰을 요청

권한 부여 서버는 전달받은 code_verifier를 저장해둔 code_challenge와 비교/검증하여 일치할 경우에만 액세스 토큰을 최종 발급

code_verifier 와 code_challenge 라는 용어가 갑자기 등장해서 낯설게 느껴지실 수도 있는데요, 여기서 중요한 부분은 code_verifier 라는 임의의 변수를 해싱(hashing)해서 나오는 값이 code_challenge 라는 것입니다.

해싱의 특성상 code_verifier 를 알면 code_challenge 를 만들 수 있지만, 반대로 code_challenge 만으로는 code_verifier 를 유추할 수 없다는 점이 PKCE의 핵심입니다.

이 과정을 통해 인증 서버는 클라이언트가 실제로 권한 코드를 요청한 주체임을 검증할 수 있습니다. 만약 권한 코드가 탈취되더라도, 원본 비밀값인 code_verifier를 알지 못하면 토큰을 발급받을 수 없습니다. PKCE는 이처럼 권한 코드 플로우의 보안을 크게 강화합니다.

이러한 흐름을 표준으로 정의한 것이 바로 RFC 7636입니다.

페이스북 로그인 예제

이야기가 길어졌네요. 이렇게 해서 세 가지 개념의 이론을 정리해보았으니, 이제 본격적으로 페이스북 로그인에서 요구하는 PKCE가 적용된 OIDC 코드 플로우를 구현하는 예제를 살펴보겠습니다.

페이스북 앱 생성

페이스북 로그인을 구현하기 위해서는 먼저 페이스북 개발자 센터에서 앱을 생성해야 합니다. 아래 단계를 따라 앱을 생성합니다.

우선, 페이스북 개발자 센터에 접속하여 우측 상단의 ‘앱 만들기’ 버튼을 클릭합니다.

두 번째 단계로 넘어가면 ‘이용 사례’ 를 추가할 수 있는데요. 여기에서 ‘Facebook 로그인을 통한 인증 및 사용자의 데이터 요청’ 항목을 선택한 후 나머지 단계를 거쳐 앱 생성을 완료합니다. 앱 생성을 완료하면 앱 목록에서 앱 ID를 확인할 수 있습니다.

앱 생성이 완료되었다면, ‘이용 사례’ 메뉴에 들어가 페이스북 로그인 설정을 위해 ‘맞춤’ 을 선택합니다.

‘클라이언트 OAuth 설정 항목’ 에 위치한 ‘유효한 OAuth 리디렉션 URI’ 를 입력하는 칸으로 이동합니다.

이곳에는 소셜 로그인 후 페이스북이 사용자를 다시 돌려보낼 URL을 입력해야 합니다. localhost도 가능하지만, HTTPS 프로토콜 적용을 권장합니다. 저는 https://localhost:3000/callback 을 입력했습니다.

클라이언트 앱 생성

루트 경로의 페이지, 버튼을 누르면 로그인이 시작된다

이와 더불어 클라이언트 앱 생성도 해야 하는데요, 저는 create-next-app 을 사용하여 Next.js 앱을 생성하였습니다. 그리고 로컬 서버 실행 시 간단하게 HTTPS 환경을 적용하도록 next dev --experimental-https 명령어를 사용했습니다.

생성한 페이지는 총 2개로, 루트 경로(/)에는 페이스북 로그인을 시작하는 버튼을 배치하고, 리다이렉션 경로(/callback)에는 페이스북에서 리다이렉트 후의 로직을 담은 페이지를 구현하려고 합니다.

이제 페이스북 로그인 버튼을 눌렀을 때 실행되는 로직을 구현하겠습니다.

`code_verifier` 생성

code_verifier 의 표준

가장 먼저, 클라이언트에서 암호화된 문자열 쌍을 생성해야 합니다. 이 과정은 서버와의 통신 없이 클라이언트에서 자체적으로 수행됩니다. 저희는 일단 웹 애플리케이션을 기준으로 설명하려고 하니, TypeScript를 사용하여 생성해보겠습니다.

Math.random() 는 시드 기반으로 유사 난수 를 제공하기 때문에 보안을 위한 난수 생성 용도로는 별도의 API 사용을 권장하고 있다

PKCE 표준에 따르면 code_verifier 는 임의의 문자열이어야 하는데, 이 문자열은 암호학적으로 안전한 무작위 문자열이어야 합니다. 여기서 암호학적으로 안전한 난수란, 무작위성(엔트로피)이 충분히 높아 예측이 불가능한 난수를 의미합니다.

Math.random()은 시드 기반으로 유사 난수를 생성하기 때문에, 예측 가능한 패턴이 있어 보안 용도로는 적합하지 않습니다.

window.crypto.getRandomValues() 로 안전한 난수를 생성하자

이를 대체하는 함수로는 JavaScript의 window.crypto.getRandomValues()가 있는데요, 이 메서드를 사용하면 무작위성이 충분히 큰 난수를 생성할 수 있습니다.

code_verifier 는 43자에서 128자 사이의 길이를 가지며, Base64URL 인코딩 을 사용하여 표현합니다. Base64URL은 URL에서 안전하게 사용할 수 있도록 일부 문자를 대체한 Base64 인코딩 방식으로, 일반적인 Base64 인코딩과 유사하지만 +, / 문자를 각각 -, _ 로 대체하고 마지막 패딩 문자 = 를 제거한다는 특징이 있습니다.

이러한 제약 조건을 만족하는 code_verifier 를 생성하는 TypeScript 코드는 다음과 같습니다.

// Base64URL 인코딩을 적용한 문자열 생성 함수
const getBase64UrlEncoded = (bytes: Uint8Array): string =>
  window
    // Base64 인코딩을 적용
    .btoa(
      Array.from(bytes)
        .map((byte) => String.fromCharCode(byte))
        .join('')
    )
    // Base64URL 인코딩에서 사용하는 문자로 변환
    .replaceAll('+', '-')
    .replaceAll('/', '_')
    .replaceAll('=', '');

// 43자에서 128자 사이의 길이를 가지는 code_verifier 생성 함수
const generateCodeVerifier = (length = 32): string => {
  // Uint8Array 배열을 생성
  const bytes = new Uint8Array(length);

  // Uint8Array 배열에 무작위 값을 채움
  window.crypto.getRandomValues(bytes);

  // Base64URL 인코딩을 적용하여 code_verifier 생성
  const codeVerifier = getBase64UrlEncoded(bytes);

  return codeVerifier;
};

`code_challenge` 생성

code_challenge 의 표준

code_verifier 를 생성했다면 이를 기반으로 code_challenge 를 생성해야 합니다. code_challenge 를 생성하는 방법은 크게 두 가지가 있습니다.

Plain: code_verifier 를 그대로 사용합니다.

S256: code_verifier 를 SHA-256 해시한 후, Base64URL 인코딩을 적용합니다.

1번의 경우에는 PKCE 적용을 하는 의미가 사실상 없기 때문에, 2번의 방법을 사용하여 code_challenge 를 생성하는 것이 일반적입니다. 따라서 이번 예제에서도 S256 방식을 사용하여 code_challenge 를 생성하려고 합니다. 그런데 웹 환경에서 SHA-256 해시는 어떻게 적용할 수 있을까요?

JavaScript에서 SHA-256 해시를 적용할 수 있는 네이티브 메서드

바로 JavaScript 에서는 crypto.subtle.digest() 메서드를 사용하여 SHA-256 해시를 생성할 수 있습니다. 이 메서드는 비동기적으로 동작하므로, async 와 await 구문을 사용하여 처리해야 하며, HTTPS 환경에서만 사용할 수 있습니다.

이렇게 나온 해시를 다시 Base64URL 인코딩하면 code_challenge 가 생성됩니다. 이를 TypeScript 로 구현한 코드는 다음과 같습니다.

// code_challenge 생성 함수
const generateCodeChallenge = async (codeVerifier: string): Promise<string> => {
  // TextEncoder는 문자열을 Uint8Array로 인코딩하는 데 사용
  const encoder = new TextEncoder();

  // code_verifier를 Uint8Array로 변환
  const encodedCodeVerifier = encoder.encode(codeVerifier);

  // Uint8Array 데이터를 SHA-256 알고리즘으로 해싱, 반환값은 Promise<ArrayBuffer>
  const hashedCodeVerifier = await window.crypto.subtle.digest(
    'SHA-256',
    encodedCodeVerifier
  );

  // ArrayBuffer로 변환된 해시 값을 Uint8Array로 변환
  const bytes = new Uint8Array(hashedCodeVerifier);

  // Base64URL 인코딩을 적용하여 code_challenge 생성
  const codeChallenge = getBase64UrlEncoded(bytes);
  return codeChallenge;
};

`code_verifier` 를 저장

PKCE 흐름에서는 클라이언트로 리다이렉트가 된 후, 최종적으로 액세스 토큰을 요청할 때 code_verifier 를 사용해야 합니다. 따라서 이 값을 리다이렉트 페이지에서도 접근할 수 있게 저장해두는 것이 중요합니다.

localStorage.setItem('code_verifier', codeVerifier);

이를 위해서는 로컬 스토리지나 세션 스토리지 등을 활용할 수 있겠죠.

인증 서버에 요청 전송

이제 생성된 code_challenge 를 포함하여 사용자를 페이스북 인증 페이지로 보내야 할 차례입니다. 공식 문서에서 제공하고 있는 파라미터를 참고하여 아래와 같은 URL을 구성하고, 사용자를 해당 URL로 리다이렉트합니다.

const url =
  `https://www.facebook.com/v11.0/dialog/oauth?` +
  `client_id=${FACEBOOK_APP_ID}` + // 필수값, 페이스북 개발자 센터에서 발급받은 앱 ID
  `&scope=openid` + // 필수값, OIDC with PKCE 에서는 반드시 openid로 설정 필요
  `&response_type=code` + // 필수값, OIDC with PKCE 에서는 위해서 반드시 code로 설정 필요
  `&redirect_uri=${FACEBOOK_REDIRECT_URI}` + // 필수값, 페이스북 앱 생성시 설정한 URI
  `&code_challenge=${codeChallenge}` + // 필수값, 위의 코드로 생성한 code_challenge 값
  `&code_challenge_method=S256` + // 권장값, code_challenge의 해싱 방법으로 여기서는 S256을 사용, 기본값은 plain
  `&state=${state}` + // 권장값, CSRF 공격을 방지하기 위한 임의의 문자열
  `&nonce=${nonce}`; // 필수값, OIDC에서 ID 토큰의 재생 공격을 방지하기 위한 임의의 문자열

router.push(url);

nonce 는 ID 토큰의 위조 및 재사용을 방지하기 위해, state 는 인증 요청에 대한 응답의 무결성과 CSRF 공격을 방지하기 위해 클라이언트가 검증해야 하는 값입니다.

이 URL을 통해 사용자는 페이스북의 로그인 페이지로 리다이렉트됩니다. 그러면 버튼 클릭 시 위와 같이 페이스북의 인증 페이지로 리다이렉트가 됩니다. 사용자는 페이스북 계정으로 로그인하고, 애플리케이션에 권한을 부여하는 과정을 거치게 되죠.

페이스북 로그인 버튼 클릭 시 인증 요청을 보내는 모습

최종적으로 페이스북 로그인 버튼 클릭 시 실행할 함수는 다음과 같은 형태로 작성할 수 있습니다.

const handleFacebookLogin = async () => {
  const codeVerifier = generateCodeVerifier();
  const codeChallenge = await generateCodeChallenge(codeVerifier);
  const state = generateRandomString(); // CSRF 공격 방지를 위한 임의의 문자열 생성
  const nonce = generateRandomString(); // ID 토큰의 재생 공격 방지를 위한 임의의 문자열 생성

  localStorage.setItem('code_verifier', codeVerifier); // code_verifier를 로컬 스토리지에 저장
  localStorage.setItem('state', state); // state를 로컬 스토리지에 저장

  const url = `...`; // 위에서 작성한 URL
  router.push(url);
};

리다이렉트 URI에서 액세스 토큰 획득

사용자가 성공적으로 인증을 마치면, 페이스북은 지정된 redirect_uri 로 사용자를 리다이렉트 시킵니다. 이때 URL의 쿼리 파라미터로 code 와 state 가 포함되는데요, code 에는 ID 토큰을 요청할 수 있는 권한 코드가 담겨 있고, state 는 CSRF 공격을 방지하기 위해 사용됩니다.

https://localhost:3000/callback?code={code}&state={state}

여기서 클라이언트는 CSRF 공격을 방지하기 위해, 2단계에서 생성한 state 값을 먼저 검증해야 합니다. 요청에 보낸 state 값과 콜백 URI에 포함된 state 값을 비교하여 일치하는지 확인하는 과정을 거칩니다. 만약 일치하지 않는다면 CSRF 공격이 의심되므로, 인증 과정을 중단하고 에러를 발생시킵니다.

// callback.tsx

const state = localStorage.getItem('state');

if (state !== router.query.state) {
  throw new Error('Invalid state parameter'); // CSRF 공격 방지를 위한 검증
}

그 후, 획득한 code와 함께 숨겨두었던 code_verifier 를 사용하여 최종적으로 액세스 토큰을 교환하는 API 를 호출합니다.

페이스북 서버는 전달받은 code_verifier 를 해싱한 후, 저장해두었던 code_challenge 와 비교합니다. 값이 일치하면, 인증된 클라이언트라고 판단하고 액세스 토큰과 ID 토큰 등이 포함된 JSON 응답을 반환합니다.

// callback.tsx

const codeVerifier = localStorage.getItem('code_verifier');
const code = router.query.code;

const url =
  `https://graph.facebook.com/v11.0/oauth/access_token?` +
  `client_id=${FACEBOOK_APP_ID}` + // 페이스북 개발자 센터에서 발급받은 앱 ID
  `&redirect_uri=${FACEBOOK_REDIRECT_URI}` + // 페이스북 앱 생성 시 설정한 URI
  `&code_verifier=${codeVerifier}` + // 페이스북 로그인 요청 시 생성한 code_verifier
  `&code=${code}`; // 페이스북 로그인 후 리다이렉트된 URI에서 추출한 code

const response = await fetch(url).then((res) => res.json());

console.log(response);
// {
//   "access_token": string // 페이스북 API에 접근할 수 있는 액세스 토큰
//   "expires_in": number // 토큰의 유효 기간 (초 단위)
//   "id_token": string // JWT 형식의 ID 토큰, 사용자의 인증 정보를 포함
//   "token_type": "bearer" // 토큰의 유형, 일반적으로 "bearer"로 설정됨
// }

const accessToken = response.access_token; // 액세스 토큰을 획득!

페이스북 인증 후 PKCE를 거쳐 액세스 토큰을 획득하는 모습

이로써 모든 인증 과정이 안전하게 완료되며, 획득한 액세스 토큰으로 페이스북 API를 호출하거나, id_token을 활용해 사용자 정보를 확인하여 자체 로그인 처리를 할 수 있게 됩니다.

마무리

이제 다른 서비스의 소셜 로그인을 붙이는 것도 수월하겠지?

이렇게 해서 PKCE가 적용된 OIDC 인증 과정을 페이스북 로그인 구현을 통해 살펴보았습니다.

저도 이 글을 정리하면서 단순히 소셜 로그인 으로만 알고 있었던 개념들 속에 숨겨진 여러 보안 메커니즘을 이해하게 되었습니다. 그리고 이러한 보안 메커니즘이 도입된 이유와 그 배경에 있는 고민들을 이해하게 되니, 단순히 기능을 구현하는 것을 넘어 보안 원리를 이해하고 적용하는 것이 얼마나 중요한지 깨닫게 되었습니다.

처음에는 저도 낯선 용어들을 마주치며 막막함을 느꼈지만, 하나씩 개념을 정리하고 실제로 코드를 작성해보면서 베일에 싸여 있던 OAuth 2.0, OIDC, PKCE의 개념이 점차 명확해졌습니다.

이제는 누군가 제게 소셜 로그인 구현에 대해 묻는다면, 좀 더 자신 있게 안전한 방향을 제시할 수 있을 것 같더라구요.

참고 자료

OAuth(오픈 인증)란 무엇인가요?

OAuth 2.0은(는) 무엇인가요?

AI와 함께하는 글쓰기 토너먼트 대회, 글드컵 진행 후기

Sun, 29 Jun 2025 00:00:00 GMT

지난달, 글 쓰는 개발자 커뮤니티 글또 10기의 성공적인 마무리를 기념하며 색다르고 재미있는 이벤트를 개최했습니다. 바로 글쓰기 토너먼트 대회, 글드컵 입니다.

글드컵은 ‘글또 제출글 월드컵’ 의 줄임말로, 글또 10기 활동 기간 동안 참여자들이 작성한 글 중 최고의 글을 가려내는 토너먼트 대결 이벤트입니다.

‘포켓몬스터의 대전 마냥, 글쓰기로 배틀을 해본다면 어떨까?’ 라는 아이디어로 시작하게 된 행사

‘글쓰기로 모인 사람들인 만큼 글쓰기로 배틀을 한다면 어떨까?’ 라는 참신한 아이디어에서 시작된 이 행사는 총 한 달의 준비 기간을 거쳐 약 70여 명의 참여자와 함께 기술 및 비기술 분야별 우승자를 가려냈습니다. 특히, 글쓰기 배틀이라는 독특한 아이디어에 AI가 심판으로 참여했다는 점 덕분에 많은 분들이 흥미를 느끼고 뜨거운 반응을 보내주셨습니다.

글쓰기 토너먼트 대회라는 새로운 형식의 행사를 통해 글또 참여자분들에게 즐거운 경험을 선사하고, 제가 애정하는 커뮤니티의 마무리를 장식하는 행사가 되었다는 점에서 글드컵은 저에게도 특별한 행사로 기억될 것 같습니다.

이번 행사는 단순히 글또 10기의 마무리를 넘어 AI를 적극적으로 활용하여 기획하고 운영한 이벤트라는 점에서 저에게 더 의미 있는 경험이었습니다. 포스터 제작부터 홍보 문구 작성, 대진표 구성, 그리고 행사의 핵심인 평가 프롬프트 작성에 이르기까지, 거의 모든 과정에서 AI의 손길이 닿지 않은 곳이 없었죠. AI와 함께 행사를 성공적으로 이끌며, 우리 일상과 업무에 AI를 어떻게 실용적으로 접목할 수 있는지에 대한 새로운 통찰을 얻을 수 있었습니다.

그래서 오늘은 글드컵이라는 행사를 기획하고 준비하는 과정과 함께, 이 과정에서 AI를 어떻게 효과적으로 활용했는지 그 노하우를 자세히 공유하고자 합니다. 이번 글이 AI를 활용한 행사 기획과 운영에 대한 통찰을 얻고 싶은 분 또는 행사 기획 및 운영에 AI를 접목하는 방법을 궁금해하는 분들께 도움이 되기를 바랍니다.

글드컵이란

아무래도 진행한 대회에 대한 소개가 필요할 것 같아서, 글드컵이 무엇인지부터 간단히 소개해 드리겠습니다.

글드컵은 글또 10기 활동 기간 중 제출된 글을 대상으로 최고의 글을 가려내는 토너먼트 대결 이벤트입니다. 참여자들은 본인이 쓴 글 중 하나를 선택해 토너먼트에 참가하고, 대진표에 따라 AI가 심판 역할을 맡아 글을 평가하는 방식으로 진행됐습니다. 글 평가는 기존 큐레이션 크루가 활용했던 다음 네 가지 지표를 AI에게 전달해서 진행했습니다.

글의 구조적 완성도: 논리적인 흐름과 짜임새 있는 구성을 평가

내용의 독창성과 전문성: 주제의 참신함과 내용의 깊이를 평가

가독성과 표현력: 문장의 명확성, 이해하기 쉬운 표현력을 평가

독자 친화성: 독자의 흥미를 유발하고 공감을 이끌어내는 정도를 평가

이 기준에 따라 AI는 각 글을 객관적이고 일관적으로 평가했으며, 더 높은 점수를 받은 글이 다음 라운드로 진출하는 토너먼트 방식으로 최종 우승작을 가려냈습니다.

기술 토너먼트: 특정 기술, 개발 방법론, 아키텍처 등 기술적인 내용을 깊이 다루는 글

비기술 토너먼트: 글쓰기 경험, 회고, 커리어, 학습 방법, 커뮤니티 활동 등 비기술적인 경험이나 생각을 공유하는 글

글드컵 토너먼트는 제출 글의 성격을 고려해 크게 두 개의 대회로 나뉘었습니다. 참가자들은 본인이 쓴 글 중 하나를 골라 기술 토너먼트나 비기술 토너먼트 중 한 분야에만 지원할 수 있습니다. 이는 아무래도 특정 기술의 동작 원리를 깊게 다룬 글과 개인적인 회고 글을 똑같은 기준으로 평가하는 것이 어렵다고 판단했기 때문입니다.

탄생 배경

새벽에 떠오른 뻘생각… 역시 새벽 감성이어야 새로운 아이디어가 샘솟는다

글드컵은 3월 2일 새벽에 문득 떠오른 아이디어에서부터 시작되었습니다. 그날은 『안드로이드 크롬에서 CSS vh 단위가 이상하게 동작했던 이유』 포스트를 제출하기 위해 밤을 새고 있던 날이었죠.

아침이 되고 나서야 글을 완성하고 잠자리에 들려는데, 불현듯 ‘포켓몬스터 대전처럼 글또에서 대결의 요소가 있는 행사를 해 볼만한 게 있을까?’ 하는 생각이 들었습니다. 내가 수집한 포켓몬을 필드에 내보내서 상대방의 포켓몬과 대결하는 것이 포켓몬 배틀의 흥미로운 요소인데, 이를 ‘글또 10기 내에서 작성한 글을 각자 하나씩 골라 상대방과 대결을 붙여보는 것도 재밌겠다’ 는 생각이 들더라구요.

ChatGPT에게 처음 시켜봤던 글쓰기 대결의 결과

과연 이 아이디어가 현실에서 실현 가능할지 궁금했습니다. 그래서 바로 ChatGPT에게 두 개의 글 링크를 던져주고 더 잘 쓴 글을 골라달라고 요청했습니다. AI가 웹 크롤링을 원활하게 할 수 있어야 이 아이디어가 현실이 될 수 있었거든요.

다행히(?) ChatGPT는 서로 다른 두 글을 비교해서 더 나은 글을 선정해 낼 수 있었습니다. 이로써 평가 프롬프트를 정교하게 다듬으면 글쓰기 배틀이라는 아이디어를 실현할 수 있겠다는 확신을 얻었습니다.

이 아이디어를 운영진 채널에 공유했을 때의 반응은 뜨거웠습니다. 다만, 이 단순한 아이디어를 구체적인 행사로 만들기까지 얼마나 많은 기획과 준비가 필요할지는 미지수였기에, 본격적인 행사 준비는 글또 10기 활동 기간이 끝난 후 다시 논의해 보기로 했습니다.

그렇게 시간이 흘러 글또 마지막 제출을 앞둔 날, 함께 이 아이디어를 진행해보고 싶은 분이 계신지 운영진 채널에 다시 물었습니다. 다행히 같은 큐레이션 운영진이었던 희선님께서 흔쾌히 함께해 주시기로 했고, 그렇게 한 달간의 긴 여정이 시작되었습니다.

준비하기

자… 그럼 뭐부터 해볼까요?

본격적으로 행사를 준비하려고 하니, 생각보다 많은 부분을 고민해야 했습니다. 어떤 AI 모델을 사용할지, 어떻게 참여자를 모집할지, 대진표는 어떻게 만들지 등등… 이 과정에서의 고민 과정을 공유합니다.

AI 모델 선정

글드컵 아이디어를 구체화하면서 가장 먼저 고민했던 건 어떤 AI 모델을 사용할지였습니다. 단순히 두 글의 링크를 던져주고 승자만 알려주는 방식은 가장 간단했지만, 저희는 단순히 승패만을 알고 싶었던 게 아니었거든요.

AI가 판단을 내리기까지의 과정을 듣고 싶다

토너먼트 참가자들은 AI에게 평가받는 자신의 글이 상대방의 글과 비교했을 때 어떤 면에서 뛰어나고, 어떤 면에서 부족한지, 본인 글의 점수는 어떻게 매겨진 것인지 그 이유를 알고 싶을 것이라고 생각했습니다. 즉, 더욱 의미 있는 정보를 제공하려면 평가 과정을 알 수 있어야 합니다. 이는 곧 AI가 단계 별로 생각하는 과정을 보여줄 수 있는 모델, 추론 모델(reasoning model) 이 필수적이라고 결론 내렸죠.

Claude가 포켓몬스터 게임을 플레이 중. 추론 모델 특성 상 판단을 내리기까지의 과정을 직접 볼 수 있다!

이러한 추론 모델에 대한 아이디어를 처음 접한 건 트위치에서 Claude가 포켓몬스터 게임을 플레이하는 방송을 보면서였습니다. AI가 특정 논리적 과정을 거쳐 판단을 내리는 모습을 굉장히 흥미롭게 봤는데요, 이 기억이 떠올라서 우리 행사에도 적용할 수 있겠다는 영감을 얻었죠.

그래서 추론 과정을 보여줄 수 있는 AI 모델들을 찾아보다가 Gemini가 눈에 들어왔습니다. Gemini의 제공 모델들을 살펴보니, Gemini 2.5 Flash와 Gemini 2.5 Pro에서 추론 과정을 확인할 수 있다는 것을 알게 되었죠. 마침 최근에 Gemini Advanced 무료 쿠폰을 받은 터라 이를 활용하기로 했습니다.

아이데이션

AI 모델 선정까지 마친 후, 저는 희선님과 오프라인으로 만나 글드컵 아이디어를 구체적인 행사로 만들기 위한 이야기를 시작했습니다. 당시 정해진 것이라곤 ‘AI를 활용해 글또 10기 제출글로 토너먼트 대결을 진행한다’ 는 큰틀 뿐이었죠.

아이디어 회의 후 기록 정리

행사의 진행자가 단 두 명뿐이었기에, 최대한 리소스를 절약하자는 데 공통적으로 의견이 모였습니다. 이러한 기조 아래, 저희는 다음과 같은 핵심 항목들을 논의했습니다.

가장 먼저 논의한 부분은 기술과 비기술 토너먼트의 구분 필요성이었습니다. 글또는 글 쓰는 개발자 커뮤니티인 만큼 기술 관련 글이 많지만, 회고록이나 일상 글도 상당수 존재했죠. 이 두 유형의 글을 동일한 평가 기준에 따라 평가하면 형평성 문제가 발생할 수 있고, 결과에 대한 참가자들의 납득을 얻기 어려울 것이라고 판단했습니다. 그래서 기술과 비기술 토너먼트를 별도로 진행하기로 결정했습니다.

다음은 참여자 모집 방식이었습니다. 구글 폼을 활용해 참가자를 모집하되, 5월 초 연휴 전까지 마감을 목표로 했습니다. 그리고 진행자의 리소스를 고려하여 각 토너먼트별 최대 64명으로 인원을 제한했습니다.

대결 진행 방식은 토너먼트 특성상 많은 수의 대결( $N - 1$ )이 발생하기에, 모든 대결을 실시간으로 할 수는 없었습니다. 이에 따라 대결은 미리 진행하고, 결과를 날짜별로 나누어 배포하기로 했습니다. 다만, 참가자들의 흥미를 더 끌기 위해 8강부터는 라이브 진행도 고려했죠.

결과 공유 방식의 경우, 인터랙티브한 전용 웹페이지 제작은 리소스 부담이 크다고 봤습니다. 그래서 간단하게 노션 페이지를 만들고, 대진 진행에 따라 결과를 수동으로 업데이트하는 방식을 택했습니다. 각 대진의 상세 결과는 별도의 페이지에서 확인 가능하게 했고요.

마지막으로 대진표 제작은 매일 업데이트가 필요하고 시각적으로도 잘 보여야 해서, Mermaid 로 코드를 작성하고 노션에 임베드하는 방식을 활용했습니다. 노션이 Mermaid를 지원했기에 가능했던 일이죠. 그리고 참여자 보상은 전체 예산을 확보한 뒤 그 안에서 분배하기로 했습니다.

이렇게 희선님과 함께 글드컵 진행의 큰 틀을 잡은 후, 세부적인 기획 방향을 고민하기 시작했습니다.

포스터 제작

포스터 깎기의 흔적. 가장 힘든 것은 이미지 생성 완료까지 기다려야 했던 것…

AI 모델 선정과 더불어, 행사의 얼굴이 될 포스터 제작에도 바로 착수했습니다. 포스터 제작에는 ChatGPT를 활용했는데요. 당시 GPT-4o의 이미지 생성 모델이 막 추가되어 지브리풍 이미지를 만드는 것이 유행이었거든요.

저는 원하는 느낌과 분위기, 조명과 배경, 그리고 유사한 포스터 레퍼런스 등을 불렛 리스트 형태로 입력하며 이미지 수정 요청을 반복했습니다.

포스터 제작을 위해 입력했던 프롬프트 키워드들

팁 하나를 드리자면, 이렇게 반복해서 요구사항을 수정할 때는 AI에게 현재까지의 요구사항을 다시 정리해 달라고 요청하면 훨씬 깔끔하게 프롬프트를 관리할 수 있습니다.

글드컵 포스터

이렇게 약 13번의 수정 과정을 거쳐 위와 같은 최종 포스터를 완성했습니다. 개인적으로는 ChatGPT 를 이용해 생성한 이미지는 전체적으로 이미지 톤이 따뜻하고 부드러운 질감으로 표현되어 제가 원하는 분위기를 잘 살려냈습니다.

좌측이 ChatGPT, 우측이 Gemini로 생성한 이미지

한편, Gemini로도 포스터 제작을 시도해 보았지만, 이미지의 느낌과 퀄리티에서 확실히 차이가 느껴졌습니다. Gemini 포스터에서는 한자처럼 보이는 문자가 섞여 나오고 현실감이 부자연스러워서 흡사 중국산 짝퉁(…) 같은 느낌을 지울 수 없었죠.

두 모델 모두 생성형 이미지에 한글 문구나 추가 이미지를 직접 삽입하는 기능은 완벽하게 지원하지 못하는 듯했습니다. 하지만 전반적인 이미지 퀄리티 면에서는 ChatGPT의 결과물이 더 만족스러웠고, 해당 이미지를 포스터로 활용하기로 결정했습니다.

참여자 모집 및 홍보 전략

다음으로 고려한 것은 홍보 문구 작성과 참여자 모집 방법이었습니다. 글또 구성원들에게 글드컵이 어떤 이벤트인지 명확히 설명하고, 참여하고 싶은 마음이 들게 하는 홍보 문구가 필요해서 공을 많이 들였습니다.

슬랙에 공유한 대회 소개

그래서 총 2.5만 포인트를 걸고 펼쳐지는 글또 10기 최고의 글을 가려라! 와 같은 후킹 문구를 처음에 배치하여 눈길을 끈 후, 글드컵 소개와 대결 진행 방식을 설명했습니다. 그 후 일정과 주의 사항, 참여 시 혜택 등의 정보를 덧붙였죠. 이모지와 슬랙의 포매팅 문법도 적극적으로 활용해 비주얼과 가독성도 높였습니다.

고민하여 작성한 참여 유도 멘트

그리고 마지막에는 ‘내 글은 아직 부족한데…’ 라고 생각하는 분들을 위한 참여 독려 메시지를 작성했습니다. 토너먼트의 특성상 대결이 필연적으로 발생하지만, 패배에 대한 부담이 참여에 대한 허들이 될 수 있다고 판단했거든요. 아무래도 자신이 작성한 글이 상대적으로 ‘더 못 쓴 글’ 로 평가되는 것은 상처가 될 수도 있기도 하구요. 그래서 글드컵을 글또 10기를 마무리하는 축제 라는 표현으로 나타내어 대결에 대한 부담을 덜어드리고자 했습니다.

이렇게 작성한 홍보 문구를 Gemini에게도 다듬어 달라고 요청했고, 최종 공지 전에는 운영진 내부 채널에서 피드백을 한 번 더 거쳐 완성도를 높였습니다.

글드컵 참여 설문지에도 소개 문구를 적었다

참여자 모집은 당연하게도(?) 구글 폼을 이용했으며, 본인이 작성한 글 하나를 선정하여 기술 또는 비기술 토너먼트 중 한 분야를 골라 글또 10기 활동 기간 중 제출한 글을 하나 선정해서 링크로 제출하게 했습니다.

평가 프롬프트 다듬기

글드컵의 핵심은 AI에게 글쓰기 대결의 심판 역할을 맡기는 것 인 만큼, 평가 프롬프트 다듬기는 필수적인 과정이었습니다. AI가 글을 평가하는 데 있어 명확한 기준과 절차를 제공해야 했기 때문이죠.

프롬프트는 크게 다음과 같은 요소들로 구성했습니다.

대충 5,000자 정도의 프롬프트를 작성했다

역할 및 상황 설명: AI에게 글드컵 대회를 소개하고 두 글을 비교 평가하는 상황을 상세히 설명, 심판으로서의 역할을 부여한 뒤 AI에게 기대하는 평가 태도와 목표를 설정

평가 항목 및 배점: 큐레이션 팀에서 사용하던 평가 항목들을 제공

글의 구조적 완성도 (30점)

내용의 독창성과 전문성 (30점)

가독성과 표현력 (20점)

독자 친화성 (20점)

예외 상황 처리: 기술/비기술 토너먼트 별 가중치 조정 및 동점자 발생 시 처리 방법 안내

포매팅 지침: AI가 생성한 결과물을 노션에 바로 붙여 넣을 수 있도록 마크다운 포맷으로 정리해 달라고 요청

후속 프롬프트 안내: AI가 다음 대결을 위해 어떤 정보를 제공해야 하는지 안내

이렇게 작성한 프롬프트 그 자체도 AI에게 다시 다듬어달라고 재귀적으로 요청하며 완성도를 높였습니다.

훌륭한 글쓰기 대결 심판으로 조련(?)시켰다

이렇게 AI에게 심판 역할을 부여했다면, 그다음부터는 대결 진행에 필요한 정보만 제공하면 AI가 스스로 대결을 진행할 수 있도록 했습니다. 매칭 정보와 참여자, 글의 링크, 글 제목을 제공하면 AI가 해당 글을 읽고 평가를 진행하는 방식이었죠.

매칭 정보를 제공하면 추론 과정을 통해 그 결과를 볼 수 있다

이렇게 출력 포매팅을 마크다운 방식으로 지정해 두어서, AI가 생성한 결과물을 노션에 바로 붙여 넣을 수 있도록 했습니다. 이 부분은 나중에 대시보드 제작 시에도 큰 도움이 되었죠.

참가 접수

참여자 목록

프롬프트 다듬기 등 모든 준비를 마치고, 드디어 글드컵 참가자 모집글을 공개적으로 올렸습니다. 약 9일간의 모집 기간 동안 총 65명의 글또 멤버들이 글드컵에 참여 신청을 해주셨고, 기술 토너먼트에는 39명, 비기술 토너먼트에는 26명이 지원해 주셨습니다. 글또 10기 활동이 이미 종료된 시점임에도 불구하고 많은 분들이 참여해 주셔서 감사했습니다.

한편으로는 글드컵 신청 마감 기한까지 작성된 글도 참여 대상으로 인정하기로 했는데, 이 글드컵 참여를 위해 새로 글을 작성해 주신 분들도 계셔서 감동이었습니다. 글드컵이 단순히 기존 글을 겨루는 대회를 넘어, 누군가에게는 글쓰기에 대한 동기 부여가 되었다는 점에서 의미 있게 느껴졌거든요.

신청서에는 참여자들에게 자신의 글을 선택한 이유도 함께 물어봤는데, 그 이유가 다양해서 매우 흥미로웠습니다. 몇 가지를 꼽자면 다음과 같습니다.

가장 공들여 쓴 글이라서

글빼미(AI 피드백 봇)로부터 좋은 평가를 받은 글이라서

오로지 글드컵을 위해 새로 작성한 글이라서

본인의 철학을 담은 글이라서

제목이 가장 눈길을 끄는 글이라서

글을 쓰는 과정이 즐거웠던 글이라서

큐레이션에 선정된 기록이 있어서

이처럼 각자의 기준과 사연으로 선정된 글들이 모이면서, 저 역시도 글드컵에 대한 기대가 점점 커져갔습니다. 참여자들의 글이 어떤 대결을 펼칠지, 그리고 AI가 어떤 평가를 내릴지에 대한 호기심이 커져갔죠.

대시보드와 대진표 제작

대회 결과를 총 5일에 걸쳐 참가자들에게 배포해야 했기 때문에, 업데이트가 용이하면서도 추가적인 코딩 작업이 필요 없는 방법을 찾아야 했습니다. 그 결과, 앞서 이야기한 것처럼 노션을 활용해 대시보드를 제작하기로 결정했습니다.

제작한 대시보드. 상단에는 대진표, 하단에는 각 대결 별 상세 결과 페이지를 구성해 놓았다

대시보드의 상단은 대진표를 한눈에 볼 수 있게 구성하고, 하단에는 각 경기에 대한 상세 결과를 표로 정리해서 별도의 추가 페이지에서 확인할 수 있도록 했습니다.

Gemini를 이용한 Mermaid 대진표 코드 생성

대진표 제작에는 Mermaid 를 활용했고 이 부분에서 Gemini의 도움 을 많이 받았습니다. 참여자들의 이름 목록과 원하는 대진표 형식을 Gemini에게 전달하자, 금세 Mermaid 문법으로 작성된 대진표 코드를 생성해 주었거든요. 이 코드를 노션에 붙여 넣으면 자동으로 대진표가 뚝딱 생성되었습니다. 만약 이걸 제가 한땀 한땀 수작업으로 작성했다면, 아마도 몇 시간은 걸렸을 것 같습니다.

그런데 참가자 수가 정확히 $2^n$ 형태가 아니었기 때문에 부전승 처리가 필요했습니다. 특히, 부전승의 숫자가 좌우 트리에 최대한 균등하게 배분되도록 배치하는 것이 중요했는데, AI는 이런 디테일한 부분까지는 제대로 처리하지 못했습니다. 결국 이런 점에서는 수동으로 조정하는 과정이 필요하더라구요.

하지만 반복적이고 시간을 많이 소모할 수 있는 대진표 초기 스케치를 AI가 빠르게 생성해 준 덕분에, 전반적인 작업 효율을 크게 높일 수 있었습니다.

대결 진행

대결 진행을 위한 스크립트

대진표가 최종 구성된 후에는, 결과 발표일 전까지 모든 대결을 미리 진행해 두는 작업이 필요했습니다. 희선님께서 정해진 대진표에 따라 AI에게 전달할 프롬프트를 뽑는 작업을 스크립트로 정리해 주신 덕분에 작업은 한결 수월했습니다. 그 후, AI가 평가한 대결 결과를 대시보드에 옮겨두는 작업을 진행했습니다.

노션에 옮겨둔 대결 결과 상세 페이지

약간의 노가다(?)성 작업이 있었긴 하지만, AI가 제공한 결과물이 노션에 바로 붙여 넣을 수 있도록 마크다운 포맷으로 정리되어 있었기 때문에 생각보다 어렵지 않게 작업을 완료할 수 있었습니다.

결과 공개

하루하루 진행되는 대결 결과 배포를 매일 슬랙에 공유했다

이렇게 해서 8강까지는 모든 대결을 미리 진행하고, 결과를 정리하는 작업을 마쳤습니다. 이제 남은 건 대진 결과를 슬랙에 공개하는 것이었죠. 준비한 일정에 맞추어 대진 결과를 슬랙에 공개하기 시작했습니다.

사람들의 뜨거운 반응(?)

대진표와 함께 생존자들의 명단(?)이 점점 줄어드는 것이 보이자 참여자들의 긴장감이 고조되는 게 느껴지더라고요. 저희는 주접과 호들갑을 많이 떨어달라 고 부탁하며 축제 분위기를 더했습니다.

매일 업데이트된 대진표

64강, 32강, 16강이 진행되는 동안은 매일 대진표를 업데이트하고, AI가 제공한 결과를 노션에 옮겨두는 작업을 반복했습니다. 다행히 하루 5~10분 정도의 반복 작업으로 마칠 수 있었죠.

승부 예측 이벤트

승부 예측 이벤트

8강부터는 라이브 행사로 대결을 진행하기로 했기에 승부 예측 이벤트도 기획했습니다. 토너먼트에 직접 참여하지 않거나 일찍 탈락한 분들도 시간이 흐를수록 치열해지는 승부를 재미있게 관람했으면 하는 바람에서였습니다.

승부 예측의 참여 대상과 방법에 대해서도 희선님과 많은 논의를 거쳤습니다. 최종적으로 8강 대진 승부 예측 및 우승자 예측을 사전에 미리 받아서 그 결과에 따라 점수를 준 뒤 순위를 매기기로 결정했습니다. 희선님께서 사전에 구글 폼으로 설문을 받고, 설문 결과를 바탕으로 승부 예측 점수를 계산하는 스프레드시트를 작성해 주셔서 이벤트를 쉽게 진행할 수 있었습니다.

라이브 행사

행사 직전 희선님과

어느덧 16강 결과까지 발표가 된 후, 저는 희선님과 오프라인에서 만나 8강 라이브 이벤트를 준비했습니다. 행사 30분 전부터 게더타운으로 방송 세팅을 시작했고, 어떤 방식으로 진행할지 논의했죠.

사실 금요일 밤이라 혹시나 관람자가 적을까 봐 걱정했지만, 시간이 흐르자 20명 가까이 되는 분들이 참석해 자리를 빛내주셨습니다. 사람들이 하나둘 들어오는 것을 보니 긴장되고 목이 타더라고요.

방송 시작 후에는 행사 소개와 함께 프롬프트 공유를 마친 후 본격적으로 대결을 시작했습니다. 제가 화면 공유를 통해 실시간 대전 결과를 방송으로 공유하는 동안, 희선님이 옆에서 다음 대결에 필요한 프롬프트를 미리 만들어 주셔서 꽤나 수월하게 진행할 수 있었습니다.

?? 아니 원래 안 그랬잖아요

하지만 예상치 못한 변수가 발생했습니다. 라이브 행사 진행 도중 Gemini가 갑자기 크롤링을 하지 못하는 사태가 벌어진 것입니다. 글 링크를 입력했는데도 내용을 읽어오지 못하고 대결을 진행할 수 없다는 메시지를 뱉어냈죠. 행사 처음부터 문제가 생겼다면 그러려니 했겠지만, 이전 대결에서는 아무 문제 없이 잘 진행되었거든요.

그래서 처음에는 일시적인 오류라고 생각했지만, 몇 번을 시도해도 똑같은 문제가 발생하는 상황이 이어졌습니다. 결국 대회가 잠시 중단되는 사태가 발생했습니다. 정확한 원인은 알 수 없었지만, 짧은 시간 내에 크롤링 요청을 너무 많이 호출해서 문제가 생긴 것 같았습니다. 수십 명이 라이브로 지켜보는 상황에서 대회가 갑자기 중단되니 상당히(…) 곤혹스럽더라구요. 리허설은 물론 이전에는 전혀 없었던 일이었습니다.

결국 대회가 중단된 상황을 설명하고, 남은 대결을 진행할 수 있는 다른 AI 모델을 찾아보기로 했습니다. 그렇게 ChatGPT를 이용해 나머지 대결을 진행하기로 결정했죠.

아쉽게도 구독 중인 ChatGPT는 유료 모델이 아니어서 추론 과정을 볼 수는 없었고, 단순 결과물만 받아볼 수 있었습니다. 라이브가 끝날 때까지 Gemini는 여전히 외부 글을 읽어오지 못했습니다.

라이브 행사를 마무리하며

예상치 못한 방송 사고(?)가 있었지만, 다행히 많은 분들의 응원 덕분에 무사히 라이브 행사를 마무리할 수 있었습니다. 특히 실시간으로 올라오는 댓글들을 확인하는 게 진행하는 입장에서 재미있는 포인트였습니다. 댓글들은 나중에도 다시 읽어보고 싶어서 모든 내용을 저장해 두었죠.

1시간 반 정도에 걸친 라이브 방송을 마치고, 희선님과는 서로 진짜 고생 많으셨다 며 응원과 감사의 인사를 나눴습니다. 몸과 정신은 힘들었지만, 많은 분들께 즐거움을 드릴 수 있었다는 점에서 뿌듯함이 느껴졌습니다. 라이브에 참여하셨던 성윤님께서도 나중에 고생 많았다며 따로 선물까지 챙겨주셔서 정말 감사했습니다.

최종 우승자 공지

치열한 경쟁을 뚫은 최종 우승자 공지

행사가 끝난 후에는 최종 대진표를 업데이트하고 각 토너먼트의 우승자를 공식적으로 발표했습니다. 그리고 축하의 인사와 함께 상품도 전달해 드렸습니다.

수상자 분들이 소감도 남겨주셨다

우승자분들께는 축하의 인사와 함께 상품을 전달해 드렸고, 감사하게도 우승 소감도 남겨주셨습니다. 또한, 라이브 방송 시 진행했던 대결 결과물까지 대시보드에 모두 업데이트하면서 글드컵의 모든 일정을 성공적으로 마무리했습니다.

후기

행사의 진행

글드컵은 모든 과정이 온라인으로 이루어졌지만 준비 기간을 포함해 2명이서 약 한 달 동안 준비한 꽤나 큼지막한 행사였습니다. 그래서인지 준비 과정이 힘들기도 했지만 그만큼 느낀 점도 많았습니다.

우선은 제가 떠올린 엉뚱한(?) 아이디어를 실제로 구체화하고 성공적으로 실행에 옮길 수 있었다는 점에서 큰 뿌듯함을 느낍니다. 특히 제가 아끼고 애정하는 커뮤니티의 마무리를 기념하는 행사가 되었다는 점, 그리고 시간이 갈수록 경쟁이 치열해지면서 많은 분들이 흥미진진하게 지켜봐 주셨다는 점, 긴장감 넘치면서도 즐거운 대결 경험을 제공할 수 있었다는 점이 기억에 남습니다.

다만, ‘한 번 쓰고 말 것’ 이라는 생각으로 진행하다 보니 많은 작업들을 수동으로 처리하게 됐는데, 그것들이 생각보다 손이 많이 갔다는 점은 아쉬운 포인트로 남습니다. 물론 필요했다면 이런 작업들을 자동화할 수도 있었겠지만, 일회용 코드를 짜는 것도 귀찮아서 그렇게 하지 않았죠. 만약 대회 템플릿 자체를 자동화 할 수 있었더라면, 이런 대회를 더 자주, 더 쉽게 열 수 있을 것이라는 생각이 듭니다. 예를 들자면 매 제출 회차마다 토너먼트 대결을 진행하는 식으로요.

기술적으로는 AI를 이렇게까지 행사에 실용적으로 활용할 수 있다는 것을 직접 경험하며 크게 느꼈습니다. 포스터 제작부터 홍보 문구 제작, 나아가 기획, 디자인, 개발 전반에 걸쳐 AI가 얼마나 큰 도움을 줄 수 있는지 확인하는 계기가 되었습니다. 이는 우리 일상과 업무에 AI가 어떻게 활용될 수 있는지에 대한 좋은 사례가 되었다고 생각합니다. 사실 애초에 AI가 없었다면 이 행사의 진행이 불가능하기도 했구요.

이렇게 해서 AI와 함께한 글쓰기 토너먼트 대회, 글드컵의 준비 과정과 진행 후기를 마치고자 합니다. 이번 행사의 진행과 기획을 함께 도와주신 희선님께 특히나 더더욱 감사하다는 말씀을 전하면서 글을 마무리하겠습니다.

나의 청춘을 함께한 커뮤니티, 글또를 졸업합니다

Sun, 11 May 2025 00:00:00 GMT

글또와 함께 성장한 내가 주요 글감이 될 거라 히로시의 회상을 BGM으로…

2019년부터 함께 했던 글 쓰는 개발자 커뮤니티 글또가 올해 3월, 10기를 마지막으로 공식적인 활동을 마무리했습니다. 햇수로 7년이라는 시간, 제 개발 인생의 거의 90%를 함께했으니 꽤 오랜 시간 이라는 말로는 부족할 만큼 깊은 인연이었죠.

글또가 10기로 종료된다는 소식은 이미 공공연히 알려져 있었기에 막상 끝났을 때 감정의 동요가 크지는 않았습니다. 하지만 오랜 시간 정들었던 학교를 졸업하는 것처럼 시원섭섭한 마음이 드는 것은 어쩔 수 없더군요.

돌이켜보면 처음 글또에 참여했을 때 남다른 마음가짐이 있었습니다. 나와 비슷한 관심사를 가진 사람들을 만난다는 호기심, 누군가 나의 글을 읽고 알아봐 줬으면 좋겠다는 기대감, 이직한 회사에서 인정받고 싶다는 욕심, 당장 한 사람의 몫을 해내고 싶다는 절박함…

이런 노력이 반드시 성공적인 커리어로 이어질 것이라는 강한 믿음으로 자기소개를 했던 때가 엊그제 같은데, 시간이 흘러 이제는 사회에서 어느 정도 자리도 잡았고 한 분야의 엔지니어로 인정받게 된 지금, 그때의 간절함이 떠올라 감회가 새롭네요.

글또를 한 마디로 정의하라면 정말 많은 생각들이 떠오릅니다. 나의 꿈, 나의 커리어, 나의 성장, 나의 열정, 나의 러닝 메이트, 나의 20대… 이것들을 한꺼번에 담을 수 있는 단어로 표현하자면 나의 청춘 이라고 말할 수 있겠네요.

지금의 저를 만드는 데 큰 영향을 준 글또의 마무리를 기념하고, 함께했던 소중한 추억을 발판 삼아 앞으로의 계획을 세우기 위해 이번 회고를 시작합니다. 이 글이 저처럼 글 쓰는 개발자 커뮤니티 글또를 궁금해하셨던 분 들께 도움이 되기를 바랍니다.

글또에 참여하게 된 계기

혼자는 외로워

저는 개발 블로그를 시작하면서부터 함께 글 쓰는 커뮤니티 에 대한 막연한 갈증을 느끼고 있었습니다.

2018년 7월, 처음 기술 블로그를 개설하고 1년간 16개의 글을 꾸준히 발행했습니다. 내용을 잘 정리한 덕분에 포트폴리오의 역할도 겸했고 이직 과정에서 도움을 받기도 했으니, 분명 블로그 활동은 저에게 긍정적인 경험이었죠.

하지만 글을 쓰는 과정은 늘 외로웠습니다. 방구석이나 집 근처 카페에 틀어박혀 밤늦도록 씨름한 끝에 글 하나를 완성하고 발행 버튼을 눌러도, 마치 메아리 없는 외침처럼 아무런 반응이나 피드백이 없는 경우가 대부분이었죠. 내 경험과 시간을 담아 힘들게 쓴 글이 그저 인터넷 세상 어딘가에 떠다니는 데이터 쪼가리(?)처럼 느껴질 때가 많았습니다.

그러다 보니 ‘나처럼 꾸준히 기술 블로그를 쓰는 사람이 또 있을까?’, ‘이런 사람들이 모여 서로 격려하고 피드백을 주고받으며 함께 성장하는 모임은 없을까?’ 이런 고민들이 머릿속을 맴돌았습니다. 점점 지쳐가던 저는 자연스레 개발자들이 모여 글을 쓰는 커뮤니티를 찾아 나서기 시작했습니다.

그러던 중 우연히 페이스북 그룹을 통해 글또라는 커뮤니티의 존재를 알게 되었습니다. 당시에는 이미 진행 중인 기수가 있어서 당장 참여할 수는 없었지만, 글또 그룹에 제가 쓴 글들을 공유하며 다음 기수가 열리기만을 손꼽아 기다렸습니다. 이것이 제가 글또와 인연을 맺게 된 첫걸음이었죠.

글또 3기 - 첫 만남

2019년 9월, 역삼 자취방 근처의 북카페에서

그렇게 저는 2019년 7월부터 12월까지 글또 3기 멤버로 정식 활동을 시작했습니다. 글또 합류를 간절히 기다렸던 만큼 기대가 컸던 시기였죠.

글또의 운영자이신 성윤님께서는 첫 제출 글은 다짐글을 권장하셨고, 이에 따라 저는 지난 1년간의 기술 블로그 활동을 돌아보는 『개발 블로그 1년 째, 나는 어떻게 바뀌었을까』 글을 첫 글또 글로 제출했습니다. 그리고 6개월의 활동 기간 동안 저는 총 11개의 글을 작성하며 꾸준히 기록을 이어나갔습니다.

3기 때 썼던 글은 회사에서 새롭게 배운 지식 과 사이드 프로젝트 위주로 작성했습니다. IT 산업기능요원으로 두 번째 회사에 이직한 지 얼마 되지 않았을 때였거든요. 새로운 환경에서 배울 것들이 정말 많았고, 야근도 잦았지만 신기하게도 개발에 대한 열정과 체력이 넘쳐나던 시기였습니다. 그때의 저는 팔팔한 스물네 살이었거든요… 😇

물론 힘들고 지친 날도 있었지만, 회사에서의 동료들이 기술 블로그를 운영하는 저를 많이 응원하고 격려해 주셔서 더욱 힘이 났던 것 같습니다. 그 덕분에 글을 쓰고 공유하는 것이 즐거웠던 기억이 나네요.

3기 활동을 하면서 기억나는 에피소드들을 잠깐 소개해보자면요.

처음으로 오프라인 모임에 참여해 봤습니다. 내향적인 성격이었던 제가 큰 용기를 낸 것이었죠. 온라인으로만 소통하던 분들을 실제로 만나 함께 이야기 나누고 서로의 글에 대해 피드백했던 시간이 제게 큰 동기 부여가 되었습니다. 멋진 회사에 다니는 분들이 많아서 ‘나도 언젠가는 저런 회사에 갈 수 있을까?’ 하고 내심 부러워했던 기억이 나네요.

사이드 프로젝트를 2개 진행했습니다. 하나는 Vue.js 기반의 크롬 확장 프로그램을 만든 것, 나머지는 곽철용 짤 생성기 입니다. 곽철용 짤 생성기는 아직까지 제 깃허브의 리포지토리 스타 수 1위를 기록하고 있습니다. 😎

기수 중간에 훈련소를 다녀왔습니다. 그 후기도 블로그에 올려두었죠. 성윤님께 미리 말씀드려 제출 패스를 예약하고 다녀왔지만, 훈련 후 돌아와서 다음 회차 글을 도저히 쓸 엄두가 나지 않아서 눈물을 머금고 미제출을 했던 쓰린 기억이 나네요.

글또 활동 범위를 넘어선 외부 멘토링 경험을 처음 해보기도 했습니다.

글또 4기 - 책 집필 도전

2020년 4월, 역삼 자취방 근처의 스타벅스에서

글또 3기를 성공적으로 마무리하며 글쓰기의 즐거움과 커뮤니티의 가치를 깊이 느꼈기에, 2020년 3월부터 8월까지 이어지는 글또 4기에도 참여를 결정했습니다.

가장 큰 이유는 글또가 제가 찾던 글쓰기 자체에 온전히 집중할 수 있는 최적의 환경이라고 판단했기 때문입니다. 글쓰기를 위한 기본적인 규칙은 제공하지만 적극적인 오프라인 모임 참여가 필수가 아닌 점이, 저에게는 부담 없이 몰입할 수 있는 환경으로 다가왔거든요.

4기 동안 저는 총 10개의 글을 작성했습니다. 하지만 3기 때와는 달리 글감을 미리 충분히 확보해두지 못해, 마감일이 다가올 때마다 소재를 짜내느라 유독 힘들었던 기억이 강하게 남아 있습니다. 때마침 코로나19로 인한 팬데믹이 시작되어 모두가 혼란스럽고 오프라인 활동이 어려워지면서 외부 경험을 통해 새로운 글감을 얻는 것도 쉽지 않았던 시기였죠.

이때도 글쓰기 자체에 대한 열정은 있었지만, 무엇을 쓸까 가 큰 숙제였습니다. 이러한 어려움 속에서 창의적인 소재를 찾기 위해 여러 시도를 해보았고, 그래서인지 4기 때 작성한 글들은 적극적인 오픈소스 활동 경험, 새롭게 등장하는 기술 트렌드 분석, 그리고 독창적인 비유를 활용하는 시도가 돋보이는 글들이 많았습니다. 가장 대표적인 글로 『JavaScript 번들러로 본 조선시대 붕당의 이해』 가 있죠.

4기 활동을 하면서 기억나는 에피소드들을 잠깐 소개해보자면요.

2년 간의 IT 산업기능요원 복무를 성공적으로 마무리했습니다.

글또를 함께한 찬규님의 제안으로 개발자로서의 성장 과정을 에세이로 집필하는 프로젝트를 시작했습니다. 출판이라는 거대한 프로젝트는 혼자서는 엄두도 못 냈을 일이었지만 글또라는 커뮤니티의 다른 분들과 함께했기에 용기를 낼 수 있었습니다.

당시 글또 4기를 함께 하고 있던 수빈님과 같은 팀으로 일했던 경험이 있습니다.

글또 5기 - 이직과 복학

2020년 11월, 해변이 보이는 강릉의 한 카페에서

글또 5기는 2020년 11월부터 2021년 5월까지 활동했습니다. 이 시기는 제 인생에서 두 가지 큰 변화가 동시에 일어났던 때입니다. 바로 반려동물 모니터링 서비스를 개발하는 스타트업으로의 이직과 대학교 복학이었죠.

저는 인원이 한 자리 수 규모인 작은 스타트업에 합류하게 되었고, 상대적으로 시니어(?) 개발자가 되었기에 할 수 있는 일들이 정말 많았고 그만큼 책임감도 컸습니다. 동시에 학교에서는 이전과는 다른 새로운 CS 지식들을 배우며 개발 역량을 넓혀갔습니다. 이렇게 새로운 회사와 학교를 병행하는 정신없이 바쁜 와중에도 글또 활동을 꾸준히 이어가며 총 11개의 글을 작성했습니다.

이때 쓴 글들은 주로 새로운 스타트업 환경에서의 경험과 도메인 지식, 그리고 복학 후 학교에서 배운 CS 지식을 다루는 내용이었습니다. 특히 『스타트업에서 조직 문화를 만들어나간다는 것』 이라는 글은 당시 제가 회사에서 느끼고 고민했던 바를 잘 담고 있어 기억에 남습니다. 이 시기는 코로나19가 여전히 극성이었고, 학교 복학으로 인해 다른 글또 멤버들과의 오프라인 커피챗 등은 이전보다 많이 하지 못했습니다.

5기 활동 중 기억나는 에피소드들을 몇 가지 소개해보자면요.

친구와 함께 강릉으로 여행을 가기로 했는데 당일에 친구가 몸이 안 좋다는 이유로 홀로 여행을 떠나게 되었습니다. 혹시 몰라 노트북을 챙겨 온 덕분에 카페에서 글또 제출 글을 썼던 경험이 있습니다. 여행지에서 노트북을 펴고 글쓰기에 집중했던 특별한 추억입니다.

복학 후에는 글또 마감일이 시험 기간과 겹칠 때가 있었습니다. 시험공부를 해야 하는 와중에 글까지 써야 해서 유독 힘들었던 기억이 나네요.

글또 6기 - 취준생

2021년 9월, 부산 본가 근처의 한 카페에서

글또 6기는 2021년 8월부터 2022년 1월까지 활동했습니다. 이 시기는 제 인생에서 취준생 이라는 타이틀을 달고 모든 에너지를 한 곳에 쏟아부었던 때입니다. 6월부터는 일과 학업 병행의 어려움으로 퇴사를 결정하고, 오롯이 취업 준비에만 몰두하기 시작했기 때문입니다.

취업이라는 명확한 목표가 생긴 만큼, 글쓰기의 방향도 자연스럽게 바뀌었습니다. 대부분의 시간을 CS 지식과 코딩 테스트 공부에 할애하며 글또에도 이와 관련된 내용들을 많이 공유했습니다.

이 시기 동안 총 10개의 글을 작성했고, 그중 『레스토랑에 비유해서 알아보는 운영체제』 와 같은 글들이 대표적입니다. 당시 저는 코로나19로 인한 팬데믹 상황이 여전했던 시기에 부산 본가에 머무르며 공부하고 있었기에, 글또 멤버들과의 오프라인 커피챗 등은 이전보다 더욱 활발하게 하지 못했던 것으로 기억합니다.

6기 활동 중 기억나는 에피소드들을 몇 가지 소개해보자면요.

이전에 같은 회사를 다녔던 찬주님께 글또를 소개해드리고 초대했습니다.

글또 4기 때부터 집필을 시작했던 책이 드디어 출간되었습니다! 책이 나왔다는 핑계로 오랜만에 많은 분들을 만나 인사를 드리고 직접 책을 선물하며 기쁨을 나눴습니다.

오랫동안 준비했던 네이버 공채에 최종 합격했다는 소식을 듣고 뛸 듯이 기뻤던 기억이 가장 강렬하게 남아 있습니다.

글또 6기가 끝난 이후에는 블로그를 Jekyll에서 Gatsby로 마이그레이션 하는 프로젝트를 진행했습니다. 공부를 겸하며 진행한 프로젝트라 개발 과정에서 많이 헤맨 기억이 나네요.

글또 7기 - 운영진 시작

2022년 8월, 컬리 본사에서 글또콘 진행할 때

글또 7기는 2022년 5월부터 10월까지 진행되었습니다. 이 시기는 제가 대학교 4학년 마지막 학기를 보내고, 곧이어 네이버에 입사하며 사회생활의 다음 단계를 준비하던 중요한 전환기였습니다.

7기부터는 운영진에 참여하게 되었습니다. 6기가 끝난 후 성윤님께서 직접 운영진 모집 글을 올리셨는데, 4년간 글또에 참여하며 글쓰기 습관과 기본기를 쌓아왔기에 이제는 커뮤니티에 본격적으로 기여하고 싶다는 마음이 들었습니다. 이 커뮤니티에 제가 받은 만큼 보답할 수 있는 가장 좋은 방법이 운영진이라고 생각했죠.

7기 동안 저는 총 10개의 글을 작성했습니다. 취업 준비 과정에서 시간 제약으로 인해 미처 깊이 다루지 못했던 CS 지식들을 정리하거나, 새로운 소재를 찾기 위해 평소 당연하게 넘겼던 개념들에 대해 파고들어 글을 쓰는 경우가 많았습니다. 글쓰기 자체에 대한 자신감이 있었던 시기였기에, 7기 활동 중에는 『기술 글쓰기를 통해 개인 브랜딩을 구축하는 나만의 방법』이라는 글을 쓰기도 했습니다.

7기 활동 및 운영진으로서 기억나는 에피소드들을 소개합니다. 이 시기부터는 코로나로 인한 제한이 점점 풀리면서 모각코와 커피챗 등 오프라인 모임에 다시금 활발하게 참여했던 기억이 납니다. 성윤님께서는 이때부터를 글또의 르네상스 시기 라고도 말씀해 주셨는데 그 시기를 운영진으로 함께 보내어서 기쁘네요.

운영진 참여를 고민하며 ‘어떤 것을 기여할 수 있을까’ 생각하다, 마침 커뮤니티 내 익명 메시지 전송 봇에 대한 수요가 있어 직접 대나무숲 슬랙 봇을 제작했습니다. 온라인 OT에서 성윤님이 봇을 소개해주셨을 때, 많은 분들이 관심을 가져주셔서 부끄럽기도 하고 기뻤던 기억이 납니다.

7기는 글또 커뮤니티의 비전을 새롭게 정의했던 시기이기도 합니다. 엄격한 기준을 세우려는 T 성향의 저와 따뜻한 마음을 강조하신 F 성향의 성윤님 사이에 의견 차이가 있었지만, 성윤님은 제 의견을 존중해 주셨습니다. 되돌아보면 성윤님의 부드러운 리더십과 따뜻한 마인드 덕분에 글또가 더 많은 멤버를 포용하며 성장할 수 있었다고 생각합니다. 한편으로 저는 리더보다는 리더를 서포트하는 역할이 더 잘 맞는다는 것을 배운 시기이기도 합니다.

글또의 첫 공식 오프라인 컨퍼런스인 글또콘이 열렸고, 당일에 행사 진행 스태프로 참여했습니다. 이때 ‘나도 언젠가 글또콘에서 발표해봐야지’ 하고 막연히 생각했던 기억이 납니다.

대학교 친구인 준호와 함께 글또 활동을 이어갔던 시기이기도 합니다.

8명 규모의 운영진이 구의에 있는 성윤님 개인 작업실에 옹기종기 모여 운영 회의를 진행했던 기억이 생생합니다. 마지막 운영진 모임 때는 성윤님께서 포르투갈에서 사 온 잼을 나눠주셨던 기억이 나네요.

글또 8기 - 자동화 크루

2023년 1월, 강남 트레바리 라운지에서 자동화 크루와 첫 만남

글또 8기는 2023년 2월부터 7월까지 진행되었습니다. 이 시기는 네이버 지식iN 팀에 입사하여 새로운 환경에 적응해 가던 중, 예상치 못하게 신규 부서로 팀을 옮기며 혼란스러움을 느끼기도 했던 때입니다. 갑작스러운 전배였지만 다행히 회사 업무가 초반에는 비교적 여유가 있었고, 덕분에 글또 활동과 커뮤니티 운영에 더 많은 에너지를 쏟을 수 있었습니다.

8기 동안 저는 총 10개의 글을 작성했습니다. 지식iN 팀에서 동영상 DRM이라는 복잡하지만 흥미로운 도메인 지식을 접하게 되었고, 이를 깊이 파고들어 정리한 글이 이 시기의 대표적인 글로 자리매김했는데, 그 글이 바로 『그 많은 OTT 콘텐츠는 어떻게 웹에서 재생될 수 있을까』입니다. 이 때는 새로운 업무 지식을 글또 제출 글로 작성하며 기록과 성장의 두 마리 토끼를 동시에 잡으려고 노력했던 기억이 나네요.

8기 활동 및 운영진으로서 기억나는 에피소드들을 소개합니다. 이 시기는 코로나 제한이 더욱 완화되면서 오프라인 커피챗 참여율이 이전 기수들에 비해 더 높아졌던 시기여서 글쓰기 외에 사람들과의 교류에서도 활력을 얻었습니다. 또한 글또 커뮤니티 자체에 많은 변화와 새로운 시도가 있었던 때입니다.

글또의 내부 구조를 재정비하며 글또 세계관을 구축했습니다. 기존 조별 활동을 위한 코어 채널 외에 같은 직무끼리 모여 소통하는 빌리지 채널을 도입했고, 이를 바탕으로 직무별 오프라인 모임인 반상회가 탄생했습니다.

글또 운영진 내에서도 역할 별로 크루를 나누게 되었고, 저는 대나무숲 슬랙 봇을 개발한 경험을 살려 자동화 크루를 이끌게 되었습니다. 이때부터 은찬님께서 또봇이라는 자동화 봇을 개발해 주신 덕분에 그동안 수동으로 처리했던 많은 운영 작업들이 자동화 및 DB화 되었으며, 이를 통해 다양한 파생 작업들이 가능해져 운영 효율이 크게 향상되었습니다.

대나무숲 서버를 호스팅 하고 있던 Heroku가 유료 플랜을 종료하면서 강제로 AWS Lambda로 마이그레이션하게 되었습니다. 이 경험은 글또 8기의 첫 제출 글의 주제로 잘 사용했죠.

글또 내에서 처음으로 스터디를 기획하고 진행했습니다. 『개발자를 위한 이력서 스터디 진행 후기』 글에도 남겼는데, 빡빡한 일정으로 힘들었지만 만족스러운 결과물을 얻을 수 있어서 개인적으로는 큰 보람을 느낄 수 있었습니다. 이 스터디 방식은 이후 글또 내에서 다양한 파생 스터디로 이어지기도 했습니다.

저는 8기의 프론트엔드 반상회 행사를 직접 기획하고 진행하면서 오프라인 행사 진행에 대한 경험치를 쌓을 수 있었습니다.

글또 9기 - 글빼미

2023년 11월, 강남 돈룩업에서 자동화 크루 시작을 기념하며

글또 9기는 2023년 11월부터 2024년 5월까지 이어졌습니다. 이 시기는 회사에서 진행하던 프로젝트가 다소 지지부진해서 개인적으로는 노잼 시기를 겪고 있었던 때입니다. 회사 업무는 기술 프로토타이핑 위주로 개발이 진행되다 보니 실제 완성된 결과물을 보지 못하는 것에 대한 아쉬움이 컸습니다.

회사 업무에서는 직접적인 글감을 얻기 어려운 상황이었기에, 9기 동안 저는 총 8개의 글을 작성했습니다. 글의 주제는 개발하면서 당연하게 여기고 놓치고 있던 기본적인 개념들을 다시 파고들어 정리하거나, 주변 동료들을 관찰하며 얻은 인사이트를 바탕으로 삼는 경우가 많았습니다. 이 시기의 대표적인 글로 『개발자가 문제 해결 과정에서 마주치는 어려움의 유형 3가지』가 있습니다.

9기 활동 및 운영진으로서 기억나는 에피소드들을 소개합니다. 운영진 활동은 8기에 이어 9기에도 자동화 크루에 속해 활동했습니다.

9기에는 운영진 규모가 기존 10명대에서 20명대로 크게 늘어났습니다. 저는 다소 보수적인 태도였는데, ‘많은 사람들이 온 만큼 끈끈한 유대가 잘 될까?’ 하는 걱정이 앞섰지만 이는 기우였습니다. 운영진에 참여하신 분들 모두 열정이 넘치는 분이셨고 크루로 역할을 잘 분배한 덕분에 운영 역시 매끄럽게 진행되었습니다. 이 경험 덕분에 이후에는 운영진 규모가 커지는 것에 대한 부담은 없었습니다.

이 과정에서 성윤님이 말씀해 주신 운영진을 참여하는 마음가짐(회사 일처럼 하지 말고 재밌게 하자 / 많은 것을 하기보다는 하나를 잘 끝내보자 / 힘들면 언제든 쉬고 돌아와도 괜찮다)을 다시금 배우며 성찰하는 계기가 되었습니다. T 성향의 제가 운영자였다면 결과 중심으로 업무를 할당했을 텐데, 성윤님의 마인드처럼 자발적인 활동은 열정 있는 사람들이 느슨하게 결합했을 때 모두가 즐겁게 참여할 수 있다는 것을 알게 되었습니다.

9기에 참여하면서 제가 이룬 성과는 제출 글 검수 자동화 도구인 글빼미를 본격적으로 개발하고 외부에 공개한 것입니다. 기존에는 글또의 최소 글자수 1000자 검수를 성윤님께서 수동으로 하고 계셨는데, 이것이 너무 비효율적이라 느껴 자동화 아이디어를 떠올렸습니다. 마침 회사에서 E2E 테스트 도구인 Playwright를 써본 경험이 있어 이를 활용해 개발했고, 8기 운영진 내부 테스트를 거쳐 사용자들이 이 결과를 어떻게 받아들일지 궁금하여 외부에 제공하기 시작한 것이 글빼미의 탄생 배경입니다.

사내 글또 멤버들을 위한 네이버만나또 라는 소모임을 운영했습니다. 같은 회사에 다니면서 글또를 하는 분들과 회사 안에서 커피챗을 할 수 있지 않을까 하는 생각에서 시작했고, 덕분에 몇몇 분들과 오프라인으로 만나 교류했습니다.

데일리 크리에이또 라는 소모임도 운영했습니다. 데일리 크리에이티브 라는 책을 매일 한 바닥씩 읽고 느낀 점을 공유하는 소모임을 시도했지만… 아쉽게도 꾸준히 진행하지 못하고 흐지부지되었습니다.

9기 프론트엔드 반상회에서는 기술 블로그를 위한 SEO 라는 주제로 오프라인 발표를 했습니다. 이를 통해 발표자, 진행자, 참여자 포지션으로 한 번씩 컨퍼런스에 참석할 수 있었습니다.

글또 10기 - 큐레이션 크루

2024년 10월, 운영진 MT를 간 대성리에서

글또의 마지막 공식 활동 기수인 10기는 2024년 9월부터 2025년 3월까지 진행되었습니다. 이 시기는 회사 업무에 아주 열정적으로 몰두하며 바쁘게 보냈던 때가 있었는가 하면, 갑작스러운 번아웃에 빠져 무기력함을 동시에 경험하기도 했던 격동의 시간이었습니다.

이러한 개인적인 상황은 글또 활동에도 영향을 미쳤습니다. 10기 동안 총 9개의 글을 작성했고, 이 시기에 작성한 글은 업무에서 얻은 지식과 감정을 정리하거나, 주변 사람들에게 조언과 도움을 경험을 위주로 작성했습니다. 대표적인 글로는 제가 직접 겪었던 번아웃을 솔직하게 풀어낸 『어느 날, 무기력이 찾아왔다』가 있습니다. 힘든 시기가 찾아왔음에도 불구하고 글 제출을 놓지 않으며 스스로를 돌아보고 기록하려 노력했습니다.

10기 활동 및 운영진으로서 기억나는 에피소드들을 소개합니다. 운영진의 규모는 30명대로 더욱 커졌고 이 덕분에 글또 내부에는 이전 기수에 없었던 수많은 시스템들이 새로 생겼던 시기입니다. 글또의 마지막을 장식하며 운영진의 일원으로서 중요한 변화와 성과를 만들어냈던 시기입니다.

운영진 조직 구조에 큰 변화가 있었습니다. 기존에는 기능 조직으로 움직였던 크루 대신 특정 목표 달성을 위한 목적 조직으로 전환을 시도했습니다. 이는 자동화 크루가 자동화 시스템 개발이라는 기능에는 충실했지만, 각자의 개발 목적이 달라 끈끈한 유대감이 부족하다는 판단 때문이었습니다.

저는 새롭게 큐레이션 크루에 합류하였습니다. 기존에 개발했던 슬랙 봇의 개발 및 유지보수도 진행하면서 2주마다 40여 개의 글을 읽고 뛰어난 글을 선정하는 큐레이션 업무도 동시에 수행하는 등 여러 역할을 병행하며 바쁜 시간을 보냈습니다.

큐레이션 크루에 합류한 이유는 9기 때 개발하고 있던 글빼미와 더 좋은 시너지를 낼 수 있는 크루라고 판단했기 때문입니다. 큐레이션은 좋은 글을 선정하는 것이 주목적이므로 좋은 글과 아쉬운 글에 대한 평가 기준을 세우는 것이 역할입니다. 이는 곧 좋지 않은 글을 판단하기 위한 글빼미의 목적과 잘 일치한다는 판단이 있었기 때문입니다.

9기부터 개발했던 글빼미에 LLM을 이용한 피드백 제공 기능을 추가한 것은 10기의 가장 큰 성과 중 하나입니다. 지훈님과 협력하여 이 기능을 구현했고, 글쓴이에게 더 풍부하고 개인화된 피드백을 제공할 수 있게 되면서 성윤님께서 오랫동안 이야기하셨던 꿈을 현실로 만들었다는 점에서 큰 보람을 느꼈습니다. 또한 LLM 피드백 강도를 설정하는 기능도 추가하며 사용자 경험을 개선하려 노력했습니다.

회사 내 글또 멤버들과의 교류가 즐거워 네이버만나또 소모임을 더욱 주도적으로 진행했습니다. 한 달에 한 번씩 정기적인 모임을 주최했고, 사내에서만 5번 이상 커피챗을 가지며 동료들과의 끈끈함을 다졌습니다.

10기 프론트엔드 반상회에는 일반 참여자로 참석하여 글또 멤버들과 교류를 이어갔습니다.

글또가 나에게 미친 영향

성공적인 커리어를 위해 어디로 가야할지 방황하던 나를 이끌어준 커뮤니티

햇수로 7년, 제 개발 인생의 대부분을 함께한 글또는 저에게 정말 많은 의미와 소중한 가치를 남겼습니다.

가장 먼저 꾸준히 글을 쓰게 만드는 강력한 동기 부여가 되어주었습니다. 보증금이라는 제도와 다른 사람과 함께 글을 쓴다는 경험이 저의 글쓰기 여정을 더 이상 외롭지 않게 만들어줬거든요. 사실 언젠가부터는 글 쓰는 행위가 익숙해지면서 글쓰기가 관성적으로 느껴지던 순간도 있었고, 제가 글을 쓰는 근본적인 태도나 마음가짐에 대해 깊이 성찰하지 못했던 점은 개인적으로 아쉬운 부분으로 남지만, 그럼에도 불구하고 글또라는 시스템 덕분에 멈추지 않고 계속 쓸 수 있었다는 것은 자명한 사실입니다.

글또는 또한 제 커리어를 한 단계 더 발전시키는 중요한 발판이 되어주었습니다. IT 산업기능요원으로 처음 복무를 시작하고 지금의 이 자리에 오기까지 글또가 제공한 함께 글쓰는 환경과 그 안에서의 경험들이 큰 도움이 되었거든요.

글또라는 환경 속에서는 저는 혼자였다면 경험하지 못했을 다양하고 값진 경험을 쌓을 수 있었습니다. 글또는 글을 제출하는 것은 물론, 다양한 사람들과의 커피챗을 통해 교류할 수 있고, 다양한 스터디와 모임이 열리고, 성장을 장려하는 여러 이벤트가 열리는 공간이었습니다. 또한 운영진으로 참여하면서 슬랙 봇 개발로 아이디어를 현실로 만들고, 반상회와 글또콘 등 여러 행사를 운영진으로서 준비하고 진행했고, 다른 멤버들의 글을 읽고 피드백하는 큐레이션 업무를 맡고, 회사 동료들과 사내 모임을 만드는 등 개발 외적으로도 정말 다양하고 의미 있는 경험을 할 수 있었죠.

무엇보다 글또를 통해 좋은 사람들을 많이 만날 수 있었습니다. 때로는 얕고 넓게, 때로는 깊고 좁게 형성된 인맥들은 제 삶의 큰 자산이 되었습니다. 모두 자신의 일과 글쓰기에 열정 넘치는 분들이었기에 그분들과 함께하는 것만으로도 저 역시 긍정적인 자극을 많이 받고 동기 부여를 이어갈 수 있었습니다.

마지막으로, 글또의 운영자이신 성윤님의 따뜻한 마음씨와 리더십에 대한 존경 입니다. 성윤님은 글또의 목적이 따뜻한 커뮤니티임을 늘 강조하셨고, 결국 사람이라는 본질을 잊지 않으셨습니다. 냉철하고 딱딱한 규칙 기반보다는 따뜻한 마음으로 사람들을 대하고, 개개인의 의사와 자율성을 존중하면서도 필요할 때는 명확한 결단력을 보여주시는 모습에서 커뮤니티 리더로서의 진정한 가치를 배울 수 있었습니다.

종종 ‘내가 성윤님의 나이였을 때 나는 어떤 생각을 하며 살고 있었는가? 라는 생각을 하곤 합니다. 사실 그때로 돌아간다고 하더라도 성윤님의 결정처럼 생각하고 행동하지 못할 것 같아서 더 존경스럽더라구요.

성윤님이 계셨기에 글또가 10기까지 이어지며 수많은 개발자들에게 긍정적인 영향을 줄 수 있었다고 생각합니다.

글또 활동을 통해 얻은 가장 큰 깨달음 중 하나는 따뜻하고 열정 있는 마음을 가진 사람들이 함께 모이면 정말 어떤 일이라도 즐겁게 해낼 수 있다는 값진 자신감입니다. 서로에게 긍정적인 영향을 주는 사람들과의 관계는 앞으로도 제 삶에 중요한 자산이 될 것입니다.

글또 이후의 나

초심을 잃지 말자

사실 7년이라는 시간 동안 꾸준히 글을 써왔지만, 아직까지도 글쓰기는 여전히 어렵다 고 느끼곤 합니다. 기술적으로 내용을 풀어내는 능력은 분명 늘었지만, 써야겠다 는 마음을 먹고 책상에 앉기는 여전히 어렵더라구요. 😓

그 원인으로는 나이가 들고 개발 외에도 신경 써야 할 일들이 많아지면서 예전만큼 글쓰기에 집중하기 어렵게 된 점도 있을 것입니다. 그럼에도 글또라는 함께 쓰는 환경 이 있었기에 그 어려움을 조금이나마 이겨내고 꾸준함을 유지할 수 있었습니다. 그리고 어렵다, 어렵다 말은 하지만 또 막상 책상에 앉으면 깊게 몰입하여 글을 쓰곤 합니다. 이는 무언가에 진정으로 몰두해서 성공을 이뤄낸 경험이 있었기 때문이겠죠.

글또의 공식 활동은 마무리되었지만, 글쓰기 습관까지 놓치는 것은 아닙니다. 앞으로는 글또의 비활동 시즌처럼 한 달에 하나 정도의 포스트를 쓰는 것을 목표로 삼으려 합니다. 회사 업무가 바쁘다는 핑계로, 7년이라는 시간 동안 저를 성장시키고 지금의 저를 있게 만든 소중한 글쓰기 습관을 소홀히 하지 않겠다는 다짐입니다.

지금은 글또 내에서 공식 활동 마무리를 기념하는 행사를 기획하여 진행 중입니다. 이 마무리 행사와 관련된 후기 글도 작성해 볼 예정이구요. 시간적 여유에 쫓겨 작성하지 못했던 몇 가지 기술 주제들도 올해가 가기 전까지는 작성할 예정입니다. 또한, 글또를 통해 만난 소중한 인연들, 특히 마지막 10기를 함께 했던 분들과는 앞으로도 꾸준히 교류를 이어갈 계획입니다.

마무리

저 글또에서 졸업합니다!

글또를 함께한 은찬님께서는 글또를 1단 로켓에 비유한 회고글을 작성해주셨습니다. 이 비유를 보자마자 참 멋있는 말이라는 생각이 들었는데요. 1단 로켓은 비록 제 역할을 다한 후 분리되지만 그 덕분에 2단, 3단 로켓이 더 높이 날아갈 수 있는 것처럼 글또는 많은 사람들이 더 넓은 세상으로 나아갈 발판이 되는 커뮤니티라고 생각이 들었기 때문입니다. 이것보다 더 찰떡같은 비유는 없는 듯 해서 한 번 인용해보고 싶었어요.

저는 이제 글또로부터 졸업한다고 생각합니다. 마치 학교를 졸업하는 학생처럼 아쉬운 마음이 들기도 하지만, 어둡고 불확실했던 나의 커리어를 비추어주고 혼자서도 잘 나아갈 수 있을 만큼 나를 성장시켜 준 것에 대해 고맙고 후련한 마음도 듭니다. 7년이라는 시간 동안 제 성장의 가장 든든한 동반자였던 글또와, 그 안에서 함께했던 모든 분들께 진심으로 감사드립니다.

글또는 이제 공식적인 활동을 마무리하지만, 글또를 통해 얻은 수많은 경험과 소중한 인연들은 제 개발 인생과 삶 속에 계속 남아 빛을 발할 것입니다. 저의 20대 청춘과도 같았던 글또에게 다시 한번 감사하다는 말을 전하며 글을 마무리합니다.

오래 준비한 완성을 축하하고, 오늘의 새로운 시작을 축하합니다. 서로에게, 그리고 자신에게 친절하시길. 그리고 그 친절을 먼 미래의 우리에게 잘 전달해주시길 바랍니다. 응원합니다. 축하합니다.

- 허준이 교수의 졸업식 축사

참고 자료

글또 1~10기. 7년의 커뮤니티 운영 회고

1단 로켓을 분리합니다. 굿바이 글또!

안드로이드 크롬에서 CSS vh 단위가 이상하게 동작했던 이유

Sun, 02 Mar 2025 00:00:00 GMT

작년에 회사에서 QA를 진행하다가 이상한 버그를 발견했습니다. 구형 안드로이드 기기에서 가상 키보드가 올라오면 CSS 단위인 vh 값이 예상과 다르게 동작하고 있었던 것이죠. 그런데 비교적 최신 기기였던 제 스마트폰에서는 정상적으로 동작하더군요.

두 스마트폰에서 다른 부분이 보이시나요?

이상하다 싶어서 원인을 찾아보니, 안드로이드 크롬 108 버전부터 브라우저가 레이아웃 표시 영역을 계산하는 방식이 바뀌었기 때문이었습니다. 제 스마트폰은 크롬 108 이상이었기 때문에 정상 동작했던 것이었죠.

솔직히 이런 변경 사항이 있었던 걸 몰랐다는 점이 꽤 충격(?)이었는데요. 그래서 이번 기회에 레이아웃 표시 영역이란 무엇인지, 그리고 크롬 108부터 기본 동작이 왜 변경되었는지 정리해 보려고 합니다.

이번 포스트를 통해 안드로이드 크롬에서 뷰포트 관련 문제를 겪고 있는 개발자 분들에게 도움이 되었으면 좋겠습니다.

문제 상황 살펴보기

좌측은 크롬 버전 103, 우측은 크롬 버전 123

처음에 나온 영상을 자세히 살펴보면 두 스마트폰에서 다른 부분을 찾을 수 있습니다.

첫 번째는 바로 document 의 높이입니다. 좌측은 가상 키보드가 올라오면 높이가 줄어드는 반면, 우측은 가상 키보드가 올라와도 높이가 그대로 유지되고 있습니다.

두 문제의 정답은

두 번째는 바로 input 의 위치입니다. 이 인풋은 top: 20vh 스타일을 갖고 있는데요. 좌측은 가상 키보드가 올라오면 인풋의 위치가 올라가는 반면, 우측은 가상 키보드가 올라와도 인풋 위치가 그대로 유지됩니다. 이를 통해 vh 단위가 두 스마트폰에서 다르게 동작하고 있다는 것을 알 수 있습니다.

이러한 차이점이 왜 발생하는지 이해하기 위해서는, 먼저 레이아웃 뷰포트와 시각적 뷰포트의 개념을 알아야 합니다.

레이아웃 뷰포트와 시각적 뷰포트

레이아웃 뷰포트를 파란 영역으로 나타냈다

레이아웃 뷰포트(layout viewport) 란 브라우저에 화면이 나타내는 영역을 의미합니다. 만약 우리가 접속한 웹 페이지에 스크롤이 있다면, 우리는 레이아웃 뷰포트 영역만큼을 화면에서 볼 수 있게 됩니다.

레이아웃 뷰포트는 position: fixed 스타일을 갖는 요소에 영향을 줍니다. 화면에 고정된 위치를 지정하는 fixed 스타일은 레이아웃 뷰포트를 기준으로 계산되기 때문에, 레이아웃 뷰포트의 크기가 변하면 fixed 스타일을 갖는 요소의 위치도 변하게 되죠.

브라우저 주소창, 가상 키보드, 핀치 줌을 이용해 레이아웃 뷰포트의 크기를 변경시켜 보았다

반면 시각적 뷰포트(visual viewport) 란 사용자가 지금 실제로 보고 있는 화면의 영역을 의미합니다. 브라우저의 주소창, 가상 키보드의 영역, 핀치 줌을 이용한 화면 확대 등 다양한 요소로 인해 레이아웃 뷰포트와 눈에 보이는 영역이 서로 다를 수 있기 때문입니다.

위 영상을 보시면 이해가 빠르실 것 같은데요, 화면에 나타나는 Visual Viewport 영역의 값 변화를 살펴보시면 됩니다.

OS와 브라우저에 따라 달라지는 동작

이렇게 해서 레이아웃 뷰포트와 시각적 뷰포트의 차이점을 알아봤습니다. 그리고 모바일 브라우저에서 가상 키보드가 올라오는 것이 시각적 뷰포트의 크기를 변경시킨다는 것도 알게 되었죠.

여기서 모바일 브라우저는 가상 키보드가 올라올 때 세 가지의 방법으로 레이아웃 뷰포트와 시각적 뷰포트를 계산할 수 있습니다. 여기서 문제가 발생하죠. 바로 OS와 브라우저의 조합에 따라 동작이 서로 달라진다는 것입니다.

브라우저 별 레이아웃 뷰포트와 시각적 뷰포트의 변경

resize-visual 방식

레이아웃 뷰포트는 변경되지 않고 시각적 뷰포트만 변경

iOS 크롬, iOS 사파리, iOS 엣지, iPad 크롬, iPad 사파리, iPad 엣지, ChromeOS 크롬

resizes-content 방식

레이아웃 뷰포트와 시각적 뷰포트 모두 변경

안드로이드 크롬 (108 버전 이전까지), 안드로이드 파이어폭스, 안드로이드 엣지

overlays-content 방식

레이아웃 뷰포트와 시각적 뷰포트 모두 변경하지 않음

해당 방식으로 동작하는 브라우저 없음

이런 차이로 인해 가상 키보드가 올라올 때 안드로이드 크롬과 iOS 크롬에서 서로 다른 동작을 하는 문제가 발생합니다.

iOS 크롬에서는 vh 단위가 유지되는 반면 안드로이드 크롬에서는 vh 단위가 변경됨

position: fixed 스타일을 갖는 요소의 위치가 iOS 크롬에서는 유지되는 반면, 안드로이드 크롬에서는 변경됨

이를 올바르게 해결하기 위해서는 사용자 에이전트를 읽어와서 JavaScript로 레이아웃 뷰포트와 시각적 뷰포트의 크기를 직접 계산해야 하는데, 개발자 입장에서는 여간 번거로운 일이 아니었죠.

안드로이드 크롬 108 버전부터 기본 동작 변경

이처럼 동일한 코드가 OS에 따라 서로 다르게 동작하는 문제가 있었기 때문에, 안드로이드 크롬 108 버전부터는 iOS의 동작 형태를 그대로 따라가도록 수정되었습니다. 즉 눈에 보이는 화면 크기가 줄더라도 레이아웃 영역 계산에 영향을 주지 않게 되었습니다. 이로 인해 다른 브라우저와의 동작 차이를 줄이고, vh 와 같은 뷰포트 단위의 동작을 일관되게 사용할 수 있게 되었죠.

만약 108 버전 이후의 안드로이드 크롬에서 기존의 동작을 유지하고 싶다면 다음과 같은 메타 태그를 사용하면 됩니다. interactive-widget 속성에 원하는 동작을 지정해주면 되죠.

<meta
  name="viewport"
  content="width=device-width, initial-scale=1.0, interactive-widget=resizes-content"
/>

새로운 뷰포트 단위의 탄생

이렇게 해서 안드로이드 크롬 108 버전부터 레이아웃 표시 영역의 기본 동작이 변경되었다는 소식을 전해드렸는데요. 마침 해당 버전에 뷰포트와 관련된 새로운 기능이 추가되어서 이를 함께 소개해 드리려고 합니다.

모바일 브라우저의 주소창과 탭 바의 유무에 따라 100vh 의 크기는 정확히 화면과 일치하지 않는다

모바일 브라우저에서는 주소창과 탭 바 등의 요소가 화면의 일부를 차지하게 되는데요. 이러한 요소들이 화면의 일부를 차지하게 되면 100vh 단위로 높이를 지정했을 때, 화면의 높이와 일치하지 않는 문제가 발생합니다.

특히 모바일 크롬을 예시로 들면… 화면을 아래로 스크롤하면 주소창이 사라지고, 가상 키보드가 올라오면 주소창이 다시 나타나는 것이 기본 동작입니다. 이러한 동작으로 인해 vh 단위로 스타일을 지정한 요소가 원하는 위치에 나타나지 않는 문제가 발생하는데, 이걸 고쳐 달라는 요청을 들으면 참 난감했거든요.

이로 인해 등장한 단위, dvh lvh svh

이러한 문제를 해결하기 위해 새로운 뷰포트 단위가 등장했습니다. 바로 dv*, lv*, sv* 단위인데요. 이 단위들은 뷰포트의 크기를 기준으로 계산되는데, 각각 다음과 같은 특징을 갖고 있습니다.

dv*: 현재 레이아웃 뷰포트의 크기를 기준으로 계산

lv*: 가장 큰 레이아웃 뷰포트의 크기를 기준으로 계산

sv*: 가장 작은 레이아웃 뷰포트의 크기를 기준으로 계산

이러한 접두어는 vw, vh, vmin, vmax 와 같은 뷰포트 단위와 함께 조합하여 사용할 수 있으며, 레이아웃 뷰포트의 크기에 따라 동적으로 변하는 뷰포트 단위를 사용할 수 있게 되었습니다.

브라우저 지원 범위

브라우저 지원 범위가 94%로 높긴 하지만 구형 브라우저에서는 지원이 되지 않기 때문에 조심해야 한다는 점을 강조하면서 이번 내용을 정리할 수 있을 것 같네요.

마무리

이렇게 해서 이번 포스트에서는 레이아웃 표시 영역이란 무엇인지, 그리고 크롬 108부터 기본 동작이 왜 변경되었는지를 정리해 보았습니다.

저는 위 내용을 팀에 공유했고, 안드로이드 크롬의 버전이 108 이상인지 미만인지에 따라 로직을 분리하는 방식으로 QA에 제보된 문제를 해결할 수 있었습니다.

혹시라도 여러분이 웹 개발 도중 구형 안드로이드 기기의 크롬에서만 뷰포트 관련 문제가 발생한다면, 이를 근거로 문제의 원인을 찾아보세요.

참고 링크

Interop 2022 Viewport - Layout Viewport

Android용 Chrome에 적용될 표시 영역 크기 조절 동작 변경사항에 대비하기

Viewport Resize Behavior

어느 날, 무기력이 찾아왔다

Sun, 16 Feb 2025 00:00:00 GMT

1월 중순, 저는 새로운 기능을 구현하기 위해 팀원들과 스펙 회의를 진행했습니다. 그런데… 회의를 진행할수록 의욕이 떨어진다는 느낌을 받았습니다. 마치 넘어야 할 산이 끊임없이 나타난다는 느낌을 받았습니다. 가슴이 답답했고 무기력감이 몰려왔습니다.

마치 시지프스가 된 기분

작년까지만 해도 어렵고 도전적인 업무를 도맡아 했던 저였기에 이런 감정이 낯설고 당황스럽게 느껴졌습니다. 흔히 말하는 번아웃 이 온 건가 싶더라구요. 그리고 작년 동료 평가에서 ”번아웃이 걱정 된다” 는 피드백을 들었던 것도 생각이 났습니다.

지금은 2월 중순이 되었고 당시의 감정은 어느 정도 추스렀습니다만, 이런 감정이 생긴 이유를 분석하고 싶었습니다. 그래서 오늘은 당시의 경험을 돌아보고 번아웃을 맞이한 이유와 해결책을 고민하는 과정을 정리해보려 합니다.

이번 포스트를 통해 번아웃을 맞이하는 저만의 이유 분석과 해결책을 고민하는 과정 이 궁금하신 분들에게 도움이 되었으면 좋겠습니다.

요약

세 가지의 키워드로 그 이유를 정리할 수 있을 것 같습니다.

1월의 우울: 환경적 요인

깊은 몰입과 잦은 상황 변화: 개인 성향적 요인

보물섬 찾기와 배 만들기: 조직적 요인

1월의 우울

기쁨이기도 하지만 걱정이기도 한 새해

첫 번째는 환경적 요인, 1월의 우울증입니다. 작년 1월에도 비슷한 감정을 느꼈는데, 올해도 같은 감정이 찾아와 이를 하나의 원인으로 생각했습니다. 검색해 보니 이는 저만의 문제가 아니라, 많은 사람들이 겪는 자연스러운 현상이더군요.

이와 관련하여 자료를 찾아보니, 1월에 유독 상실감과 무기력감을 느끼는 이유로는 다음과 같은 것들이 있다고 합니다.

일조량 감소: 1월은 일조량이 가장 적은 달로, 햇빛을 받을 시간이 적어지면서 우울감이 증가할 수 있음

연말연시의 스트레스: 한 해를 결산하고 새로운 목표를 세우는 과정에서 부담감을 느낌

휴가 종료: 연말 휴가 후 다시 일상으로 복귀하는 과정에서 무기력감을 경험

저 역시 여기에 해당하는 부분이 많았습니다. 연말에는 긴 휴가를 다녀왔고, 연말까지 끝내야 할 업무를 마무리하느라 막판 스퍼트(?)를 내기도 했죠. 그러다 보니 1월이 되면서 모든 걸 새롭게 시작해야 한다는 부담감이 더 크게 다가온 것 같습니다.

완성된 2024년, 이제 2025년의 도화지에 첫 스케치를 할 시간

새해라는 환경적 변화가 모든 것을 새로 시작한다는 느낌을 주는데요. 그것이 저에게는 마치 그리던 그림을 서둘러 마무리하고 숨을 돌렸더니, 흰 도화지를 새로 받아 스케치부터 시작하려는 느낌 같았습니다. 막상 다시 그리기 시작하면 금방 익숙해지겠지만, 처음엔 막막하고 부담스러울 수밖에 없겠죠.

다행히 1월의 우울감은 시간이 지나면 자연스럽게 사라진다고 합니다. 그리고 설 연휴를 맞이하면서 충분히 휴식하는 시간도 가졌습니다. 덕분에 저 역시 지금은 한결 나아졌고, 다시 평상시의 리듬을 찾아가고 있습니다.

깊은 몰입과 잦은 상황 변화

둘 사이의 밸런스를 찾는 과정

두 번째 이유는 개인 성향적 요인인업무에 대한 깊은 몰입과 잦은 상황 변화의 충돌이었습니다.

저는 하나의 어려운 문제를 깊이 파고들어 해결하는 것을 좋아합니다. 또한 결과의 디테일과 완성도 역시 중요하게 생각하는 편이기 때문에, 이런 업무들을 맡으면 끝까지 완벽하게 완성하고 싶은 욕구가 생기곤 했습니다. 이것은 저의 열정과 동기 부여를 만드는 요소 중 하나였죠. 그래서인지 실제로 작년에 회사에서 제가 맡은 업무들도 대부분 그런 성향을 반영한 것들이었습니다.

이런 방식의 업무 스타일은 인내심과 끈기를 요구하는데요, 저는 이 분야에서 매우 재능(?)이 뛰어난 편입니다.

어릴 적부터 인내심 하나는 기가 막혔다!

위 사진은 제가 고등학생 때 진행했던 행동 발달 항목 테스트 결과지인데요. 인내심이 평균적인 다른 사람과 비교했을 때 상당히 높은 편으로 나온 것을 볼 수 있습니다. 상당히 아웃라이어(?)라고 볼 수 있죠. 이러한 성향은 개발자로서 어려운 문제를 인내심을 가지고 끈기 있게 해결해 나가는 데 있어서 큰 장점으로 작용했습니다.

하지만 반대로, 불확실한 환경과 잦은 변경 사항은 저에게 스트레스로 다가왔습니다. 빠르게 프로토타이핑을 하거나 개념 증명(Proof of Concept) 중심의 업무는 흥미를 끌지 못했죠. 그런데 제가 속한 팀은 해외향 신규 서비스 런칭 을 목표로 하는 팀이기 때문에 서비스 방향을 탐색하는 과정에서 기획 변경(피보팅, Pivoting)이 빈번히 발생했습니다.

이 과정에서 지금까지 공들여 만든 작업물들이 사용되지 않고 폐기되는 경우도 많았고, 그런 상황이 반복될수록 심리적인 저항감이 커졌습니다.

이 방향이 아닌가? 다른 길로 가보자!

물론 저는 변화 자체를 거부하는 사람은 아닙니다. 하지만 회사의 서비스 방향이 계속 바뀌고, 동의할 수 없는 결정이 내려질 때면 감정적으로 소모되는 느낌이 들었습니다.

결과물에 주인 의식을 갖고 일하는 것이 중요하다는 제 가치관이 흔들리기 시작했죠. ‘코드가 버려질 수도 있다는 걸 의식하고 덜 열정적으로 일하는 것이 맞는 걸까?’ 라는 고민이 들었거든요.

우리가 코드의 주인은 아닐지라도, 그 탐색 과정은 가치 있다.

여기에 대한 해답은 팀원들에게 저의 고민을 솔직하게 공유하면서 얻을 수 있었습니다. 우리가 돈을 받고 일하는 이상, 코드의 주인은 결국 회사입니다. 그러므로 결과물에 과몰입하는 것이 꼭 좋은 방향은 아닐 수도 있다는 것이죠.

몰입과 상황 변화를 대처하는 방법으로는 결과를 탐색하는 과정 또한 가치 있다 는 마음가짐을 갖는 것이었습니다. 코드의 가치는 단순히 배포된 결과물에서 끝나지 않습니다. 과정에서 얻은 경험과 지식이 팀에 축적되고, 팀원들에게 공유되면서 무형 자산이 됩니다.

팀원들과 함께 우리가 하고 있는 업무를 스스로 평가해 보았을 때 우리는 일반적인 웹 서비스에서는 경험할 수 없는 흥미롭고 도전적인 업무를 하고 있고, 이 과정에서 저의 경험은 팀에 자산으로 남아서 다른 팀원들에게도 많은 도움이 되고 있다고 평가해 주셨습니다.

실제로 제가 개발한 기능이 폐기된 적이 있지만, 그 과정에서 배운 것들이 이후 프로젝트에서 더 나은 코드를 작성하는 데 큰 도움이 되었습니다. 또한 제 경험을 팀원들에게 전수하면서 팀 전체의 역량을 높이는 계기가 되기도 했죠.

이러한 관점의 변화를 통해 결과물이 사용되지 않는다고 해서 그것이 모두의 시간과 노력이 허사로 느껴지는 것은 아니라는 것을 깨달았습니다. 우리의 노력은 결국 어디선가 다시 쓰일 것이고, 그 과정에서 배우는 것들이야말로 가장 값진 자산이니까요.

보물섬 찾기와 배 만들기

보물섬을 향한 항해

세 번째 이유는 조직적 요인, 일의 목표와 방향, 의미가 명확하지 않다는 점이었습니다.

저는 일의 목표와 방향에 공감할 수 있는지의 여부가 동기 부여에 큰 영향을 미치는 편입니다. 그런데 시간이 흐를수록 우리 서비스의 목표와 방향이 여러 번의 피보팅을 거치며 정확하게 무슨 문제를 해결하고 싶은 것인지가 명확하지 않다는 생각이 들었습니다.

팀원들에게 이 내용을 공유할 때 저는 보물섬과 배 를 비유로 들어 설명했습니다.

일반적인 목표 지향적인 회사에서는 이렇게 일을 하는 것 같아요. 바다 너머에 보물섬이 있다고 해보죠. 육지에 있는 사람들은 그 보물섬을 찾기 위해 배를 만들고 노를 젓습니다. 이 과정이 물론 힘들고 어렵겠지만, 목표가 명확하고 향하는 방향이 명확하다면 그 노력이 가치 있게 느껴질 거예요.

그런데 저희 조직은 좀 반대인 것 같아요. “일단 배를 만들어. 그리고 노를 저어봐. 그러다 보면 보물섬을 만날지도 몰라.” 라는 느낌이 들어요. 열심히 노를 저어야 하는 실무자 입장에서는 시간이 흐를수록 동기 부여가 점점 옅어질 수밖에 없는 것 같아요.

보물섬을 찾는 것이 우리가 풀어야 할 문제이자 목표고, 어떤 방향으로 가야할 지 정하는 것이 선장의 역할일 거예요. 그리고 실무자는 선장의 명령에 따라 열심히 노를 저어야 합니다. 이것이 각자의 역할이니까요.

열심히 노를 젓기 위해서는 보물섬을 찾는 것이 왜 중요한지를 이해하고 있어야 하는데, 그게 명확하지 않다면 노를 젓는 것이 힘들어질 수밖에 없는 것 같아요.

이런 이야기를 바탕으로 여러 이야기를 나누었는데요. 이를 통해 저는 조직 관점에서 탑다운 의사 결정을 내릴 때 충분한 설명과 근거가 뒷받침되지 않았다는 점, 그리고 실무자가 리더에게 편하게 의견을 전달할 수 있는 커뮤니케이션 창구가 필요하다는 것을 느꼈습니다.

우리 조직의 이런 부분이 사기에 영향을 미치고 있다는 점에 대해서는 공감했지만, 매우 큰 조직에 속해 있는 실무자의 입장으로써 여기에 대해 뚜렷한 해결책을 제시하기는 어려웠습니다. 사람들이 모인 곳에서는 결국 정치적인 요소가 들어가기 마련이라는 점을 감안해야 한다는 의견도 있었구요.

하지만 팀원들과 이런 이야기를 나누면서 서로의 생각을 공유하고 공감하는 것만으로도 감정 해소에 많은 도움이 되었습니다.

결론

모든 직장인들 화이팅!

초반에는 번아웃이 왔다는 사실을 인정하고 싶지 않았지만 이를 받아들이고 원인을 분석하며 해결책을 찾아가는 과정에서, 저는 멘탈적으로 한층 성장할 수 있었습니다.

특히, 제 노력과 가치를 인정해 주는 팀원들에게 감사함을 느꼈고, 솔직한 대화를 통해 신뢰가 더욱 깊어졌습니다. 무엇보다도 충분한 휴식과 팀원들과의 소통이 가장 중요하다는 것을 깨달았습니다. 서로의 고민을 공유하고 공감하는 과정에서 감정적으로도 큰 위안을 얻을 수 있었죠.

이렇게 해서 번아웃의 이유를 분석해 보았는데요, 이러한 경험을 통해 저는 상황 변화에 더 유연하게 대응할 수 있는 개발자로 성장하고 있다는 확신이 들었습니다. 물론 퇴사나 이직 같은 극단적(?) 선택지도 있겠지만, 저처럼 본인을 둘러싼 상황과 성향, 감정을 분석해 보고 글로 정리해 보는 것도 좋은 방법이 될 수 있을 것 같아요.

재그지그의 개발 블로그

나는 하루 5분만 바꾸기로 했다

책 소개

루틴의 필요성 알기

아주 작은 루틴으로 시작하기

뼈대 루틴 세우고 가지 루틴 쌓기

루틴 세트 유지하기

마치며

Safari에서 그라데이션 배경에 트랜지션이 적용되지 않았던 이유

TL;DR

그라데이션 트랜지션 구현하기

투명도 조절으로 구현하기

currentColor로 구현하기

Safari의 렌더링 최적화 문제

해결 방법

강제 리페인트 유도

@property로 CSS 변수 애니메이션

마무리

다섯 마리의 토끼를 쫓았던 2025년 회고

2024년에 세웠던 목표

일과 삶의 균형을 잘 맞추기

회사에서 1인분 이상의 몫 해내기

데일리 크리에이티브 책 완독하기

일기 쓰기

분야와 상관없이 새로운 도전 시도하기

블로그 테마 오픈소스로 공개하기

2025년 타임라인

유니코드 문자열 정규화

글빼미 고도화

글또 운영진 모임

독서

갤럭시 S25

프론트엔드 반상회

번아웃

크롬에서의 뷰포트 단위

도쿄 워케이션

글또 회고

글드컵

소셜 로그인 구현하기

유럽 여행

강의

iOS 브라우저의 버그

밴드 활동

올해를 한 마디로 정리하자면

새해 목표 다짐을 한 마디로 정리하자면

일과 자기 계발

삶과 취미

iOS 브라우저에서 스크롤과 좌표 계산 API를 함께 썼더니 생긴 일

TL;DR

문제의 발견

실제 데모

해결 방법

setTimeout 으로 여유 시간 주기

스크롤 값에 min/max 직접 적용하기

최종 결론

『실용주의 기술 블로그 글쓰기』 수강 후기

강의 개요

강의 커리큘럼

기술 블로그 글쓰기의 어려움

글의 독자 설정 및 좋은 글에 대한 정의 설정하기

글쓰기 파이프라인

글쓰기 세부 과정 소개

SEO와 글 발행 전략 및 사례 공유

FAQ

글쓰기 레벨

강의 후기

클라이언트 환경에서 안전한 소셜 로그인을 구현하는 핵심 메커니즘, OIDC와 PKCE 알아보기

개념 정리

OAuth 2.0

OIDC

PKCE

페이스북 로그인 예제

페이스북 앱 생성

클라이언트 앱 생성

code_verifier 생성

code_challenge 생성

code_verifier 를 저장

인증 서버에 요청 전송

리다이렉트 URI에서 액세스 토큰 획득

마무리

`currentColor`로 구현하기

`@property`로 CSS 변수 애니메이션

`setTimeout` 으로 여유 시간 주기

`code_verifier` 생성

`code_challenge` 생성

`code_verifier` 를 저장