[회고] LD 프로젝트 회고

 

LD HR 시스템 구축 회고

 

어제부로 10개월간 진행했던 LD HR 시스템 구축 프로젝트가 끝났다. 철수까지 마무리하고, 오늘은 프로젝트 종료 다음 날. 당연히 조금은 널널할 줄 알았는데도 생활 패턴은 여느 때와 다름없다. 아침 일찍 일어나 운동하고, 출근해서 업무 시작 전까지 책을 읽고 개인적인 일들을 정리한다. 단지 이제 출근지가 회사가 아닌 도서관이라는 점만 다를 뿐.

 

도서관은 평일이라 그런지 한가하다. 주말엔 오픈 전에 줄을 설 정도로 북적이는데, 지금은 조용해서 좋다. 이렇게 여유 있는 분위기에서 지난 프로젝트를 한번 되짚어 본다.

 

GPT가 그려준 프로젝트 회의 모습

인터뷰: 요구사항 검토, 다시는 대충 넘기지 않기

 

이번 프로젝트 초반에 가장 아쉬웠던 부분이 바로 요구사항 인터뷰다. 사실 고객과 함께 요구사항 정의서를 한 항목씩 검토했어야 했다. 하지만 내가 미팅에 들어가기 직전에 다른 업무의 인터뷰에서 문제가 생겨, 약간 흐트러진 상태로 들어갔다. 고객은 이미 모든 요구사항이 문서에 정리됐는데 왜 또 검토하냐며 불편한 반응을 보였고, 내 순서에서는 아예 전체 내용을 검토하지 말라는 조언(?)도 받았다. 나도 그 분위기에 휩쓸려 중요한 검토를 대충 넘기고 말았다.

 

결과적으로 이게 큰 실수였다. 문서에 있다고 해도, 왜 이 항목이 필요한지, 어떤 상황에서 작성됐는지를 파악했어야 했다. 고객의 눈치를 보지 않고, 요구사항 항목 하나하나를 꼼꼼하게 짚고 넘어갔어야 했다는 걸 이번에 절실히 느꼈다. 다음 프로젝트에서는 무조건 전체 항목을 자세히 확인하고, 누가 뭐래도 핵심을 짚고 넘어갈 거다.

 

---

 

설계: 피그마 vs PPT, 중간은 없을까?

 

이번엔 피그마와 PPT를 병행해서 설계를 진행했다. 피그마는 작업과 정보 공유에는 탁월하지만, 고객사 내부에서는 보안 정책 때문에 접속이 불가능했다. 결국 내부에선 피그마로 작업하고, 고객용 산출물은 다시 PPT로 제작하는 이중작업을 해야 했다.

 

피그마는 협업에 좋지만, 업무 화면 단위로 히스토리 관리나 세세한 내용 공유에는 약간 한계가 있고, PPT는 표현력과 버전 관리 모두 부족하다. 이번엔 문서관리툴도 없어 파일명에 날짜와 버전을 붙여가며 관리했는데, 제대로 정리되기 어려웠다.

 

피그마와 PPT의 장점을 섞은 툴이 있다면 정말 좋을 텐데… 아니면 피그마를 좀 더 업무화면 중심으로 트리 구조로 관리할 수 있는 방식이 필요하겠다. 여전히 산출물은 PPT라는 현실이 답답하긴 하다.

(아직 내가 피그마를 능숙하게 다루지 못해 그럴 수도 있다.)

 

화면 설계 시에는 As-Is 화면을 직접 볼 수 없었고, 오직 전달받은 캡쳐 화면에 의존하여 기존 업무를 분석해야 했다.

다음 프로젝트는 고객 담당자의 자리에 찾아가서 하는 한이 있더라도, 직접 필요한 화면을 실행해 봐야 겠다.

---

 

개발: 다행히 잘 맞는 개발자와의 협업

 

개발자 분은 내성적인 성격이었지만, 맡은 일은 꼼꼼하게 잘 처리해줬다. 말수가 적어서 커뮤니케이션에 조금 신경을 써야 했지만, 그 외엔 큰 문제 없이 잘 흘러갔다. 이런 개발자와 일할 수 있었다는 건 행운이었다.

 

---

 

데이터 이관: 화면 없이 캡처로만?

 

데이터 이관 작업은 정말 고생했다. 데이터는 엑셀로만 받을 수 있었다. 분명 더 많은 기능과 데이터가 있었을 텐데, 확인이 어려웠다.

 

실제로 업무가 어떻게 처리되는지 알 수 없고, 데이터 흐름도 제대로 파악이 안 되는 상태에서 이관을 진행해야 했기 때문에, 한 번에 끝내는 건 불가능했다. 수차례에 걸쳐 데이터를 확인하고 다시 이관하는 작업을 반복해야 했다.

 

다음 프로젝트에서는 어떻게든 업무 담당자 자리에 직접 찾아가서 눈으로 확인하고 작업해야겠다. 시간이 더 들더라도 결과는 훨씬 안정적일 거다.

 

---

 

안정화 및 인수인계: 구글 시트의 재발견

 

테스트 단계부터는 오류나 개선 요청 사항을 구글 시트에 정리해서 개발자와 공유했다. 발생한 문제, 요청자, 발생 시점, 처리 예정일, 상태 등을 꼼꼼히 기록했고, 다행히 개발자가 잘 따라와 줬다. 나중엔 개발자가 나보다 더 꼼꼼하게 시트를 관리해줘서 감동이었다.

 

---

 

기타: 기억해 둘 교훈들

1. 고객과 가까이 있어야 한다
2. 가능하면 같은 건물, 최소한 가까운 층이라도. 자주 만나고 대화하는 것만큼 중요한 게 없다.
3. 과도한 보안 정책은 프로젝트를 지연시킬 뿐이다. 시작 전에 타협점을 꼭 찾아야 한다.
4. 커뮤니케이션은 ‘만남 → 전화 → 메일’ 순
5. 얼굴 보고 말하는 게 제일 좋고, 안 되면 전화라도 해야 한다. 메신저나 메일은 공식적인 기록을 남길 용도로만 사용하는 게 좋다. 구두로 나눈 이야기는 반드시 메일로 정리해두자. 나중에 증거가 되는 건 대부분 이메일이다.

 

---

 

마무리하며

 

프로젝트가 끝나면 늘 아쉬움이 남는다. 잘한 부분도 있었지만, 지금 돌아보면 “그때 왜 그렇게 했지?” 싶은 부분들도 많다. 그래도 이번 프로젝트를 통해 얻은 건 분명히 있다. 다음 프로젝트에서는 더 잘할 수 있겠다는 확신도 생긴다.

 

지금은 잠시 쉬는 시간. 하지만 이런 시간 속에서 다음을 준비하는 습관은 그대로 유지하려 한다. 이번 회고도 그런 준비의 일환이다. 이 글을 읽는 누군가에게도 작은 참고가 되길 바라며, 다음 프로젝트에선 더 나은 모습으로 회고를 쓸 수 있길 바란다.