0063. 한날님과 함께하면 나의 프로젝트가 엎어질 일은 없겠구나

푸딩캠프 이야기

오늘 토이스토리 2기 모집을 마감합니다!

토이스토리 2기는 2025년 1월 31일 21시에 모집을 마감합니다.

출시해 운영하는 프로젝트.결제 시스템을 연동해 유료화하는 프로젝트.풀스택으로 팀이 결성된 프로젝트.26년차 CTO 출신 개발자를 랜선 사수로 맞이하는 프로젝트.

아직 참가하실 시간과 자리가 남아있습니다. ☺️

한날님과 함께하면 나의 프로젝트가 엎어질 일은 없겠구나

🍮 푸딩 : 안녕하세요, 지영님. 프로젝트 발표회 이후 며칠 안 지났는데, 여전히 반갑네요.

👩🏻 지영 : 안녕하세요~

🍮 푸딩 : 간단히 자기소개 부탁해요.

👩🏻 지영 : 저는 토이스토리의 손절보안관팀에서 백엔드 개발자로 참여한, 인턴 경험도 없는 순도 높은 생신입 백엔드 개발자입니다.

🍮 푸딩 : 순도 높은??? 참신하네요. 자, 그럼.

👩🏻 지영 : 한날님.

🍮 푸딩 : ?

👩🏻 지영 : 질문이 있는데, 잠깐 괜찮을까요?

🍮 푸딩 : 네, 잠깐이라면. 뭐예요?

👩🏻 지영 : 저희 프로젝트 질문인데요. 저희 사용자는 로그인하면 액세스 토큰(Access Token)을 발급받아서 API 호출에 사용해요. 그런데 한 페이지에 3개 API를 호출하는 곳이 있거든요. 만약에 첫 번째 API 호출 순간엔 토큰이 유효한데, 두 번째나 세 번째 API 호출하는 순간엔 만료되어서 유효하지 않으면 세 API를 호출하는 페이지에 문제가 생기잖아요. 이런 때 서버에선 어떻게 대응해야 할까요?

🍮 푸딩 : 흐음...

대개 그런 일은 웬만해서는 없겠지만, 마이크로 초까지 타이밍 문제를 생각한다면 여러 측면에서 다각도로 문제를 정의하고 푸는 게 좋아요. 기본적으로 상태가 없는 Stateless로 HTTP를 다룰테니 세 API 호출 각각은 서로에 대해 독립되고 연관성이 없지요. 따라서 말씀하신 바와 같이 세 API 호출을 같은 맥락으로 묶고자 한다면 그건 사실상 상태가 있는, Stateful 인 거예요. Stateless를 Stateful하게 다루니 말씀하시는 염려되는 상황이 숫자로만 보면 가능해요. 이런 Stateful을 어디까지 구현하느냐에 따라 구현 방법이 달라질 거예요. 쉽게 떠오르는 방법은 서버가 아니라 클라이언트에서 대응하는 거예요. 세 API 호출이 같은 맥락이라는 건 서버는 모르지만, 호출이라는 의도(intent)를 가진 클라이언트는 알고 있죠. 따라서 세 API 호출을 일으키고 응답을 받은 뒤 세 응답이 200 OK 응답을 받으면 응답받은 데이터를 사용해 화면을 그리는 거예요. 액세스 토큰으로 JWT 쓰시죠? 그럼 토큰을 디코딩해서 만료일시를 검사해서 API 세 개를 호출하는 데 소요되는 시간보다 좀 더 넉넉한 시간 전에 미리 토큰을 갱신하는 거예요. 좀 더 쉽게는 일정 시간마다 자동으로 토큰을 갱신하고요. 세 API를 호출했다면 세 API가 아마 가까이 응집되어 있을 가능성이 큰데요. All I know is now 알게 됐어 나 (I know) 그동안 맨날 always up and down (no more) 생각 또 생각 spinnin' 'round and 'round, changing my mind 수상해서 그렇지 이런 헛소리 (no more) How it's supposed to be 그만해 'cause it's clear (It's simple) it's like biting an apple 각 개체(Entity)를 노드로 보고 노드 간 관계를 그려서 연결되어 있다면(Edge) GraphQL을 사용하는 것도 방법일 거예요. GraphQL의 용도가 말씀하신 상황을 위한 용도는 아니긴 하지만, 요는 한 API 호출로 인접한 데이터를 함께 가져온다는 아이디어예요. 사용자에겐 좀 불친절하지만 직관적인 방법도 있어요. 세 API를 호출한다면, 화면에서 연관된 부분 별로 호출에 관여하는 API가 다른 것일텐데요. API 호출에 성공한 부분만 그리고, 실패한 부분은 실패했다는 표시를 하는 거죠. 마치 Any 처럼요. 그에 반해 단 하나라도 401이나 403 응답을 받으면 세션이 만료되었으니 새로고침하겠다는 안내를 띄우는 거예요. 구글 닥스나 스프레드시트 등 구글 도큐먼트 제품들이 이 방식을 따르죠. 기술적으로는 사용자에게 거칠거나 불친절해서 사용자에게 유료한 사용자 경험을 주지 못하잖아요. 그렇다면 HCI(Human-Computer Interaction, 인간-컴퓨터 상호작용)에 기초하여 UX/UI를 고민해 사용자 경험을 개선할 수도 있을 거예요. 애니메이션 효과를 주어서 로딩되는 체감 시간을 적게 느끼게 하는 것처럼요. 관련해서 인간 중심 인터페이스(Humane Interface) 책 추천해요.

🍮 푸딩 : 살쪄서 그런가. 어우, 숨차. 다이어트 열심히 해야지.

👩🏻 지영 : 고맙습니다... 중간에 스파이도 있고... 인터뷰에 집중하겠습니다.

🍮 푸딩 : 지영님은 저와 이력서 멘토링으로 커피챗을 하다가 제가 토이스토리 참여를 제안하는 걸 계기로 토이스토리에 참여해 현 소속팀인 손절보안관에 합류하셨잖아요. 그때 멘토링하며 인상적이라 생각한 점이 프로젝트를 출시해 운영해본 경험이었거든요. 이번에도 출시해서 운영을 하셨는데, 운영하면서 경험한 특이한 사례가 있을까요?

👩🏻 지영 : 특이한 사례요. 서버를 배치해서 배포하고서 겪었던 문제인데, 의미 없는 HTTP 요청이 많이 들어왔어요. API 서버에 크롤링 시도하려는 것 같은 것도 있고, 공격 당하기 좋은 파일이 있는지 찔러보는 공격 시도가 되게 많았어요. 그게 정상 요청보다 훨씬 많은데, 지금 당장은 제가 생각해낼 수가 없는 게 없어요. 처음 겪는 상황이라.

🍮 푸딩 : 치명적이진 않은데 신경 쓰여서 해결하고 싶을 텐데, 이번에 수료해 프로젝트는 끝났지만, 만약에 향후 더 운영한다면 이걸 해결하고 싶으세요?

👩🏻 지영 : 네, 하고 싶을 것 같아요. 제가 서버 로그를 보는 입장이다 보니까 아무래도 좀 신경 쓰여요.

🍮 푸딩 : 그런 게 또 뭐가 있어요? 해결하고 싶은 거?

👩🏻 지영 : 해결하고 싶은 거... 개선하고 싶은 점은 아까 질문드린 리프레시 토큰 문제도 처리할 수 있으면 하고 싶고요. 그리고 전체 UX적으로 운영 지표 같은 거를 봤을 때, 서비스 흐름이 끊어지는 부분이 있어요. 사용자의 반응이 일어나 상호작용이 재작용하는 과정으로 안 이어져서 이거를 개선하면 어떨까 싶어요.

🍮 푸딩 : 그걸 어떻게 발견한 거예요?

👩🏻 지영 : 그건 의현님이 달아주신 슈퍼셋에서 지표를 볼 수 있는데, 오늘 들어온 사용자 수, 오늘 만들어진 메시지 개수, 질문 개수 등을 대시보드로 봐요. 대시보드로 지표를 보다보니 항상 메시지에 대한 사용자 상호작용이 적은 거예요. 0일 때도 있고. 그렇게 발견했어요.

🍮 푸딩 : 개발에서는 발견하기 어려웠을 문제를 서비스 운영으로 발견한 거군요. 사용자 피드백도 받으셨어요?

👩🏻 지영 : 저희 기획자분이 베타 사용자 인터뷰를 하셨고, 지인 사용자에게 피드백을 요청했어요.

🍮 푸딩 : 토이스토리에서 추구하는, 그러니까 출시해서 운영해야 한다는 취지를 굉장히 이상적으로 실행하셨네요. 이번 프로젝트를 개발하는 과정이나 출시와 운영하는 과정에 있어서 이전과 다른 경험이 있다면 뭐가 있을까요?

👩🏻 지영 : 제가 참여한 프로젝트는 1차 프로젝트를 계승하는 2차 프로젝트거든요. 하지만 핵심 콘셉트와 아이디어를 나머지는 새로 만드는 부분이 많아요. 데이터베이스 구조도 다르고요. 그래서 데이터 호환이 되지 않는데, 저희 팀은 1차 프로젝트에서 운영하며 쌓은 데이터를 2차 프로젝트에 이전(Migration)하길 바랐어요. 그걸 제가 해야 했는데 고민이 많았어요. 그래도 고심 끝에 설계한 데이터 이전 계획이 잘 작동해서 문제없이 데이터를 이전했어요.

🍮 푸딩 : 토이 프로젝트인데 데이터 이전을 했다니 특이한 경우네요. 물론 실무에서는 새 데이터베이스로 이전하는 경우가 심심찮게 있어요. 새벽에 서버 점검한다고 하면 대개는 데이터베이스 이전 작업이라고 보면 돼요. 그렇게 실무에서 하는 경험을 토이 프로젝트에서 하셨네요.

👩🏻 지영 : 그렇군요. 저희는 운좋게 문제없이 한 번에 데이터를 이전했는데, 실무에서는 어떤가요?

🍮 푸딩 : 온갖 경험이 있지만, 재밌는 사례를 하나 들려드릴게요. 데이터 이전(Migration) 스크립트는 대개 한 번 쓰고 버리니 코드를 작성하는 데 공들이지 않아요. 그게 효율적이고 합리적이죠. 그런데 마이그레이션 스크립트가 동작하는 중에 문제가 발생해서 중단됐어요. 새벽 4시에. 서둘러 마이그레이션 스크립트를 검토하는데 일회용 코드라고 대충 짜서 코드를 이해하기 어려웠어요. 그래서 비상 상황에서 뜬금없이 마이그레이션 스크립트 코드를 리팩토링했어요. 마이그레이션 스크립트가 돌기 시작하면 한두 시간 걸리는데, 이 말은 코드 작업에 대한 피드백을 받는 데 한두 시간 걸린다는 의미잖아요. 그래서 그 상황에서 리팩토링은 얼핏 보면 돌아가는 것 같지만 오히려 가장 빠른 길을 가는 방법이었어요.

🍮 푸딩 : 여튼. 우리가 일주일에 한 번씩 코칭 세션을 가졌잖아요. 초반에 지영님이 적극 코칭 세션을 잘 활용하셨죠.

👩🏻 지영 : 코칭 세션에서 저는 제가 해결할 수 없거나 까다로운 것 위주로 질문을 많이 드렸어요. 제가 주로 고민한 점은 A안과 B안이 있을 때, 어떤 방식으로 선택해야 하는지에 대한 기술적인 고민이었어요. 테스트 코드를 꼭 작성해야 하는가? 그런 질문도 드렸고, 서비스 계층에 대한 질문도 드렸네요. 주로 제 고민에 대해 경험이 있는 선배 개발자께 드릴 수 있는 질문을 많이 드렸고, 그런 질문에 실질적인 해결책과 생각할거리를 주셔서 많이 도움을 얻었어요.

🍮 푸딩 : 토이스토리 2기에서는 코치보다는 랜선 사수 역할의 비중을 더 크게 설정할 거거든요. 바로 옆에서 함께 실무를 고민하고 협업하는 사수인 거죠. 이러한 역할에 대해 어떻게 보세요?

👩🏻 지영 : 음... 정말 어려운 질문을 해주셨네요. 아무리 친근하고 나의 성장을 위해 일하는 랜선 사수로 콘셉트를 잡으셔도 나이가경력이 좀 많으셔서 주니어 입장에서는 먼저 편안하게 다가가기 좀 어려울 것 같아요. 그래서 한날님이 라포(Rapport) 형성에 노력을 들이시면 더 좋을 것 같아요. 디스코드에서 한날님에게 질문하면 칼답을 하시잖아요. 그래서 참여자분들도 라포를 형성하면 많은 도움이 될 것 같아요. 근데 한날님은 개발자인데, 다른 직군에 대한 사수 역할은 어떻게 하시는 거세요?

🍮 푸딩 : 개발팀의 팀장 느낌일지도 모르겠네요. 팀장도 본인의 하드스킬 직군이 있잖아요. 그걸 바탕으로 제품을 최우선으로 하여 제품과 팀에 필요한 걸 함께 고민할 수 있어요. 예를 들어, 주니어 디자이너가 디자인 시스템을 만들고 싶지만 해야할지 말아야할지 고민하고 있을 때, 팀장은 팀의 상황, 그리고 본인의 하드스킬을 토대로 디자인 시스템 구현 계획을 짤 수 있겠죠. 가령 프론트엔드 개발이 팀장의 직군이라면 구현 난이도에 맞춰 디자인 시스템의 구현 순서를 설계하는 데 도움을 줄 수 있을 거예요. 디자인 시스템에 대한 실무적인 도움이 필요하다면 팀장의 인맥을 이용해 도와줄 사람을 수배해줄 수도 있고요.

👩🏻 지영 : 아아, 맞아요. 코칭 세션을 돌이켜보면, 저랑 베르데님이 가장 많이 질문을 했잖아요. 근데 기획/PM인 베르데님과 한날님이 주고 받는 이야기 내용의 분야를 저는 잘 모르지만, 그 광경을 봤을 때 되게 좋았어요. 한날님이 툴 같은 것도 많이 알려주시고, 어떤 방식으로 활용할 수 있는지 푸딩캠프 데이터를 까서 보여주시며 실질적인 부분까지 다 알려주셨잖아요. 그런 게 좋더라고요.

🍮 푸딩 : 사실, 저연차 주니어가 필요로 하는 도움은 제 입장에선 대체로 예상 범위 안에 있고, 제 지식과 경험 범위 안에 있어요. 날로 먹고 살아도 26년 동안 일해온 것이니... 그런 점에서 토이스토리 참여자들이 저를 어떻게 활용하면 좋을지 조언을 해주신다면?

👩🏻 지영 : 저도 토이 프로젝트 팀을 여럿 경험했지만, 토이스토리 특유의 분위기, 환경이 있어요. 제가 운이 좋은 걸지도 모르겠지만, 저희 팀은 다 프로젝트에 열정이 있었고, 의견 제시도 적극했어요. 팀원과 문제를 공유하고 기획에도 적극 참여하며 팀의 결속감 같은 걸 단단히 만들었는데, 그렇게 프로젝트를 진행하면 되게 잘 될 것 같아요. 이런 분위기와 환경이 잘 없어요.

👩🏻 지영 : 그리고 한날님과 함께하면 나의 프로젝트가 엎어질 일은 없겠구나, 그런 믿음을 갖고 노력하며 열심히 하면 좋은 결과를 낼 수 있을 거라 생각해요.

🍮 푸딩 : 지영님이 토이스토리 2기에 참여한다면, 어떤 프로젝트를 하고 싶으세요?

👩🏻 지영 : 수익이 될 만한? 그런 프로젝트이면 좋겠어요.

🍮 푸딩 : 오호? 결제 시스템을 연동하는 걸로 만족하지 않고, 진짜 수익까지 내는 수준까지 만드는 거예요?

👩🏻 지영 : 네. 실제로 돈이 왔다 갔다하면 정말 어디에서도 하지 못하는 경험이지 않을까 생각해요. 물론 책임 범위도 커지겠지만.

🍮 푸딩 : 그런 식으로 푸딩캠프 토이스토리가 남다른 점이 있다면 뭐가 더 있어요?

👩🏻 지영 : 일단 제게 있어서 가장 큰 부분은 출시와 운영이에요. 사람 의지만으로는 어려운 게 있잖아요. 아무리 굳은 의지로 출시해서 운영하려고 해도 쉽지 않은데, 토이스토리는 한날님이 일정을 정해주시잖아요. 이때까지는 반드시 출시를 하시고, 이 기간 동안엔 운영만 하시라. 이렇게 잡아주시는 게 진짜 실제 결과로 이어지는 데 굉장히 큰 역할을 하는 것 같아요. 그런 일정이나 체계가 있는 걸 보고 토이스토리에 참여한 점도 있어요. 여기는 중간에 엎어지진 않겠구나, 흐지부지 흩어지진 않겠구나, 그런 게 있어요.

👩🏻 지영 : 그리고, 실무를 경험한 사람이 최소 한 명은 있다는 점도 장점같아요. 저희 팀은 저랑 나리님을 빼고 다 현업에서 일하시는 분들이었는데요. 실제 서비스하는 경험이 있으시다보니 “이걸 했을 때 진짜로 사용자가 쓸 것인가?” 이런 사고방식으로 생각하는 방법을 배운 것 같아요. 문제를 해결하는 데 코드만 있는 것이 아니라는 걸 아는 식으로 시야가 넓어졌어요.

🍮 푸딩 : 왜 실무 경험자가 최소 한 명이라 하셨나 했는데, 그게 저군요. 26년차 개발자.

🍮 푸딩 : 팀에서 유일한 백엔드 개발자로 고군분투하셨잖아요. 지금의 지영이 3달 전의 지영에게 말을 전한다면, 어떤 이야기를 해주실 건가요?

👩🏻 지영 : 코치님 도움이 필요한 것들을 일주일에 한 번 있는 코칭 세션에 맞춰 모아서 질문하지 말고, 그때 그때 DM을 바로 보내라고 할 것 같아요. 따로 개인 세션을 일주일에 한두 번 만들어달라고 제안드릴지도 모르고요. 아까도 말씀드렸듯이 한날님은 칼답을 되게 잘해주시기 때문에, 걱정말고 질문하라는 말을 하고 싶어요. 그리고 팀을 믿고 더 의지해서 문제를 팀에 공유하며 함께 고민하고 헤쳐나가라는 말을 하고 싶어요. 심적으로 힘든 것도 얘기 나누고 도움도 청하고요.

🍮 푸딩 : 훌륭합니다. 그런 훌륭한 마음가짐으로 토이스토리 추천사도 해주세요.

👩🏻 지영 : 뭐든 해봐야 아는 거잖아요. 지금 망설이고 있다면 일단 해보시라고 하고 싶어요. 한날님이 굉장히 좋은 분이에요. 한날님은 그러니까 나쁜 말을 하지 않아요. 뭐라고 해야 하지? 불편한 말을 안 하려고 굉장히 노력하시는 분이에요. 그런 분이 많이 없다고 저는 생각하거든요. 그런 분이니까 너무 두려워하지 말고 지원을 해보셨으면 좋겠고요. 그런 좋은 사람을 새로이 만난다는 점도 되게 좋은 기회이니까 지금 당장 신청하세요. 저는 이 프로젝트하면서 되게 좋은 사람들을 만났기 때문에 추천드립니다.

🍮 푸딩 : 감사한 추천사 감사합니다. 그리고 인터뷰에 시간 내주셔서 고맙습니다.

👩🏻 지영 : 수고하셨습니다!