2025 복기 (1년 4개월만에 쓰는 글)

마지막 게시글로부터 1년 4개월간의 기록

결국 서비스 기업으로 이직은 실패했지만 IT기업 중에서도 프로젝트를 다수 수행하는 회사에 경력으로 입사

12개월 동안 두 개의 프로젝트를 수행, 무사 마무리를 짓고 숨을 돌리고 있습니다.

 

그 12개월 안에서도

ADsP 자격증 시험을 도전했지만 60점 합격에 58점 을 받고

현타가 와서 더이상 아무런 시도를 하고 있지 않습니다.

 

차라리 그 시간에 SQL 공부를 더 할걸 그랬네요

두 프로젝트를 진행하면서 개인적인 개선점을 뽑아본다면

 

1. SQL 튜닝 작성

2. 테스트를 꼼꼼하게 하고 배포할것

 

이네요.

 

ETL 제품을 다룬다는 것은 단순히 데이터를 적재하는 작업을 의미하지 않습니다.
데이터가 어떻게 저장되고, 어떻게 가공되며, 어떤 방식으로 조회되는지까지 이해해야 비로소 하나의 완성된 흐름이 됩니다.

제품 사용법만 익히고 데이터 조회 성능을 고려하지 않는다면 그 사이에는 필연적으로 기술적인 공백이 생기게 됩니다.
이 공백은 곧 성능 문제, 확장성 문제, 그리고 서비스 품질 저하로 이어집니다.

 

SQL 튜닝은 그 공백을 메우는 핵심 역량이며 이를 이해하지 못한 채 ETL을 다룬다면 데이터와 서비스를 충분히 활용하지 못하는 불완전한 실력이라고 해도 과언이 아닙니다.

 

이번에 정말 뼈저리게 느꼈네요.

쿼리가 1초이상 걸린다는 것이 서비스에 전체적인 영향을 줄 수 있다는 것

 

그리고 운영환경에 접근이 쉽지 않은 곳에서 작업을 하는 경우가 생기는데 개발서버에선 테스트 데이터 부족, 환경 이슈 등으로 테스트가 불가능한 기능일지라도 최대한 꼼꼼하게 살펴보고 진행하는 것이 중요하다는 것을 알았습니다.

 

원래도 개발을 좀 산만하게 하고 (여기갔다가 저기갔다가 이거하다가 저거하러감 ;;) 시야가 좁은편이라 이 점에 대해서는 예전부터 인지하고 있었지만 매번 다짐을 합니다

 

^^

 

이것은 번외입니다만

AI가 판을 치는 이 업계에서 경력이 쌓이면 쌓일수록 드는 생각은

개발자가 단순히 개발을 하는 사람이 아니고 비즈니스 로직을 이해하는 사람이라는 것입니다.

 

이건 사실 0년차때부터 정말 뼈저리게 느끼고 있습니다.

정말 생각이라는걸 안하고 말한 것만 구현하는건가 싶은 상황이 항상 있었는데

비즈니스 로직을 이해하지 못한 개발은 결국 코드만 남고 서비스는 남지 않습니다.

프로젝트의 완성도를 결정짓는 것은 소스 코드의 양이 아니라 비즈니스에 대한 이해의 깊이입니다.

 

결국 개발은 누구나 할수 있는 부분이고 대체 불가능한 인력이 되려면

설계를 이해하며 개발하는 사람이 되는 것이라고 생각합니다. 

 

말이 통하는 동료가 같이 일하는 동료로서 최고의 동료!

라는 생각이 드는 4년차따리입니다. ㅎㅎ