첫 GS 인증을 하고 난 후기..

시작

SW 개발병으로 시작했던 군 생활을 마치고 나서, 작년 이맘때쯤 지금 다니는 회사에 신입 개발자로 입사하였다.

 

초반 6개월 정도는 회사의 메인 솔루션에 연관된 세팅 프로그램을 만드는 업무를 맡았었다.

 

이후 올해의 시작을 맞이하며 나에게 새로운 업무가 할당되었다.

 

GS 인증을 받을 소프트웨어를 만들라는 것.

 

처음으로 가시적인 결과를 낼 수 있는 기회라 생각되는 동시에,

몇 백만원 가량의 시험비를 듣고 나선 갑자기 어깨가 무거워지는 걸 느낄 수 있었다. 

 

게다가 GS인증을 진행하는 기관인 TTA에서 최근 규정을 바꾼 것도 부담으로 다가왔다.

 

기존에는 GS인증 기간 중 프로그램의 하자가 있을 경우 여러 번 패치 버전을 보낼 수 있었지만,

바뀐 방식으로는 그 패치의 횟수가 단 1회로 제한되어버린 것이었다.

 

GS 인증 신청을 하고 난 후 최소 3개월은 있어야 심사에 들어가는데 만일 이 심사 과정에서 한 번의 패치로 통과되지 않을 경우 다시 인증 신청을 해야 한다.

 

다시 신청할 경우 비용도 다시 지불해야하고, 무엇보다 최소 3개월의 시간을 다시 기다려야 한다.

 

시간이 생명인 비즈니스 세계에서 3개월은 한 분기가 날아가는 것이라 가볍게 볼 문제가 아니었다.

 

이런저런 부담과 설렘을 동시에 느끼며 시작한 프로젝트..

 

품질팀과의 첫 회의를 시작으로 컨셉을 잡고,

3개월가량의 프로그램 개발 과정을 거쳐 첫 프로토 타입을 만들었다.

 

심사 시작 한 달 전이었다.

 

 

피드백

품질팀으로부터 받은 첫 피드백은 "프로그램답게 만들어 주세요" 였다..

 

아..? 프로그램답게..?

 

예쁘게 만들어 달라는 요청이었다.

 

프로젝트를 시작할 때 UI보다 기능 위주로 기획했었기에 UI에 거의 신경을 안 썼던 것이 사실이었다.

 

GS 인증 심사가 시작되기 전까지 프로그램을 만들어야 했고, 다 같이 모여 회의한 자리에서

영업부장님이 직접 말씀하셨던 내용 또한 "UI는 신경 쓰지 말고 기능 구현에 초점을 두라"였기 때문이다.

 

그래서 개발하는 내내 기능 구현에 집중하고, UI는 기능의 결과를 표현할 정도로만 디자인하였다.

 

UI Component들에게 Texture를 입히지도 않았고, 표의 테두리를 신경 쓰지도 않았다.

 

흠.. UI를 애초에 배제하고 개발해왔지만, 품질팀으로부터 이런 피드백을 받고 나니 조금은 UI에도 신경을 써야 하나 라는 생각이 들었다.

(물론 피드백을 받는 순간엔 "원래 프로젝트 시작할 때 UI보다 기능 위주로 가기로 했었잖아요"라고 말했으나...)

 

마침 얼마 후 회사 내부 시연도 진행될 예정이었기에, 이참에 UI를 개선하기로 하였다.

 

UI Component들에게 아름다운 옷도 입히고, background에 아름다운 잔디들을 심었다.

 

이렇게 UI 작업을 진행하고 있을 무렵, 품질팀으로부터 정식으로 1차 피드백 내용을 전달받았다.

 

피드백 내용 중엔 내가 소홀히 했던 많은 요소들이 적나라하게 드러나있었다.

 

가장 와 닿았던 부분은 가이드 팝업의 부재였다. 

 

보통 프로그램의 버튼을 클릭하면 팝업 창으로든, 말풍선으로든, 애니메이션 효과로든 클릭의 결과를 사용자가 알 수 있게 해주는데 나는 그 기능들을 넣지 않았던 것이었다.

 

매번 회사 내부용 프로그램, 특정 사람들만 사용하는 프로그램을 만들다 보니

범용적인 사용성에 대해 별다른 고민을 하지 않았던 것이었다.

 

사실 가이드 팝업의 경우, 프로그램을 사용하는 사람이 적다 할지라도 개발자로서 당연히 넣어주어야 할 양심(?)이었다.

 

이 외에도 창을 resizing 할 때 UI가 깨져서 보인다든지,

통계를 보여줄 때 사용자가 쉽게 의미를 파악할 수 있어야 한다든지 등의 내용들도

내가 소홀하게 여겼던 부분이었다.

 

위의 내용들을 수정한 후 다시 품질팀에 프로그램을 보낸 지 며칠 뒤, 2차 피드백 내용을 전달받았다.

 

2차 피드백 내용을 읽던 중 쇼킹한 사실을 알게 되었다.

 

내가 구현한 프로그램의 핵심 기능 중 하나가 원래 기획한 의도와 다른 식으로 구현이 된 것이었다.

 

아니, 정확히 말하자면 핵심 기능 A에 대한 개발팀과 품질팀 간의 이해가 달랐었다.

 

나와 함께 이 프로젝트를 진행하신 개발팀 위원님은 나와 동일하게 이해를 하고 계셨고,

품질팀의 두 분은 나와 위원님과는 다르게 아예 다른 내용으로 이해를 하고 계셨다.

 

프로젝트 초기에 3 ~ 4 시간의 토의 끝에 결정한 기능이었기에 내가 이해한 내용에 대해 추호의 의심도 없었다.

 

그리고 이 기능은 1차 피드백 때도 계속 보여주었던 내용이었다.

 

하지만 그 오랜 시간을 토의했음에도 이렇게 이해가 다를 수 있다니, 커뮤니케이션 오류를 인정하면서도 어딘가 씁쓸한 마음은 가시질 않았다.

 

중형급 수술을 거쳐 핵심 기능은 품질팀이 요구하는대로 바꾸었지만,

이와 같은 상황이 언제든 다시 발생할 수 있겠다는 생각이 들었다.

 

그래서 타 팀과의 협업, 혹은 같은 팀 내에서라도 여러 사람이 작업을 할 경우,

최대한 프로토타입을 빨리 만들고 빨리 검증받는 것밖에 방법이 없다는 생각이 들었다.

 

애초에 커뮤니케이션을 잘하면 되지 않느냐 생각될 수 있지만,

이번 사안의 경우는 커뮤니케이션이 잘 되었다고 생각되었던 맥락에서 발생한 일이었다.

 

토의가 잘 끝났으면 이 내용을 최대한 빨리 구현시켜서 확증을 받는 게 중요하겠다는 생각이 들었다.

 

그래서 개발을 하는 나의 스타일도 어느 정도 바꿔가는 중이다.

 

기존엔 어느 정도 완성하고 기능들이 다 동작하는 상태로 다른 사람에게 프로그램을 넘겨주었지만,

앞으로는 중간중간 협업하는 사람들에게 검증을 받아보는 방식으로 개발해야겠다.

 

 

GS 인증

우여곡절 끝에 2차 피드백, 3차 피드백을 거쳐 GS 인증 심사가 시작되었다.

 

GS 인증 심사 내내 버그리포트만 기다리고 있었다. 인증 시작 후 며칠 뒤, 마침내 버그 리포트가 나왔고,

나는 주말 출근을 하여 최대한 빨리 이슈들을 해결하였다.

 

덕분에 월요일 업무가 시작하는 시점에서 품질팀에게 새 프로그램을 넘길 수 있었다.

 

이렇게 만들어진 패치 버전은 GS 인증 기간 중 마지막 이틀 동안 테스트가 이루어졌다.

 

첫날은 기존에 나온 버그 이슈들이 제대로 수정되었는지에 대해 테스트하였고,

마지막 날은 프로그램의 리소스 사용량 등을 측정하였다.

 

대개 첫 날 이슈 테스트가 잘 통과되고, 마지막 날 프로그램이 죽는 등의 큰 사건이 펼쳐지지 않는 이상

실무자 검토는 무사히 패스하는 것 같다.

 

현재 나의 프로젝트 또한 실무자 검토까지는 끝난 상태이고, 마지막 최종 검토자의 승인만 남은 상황이다.

 

이번 달 중순에 최종 발표가 난다고 하는데, 여기까지 와서 설마 떨어지진 않겠지...

 

p.s 2020.6.19) GS 심사는 4월 말에 무사히 최종 통과되었다...!!

 

생각한 점 요약

이번 GS 인증을 준비하면서 생각한 점들을 간략히 정리해보면,

 

1. 프로그램을 만들 때 최소한의 개발자 양심(?)을 갖고 개발하자.

가이드 팝업, 데이터의 효과적인 표현, window resizing, 사용자가 이것저것 눌러볼 때에 대한 대처, setting file 등이 없을 때의 에러 처리, 사용자가 이상한 값을 input으로 넣었을 때에 대한 대처, text 등을 너무 길게 입력했을 때에 대한 대처 등등..

 

2. 협업하는 상대방에게 프로그램을 A부터 Z까지 다 만들고 나서 보여줄 것이 아니라, C 나 E일 때부터 차근차근 보여주면서 프로그램을 만들어 나가자. 나와 상대방의 생각은 언제든 다를 수 있다.