2023년 07월 3주차 회고

한주 동안 한 일을 모두 적으려면 엄청난 양을 적어야겠지만 딱히 생각나는 것이 없다. 그땐 정말 힘들거나 큰 일이라고 생각한 것도 나중에 지나고 보니 그리 큰 일이 아니었나 보다.

아직은 좀 더 강해질 가능성이 있다고 받아들이고 싶다.

좀 더 Composable Architecture 처럼

이제 프로젝트가 중반으로 넘어가며 여러 문제들이 나오기 시작한다. 개인적으로 생각되는 문제점들은 다음과 같다.

• TCA 를 제대로 활용하고 있는지에 대한 의심
• 테스트 코드의 부재
• 인수인계 문서 부재

---

TCA 활용

TCA 는 하나의 큰 기능을 단위별로 쪼개 조합하는 오픈 라이브러리이다.

단위 별 조합에서 앱의 상태변경을 하기 위해 상태값을 공유할 수 있도록 하여 각 단위가 서로에게 영향을 끼칠 수 있다.

지금 강조하고 있는 부분이 바로 단위 이다.

과연 내 프로젝트는 잘 단위 별로 개발되어 있는가? 의문이 들었다.

(예시) Dropdown

현재 공통 드롭다운 버튼을 만들어 사용하고 있다. 드롭다운이 표현해야 할 데이터는 다음 두 가지 특징을 갖는다.

1. 고정된 값
2. 서버로부터 불러와야 하는 값

고정된 값은 enum 을 사용했다. enum 에 CaseIterable 프로토콜을 구현하도록 하여 연속된 값을 Dropdown 뷰의 상태값으로 사용한 것이다.

그런데 서버로부터 불러와야 하는 값은 enum 사용이 불가하다. 그러므로 Array 를 사용해야 하는데, 지금까지 사용하던 드롭다운 뷰는 CaseIterable 의 allCases 를 참조하고 있었다.

여기서 고민이 좀 되었다. Dropdown 뷰는 표현하고자 하는 것은 연속된 값을 표현하고, 유저의 이벤트에 따라 자신의 상태값을 정의하는 것이다. 여기에 enum, Array 등으로 상태를 새로 정의해야 하는 건 문제가 있다고 생각한다.

그 날 개발할 것들이 예정되어 있어 지금은 중복코드를 남겨둔 채로 개발을 끝마치긴 했지만 이건 기술부채로 판단된다.

(예시) NumberKeyPad

앱에는 키패드를 활용하는 화면이 다수 존재한다. 여기서 문제는 키패드 입력에 따른 뷰의 반응이 여러가지였다.

• 회색 동그라미 6개를 준비한다. 숫자 하나를 입력하면 회색 동그라미가 왼쪽부터 차례대로 녹색 동그라미가 된다. 6개를 다 입력하면 더 이상 입력을 받으면 안된다.
• 금액을 입력한다. 처음에는 0 으로 시작하고 뒤에는 $ 혹은 ₩ 등의 화폐단위를 표시한다. 키패드 입력은 따라 1, 10, 100, 1000 자리순으로 입력되어야 한다. 1234 를 연속으로 입력하면 1234$ 나 1234₩ 등으로 화면에 표시되어야 하는 것이다. Backspace 버튼을 연속으로 누르면 0$ 나 0₩ 로 표시되어야 한다.

생각해낸 방법은 키패드만 담당하는 구조단위를 만들기 였다. 키패드 구조에는 키패드 입력에 대한 인터페이스 즉, 뷰를 제공하고 뷰의 이벤트를 부모 뷰에 전달한다.

이벤트를 전달받은 부모 뷰는 자식 뷰의 상태값을 포함한 자신의 상태값을 통해 자신의 상태값을 업데이트 한다.

---

잘한 것도 있고 못한 것도 있다. 그런데 실제 앱을 개발해보지 못했다면 절대 알 수 없었을 부분에 대해 배웠다는 생각이 든다.

테스트 코드

테스트 코드는 좀 생각해 볼만한 문제다. 만약 테스트 코드가 프로젝트 진행에 방해가 되는 부분이 너무 크다면 굳이 작성할 생각은 없다.

현재 진행하고 있는 앱은 사실 서버에 무언가를 요청하고 그 응답을 화면에 표현하는 것이 대부분이다.

그렇다면 Unit-Test 에 Amplify 나 Apollo 등 외부 의존성을 세팅하는 코드와 함께 테스트 코드를 짜야 하는가? 두 가지 문제가 있다.

• Amplify, Apollo 같은 외부 의존성을 주입하는 순간 Unit-Test 는 느려진다. 느린 Unit-Test 는 그 가치가 현저히 떨어진다.
• 가치가 떨어지는 테스트 코드를 작성하는 데 많은 시간과 공을 들이는 것은 옳지 못하다. 그렇다고 Mock 을 만들기엔 현실성이 떨어진다.

지금 생각하고 있는 것은 Unit-Test 가 아닌 UI-Test 가 훨씬 적절하겠다 는 것이다. UI-Test 는 적어도 혼자서 계속 돌면서 문제를 파악하기 때문에 코드만 잘 짜놓으면 문제를 바로 캐치할 수 있다.

거기다가 어차피 Unit-Test 에 의존성을 주입해서 테스트해야 한다고 파악된 순간 UI, Unit-Test 둘의 소요시간에 큰 차이가 없다.

인수인계 문제 부재

이 프로젝트가 끝난 뒤 어떻게 될지 몰라 라는 생각이 아니다. 내가 다른 업무를 여기서 본다고 해도 마찬가지다.

프로젝트가 중간에 중단되지만 않으면 언젠가 이 프로젝트는 누군가에게 인수인계 되어야 할 것이다.

그 상황에서 "인수인계 시작" 이라고 했을 때 문서를 만들기 시작하면 정말정말 오래걸리고 서로 대단히 힘들 것이다.

어떻게 적어야 할까... TCA, SwiftUI 를 실제 많이 활용해 본 개발자 만나기가 참 어렵다. 나도 아직 배우고 있는 단계이기 때문에 어떻게 해야 새로 오시는 분의 "소프트 랜딩" 을 도울 수 있을까.

언젠가 일어날 일이다. 대비가 필요하다.

재택?

개인 공부를 피곤하다는 핑계로 소홀히 했다. 출퇴근 시간에 인강을 듣기는 듣는데 거의 졸면서 듣고 있다. 그래도 졸았으면 다시 돌아가거나 한번 더 듣는 식으로 하고 있는데, 뭔가 시간 낭비가 많다는 느낌이 든다.

그런데 이번 재계약 때 클라이언트 측에서 일주일에 한번만 출근해도 좋다는 말씀을 해 주셨다. 이제 상호간의 신뢰가 쌓였다는 것이 이유였다. 나는 이 말에서 2 개를 느꼈다.

• 프로젝트가 끝날 때까지 개발을 계속 이어갔으면 한다.
• 일종의 권리를 줄테니 더 많은 성과와 노력을 바란다.

나는 권리에 좀 더 집중하고 싶다.

권리에는 책임이 따른다. 클라이언트에서 권리를 주었으니 나는 책임을 지는 것이 좋다. 책임을 지지 않으려 한다면 권리도 없어질 것이다.

나는 이 권리를 잘 이용하면 회사를 다니면서도 개인 공부에 소홀해지지 않을 것이라고 생각했다. 하지만 여기서 딜레마가 발생한다. 책임을 져야 하는데, 개인공부를 한다고 하면 책임에 소홀해질 수 있다.

하루종일 고민을 한 결과 수, 목요일만 재택을 하기로 했다. 월, 금은 한주의 시작과 종료이므로 출근을 할 필요가 있다고 생각했다. 그렇게 되면 3일 재택인데, 프로젝트 진행에 영향을 끼치지는 않을까 무서웠다. 그래서 화요일도 나오기로 하여 그렇게 되었다.

나의 선호에 따라 유연한 근무를 할 수 있게 되었다. 이 권리를 이용해 개인 공부도 하고 권리에 대한 책임지는 모습을 통해 얻은 것을 잃지 않도록 노력해야 겠다.