프로젝트가 끝나면 남는 것
SI(System Integration) 사업을 수행하다 보면 프로젝트가 끝난 후 “이제 끝났다!”는 안도감과 함께 “다음에는 더 잘하자”는 막연한 생각이 떠오를 때가 많습니다. 하지만 그 생각만으로는 부족합니다. SI 프로젝트의 특성상 복잡한 시스템 구축, 다양한 이해관계자 관리, 그리고 기한 내 완료라는 과제가 얽혀 있어 예상치 못한 문제와 실패가 발생할 수밖에 없기 때문이죠.
여기서 중요한 것이 바로 Lesson Learned (교훈 도출)입니다. 프로젝트 수행 중에 경험한 성공과 실패의 사례를 기록하고 분석하면 같은 실수를 반복하지 않고 더 나은 결과를 만들어낼 수 있습니다.
오늘은 SI 사업 수행에서 Lesson Learned가 왜 중요한지, 그리고 이를 효과적으로 실무에 적용하는 방법을 이야기해보겠습니다.
Lesson Learned의 중요성과 그 역할
A. Lesson Learned란 무엇인가?
Lesson Learned는 프로젝트 수행 중 경험한 실패와 성공 사례를 정리하고, 이를 통해 향후 유사 프로젝트에서 개선할 수 있는 교훈을 도출하는 과정입니다.
- 프로젝트를 수행하면서 무엇이 잘되었는지, 무엇이 문제였는지를 돌아보고,
- 해당 경험을 조직의 자산으로 남기는 것입니다.
결국, 개인과 팀의 경험을 체계화해 미래 프로젝트의 리스크를 줄이고 생산성을 높이는 것이 목표입니다.
B. SI 사업에서 Lesson Learned가 중요한 이유
- 반복되는 실수 방지
SI 프로젝트에서는 동일한 패턴의 실수가 반복되는 경우가 많습니다.- 예: 요구사항 명확화 부족 → 개발 후 추가 요청 발생 → 일정 지연예: 네트워크 아키텍처 설계 미흡 → 시스템 병목 현상 발생
- 프로젝트 리스크 관리
SI 사업은 다수의 시스템과 이해관계자가 얽혀 있어 리스크 발생 가능성이 높습니다.- 과거 프로젝트에서 발생했던 리스크를 문서화하면, 다음 프로젝트에서 선제적으로 대응할 수 있습니다.
- “고객사의 네트워크 환경이 복잡하여 사전 테스트가 필요했는데 이를 간과했다.”
→ 이후에는 사전 환경 분석을 철저히 진행하도록 체크리스트에 추가.
- 프로세스 개선과 효율성 증대
성공 사례는 팀의 강점으로, 실패 사례는 개선점으로 활용해 프로세스를 최적화할 수 있습니다.- 프로젝트 단계별로 불필요한 프로세스를 제거하고, 업무 효율성을 극대화할 수 있습니다.
- “기존에는 배포 시 수작업으로 설정 변경을 했지만, 자동화 툴을 도입해 배포 시간을 줄였다.”
- 조직의 지식 자산화
프로젝트 경험이 개인에 의존하면 해당 담당자가 퇴사했을 때 그 지식이 사라질 수 있습니다.- Lesson Learned를 통해 지식과 노하우를 문서화하면 조직 전체의 자산으로 남기게 됩니다.
- 특히 중소기업에서는 인력 변동이 잦아 이러한 문서화가 더욱 중요합니다.
C. 효과적인 Lesson Learned 도출과 적용 방법
- 프로젝트 회고(Review) 미팅 진행
- 프로젝트 완료 직후, 팀원과 이해관계자들이 함께 참여하는 회고 미팅을 진행합니다.
- 주요 질문:
- What went well? (잘된 점)
- What went wrong? (문제점)
- What can we improve next time? (개선할 점)
- 체계적인 문서화와 공유
- 회고를 통해 도출된 Lesson Learned를 체계적으로 정리해 문서화합니다.
- 문서를 사내 공유 플랫폼(예: 위키, 협업 툴)에 저장하고 전사적으로 공유합니다.
- 포맷 예시:
| 항목 | 내용 | 개선 방안 |
| 문제점 | 요구사항 불명확으로 인한 일정 지연 | 요구공학의 도입 |
| 성공사례 | 네트워크 아키텍처에서 지속 발생하는 혼잡 증상 해결 | QoS를 통한 네트워크 자원 활용성 증대 |
- 체크리스트와 표준 프로세스 개선
- 도출된 교훈을 반영해 프로젝트 실행 시 사용할 체크리스트와 표준 프로세스를 업데이트합니다.
- 예를 들어, 사전 환경 분석을 누락한 문제가 발생했다면:
→ 다음 프로젝트부터 “사전 네트워크 환경 분석 체크리스트”를 필수 단계로 추가
- 주기적인 리뷰와 적용 점검
- Lesson Learned는 단순히 기록만 해두면 의미가 없습니다.
- 이후 프로젝트에서 얼마나 적용되었는지 점검하고, 적용 결과를 다시 피드백하여 개선합니다.
경험이 곧 자산이다
SI 프로젝트는 언제나 새로운 도전입니다. 하지만 과거의 경험을 Lesson Learned로 체계화한다면, 우리는 실수를 반복하지 않고 더 나은 결과를 만들어낼 수 있습니다.
- 성공과 실패를 기록하라.
- 프로세스를 개선하라.
- 조직의 자산으로 만들어라.
“경험은 최고의 스승”이라는 말이 있듯이, 과거 프로젝트의 교훈은 미래 프로젝트의 성공을 위한 가장 강력한 무기가 될 것입니다.
여러분이 SI 사업을 수행하면서 Lesson Learned를 습관화하고, 이를 팀과 조직 전체의 성장으로 연결시키시길 바랍니다. 경험을 남기면 실패는 더 이상 실패가 아닙니다.
Tip: Lesson Learned가 무조건 형식을 준수하여 작성될 필요는 없습니다. 만약 개인의 참고를 위한 자료라면 알아보기 쉬운 형태로 신속하게 작성될 필요가 있겠죠? 아래는 제가 실제로 사업 지원을 수행하며 작성한 Lesson Learned의 일부 예시입니다.
- 필요한 UTP, 벨크로, 케이블타이, power cable 등 소요항목 먼저 조사하기 (몇 M? 중요)
- 랜선 연결 작업 시 처음부터 표시 제대로 하기 (추후 라벨링 작업에 많은 시간이 소요될 수도 있음)
- 포트 및 장비 연결에 대한 내용은 그때그때 기록하기 (포트맵, 랙실장도 등)
- 보안설정 변경 작업이 수행되는데, 관리자/모니터링용 계정, 기본 서비스 포트, 로그 설정 등을 변경해야함 (참고)
-> 계정 및 접속정보 관리대장을 일관성있게 관리하는 것이 중요- 분리발주 품목은 (예, SW) 설치 시 특정 환경에 대한 요구사항이 있음 (패키지 설치 여부, OS 버전 등등), 해당 내용 먼저 조사해서 준비하는 것 필요 (백업sw를 설치하려면 redhat os에는 이런 패키지들이 필수이고~, debian에는 이런게 있고~ 하는 것들임 dpkg, rpm 등으로 밀어넣음) -> 폐쇄망에서는 패키지 설치가 제한적임
- 메일서버는 메일용 SSL 인증서가 있음. 발급받을때 MAIL. 도메인으로 시작하도록 발급받는 것이 중요함