미리보기

기술적 깊이를 더하고, 팀과 함께 성장하는 개발자

저는 단순히 코드를 작성하는 개발자가 아니라, 기술을 깊이 이해하고 체계적으로 접근하는 개발자가 되기 위해 노력하고 있습니다.

트러블슈팅 과정에서 웹서핑을 하다 보면 "이 값을 변경하니 문제가 해결되었다" 같은 글을 자주 접할 수 있습니다. 빠른 문제 해결에는 도움이 될 수 있지만, 저는 이런 방식보다는 근본적인 원인을 분석하고 해결하는 접근법을 지향합니다. 특히, 여러 시스템이 연계된 환경에서는 특정 시스템의 병목이나 Failover가 다른 시스템에도 영향을 줄 수 있기 때문에, 문제의 원인을 명확히 파악하는 것이 중요합니다.

가장 인상 깊었던 경험은 슬로우 쿼리 개선 업무였습니다. 문제의 원인은 SELECT 쿼리에서 각 ROW의 상태 값을 계산하기 위해 서브쿼리를 반복 호출하는 것이었습니다. 이를 EXPLAIN ANALYZE를 활용해 성능 병목을 파악하고, JOIN을 사용해 서브쿼리를 제거하는 방식으로 최적화하여 성능을 크게 개선했습니다.

하지만 여기서 문제 해결에 그치지 않고, 추가적으로 UPDATE가 잦은 테이블에서 발생하는 Dead Tuple과 AutoVacuum의 영향을 학습하며 데이터베이스 내부 동작 원리를 더 깊이 이해할 수 있었습니다. 이러한 인사이트를 팀원들과 공유하면서, 단순한 최적화가 아닌 DB 운영의 안정성과 장기적인 성능 개선까지 고려하는 팀 문화를 만드는 데 기여했습니다.

저는 앞으로도 단순한 문제 해결을 넘어, 기술을 깊이 이해하고 팀과 함께 성장하는 개발자가 되고자 합니다.

문제의 본질을 파악하고 최적의 솔루션을 찾는 개발자

신규 개발 및 운영 업무를 진행하다 보면 다양한 업데이트 요청을 접하게 됩니다. 하지만 그중 일부는 추가적인 개발 없이도 해결할 수 있는 경우가 있습니다.

개발자가 도메인 지식이 부족할 수 있듯이, 기획자나 PM 또한 시스템 구현의 세부 사항을 완벽히 이해하지 못할 수 있습니다. 이러한 간극을 메우는 것 또한 개발자의 역할이며, 원활한 소통이 중요한 이유입니다.

예를 들어, 게시글과 카테고리 관련 개발을 진행하던 중, 기획자로부터 "카테고리 없음"이라는 별도의 카테고리를 추가해 달라는 요청을 받았습니다. 하지만 시스템 구조를 고려했을 때, 이는 불필요한 작업으로 보였습니다. 요청의 의도를 명확히 하기 위해 기획자에게 해당 카테고리의 용도를 물었고, "사용자에게 보이지 않지만 데이터를 남기기 위한 목적"이라는 답변을 들었습니다.

이미 게시글, 카테고리, 매핑 테이블의 구조를 고려하고 있던 저는 해당 요구 사항을 별도의 카테고리 없이도 충족할 수 있음을 설명했고, 불필요한 개발을 줄이며 최적의 방식으로 구현할 수 있었습니다.

이처럼 개발자가 기획서만 보고 개발을 진행한다면, 문제 해결보다 구현 자체에 집중하게 되는 위험이 있습니다. 저는 단순히 주어진 기능을 만드는 것이 아니라, 기획의 본질을 이해하고 최적의 솔루션을 찾아가는 개발자가 되고자 합니다.