회고 | 2025년 - 완벽보다 완료!

출처: https://newneek.co/@highoutputclub/article/13982

회사

2번의 릴리즈 2번의 QA

여름과 겨울 두 번의 QA를 끝내고 맞이한 2번의 릴리즈.

4-5개월가량 열심히 준비한 결과물이 얼마나 요구사항에 적합하게 만들었는지, 사용성에 불편함은 없는지, 논리적인 오류가 없는지 등을 시험하는 일은 아무리 겪어도 매번 떨린다. 열심히 만들었다고 하지만 나도 모르는 결함이 있을까 봐 물가에 내놓은 자식처럼 QA 기간은 늘 노심초사이다.

 

• 상반기 - QA는 첨부파일 관련 이슈가 많이 올라왔다. 기존 각 서버의 파일 시스템에 적재하던 첨부파일을 minIO로 전환 작업과 함께 첨부파일 로직을 공통화했고, 덕분에 12월에 진행한 QA에서는 첨부파일 결함이 올라오지 않았다.
• 하반기 - UI 오류가 무려 33%를 차지했다. 변명을 하자면 한도 끝도 없다는 걸 알기에.. 겸허히 받아들이겠다. 아예 어려운 문제 틀리면 인정하겠는데, 잘못 보고 틀린 문제도 있어서 조금 더 구질구질해지는 마음,,, 분명 잘 되었다고요.. 억까라고요.. 
  

 

다음엔 개발 단계에서부터 figma mcp를 적극적으로 활용하리라 다짐했다.

팀원분께서 cursor - figma mcp 연동 방법을 공유해주셔서 이번에 적용해 봤다. 실제로 써보니까 "실제 소스와 기획서를 비교했을 때 어떤 차이점이 있는지"를 알 수 있어서 엄청!!! 든든했다. 감사합니다 하트

틀린 그림 찾기에 자신감이 생겼어요..

앞에서 끌어주고 뒤에서 밀어주는 기획자와 개발자

n번의 QA를 지나며 기획자분들과의 긴밀한 협조가 중요하다는 것을 깨달았다. 하반기 QA는 기획자 분들께 적극적으로 현재 개발된 사항과 QA에서 지적으로 나올 수 있는 문제점에 대해 미리 공유드렸다. (우리는 같은 배를 탔고!!! 우리는 한 팀이다!!를 강조함) 기획적으로 풀 수 있는 이슈가 있다면 기획서에 반영하고, 개발에서 해결할 수 있다면 일정에 무리되지 않는 선에서 해결했다. 그래서인지 12월 QA에서는 기존 로직을 뒤엎는(?) 결함이 발견되지 않아 아주 뿌듯했다.

 

2024년에는 도메인에 대한 지식이 충분하지 않은 상태에서 개발을 하려니 기획 의도를 파악하기 어려웠고, 누락된 예외처리나 정책이 있으면 개발을 뒤엎어야 하는 상황에 분노(?)했다면, 2025년은 도메인 지식이 늘어나고, 기획에서 놓친 부분을 역으로 제안하며 같이 만들어서 더 탄탄해진 정책 위에서 성장했던 거 같다.

 

AI 잡도리하는 법을 배우다.

6월부터 전사 차원에서 cursor를 지원해 주고, 적극적으로 사용하는 것을 권장했다. gpt와는 다르게 코드 context를 기반으로 답변을 주기 때문에 좀 더 만족스러운 결과가 나왔고, 도입 전과 비교했을 때 24시간 걸리던 업무가 5시간만에 끝났으니 업무 효율이 올라간 건 말할 것도 없다. 할루시네이션을 판단하기 위해 올해 공부 키워드를 “기본기”로 잡고, AI의 헛소리와 오버엔니지어링에 흔들리지 않는 나만의 코어를 갖기 위해 노력했다.

 

"너 진짜 맞아? 나는 ~라고 생각하는데 너가 그렇게 생각하는 근거는 뭐야"하며 AI 잡도리를 하며 완성도를 높여갔다.

여기서 세이브한 시간을 기획서 검토에 투자했고, 누락된 내용이 있는지, 요구사항을 제대로 이해한 게 맞는지 더블 체크하는 데 사용할 수 있었다. 전에는 개발에 급급 → 요구사항 애매 → 자의적 판단 → 어 이거 아닌데! → 갈아엎기 → 분노의 악순환이었다면, 이제는 요구사항이 애매하면 바로 물어본다. 애매할 때 차라리 걸고 넘어지는 게 지름길이라는 걸 깨달은 것도 한 몫을 하는 거 같다.

 

API 100개 이관 작업에 큰 도움을 준 cursor야 고맙다..

아키텍처를 바꿔 보니까요

백엔드 아키텍처 변경 작업은 하반기 중요한 과업 중 하나였다. 한정된 자원으로 쉽지 않은 길이었지만, 팀원 모두 동의하고 있었다.

 

이대로 가다간 더 큰일남.

 

기존 아키텍쳐의 문제점은 “유지보수”,“재사용”,“확장”이 어려운 구조였다. 핵심 비즈니스 로직과 순수 비즈니스 로직이 혼재되어 있어 흐름 파악이 어려웠고, 다른 도메인에서 순수 비즈니스 로직을 사용하기 위해서는 cmd + b(해당 코드를 사용중인 코드로 이동 명령어)로 소스를 타고 타고 타고 가야 하는 상황이 반복되었다.

 

 

한정된 시간, 인력, 자원임에도 점진적으로 계속 바꿔나갔다.

 

핵심 비즈니스와 순수 비즈니스(=도메인)를 나눴고, 핵심 비즈니스에서는 흐름 파악을 최우선순위로 두어 구체적 구현을 모르도록 추상화했다. 서비스 레이어의 메서드명도 기존에 “어쩌구저쩌구를이런조건으로만든다” 에서 “만든다”로 축약할 수 있었다. 이게 가능했던 이유는 서비스 레이어는 결국 도메인들을 결합한 형태이고, 구체적 구현은 해당 도메인에서 이루어지기 때문이다. 글쓰기의 완성은 퇴고인 것처럼, 코드를 덜어내니까 핵심 비즈니스가 보였다.

 

성장

나 != 내 코드

코드와 나를 분리하려고 노력했다. 이건 나에 대한 비난이 아니며 더 좋은 제품을 만들기 위함이라고 마인드 컨트롤했다. (그게 사실이고!)

 

작업 대상은 “구체적으로” 

작업 시작 전 최대한 구체적으로 작은 거 하나하나 리스트업을 해나갔고, 중간에 다른 업무가 치고 들어오더라도 누락된 사항 없이 작업할 수 있었다. 다른 팀원과 협업 시에도 커뮤니케이션 비용 절감! 과거에도 리스트업은 했었다. 수영장 조식 룰루였지만,,

좌: 과거 우: 현재

사내 역량 시험 합격! 

드디어 합격했다. ^.ㅜ..

2026 액션 플랜

이력서 업데이트

• 랠릿 회원 가입하고 업데이트밖에 안 했음... 
• 포트폴리오 스터디 참여해보자 

서평 리뷰 4회

• 분기별로 한 번씩 서평 쓰고 싶다.
• "글 쓰는 개발자" 자아 챙기기

AI와 함께 일하기 위해 어떤 준비를 해야 할까 고민

• AI 협업 관련 컨퍼런스 참여 

새롭게 시작한 인강 완강

• 자바 고급2 
• 클린 코드 

나만의 서비스 프로토타입으로 만들어보기

• 진짜 허접해도 좋으니 완벽보다는 완료를 목표로 일단 해보자

 

지난 회고 모음

회고 | 거창하고 대단한 의미 없어도 괜찮은 25년 상반기

 

회고 | 글 쓰는 또라이가 세상을 바꾼다. 글또 10기를 마무리하며

 

후기 | 글또 프론트, 모바일 반상회 후기