[WHY 시리즈 1] E.003 — 단위 테스트, 개밥 먹기, 데이터 구조 정의
‘코드와 서비스 만들기를 좋아하는 소프트웨어 엔지니어’로 일하고 있다. 엔지니어는 문제를 해결하는 사람이다. 문제를 해결하는 과정에는 여러 가지 선택이 존재할 수 있다. 가능한 최선의 결과를 위해, 항상 내 선택의 Why에 답할 수 있는 사람이 되고자 한다. 매주, 한 주 동안 내가 결정한 선택의 Why에 대해 정리하고자 한다.
호찌민(사이공)에서의 3주차 일과 삶. 이제 꽤 사람과 환경에 적응해가고 있다. 이번 주는 프로젝트 Phase 2에 대한 회고에 참여할 수 있었고, 원격에서 근무를 하고 계시던 서버 엔지니어 동료가 사이공 오피스로 출근하여 모든 엔지니어가 얼굴을 마주하고 토론할 수 있었다. 정신없이 흘러갔던 3주차의 선택에 Why를 던져본다.
Why?
1. 3rd party API 단위 테스트
현재 맡고있는 업무 중, 3rd party API를 사용하여 개발을 진행해야 하는 일이 존재한다. 이 외부 API와 통신하는 모듈을 개발하고, 단위 테스트 코드를 작성하던 중 정신이 번쩍 들었다. 내가 작성하는 단위 테스트 코드는, 같은 입력에 대해서도 외부 서버의 상태에 따라 실패할 수도 성공할 수도 있는 단위 테스트 코드였기 때문이다. 그래서, 처음부터 생각을 다시 정리했다. 단위 테스트란 무엇인가? 위키피디아에서는 ‘unit testing is a software testing method by which individual units of source code.’ 즉, 소스 코드의 개별 단위(가장 작은 단위라고 이해하고 있다.)를 테스트하는 방법 중 하나라고 정의한다. 이규원님의 글에서는 ‘이상적으로 단위 테스트 케이스는 테스트 대상이 아닌 코드의 결점에 독립적이어야 합니다.’ 라고 표현했다. 그래서 외부 API와 통신하는 해당 모듈을 위해 테스트 대역(Test Double)을 사용하기로 결정했다.
- Why? 해당 단위 테스트 코드의 목적은, 테스트 대상이 되는 단위 내에서 내가 작성한 코드의 결점을 발견하기 위함이다. 즉, 외부 환경(3rd party API 서버)에 따라 단위 테스트 결과가 달라지는 것은 본 목적을 벗어나는 일이다.
가급적 단위 테스트 코드를 작성하기 전, 테스트 하려는 대상과 목적을 명확히 하고 시작하려 한다. 그렇지 않으면 테스트 대상의 범위를 벗어난 단위 테스트 코드를 작성하게 될 수도 있다.
Note: 이규원님의 다른 글을 읽고 공감되는 구절을 발견했다. ‘나는 테스트 케이스를 작성할 때 단위 테스팅을 할지 통합 테스팅을 할지 심각하게 판단하지 않는다. 다시 말하지만 그건 나에게 별 의미가 없는 고민이다. 중요한 것은 테스트 케이스가 없음으로 인해 불안함을 느끼는지다.’
중요한 것은 내가 작성한 코드의 불안함을 제거했느냐이지, 어떤 테스팅 기법을 적용했느냐가 아니다.
2. 개밥 먹기
현재 프로젝트의 Phase 2가 종료될 무렵, 팀에 조인하게 되었다. 프로덕트 팀에서 Phase 2를 회고하는 시간을 갖게 되었고, ‘우리는 개밥 먹기를 잘 했는가’에 대해서는 아쉬움이 남는다는 동료의 말을 듣게 되었다. 개밥 먹기란 본인이 만들고 있는 프로덕트를, 본인이 직접 사용해보는 것을 의미한다. Phase 2에서는 개밥 먹기에 대해 스스로 회고할 내용이 없었지만, Phase 3에서는 더욱 자주 개밥 먹기를 하자는 동료들의 의견에 동의했다.
- Why? 적어도 내가 만든(혹은 개발한) 결과가 전체 프로덕트에 어떤 영향을 미치는지 알고 있는 것은 중요하다. 내가 맡은 기능 범위 안에서 개발의 결과물은 좋았을지라도, 전체 프로덕트를 사용하는 관점에서는 예상 밖의 불편함을 경험할 수도 있다. 이러한 불편함을 빠르게 발견하고, 프로덕트 자체를 더 옳은 방향으로 개선하기 위해서라도 개밥 먹기는 중요하다.
다음주 부터 시작되는 Phase 3에서는, 새로운 버전의 앱이 릴리즈 되었다는 알림이 올 때 마다 다같이 역동적으로 프로덕트를 써보는 모습을 볼 수 있을 것 같다.
3. 데이터 구조 정의
원격으로 근무하시던 서버 엔지니어 동료가 사이공 오피스로 1주일 동안 출근하게 되셨고, 모바일 앱 개발을 하시던 다른 엔지니어 분의 제안으로 클라이언트와 서버 간의 특정 인터페이스에 대해 토론하는 시간을 갖게 되었다. 클라이언트와 서버가 주고 받는 데이터 구조에 대한 이야기였으며, 특정 object와 그 하위 object의 구조를 어떻게 설계할까에 대한 것이었다. 왜 예상보다 오랜 시간을 이 주제에 대해 토론하는데 사용했을까?
- Why? 당연한 이야기지만, 클라이언트와 서버쪽 모두가 동의할 수 있는 데이터 구조를 이끌어내야 했다. 클라이언트 쪽의 기능 요구사항을 지원할 수 있는 데이터를 서버에서 보내주어야 하고, 굳이 클라이언트와 서버 양쪽에서 검증할 필요가 없는 데이터를 걸러내고, 클라이언트에서 파싱하기 유리한 구조로 갈지 혹은 서버의 데이터 스키마를 최대한 유지할지 등의 이야기는 결국 모두가 동의할 수 있는 데이터 구조를 이끌어내기 위함이었다.
- Why? 안타깝게도, 현재는 요구사항이 명확한 상태에서 개발을 진행한다기 보다는 명확한 요구사항 도출 과정과 개발 과정이 어느 정도 중첩되는 형태로 일이 진행되고 있다. 프로젝트 특성 상, 동료들 모두 동의한 환경이며 적극적으로 역할이 다른 동료들과 협업하고 일이 되게끔 해야 하는 상황이다. 즉, 요구사항의 변경 가능성이 적지 않은 환경이라는 말이다. 현재까지의 요구사항을 만족시키면서, 예측할 수 있는 다른 상황들을 고민해보고 추후 변경에 열려있는 구조를 가져가기 위함이었다.
이제 다가오는 새로운 주 부터는, Phase 3의 본격적인 설계/개발이 시작된다. 또 어떤 고난들이 날 기다리고 있을지 걱정 반 설렘 반. 잘 해결해 나가고, 배움의 이야기가 충만한 한 주가 되길 바란다.
