
개발보다 중요한 것은 유지보수다
개발자 생활을 처음 시작했을 때는 새로운 기능을 만드는 것이 가장 중요한 일이라고 생각했습니다.
신규 화면을 만들고 새로운 기능을 구현하는 것이 개발자의 핵심 업무라고 믿었습니다.
하지만 여러 프로젝트를 경험하면서 생각이 달라졌습니다.
실제 운영 중인 시스템에서는 신규 개발보다 유지보수 업무가 훨씬 많았습니다.
특히 삼성전자 MES 프로젝트와 현재 수행 중인 PLM 운영 업무를 경험하면서 느낀 점은 장애를 빠르게 분석하고 원인을 찾는 능력이 개발자의 중요한 경쟁력이라는 것입니다.
실제로 운영 환경에서는 코드 작성보다 문제 분석에 더 많은 시간을 사용하는 경우가 많습니다.
장애가 발생하면 가장 먼저 로그를 확인한다
신입 개발자 시절에는 장애가 발생하면 바로 소스를 열어봤습니다.
하지만 경험이 쌓이면서 접근 방식이 바뀌었습니다.
현재는 다음 순서로 확인합니다.
사용자 증상 확인
↓
로그 확인
↓
Transaction 확인
↓
Dataset 확인
↓
소스 분석
생각보다 많은 문제들이 로그만 봐도 원인을 찾을 수 있습니다.
실제로 유지보수 업무의 상당수는 로그 분석만으로 해결 가능합니다.
화면보다 Transaction을 먼저 확인하자
사용자들은 보통
"조회가 안 돼요"
"저장이 안 돼요"
라고 이야기합니다.
하지만 실제 원인은 화면보다 서버 통신에 있는 경우가 많습니다.
대표적으로
- Controller 오류
- Service 오류
- SQL 오류
- Dataset 매핑 오류
등이 있습니다.
그래서 저는 문제가 발생하면 항상 Transaction 로그부터 확인합니다.
실제로 이 방법으로 장애 분석 시간을 많이 줄일 수 있었습니다.
Dataset 상태를 확인하는 습관
넥사크로 유지보수에서 가장 많이 사용하는 기능 중 하나입니다.
예를 들어
조회 결과가 보이지 않는 경우
저장이 되지 않는 경우
수정 내용이 반영되지 않는 경우
대부분 Dataset 상태를 확인하면 원인을 찾을 수 있습니다.
특히 RowType 문제는 운영 프로젝트에서 자주 발생합니다.
신규 데이터인지
수정 데이터인지
삭제 데이터인지
구분이 잘못되면 정상적인 저장이 이루어지지 않습니다.
SQL부터 의심하지 말자
신입 시절에는 문제가 발생하면 무조건 SQL을 의심했습니다.
하지만 운영 경험이 쌓이면서 오히려 SQL 문제보다 다른 원인이 더 많다는 것을 알게 되었습니다.
예를 들면
조회 조건 누락
Dataset 이름 불일치
Transaction 파라미터 오류
Grid 바인딩 오류
같은 문제가 훨씬 자주 발생합니다.
실제로 유지보수 업무에서는 SQL보다 설정 오류가 더 많이 발견되었습니다.
공통함수 변경은 신중해야 한다
운영 프로젝트에서 가장 위험한 작업 중 하나입니다.
공통함수 하나가 수십 개 화면에서 사용되는 경우가 많습니다.
처음에는 단순한 수정처럼 보일 수 있습니다.
하지만 테스트 없이 배포하면 예상하지 못한 화면까지 영향을 받을 수 있습니다.
제가 경험했던 프로젝트에서도 공통 Validation 함수 수정 후 여러 화면에서 오류가 발생한 적이 있었습니다.
그 이후로는 공통 영역 수정 시 영향도 분석을 먼저 수행하고 있습니다.
운영 데이터와 개발 데이터를 구분하자
유지보수 업무를 하다 보면 가장 조심해야 하는 부분입니다.
운영 서버
테스트 서버
개발 서버
를 명확하게 구분해야 합니다.
특히 운영 DB에 직접 접근하는 경우에는 더욱 주의가 필요합니다.
실제로 현업에서는 단순 조회라고 생각했던 작업이 운영 데이터에 영향을 줄 수 있습니다.
그래서 현재도 작업 전 서버 정보를 먼저 확인하는 습관을 유지하고 있습니다.
사용자 문의는 증상이 아닌 원인을 찾아야 한다
운영 업무를 하다 보면 다양한 문의가 들어옵니다.
"조회가 안 돼요"
"저장이 안 돼요"
"화면이 이상해요"
하지만 이런 문의만으로는 원인을 알 수 없습니다.
그래서 항상 추가 정보를 요청합니다.
- 언제 발생했는지
- 어떤 데이터를 조회했는지
- 특정 사용자만 발생하는지
- 전체 사용자에게 발생하는지
이런 정보가 있어야 정확한 분석이 가능합니다.
유지보수는 개발 실력을 빠르게 성장시킨다
많은 개발자들이 유지보수 업무를 선호하지 않습니다.
저 역시 신입 시절에는 신규 개발을 더 하고 싶었습니다.
하지만 지금 돌아보면 유지보수 경험이 개발 실력을 가장 많이 성장시켰다고 생각합니다.
왜냐하면
기존 코드 분석
장애 원인 파악
데이터 흐름 이해
업무 프로세스 이해
를 모두 경험할 수 있기 때문입니다.
실제로 운영 경험이 쌓일수록 시스템 전체를 보는 시야가 넓어졌습니다.
제가 유지보수 시 항상 확인하는 체크리스트
장애 분석 시 현재도 사용하는 순서입니다.
1. 로그 확인
2. Transaction 확인
3. Dataset 상태 확인
4. SQL 확인
5. Grid 바인딩 확인
6. 공통함수 영향도 확인
7. 서버 환경 확인
이 순서만 지켜도 대부분의 문제를 빠르게 찾을 수 있습니다.
마무리
넥사크로 유지보수는 단순히 버그를 수정하는 작업이 아닙니다.
시스템 구조를 이해하고 데이터 흐름을 분석하며 사용자 문제를 해결하는 과정입니다.
저 역시 여러 MES 프로젝트와 PLM 운영 업무를 경험하면서 신규 개발보다 유지보수를 통해 더 많은 것을 배웠습니다.
만약 넥사크로 개발자로 성장하고 싶다면 유지보수 업무를 단순한 수정 작업으로 생각하지 말고 시스템을 이해할 수 있는 좋은 기회로 바라보길 추천합니다. 시간이 지날수록 그 경험의 가치를 크게 느끼게 될 것입니다.
'개발기초' 카테고리의 다른 글
| 개발기초 KOSA 2편 기업결제요청이란? 퇴사 후에도 가능할까? (0) | 2026.06.16 |
|---|---|
| 개발기초 KOSA 1편 경력등록 방법 총정리 (2026 최신판) (0) | 2026.06.15 |
| 개발기초 넥사크로 9편 (넥사크로 개발 환경 구축, 처음 프로젝트를 시작하기 전에 알아야 할 것들) (0) | 2026.06.11 |
| 개발기초 넥사크로 8편 (넥사크로 프로젝트 구조 이해, 실무 프로젝트는 어떻게 구성될까) (0) | 2026.06.10 |
| 개발기초 넥사크로 7편 (넥사크로 공통함수 설계 방법, 유지보수와 생산성을 동시에 높이는 개발 습관) (0) | 2026.06.09 |