(일상) 백엔드로 지내며 있었던 일들

🍀 이게 뭐죠?

두서 없는 글이긴 한데, 그래도 3년동안 지내며 있었던 일들을 일기처럼 기록해두면 좋겠다 싶어 남겨보았다.

생각날 때 마다 조금씩 추가할 예정.

 

 

🍀 무언가 늘긴 했다.

API 기능, 어드민을 뽑아 내는 속도가 많이 늘었다.

시간이 무섭긴 한가보다. API 추가 - 테스트를 뽑아내는 속도가 엄청나게 늘었다. 로직이 복잡해도 문제를 쪼개놓고 하나씩 해결하는 편이다. 특히 어드민. 편성 외주가 따로 있기에 비슷한 인증인가 및 어드민 기능들을 각 서버마다 뽑아야하는데, 처음엔 3주 넘게 걸렸던게 기능이 간단하면 테스트까지 2-3일 정도면 충분했다.

 

다만 무시무시한 트래픽을 맞아 본 적이 없기에 내가 이론으로만 공부하고 적용 한 것들이 대규모에 가서도 잘 먹힐지 확신이 없는건 함정. 그래서 긴장을 놓지 않고 계속해서 공부해 나갈 예정이다.

거의 API 뽑는 기계.. 하긴 비슷한 구성으로 조금씩 바꿔서 4번은 반복한 듯

 

 

문제를 풀기 전 그림을 그려보는 보는 습관이 생겼다.

이전에는 기획서 -> Jira 티켓 -> 코드 개발로 순서대로 진행했고 백엔드 내에서만 검증하고 끝내는 경우가 많았었다.

하지만 경험이 쌓이 다보니 개발자는 문제를 풀어내는 게 중요하지 코드를 예술적으로 만드는 거에 집착하는 게 아무 의미가 없다는 걸 깨닫게 되더라.

기획서대로 만들었는데요? 백엔드 로직상은 정상인데, 사용자 입장에서 보니 이상하긴 하네요.

 

사실 이 말은 내 역량이 부족하다는 걸 인정하는 것과 같다. 코드를 볼 시간에 기획서를 한번 더 읽어보고, 사람을 찾아가 이게 왜 필요한지를 물어보고 더 쉬운 풀이 방법은 없는지 알아내는 과정이 훨씬 더 중요했다.

 

그래서 요즘은 코드를 건드리기 전 그림을 먼저 그려보는 습관이 생겼다. 간단한 와이어프레임 위에다가 사용자 입장에서 정리해두고 "그대로" 만드는게 아니라 "왜" 이걸 만드는지에 대해 계속해서 물어보고 수정해나간다. 재밌는 건 "문제를 명확하기 위해" 문서로 정리하는 건데 하나씩 대화를 이어나가보면 문제 자체가 바뀌면서 아예 처음부터 다시 시작하기도 한다. 

 

내가 이 도메인에 대한 경험이 더 많이 쌓여있었다면, 혹은 문제를 풀 수 있는 방법들을 더 알고 있었다면 훨씬 더 빨리 진행 될 수 있는 것들이 많다고 느낀다. 이건 시간이 답이려나.

 

 

시력이 늘어(?) 코드가 더 잘보인다.

TMI 이긴 한데 최근에 스마일 라식 수술을 했다. 이제 더 맑은 눈으로 코드를 바라볼 수 있다 🙄 그런데 검사할 때마다 시력이 올라가서 이제 검사할 때 1.5가 보이기 시작한다.. 흠 좋은거겠지? 그리고 안경을 벗으려고 라식한건데 뭐랄까.. 10년동안 낀 안경을 벗으니 바지 벗고 출근하는 느낌이라 안경 알만 빼고 끼고 다니는 중.  

 

---

🍀  여러 문제들이 있었다.

언제나 괴롭히는 날 중복 insert

"설마 그 짧은 밀리세컨드 사이에 여러번 요청이 오겠어?"  그렇다. 보통 이렇게 말하면 대부분 발생한다. 그것도 자주 발생한다. 실 사용자가 어쩌다 호출하는 경우도 있겠지만 timeout 발생 시 모바일에 재시도 로직이 대부분 포함되어 있기 때문이었다.

• 가장 간단한 방법은 DB 유니크로 풀어내는 거겠지만 상황에 따라 그럴 수 없거나 비효율적일 때가 많다.
• 보통 정합성이 중요하면 Redis Pub/Sub 으로 간단하게 insert 락을 걸어서 막아두기도 했다. 다만 이 경우엔 Redis 응답이 없을 때 DB로 바로 저장할지, 그냥 에러를 터트릴지 고민이 된다.
• 실시간으로 만들 필요가 없다면 레코드를 생성하는 시점을 바꿔 어드민에서 미리 만들거나 큐로 분리해서 걸러서 저장해도 된다.
• Redis 사용하기 애매한 상황도 있다. 그럴 땐 DB Native upsert 쿼리를 사용했는데, 이건 H2 및 JPA를 사용하지 못해 코드가 더러워지는 단점이 있다. 어떤 방법을 써도 뭐랄까 모든 상황에 깔끔하게 일괄 적용하기가 애매해서 더 나은 방법은 없을까 고민하곤 한다.

사실 무엇을 고르던 장단점이 있긴해서. 그때 그때 다른 방법을 적용하는게 맞는건가 싶기도 하다.

 

 

SpringBoot 3.0 업데이트

개인적으로 https://techblog.lycorp.co.jp/ko/how-to-migrate-to-spring-boot-3 이 글이 끝판왕이라고 생각한다. 3번씩 읽어보자.

버전을 업그레이드할 때 코드를 바꾸고 컴파일이 계속 실패하는건 전혀 문제가 되지 않았다. 오히려 제일 치명적이었던건 "문제가 있는데 서버가 정상적으로 뜨는 경우" 였다.

 

실제로 springboot3.0으로 올라가면서 yml 구조가 변경되어 설정값이 전부 기본값으로 변경되어 운영도중 장애를 겪었는데 정말 끔찍했다. 왜 그러는지 이유도 빨리 찾을 수 없기도하고. 요즘은 디버깅으로 설정값이 적용되어있는지 Config 객체를 직접 확인하곤 한다.

• Spring Cloud Gateway: Spring Cloud Gateway - Appendix A: Common application properties
• Spring Cloud OpenFeign: Spring Cloud OpenFeign - Appendix A: Common application properties
• Spring Cloud Vault: Spring Cloud Vault - Appendix A: Common application properties

 

알 수 없는 Dev 배포 실패

• 로컬에서는 멀쩡했는데, 베타에서는 HealthCheck에 실패하면서 배포가 반복해서 안되는 경우
• 정적인 로그 메시지 하나 수정해서 베타에 배포했는데 간헐적으로 OOM이 발생하는 경우

요즘은 운영 서버 스펙 자체가 그렇게 높지 않다. 대부분의 웹 서비스는 CPU 바운드가 아니라 IO 바운드니, 성능이 부족하면 서버 대수를 늘린다. 특히 베타 서버의 경우 스펙이 최소사양 수준인데, JVM에 이것저것 추가하다보면 메모리가 부족하거나 서버가 뜨는데 오래 걸려 실패로 처리되는 경우가 잦았다.

 

기억하자. 내가 쓰는 Mac 은 실제 운영서버에 비해 압도적으로 좋은 스펙을 가진 서버이다. 이거만 알면 쉽게 유추하고 별거 아닌 문제들이었는데, 정확한 이유를 몰라서 하루를 날리고 인프라 팀의 도움을 받아 겨우 넘어갔던 기억이 있다. 🫠  ..그리고 시간날 때 인프라 공부도 짬짬히 해놔야겠다. 회사에서 대부분 AWS 마우스 딸깍이 전부이니 안될 때 더 당황스러웠었다.

// 당시 에러 메시지
Readiness probe failed: Get "http://...:8080/actuator/info": dial tcp ..8080: connect: connection refused
Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "a5eb65ad7f89ef1ea279338ad24f...28ec9d71e1715121fc7": plugin type="aws-cni" name="aws-cni" failed (add): add cmd: failed to assign an IP address to container

 

 

외부에서 가져오는 것들은 언제나 장애가 날 수 있다.

AWS도 1년에 한번씩은 장애가 난다. 뭐 당연히 인프라 이중화를 할 수는 없지만, 적어도 외부 API 나 캐시등은 뻗었을 때 예외 처리를 해놓고 바로 알 수 있게 구성해야한다. 믿고 사용하면 당장 몇 개월은 아무 문제없이 지나가겠지만 기억속에서 잊혀질 때 쯤 찾아와 서비스 전면 장애를 일으켜 심장 떨어지게 만들었던 경험이 있다.

• MockServer를 활용해서 서비스가 느려지거나 응답 스펙이 이상할 때 테스트도 추가해놓아도 좋고 그게 아니라면 적어도 Dev, Beta에서 걸러질 수 있게 수동으로 라도 확인할 수 있는 테스트를 만들어 두자.
• Redis 도 JSON 스펙이 달라지거나 캐시가 통으로 교체되어 배포시 문제가 되는 경우가 자주 있었다. 캐시를 읽다가 에러가 발생했을 때 CacheErrorHandler를 미리 만들어 두어 DB에서라도 읽도록 추가해두고, 캐시 스펙이 변경되면 새로운 키 prefix 를 할당하여 배포하기 전 캐시를 미리 채워주면 된다.

 

 

---

🍀 지금은 이런 것들을 하고 있다.

토이프로젝트로 LangChain과 Python을 배워보자

대 AI의 시대라 사내에서 관련된 아이디어들이 끊임없이 나오고 최근에 서비스에 적극 반영하려고 하고 있다. 조금씩 공부해보니 새로운 기법들이나 신기한 것들이 끊임 없이 나오고 있어 써먹을 수 있는 곳이 많은데 방법을 알지 못해서 사용하지 않았던 것들이 많더라.

 

- 모델별로 성능을 평가하고 모델을 섞어 사용하는 것도 방법이다.

- 프롬프트가 길 때 Prompt Caching(Claude)를 활용할 수 있다.

- Online Evaluators 을 활용하면 응답에 대한 평가를 쉽게 거를 수 있다.

- 질문 자체가 모호하면 스스로 질문과 답변을 이어나가게끔 ReAct 프롬프팅과 메모리를 적절히 활용할 수 있다.

 

토이 프로젝트를 겸하면서 기존에 OpenAI를 사용해서 간단하게 만들었던 것들을 하나씩 개선시키고, 기획 단계에서 현재 쉽게 구현할 수 있는 아이디어들을 정리하려고 한다.

 

그래서 자연스럽게 다음 글은 사내 AI 활용과 토이프로젝트에 관한 이야기를 할 예정.

 

 

 

내가 한 일들을 정리하고 있다.

글또 9기에 이어 글또 10기에도 신청했다. 저번이 아쉽기도 했고, 어차피 블로그와 노션에 하나씩 정리하고 있었는데 잘된 거 같다.

 

내가 한 업무들, 감정들, 토이프로젝트... 이런 것들을 하나씩 정리해나가면서 내가 무엇을 배웠고 어떻게 개선할 지를 조금씩 적어나갈 예정이다. 지금은 두서없는 글이지만 하나씩 쌓이고 글 실력이 늘다보면 이것들도 경험이 되고 내용들이 더 풍부해지지 않을까 싶다.

 

오늘의 일기(?) 끝!