티스토리 뷰
들어가는 글
벌써 2025년이 끝나가고 있다.
이에 따라 올해 내가 일을 하면서 어떤 선택을 했고, 그에 따른 결과가 어땠는지 정리해보고자 한다.
개인적으로 올해는 폭발적인 기술 성장보단 어떤 환경에서 어떤 개발을 하고 싶은지 커리어를 정리하는 한 해가 되었다고 생각된다.
일
보안 회사 근무(~3월)
작년 7월부터 예전에 산업기능요원으로 다니던 회사에서 근무를 하고 있었다.
해당 회사에서 내가 맡았던 부분들은 ASM 솔루션 개발이다.
팀 내에서는 Python으로 작성된 정보수집/공격 자동화 엔진 개발 쪽으로 간략히 정리하면 다음과 같다.
- Python 으로 작성된 정보수집/공격 자동화 엔진 고도화
- MSA 에서 서비스 - 엔진 간 Event-Driven Task Orchestration
- Debezium을 통해 MSA 에서 읽기 병목 개선 및 서비스 간 책임 분리 유지
기술적으로는 굉장히 마음에 드는 경험을 할 수 있었다.
특히 MSA 환경에서 비동기 작업과 데이터 흐름을 설계해볼 수 있어서 좋았다고 생각된다.
이직
예전 회사에서 했던 일들을 솔직히 말하자면 기술적으로는 굉장히 마음에 들었다.
일단 CRUD 개발은 누구나 할 수 있기에, 저렇게 Task 단을 개발하는 것을 개인적으로 좋아한다
심지어 기술 도입 같은 것도 본인이 책임질 수만 있다면 자유롭게 도입하고 개발할 수 있었다.
그리고 오래 다녔던 회사(산기요 23개월 + 파트타입 18개월 + 정규직 8개월) 라서 심리적으로 편하기도 했다.
그럼에도 불구하고 이직을 결정한 사유를 풀어보자면 다음과 같다.
코드 리뷰 문화 부재, 중장기 계획 부재.
일단 기획이라는게 없다. 구두로 이런게 되면 좋겠다라고 하면 그냥 한다. 테스트나 QA 이런 것도 없다 일단 개발한다
내가 개발한 것에 대한 피드백 같은 게 전혀 없다.
이렇게 하면 자유도는 높긴 한데, 다음과 같은 단점들이 있었다.
- 개발하는 사람에 따라서 코드 퀄리티가 천차만별이다.
- 다른 사람이 개발한 것에 대해 전혀 알지 못하고, 만약 그 사람이 퇴사하면 모든 노하우가 유실된다
- 개발자 개인적으로 잘못된 코드를 짠 것인지 알 길이 없다 (오로지 개인의 능력에 의존함)
- 제품, 개발자 성장 모두에 악영향을 끼치게 된다
보안 개발이라는 도메인이 백엔드로서 메리트가 크지 않다.
보안이라는 도메인은 굉장히 중요하고 매력적인 도메인이라고 모두 생각은 한다.
그러나 그것으로 돈을 버는 것은 다른 문제다.
실제로 채용 공고들을 살펴보면 이 스킬과 경험이 다른 곳에서는 매력적이지 않았다.
막상 면접에 가보면, 내가 해온 것들을 설명하는 것부터가 어려움이 있었다.
- 내가 개발한 것에 대한 질문보다는 일단 보안회사에 있던 사람으로 인식됨
- 백엔드 개발을 하고 싶은 사람으로 어필하기 쉽지 않다.
내가 하고 싶은 것은 백엔드 서비스 개발인데, 해당 회사에서의 경험을 고려해봤을 때 방향성이 맞지 않았다.
만약 보안 개발이라는 도메인으로 진입을 하고 싶다면, 다음의 사람에게 추천한다.
- Low-Level 장비를 다룰 수 있는 포지션으로 가고 싶은 사람(=방화벽)
- 아예 DevOps 나 Cloud Engineer 가 하고 싶은 사람
- 보안 개발 말고 아예 보안 직군 자체로 가거나 보안 도메인 자체에 매력을 느끼는 사람
어쨌든 나는 이러한 방향성 문제로 다른 업무를 하는 곳에 지원하고자 했다.
이전부터 알고 있던 사람들이 많이 퇴사를 했고, 회사에 오래 다니는 사람이 없다.
최고의 복지는 동료라는 말이 있다. 아무리 힘들어도 동료들이랑 같이 하면 버틸 수 있다.
그런데 그런 동료들이 다 퇴사를 한다면 정말 우울해진다.
특히 회사에 오래 경력을 쌓은 사람들이 거의 없고 주니어 레벨들만 들어온다면 이직을 고려할 필요가 있다.
새로운 회사 합류(3월~)
아무튼 이런저런 이유들로 인해 현재 다니는 회사로 이직을 하게 되었다. 여기서 맡은 포지션은 백엔드 서비스 개발로, 기존과 유사하게 Python 백엔드이다. 올해 내가 맡았던 일들을 시간순으로 간략하게 요약하면 다음과 같다.
- 성과요약, 메시징 기능 설계 및 개발(신규 기능)
- SCM 개발(신규 프로젝트)
- 기존 서비스 리팩토링 및 개선
- 결제 구독 시스템 설계 및 개발(신규 기능)
현 회사에서 한 일들은 가능한 별도의 블로그 글로 풀고, 여기서는 기존 회사와 달라진 점만 간단히 요약한다.
개인적으로 성장한 부분
기존 회사와 비교해서 현 회사에서 내가 집중한 부분은 다음과 같다.
- 혼자 잘 개발하는게 아니라 팀으로 제품 가치를 끌어올리기
- 재택근무라는 환경에서 자기 절제력과 생산성을 높이기
- 코드 리뷰에 익숙해지고 효율적으로 개발하기
그리고 백엔드 개발 포지션으로 정착하게 되면서 다음의 장점들이 있었다.
- 트랜잭션을 관리할 일이 많아졌다.
- 메시징, 결제 도메인을 다룰 수 있게 되었다.
- 어떻게 하면 프론트엔드와 효율적으로 일할 수 있을지 고민하는 습관이 생겼다.
물론 아쉬운 점도 존재한다.
- 기존과 같이 자유로운 설계 및 기술 도입은 어렵다.
- 좀 더 API 쪽 일을 하게 되면서 뒤의 Task 나 아키텍처 설계랑은 거리가 생겼다.
Django
기존 회사보다 서비스에 더 밀접한 개발을 하게 되면서 API, 도메인 모델링에 집중할 수 있었다.
백엔드 프레임워크로는 Django Ninja 를 사용했는데, 여러모로 장점이 있었다.
특히 컨트롤러 단에서 편한게 많았는데 나열하면 다음과 같다
- Pydantic 기반으로 Schema 처리되서 FastAPI처럼 API 짜기 매우 편하다
- 인증 처리할 때 Django 에서 제공해주는 User 객체가 Controller 에서 쓰기 편하다
그래서 FastAPI 에 Django ORM 을 붙여서 쓰는 느낌이 들어서 매우 편하긴 했다.
DDD(Domain-Driven Development)
개발을 하다보면 코드들이 매우 비대해지기 마련이다. 이에 대해 도메인 경계를 잘 나누는 것이 중요하다.
코드가 비대해지는 이유는 여러가지가 있겠지만, 주로 다음과 같다
- 컨트롤러, 서비스, 레포지토리 간 역할 분리가 모호하다
- 도메인간 역할 분리가 모호하다
- 서비스에 모든 로직을 배치한다
팀에서는 신규 프로젝트를 구현할 때 이러한 것들을 피하기 위해 DDD 를 도입하기로 결정했다.
DDD에 대한 상세적인 설명은 생략하고, 사용하면서 주의한 점을 정리하면 다음과 같다.
- 각 도메인 간의 명시적인 class import 및 호출은 없다.
- Queryset 의 사용은 반드시 Repository 에서만 처리한다
- Controller - Service - Repository 는 항상 DTO, Entity, Aggregate 만을 주고받는다
- 모든 Service 는 최소한 Query, Command 로 분리되어 작성된다.
- 만약 각 서비스 간 호출 의존성이 생기는 경우 반드시 OutQuery, OutCommand를 통해 호출한다.
- 만약 각 서비스 간 시간 의존성이 생기는 경우 반드시 Event 객체 및 Handler 를 등록하여 사용한다.
이에 따른 특징은 다음과 같다.
- 일단 도메인 정의만 잘 되어 있다면 개발하기 이렇게 편할 수가 없다.
- 코드가 단순히 깔끔해지는게 아니라 일종의 템플릿을 작성하듯이 명확하고 편리해진다.
- 단 초기 셋업이 오래 걸리고 도메인 간 의존성을 푸는게 복잡해질 수 있다.
스킬
작년에 비해 스스로 기술적인 성장을 많이 하지는 않았다고 생각된다.
그래도 일단 올해 한 것들을 정리하면 다음과 같다.
사이드 프로젝트
작년에도 하던 사이드프로젝트인 유니페스를 이어서 개발했다.
내가 맡았던 부분으로 기억나는 것은 웨이팅 관리로 Redis의 ZSET 을 정말 재밌게 사용했다.
컨퍼런스 참여
지금까지 개발자라는 타이틀을 달고 컨퍼런스라는 것을 가본적이 없었다. 올해는 파이콘에 참여를 해보았는데, 재밌었다.
개인적으로 CPython CORE 와 새로운 파이썬 버전에서 GIL 과 관련된 이슈들을 흥미롭게 봤다. PySpark 에 대해서도 봤었는데, 이건 현재 회사에서 데이터 파이프라인 구축할 일이 있을때 활용할듯하다.
기술 블로그
올해 10월 쯤부터 블로그에 글 쓰는 것을 하게 되었다. (블죽모)
그렇게 영양가 있는 글은 아니지만, 역시 명확한 기억보다는 흐릿한 기록이 낫다고 생각된다.
역시 사람은 강제성이 생겨야 뭔가 하는것 같다.
결론
내 선택에 대한 책임을 성인이 되고 난 후에 올해만큼 져본적이 없는 것 같다.
개인적으로, 이직이란 행위 자체를 굉장히 피곤하고 귀찮은 일이라고 생각한다.
그 시간에 차라리 일에 더 집중하고 싶다.
그렇지만 환경을 바꾸지 않으면 해결되지 않는 것들이 있기 마련이다.
돌이켜보면 잘 선택한 이직이었던 것 같고, 지금은 이곳에서 열심히 일하며 커리어 성장을 이어가고 싶다.
'회고' 카테고리의 다른 글
| 백엔드 혼자 맡게 된 이야기 (0) | 2026.04.04 |
|---|---|
| 대체 가능한 개발자라는 걸 인정하기 (그리고 고치기) (0) | 2026.02.11 |
| 2024년 나는 무엇을 했는가 (1) | 2024.12.29 |
- Total
- Today
- Yesterday
- 백준
- cipher suite
- docker-compose update
- kafka쓰고싶어요
- Til
- django testcase
- endl을절대쓰지마
- 최대한 간략화하기
- 그리디
- Python
- BOJ
- 코딩테스트
- Remote
- 프로그래머스
- 회고
- PREFECT
- 우선순위큐
- 이것도모르면바보
- SSL
- 삽질
- 불필요한 값 무시하기
- SQL
- 스택
- 파이썬
- 위상정렬
- jwt
- requests
- Javascript
- 힙
- vscode
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |