728x90
반응형
1️⃣ 한 줄 요약
2025년은 나에게 어떤 해였나
네이버시스템이 망했다. 그치만 쉬는 기간동안 그렇게 불안하지 않은 것이 신기했다.
이직한 회사가 너무 힘들어서 처음으로 회사 스트레스라는 걸 경험했다.
과중한 업무를 감당하면서도 부족한 시간을 쪼개 나를 돌아보는 시간을 갖는 것이 숙제였다.
요가 강사 자격증을 따며, 마음공부를 했고 새로운 사람으로 크게 성장한 해였다.
내가 동시에 살았던 모습들
2025년의 나의 역할
- 👩💻 개발자로서의 나: 회사에서 개발하기
- 🧘 요가를 수련하고 가르친 나: 하타요가안 TTC과정을 듣고 새벽 수리야 요가 안내하기
- 🗣️ 영어를 배우는 나: Chatgpt로 영어 공부하기
- 🧍 그냥 한 사람으로서의 나: 넷플릭스 보기
역할들이 서로에게 남긴 흔적
- 일이 요가에 준 영향: 힘들어도 마음을 지킨다는게 무슨 말인지 삶으로 경험하게 해줌.
- 요가가 일에 준 변화: 힘들 때 내 마음을 돌아보게 함.
- 영어 공부가 나의 태도나 자신감에 준 영향: gpt와 대화하는게 너무 어려워서 두려운 상태. 하지만 희망을 놓지 않는 중.
- 어느 역할이 가장 나를 지켜주었나? 일 끝나고 집에와서 밤에 하는 취미를 하는 나가 나를 지켜줌
2️⃣ 올해의 키워드 3가지
- 키워드 ① : MSA
- 키워드 ② : 받아들이는 태도
- 키워드 ③ : 시간이 없더라도 나를 챙기는 습관
3️⃣ 기술 스택 회고
🔹 Frontend
- 주력 기술: nginx, react, docker, jenkins
- 올해 가장 많이 다룬 기술: CI/CD, react
- 새로 익힌 것: jenkins
- 아직 불안한 영역:
- react 컴포넌트 조합
- react 컴포넌트 조합 관련한 부분 깊게 공부해서 공통 refactoring하기
- jenkins pipeline
- jenkins pipeline의 소요시간을 줄이기위한 공부
- react 컴포넌트 조합
🔹 Backend
- 주력 기술: spring boot, msa, docker, jenkins, keycloak, postgresql
- 올해 가장 많이 다룬 기술: msa 기반의 spring boot
- 새로 익힌 것: docker, msa, nginx
- 아직 불안한 영역:
- MSA
- msa를 깊게 공부하기 (지금은 프로젝트 쪼개는 정도)
- keycloak
- 깊게 공부하기 (인증서버를 동료와 함께 개발해서 온전히 이해하지 못함)
- MSA
잘한 점
- CI/CD : Docker, MSA구조로 프로젝트 생성 및 CI/CD를 처음임에도 안정적으로 잡아서 배포에 들어가는 시간을 크게 줄였다. 덕분에 툴 뿐만 아니라 서버 구성에 대해 배울 수 있었다.
- Cursor, AI 도입. Claude와 Cursor를 써보며 AI 와 일하는 방식을 터득한 해이다. 개발속도가 빨라지면서 재미를 더 붙였다. 코딩의 디테일보다는 시스템을 만드는 법을 배워야겠다고 생각했다.
- 소통 : 타 팀과의 소통에 힘듦이 있을 때, 팀장님과 이야기 한 점. 팀장님이 상황을 풀어주시는 과정을 보면서 어떻게 해야하는지 배울 수 있었다. 되는 것과 안되는 것을 나누어 안되는 것에 대해 논리적으로 설득하고, 되는 것은 진행상황을 확실하게 표시하는 것만으로도 소통에 크게 도움이 되었다.
아쉬운 점
🔹 Frontend
- 사용한 프레임워크/라이브러리: react, kendo-react
- 상태관리/빌드도구: jenkins, vite
- UI/UX에서 배운 점:
- 사용자관점 (요구사항으로 끝나지 않고 사용자가 어떻게 하면 편할지) 을 고민하며 개발할 것
- 커서 모양
- 가독성
- 사용자 편의 기능 (노선 복제 등)
- 사용자관점 (요구사항으로 끝나지 않고 사용자가 어떻게 하면 편할지) 을 고민하며 개발할 것
- 아쉬운 점
- 시간이 없어서 가독성이 부족하게 짠 코드가 있음. (특히 인증 코드)
- kendo-react-v1 (2024년에 만듦, kendo react를 wrapping해서 공통으로 사용하고 있음) 이 조금 더 가독성 있었으면, 다른 코드들도 훨씬 가독성 있었을 것.
- 팀원들의 코딩 스타일이 많이 달라서 가독성이 떨어짐. 모두가 react를 더 깊게 알도록 공부할 필요가 있음
- react-router-dom의 상태관리와 context, redux의 상태관리 등이 혼재되어있음. 각 사용을 명확히 할 필요가 있음.
- 시간이 없어서 가독성이 부족하게 짠 코드가 있음. (특히 인증 코드)
🔹 Backend
- 사용한 프레임워크/라이브러리 : java 17, springboot, POI, OZ
- backend에서 배운 점
- AI를 이용하면 에러 로그 등을 예쁘게 찍기 좋다.
- ExcelDownload시 사용자에게 에러 메시지 표출
- java에서 @Async를 이용하여 비동기 처리 하는 방법
- MSA를 할때는 응집성이 중요하다
- 결합도가 높으면 MSA의 의미가 떨어지고 유지보수가 힘들다.
- AI를 이용하면 에러 로그 등을 예쁘게 찍기 좋다.
- 아쉬운 점
- MSA에 맞는 아키텍처 필요 : MSA에 DDD를 적용하여 응집도를 높이고 싶었는데, 팀원들과 함께 공부하지 못해 적용하지 못했다. 나 혼자 안다고 될 일이 아니며, 혼자서 하고싶다면 DDD에 정통한 후 논리적으로 설득해야 함을 알았다.
- AI가 짜준 코드를 내가 다시 짜라고 하면 완전히는 못 짤 것 같다. AI의 능력이 내 능력이 되도록 습관적으로 노력해야 한다. (앞으로는 AI가 코드를 짤 텐데 내가 잘 짤 필요가 있을까 하는 의문은 있다.)
가장 성장했다고 느낀 부분
🔹 DevOps
- 다뤄본 것: Docker, Jenkins, MSA, Nginx …
- Docker기반 MSA의 CI/CD 구조를 처음부터 구축했다.
- 툴 뿐만 아니라, 서버 구성에 대해서 알게 되었다.
인상 깊었던 장애 or 이슈
- 원인: 설계의 부족으로 인한 지속적인 재개발, 요구 사항 도출의 부족으로 인한 설계의 부족, 문서화의 부족으로 인한 요구 사항 도출의 부족.
- 내가 배운 것:
- 처음 설계를 해봤다. PM은 요구 사항을 한 줄로 밖에 주지 않으며 자주 바뀐다는 것을 경험했다. 요구 사항을 도출하고 문서화하며 확장 가능하게 개발하는 일은 개발자의 몫이다.
- 설계를 처음부터 잘 해야 한다. 설계를 잘 하기 위해서는 적극적으로 문서화하고, AI의 도움을 받을 수 있다. (도메인별로 문서정리를 하는 방법을 고민중 - 인수인계, AI와 협업에도 좋을 듯)
4️⃣ 가장 기억에 남는 프로젝트 2~3개
📌 광역 BMS
- 목적: 지자체마다 각각 있던 BMS를 통합하여 광역 BMS를 만든다.
- 내 역할: 광역 BMS 요구사항에 따라 프론트, 백엔드 개발 및 개발서버 배포
- 기술적 도전: MSA구조로 CI/CD하기, 대용량 엑셀 업로드 기능 만들기.
- 결과: MSA구조로 적절히 프로젝트를 나누고 jenkins pipeline을 작성하여 CI/CD, AI를 이용하여 엑셀 템플릿이 맞지 않을 때 사용자에게 보기 좋게 알림을 보여주는 기능 개발.
- 회고 한 줄: 급박한 상황에 더한 새로운 기술에 하루하루가 힘들었지만, AI와 협업하며 상황을 타개해나갈 수 있었다.
5️⃣ 문제 해결 & 의사결정
✔ 잘한 선택
- 이유: 신 버전을 만들지 않고 구 버전 react-kendo v1을 도입한 것.
- 결과: 신버전을 만들거나 팀원들에게 새로 배포하고 배우게 하는 시간도 들지 않음. 버그도 별로 없었음. 프로젝트를 개발할 시간을 갉아먹지 않았으며, 팀원들도 만족스러워 했음.
❌ 아쉬운 선택
- 당시 판단: 아쉬운거 없이 너무 잘했고 수고했음. 그래도 하나 뽑자면, 소통의 오류로 domain에 맞지 않은 위치에 개발한 API가 하나 있음.
- 지금 다시 한다면: AI를 이용해 적절한 프로젝트 위치에 API를 옮겼을 것.
6️⃣ 협업 & 커뮤니케이션
- 협업에서 잘한 점:
- 힘들었던 관계: 사업팀에서 QA를 하며 나오는 로직적 누락과 버그, 편의기능 등을 모두 시간적 상황 때문에 모두 받아들이기 힘든 상황에서 그저 화가 남.
- 배운 점: 팀장님을 보며 할 수 있는것과 할 수 없는것, 기한 등을 명확히하고 사업팀에게 논리적으로 설득하면 된다는 것을 배움.
- 내가 바꾸고 싶은 협업 방식:
- 나 - 사업팀 : 내가 팀장이라고 생각하고 명확히 한 것들에 대해 논리적으로 설득하기.
- 나 - 나 : 나를 비난하지 말 것. 오류가 나온다며 나를 비난한다고 생각하였으나, 실제로 타인은 나를 비난하지는 않았음을 깨닳음. 내가 상황에 화가 난 것 뿐이라는 것을 깨닳음.
7️⃣ 나의 개발자 정체성
- 나는 어떤 개발자인가?
- 성장하고 싶은 개발자.
- 많은것을 자동화하고자 하는 개발자.
- 올해 바뀐 생각:
- 성장하기 위해서는 가만히 앉아 책 보는 일이 중요하다.
- 코딩을 너무 잘 할 필요는 없지만, 코드를 읽고, 설계하는 능력은 너무 중요해졌다.
- 지키고 싶은 기준:
- AI를 쓰다가 코드적으로 생각하는 법을 잊지 말 것.
- 앞으로 버리고 싶은 습관:
- 기능 중심으로 생각하는 습관 → 사용자 중심으로 생각하는 습관
8️⃣ 몸과 마음 관리
- 체력 관리: 일주일에 하루는 꼭 쉬기. 잠 8시간 자기. 일주일에 한번은 꼭 운동하기
- 스트레스 관리: 아무리 바빠도 하루를 마무리할 때 나를 돌아보는 루틴 가지기.
- 개발 외에 나를 지탱한 것: 요가 TTC
- 번아웃 신호는 있었나: 일이 너무 몰아쳐서 대체적으로 번아웃 상태였고, 종종 다 때려치고 싶었지만, 하루만에 그 상태에서 빠져나오는 것도 신기했다. 요가 도반들과 나를 챙기는 시간을 매일 가지고 있는데, 한가지 깨달은 것은 번아웃이 있더라도 나를 돌아보면 생각보다 내 영혼은 괜찮다는 것이다.
9️⃣ 2026년을 위한 질문
- 더 깊어지고 싶은 영역은?
- 확장가능, 재설계 가능하게 소프트웨어를 설계하는 방법
- 기술 말고 키우고 싶은 능력은?
- 아무리 지치고 힘들더라도 나를 돌보는 능력
- 타 팀과의 커뮤니케이션 능력
- “이건 꼭 해보고 싶다” 1가지:
- AI와 협업하는 표준안 만들기.
- 1년 뒤의 나에게 하고 싶은 말:
- AI에게 사용당하는 사람이니, 사용하는 사람이니?
🔚 마무리 문장
2025년의 나는 최선을 다했는가? YES / NO
YES. TTC하면서 풀야근 회사 다니기. 매 순간 최선을 다하지 않으면 살아남지 못헀어.
728x90
반응형