코드 관리

오늘도 미미하지만 중대한 실수를 저질렀다!!!!!!

오늘의 실수 주제는 '코드 관리' 이다.

내가 말하는 코드 관리는 SVN, Git과 같은 형상 관리 도구(버전 관리 시스템)에 관한 이야기가 아니다.

 

 

대학교 소프트웨어공학 수업에서 Waterfall 방식 대비 Agile 방법의 장점에 대해 많이 배웠다.

Agile의 가장 큰 장점은 유지보수 비용이 적게 든다는 점이었다.

Waterfall 방식은 요구사항 정의 → 분석 → 설계 → 개발 → 테스트 → 배포 → 유지보수 순으로 진행된다.

요구사항 정의부터 배포까지의 단계가 더 많지만 비용 자체는 유지보수가 압도적이다.

요건대로 개발했음에도 유지보수할 것은 끊임없이 생긴다.

 

그렇다면 Agile 방식을 선택하면 되잖아!!!

실무에서 Agile을 사용하는 기업은 그리 많지 않다.

큰 조직인 만큼 조직 구조가 수직적이고 각 단계별 실무 담당자, 책임자가 명확히 구분되어 있기에 Waterfall 방식을 선호하는 듯하다.

그러므로 우리는 유지보수의 늪에서 쉽게 빠져나올 수 없다!!!

 

 

이 게시글에서 하고 싶은 말은 유지보수할 일이 많다! 남이 짠 코드를 내가 수정해야하는 일이 많다! 그냥 일이 많다!

많은 일을 한꺼번에 처리하다보면 A 개발건을 처리하기 위해 건들인 코드 a-1, a-2, a-3과

B 개발건을 처리하기 위해 건들인 코드 b-1, b-2, b-3이 헷갈리기 시작한다....

바로 이 것이 오늘 내가 저지른 실수의 핵심이다!!

 

 

나는 평소에 특정 개발건을 처리하기 위해 건들인 코드들을 한번에 SVN에 Commit한다.

그리고 Commit message에 어떤 것들을 수정했는지 대강 작성했다.

추후에 형상 관리 시스템을 통해 운영에 코드를 최종 배포할 때 나는 Commit 이력과 Commit message를 보고 소스 코드를 선택하여 배포한다.

이 외에는 따로 각 개발건에 대해 어떤 코드들을 건드렸는지 기록하지 않았다.

 

 

오늘의 실수에 대해 먼저 간략히 설명하자면 다음과 같다.

나는 A 개발건을 처리하고 a-1, a-2를 우선 Commit 한 후 B 개발건을 처리하다가 A 개발건 Commit 시 a-3이 빠졌다는 것을 알게 되었다.

나는 그때 이미 b-1을 개발 완료한 상태여서 a-3과 b-1을 함께 Commit 해버렸다.

그리고 Commit message에는 장표 수정. 이 한마디를 기록했다.

 

A 개발건에 대한 테스트가 끝나고 형상 관리 시스템에서 최종 배포를 할 때 "어떤 코드를 수정했더라?" 라고 생각하며 Commit 이력을 봤다.

나는 a-1, a-2 | a-3, b-1 이렇게 두 개의 Commit을 보고는 "아! 첫번째 Commit이 A 개발건이고 두 번째 Commit이 B 개발건인가보다!" 라고 생각하며 a-1, a-2 만 골라 최종 배포했다....

 

 

배포가 완료되고 운영에 수정 사항이 정상적으로 반영되었는지 확인하던 중 a-3이 반영이 안 된 것을 발견했다!!

그래서 문제를 이 잡듯이 뒤진 결과...... 내가 배포할 소스 코드 하나(a-3)를 빼먹은 것을 알게 되었다.

b-1과 함께 Commit 하는 바람에 B 개발건에 관련된 소스 코드라고 생각한 것이다.

결국 a-3을 추가해서 배포하긴 했지만,,,,

이번 사건으로 수정한 소스 코드를 리스트로 관리하는 것이 얼마나 중요한 것인지 뼈저리게 느끼게 되었다.

 

 

 

 

---

 

방법은 뭐든 상관없다!

수기로 종이에 작성해도 좋고, 엑셀로 정리해도 좋다.

뭐든 어떤 개발건에 어떤 코드를 수정했는지 기록을 해두지 않는다면 나와 같은 대참사가 발생할 것이다.

 

나는 내일 출근하자마자 엑셀 파일을 하나 만들 예정이다.

엑셀 외에 더 좋은 방법이 있다면 함께 공유하면 좋을 것 같다!

지금까지 총 6개 정도의 개발 건을 수행했는데 그중 2개에서 지금과 같은 문제가 생겼었다.

수정한 소스 코드 리스트 관리 이후 오류가 얼마나 줄었는지는 이후 게시글로 공유하겠다!