2025년 9월 회고

9월의 일

BFF Persistent Query 대응

팀에서 관리하고 있는 BFF에서 지금까지 Persistent Query를 대응하지 못하고 있었어요. 보안과 성능 측면에서 임팩트가 있는 부분이라고 생각했고, PoC를 거쳐서 알파 환경에서만 동작하도록 처리한 상태로 내부 테스팅을 할 수 있는 만큼 개발을 완료했어요. 프로덕션으로 배포하기전에 챙겨야할 부분들이 몇 가지가 남아있어요.

persistent query라는 것은 결국 client가 id를 전송하면 server는 해당 id에 매핑되어있는 graphql operation document를 찾을 수 있어야해요. 그렇게 하기 위해서는 client에서 배포시에 클라이언트에서 사용하고 있는 모든 graphql string을 찾아서 id에 매핑하고 서버가 접근할 수 있는 저장소에 해당 값들을 저장해두고 확인할 수 있는 작업이 필요해요. 하지만 여기서 조금 더 고려해야했던 부분이 있었어요. graphql string이 달라지는 배포가 있었을 때에 예전 버전의 클라이언트를 이미 실행중인 유저는 에러를 겪을 수 있다는 생각이 들었어요. 프론트엔드 개발시에도 클라이언트 build 결과인 assets 파일들을 계속 S3에 쌓아두어야 배포해도 예전 버전을 사용하고 있는 유저들이 문제를 겪지 않는 것과 같은 문제에 대한 대응이 필요하다고 생각했어요. node 서버는 graphql id와 operation document 매핑에 대한 정보를 central dogma를 통해서 가져오고 있어서 어떻게 업로드하고 서버에서 가져와서 사용하게끔 할 것인가에 대해서 조금 더 고민해보고 있는 상황이에요.

아직은 시작단계지만 persistent query를 곧 지원할 수 있을 것이라는 기대를 하고 있고, 다음 달에는 진행을 마무리해서 production 배포까지 해볼 생각이에요.

광고주센터의 상태값 개편과 상태에 따라 보여주는 콜아웃 로직 개편

개발하고 있는 광고주센터에서 현재 보여주고 있는 광고 상태값에 대한 개편을 진행했어요. 현재의 광고 상태값의 유형은 유저들이 정확하고 빠르게 광고의 상황에 대해서 이해하지 못할 것이라는 우려가 있는 상태였어요. 그래서 기존에 전문가모드에서 사용하고 있는 유형을 그대로 따라가는 방식으로 개편을 진행했어요. 구현은 정책이 잡힌대로 하면 되는 문제였지만, 여기서 하나 고민이었던 부분은 어떻게 기존 동작들이 문제없이 동작함을 보장하면서 마이그레이션을 할 수 있는가에 집중해있었어요. 어떻게하면 코드에만 녹아있는 특정 상태에 대해서 전체 팀이 싱크를 이룰 수 있을까 고민을 하기 시작했어요.

하나 아이디어가 나왔던 부분은 UI/UX 디자인할 때에 원칙에 대해서 고민을 했는데요. 특정 컨디션에서만 유저에게 존재하는 컴포넌트 혹은 다른 플로우로 유저를 보낸다던가와 같은 복잡한 스펙이나 정책 자체가 너무 남발될 경우 만드는 사람들도 눈에 보이지 않기 때문에 코드를 직접 까보지 않으면 알 수 없겠다는 생각이 들었어요. 그래서 이런 UX를 구현하는 것을 지양해야하지 않을까 싶었어요. 조건에 따라서 다른 컴포넌트를 보여주는건 당연히 필요할 수 있겠지만, 특정 조건에 따라서 특정 섹션이 보이고 안보이고가 아니라 다른 상태의 컴포넌트를 보여줄 수도 있지 않을까 정도의 생각이었어요. 특정 조건이 안되서 특정 섹션이 안보인다면 왜 이 섹션이 노출이 안되고 있는지에 대한 내용으로 UI를 보여줄 수도 있겠다 싶어서 이런 생각을 하게 되었어요.

그럼에도 불구하고 무조건 그렇게 Design을 하지 말아주세요는 말이 안된다는 생각도 들어서 결국 실제 유저들이 겪고 있는 진실의 원천은 코드였기에 코드에서 정책을 작성하고 그 코드가 배포할 때마다 즉시 문서에도 반영되는 형태가 가장 좋은 선택이 아닐까라는 생각이 들더군요. 결국 특정 Config를 개발에서 작성하면 그것이 문서와 배포시마다 바로바로 동일하게 싱크가 되었으면 좋겠다는 생각이 들었어요. 그래서 간단히 찾아보니 zod schema를 작성하고 그것이 바로 swagger로 변환해서 웹사이트를 보여준다던가와 같은 개념들이 존재하더라구요. 아직 구체적으로 시도해보진 못했지만, 다른 여러가지 방법들을 탐구해보고 시도해보고 싶다는 생각이 들었어요.

9월의 생각

SDD (Spec Driven Development)에서 배운 것들

SDD 기법을 AI Agent에서 활용할 수 있는 commands를 제공해주는 spec-kit이라는 github repository가 있다는 것을 알게 되었어요. 간단히 어떤 기능을 제공하는지에 대해서 살펴보면, 기본적으로 다음과 같은 commands를 제공해요.

consitution: 프로젝트의 헌법을 구성해요. 예를 들면, 프로젝트에서 가장 중요한 원칙들을 만들 수 있는 command라고 생각할 수 있어요. claude code의 init과 비슷하다고 볼 수 있어요.
specify: how가 아니라 what에 집중해서 어떤 기능을 개발하고 싶은지에 집중해서 프롬프트를 작성하면 spec을 분석하고 user story와 acceptance criteria를 작성해요.
plan: specify 과정에서 작성된 문서를 바탕으로 기능적, 비기능적인 구현을 구체적으로 어떻게 할 것인지에 대한 프롬프트를 제공하면 관련된 문서를 생성해줘요.
tasks: 지금까지 생성된 모든 문서를 참고해서 어떻게 작업을 쪼개고, 어떤 순서대로 진행하면 좋을지에 대한 문서를 작성해줘요.
implement: 지금까지 생성된 문서를 참고해서 지금 진행해야할 작업을 파악하고 한번에 하나씩의 작업을 진행해줘요.
clarify (optional): specify 과정에서 유저의 결정이 더 필요한 경우에 해당 커맨드를 사용해서 문서를 조금 더 명확하게 업데이트할 수 있어요.
analyze (optional): 지금까지 작성된 문서들이 일관성있게 작성되어있는지를 체크해줘요. 실제 구현전에 한번 체크해보면 더 좋은 결과물을 얻을 수 있다고 안내해주고 있어요.

실제로 위 커맨드들을 사용해서 구현하고자하는 기능들 구현을 몇 번 시도했지만 사실 대부분 실패했어요. 그럼에도 이 부분을 다시 한번 정리해보는 이유는 개인적으로 직접 테크스펙을 작성한다고 했을 때에도 위와 같은 과정을 보통 거치고 중요한 핵심 프로세스를 잘 파악하고 정리되어있다고 생각했기 때문이에요. 또한 실제로 spec-kit의 command, script, template 파일등에서 어떤 식으로 생각을 구체화하고 계획을 세우면 좋을지 배울 점들이 있었기 때문이에요.

몇 가지만 뽑아보자면, 다음과 같은 것들이 있었어요.

specify 과정에서 entity를 파악하고, entity를 기준으로 usecase를 파악하고 있었어요.
research.md 파일에 작성하는 것처럼 특정 결정을 내리기전에 각 결정에 대한 트레이드오프를 살펴보고 그 근거들을 기반으로 의사결정을 하고 있었어요.
tasks.md에서는 AI Agent Tool이 한 세션동안에 하나의 작업에 집중할 수 있는 환경을 만들기 위해서 우선순위에 맞춰서 작업을 쪼개고 관리할 수 있게 해주고 있어요.

위 내용들은 기본이라고 생각할 수도 있겠지만, 굉장히 작업을 하기 전에 꼼꼼하고 정확하게 잘해야할 영역이라는 점이라는 생각을 가지고 있었고, 이런 점들은 AI Agent에게도 동일하게 작동하는 부분일 수 있겠다는 생각이 들었어요. 그래서 개인적으로 spec-kit의 특정 방법론들은 문서를 작성할 떄에도 다시 떠올리면서 반영해보고 있는 부분도 있어요.

다른 면접관들을 관찰하면서 좋은 질문이라고 느꼈던 몇 가지 질문들

최근에 의도하지는 않았지만 다른 팀들 채용 직무면접에 많이 참가하고 있어요. 면접을 참여하면서 괜찮은 질문이다라는 생각이 들었던 질문이 몇가지 있었어요. 관련해서 간단히 기록하고 다시 한 번 상기시키기 위해서 이 부분을 작성하고 있어요. 직무 면접이기때문에 기술적인 부분도 많이 물어보지만, 세세한 질문의 출발이 이 질문이여도 굉장히 좋겠다는 생각이 들었어요. 그 질문은 바로 다음 질문이었어요.

Q. 이 회사에서 지원자분은 어떤 것을 얻고자 하시나요? 그리고 본인은 회사에 어떤 것을 제공할 수 있다고 생각하시나요?

위 질문의 첫 번째 부분은 지원자가 회사의 지원한 동기 혹은 이직 동기에 대해서 정확히 알 수 있으며, 면접관들은 이 질문에 대한 답을 기준으로 이 분이 회사에 입사했을 때에 만족하면서 회사에서 생활을 할 수 있을 것인가에 대해서 생각해보기에 굉장히 좋은 질문이라고 생각했어요. 그리고 두 번째 부분은 본인의 장점이 무엇인가에 대해서 들을 수 있으며, 기본적으로 면접관이 듣기에 해당 질문의 답이 우리 팀에 필요한 것인지 체크해보고, 그 질문에 대한 답이 진실인지 알기 위해서 후속 질문을 이어가보면서 검증해보면 좋겠다는 생각이 들었어요.

9월의 학습

연금의 종류

9월에 학습 주제로는 연금에 대해서 공부하겠다고 했었는데요. 드디어 아주 조금 공부를 했고 조금의 결실을 만들어서 간단히 정리해봐요. 우선 연금의 종류는 다음과 같이 3가지가 있어요.

국민연금
개인연금
퇴직연금

그리고 여기서 특히 개인연금은 세 가지 종류로 나뉜다고 볼 수 있어요.

연금저축보험: 저축보험은 안정적으로 가입한 대로 나중에 금액을 받는 상품
연금저축펀드: 직접 투자를 운용하면서 금액을 쌓아가고 55세 이후부터 연금을 수령할 수 있는 상품
IRP(개인형 퇴직연금): 퇴직금 + 개인 추가 납입으로 쌓아가고 55세 이후부터 연금을 수령할 수 있는 상품

특히 단순히 연금을 구성하기 위해서만 사람들이 들고 있지는 않고 세액공제라는 혜택을 받을 수 있기 때문에 많은 사람들이 찾고 가입하고 있는 상품이에요. 연금 상품에 돈을 넣게 되면 최대 연 600만원 한도로 세액공제를 받을 수 있기 때문에 연금도 구성하고 세금도 절약할 수 있는 상품이에요.

10월의 학습 주제

10월에는 랜덤 학습 주제로서 다음을 생각하고 있어요. 관심있는 회사에 대한 재무제표를 분석하고 회사의 구조에 대해서 공부해보는 시간을 가져볼까 싶어요. 경제 감각이 굉장히 약한 저로서는 굉장히 필요한 공부라고 생각이 들어서요. 도전해보고 재미를 느끼고 싶은 상황이에요.

이렇게 또 연말 느낌이 나는 10월이 벌써 다가와버렸는데요. 모두 추석연휴 잘보내시고, 10월, 11월, 12월도 열심히 살면서 이번 년도 마무리도 잘해볼 수 있도록 같이 노력해봐요. 화이팅이에요. 모두.