2024 간단 회고

지금은 1월 1일 오전 9시

올 한해의 시작으로 개발자로서의 2024년의 나에 대한 간단한 회고를 해 보고자 한다.

 

배웠던 것, 아쉬웠던 것은?

 지금까지 개발자로서 일을 한지는 꽉 채워 2년 정도 되어가는데, 회사에서 개발한 프로덕트를 유저가 쓰게 되는 경험이 많지 않았다.

그러다보니 자연스럽게 유저 피드백을 받을 수 있는 방법이 별로 없었다.

 

 그 이유는 1. 유저가 많지 않은 서비스였다거나 2. 하다가 (혹은 다 했는데..) 비즈니스적 이유로 빠그라진 것들이 대부분이었기 때문 ㅠㅠ

 

 그러다가 2024년 6월에 런칭한 웹 사이트가 처음으로 유저 사용이 있었던 사이트였다. 그것도 아주 많았던!

 

GA 에 들어가보니

 

 요 정도로 분석이 되고 있고, 지난 달만 해도 월 8.1천명의 사용자가 사용을 하고 있는 사이트.

 

 그러다보니 혹시나 예기치 못한 버그가 터지진 않을까 노심초사했던 것이 사실이다.

 

 그래서 sentry 툴도 활용해서 달아놓고 유저들이 어떤 버그를 맞닥뜨리는지 분석해 예외 처리도 하고 등등 기본적으로 해야할 에러 핸들링 툴들은 다 적용해 놓았었다.

 

특히나 이 도메인은 특수성이 있는 도메인이다.

서브컬쳐 문화를 도메인으로 하고 있는 행사 소개 및 진행 관련 모든 것을 담고 있는 웹 사이트였고, 유저의 특성이 일반 웹사이트 유저와는 살짝 다른 특성들이 있었기에 겪었던 문제 상황 3가지가 기억에 남는다.

 

유저들이 사이트 및 행사에 진심이라 하나씩 다 까보고 파보고 유저들의 피드백도 커뮤니티에서 바로 바로 확인할 수 있다는 특징으로 알게 된 흔하지 만은 않은 3가지 문제 상황들을 이야기 해 보겠다.

 

 # 첫번째 문제 상황 - 연속적 액션이 일어나는 곳에는 디바운스 처리를 잊지 말자

 웹 사이트 특성 상 부스 신청을 선착순으로 한 날 한 시에 접수 받아야 하는 상황이 있었다. 특수성이 있는 도메인이다 보니 해당 도메인의 유저들에 제대로 녹아들지 못했던 탓인지 이 부스 신청이라는게 이렇게까지 화력이 강할 줄은 몰랐던 것..

 

그래서 토요일 오후 2시에 수백명의 유저들이 몰려서 부스 신청을 했고, 몇 천건의 신청서가 DB에 쌓였다.

실시간으로 쌓이는 DB 신청서를 보고 헉 우리 대박 나나봐..! 했었는데 자세히 보니 중복 접수건이 아주 많았던 것..

 

 테스트할 때는 연타해서 버튼을 갈겨본 적이 없었으니 서버 로딩이 걸릴 때 연속적으로 부스 신청 접수가 될 줄도 몰랐다는게 패착이었다.

 

물론 버튼에 로딩 처리는 해 놓았지만, 로딩 처리가 돌아가기 전에 이미 대량의 중복 건이 발생해버린 상황 ;-;

접수 버튼에 디바운스를 걸어 연속적으로 호출되는 함수 중 마지막 함수만 작동하게 만드는 것으로 추가 조치를 하고, 연속적인 액션이 발생할 수 있는 부분에는 꼭 디바운스를 잊지 않아야 한다는 교훈을 얻었다..

 

또한 테스트 시 실제 시나리오를 충분히 고려해 다양한 상황에서 시뮬레이션을 진행하며 극단적인 사용 패턴 또한 적극적으로 실험 해야 겠다.

 

# 두번째 문제 상황 - 민감한 정보에는 요청과 응답 데이터를 암호화 하자

요청과 응답 데이터를 모두 까 보고 남은 티켓 수량을 파악하는 유저가 등장..

이렇게 까지 이 행사에 진심이라고? 싶은 경험이었다.

 

 

 

 

 사이트 오픈한 후 모 커뮤니티 사이트에 종종 글이 올라오고 있어 눈팅하던 중 이런 글을 발견한 것..!

우리가 주고 있던 데이터를 네트워크 탭으로 확인하며 remain_quantity 를 파악해 지금 몇장이 남았는지를 실시간으로 체크하고 공유하고 있었다ㅠㅠ

 

 물론 서버에서 주는 데이터는 모두 클라이언트에서 렌더링 될 데이터이기 때문에 요청과 응답을 따로 암호화를 할 필요는 없다.

무신사 등등 타 사이트의 네트워크 탭을 까 보았을 때도 모두 평문으로 데이터를 주고 받고 있었다.

 

 하지만 해당 remain_quantity 데이터는 클라이언트에서 매진 여부를 파악하기 위해 특수하게 받고 있던 데이터였기 때문에 암호화의 필요성이 있었던 것을 간과했다.

 

 위 게시물을 확인한 후 바로 암호화 조치를 시행.

(게임 업계에서는 종종 일어나는 일이라 암호화 작업하는 것이 일반적이라고 한다.)

유저가 서비스에 진심일 경우에 일어나는 일인 것 같다.

 

# 세번째 문제 상황 - 현장에서 맞닥뜨린 예외 상황들

사이트에서 제공하는 기능 중에 행사 티켓을 구입하고 그 티켓을 QR 코드의 형태로 보여주어 입장을 도와주는 기능이 있었다. 그리고 축제 현장에 찾아가 입장하는 유저들을 겪으며 알게 된 예외 상황들

 

- 데이터가 부족한 학생이라 집에서 QR 코드를 캡쳐해 온 친구들

- 세로로 접히는 갤럭시 폴드를 쓰는 친구들

 

등등 예외적인 상황들을 모두 처리하지 못했다는 것을 깨닫고 디자인 및 프론트 수정이 필요한 케이스들이 왕왕 있었다.

 

 

이 외에도 우리 사이트와 동일한 앱을 만들고 있는 유저를 발견하기도 하고.. 신기한 사건들이 많았다.

이렇게 여러가지 흔치 않은 상황들을 겪으며 유저의 경험이 있고 없고가 개발 디테일을 잡는데 큰 도움이 된다고 느낀 값진 경험들이었다.

 

 

올해 가장 큰 성취는?

퇴근 후나 주말에 짬을 내어 집에서 개발자 취업을 목표로 하고 있는 친구들과 멘토링을 진행했다.

진행하며 오히려 내가 더 많이 배우게 되어 선순환이 었던 활동이라 나에게 있어서 올해 가장 큰 성취라고 말할 수 있을 것 같다. 

 

1년 동안 진행해 오면서도 사실 멘티들이 진짜로 원하는게 뭔지 파악하기는 힘들어 따로 익명의 설문조사를 준비해 의견을 받아보았었다.

 

 

 

 

 

많지는 않은 응답이었지만 그래도 멘토링 방향성을 점검해 보기 좋았던 설문이었고, 개선해야 할 점은 조금 더 소통을 잘 해 멘티들의 다양한 이야기들을 들어볼 수 있는 형태로 개선은 필요하다고 느꼈다.

 

사실 내가 멘티라고 하더라도 매주 다양한 질문을 하는 것부터 부담이고 한계가 있을 것 같긴하다.

멘티들의 자기 회고를 통해 자연스럽게 질문을 이끌어 낸다거나 코드리뷰를 통해 자연스럽게 소통할 수 있는 기회를 얻는다거나 또 다르게 질문을 할 수 있는 환경을 만드는 방법을 올해에는 모색해 보아야 겠다.

 

무엇보다 멘토링을 하면서 가장 긍정적으로 작용하는 점은 내 스스로가 끊임없이 발전해야 멘토링 시간에 할 이야기도 생기기 때문에 쉬지 않고 개발 네트워킹에 참여하고 스스로 공부하게 되는 원동력이 되는 것이 가장 큰 성취이다.

 

 

2025년에는 무엇을?

# 네트워킹 및 스터디 참여

: 개인적으로 인생의 중요한 일이 하반기에 있었던 터라 하반기에는 네트워킹이나 스터디에 참여를 잘 못했다.

올해부터는 다시 스터디도 네트워킹 이벤트도 많이 참여해 다른 개발자들을 보면서 인사이트를 얻고 또 다시 열심히 일하게 하는 원동력을 얻을 것이다.

 

# 시니어가 되기 위해서 어떤 기술과 역량이 필요할지 고민

: 이제 만 3년차가 되어가는 시점에서 주니어 딱지를 떼고 중니어, 시니어로 거듭나야 하는데 아직은 자신이 없다.

시니어가 되기 위해서 어떤 역량이 필요할 지 종종 고민을 하고 있었는데, 얼마 전 가게 된 네트워킹 강연에서 답을 어느 정도 얻을 수 있었다.

 

• • 페어프로그래밍
  • 공통 라이브러리, 프레임워크 제작
  • 업무 효율화 체계 도입
    • → 스스로 열심히 일을 하는 것 보다는 동료들이 더 효율적으로 일할 수 있게 도와주는 것

요런 것들을 업무에서 스스로 실천할 수 있는 사람으로 2025년에는 조금 더 노력해 보아야 겠다.