이동규

개발 잘하고 싶다

기록으로 남기려는 이유…

올해 초, 내가 근무하는 부서의 실적이 좋지 못해 부서의 헤드와 절반 이상의 인원이 퇴사하거나 교체되었다. 그러한 칼바람은 처음이었고, 다행이라고 해야하나… 내 업무인 개발과는 크게 관련 없는 분야들이었다.

하지만, 유니티와 3년동안 공동 개발하여 서비스했던 codeAlive의 계약 만료가 올해 5월이었고, SOW 관리를 담당하고 있던 과장과 차장이 퇴사하는 바람에 내가 그 일을 떠맡게 되었다.

정확히 기억은 나지 않지만, 우리쪽에서 지금까지 제대로 관리하지 못한 SOW 항목들을 내가 인수받은 시점인 3월부터 5월까지 마무리 지어야 한다는 것은 정말 어처구니 없는 일이었다. 그리고 SOW 항목에는 까다로운 작업인 ‘클라우드 마이그레이션’ 건이 있었다.

결과는? 다행히 대부분 이행되었는데, 어떻게 이런 불가능한 일을 Clear 했는지를 짧게 나마 기록하고 싶었다.

개발 기간 및 기여

개발 기간:

  • 2023년, 3월 ~ 6월

기여:

  • 3년 치, SOW 항목의 이행 준수 검사
    • 테스트 계획 수립, 실행
  • Unity 납품항목의 인수 및 검수 확인
  • 유지보수(Unity 앱, 웹 프론트)
    • 개발문서 및 소스코드 분석, 관리

※ 다행인지, 불행인지 내가 Unity Editor로 프로젝트 경험이 많은 편이라, 웹 프론트 말고도 Unity 엔진으로 개발된 클라이언트 앱도 유지보수를 담당하게 되었다. 개발은 한 분야를 통달하는 것도 좋지만, 다른 분야를 두루 아는 것도 이렇게 인원이 적은 소규모 집단에서는 유리하게 작용하는 것 같다.

뻔한 비법 1. 절대 미루지 않고 문서로 소통하며, 있는 힘껏 협력한다.

Unity와의 3년 동안 SOW(Statement of Work) 계약이 체결되어 진행되는 동안, 지난 전임자들이 Unity 측에 의뢰한 개발문서(하다못해, 스토리보드)가 거의 없었다. 게다가 더 어려웠던 점은 이전의 스토리를 잘 알지 못하는 나였기에 SOW의 어느 항목이 어디까지 완료되었는지 전달받지도 못했다.

그러던 중, Untiy 수석 PM께서 신규개발한 기능에 대한 우리쪽 검수 부탁과 클라우드 마이그레이션 건에 대해 전달해주셨고, 필요한 내용들을 Slack의 대화들을 최대한 긁어 모아 깔끔히 정리, 전달해주셨다.

이러한 문서들을 나는 Notion에 항목별로 모아, 관리하여 Unity와 공유하였고 모든 기록을 위한 창구로 사용하였다.

먼저, 신규 개발한 기능에 대한 소규모 테스트 케이스 뿐만 아니라, 앞으로 남아있는 SOW 항목의 테스트 계획(Test Objectives, Test R&R, Test Schedules, Test Environment, Test Case)을 아래와 같이 작성하여 Unity와 공유하였고, Notion의 카드를 이용하여 실행 상태를 서로 확인하였다.

돌이켜보니 이러한 프로세스 덕분에 뒤에 있을 큰 과업들도 무사히 마무리할 수 있었던 것 같다. (다시 한번, Unity 수석 PM님과 사수이신 송차장님께 감사를 표하는 바이다 ( - - ) ( _ _ ))

image-20230821151707577

image-20230821152213940

image-20230821152619147

image-20230821152842604

image-20230821152956996

뻔한 비법 2. 실사용 테스트가 가장 좋은 검증법!

3~4월은 정말 바빴던 것 같다. 유니티에서는 클라우드 마이그레이션(Tencent → Azure-한국)으로 서비스 이전하느라 무척 빠듯했고, 우리쪽에서는 Azure-한국 설정에 필요한 자원 공급, 소규모 단위 테스트, 검증, 재요청을 수시로 진행했던 것 같다.

나의 사수가 “이 프로그램을 운영중인 오프라인 센터에서 Azure로 마이그레이션된 프로그램을 설치해보고 수업시간에 애들이 직접 사용해보게 해야한다.”로 방향을 설정해주셔서 센터를 섭외하였고, 유니티 수석 PM님과 5월 동안 1~3차 베타 테스트를 진행하여, 무사히 마이그레이션 업무를 끝낼 수 있었다.

결론적으로 실사용 테스트를 위한 ‘철저한 준비작업’, ‘발생할 리스크와 해소방법’이 클라우드 마이그레이션을 성공적으로 완수할 수 있던 가장 큰 원인이었던 것 같다.

무엇보다 토요일에도 불편한 기색없이 오프라인센터에 오셔서 4~5시간 동안 수업을 직관하며 함께 대처해주신 Unity 수석 PM님과의 추억이 뜻깊었다.

뻔한 비법 3. 인수 품목과 검수 확인 방법

5월 말에 이르러 우리쪽에서 유지보수 하기 위한, 소스코드와 개발문서 등을 전달받아야 할 마무리 단계가 남아있었다. 하지만, ‘인수 및 검수 확인서’를 작성해본 적 없는 개발자인지라… 도저히 감이 오지 않아, 이쪽으로 정통할 유니티 수석 PM께 어려운점을 요청했고, 정말 감사하게도 아래와 같이 납품 항목이 담겨있는 확인서 양식을 공유해주셨다.

image-20230821154712034

그리고, 이러한 납품 항목에 맞춰 우리쪽에서는 검수 확인을 해줘야 하기 때문에, Notion 페이지에 항목을 체크박스로 만들어, 검수가 완료되는대로 일자를 기록하여 체크, 항목마다 완료되는대로 유니티에 공유하였다.

image-20230821154851898

뻔한 비법 4. 뭐든 열심히 하면, 개발에 도움이 된다.

3년간 개발한 소스코드를 받아 검증하는 일은 정말 쉽지 않았다. 정확히 말하면, “잘되는 것 같은데?” 수준으로 검증해서는 유지보수를 할 수 없을 것이라 생각이 들었다.

그러던 중, 당연하게도 3년치 SOW에서 유니티에서 전부 개발하기에 자원적으로 부족한 이슈(클라이언트 앱-다크모드, 웹 클래스룸에서 클라이언트앱 등록 등)가 발생했고, 내가 갖고 있는 부족한 기술로 “유지보수를 위한 코드 검증입니다!”라는 이유로 대신 개발하여, 유니티와 매끄러운 관계를 가져갈 수 있었다.

게다가 웹 클래스룸에서 해당앱이 깔려있지 않으면, 다운로드하고 깔려있으면 실행하는 시나리오 부분의 개발이 필요해서 이 기능은 Angular로 작성된 코드를 뜯어보며 내가 직접 개발해보았다. (너무 자랑하는 느낌.. ㅎㅎ)

비록 누가 볼 때는 “유니티에서 해주는건데 너가 왜함? 너 호구임?”이라고 할 수 있지만, “내가 할 수 있으니 한거지… 그러면, 나중에 유지보수할 때 도움도 되고 그만큼 유니티에서 소스코드와 개발문서를 잘 주었다는 증명이잖아?”라고 반문할 수 있겠다. ㅎㅎ

어쨌든… 개발은 뭐든 해보고 많이 알 수록 좋은 것 같다. 그리고 이런 위기 상황에서 오히려 유지보수를 미리 연습해볼 수 있고 그 과정에서 부족한 항목들도 알게되어 유니티에 요청할 수 있었기에 매우 좋은 경험이었던 것 같다.

뻔한 비법 5. 경험이 없을 때는 논문과 타인의 개발 블로그가 큰 도움이 된다.

내가 이러한 분야(납품 점검, 인수, 검수, 유지보수 등)에 경험이 전혀 없었기 때문에 논문과 개발 블로그를 많이 참고하였다. 그 중에서도 검수에 필요한 테스트 계획 수립은 2개의 논문을 참고하여 아래와 같이 미리 정리해두었고, 이 내용을 참고하여 뒤에 있을 테스트 계획서를 정석적으로라도 작성할 수 있었던 것 같다.

참고 논문 1) 여호영 외 2, 소프트웨어의 유지보수를 위한 PSDG 기반 의미분할모형의 설계

[요약]

유지보수란? 소프트웨어의 유지보수는 개발 단계에서 만들어진 소프트웨어를 사용자에게 인도한 다음에 이루어지는 활동으로써, 주로 기 개발된 소프트웨어의 결점이나 오류를 교정하고, 주변 환경의 변화에 따른 적응 및 확장과 결함예방 활동들을 일컫는다.

유지보수를 위한 세부방법들

  1. 원시코드를 이해하기 쉽게 재구성하거나, 원시코드를 이용하여 설계 문서와 분석관련 문서의 회복 및 표준화 문서로 재 작성하는 재공학방법 ← 이건 유니티에서 해주지 않을까?
  2. 개발 및 유지보수에 관련된 모든 문서를 데이터베이스화하여 관련 정보를 효율적으로 검색하고 관리 유지하기 위하여 통합 자료 저장소 구축 및 관리방법 ← 이 노션에서 해보자

그렇다면, 유지보수의 중요한 인자는?

  • 기존코드와 분석 및 설계관련 문서들의 이해용이성과 정형화가 유지보수의 중요한 인자

참고 논문 2) 최규진 외 1, 관리 도구를 통한 소프트웨어 유지보수 수행 모델 설계 및 시스템 개발

[요약]

소프트웨어 유지보수에 마땅한 관리도구가 없어 문제:

소프트웨어 유지보수는 관리 도구를 통한 표준화된 수행 방법이 없어 주로 메일과 문서로만 업무를 수행하고 있다. 그래서 각 개발자들은 산출물 등 문서 작성에 시간을 많이 사용하고 관리자는 산출물 수합 업무 시간이 증가되어 유지보수 관리 비용이 불필요하게 많이 사용된다.

또한, 유지보수 기간은 소프트웨어가 폐기될 때까지 몇 년 이상 진행된다. 이 유지보수 기간이 길어 질수록 요구사항 개발에 따른 소프트웨어 복잡도가 높아지고 개발자 및 관리자의 퇴사 등으로 이력 추적이 힘들어 지면서 소프트웨어 변경 추적이 어렵게 된다.

소프트웨어 유지보수란?

소프트웨어가 제품으로 개발된 후 사용자가 사용하기 시작하면서부터 폐기될 때까지 오류를 수정하거나 새로운 기능을 추가하기 위해 소프트웨어를 변경하는 과정을 말함. ← 유지보수 정의를 비교해보자

소프트웨어 유지보수 관리 항목(최규진 외1, 관리 도구를 통한 소프트웨어 유지보수 수행 모델 설계 및 시스템 개발, p.1 표1)

image-20230821162645385

위 관리 항목 별 수행 방안

  • 신규 프로그램 개발 요청

    • 신규 이름으로 프로그램 항목 생성

    • 신규 개발에 대한 요구사항 항목 생성

    • 두 개의 항목을 연결된 항목으로 수정
  • 기존 프로그램에 대한 개발 요청
    • 개발 또는 운용 요구사항 항목 생성
    • 요구사항에 연결할 항목에 프로그램 항목 등록
  • 이슈 및 리스크 발생
    • 이슈 또는 리스크 항목 생성
    • 이슈/리스크 상위 항목에 해당 요구사항 ID 등록
  • 결함 및 장애 등록
    • 결함 항목 생성
    • 결함 상위 유형에 해당 요구사항 ID 등록

아쉬운 마무리

이렇게 열심히 달려왔던 지난 3개월이었지만, 개발라인에서는 충분히 이행되었다고 판단된 내용임에도 최종 보고를 해야하는 우리쪽 담당자의 눈에는 성에 차지 않았다. 그래서, 내가 어찌할 수 없는 트러블로 결국 기분좋게 마무리할 수 없었다.

하지만, 덕분에 유니티 수석 PM님과 개인적으로 연락할 수 있는 인연도 생겼고, 나 자신을 조금더 좋게 평가해줄 수 있는 여유가 생긴 값진 경험이었던 것 같다.

댓글남기기

참고