| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |
- docker
- zuul
- 반버논
- 애그리거트
- Kotlin
- springcloud
- Spring
- webframework
- MSA
- armeria
- 바운디드컨텍스트
- spring6
- springboot3
- spring scheduler
- spring caching
- Pay
- MongoDB
- springboot
- java17
- 값객체
- 신입
- 개발자
- Conference
- Redis
- ddd
- kakao
- spring-web
- ifkakao
- IDDD
- mongo
- Today
- Total
Easy Understanding
2025년 업무 회고 본문
2025년은 개인적으로도 업무적으로도 정신이 없던 한해였다.
결혼을 하면서 개인적으로 새로운 환경에 적응을 하느라 정신이 없었고,
업무상으로는 서비스 오픈이라는 급박한 환경에도 놓여있었다.
1. 나의 역할
우리 서비스는 커머스로서 다양한 업무가 존재하지만, 그 업무들에 많은 사람이 투입되어 진행할 수 있는 상황은 아니었다.
다른 서비스라면 한 팀이 맡아야 하는 것을 거의 한 명이서 맡고 있는 상황이었다.
물론 개발 초기라서 아직까진 이런 인원으로도 개발은 가능한 상황이었고 결국 오픈은 잘 해낼 수가 있었다.
내가 맡은 업무는 주문/결제 파트이다.
커머스의 많은 부분은 정말로 중요하지만, 주문결제도 커머스의 핵심 부분을 담당하고 있다.
만약 장애가 생긴다면 매출이 끊기는 상황이 올 수도 있기 때문에 부담스러운 파트이기도 하다.
그럼에도 오픈 후 평가를 내린다면 어찌저찌 해냈다라고 볼 수는 있을 것 같다.
필수 기능들과 더불어 중간중간 들어오는 복잡한 요구사항들에 대한 개발도 어떻게든 해냈다.
물론 부분 장애는 가끔 있었지만, 전면 장애라든지 롤백까지는 겪어본 적은 없었다.
원래도 내 연차에 이 정도는 해내야 하는건지는 잘 모르겠지만, 스스로는 그래도 이 정도면 만족스러운 결과였다.
특히나 결제 파트만큼은 이전의 경험을 살려서 좀 더 수월하게 개발할 수 있었다.
오픈 후 운영에 들어가서도 무엇이 어떻게 필요한지 금방 파악할 수 있었던 걸 보면 역시 이전 경험을 무시 못하겠다는 생각도 했다.
2. 경험 부족
하지만 일을 하면서 내 부족함에 대해서도 많은 생각이 들었다.
개발이나 비즈니스의 경험이 부족하다보니 근시안적으로 보이는 것들이 참 많았다.
특히나 어려웠던 것은 커머스는 작은 기능의 추가만으로 그 여파가 도메인 전체로 전달되는 서비스라는 것이었다.
처음에는 간단한 수정이라고 생각했는데, 막상 모든 도메인 담당자를 확인해보면 대규모 수정이 필요한 경우도 꽤나 많았다.
이럴 때마다 커머스 참 어렵다는 생각이 많이 들곤 했다.
물론 지금까지도 주변에서 경험이 있는 많은 분들이 도와주셔서 어려움이 있어도 헤쳐나갈 수가 있었다.
게다가 요샌 ai 프롬프트로 물어봐도 웬만한 건 다 알려준다.
"이 문제에 대해서 다른 회사는 어떻게 하는지 알려줘" 라든지 물어보면 당연히 회사 내부 코드를 보고 알려주는 건 아니겠지만, 나름 합리적인 방향을 제시해주는 걸 보면서 많이 배우기도 했다.
하지만 그럼에도 다른 서비스들은 이 문제를 어떻게 다루고 있는지가 궁금하곤 했다.
역시 사람은 다양한 경험을 해봐야 그 깊이가 넓어질까? 라는 의문도 들곤 했다.
웃기지만 흑백 요리사를 보면서 요리나 개발이나 비슷할 것 같다는 생각도 들었다.
비슷한 재료를 사용하고 비슷한 방법으로 요리하더라도 결과는 다양하게 나오곤 한다.
비슷한 라이브러리와 기술을 사용하지만 사람에 따라 팀에 따라 스타일이 달라질 수 있다는 것이 개발도 뭔가 비슷한 것 같다.
그렇다고 다른 회사에 가고싶냐라고 생각하느냐면 그것도 아니다.
지금까지 내가 만든 프로덕트에 애착이 있고 이게 어디까지 확장되는지 보고 싶은 마음도 있다.
근데 이것이 옳은지 아닌지를 판단하려면 새로운 기준이 필요할 것 같기도 하고.
앞으로도 커리어 적으로 고민이 많이 될 것 같다.
3. 즐거웠던 점
지금 다시 되짚어보니 2025년은 참 재미있게 일했던 한 해였다.
- 새로운 것을 직접 만들어보았다는 점
- 그 과정에서 내가 기여한 것도 꽤 많았다는 점
- 그 서비스가 오픈하고 잘 돌아가는 걸 보았다는 점
- 같이 일하는 사람들이 좋았다는 점
등 나의 2025년 업무는 결론지어보면 참 재미가 있었다.
특히 내가 만든 기능이 매출에 반영되고 있는 걸 보는 것이 참 재미있었다.
로그를 보면서 유저가 별 문제 없이 결제하고 완료화면을 보게 되었을 때 참 신기했다.
물론 우리 서비스는 여기서 끝이 아니고 매우매우 달릴 준비를 많이 하고 있는 서비스이다.
여전히 해야할 일은 많고 돈 벌어올 구멍은 계속해서 만들어 놓는 중이다.
거대한 요구사항들을 볼 때마다 숨이 턱턱 막히는 경우가 많았고 앞으로도 그럴 것인데,
지금까지 그래왔던 것처럼 어떻게든 잘 해내기를 바라고 있다.
올해도 한숨 백만번 쉬면서 어떻게든 해내고, 연말에 웃으면서 마무리하기를 바라고 있다.(휴가를 사용하며...)
4. AI
올해는 비즈니스 개발적인 측면에서는 정말 많은 것을 해냈지만, 막상 기술적으로는 뭘 그렇게 발전했는지 기억이 나지를 않는다.
새로운 라이브러리나 프레임웍을 쓴 것도 아니고, 새로운 아키텍처를 도입하지도 않았고, 심지어 공부도 별로 안 했다.
물론 이건 반성할만한 일이지만 무엇보다도 ai 의 발전에 적응하느라 그럴 시간이 없었다는게 사실 크다.
아마도 연초에만 해도 프롬프트 코딩은 하지 않았던 걸로 기억하는데,
연말이 다 되어서는 클로드 코드가 없어서는 절대로 안될 소중한 친구가 되어버렸다.
다들 비슷한 말을 하겠지만, 클로드 덕분에 2025년 나의 코딩의 패러다임도 획기적으로 바뀌었다.
이것을 통해 만드는 결과물이 달라지거나 새로운 구조가 된 것은 전혀 아니다.
여전히 기존의 기술을 사용했고, 기존의 방법론을 사용했다.
하지만 그 속도와 효율이 말도 안되게 올라간 것이 ai 사용의 핵심이었다.
간단하게 몇 가지로 정리해 보자면 다음과 같다.
1) 아키텍처, 네이밍, 비즈니스 로직 등 고민이 있을 때 해결사 역할
어떻게 보면 기존 선배들의 역할을 대신해주었다고 할 수 있다. 이건 어떻게 해야할까 고민될 때 클로드에게 물어보면 대부분 막히지 않고 해결할 수 있었다. 예를 들면 "기획자가 주문에 이런 기능을 넣어달라고 하는데 어떻게 하면 좋을까?" 라고 물어본다면 클로드는 어느 정도 해결책을 정해준다. 물론 내가 고민해도 되고 공부해서 떠올릴 수도 있지만, 이미 한 번의 타이핑으로 만족할만한 답변이 나오는데 굳이 그럴 필요가 있을까 싶은 것이다. 물론 대부분의 상황에서 만족할만한 답변을 주지 않아서 직접 고민할 때도 많지만, 이 정도면 충분히 해결사라고 부를만 한 것 같다.
2) 테스트 코드 작성 효율 폭발적 증가
ai 는 우리의 프로덕트를 테스트해주지는 않는다. 만약 가능하다고 해도 확률에 의해 돌아가는 ai 를 신뢰할 수는 없는 노릇이다. 그러면 확률을 100퍼센트로 만들어주는 테스트코드를 ai 에게 맡기면 된다. 이 덕분에 테스트 코드 생산량이 획기적으로 늘었는데, 기존엔 귀찮아서 넘기곤 했던 테스트코드를 무조건 만들도록 한다. 이젠 테스트에 대한 변명은 할 수 없게 되었다.
3) 노가다 작업 해소
이름 바꾸기라든지, 리팩터링이라든지 일괄 수정 등 노가다로 느껴지는 작업들도 참 쉬워졌다. 이런건 일을 시키기도 쉽고 확인하기도 쉽다. 그냥 클로드를 돌려두고 잠시 화장실을 갔다오면 다 되어있는데 아주 만족스러웠다. 심지어 퀄리티를 요구하는 어드민 ui 는 생산량이 거의 100배는 늘어난 것 같다. 이전 프로젝트를 할 때 어드민 메뉴 하나 만드는데 하루가 걸렸고, 뭐 특별한 ui 만드려고 하면 하루가 더 걸렸는데 지금은 딸깍 한번으로 이 모든게 끝난다. 심지어 퀄리티도 더 좋게.
주변에선 우스갯소리로 클로드 쿼터 다 사용하면 일 안한다라는 얘기도 하더라.
근데 슬슬 이젠 농담도 아니게 된 것 같다.
이젠 농기계를 쓰다가 굉이로 넘어가는 느낌일 것 같다.
5. 2026년의 목표
그렇다면 올해 2026년 나에게 필요한, 내가 발전시키고 싶은 능력은 무엇일까.
2025년이 ai 로 개발계에 큰 바람을 불어왔지만, 그럼에도 불구하고 여전히 필요한 능력은 있다.
ai 는 개발을 하는 방식을 변화시켰지만, 여전히 그 산출물은 코드이고 새로운 개발 패러다임은 제시되지 않았다.
여전히 기존 지식에 대해서는 전문적인 수준으로 유지가 되어야 한다는 것이다.
그리고 계속 느끼는 것이지만 복잡한 비즈니스가 문제다.
복잡한 비즈니스를 풀기 위해서는 코드 말고도 해결해야 할 것이 너무나도 많다.
커뮤니케이션이나 협상 등 여전히 ai 로도 불가능한 영역이 개발자에겐 많이 남아있다.
그 과정을 이해하고 개발을 위한 방향성을 빠르게 정하는 것이 여전히 개발자에게 필요한 능력이 아닐까 한다.
그리고 내가 2026년 잘하고 싶은 것이 있는데 문서화와 도식화이다.
일을 하면서 느낀 것이 문서화와 도식화는 하는 사람만 하고, 잘하는 사람은 계속 잘한다는 것이었다.
사실 개발자로서 코드만 잘 작성하면 어떠냐고 생각할 수 있는데 그것도 맞는 이야기이다.
이런 거에 신경을 크게 쓰지 않아도 어떻게든 결과만 내면 큰 문제는 없다.
하지만 개인적으로 문서화는 자기만족뿐 아니라 개발자간 협업에 큰 도움이 된다고 생각은 하고 있다.
2025년엔 바쁘다고 핑계되며 많이 만들지 못한 것 같은데, 올해는 좀 제대로 해볼까 하고 있다.
마무리
원래 내가 정리하려고 했던 회고의 주기는 분기별이었지만, 부끄럽게도 오랜만에 회고를 써 보았다.
쓰기 전엔 내 2025년 커리어가 주어진 일 만하다가 이렇게 끝나는 게 아닌가 싶었는데,
정리하며 쓰고보니 모아두면 나름 하나의 정리된 흐름이 보여서 뿌듯하고 다행이다.
2021년 12월부터 일을 시작하고, 어느덧 만 4년이 넘는 커리어가 되었다니 시간이 참 빠르다.
물론 글을 쓰다보니 아직 갈 길이 먼 커리어라는 생각도 들기도 한다.
올해도 작년만큼 치열하게 돈을 벌고 다시 회고를 작성해봐야겠다.
'Job' 카테고리의 다른 글
| 주니어 개발자 2023 2분기 회고 (0) | 2023.07.01 |
|---|---|
| 주니어 개발자의 2023년 1분기 회고 (1) | 2023.04.01 |
| 2022년 4분기 + 2022년 회고 (2) | 2022.12.25 |
| 2022년 3분기 회고 (1) | 2022.10.08 |
| 2022년 2분기 주니어 개발자의 회고 (2) | 2022.07.03 |