5년차 개발자로서의 회고: 실수에서 배우고 성장하는 개발자의 경험 공유
2025년이 되면서, 나는 벌써 5년차 개발자가 되었다. 시간이 빠르게 지나면서 많은 경험을 쌓았다. 초기에는 부족함이 많았지만, 이제는 조금 더 여유를 가지고 문제를 바라볼 수 있는 능력이 생겼다. 물론, 그동안 배우고 경험한 것들을 한 번에 다 흡수할 수 없었고, 계속해서 나아가야 할 길이 많다는 것을 깨닫게 되었다. 5년차라는 작은 경력에 안주하지 않고, 앞으로도 자만하지 않고 더 열심히, 더 넓은 시각으로 배우고 성장할 수 있도록 노력할 것이다. 이번 회고를 통해 그동안의 개발 경험을 되돌아보며, 그 과정에서 얻은 교훈들을 공유하고자 한다.
1. 소스 누락
개발자는 로컬 환경에서 작업한 소스를 다른 환경에 배포할 때, 종종 소스 파일이 누락되는 실수를 할 수 있다. 특히 개발, 테스트, 운영 환경이 분리된 경우, 이를 관리하는 과정에서 실수가 발생할 수 있다. IDE에서 작업한 파일을 올바른 환경으로 전송하는 과정에서 누락된 소스가 있다면, 시스템에서 예기치 않은 오류가 발생할 수 있다. 소스 누락을 방지하려면, 각 소스 파일을 별도로 리스트화하고, 배포 전에 모든 파일을 다시 한 번 확인하는 것이 중요하다. 또한, 배포 전에 개발 환경에서 충분히 테스트를 진행하여 문제가 발생할 확률을 최소화하는 것이 필요하다. 이러한 과정을 통해 실수를 줄이고 안정적인 배포가 가능해진다.
2. 전체 머지의 위험성
개발팀에서 여러 명이 한 소스 파일을 수정하는 경우, 전체 머지를 진행할 때 위험이 따를 수 있다. 만약 내가 수정한 부분 외에도 다른 사람이 수정한 부분이 있다면, 머지를 진행하면서 의도치 않게 다른 사람의 코드가 누락될 수 있다. 또, 수정된 코드가 내가 작성한 코드와 충돌을 일으킬 수도 있다. 예를 들어, 이전 작업자의 변경사항이나 수정 이유를 모른 채 머지 작업을 하면, 시스템 동작에 영향을 줄 수 있는 코드가 함께 배포될 수 있다. 이런 위험을 최소화하려면, 소스 파일을 머지할 때 다른 팀원의 작업을 미리 확인하고, 내가 작업한 부분만을 선택적으로 머지한 뒤 충분한 테스트를 해야 한다. 머지 작업은 항상 운영 환경의 최신 소스 파일을 기준으로 해야 한다.
3. 환경 설정 파일 관리
배포를 진행할 때, 각 환경에 맞는 설정 파일을 사용하는 것이 매우 중요하다. 개발, 테스트, 운영 환경은 각각 다른 설정을 요구하는데, 특히 DB 설정이나 외부 API 주소 등 중요한 환경 변수를 실수로 잘못 적용할 경우 큰 문제가 발생할 수 있다. 예를 들어, 개발 환경의 DB 설정을 운영 환경에 그대로 배포하면, 운영 시스템에서 정상적으로 작동하지 않거나 시스템 장애를 초래할 수 있다. 따라서, 각 환경별로 별도의 설정 파일을 관리하고 배포 전에는 반드시 해당 파일들이 올바른 환경에 맞게 설정되었는지 다시 한 번 점검해야 한다. 이를 통해 배포 후 예상치 못한 오류를 방지할 수 있다.
4. 컨테이너 재기동 전후 로그 모니터링
컨테이너 환경에서 개발할 때, 컨테이너의 재기동 과정에서 장애가 발생할 수 있다. 컨테이너가 정상적으로 동작할 때는 문제가 없지만, 재기동 후 새로운 문제가 발생할 수 있으므로, 재기동 전후로 로그를 실시간으로 모니터링하는 습관을 들이는 것이 중요하다. 대부분의 개발자는 귀찮아서 로그 파일을 나중에 찾아보려고 할 수 있지만, 로그를 미리 모니터링하면 장애 발생 시 빠르게 대응할 수 있다. 실시간 로그 모니터링은 시스템 장애를 조기에 발견하고 문제를 해결하는 데 매우 중요한 도구가 될 수 있다. 따라서, 컨테이너 재기동 후에는 반드시 로그 창을 띄워놓고 실시간으로 모니터링해야 한다.
5. SQL 쿼리 수정 시 리뷰 요청
SQL 쿼리는 시스템의 성능과 직결되는 중요한 부분이므로, 쿼리 수정 시에는 주의 깊게 접근해야 한다. 특히 WHERE 조건을 수정할 경우, 기존 쿼리의 성능이 크게 달라질 수 있다. 잘못 수정된 쿼리는 성능이 떨어지고, 심지어 DB에 부하를 주어 시스템 장애로 이어질 수 있다. 그렇기 때문에, 쿼리를 수정한 후에는 반드시 다른 개발자나 DBA에게 리뷰를 요청하는 것이 좋다. 만약 DBA가 없다면, 쿼리 최적화에 능숙한 동료 개발자에게 도움을 받는 것도 좋은 방법이다. 이렇게 리뷰를 받은 후, 성능 문제나 잠재적 오류를 미리 예방할 수 있다.
6. 리소스 내역 관리 문서 작성
개발한 소스를 문서화하는 것은 장기적인 유지보수와 협업을 위해 매우 중요한 일이다. 개발 과정에서 내가 수정한 내용을 정확히 기록해두면, 시간이 지나서 내가 다시 그 부분을 수정할 때 유용하게 활용할 수 있다. 또한, 동료 개발자가 내 소스를 수정해야 할 때, 수정 이유나 로직을 정확히 이해할 수 있도록 돕는다. 문서화는 커밋 메시지나 주석과 함께 사용하여, 이후 유지보수 작업이 필요할 때 유용한 정보가 될 수 있다. 개발을 하면서 문서 작성이 귀찮을 수 있지만, 이 작은 습관이 장기적으로 많은 시간을 절약할 수 있다.
7. 문서, 로그, 자료 기반의 대화 습관
개발자는 소통 능력을 중요하게 여겨야 한다. 내향적인 성향을 가진 개발자일수록 소통을 피할 수 있지만, 코드만으로 모든 것을 해결할 수는 없다. 특히, 중요한 결정을 내리거나 문제를 해결할 때는 구체적인 근거가 필요하다. 이때, 문서, 로그, 자료는 내가 주장하는 내용에 신뢰를 부여하는 중요한 역할을 한다. 예를 들어, 시스템에 발생한 오류를 설명할 때, 로그 파일을 보여주면 문제의 원인을 빠르게 파악할 수 있다. 이러한 자료들이 있으면, 동료들과의 소통에서 신뢰를 얻을 수 있으며, 문제 해결 속도도 빨라진다.
8. 이슈&해결 문서 작성
개발자는 다양한 문제에 직면하게 된다. 문제를 해결할 때마다 그 과정을 문서화하는 것이 좋다. 이슈&해결 문서를 작성하면, 동일한 문제에 다시 직면했을 때 빠르게 해결 방법을 찾을 수 있다. 또한, 개발팀 내에서 정보를 공유할 수 있어, 다른 팀원이 같은 문제를 겪을 때 큰 도움이 된다. 이슈와 해결 방법을 기록해두면, 개발자의 경험이 축적되어 점점 더 효율적인 문제 해결을 할 수 있게 된다. 이는 팀의 전반적인 생산성을 높이는 데 기여할 수 있다.
9. 계정 관리
개발 환경과 운영 환경에서 사용되는 계정은 매우 중요하다. 각 환경에서 테스트 계정, 관리자 계정 등을 관리하는 것이 중요하며, 이를 적절하게 관리하지 않으면 보안에 큰 위협이 될 수 있다. 계정의 접근 권한을 명확히 하고, 불필요한 계정은 삭제하거나 잠가두는 등의 관리 작업이 필요하다. 또한, 환경별로 계정 정보를 정리해 두고, 이를 주기적으로 점검하여 보안을 강화해야 한다. 이처럼 계정 관리는 보안뿐만 아니라 시스템의 안정성에도 중요한 영향을 미친다.
참고 링크
[WAS] 제우스(JEUS) 정리 – 설치 실행, 에러, 명령어
리눅스 서버가 이상할 때, 로그 보는 곳 – 쿠카의 개발일지
