🔗 https://cerebralvalley.ai/e/gemini-3-seoul-hackathon?tab=guest-list

TL;DR

• 만든 것: Gemini 3를 활용한 서울 랜드마크 방탈출 게임 "Seoul Adventure"

• 핵심 기술: Gemini 3 Flash Preview로 시나리오 자동 생성 + 이미지 인증

• 가장 큰 교훈: 해커톤에서는 익숙한 스택 + 데모 중심 개발이 정답

프로젝트: Seoul Adventure

아이디어

서울 랜드마크에서 방탈출을 해본다면 어떨까? 라는 생각을 시작으로 서울에 있는 여러 랜드마크들에 방문해서 미션을 수행하는 서비스를 만들어봤다. 약간의 스토리텔링과 인증, 퀴즈 형식을 가미해서 군데 군데를 돌아보고 추억을 남기는 서비스다.

인증 방식은 사진, 퀴즈, GPS 위치 정보 세가지로 구성했다.

🔗 https://github.com/Aqudi/seoul-adventure

기술 스택

Gemini 3 활용

Gemini 3를 세 가지 핵심 기능에 활용했다:

1. 시나리오 자동 생성: 랜드마크 이름만 입력하면 역사적 스토리라인, 퀴즈, GPS 좌표가 포함된 탈출 시나리오가 자동 생성된다.

2. 이미지 인증: 사진 퀘스트 완료 시 AI가 사진을 분석하여 정확한 장소 방문 여부를 검증한다.

3. 퀘스트 구성: GPS 좌표 기반 위치 인증, 역사 퀴즈, 사진 인증 등 다양한 미션 타입을 지원한다.

팀 구성

사이프에서 만난 형, 누나와 3인 팀(백엔드 2, 프론트 1)으로 참가했다.

개발 타임라인

삽질 기록

1. Turborepo + MikroORM 설정 삽질 (30분+)

안 써봤던 Turborepo(monorepo)와 MikroORM을 선택했는데, 초반에 설정 때문에 30분 이상을 소요했다. 알고 보니 root에 있는 tsconfig 문제였는데, MikroORM 설정 문제인 줄 알고 한참 헤맸다.

교훈: 해커톤에서는 익숙한 스택을 쓰는 게 정답이다. 새로운 기술을 배우고 싶으면 해커톤 전에 미리 연습하자.

2. Gemini API Rate Limit

시연 직전에 too many requests 에러가 발생해서 라이브 데모가 순탄치 않았다.

원인: 크레딧을 충전했는데도 무료 플랜의 rate limit이 적용되고 있었다. 플랜을 올려봐도 해결이 안 돼서 결국 데모 중에 에러가 났다.

교훈: API 사용시에는 결제 플랜 꼭 확인하고 사용하자.

3. 불필요한 기능에 시간 낭비

회원 인증과 실제 배포에 시간을 썼는데, 데모 영상이나 라이브 데모만 보여주면 되는 상황이었다.

교훈: 해커톤에서는 "동작하는 데모"가 "배포된 반쪽짜리"보다 낫다.

회고

좋았던 점

1. 3년 만의 해커톤: 7~8시간 몰입해서 개발하는 경험 자체가 값졌다. 평소에는 업무와 일상에 쫓기다 보면 이렇게 한 가지 일에 집중하기 어려운데, 해커톤이라는 환경이 강제로 몰입 모드를 만들어줬다.

2. 좋은 팀원들과 함께: 서로 역할 분담도 잘 되고, 막히는 부분 있으면 바로바로 논의할 수 있어서 혼자 할 때보다 훨씬 재밌었다.

3. 재밌는 아이디어 발굴: "서울 랜드마크에서 방탈출"이라는 컨셉이 생각보다 확장성이 높았다. 따로 사이드로 개발하고 싶다.

4. Pencil.dev 사용: 해커톤 때 10분 활용해봤는데 생각보다 훨씬 결과물이 좋게 나왔다. 이제 디자이너 없이도 사이드프로젝트 디자인 정도는 뚝딱 할 수 있을 것 같다. 다만 최초 생성 이후에는 성능이 급격하게 떨어지는 느낌이었다.

   

5. 세빛둥둥섬에서의 코딩: 한강 위에 떠 있는 건물에서 코딩하는 경험은 처음이었다. 창밖으로 보이는 한강뷰가 생각보다 집중력에 도움이 됐다. 약간의 힐링되는 느낌도 있었다.

아쉬웠던 점

1. 아이디어 회의에 2시간: 오전 9시에 가서 아침밥 먹고 아이디어 회의를 시작했는데, 2시간이나 걸렸다. 최소한 방향성은 미리 정하고 왔어야 했다.

2. 행사 사전 조사 부족: 공지 페이지를 꼼꼼히 안 봐서 구글 크레딧을 못 받았다.

3. 새로운 기술 스택: Turborepo, MikroORM 등 제한된 시간 내에 개발하기도 벅찬데 새로운 기술까지 학습하려니 시간이 배로 들었다.

4. 비효율적인 작업 프로세스: 프론트/백엔드 나눠서 작업했는데, 요즘 AI 코딩 도구가 워낙 잘되어 있으니 기능 단위로 동시에 하는 게 나았을 것 같다.

5. 네트워킹 부족: 정신없이 개발하느라 다른 팀들과 교류를 못 했다. 해커톤을 네트워킹의 장으로 더 활용할 수 있었을 텐데.

다음 해커톤을 위한 액션 아이템

부록: 행사 운영 리뷰

아쉬웠던 운영

1. 대회 3~4일 전에 장소 공지

2. Discord 질문에 대한 답변이 거의 안됨

3. 신청이 선착순이 아니라 행사장 도착이 선착순

   • 총 427명이 지원했는데 그 중 250명만 들어갈 수 있다고 했음

   • 전 날 미리 서울로 올라오는 지방 분들은 어떻게 해야 하냐고 당황

4. 전력 부족: 문의했을 때 임시로 벽에 붙어서 충전하라는 말 밖에...

좋았던 점 (가성비 최고)

1. 무료인데 퀄리티 좋은 식사: 행사 장소가 연회장으로 쓰던 곳이라 식사가 맛있었다. 삼시세끼 + 커피, 주스, 과자, 에너지바까지 제공해줬다.

   

2. 네트워킹 분위기가 좋았다: 개발하느라 바빴지만 네트워킹하면서 더 알차게 보내신 분들이 많았다.

마치며

3년 만의 해커톤이었다. 오랜만에 업무 외 개발에 푹 빠져서 할 수 있어서 좋았다. 운영은 약간 아쉬운 부분들이 있었지만, 무료임에 불구하고 맛있는 밥을 세 끼나 챙겨줬다는 게 감동적이었다. 결론적으로는 한강 위에서 코딩하고, 좋은 팀원들과 재밌는 프로젝트를 만들면서 즐겁게 보낸 시간이었다.

다음 해커톤에서는 이번에 배운 교훈들을 적용해서 더 완성도 높은 결과물을 만들어보고 싶다. 그리고 Seoul Adventure는 사이드로 계속 개발해봐도 좋을 것 같다.

드디어 글또 10기 활동 회고를 정리해본다.
6개월간의 여정을 뒤돌아보니 정말 많은 일들이 있었다.

글또라는 커뮤니티를 8기가 한창 진행되고 있을 때 알았는데 이름부터 인상이 강렬했다.

"글쓰는 또라이가 세상을 바꾼다."

유쾌하고 독특한 문구에 피식 웃으며, '여긴 도대체 어떤 사람들이 모이는 곳이지?' 하고 넘겼었다.

재밌는 건 결국, 나도 그 "또라이들" 중 한 명이 되었다는 것이다. 😌

글또는 개발자들이 2주에 한 번 글을 쓰며 성장하는 커뮤니티다.
글을 중심으로 서로 연결되고, 경험을 나누고, 함께 성장하는 따뜻한 공간이다.
👉 글또 소개 페이지 바로가기

🤔 글또, 왜 지원했나요?

글또 10기에 지원했을 당시, 나는 입사한 지 7개월 된 백엔드 개발자였다. 백엔드 1, 프론트 1로 구성된 팀에서 혼자 백엔드를 전담하다 보니, 개발 일정 따라 정신없이 일은 하고 있지만 내가 잘하고 있는지 전혀 모르겠어서 너무 답답했다. 실제로 그때 썼던 회고들을 보면 참… 인정과, 관심에 목말랐다는 게 여실히 보였다.

"내가 잘하고 있는 걸까?" "내가 원하는 커리어는 뭘까?" 하는 고민은 많고, 주변에서는 물경력이니 JSON 상하차니 이런 이야기가 들려오니까 앞으로 내 커리어 잘 만들어 갈 수 있을까 하는 걱정, 불안이 컸었다.

그래서 더욱 더 나와 비슷한 고민을 나눌 수 있는 사람들과의 연결이 절실했던 것 같다. 이런 시기에 글또에 들어가서 다양한 개발자들과 같이 글쓰고 이야기를 나눌 수 있었다니! 운, 타이밍 다 좋았다. 🥹🍀

"10기가 마지막이다."

물론, 처음에는 2주에 1편 글 제출과 훈련소 일정이 겹친다는 것 때문에 살짝 망설이기도 했는데 마지막이라는 문구가 이런 망설임을 단번에 날려버렸었다. 😂

마지막이라는데 참을 수 없지!

✍️ 6개월 동안 어떤 활동을 했나요?

글또 시작하면서 했던 다짐 중 하나가 글 2주에 한 편씩 쓰기와 커피챗 월 2회 이상하기였는데 90% 이상은 달성했다!

글또 10기 활동 기간 동안 총 10편의 글을 썼다. 아쉽게도 패스와 미제출이 하나씩 있었다. 2회차 때 훈련소에 가 있어서 패스한 거랑 마지막 회차 때 지금 이 회고 쓰다가 감상에 젖어 결국 완성 못하고 미제출로 끝났다. 그래도 이 회고가 다시 글쓰기 흐름을 만들어줄 거라고 생각하니까 오히려 좋지 않나 싶다 😊

작성한 글들을 주제로 분류해보면 아래와 같다.

• 회고 3편

• 기술 5편

• 책, 컨퍼런스 후기 2편

아직 글 쓰고 올리는 게 익숙하지는 않지만 글쓰는 재미는 좀 알게 된 것 같다. 글또 끝나고 글을 안 쓰긴 했지만 그래도 “어? 이거 글 써보고 싶은데”하는 것들이 종종 보인다. 오늘 회고 글을 시작으로 조금씩 써서 올려보려고 한다!

퇴고또라는 소모임 활동으로 글 피드백도 서로 주고 받아봤는데 내 글들은 아직 갈 길이 멀다고 느껴졌다. 그래도 글을 썼기 때문에 부족한 부분이 보이고 채울 기회가 주어진 것이니 기쁘게 생각한다.

커피챗도 열심히 참여했다. 커피챗은 총 23회 인증했는데 글또 이후로도 슬랙은 계속 유지되고 있어서 종종 사람들과 어울리다보니 어느새 30개가 됐다. 글또 내 소모임에서 열리는 오프라인 모임, 반상회, 2024 성과 회고, 눈썰매타러 가기 등 다양하고 즐거운 활동들이 많았다. 요즘은 좀 뜸하게 들어가는데 들어갈 때마다 반가운 얼굴들이 많이 보여서 기분이 좋다.

커피챗하기 목표를 달성하기 위해 용기내서 신청한 1대1 커피챗도 저 중에 11회나 된다!

커피챗 외에도 쓸모있는 10분 모각글또, 퇴고또, 다진마늘(일간 목표 설정 챌린지) 등 다양한 인증 소모임들에도 참석했었는데 매일 꾸준히 하지는 못했지만 덕분에 나만의 글쓰기 루틴이나 일간 목표 설정 방법 등 만들어서 아직까지도 잘 써먹고 있다.

특히 자랑하고 싶은 건 내 생에 첫 마라톤으로 10km를 1시간 4분 만에 완주했다는 것이다. 신경써서 연습일정 만들어주시고 응원해주신 글또 분들 덕분에 시작할 수 있었고 마무리할 수 있었다고 생각한다. 뭐든 처음 시작할 때 그 일을 좋아하고 이미 해본 사람들이 있다는 건 엄청난 축복인 것 같다.

지금 다시 돌아봐도 글또 활동은 “글쓰기”보다 훨씬 많은 영역에서 크고 작은 변화들을 만들어줬다.

같이 하니까 평소에 하지 않던 일도 더 쉽게 도전해볼 수 있었고, 더 오래 지속할 수 있었다고 생각한다!

☕ 가장 기억에 남는 활동은 뭔가요?

글또 활동 중 가장 인상 깊었던 건 단연 커피챗이다. (커피챗도 엄연히 글또 메인 컨텐츠 중 하나다!)

처음 커피챗을 요청할 때 '내가 그 분에게 어떤 도움이 될까? 귀찮기만 한 건 아닐까?'라는 걱정이 앞서서 커피챗이 망설여졌었다. 하지만 그런 걱정이 무색하게도 만나는 분들 모두 적극적이고 따뜻하게 맞아주셨었다.

특히 첫 커피챗 상대였던 은찬님과의 만남은 아직도 기억에 선명하다.
Flutter와 1인 개발, 매일 글쓰기 이런 키워드에 은찬님에 대한 호기심이 생기면서 설렘반, 걱정반으로 DM을 보냈는데, 흔쾌히 응해주신 데다 직접 회사 근처로 찾아와주셔서 너무 감사했다.

'회사 없이도 살아남을 수 있는 역량'이나 '개발자로서의 성장 방향' 같은 주제들은 그때 처음 구체적으로 생각해본 것들이었고, 그 자리에서 받은 영감과 따뜻한 관심 덕분에 이후로도 커피챗을 계속 신청할 수 있는 용기가 생겼다.

이후에도 올라오는 글을 읽으면서 궁금해진 분들이 있으면 용기내서 말을 드려봤고 현업 고민, 글쓰기 루틴, 사이드 프로젝트 등 다양한 이야기를 나눴었다. 그 중 “나를 위해 더 열심히 해야 한다”라는 말이 특히 기억에 남는 것 같다. 글또 하기 전에도 종종 찾아봤던 블로그 ‘연로그’ 운영하시는 시연님과 나눈 이야기였는데 사람들이 열심히 일하는 원동력에 대한 궁금증이 있던 나에게 ‘열심히 일하는 게 다른 누구를 위한 게 아니구나!’하는 깨달음을 줬었다.

단체로 만났던 커피챗 중 기억에 남는 것은 2024년 성과 회고 커피챗이다. 처음 회사에서 성과 리뷰를 작성하게 됐는데 '이번 해에 뭘 해왔지?' 막막했다. 이런 시기에 글또 분들이랑 같이 고민하고 나눌 수 있는 자리가 생겨서 내 1년을 돌아보며 어떤 성과를 이뤘는지 고민하고 피드백 받을 기회는 내게 너무 소중했다.

글또가 단순히 '2주에 한 번씩 글을 제출하는 모임'이 아니라 글을 중심으로 사람들을 연결하고 따스함을 나눠주는 커뮤니티라는 걸 6개월 간의 커피챗을 통해 몸으로 직접 느낄 수 있었다.

🤔 아쉬웠던 점이 있나요?

가장 아쉬운 건 시간: 6개월이 이렇게 짧은 거였나 싶다. 😱 눈 깜짝할 새에 6개월이 지났고 지금은Ï 거기에 더해 4개월이 추가로 더 흘렀다. 왜 이렇게 시간이 빠른 건지… 그저 아쉬울 따름이다. 잠깐이라도 한 눈 팔면 분기가 지나가고 ‘나 뭐했지’ 싶다. 정신차리고 제때 제때 회고하면서 알차게 보내자!

커뮤니티 기여: 받기만 하는 것보다 다른 분들 글에 더 적극적으로 댓글을 달고 피드백을 주고 싶었는데, 막상 하려니 '내가 이런 말을 해도 될까?' 하는 망설임이 컸다. 또 내 글 쓰는데 바빴지 다른 사람들 글을 잘 안 읽은 것도 아쉽다. 이제 와서 보니까 재밌고 따라쓰고 싶은 글들이 많은데 그때 보고 더 많은 사람들과 이야기를 나눠볼 걸 싶다.

글의 깊이, 재밌는 글: 기술적인 내용을 다룰 때 더 깊이 파고들어 정말 도움이 되는 글을 쓰고 싶었는데, 시간에 쫓겨 표면적인 내용에만 그친 것 같아 아쉬웠다. 또한 내가 쓴 글이 재미가 없다고 느껴졌었는데 퇴고하면서 피드백을 받아보니 내 이야기가 빠져있는 것 같다라는 말을 들었었다. 앞으로는 글을 쓸 때 내 경험, 내 생각이 녹아있는 글을 쓰도록 노력해야겠다.

마무리

벌써 글또 10기 마무리된지 4개월이 지나고 있다. 2024년 10월부터 2025년 3월까지 바빠서 정신없기도 했었지만 글또 덕분에 더 즐겁게 보낼 수 있었고 회사 생활도 이에 힘입어 더 열심히 할 수 있었던 것 같다. 자주 마주치던 분도 아예 얼굴도 못 본 분도 언젠가 꼭 한 번은 마주칠 것 같으니 그때까지 더 열심히 살아야겠다! 그리고 그때가 되면 “요즘도 글또 덕분에 글쓰기 시작하고 꾸준 잘 쓰고 있어요”라고 당당히 말할 수 있었으면 좋겠다 😊

그때를 위해서 글또하면서 몸소 느낀 "완벽하지 않아도 시작하기"를 실천하며 조금씩 글을 쌓아보고 조금씩 고쳐보면서 나만의 길을 만들어가봐야겠다!

글또야, 잘 가~ 👋

이 글에서 다루는 내용

• 포트포워딩이 안 되는 이유 (CGNAT 환경 이해)
• CGNAT 우회 방법들의 장단점 비교
• Cloudflare Tunnel 설정 방법 (MacOS 기준)

외부에서 내 PC로 접근할 수 있도록 허용하는 방법을 생각하면 포트포워딩이 가장 먼저 떠오릅니다. 공유기에서 특정 포트를 열어 외부에서 서버에 접속할 수 있도록 설정하는 방식으로, 마인크래프트 멀티를 해보셨던 분이라면 분명 해보셨을 방법입니다. 😊

작년에 저는 홈서버에 제가 쓰고 싶은 서비스를 띄워두고 쓰려고 서버를 배포했었습니다. 그런데 포트포워딩을 하고 접속 테스트를 하려고 공유기 설정에 들어가보니 외부 IP가 192.168.x.x 형태로 되어 있고 외부에서 접속이 안 됐습니다. 굉장히 난감했죠...

이번 글에서는 제가 겪었던 CGNAT이라는 환경에 대한 설명을 포함한 포트포워딩의 주요 문제점과 여러 해결법 중 제가 선택한 Cloudflare Tunnel 사용법까지 정리해보겠습니다.

포트포워딩의 주요 문제점

포트포워딩이 항상 동작하는 것은 아닙니다. 제가 겪었던 것처럼 안 되는 경우가 있는데, 주로 다음 세 가지 이유 때문입니다.

1. 공유기의 NAT 설정 문제

공유기는 사설 IP 주소를 공인 IP 주소로 변환하여 여러 기기가 인터넷에 접속할 수 있도록 합니다. 이 과정에서 올바른 포트포워딩 설정이 이루어지지 않거나 공유기의 제한이 있을 경우, 외부에서 서버에 접근이 어려울 수 있습니다.

이 경우는 설정을 다시 확인하면 대부분 해결됩니다.

2. ISP의 공인 IP 제한 (CGNAT 문제)

CGNAT가 뭔가요?

CGNAT(Carrier-Grade NAT)는 ISP가 여러 사용자에게 하나의 공인 IP를 공유하게 만드는 기술입니다. IPv4 주소가 부족해지면서 ISP들이 비용 절감을 위해 도입했습니다.

왜 포트포워딩이 안 되나요?

CGNAT 환경에서는 이중 NAT 구조가 됩니다:

외부 → ISP의 CGNAT → 공유기 → 홈서버

포트포워딩을 설정해도 ISP 레벨에서 추가적인 NAT 계층이 존재하기 때문에 외부에서 서버에 직접 접근할 수 없습니다. 외부에서 들어오는 연결이 수십~수백 명의 사용자 중 누구에게 보내야 할지 ISP가 알 수 없기 때문이죠.

내가 CGNAT 환경인지 확인하는 방법

1. 공유기 관리 페이지에서 WAN IP를 확인합니다.
2. "내 IP 확인" 사이트(예: whatismyip.com)에서 공인 IP를 확인합니다.
3. 두 IP가 다르면 CGNAT 환경입니다.
4. 특히 WAN IP가 100.64.x.x ~ 100.127.x.x 형태면 거의 확정입니다.

제 경우, 자취방의 인터넷이 CGNAT 환경이었기 때문에 공유기의 WAN IP가 192.168.x.x 형식의 사설 IP였고, 포트포워딩을 설정해도 외부에서 접근할 수 없었습니다.

3. 보안 이슈

포트포워딩이 되더라도 실제 IP를 노출해야 하므로 해킹 시도나 DDoS 공격에 노출될 위험이 높아집니다. 포트가 열려있다는 것 자체가 공격 표면이 되기 때문입니다.

이러한 문제들을 해결하기 위해 Cloudflare Tunnel을 활용하면 포트포워딩 없이도 안전하게 홈서버를 운영할 수 있습니다.

Cloudflare Tunnel이란?

Cloudflare Tunnel(구 Argo Tunnel)은 서버의 IP를 공개하지 않고도 외부에서 접속할 수 있게 해주는 서비스입니다. 기존 포트포워딩 방식과 가장 큰 차이점은 공유기에서 포트를 열 필요가 없다는 점입니다.

기존 포트포워딩 방식

외부 클라이언트 → 공유기 포트포워딩 → 홈서버

• ✅ 서버가 직접 외부에서 접근 가능
• ❌ 포트가 노출되므로 해킹 위험 존재
• ❌ CGNAT 환경에서는 사용 불가

Cloudflare Tunnel 방식

홈서버 → Cloudflare Tunnel → Cloudflare → 외부 클라이언트

• ✅ 서버의 IP가 노출되지 않음
• ✅ 포트포워딩 필요 없음 → CGNAT 문제 해결
• ✅ Cloudflare의 보안 기능 활용 가능

핵심은 연결 방향이 반대라는 점입니다. 포트포워딩은 외부에서 들어오는 연결을 받아야 하지만, Cloudflare Tunnel은 홈서버가 먼저 Cloudflare로 연결을 만들고, Cloudflare가 외부 요청을 중계해줍니다. 그래서 포트를 열 필요가 없고, CGNAT 환경에서도 동작합니다.

게다가 Cloudflare는 대부분의 경우 무료로 사용할 수 있으며, TLS 인증서 자동 발급, DDoS 방어, WAF(Web Application Firewall)까지 기본 제공됩니다.

이런 이유로 홈서버를 운영할 때 포트포워딩 대신 Cloudflare Tunnel을 사용하기로 했습니다.

CGNAT 우회 방법 비교

Cloudflare Tunnel 외에도 CGNAT를 우회하는 여러 방법이 있습니다:

Cloudflare Tunnel을 선택한 이유:

• 완전 무료: 다른 솔루션들은 유료이거나 기능 제한이 있음
• 보안 자동화: TLS 인증서 자동 발급, DDoS 방어, WAF 기본 제공
• 설정 간단: VPS + VPN 조합은 설정과 유지보수가 복잡함
• 글로벌 CDN: Cloudflare 네트워크를 통해 전 세계 어디서든 빠른 접속

물론 Cloudflare에 의존하게 된다는 단점이 있지만, 개인 홈서버 용도로는 충분히 트레이드오프할 만하다고 생각했습니다.

Cloudflare Tunnel 설정 방법 (MacOS 기준)

사전 준비

Cloudflare Tunnel을 설정하기 전에, 도메인이 Cloudflare에 등록되어 있어야 합니다. Cloudflare가 도메인의 DNS를 관리해야 터널과 연결할 수 있기 때문입니다.

1. Cloudflare에 도메인 등록

• Cloudflare에서 도메인 구매: Cloudflare를 통해 직접 도메인을 구매할 수 있습니다.
• 외부에서 구매한 도메인 등록: 이미 다른 등록기관에서 도메인을 구매했다면, 해당 도메인을 Cloudflare에 추가하고 네임서버를 Cloudflare에서 제공하는 것으로 변경하면 됩니다.

2. 네임서버 변경 절차

• 도메인 등록기관(예: 가비아)의 관리 페이지에 로그인합니다.
• Cloudflare에서 제공하는 네임서버 정보로 기존 네임서버를 변경합니다.
• 네임서버 변경이 완료되면, 변경 사항이 제대로 적용되었는지 확인합니다. (최대 24시간 소요)

참고 자료:

• 가비아 네임서버 변경 가이드
• Cloudflare에 도메인 추가하기

1. Cloudflare Tunnel 생성

터널을 생성하면 Cloudflare에서 고유한 터널 ID를 부여받습니다. 이 ID를 통해 홈서버와 Cloudflare가 연결됩니다.

• one.dash.cloudflare.com으로 이동하여 네트워크 > Tunnels 메뉴에 접속합니다.
• 터널 유형에서 Cloudflared를 선택합니다.

2. Cloudflare Tunnel 커넥터 설치 및 실행

커넥터(cloudflared)는 홈서버에서 실행되며, Cloudflare로 아웃바운드 연결을 유지합니다. 이 연결을 통해 외부 트래픽이 홈서버로 전달됩니다.

• 터널 구성에서 자신의 환경(MacOS/Linux/Windows/Docker)을 선택합니다.
• 표시된 명령어를 복사하여 터미널에서 실행합니다.

brew install cloudflared
sudo cloudflared service install <token>

• 설치가 완료되면 Connectors 섹션에 연결된 커넥터가 표시됩니다.

3. 공개 호스트 설정

어떤 도메인으로 들어온 요청을 홈서버의 어느 포트로 전달할지 설정합니다.

• 홈서버의 80번 포트(리버스 프록시)에 Cloudflare Tunnel을 연결하고 싶다면 하위 도메인을 와일드카드(*)로 선언합니다.
• *.example.com 형태로 설정하면 test.example.com, home.example.com 등 모든 서브도메인 요청을 받을 수 있습니다.

4. DNS에 Wildcard 도메인 연결하기

DNS 레코드를 추가해야 Cloudflare가 해당 도메인으로 들어오는 요청을 터널로 라우팅할 수 있습니다.

터널 ID 복사:

• 터널 리스트에서 방금 생성한 터널의 ID를 복사합니다.

DNS 레코드 추가:

• dash.cloudflare.com에 접속하여 DNS 레코드를 추가합니다.
  • 유형: CNAME
  • 이름: * (와일드카드)
  • 대상: <터널 UUID>.cfargotunnel.com
  • 프록시 상태: 프록싱됨 (주황색 구름 아이콘)

주의사항: Multi-level Subdomain SSL 제한

Cloudflare Tunnel 무료 플랜에서는 1단계 서브도메인(sub.example.com)에 대해서만 SSL 인증서가 제공됩니다. 2단계 서브도메인(sub.sub.example.com)은 SSL이 적용되지 않습니다.

왜 그런가요?

Cloudflare의 무료 SSL 인증서가 와일드카드(*.example.com)까지만 적용되기 때문입니다. *.*.example.com은 지원되지 않습니다.

해결 방법:

대부분의 경우 1단계 서브도메인으로 충분하므로, 굳이 복잡하게 구성할 필요는 없습니다.

참고: Cloudflare Advanced Certificate Manager

결론: Cloudflare Tunnel이 정답일까?

Cloudflare Tunnel은 공인 IP가 없거나 사용에 어려움이 있는 사용자나 보안을 강화하고 싶은 경우에 손쉽게 쓸 수 있는 솔루션입니다. 하지만 몇 가지 고려할 점이 있습니다.

알아둘 점

장점:

• 무료로 대부분의 기능 사용 가능
• TLS 인증서, DDoS 방어, WAF 기본 제공
• 설정이 간단하고 관리 부담이 적음
• 포트 개방 불필요로 보안 강화

제약사항:

• Multi-level subdomain (sub.sub.example.com)은 유료 플랜 필요
• 일부 사용자는 직접 프록시보다 속도 저하 경험
• Cloudflare에 대한 의존성

사용자 유형별 추천

저는 현재 n8n, karakeep, vaultwarden 등을 Cloudflare Tunnel로 운영하고 있는데, 설정 한 번으로 포트포워딩 고민 없이 안정적으로 사용하고 있습니다. 홈서버를 운영하면서 관리 리소스를 줄이고 안전하게 운영하고 싶다면 Cloudflare Tunnel을 적극 추천합니다.

물론 공부 목적이라면 포트포워딩을 쓰면서 잠재적인 보안 위협 요소들을 하나씩 차단해보는 경험도 좋을 것 같습니다. Cloudflare Tunnel이 안 좋은 상황이나 쓸 수 없는 상황이 더 있다면 댓글로 공유해주시면 좋겠습니다.

이번 K-Devcon 2월 Dev Bloom 행사는 광화문 마이크로소프트 사옥 13층에서 열렸습니다. 시위가 있어서 교통이 혼잡했는데, 다행히 늦지 않게 도착할 수 있었어요. 현장에는 약 150~200명의 개발자와 디자이너분들이 모였지만, 운영진이 공간을 잘 구성해주셔서 쾌적하게 강연들을 들을 수 있었습니다

.

세션은 각각 40분씩 진행되었는데, 시간이 다소 짧아 질문을 충분히 못 하는 아쉬움이 있었어요. 그래도 쉬는 시간마다 발표자분들께 직접 질문을 하고 사진도 찍을 수 있어 뜻깊었습니다. 행사 마지막에는 이지스 퍼블리싱에서 협찬한 도서 추첨이 있었는데, 운 좋게 당첨돼서 "알고리즘 코딩 테스트" 책을 받았습니다!

공식 행사 정보

• K-DEVCON 홈페이지: https://k-devcon.com/

• 2월 DevBloom 행사 안내 페이지: https://k-devcon.com/entry/Event-2025-02-15-K-DEVCON-%EC%84%9C%EC%9A%B8-2%EC%9B%94%EC%97%94

📝 세션별 내용 & 인상 깊었던점

(1) Rust Concurrency – 옥찬호 (42dot)

기대했던 바

• Rust가 C++이나 Node.js와 달리 동시성을 어떻게 안전하게 처리하는지 궁금했다.

• Rust의 소유권 시스템과 멀티스레드 환경에서의 데이터 보호 방식이 실제로 어떻게 작동하는지 알고 싶었다.

얻은 인사이트

• 뮤텍스(Mutex)와 데이터가 하나로 묶여 있는 구조: C++에서는 데이터와 락이 분리되어 있어 주석이나 문서로 관리해야 하는데, Rust에서는 **"Mutex 자체가 데이터를 포함"**하기 때문에 안전성이 보장된다는 점이 인상적이었다.

• 추가로 궁금해진 점: Node.js의 worker_threads와 Rust의 멀티스레드 모델의 차이점. 싱글스레드 기반인 Node.js의 worker_threads와 Rust의 멀티스레드 사이의 어떤 차이가 있는지 비교해볼 계획이다.

다음 액션

• Rust에서 배운 Arc<Mutex<T>>, channel 등을 활용해 간단한 동시성 예제를 만들어볼 예정이다.

• Rust와 Node.js의 동시성 모델을 비교하는 블로그 포스팅을 작성할 계획이다.

(2) 구해줘, 내 월세 – 은종민 (제니스 신당역 공인중개사무소)

기대했던 바

• 최근 전세 계약을 마무리하면서, 다음 월세 계약을 준비 중이라 실질적인 부동산 팁이 필요했다.

• 전세 사기가 사회적 이슈가 되는 만큼, 어떤 점을 체크해야 하는지 정리된 정보를 듣고 싶었다.

얻은 인사이트

• 등기부 등본을 직접 확인해야 한다: 중개사가 뽑아주는 요약본만 믿지 말고, 직접 등기부를 떼서 확인하는 습관이 필요하다.

  • 최신 등기부 등본 요약 조회 방법: https://www.youtube.com/watch?v=aU9fyVLqIEU

• 집 비밀번호 관리의 중요성: 집을 부동산에 내놓을 때 기존 비밀번호를 그대로 유지하면, 점유 문제가 발생할 수도 있다.

• 월세 계약 시 초안 확인: 계약서 초안을 미리 받아 검토해야 한다. 계약 당일 급하게 사인하면 놓치는 부분이 많아질 수 있다. 실제로 전세 계약할 때 초안을 미리 못 받아서 당일 정신없이 사인했던 경험이 있어서 더 공감됐다.

다음 액션

• 계약 전 등기부 등본 직접 떼보기 및 특약 조항 꼼꼼히 확인.

• 집을 누군가에게 보여주고 비밀번호 변경하기, 보증금 받기 전에는 비밀번호 알려주지 않기

(3) 멀티 에이전트의 구현 및 활용 – 정유선 (신세계)

기대했던 바

• AI 모델이 단순한 Q&A 수준을 넘어 도구(툴)와 API를 활용해 문제를 해결하는 방식이 궁금했다.

• 최근 AI 기술이 에이전트 기반으로 발전하는 만큼, 현업에서는 어떤 방식으로 적용하고 있는지 알고 싶었다.

얻은 인사이트

• Generative AI의 역할 변화: 단순한 챗봇이 아니라 툴을 활용해 직접 문제를 해결하는 에이전트가 대세라는 점이 인상적이었다.

• LLM 워크플로우(프롬프트 체이닝, 병렬화, 오케스트레이션 등) 여러 개의 에이전트를 협력시키거나 특정 작업을 효율적으로 분할 수행하는 기술에 대해서 알게 됐다. LLM 워크플로우 참고자료

다음 액션

• LangGraph를 활용해 간단한 AI 비서진을 만들어볼 계획이다. "개발 도우미", "자료조사 도우미" 등 역할을 나누어 실험해보면, 개인 생산성을 높이는 데에도 도움이 될 것 같다.

(4) 9명의 제품팀이 48명이 되기까지 – 이동욱 (인프랩)

기대했던 바

• 스타트업이 작은 팀에서 규모를 키우는 과정에서 조직 운영 방식이 어떤 영향을 미치는지 알고 싶었다.

• 현재 우리 회사 제품팀 규모도 40~50명 정도 된다고 알고 있어서 도움될만한 정보가 있을 것 같았다.

얻은 인사이트

• 기능 조직 → 목적 조직 → 특수 목적 조직으로 성장: 초기에는 직무별 기능 조직이 필요하지만, 성장이 빨라질수록 목적 조직이 효율적이라는 점이 공감됐다.

• **"병목이 발생하면 다른 조직이 도와야 한다"**는 용병 문화가 인상적이었다. 특정 팀이 과부하를 겪을 때, 비효율을 감수하고라도 조직 전체 속도를 맞추는 것이 중요하다.

• 특수 목적 조직의 필요성: 디자인 시스템, 내부 도구 개발 등 매일매일 개선이 필요하지 않은 영역을 관리하는 조직이 있으면 장기적인 생산성이 올라간다.

다음 액션

• 사내 디자인 시스템과 코어 서비스 개발을 특수 목적 조직 형태로 운영하는 방안을 리드들에게 건의해봐야겠다.

(5) Stack Overflow 25,000점 달성기 – 김영재 (LINE)

기대했던 바

• 평소 Stack Overflow에서 검색은 많이 하지만, 질문이나 답변을 직접 남긴 적이 없어서 어떻게 기여할 수 있을지 알고 싶었다.

• 커뮤니티에서 적극적으로 활동하면 어떤 이점이 있는지도 궁금했다.

얻은 인사이트

• 커뮤니티 활동이 좋은 질문과 답변을 하기 위한 훈련이며, 이는 곧 AI 시대의 좋은 개발자가 되기 위한 방법이다.

• ChatGPT 등장 이후 Stack Overflow의 질문 수가 5분의 1로 감소했다. AI가 모든 해답을 제공할 것처럼 보이지만, 실제 문제 해결 과정에서 얻는 시행착오의 가치가 오히려 높아지고 있다.

• 지식 노동자로서 자신의 경험을 시작과 끝이 있는 완결된 지식으로 가공하는 능력이 필수적이다.

• 좋지 못한 질문 사례들을 보며 나의 질문 방식을 돌아보게 되었다.

다음 액션

• 상반기 동안 200점 이상 획득하는 것을 목표로, 회사 프로젝트에서 겪은 오류나 삽질했던 내용을 중심으로 Stack Overflow에 질문/답변을 남겨봐야겠다.

✅ 이번 행사 총평

Rust 동시성부터 부동산 계약 팁, AI 멀티 에이전트, 스타트업 조직 운영, 스택오버플로우 커뮤니티 참여까지 폭넓은 주제를 한 자리에서 접할 수 있어서 뜻 깊었던 5시간이었습니다.

각 세션 시간이 한정적이라 질의응답 시간이 부족했던 게 좀 아쉬웠지만, 추가로 질문이 있을 때 정말 기꺼이 시간 내어 답변해 주셔서 너무 감사했습니다. 특히, 제 고민을 들어주고 인프랩의 사례를 공유해주신 동욱 님, 그리고 발표장 바깥에서 자리를 지키며 도움이 필요하신 분들에게 부동산 상담까지 해주신 은종민 님 덕분에 더욱 뜻깊은 시간이 되었습니다. 따뜻함을 한껏 충전할 수 있었던 행사였어요! ☺️

다음 K-Devcon 행사에도 참석해서 앞으로도 이런 배움의 기회를 계속 늘려가고 싶습니다. 그래서 이번에 K-Devcon에서 운영하는 멘토링 프로그램 "고투런" 2기 멘티도 모집에도 지원해볼 예정입니다!

궁금하신 점이나 공유하고 싶은 이야기가 있다면 언제든 댓글 달아주세요! 감사합니다!

최근 여러 프로젝트를 진행하면서 테스트가 단순히 선택이 아니라 필수 요소임을 다시금 깨달았습니다. 특히 회사에서 진행된 테스트 특강을 통해 테스트가 개발 프로세스 전반에 걸쳐 중요한 전략임을 재인식하게 되었고, 이 기회에 보다 체계적이고 심도 있는 테스트 방법론을 배우고자 “풀스택 테스트”를 읽게 되었습니다.

책 소개

”풀스택 테스트”는 10가지 테스트 기술을 중심으로 웹과 모바일 애플리케이션의 품질 확보 방법을 종합적으로 정리한 책입니다. 총 432쪽 분량으로, 저자인 가야트리 모한의 풍부한 실무 경험과 노하우가 담겨 있으며, 최경현 님의 번역 덕분에 쉽게 읽을 수 있습니다.

한빛미디어 책 소개 페이지 바로가기

책은 13개 장으로 구성되며, 첫 장에서는 풀스택 테스트의 기본 개념과 ‘시프트 레프트’ 전략을 소개합니다. 이후 수동 탐색적 테스트, 자동화 기능 테스트, 지속적 테스트, 데이터 테스트, 시각적 테스트, 보안 테스트, 성능 테스트, 접근성 테스트, 교차 기능 요구사항 테스트, 모바일 테스트까지 다양한 영역을 순차적으로 다룬 뒤, 마지막 장에서 AI, 머신러닝, 블록체인, IoT, AR/VR 등 신기술 테스트 전략을 소개합니다.

각 장은 구성 요소 → 전략 → 실습 → 추가 테스트 도구 → 인사이트 순으로 전개되며, 필요한 테스트 기술을 빠르게 찾아볼 수 있어 일종의 ‘백과사전’처럼 활용하기에 매우 유용합니다.

주요 내용 요약

이 책은 다음의 10가지 핵심 테스트 기술을 중심으로 다양한 실무 사례와 도구 사용법을 제시합니다:

1. 수동 탐색적 테스트

2. 자동화된 기능 테스트

3. 지속적 테스트

4. 데이터 테스트

5. 시각적 테스트

6. 보안 테스트

7. 성능 테스트

8. 접근성 테스트

9. 교차 기능 요구사항 테스트

10. 모바일 테스트

이 중 개인적으로 가장 인상 깊었던 보안, 성능, 접근성 테스트에 대해 조금 더 자세히 살펴보겠습니다.

보안 테스트 (7장)

개발 일정이 빠듯하다 보면 보안은 후순위로 밀리기 쉽지만, 서비스 전체의 신뢰도에 치명적 영향을 줄 수 있기에 결코 가볍게 볼 수 없는 영역입니다. 이 책에서는 STRIDE 위협 모델을 통해 보안 위협을 **스푸핑(Spoofing), 변조(Tampering), 부인(Repudiation), 정보 노출(Information Disclosure), 서비스 거부(Denial of Service), 권한 상승(Elevation of Privilege)**의 여섯 가지 범주로 나누어 체계적으로 파악할 것을 제안합니다.

STRIDE 위협 모델

• 마이크로소프트가 제안한 보안 위협 분석 방법론으로, 애플리케이션 및 시스템을 설계 개발할 때 어떤 위험 요소가 있는지 체계적으로 분석할 수 있습니다.

• 더 자세한 내용은 Wikipedia STRIDE 위협 모델 문서를 참고해주세요.

또한 책에서는 OWASP ZAP이나 Dependency-Check 같은 자동화 보안 도구를 적극적으로 활용해, 개발 과정에서 지속적으로 보안을 점검하길 권장합니다.

OWASP ZAP (Zed Attack Proxy)

• 오픈 소스 웹 애플리케이션 보안 스캐닝 도구로, 취약점 스캐닝을 자동화할 수 있습니다.

• OWASP ZAP 공식 웹사이트에서 설치 방법과 사용 예시를 확인할 수 있습니다.

Dependency-Check

• 애플리케이션이 사용하는 라이브러리(의존성) 중 보안 취약점이 존재하는지 분석해주는 오픈 소스 도구입니다.

• OWASP Dependency-Check 공식 웹사이트에서 최신 버전을 다운로드하고 사용법을 배울 수 있습니다.

이처럼 7장에서는 위협 모델을 통해 무엇을 방어해야 하는지를 명확히 정의한 후, 보안 자동화 도구를 사용해 어떻게 방어할지를 실질적으로 보여줍니다.

성능 테스트 (8장)

성능은 사용자 경험과 매출에 직결되는 중요한 요소로, 이 책에서는 다양한 사례와 통계를 통해 성능 최적화가 왜 중요한지 설득력 있게 보여줍니다.

• 페이지 로드 시간 0.5초 증가 시, 사용자 이탈률이 20% 증가

• 2018년 아마존 프라임데이 장애 시, 약 1억 달러의 손실 발생

• 모비파이(Mobify)는 로딩 시간 100ms 감소만으로 연간 매출 38만 달러 증가 효과

성능 지표를 체계적으로 관리하기 위해 책에서는 RAIL 모델을 소개합니다.

RAIL 모델

• 구글이 제안한 웹 성능 측정 및 최적화 가이드라인으로, Response, Animation, Idle, Load 네 가지 항목으로 나누어 성능을 모니터링하고 개선합니다.

• 각 단계별 목표 시간(예: 사용자의 액션에 100ms 내로 반응해야 한다 등)이 명시되어 있어 구체적인 목표 설정이 가능합니다.

• 자세한 내용은 RAIL Model (Web MDN)에서 확인할 수 있습니다.

8장에서는 이런 성능 지표와 함께 로드 테스트, 부하 테스트 등 다양한 테스트 전략을 다루며, 실제로 어떻게 성능 병목 구간을 찾아내고 개선할 수 있는지 현실적인 가이드를 제공합니다.

접근성 테스트 (9장)

처음에는 “이런 것까지 꼭 테스트해야 하나?” 싶을 수 있지만, 실제로는 접근성이 사용자 경험에 큰 영향을 미치며 법적·윤리적 측면에서도 점점 중요해지고 있습니다. 책에서는 WCAG 2.0의 기본 원칙을 기반으로 접근성을 보장하는 방법을 체계적으로 설명합니다.

WCAG(Web Content Accessibility Guidelines) 2.0

• W3C(월드 와이드 웹 컨소시엄)에서 제정한 웹 콘텐츠 접근성 지침입니다. 인식 가능(Perceivable), 운용 가능(Operable), 이해 가능(Understandable), **견고성(Robust)**의 4대 원칙을 제시합니다.

• W3C 공식 문서를 통해 더 자세한 내용을 확인할 수 있습니다(현재는 2.1이 최신 버전입니다.)

또한 WAVE, Lighthouse 같은 자동화 도구부터 스크린 리더 테스트, 키보드 전용 사용성 확인 등 실제로 접근성을 개선하기 위한 다양한 검증 방법이 소개됩니다.

• WAVE: 웹 페이지 접근성을 분석하고, 시각적으로 문제가 되는 영역을 표시해주는 도구

  • WAVE 공식 웹사이트

• Lighthouse: 구글이 제공하는 오픈 소스 도구로, 크롬 개발자 도구에서 바로 접근성·성능·SEO 등을 점검할 수 있음

  • Lighthouse 공식 문서

• 스크린 리더: 시각 장애인을 위한 화면 낭독 소프트웨어(JAWS, NVDA 등)

  • JAWS 공식 웹사이트

  • NVDA 공식 웹사이트

9장을 통해 접근성은 그저 _추가 기능_이 아니라, 서비스 전반의 설계 철학이라는 저자의 통찰을 배울 수 있습니다.

책 활용 방법

개인적으로 느꼈을 때 이 책을 활용할 수 있는 가장 좋은 방법을 정리해봤습니다.

1. 1장 먼저 정독하기

   • 1장은 이 책의 서론 격으로, ‘풀스택 테스트’의 기본 개념과 시프트 레프트 전략 등 핵심 골자를 제시합니다.

   • 이를 꼼꼼히 읽어본 뒤, *“아, 이런 종류의 테스트가 있구나”*라는 큰 그림을 잡으면 이후 각 장을 선택적으로 보기에 훨씬 수월해집니다.

2. 현업(또는 현재 프로젝트)에 필요한 테스트 기술 파악

   • 1장을 통해 전체 목록을 살펴본 뒤, 지금 당장 필요한 영역(예: 성능, 보안, 접근성 등)을 우선적으로 찾아봅니다.

   • 목차나 장별 요약을 참고해 구체적인 전략과 도구 사용법을 빠르게 확인하고, 필요한 부분만 집중 공략해도 좋습니다.

3. 백과사전처럼 필요할 때마다 참고

   • 이 책은 각 챕터의 구성이 비슷한 패턴(구성 요소 → 전략 → 실습 → 추가 테스트 도구 → 인사이트)으로 되어 있어, 원하는 테스트 기술을 바로 찾아보고 참고하기 쉽습니다.

   • 실제 프로젝트에서 “보안 취약점 스캔 방법이 궁금하다”거나 “UI 일관성 테스트를 어떻게 자동화할까?” 같은 구체적 고민이 떠오를 때마다 관련 챕터를 찾아보세요.

개인적인 감상평

처음 이 책을 펼쳤을 때, 테스트 분야를 거의 전 영역에 걸쳐 소개한다는 점이 가장 인상적이었습니다. 특히 1~2장에서 전반적인 테스트 개념과 ‘왜 테스트가 중요한지’에 대한 설득이 잘 이루어져, 평소 테스트에 대해 피상적으로 알던 제게 많은 통찰을 주었습니다.

성능 테스트에 대한 8장 역시 실제 업무에서 바로 활용할 수 있을 정도로 구체적인 예시와 전략을 다뤄 큰 도움이 됐습니다. 다만 전체적으로 예제 코드나 프로젝트별 튜토리얼이 조금 더 풍부했으면 어땠을까 하는 아쉬움도 있습니다. 실제로 테스트 전략을 구성해본 경험이 적은 독자에게는 다소 이론적이라고 느껴질 수 있을 것 같습니다.

결론 및 추천

“풀스택 테스트”는 테스트 기법 전반을 폭넓게 다루고 있어, 개발자나 QA 엔지니어가 테스트의 중요성과 다양한 기법을 빠르게 파악하기에 좋습니다. 특히 보안, 성능, 접근성처럼 실무에서 간과하기 쉬운 분야를 체계적으로 설명하기 때문에, 이를 업무에 적용해보고 싶은 분들에게 권장할 만합니다.

백과사전형 구성 덕분에 필요한 챕터부터 골라 읽을 수 있다는 점도 장점입니다. 초중급 개발자는 물론, 테스트 전략 수립에 관심 있는 모든 IT 종사자에게 이 책을 추천합니다. 특히 1장을 통해 전체 테스트 기법을 먼저 파악한 뒤, 자신의 프로젝트 상황에 맞춰 해당 테스트 분야를 집중적으로 살펴보는 것을 권장합니다.

"한빛미디어의 후원으로 책을 받아 작성합니다."

정말 길었던 한 해였기 때문에 연간 회고에 적고 싶은 이야기가 굉장히 많지만 그 중에서 커리어, 기록, 여행, 관계 이렇게 4가지 키워드를 중심으로 2024년을 기록해보려고 한다.

커리어 그리고 병역시작!

먼저 가장 축하하고 싶은 일이다! 4월에 입사하면서 전문연구요원을 시작해서 벌써 9개월차가 됐다. 지금까지 계속 스트레스 받던 일인데 시작하고 나니까 속이 후련하다. 3년을 할 바에는 1년 반 육군을 갔다와야 하나 고민을 수십번을 했고 대학원을 괜히 갔나 후회도 많이 했는데 지금에와서 생각하니 배부른 소리였다.

10월에 훈련소를 갔다오고 나니까 1년 반 육군은 말이 안되는 소리라는 걸 알게 됐다. 휴가 갔다온다고 생각하고 갔는데 전혀 아니었다. 앞으로는 군대가 낫다는 소리를 절대 안하려고 한다. 뭐가 됐든 사회가 좋다.

취업 준비부터 시작해서 취업까지 약 3개월이 걸렸는데 다시 돌아보니 정말 운이 좋게 착착 진행됐던 것 같다. 이력서 준비하는 과정부터 시작해서 내가 고민이 있을 때 경청해주고 조언을 해준 부모님과 주변 동료, 선배들에게 너무 감사하다. 지금같이 어려운 시기에 내가 목표했던 조건의 회사에 적절한 시기에 들어갈 수 있었던 건 정말 운이 많이 도와준 것 같다.

취직 준비를 하면서 가장 크게 배운 점은 어떤 일을 하던 기준을 내 안에 두는 게 가장 중요하다는 것이다. 아무리 맛있는 음식이라고 주변에서 칭찬을 하더라도 내 입맛에 맞지 않으면 나에게 그 음식은 좋은 음식이 아니다. 커리어도 마찬가지다. 나와 비슷한 상황인 사람을 참고할 수는 있어도 결국은 판단은 내 몫이고 내 기준에 따라 해야 한다. 취업 준비를 하던 시기의 나는 처음 해보는 이 일이 두려워 자꾸 다른 사람에게 미루고 남들과 비교만 하며 나를 옥죄고 있었다. 주변 사람들의 조언 덕에 결국 내 커리어는 내가 원하는 커리어의 모습에 달려 있다는 걸 깨닫고 두렵지만 차근차근 준비해서 지금의 내가 있을 수 있다.

⭐2025년에는!⭐

커리어 영역에서 내 기준을 만들기 위해 계속해서 노력해야겠다.

• 어떤 기술과 업무를 맡았을 때 내가 가장 몰입하고 성장하는지 관찰하기

• 업계의 다양한 선배들을 만나 그들의 커리어 기준과 철학 배우기

• 내가 생각하는 "좋은 개발자"의 모습 정의하기

기록의 힘!

주변에 자랑하고 다니는 것 중 하나는 1년 동안 약 49개의 주간 회고를 작성했다는 것이다. 메모어 14기부터 시작해서 17기를 하고 있는 지금까지 약간의 텀을 제외하고는 짧더라도 계속 회고를 지속해왔다. 기록을 하면서 나에 대해서 더 잘 알게 되고 지금에 와서는 아예 기억도 안나는 입사 초의 감정들이 고스란히 회고에 남아있다. 앞으로도 회고는 꾸준히 가져가야 할 내 습관 중 하나가 됐다. 일요일 10시만 되면 놀고 있던 쉬고 있던 일어나 회고를 적는 내 모습 너무 뿌듯하다.

특히, 감정에 대한 회고는 그 당시에 이유없이 느껴졌던 불안감이나 우울함을 객관적으로 바라보게 해주기 떄문에 너무 소중한 기록이다. 2022년 말부터 학교에서 심리상담을 받으면서 '나'를 알기 위해 노력했던 것들이 지금에 와서 회고로 완성된 것 같다. 어떤 상황에서 내가 어떤 감정을 느끼는지 파악하고 다음에 비슷한 상황이 왔을 때 더 빠르게 인지하고 조치를 취할 수도 있게 됐다는 게 자랑스럽다. 조만간 그때 심리상담사 선생님께 연락드려 감사함과 성장한 내 모습을 전해야겠다.

처음에는 회고 쓰는 것도 어려웠는데 어느 순간부터 아래처럼 내가 기록하고 싶은 내용, 관점을 중심으로 회고 포맷이 계속 변해왔다. 아래는 2024년 18주 때 썼던 신입 사원의 고충과 52주 때 썼던 여전히 고민하는 내 모습이 담긴 회고다. 까맣게 잊고 있었는데 그때의 감정이 다시금 새록새록 떠오른다.

⭐2025년에는!⭐

• 지금처럼 주간 회고 작성하는 습관을 유지하기

• 월간회고, 분기별 회고를 추가하여 생각을 더 정돈하기

• 기록을 통해 나에 대해서 더 알기 위해 노력하기

여행, 추억 만들기

이번 년도에 잘했던 일 중 하나로 여행도 소개하고 싶다. 2024년 전에는 해외 여행을 일본 오키나와와 규슈 지방 한 바퀴 돈 것 제외하고는 없었다. 그런데 2024년에만 대만, 필리핀, 홍콩, 일본 4개국에 총 5번이나 방문했다. 회고 하기 전까지는 이게 전부 1년 안에 일어난 거라고 생각도 못했다. 모든 여행이 내게 의미 깊은 날들이었어서 공유해보려고 한다.

• 1월 대만, 나홀로 첫 해외여행

• 3월 필리핀, 입사 전 후회없는 선택

• 9월 홍콩, 훈련소 입소 전 후회없는 선택, 여자친구와 첫 해외 여행

• 12월 일본 후쿠오카, 대학 친구들과 첫 해외 여행

• 12월 도쿄, 생일, 크리스마스, 여자친구와 500일 기념 여행!

가장 헤프닝이 많았던 여행이 1월 대만여행이다. 고등학교 친구와 같이 가기로 했었는데 예약까지 다 했더니 이 친구가 여권이 2년 전에 만료됐는데 이미 여권 신청을 해서 긴급여권 발급도 안되는 상황이 돼버렸다. 그래서 결국 나 혼자 떠나게 됐다.

의도치 않게 홀로 떠나는 첫 해외여행이 됐지만 너무 뜻깊은 시간이었다. 우연히 인도인 친구를 사귀어서 같이 하루를 보내고 친구의 친구 소개로 알게 된 홍콩, 대만 친구들과 대만식 훠궈도 먹어봤다. 버스투어 갔을 때는 혼자 온 한국인 관광객 2명과 파티를 맺어서 신나게 돌아다녔고 마지막 날에는 5년 만에 만나는 고등학교 친구가 우연히 대만에 왔다고 해서 같이 야시장을 돌았다.

우연으로 시작했지만 내게는 너무 좋은 기회가 됐고 이후 좋은 일도 있었고 나쁜 일도 있었지만 결국 다양한 사람을 경험해볼 수 있었고 나의 취향에 대해서 충분히 고민하고 행동할 수 있는 시간이었다.

이 여행으로 가장 크게 배운 점은 두가지다.

• 이동 동선 만큼은 꼭 미리 짜두자. 미리 고려하지 않은 만큼 시간 손해를 본다.

• 그 나라 언어 공부는 얕게라도 꼭 하고 가자. 외국에 나가면 우리는 그냥 아시아인 1이다. 영어 안 통하는 곳이 많다.

⭐2025년에는!⭐

• 일본어로 자기소개할 수 있도록 연습하기

• 가족들과 여행 가보기

관계

2024년은 관계를 통해 내가 바라고자 하는 모습을 실현하고자 노력하는 해였다. 4차 산업혁명의 시대, 자기를 혁신하는 방법이라는 영상에서 본 "당신을 설명하는 사람은 최근에 만난 5명"이라는 말이 큰 영향을 주었다. 결국 내 주변에는 내 생활 패턴과 비슷한 사람들이 주로 남게 된다는 것이었다. 반대로 생각하면 내가 어떤 사람이 되고 싶은가에 따라서 주변에 어떤 사람을 둬야 하는지가 결정되는 것이다.

2024년의 내가 바라는 모습은 성장, 일 잘하기, 글쓰기라는 키워드로 설명할 수 있을 것 같다.

• 성장: 메모어에서 성장과 회고에 관심이 많은 사람들을 만났다.

• 일 잘하기: 셀프그로쓰 스터디를 통해 회사 생활을 잘하는 법에 관심있는 동료들을 만났다.

• 글쓰기: 글또에서 글쓰기를 잘하고 싶어하는 사람들을 만났다.

성장, 일 잘하기, 글쓰기에 관심이 많은 사람들을 가까이 하면서 1년이 지난 지금은 기록과는 거리가 먼 내가 매주 회고를 하는 습관을 가진 사람이 됐고, 죽어있던 내 블로그에도 매달 2편의 글이 올라오고 있다. 그리고 처음 회사에서 혼자 끙끙 앓던 내가 이제는 회사에서 고민이 있을 때면 동료들과 함께 논의할 수 있는 내가 됐다!

다들 너무 고마운 존재들이고 앞으로 이런 커뮤니티에 나는 어떤 기여를 할 수 있을까? 어떻게 하면 좋은 영향을 주는 사람이 될 수 있을까를 계속해서 고민해서 받은 것의 배로 돌려주고 싶다.

⭐2025년에는!⭐

• 각 영역별로 롤모델이 되는 멘토 찾기

• 일회성 만남이 아닌 지속적인 관계 맺기에 집중하기

• 받기만 하는 것이 아닌 서로 도움이 되는 관계 만들기

이번에 회사에서 후기 서비스를 개발하고 있다. 요구사항 중에 후기에는 최대 5개의 사진이 포함된다는 항목이 있었다. API 서버를 Aws Lambda로 만들고 있어서 Api Gateway의 payload 크기 제한인 10MB, Lambda의 payload 크기 제한이 6MB로 이미지 업로드 크기에 제한이 생기는 문제가 있다. 참고: Amazon API Gateway 할당량 및 중요 정보, AWS Lambda 할당량

또한 Lambda로 이미지를 업로드하는 경우에는 이미지 업로드 후 S3로 업로드라는 과정까지 추가되므로 이미지를 올리는 데 더 많은 시간이 소요되고 소요되는 만큼 lambda 비용이 추가적으로 나온다는 문제도 있다.

오늘은 이 문제를 해결하기 위해서 클라이언트에서 직접 s3로 파일을 업로드하는 방법들 최종적으로 선택했던 s3-presigned-post 방식에 대해서 포스팅하려고 한다.

해결책 1: API Gateway S3 Proxy

우선 API Gateway를 통해서 S3에 접근하는 방법이 있다. 이 방법은 S3를 public으로 만들지 않아도 S3에 접근할 수 있도록 할 수 있고 API Gateway의 보안 기능들을 활용할 수 있다. 그리고 Lambda를 통하지 않아도 되니 추가적인 비용이 들지도 않고 Lambda의 payload 크기 제한이 6MB가 넘는 파일도 다룰 수 있게된다.

그런데 이 방법은 여전히 10MB의 payload 제한이 있다는 단점이 있어서 이번에는 선택하지 않았다.

해결책 2: S3 presigned url

다음으로 고려했던 방법은 presigned url이었다. S3에 저장된 파일에 접근할 수 있는 권한 정보를 url에 인코딩하여 서버에서 클라이언트로 보내주면 그 url을 이용해서 파일을 조회하거나 업로드할 수 있는 기능이다.

구현이 매우 간단하고 url의 유효시간을 조절할 수 있어 유용하다.

서버에서 업로드를 관리하지 않으니 업로드 속도도 더 빠르고 파일이 커서 lambda payload limit에 걸리거나 lambda timeout이 생기는 일도 발생하지 않는다.

s3 presigned url 방식 서버 코드 예시

const { S3Client, PutObjectCommand } = require("@aws-sdk/client-s3");
const { getSignedUrl } = require("@aws-sdk/s3-request-presigner");

const s3 = new S3Client({ region: process.env.AWS_REGION });

module.exports.generateSignedUrl = async ({
  key,
  contentType,
  expiresIn = 3600,
}) => {
  const command = new PutObjectCommand({
    Bucket: process.env.BUCKET_NAME,
    Key: key,
    ContentType: contentType,
  });

  const signedUrl = await getSignedUrl(s3, command, { expiresIn });
  return signedUrl;
};

s3 presigned url 방식 클라이언트 코드 예시

const getUploadUrl = async (params: {
  key: string
  contentType: string
}): Promise<string> => {
  return axios
    .post('/generate-presigned-url', {
      ...params,
    })
    .then((res) => res.data);
}

const file = "<form으로 업로드한 파일>"
const uploadUrl = await getUploadUrl({ key, contentType: file.type })요청

const response = await fetch(uploadUrl, {
    method: 'PUT',
    body: file,
    headers: {
      'Content-Type': file.type,
    },
})

if (!response.ok) {
    throw new Error('파일 업로드 실패')
}

s3 presigned url 방식의 한계

클라이언트 측에서 파일 업로드를 전부 제어하기 때문에 content type, 파일 사이즈 등을 서버에서 컨트롤 할 수 없다는 문제가 있다. IAM 정책을 통해서 일부 제약을 걸 수도 있지만 이 경우에는 S3 전체에 적용되기 때문에 상황에 따라 유연하게 사용하기가 어렵고 인프라에서 관리하게 되니 눈으로 확인하기 어렵다고 느껴졌다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": ["s3:PutObject", "s3:PutObjectAcl"],
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-meta-file-type": ["image/jpeg", "image/png"]
        }
      }
    }
  ]
}

해결책3: S3 presigned post

마지막으로 찾아본 방법은 s3 presigned post를 활용하는 방식이다.

presigned post는 presigned url과 유사하게 s3의 특정 객체에 일시적으로 접근할 권한을 주는 방식이다. 여기에 conditions를 통해서 업로드하는 파일에 제약을 걸 수 있다. Conditions는 AWS S3 POST Policy 문서를 참고하여 작성할 수 있다.

이번에는 파일 사이즈, 파일 타입, 업로드할 폴더 정도만 제약을 걸면 되서 다음과 같은 조건들을 사용했다.

[
  ['content-length-range', 0, options.maxFileSize], // 파일 크기 제한
  ['starts-with', '$Content-Type', options.allowedMimeType], // MIME 타입 제한
  ['starts-with', '$key', prefix], // 파일 키는 특정 prefix로 시작
]

S3 presigned post 서버 코드 예시

import { S3Client } from '@aws-sdk/client-s3';
import { createPresignedPost } from '@aws-sdk/s3-presigned-post';
import { ulid } from 'ulid';

const s3Client = new S3Client({
  region: process.env.AWS_REGION,
});

export async function generatePresignedPost(
  bucketName: string,
  prefix: string,
  options: {
    maxFileSize: number;
    expirationSeconds: number;
    allowedMimeType: string;
  },
) {
  const fileKey = `${prefix}${ulid()}`;

  const post = await createPresignedPost(s3Client, {
    Bucket: bucketName,
    Key: fileKey,
    Expires: options.expirationSeconds,
    Conditions: [
      ['content-length-range', 0, options.maxFileSize], // 파일 크기 제한
      ['starts-with', '$Content-Type', options.allowedMimeType], // MIME 타입 제한
      ['starts-with', '$key', prefix], // 파일 키는 특정 prefix로 시작
    ],
  });

  return post;
}

위 함수를 실행하면 resource에 접근할 수 있는 url과 옵션으로 준 값들을 바탕으로 생성된 fields가 포함된 응답이 나온다.

{
    "url": "https://s3.<aws_region>.amazonaws.com/<bucket_name>",
    "fields": {
      "bucket": "<BUCKET_NAME>",
      "X-Amz-Algorithm": "AWS4-HMAC-SHA256",
      "X-Amz-Credential": "...",
      "X-Amz-Date": "20241220T073342Z",
      "X-Amz-Security-Token": "base64로 인코딩된 token",
      "key": "path/to/your/file",
      "Policy": "jwt로 인코딩된 policy",
      "X-Amz-Signature": "..."
    }
}

s3 presigned post 클라이언트 코드 예시

위의 서버측 응답의 url로 업로드할 파일과 fields의 값들을 formData에 넣어서 POST 요청을 하면 업로드할 수 있다.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>S3 Presigned POST Upload</title>
</head>
<body>
    <h1>Upload File to S3</h1>
    <input type="file" id="fileInput" />
    <button id="uploadButton">Upload</button>

    <script src="upload.js"></script>
</body>
</html>

document.getElementById('uploadButton').addEventListener('click', async () => {
    const fileInput = document.getElementById('fileInput');
    const file = fileInput.files[0];

    if (!file) {
        alert('Please select a file to upload.');
        return;
    }

    // Presigned POST 응답을 가져오는 API 호출 (예: Lambda 함수)
    const response = await fetch('/api/getPresignedPost'); // 실제 API 엔드포인트로 변경
    const presignedPost = await response.json();

    const formData = new FormData();

    // Presigned POST의 필드 추가
    Object.entries(presignedPost.fields).forEach(([key, value]) => {
        formData.append(key, value);
    });

    // 파일 추가
    formData.append('file', file);

    // S3로 파일 업로드
    const uploadResponse = await fetch(presignedPost.url, {
        method: 'POST',
        body: formData
    });

    if (uploadResponse.ok) {
        alert('File uploaded successfully!');
    } else {
        alert('File upload failed.');
    }
});

결론

서버리스 환경에서 사진을 업로드하려면 Lambda와 API Gateway의 제한(예: 10MB, 6MB)과 Lambda 실행 비용·시간을 모두 고려해야 합니다. 이러한 제약을 해결하면서도, 후기 서비스나 이미지 업로드가 많은 환경에서 유연하고 효율적인 방안을 원한다면, “S3 Presigned Post” 방식이 탁월한 선택입니다.

• 별도의 Lambda 처리 없이 직접 업로드가 가능해, Lambda 비용과 응답 지연을 줄일 수 있습니다.

• 파일 크기, MIME 타입, 파일 경로 등 세부 조건을 정책(conditions)으로 설정해 업로드를 유연하게 제어할 수 있습니다.

• API Gateway의 페이로드 제한과 Lambda의 메모리·타임아웃 문제에서 자유로울 수 있어, 대규모 트래픽이나 대용량 파일 업로드에도 안정적으로 대응 가능합니다.

결국, 서버리스 환경에서 필요 이상의 비용·시간을 소모하지 않으면서도 확장성과 보안성을 모두 담보할 수 있다는 점이 “S3 Presigned Post” 방식의 가장 큰 장점입니다. 앞으로 후기 서비스를 비롯한 다양한 이미지 업로드 시나리오에서 이 방식을 고려해보셔도 좋을 것 같습니다.

참고자료

• AWS API Gateway 할당량 및 중요 정보

• AWS Lambda Limits

• AWS S3 Presigned Url

• AWS S3 Presigned Post

• Delivering images in AWS S3 bucket through AWS API gateway

개발자님! 화면이 너무 늦게 떠요!!

이번 주에 매출 통계 기능을 개발해서 개발 서버에 올렸는데 테스팅을 하다가 갑자기 긴급 호출이 들어왔다. API 속도가 너무 느리다는데 얼마나 느리길래 그런지 확인해봤더니 무려 10~16초가 걸렸다.

신규 레포지토리를 파서 개발한 거라 설정에 문제가 있었나? VPC 간 통신 때문에 지연되는 건가? 별의별 생각이 다 들어서 각 모듈별로 실행되는 시간, 실제 쿼리하는 시간을 전부 측정해봤는데 10~16초나 걸릴 만한 이유를 찾지 못했다.

실제 동작이 query string 받아서 SELECT * From table WHERE a = ? AND b = ? ORDER BY c DESC 정도만 수행하는 아주 간단한 API 였는데, 너무 이상한 수치였다.

CloudWatch 로그를 아무리 뒤져봐도 에러도 보이지 않았고,
코드의 각 부분이 실행되는 시간을 측정해봐도 2초 이내에 모든 실행이 완료되고 있었다.

이상한 점은,

• 지정한 동작(쿼리 실행, 결과 가공 등)은 모두 끝났는데도

• 응답을 바로 반환하지 않고 6초 이상 대기한 뒤에야 응답을 반환하고 있다는 것

이었다.

즉, “로직은 다 끝났는데, 어딘가에서 응답이 붙잡혀 있는 상태” 였다.

Connection Pool과 유휴 연결

결론부터 말하면, 문제의 1차적인 원인은

connection pool의 유휴 연결 때문에 Node.js 이벤트 루프가 완전히 비지 않았고,
그로 인해 Lambda가 응답을 바로 반환하지 못하고 지연이 발생한 것이었다.

사용하고 있던 라이브러리는 pg.Pool이었고, idleTimeoutMillis 기본값은 10초다.
node-postgres 문서의 설명은 다음과 같다:

number of milliseconds a client must sit idle in the pool and not be checked out
before it is disconnected from the backend and discarded
default is 10000 (10 seconds) – set to 0 to disable auto-disconnection of idle clients

즉, 한 번 빌려갔다가 돌려준 커넥션이 최소 10초 동안 idle 상태로 pool 안에 남아 있고, 이 동안에는 소켓/타이머 레퍼런스가 살아 있기 때문에 Node.js 이벤트 루프 입장에서는 “아직 완전히 idle이 아니다” 라고 보는 것이다.

Lambda handler 방식과 이벤트 루프의 관계

여기서 자연스럽게 이어지는 질문은 이것이다.

“idle connection이 이벤트 루프를 잡고 있는 건 알겠는데,
이벤트 루프가 안 비면 왜 응답이 늦게 나가는 걸까?”

그 이유는 Lambda handler 방식 때문이다.

Node.js에서 Lambda handler는 크게 두 가지 방식이 있다.

1. async/await 기반

    exports.handler = async (event, context) => {
      const result = await doSomething(event);
      return {
        statusCode: 200,
        body: JSON.stringify(result),
      };
    };
   

2. callback 기반 (공식 문서 기준으로 Node.js 22.x까지만 지원된다)

    exports.handler = (event, context, callback) => {
      doSomething(event, (err, result) => {
        if (err) {
          return callback(err);
        }
        callback(null, {
          statusCode: 200,
          body: JSON.stringify(result),
        });
      });
    };
   

callback 방식에서는 기본적으로

• 콜백을 호출한 뒤에도

• 이벤트 루프에 남아 있는 작업(타이머, 소켓 등)이 모두 사라질 때까지,

• 또는 함수 타임아웃에 도달할 때까지

실행을 계속 유지하려는 동작을 한다.

그래서 callback 방식으로 구현한 상태에서 이벤트 루프를 붙잡고 있는 idle connection이 있으면,
로직은 이미 끝났는데도 응답이 바로 나가지 않고 지연되는 상황이 만들어질 수 있다.

fastify-aws-lambda 내부는 callback 기반이었다

Fastify 앱을 Lambda로 올릴 때 우리는 아래와 같은 형태로 간단하게 래퍼만 호출하고 있었다.

const awsLambdaFastify = require('@fastify/aws-lambda');
const { createApp } = require('./createApp');

const app = createApp();
const proxy = awsLambdaFastify(app);

module.exports.handler = proxy;

코드만 보면 이 핸들러가 async/await 기반인지, callback 기반인지 전혀 알 수 없다.

그런데 내부 구현을 확인해보니, aws-lambda-fastify는 Fastify 앱을 감싸면서 최종적으로 Lambda에 등록되는 handler를 (event, context, callback) 형태의 callback 기반으로 생성하고 있었다.

그 결과,

• callback 스타일의 **기본 동작(이벤트 루프가 완전히 빌 때까지 실행을 유지하려는 동작)**이 그대로 적용되고

• pg.Pool의 idle connection이 이벤트 루프를 비우지 못하는 상황과 맞물리면서

• 로직은 이미 다 끝났는데도 응답이 수 초 동안 지연되는 현상이 발생했다.

해결방법

1) Lambda context.callbackWaitsForEmptyEventLoop = false

먼저, Node.js Lambda의 Context 객체는

함수 이름, 버전, 메모리 등 실행 환경에 대한 정보와 몇 가지 설정 값을 제공하는데,
그중 하나가 callbackWaitsForEmptyEventLoop다. 이 값은 callback 기반 핸들러에서만 의미가 있는 옵션이다.

문서 설명을 보면:

Node.js 이벤트 루프가 빌 때까지 대기하는 대신, 콜백이 실행될 때 즉시 응답을 보내려면 false로 설정합니다.
이것이 false인 경우, 대기 중인 이벤트는 다음 번 호출 중에 계속 실행됩니다.

즉, 이 값을 false로 설정하면

• 이벤트 루프가 완전히 비기까지 기다리지 않고

• 이미 준비된 응답을 바로 반환하고

• 남아 있는 타이머/소켓 같은 것들은 다음 호출에서 재사용될 수 있도록 놔두는

동작을 하게 된다.

Fastify를 Lambda로 올릴 때는 aws-lambda-fastify를 통해 handler를 만들고 있었기 때문에,
이 옵션을 래퍼에 직접 넘겨서 동작을 바꿔줄 수 있었다.

const proxy = awsLambdaFastify(app, {
  callbackWaitsForEmptyEventLoop: false,
});

module.exports.handler = proxy;

이렇게 설정한 이후에는 로직이 끝난 시점과 클라이언트가 응답 받는 시점이 거의 일치하게 바뀌었고,
10초 가까이 붙잡혀 있던 지연 현상도 없어졌다.

2) 유휴 연결시간 줄이기

유휴 연결시간 자체를 줄여서 이벤트 루프에 idle 연결이 더 짧게 남도록 조정하는 방법도 시도했봤다.

const { Pool } = require('pg');

const pool = new Pool({
  idleTimeoutMillis: 1000, // 1초로 설정
});

기본값(10초)으로 설정했을 때보다 확실히 응답 시간이 줄어들긴 했지만,
여전히 응답이 준비된 이후에 잠깐의 대기 시간이 생기는 문제가 있었다.

그렇다고 idleTimeoutMillis를 너무 짧게 설정하면,
비용이 큰 데이터베이스 연결을 Lambda가 실행될 때마다 계속 새로 시도해야 하는 문제가 생긴다.

결국,

• context.callbackWaitsForEmptyEventLoop = false로 응답을 먼저 보내도록 만들고

• idleTimeoutMillis는 사용 패턴에 맞는 적절한 값으로 조정하는 것

이 현실적인 타협점이라고 판단했다.

결론

삽질했던 시간보다 훨씬 간단하게 해결한 문제였다.

이번에 겪은 일은, 결국 내가 사용하고 있는 플랫폼에 대한 이해 부족에서 비롯된 문제였다. 요즘은 AWS 서비스들이 워낙 잘 되어 있다 보니 “설마 인프라 쪽에 원인이 있겠어?”라는 생각으로, 코드만 붙잡고 있었던 것도 한몫했다. 앞으로는 코드에만 집중하기보다, 런타임·플랫폼·네트워크까지 포함해서 문제를 좀 더 다각도로 바라보려 한다.

이번에 크게 느낀 점은 두 가지다.

• 첫째, 라이브러리의 겉 API만 보지 말고, 중요한 경계(Lambda handler, DB 커넥션, 이벤트 루프 등)를 다루는 부분의 구현은 한 번쯤 직접 뜯어보자는 것이다. 이번에도 aws-lambda-fastify 내부가 callback 기반이라는 사실을 알고 나서야 퍼즐이 맞춰졌다.

• 둘째, 서버리스를 사용할 때는 기본 동작과 내가 적용한 설정이 어떻게 맞물리는지 반드시 이해해야 한다. Lambda의 실행 모델, handler 방식(async/await vs callback), Connection Pool의 동작 방식, idleTimeoutMillis, callbackWaitsForEmptyEventLoop 같은 설정은 실제 성능과 응답 지연에 직접적인 영향을 준다. “서버리스니까 알아서 처리해주겠지”라는 기대보다는, 내 코드가 서버리스 환경에서 어떻게 실행되는지 명확히 이해하고 사용하는 것이 중요하다는 점을 다시 한 번 느꼈다.

이런 것들을 한 번 겪어두면, 다음 비슷한 장애가 왔을 때 “코드만 들여다보는” 시간은 조금 줄어들 거라고 기대하고 있다.

참고자료

• NodeJS 와 PostgreSQL Connection Pool

• AWS Lambda RDS connection timeout

• https://gist.github.com/streamich/6175853840fb5209388405910c6cc04b

• https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/nodejs-context.html

• https://dev.to/dvddpl/event-loops-and-idle-connections-why-is-my-lambda-not-returning-and-then-timing-out-2oo7

• https://en.wikipedia.org/wiki/Connection_pool

들어가며

회사에 입사한 지 8개월이 지나면서, 업무에 대한 익숙함과 함께 막연한 불안감이 찾아왔다. 특히, 반복되는 이슈 처리와 해결 과정에서 '이렇게 계속해도 내 커리어에 도움이 될까?'라는 의문이 들었다. 이러한 고민을 해소하고자 시니어 개발자이신 개발전략실 이사님과 개발자는 아니지만 함께 일하고 있는 팀장님께 개인적인 성장과 회사일의 관계, 회사 생활 잘하는 법 등 조언을 구했다.

두 분 모두 친절하게 답변해주셨고 어느 정도 실마리를 얻은 것 같은 기분이 들었다. 아직은 더 생각해봐야 할 것들이 많아서 글로 정리하면서 생각을 좀 정리하려고 한다.

회사가 기대하는 내 연봉의 3배 가치, 나는 충분히 하고 있을까?

이사님과의 대화에서 가장 인상 깊었던 부분은 "회사가 굴러가기 위해서는 직원이 받는 연봉의 2배, 3배 이상의 가치를 만들어줘야 한다"는 말이었다. 지금까지 연봉에 대한 불만만 품었던 나는 이 말을 듣고 큰 충격을 받았다. 한 번도 회사가 나를 어떤 시선으로 바라보고 어떤 기대를 하고 있는지는 진지하게 생각해본 적이 없었던 것 같다. 나는 과연 회사가 기대하는 만큼의 성과를 내고 있는 걸까? 스스로에게 묻게 된 순간이었다.

또한, 이사님은 생산성의 핵심은 짧은 시간 안에 팀이 추구하는 방향으로 결과를 만들어내는 것이라고 설명해주셨다. 단순히 오래 일한다고 해서 생산성이 높아지는 게 아니라는 것이다. 오히려, 팀의 방향성과 맞지 않는 일은 아무리 많이 해도 결국 의미가 없다고 강조하셨다.

이 대화를 통해 깨달은 점은 내가 회사와 고용주가 기대하는 가치를 제대로 이해하지 않았다는 것이 불안감의 원인 중 하나였다는 것이다. 앞으로는 불만을 느끼기만 할 것이 아니라, 내가 회사에 어떤 가치를 제공할 수 있을지, 그리고 그 가치를 더 높이기 위해 무엇을 할 수 있을지 먼저 고민해 보자고 마음먹었다.

안주하지 말고 업무 범위를 넘나들며 확장하기

이사님과 대화를 통해서 깨달은 다른 교훈 중 하나는 업무 범위를 넘나드는 자세였다. 연봉대비 효율성을 높이기 위해서는 맡은 일에만 안주하지 말고 업무범위를 넘나들며 내 범위를 확장하는 것이 필요하다고 했다. 물론 무조건적으로 다른 영역의 일을 침범하라는 의미가 아니라, 기회가 왔을 때 적극적으로 참여하라는 것이었다.

팀장님과의 1대1 미팅에서도 비슷한 이야기가 나왔다. 내가 잘하고 있는지에 대해 고민을 털어놓자, 팀장님은 "잘하고 있는지의 기준은 자신이 정해야 한다"고 말씀하셨다. 하지만 덧붙여, 자신의 업무 범위를 넘어서 팀의 공백을 메우고, 커뮤니케이션 비용을 줄이는 데 기여하는 사람이 일을 잘하는 사람이라고 하셨다. 예를 들어, 어드민 도구 기획에서 미리 사용성과 필요한 기능을 고려해 설계한 덕분에 팀의 커뮤니케이션 비용을 줄일 수 있었던 사례를 언급해주셨다. 기획자가 맡았어야 할 업무를 내가 먼저 해결했기 때문에 더 효율적인 작업이 가능했던 것이다.

또한, 업무 범위를 확장하는 것이 중요한 이유는 조직이 성장할수록 더 많은 빈 공간이 생기기 때문이다. 특히 스타트업에서는 인원이 적을 때 한 사람이 여러 역할을 맡지만, 회사가 커지면서 각자의 역할이 분명해질수록 아무도 맡지 않는 일이 생겨난다. 바운더리를 넘나드는 사람은 이 빈 공간을 자발적으로 메우고, 회사가 기대하는 이상을 충족하는 중요한 역할을 한다. 이러한 노력은 단순한 성과 이상의 가치를 만들어낸다. 바운더리를 확장하며 노력하는 사람은 동료들에게 신뢰받고 함께 일하고 싶은 동료로 기억된다. 결국, 맡은 일에만 머무르지 않고 확장하고자 할 때, 나의 성장과 함께 동료들의 신뢰를 얻을 수 있는 것이다.

인맥의 중요성과 이를 효과적으로 활용하는 방법

이사님과 팀장님과의 대화를 통해 얻은 또 하나의 중요한 교훈은 인맥의 힘이었다. 시간이 지나면서 커리어가 깊어질수록, 우리가 정말로 잘하는 분야는 제한적일 수밖에 없다. 이때 내가 쌓아온 인맥은 그 한계를 뛰어넘어 줄 중요한 자산이 된다. 인맥은 단순한 인간관계를 넘어, 나의 성장을 도와주는 중요한 정보와 기회의 창구가 될 수 있다.

예전에 회사의 주니어, 중니어, 시니어 분들에게 "처음 보는 문제를 맞닥뜨렸을 때 어떻게 해결하시나요?"라고 물어본 적이 있었다. 시니어 분의 대답은 예상 밖이었다. 그는 "트위터나 페이스북에 있는 제 지인들에게 질문을 던질 것 같다"고 했다. 책이나 인터넷에 있는 일반적인 정보보다, 그 분야에서 오랜 시간 경험을 쌓아온 전문가의 조언이 훨씬 더 유용할 수 있다는 것이다. 이 답변은 내게 인맥이 문제 해결의 비밀 무기가 될 수 있다는 사실을 깨닫게 해주었다.

하지만 인맥을 효과적으로 활용하기 위해서는 몇 가지 팁이 필요하다. 먼저, 전문가에게 접근할 때는 구체적이고 명확한 질문을 준비하는 것이 중요하다. 예를 들어, "이 기능을 구현할 때 성능 최적화 측면에서 어떤 방법이 가장 효율적일까요?"와 같이, 문제 상황과 필요한 조언을 분명히 설명하는 것이다. 이렇게 하면 상대방이 더 쉽게 상황을 이해하고, 정확한 조언을 줄 수 있다.

또한, 전문가를 멀리서만 찾을 필요는 없다. 회사 내에도 뛰어난 전문가들이 많다. 최근에 쿠팡에서 정산을 오랫동안 맡아온 분이 우리 회사에 합류했는데, 그분께 커피 한 잔을 제안하며 자연스럽게 정산에 관한 궁금증을 물어볼 수 있다. 회사 안에서도 용기를 내어 대화의 문을 열면, 생각보다 많은 인사이트를 얻을 수 있다.

지금은 주변에 주니어들이 많아 인맥의 중요성을 크게 실감하지 못할 수도 있다. 하지만 시간이 지나면서 각자의 커리어에서 중요한 자리에 오르게 될 것이다. 나와 비슷한 위치에 있는 동료들이 시간이 흐르며 함께 성장하는 모습은 마치 복리효과가 쌓이는 것처럼, 그 가치가 점점 커질 것이다. 앞으로 이 복리효과를 제대로 누릴 수 있도록 더 많은 사람들과 의미 있는 관계를 맺어 나가야겠다고 생각했다.

마무리

이 글을 쓰면서 회사 생활에서 느꼈던 불안감과 내 성장과 회사일의 관계에 대해 다시 한 번 고민해볼 수 있었다. 그리고 주변에 나에게 도움을 줄 수 있는 분들이 많고 언제든지 내가 용기내어 손을 내민다면 기꺼이 도움을 주실 분들이라는 것도 느낄 수 있었다.

또한, 내게 주어진 것에 불평, 불만만 할 게 아니라 내가 줄 수 있는 가치가 무엇인지에 대해서도 고민하고 어떻게 하면 더 큰 가치를 줄 수 있는지에 대해서도 고민을 하게 됐다. 그리고 이 가치를 높이는 과정이 결국에는 나의 성장과 직결되는 것이라는 것도 새삼 알게 된 것 같다.

그리고 나와 함께 일하고 있는 동료들도 생각보다 훨씬 훨씬 큰 자산이라는 것도 깨달았다. 동료들과 함께 일하게 된 게 너무나 기쁜 일이고 이미 나는 많은 도움을 받고 있다는 것을 새삼 느꼈다. 앞으로 내가 그들에게 도움이 되는 존재가 될 수 있도록 열심히 노력해야겠다!

아직은 조언들을 구체적으로 어떻게 실천해야 할지는 아직은 좀 막막한 것 같다. 그래서 일단은 아래와 같은 2가지 액션 아이템을 먼저 시도해보려고 한다. 아자 아자 화이팅!

1. 월간 업무 돌아보기: 매달 말, 내가 맡았던 프로젝트나 업무를 돌아보며 내 업무 범위를 어떻게 확장했는지와 더 나아갈 수 있는 영역이 있는지 정리해보기

2. 월 1회 사내 커피챗: 회사 내에서 관심 분야의 시니어나 다른 부서의 전문가 분을 한 명 정해 월 1회 커피를 마시며 대화하는 시간 가져보기

글또 10기에 지원하면서 제 인생에 대해서 전체적으로 돌아보는 시간을 가져봤습니다. 처음에는 막막했는데 적다보니 생각보다 적을 이야기가 많고 제가 훨씬 입체적인 사람처럼 느껴지네요! 혹시나 이 글을 읽게 되신다면 한 번 자신의 삶의 지도를 작성해보셔도 좋을 것 같습니다!

[만들기를 좋아하던 성장기의 나]

잘 기억이 나지 않는 유년기의 모습 중 기억에 남는 것은 무언가를 만드는 걸 참 좋아한다는 것입니다. 블록이나 레고, 종이접기같이 뭔가 만들어내는 것을 좋아했고 언젠가는 초록매실을 만들겠다고 집 근처 매실나무에서 매실을 따서 칼질을 하다가 손이 다쳤던 것도 생각이 나네요. 이후 초, 중, 고를 나오면서도 변하지 않았던 것 같습니다. 천연효모를 만들겠다고 포도를 옷장에 넣고 발효시키던 모습과 나무를 사서 톱질하다가 손바닥을 꼬맸던 적도 있었던 것 같습니다. 결과물의 퀄리티가 그렇게 좋지 못했던 것 같은데 그래도 나름 열심히 뭔가를 만들려고 노력을 많이 했던 것 같습니다. 그나마 이때 시도했던 여러가지 중에 아직까지 유용하게 쓰고 있는 기술은 요리인 것 같네요 ;D

[프로그래밍과 첫 만남]

제가 프로그래밍을 처음 접한 건 중학교 1학년때 과학선생님이 임베디드 소프트웨어 경진대회에 데리고 나가면서였습니다. 사실 그때는 너무 못해서 블록코딩으로 주어진 로봇을 앞, 뒤, 좌, 우로 움직여서 미로 통과하는 미션만 겨우 해내고 나머지 미션들은 거의 포기했었습니다. 🤣 그럼에도 이 경험이 프로그래밍하면 가장 먼저 생각나는 이유는 이때부터 컴퓨터가 스타크래프트, 마인크래프트 머신이 아니라 생산적인 도구가 될 수 있다는 걸 알려줬기 때문입니다.

이 경험 이후로 프로그래밍에 대한 관심은 빠르게 늘어가서 중학교 3학년때 아두이노로 도어락을 만들어 무려 미래창조과학부 장관님과 악수를 했습니다! (수상한 건 아니었고 박람회 같은 곳에 전시했던 걸로 기억납니다.)

이런 일련의 사건들을 거치면서 프로그래밍에 대한 흥미는 점점 커져갔고 언제부터인가 저는 제가 경험한 프로그래밍의 즐거움과 가능성을 다른 사람들과 나누고 싶어졌습니다. 특히 처음에는 프로그래밍을 어렵게 생각하는 사람들에게, 이것이 얼마나 재미있고 유용한 도구인지 보여주고 싶었습니다.

[나의 성장 공식: 커뮤니티를 통한 지식 공유와 성장]

대학교에 진학한 후에는 프로그래밍 교육이 제 주된 관심사였습니다. 1학년때부터 지방의 중학교에 방문해서 5~6일 정도의 프로그래밍 교육을 기획해서 방학동안 캠프를 열거나 일산의 초등학교에서 주말마다 몇 주에 걸쳐서 교육하는 활동도 기획해서 운영했었고, 대학교 2학년때부터는 멋쟁이사자처럼이라는 비전공자를 위한 프로그래밍 교육 동아리에 들어가 회장, 운영진 등으로 활동하면서 웹 개발 교육 프로그램을 기획하고 실제로 교육도 진행하고 해커톤, 아이디어톤 등 다양한 행사를 개최했습니다.

이렇게 프로그래밍의 매력을 널리 알리고자 하는 열정으로 시작한 활동들은 예상치 못한 방식으로 제 자신의 성장으로 이어졌습니다. 저는 이 과정에서 중요한 깨달음을 얻었습니다. 바로 '나눔을 통한 성장'이라는 성장 공식을 발견한 것입니다.

처음에는 단순히 제가 알고 있는 것을 다른 사람들에게 전달하는 것이 목표였습니다. 하지만 교육 활동을 하면 할수록, 제가 오히려 더 많이 배우고 성장하고 있다는 것을 깨달았습니다. 질문에 답하기 위해 더 깊이 공부하게 되고, 복잡한 개념을 쉽게 설명하기 위해 노력하는 과정에서 제 지식이 더욱 단단해졌습니다. 그리고 이런 과정 중에 수백명 규모의 수강생이 있는 강의를 찍게 되는 등 예상치 못한 기회들이 들어오기도 했습니다.

이후에도 플러터라는 크로스 플랫폼 프레임워크에 관심이 생겨서 공부를 할 때도 이 성장 공식이 잘 들어맞았던 것 같습니다. 오픈 채팅방에서 열심히 활동하면서 올라오는 질문들은 공부해서 답변하고 모르는 건 같이 고민했고, 그 안에서 스터디 그룹을 만들어 같이 공부하기도 했습니다. 그리고 여기서도 좋은 기회를 만나 졸업 전에 서버, IOT기기, 애플리케이션까지 모두 외주로 개발해보는 경험도 쌓을 수 있었습니다.

[우당탕탕 대학원]

처음 대학원 진학을 결심했던 것은 웹 개발만으로는 경쟁력을 얻기 어려울 것 같다는 생각때문이었습니다. 그 당시 우후죽순 생겨나는 부트캠프들에 이대로 가만히 있어서는 뒤쳐질 것 같다는 생각에 대학교 2학년 2학기 말부터 학부 연구생 생활을 하다가 한 학기 일찍 졸업하고 대학원으로 진학을 했었습니다.

처음에는 연구실 분위기가 너무 좋고 연구 주제도 재밌어서 좋았지만 중간에 현대자동차와 함께 하는 프로젝트를 메인으로 수행하게 되면서부터 연구실 내에서 비슷한 주제의 연구를 한 사람도 없어 도움받기가 어렵고 방향성도 계속 흔들리면서 연구에 대한 흥미가 많이 떨어졌었습니다. 그러면서 내가 진짜 하고 싶은게 무엇인지에 대한 고민을 많이 했던 것 같습니다. 다행히 졸업은 무사히 했지만 졸업 이후에도 앞으로의 진로에 대한 고민이 정말 많은 시기였습니다.

그래도 고민이 그렇게 오래가지는 않았던 것 같습니다. 졸업 이후, 플러터 커뮤니티에서 알게 된 인연들을 통해 여러 외주를 받아 일하고 주변 지인들과 이야기도 나눠보고 메모어라는 회고 모임에서 활동하면서 '나'에 대해서 계속 고민하다보니 결국 내가 원하던 건 연구원, 개발자 같은 직업이 아니라는 걸 깨닫게 됐습니다.

[현재 나의 목표]

'내 서비스 개발'이 현재 제가 목표로 삼고 있는 것입니다.

이 목표는 단순히 기술적인 도전을 넘어서, 의미 있는 가치를 창출할 수 있는 일을 하고 싶다는 생각에서 출발했습니다. 외주 프로젝트를 진행하면서 서비스 개발의 매력에 빠져들었고, 사용자들이 실제로 사용할 수 있는 제품을 만들고 그것을 사용하는 모습을 보며 느끼는 성취감이 무엇보다 컸습니다. 이를 통해 제 제품을 널리 퍼트리고 싶다는 열망을 갖게 되었습니다.

서비스 개발은 단순히 코드를 작성하는 것 이상의 과정입니다. 사용자 경험(UX) 개선, 문제 해결, 프로젝트 관리, 마케팅 등 다양한 요소들이 결합되어야 합니다. 이는 제가 지금까지 경험해보지 못했던 많은 것들을 요구합니다.

그래서 저는 다양한 관련 업무들을 경험할 수 있는 회사에서 백엔드 개발자로 일하며, 미래에 있을 내 서비스 개발을 위한 역량을 키우기 위해 노력하고 있습니다. 현재 회사에서 개발하고 운영하는 서비스도 매우 재미있지만, 내 서비스를 출시할 날을 고대하고 있습니다.

그리고 그 날이 더 빠르게 다가올 수 있도록 사이드 프로젝트를 시작했습니다. 작게나마 조금씩 개발을 진행하며, 길게 잡아도 이번년도에는 내 서비스를 출시하는 것을 목표로 하고 있습니다. 앞으로도 꾸준한 노력과 성장을 통해 이 목표를 달성하기 위해 최선을 다할 것입니다.

프로그래머스 - 가장 큰 수

Key 함수로 리스트 정렬하기

Python에서 가장 간단한 정렬 방법 중 하나는 key 함수를 사용하는 것이다. key 함수는 인자 하나를 받아 정렬에 사용할 기준 값을 반환한다.

key 함수, 또는 collation 함수는 min(), max(), sorted(), list.sort(), heapq.merge(), heapq.nlargest(), heapq.nsmallest(), itertools.groupby() 등 정렬이 필요한 다양한 함수에서 활용된다.

예제: 대소문자 구분 없는 정렬

words = ["apple", "Banana", "cherry", "Date"]
sorted_case_insensitive = sorted(words, key=str.lower)
sorted_default = sorted(words)

print(sorted_case_insensitive)
print(sorted_default)

# 출력 결과:
# ['apple', 'Banana', 'cherry', 'Date']
# ['Banana', 'Date', 'apple', 'cherry']

str.lower 함수를 key로 사용하면 대소문자를 구분하지 않고 알파벳 순으로 정렬한다. 반면, 기본 정렬은 대소문자를 구분해 정렬한다.

예제: 튜플의 특정 값 기준 정렬

# 학생 정보 (이름, 성적, 나이) 튜플 리스트
students = [
    ('John', 'A', 15),
    ('Dave', 'B', 15),
    ('Alice', 'A', 12),
    ('Carol', 'B', 12),
]
sorted_students_by_age = sorted(students, key=lambda student: student[2])

print(sorted_students_by_age)

# 출력 결과:
# [('Alice', 'A', 12), ('Carol', 'B', 12), ('John', 'A', 15), ('Dave', 'B', 15)]

나이를 기준으로 정렬하고 싶다면 key 함수에 나이에 해당하는 값을 반환하는 함수를 지정해 정렬하면 된다. 이 예제에서는 익명 함수를 사용해서 나이를 반환하는 함수를 구현했다.

예제: 여러 기준으로 정렬하기

Python 정렬 알고리즘은 기본적으로 안정적(stable)이어서, 같은 키 값을 가진 요소들 사이의 원래 순서를 유지한다. 여러 조건을 사용해 정렬할 때는 key 함수를 통해 반환되는 값을 튜플로 구성해 이를 쉽게 달성할 수 있다.

다음 예제에서는 학생 정보를 담은 튜플 리스트를 성적(내림차순)과 나이(오름차순)를 기준으로 정렬한다. 이를 위해 lambda 함수를 사용해 정렬 기준을 정의한다.

students = [('Carol', 'B', 12), ('Alice', 'A', 12), ('Dave', 'B', 15), ('John', 'A', 15)]
sorted_students = sorted(students, key=lambda student: (-ord(student[1]), student[2]))
print(sorted_students)
# 출력 결과:
# [('Alice', 'A', 12), ('John', 'A', 15), ('Carol', 'B', 12), ('Dave', 'B', 15)]

위 예제에서 lambda 함수는 각 학생(student)에 대해 성적의 알파벳(student[1])을 ASCII 코드로 변환해 내림차순 정렬 기준으로 하고, 같은 성적을 가진 학생들 사이에서는 나이(student[2])를 오름차순 정렬 기준으로 한다.

또 다른 방법으로 성적을 기준으로 내림차순 정렬한 후, 이후에 나이를 기준으로 오름차순 정렬하는 방식도 가능하다. 하지만, Python 정렬이 안정적이라는 점을 활용해 한 번에 여러 조건을 적용하는 것이 코드를 간결하게 유지하고 성능 측면에서도 유리하다.

# 성적 기준 내림차순 정렬 (단계 1)
sorted_by_grade = sorted(students, key=lambda student: -ord(student[1]))
# 나이 기준 오름차순으로 다시 정렬 (단계 2)
sorted_by_grade_then_age = sorted(sorted_by_grade, key=lambda student: student[2])
print(sorted_by_grade_then_age)
# 출력 결과:
# [('Alice', 'A', 12), ('John', 'A', 15), ('Carol', 'B', 12), ('Dave', 'B', 15)]

operator 모듈을 활용하여 리스트 정렬하기

함수를 임의로 정의할 수 있지만, operator 모듈의 사전 정의된 기능을 활용할 수도 있다. 예를 들어, 리스트의 인덱스1에 위치한 아이템을 가져오는 lambda 함수 대신 operator.itemgetter(1)를 사용할 수 있고, dictionary의 key나 클래스 멤버는 operator.attrgetter("firstname")와 같이 접근할 수 있다.

여러 기준으로 정렬하기를 원한다면 operator.itermgetter(1, 2) 또는 operator.attrgetter("firstname", "lastname")과 같이 사용할 수 있다.

import operator

sorted_students = sorted(students, key=operator.itemgetter(1, 2))
print(sorted_students)
# 출력 결과:
# [('Alice', 'A', 12), ('Carol', 'A', 15), ('Dave', 'B', 12), ('Bob', 'B', 15)]

operator.itemgetter(1, 2)를 사용해 성적 오름차순, 나이 오름차순으로 정렬한다.

from operator import attrgetter

class Person:
    def __init__(self, firstname, lastname):Ï
        self.firstname = firstname
        self.lastname = lastname

    def __repr__(self):
        return f"Person({self.firstname}, {self.lastname})"

persons = [
    Person('John', 'Doe'),
    Person('Jane', 'Doe'),
    Person('Alice', 'Cooper'),
    Person('Bob', 'Barker')
]

sorted_persons = sorted(persons, key=attrgetter('lastname', 'firstname'))
Ï
for person in sorted_persons:
    print(person)

# 출력 결과:
# Person(Bob, Barker)
# Person(Alice, Cooper)
# Person(Jane, Doe)
# Person(John, Doe)

클래스나 dictionary의 경우 operator.attrgetter(...)로 속성 기준 정렬을 한다.

functools.cmp_to_key로 리스트 정렬하기

functools.cmp_to_key 함수는 사용자 정의 비교 함수를 키 함수로 변환해 사용한다. Python 3에서는 cmp(a, b) 형태의 직접 비교 방식 대신 키 함수 사용을 권장한다. 비교 함수를 사용해야 하는 상황이라면 이 함수로 비교 함수를 키 함수로 변환할 수 있다.

from functools import cmp_to_key

def compare_items(x, y):
    return len(x) - len(y)

key_function = cmp_to_key(compare_items)

str_list = ['banana', 'apple', 'cherry', 'date']
sorted_str_list = sorted(str_list, key=key_function)

print(sorted_str_list)  

# 출력 결과:
# ['date', 'apple', 'banana', 'cherry']

compare_items 함수는 문자열 길이를 비교한다. cmp_to_key로 이를 키 함수로 변환하고, sorted의 key 인자로 전달해 문자열 길이 기준으로 정렬한다.

정렬을 지원하는 클래스 만들기

복잡한 정렬 로직이 필요한 경우 사용자 정의 클래스를 만들어 정렬할 수 있도록 하는 것이 유지보수와 가독성 측면에서 유리하다.

Python에서는 매직 메소드를 이용하여 클래스 인스턴스 간 비교 연산자를 직접 정의할 수 있고 이렇게 구현한 비교 연산자들은 sorted, list.sort()와 같은 내장 함수와도 함께 사용할 수 있어 더 깨끗하고 Pythonnic한 코드를 만들 수 있다.

class Person:
    def __init__(self, firstname, lastname):
        self.firstname = firstname
        self.lastname = lastname

    def __repr__(self):
        return f"Person('{self.firstname}', '{self.lastname}')"

    # 비교 매직 메소드 추가
    def __lt__(self, other):
        return (self.lastname, self.firstname) < (other.lastname, other.firstname)

persons = [
    Person('John', 'Doe'),
    Person('Jane', 'Doe'),
    Person('Alice', 'Cooper'),
    Person('Bob', 'Barker')
]

# 성(lastname)과 이름(firstname) 순으로 정렬
sorted_persons = sorted(persons)

for person in sorted_persons:
    print(person)

# 출력 결과:
# Person('Bob', 'Barker')
# Person('Alice', 'Cooper')
# Person('Jane', 'Doe')
# Person('John', 'Doe')

결론

이번 포스팅을 작성하면서 python 정렬 방식을 확실하게 정리한 것 뿐만 아니라 operator 모듈을 활용하는 방법이나 여러 정렬 기준을 한 번에 적용하여 정렬하는 방법까지 알게 됐다. Python을 꽤 오래 사용했었는데 관성적으로 사용하는 것들만 사용하던 것을 반성하는 시간이 됐다.

오랜만에 어떤 기능들이 추가됐는지 궁금하여 Python 3.12 릴리즈 문서를 열어보니 type statement가 추가되어 generic 타입과 type aliases를 좀 더 자연스럽게 할 수 있게 됐고, f-strings 사용 시 불편했던 "{""}"이 이제는 오류가 나지 않는다고 해서 반가웠다. 언어도 끊임없이 발전하니 언어에 대한 공부도 게을리하지 말아야겠다고 생각이 들었다.

다음에는 최근에 많이 쓰고 있는 Dart나 Python의 새로운 기능들이나 어떻게 업데이트가 되어왔는지 한 번 훑어보는 글을 작성해봐야겠다.

References

• Python3 Docs - operator module
• Python3 Docs - key function
• Python3 Docs - functools.cmp_to_key
• Python Magic Methods 비교 연산자
• Python3 Docs - 정렬 How To

그래서 오늘은 세 가지 Dart Map 구현체 HashMap, SplayTreeMap, LinkedHashMap에 대해서 살펴보고 각 구현체를 언제 사용해야 하는지에 대해서 정리를 해보려고 한다.

Map 자료 구조

Map은 연관된 키를 사용하여 값을 검색하는 키/값 쌍의 컬렉션이다. 여러 프로그래밍 언어에서 기본적으로 제공하는 자료형으로 파이썬에서는 사전(dictionary)이라는 자료형으로 제공하고 있다.

Map.entries 속성을 통해서 Map안의 키/값 쌍을 반복할 수 있는데 이때 반복의 순서는 맵의 세부 구현에 따라서 달라지게 된다. 현재 Dart 3.2.5 버전의 Map 구현체는 HashMap, SplayTreeMap, LinkedHashMap 세 가지가 있다.

1. HashMap

HashMap은 Dart의 기본 Map 구현체로 해시 테이블을 활용하여 조회, 추가, 삭제가 빠르지만 요소의 순서를 유지하지 않는다는 특징이 있다.

HashMap이 적합한 상황

• 성능: 빠른 조회, 추가, 삭제가 중요할 때

• 순서가 없는 데이터: 요소들의 순서가 중요하지 않은 상황

예제 시나리오: 앱 설정 저장, 검색

import 'dart:collection';

void main() {
  final userPreferences = HashMap<String, dynamic>();

  // 사용자 선호도 설정
  userPreferences['theme'] = 'Dark';
  userPreferences['fontSize'] = 14;
  userPreferences['notificationsEnabled'] = true;

  // 특정 선호도 접근
  final theme = userPreferences['theme'];
  print('사용자가 선택한 테마: $theme');

  // 더 많은 선호도 추가
  userPreferences['language'] = 'English';
}

// Output:
// 사용자가 선택한 테마: Dart

2. SplayTreeMap

SplayTreeMap은 self-balancing binary search tree를 기반으로 하는 Map 구현체로 키를 기준으로 값을 정렬한다. 자주 사용하는 값은 트리의 루트에 가까운 위치로 이동되어 이후에 접근할 때 더 빠르게 접근할 수 있게 만든다는 특징이 있다.

SplayTreeMap이 적합한 상황

• 정렬: 키를 기준으로 요소들을 정렬된 상태로 유지해야 할 때 (순서가 중요한 데이터)

• 효율적인 접근: 데이터별로 접근 빈도가 크게 차이나는 상황

예시 시나리오: 리더보드

점수 순으로 정렬된 상태를 유지하면서 Top3와 같이 자주 접근하는 데이터가 있을 경우가 있을 때 SplayTreeMap이 유용하게 사용될 수 있다.

import 'dart:collection';

void main() {
  final scores = <String, int>{};
  final leaderboard = SplayTreeMap<int, Set<String>>();

  // 플레이어 점수 추가/업데이트하는 함수
  void updateScore(String playerId, int score) {
    leaderboard[scores[playerId]]?.remove(playerId);
    leaderboard.putIfAbsent(score, () => {}).add(playerId);
    scores[playerId] = score;
  }

  // 점수 추가/업데이트
  updateScore('player1', 100);
  updateScore('player2', 150);
  updateScore('player3', 100);

  // 리더보드를 내림차순으로 표시 (가장 높은 점수가 먼저)
  for (var score in leaderboard.keys.toList().reversed) {
    print('점수: $score, 플레이어들: ${leaderboard[score]}');
  }

  // 점수 추가/업데이트
  updateScore('player1', 120);
  updateScore('player2', 200);
  updateScore('player3', 150);

  // 리더보드를 내림차순으로 표시 (가장 높은 점수가 먼저)
  print("\n업데이트 후");
  for (var score in leaderboard.keys.toList().reversed) {
    if(leaderboard[score] != null && leaderboard[score]!.isNotEmpty) {
      print('점수: $score, 플레이어들: ${leaderboard[score]}');
    }
  }
}

// Output:
// 점수: 150, 플레이어들: {player2}
// 점수: 100, 플레이어들: {player1, player3}
// 
// 업데이트 후
// 점수: 200, 플레이어들: {player2}
// 점수: 150, 플레이어들: {player3}
// 점수: 120, 플레이어들: {player1}

3. LinkedHashMap

LinkedHashMap은 항목이 추가된 순서를 유지한다. 즉, 맵을 순회할 때 항목이 추가된 순서대로 반환된다. 항목의 삽입 순서가 중요할 때 특히 유용하다.

LinkedHashMap이 적합한 상황

• 순서 유지: 데이터의 순서가 중요한 애플리케이션

예시 시나리오: 쇼핑 카트

쇼핑카트에는 담은 순서대로 표시가 되며 쇼핑카트의 수량이 변경되더라도 그 순서는 변경되지 않는다. 쇼핑카트는 LinkedHashMap이 동작하는 방식과 유사하다.

import 'dart:collection';

void main() {
  var shoppingCart = LinkedHashMap<String, int>();

  // 상품을 쇼핑 카트에 추가
  shoppingCart['Apple'] = 1;
  shoppingCart['Banana'] = 2;
  shoppingCart['Orange'] = 2;

  // 카트 내용 확인
  print("쇼핑 카트:");
  shoppingCart.forEach((itemNumber, itemName) {
    print("$itemNumber: $itemName개");
  });

  // 수량 변경
  shoppingCart['Apple'] = 6;

  print("\n수량 변경 후 쇼핑 카트:");
  shoppingCart.forEach((itemNumber, itemName) {
    print("$itemNumber: $itemName개");
  });
}

// Output:
// 쇼핑 카트:
// Apple: 1개
// Banana: 2개
// Orange: 2개
// 
// 수량 변경 후 쇼핑 카트:
// Apple: 6개
// Banana: 2개
// Orange: 2개

결론 - 무엇을 사용해야 할까?

• 순서가 중요하지 않고 빠른 검색, 삽입, 삭제가 필요한 경우 HashMap

• 정렬과 자주 접근하는 요소에 대한 효율적인 접근이 필요할 때 SplayTreeMap

• 삽입 순서가 유지되어야 하는 경우 LinkedHashMap

추가 자료 및 참고 자료:

• Dart Collection - HashMap

• Dart Collection - SplayTreeMap

• Dart Collection - LinkedHashMap

먼저 이 프로젝트는 순전히 내가 필요했기 때문에 개인적인 용도로 만든 것으로 Yes24의 eBook 프로그램이 바뀌면 사용이 불가능할 수 있다. 지금은 Windows 버전만 만들었고 이후 MacOS 버전도 개발환경을 준비되면 배포해보도록 하겠다.

다운로드

아래 링크로 들어가서 오른쪽 Release란에 최신 버전을 클릭하고 Release.zip 을 다운받고 압축을 풀면 최신 버전을 사용할 수 있다.
YesTakeout 설치 링크

사용 방법

이 프로젝트는 Yes24 Ebook에서 사용하는 로컬 데이터베이스에 담긴 정보가 필요하므로 우선 Yes24 Ebook을 설치와 데이터 다운로드 과정이 필수적이다.

Yes24 eBook PC 뷰어 설치

⚠️ 반드시 아무런 세팅없이 다음을 눌러서 설치를 하셔야지 사용하실 때 번거롭지 않습니다.

1. 아래 링크를 통해 Yes24 eBook PC 뷰어 설치

   • Yes24 eBook PC 뷰어 설치 링크 접속 후 사진에 표시된 버튼 클릭하여 설치

2. 

   원하는 책의 다운로드 버튼을 눌러 책을 다운로드

3. 

   다운로드 완료 후 2번 사진처럼 열기 버튼으로 바뀌었다면 열기 버튼 클릭

YesTakeout을 사용하여 하이라이트, 메모 열람

1. yes_takeout.exe 파일 실행

   

2. 아래와 같은 화면이 뜨면 Takeout 하러 가기 클릭

   

3. Open database 를 클릭하여 Yes24 eBook 데이터베이스 선택

   • 기본 설정으로 설치했다면 Open database 클릭했을 때 바로 설정이 될 것이다.

   • 기본 데이터베이스 주소: %USERPROFILE%\AppData\Local\YES24eBook\databases

4. 

   원하는 책 선택

5. 인덱스 보기, 메모 보기, 하이라이트색 등을 토글할 수 있다.

   이제 원하는 부분을 드래그하여 선택한 후 독서노트를 작성하면 된다.

   

앞으로의 계획

앞으로는 다음과 같은 기능들을 만들어볼 예정입니다. 일단은 제가 필요하다고 생각하는 내용들을 위주로 넣어놨는데 지금도 충분한 것 같기는 해서 사용하시는 분들이 있는지 반응을 보고 필요하다면 업데이트를 해봐야겠습니다.

• MacOS 지원

• 템플릿 기능: 선택한 하이라이트를 템플릿에 맞춰서 내보내기

• 옵시디언으로 내보내기 기능: 옵시디언으로 하이라이트와 메모, 책 정보 내보내기

• 필사 기능: 그냥 복사하는 것이 아니라 직접 타이핑해서 복사

한계점

• 우선 가장 큰 한계점은 Yes24 eBook PC 뷰어에 의존하고 있기 때문에 이 프로그램이 바뀌거나 했을 때 바로 대응이 안 될 수 있다. 개인적으로 필요해서 만들었기 때문에 그렇게 된다면 리*북스로 넘어가야할 것 같다.

• PDF 기반의 eBook은 지원이 안된다. PDF 파일 자체에 주석이 저장되고 그 내용을 데이터베이스에 저장하는 방식인 것 같아서 그것까지는 어떻게 할 수가 없었다.

• Web을 지원하려고 했으나 데이터베이스를 읽어오는 부분에서 문제가 생겨서 PC 버전으로 만들게 됐다. 귀찮을 수 있지만 다운받아서 사용해야 한다.

후기

Windows 프로그램을 만들어본 것은 처음이었지만 Flutter를 사용하니까 그냥 크로스플랫폼 앱 개발하듯이 매우 편하게 개발할 수 있었다. 후기에서는 이번에 시도해본 것들과 개발하면서 느낀점들을 간략하게 정리해보겠다.

1. SQLite3의 Flutter Web 버전 지원 문제

   • Web 버전으로 만들어서 모두가 사용할 수 있도록 할 예정이었는데 큰 자칠이 생겼다. WASM을 이용해서 컴파일된 SQLite3를 지원하지만 로컬 데이터베이스를 읽어서 로드하는 기능을 지원하지 않아서 Web 지원을 포기하게 됐다.

   • BLE 기능을 도입하는 프로젝트에서도 공식적인 라이브러리가 없어서 flutter 사용이 굉장히 힘들었는데 이번에는 native에 대한 이해가 얼마나 중요한지와 flutter의 단점을 여실히 느낄 수 있었다.

2. Clean architecture(?)

   • 이번에 clean architecture를 도입해보고 riverpod 이라는 상태관리 라이브러리의 2.0 버전을 사용해봤다. 일단 두 가지 다 좋은 방법이라고 생각이 되지만 익숙하지 않으니 시간이 꽤 오래 걸린 것 같다. 특히, 이게 맞는 방법인지가 확실하지 않으니까 더 더뎠던 것 같다.

   • 그리고 지금 프로젝트 규모에 비해서 너무 복잡한 설계를 사용한 것 같다. 추상화를 통해서 이득을 볼 부분을 없는 것 같은데 소 잡는 칼을 닭 잡는데 사용한 것 같은 꼴이었다.

   • 개발 속도 빼고 불편했던 점 중 하나는 바로 IDE의 지원이다. Interface에 의존을 하다보니 구현체로 이동하기 위해서는 하나의 스텝을 더 밟아야 해서 생각보다 거슬렸다.

   • 그래도 한 번 해보니까 추상화에 의존하게 되므로 구현을 수정해도 활용하는 부분이 영향을 받지 않는 다는 것은 확인할 수 있었다. 그래도 프로젝트 규모가 작아서 앞에서 말한 것처럼 그렇게 큰 효과는 보지 못한 것 같다.

Yes24 Ebook의 독서노트 내보내기 미지원

현재 Yes24의 크레마 클럽을 구독 중이다. 정말 너무 좋은 서비스이지만 가장 큰 문제는 독서노트를 다른 플랫폼으로 이동시킬 수 없다는 것이다. 리디북스의 경우에는 웹 기반으로 되어 있어서 자연스럽게 독서노트를 내보낼 수 있는데 Yes24는 지원하지 않는다는 것이 굉장히 아쉬운 부분이었다.

심지어 PC 버전에서는 하이라이트를 할 수 없으며 하이라이트가 표시도 되지 않는다. 메모도 작성이 안 된다. (이 정도면 PC 버전은 완전히 버린 것이 아닌가 싶은 생각이 든다). 이쯤되면 포기하고 리디북스로 가는 것이 맞겠지만... 우리 Yes24 나쁘지 않은 서비스니까 또 사용하시는 분이 꽤 되는 것 같으니까 내가 한 번 방법을 찾아보게 됐다.

어떻게 해결할 수 없을까?

최근에는 Obsidian이라는 툴에 관심이 생겨서 독서노트를 Obsidian에서 작성하고 싶어서 책을 다 까져오는 게 아니라 내가 하이라이트한 부분이랑 메모만 가져올 수 있으면 좋겠다는 생각에 Yes24 Ebook PC 프로그램을 좀 분석했다.

결과는 대성공! PC 버전에서는 지원하지 않는 기능이지만 내부적으로는 해당 정보들을 가지고 있는 것을 발견할 수 있었다. 다행히 간단하게 해결할 수 있는 부분인 것 같아서 주변에 필요한 기능들을 좀 물어보기도 하고 개인적으로도 정리해서 이 프로젝트를 시작했다! (생각보다 필요로 하시는 분들이 꽤 계신 것 같아서 두근두근하다.)

필요한 기능 및 출시 일정

간단하게 필요한 기능들을 중심으로 출시 일정을 정리해봤다.

• 1차 출시: 2024년 1월 3일

  • Yes24 Ebook에 작성한 메모나 하이라이트 등의 주석 추출

  • 추출한 주석들을 디스플레이

  • 추출한 주석들을 텍스트로 내보내기 기능

• 2차 출시: 2024년 1월 13일

  • 추출한 주석들을 템플릿에 맞춰 내보내기 기능

  • 추출한 주석들을 Obsidian으로 내보내기 기능

세부 사항

애플리케이션의 형태나 간단하게 필요한 도구들과 경험해보고 싶은 것들을 정리해봤다. 기능이 비해서 좀 과한 느낌이 없잖아 있지만 평소에 관심이 있던거라 슬쩍 끼워넣어봤다.

• 애플리케이션 형태: 웹 애플리케이션

• 프레임워크: Flutter

• 클린아키텍쳐 써보면서 장단점 느껴보기

  • Code with andrea 튜토리얼 참고

  • Drift clean architecture 튜토리얼 참고

• Dart 언어로 작성된 ORM drift 사용해보기

• Riverpod2.0에서 소개된 riverpod generator 사용해보기