우선 하나 고백하자면 저번주에 회고를 빼먹었다. 그리 잘못한 것도 아닌데 참 부끄러운 느낌이 든다. 되는대로 써보고 짧으면 짧은대로, 길면 긴대로 적어보도록 하자.
회사 일 vs 개발 공부
이걸 고민하는 이유 중 하나는 "개발 공부를 못하고 있다" 이 아닐까 한다.
개인적으로 잘만 하면 개발자는 다른 직군에 비해 돈을 "안전"하고 "많이" 벌 "확률" 이 높은 직업이라고 생각한다. 하지만 세상에 공짜는 없는 법.... 그렇기에 신께서는 개발자에게 공부하지 않으면 뒤쳐진다는 과제를 내주시지 않은게 아닐까 싶다.
나의 주말이 아닌 주일의 하루 일과다.
- 05:30~07:30 : 기상 및 헬스장
- 07:30~09:00 : 회사 출근 및 도착
- 09:00~10:00 : 아침식사(책상에서 프로틴 파우더와 베이글을 하나 먹음)
- 10:00~12:30 : 오전 업무
- 12:30~13:30 : 점심식사(나가서 아무거나 먹음)
- 13:30~19:30 : 오후 업무
- 19:30~21:00 : 집 도착(야근 시 더 길어짐)
- 21:00~ : 저녁식사 및 공부(인데 거의 방전상태라서 아무것도 못함)
우선 당연하다고 본다 운동하고 업무하고 3시간 지하철을 탔는데 집에 와서 밥까지 먹었으니 당연히 공부할 기력이 나오지 않을 것이다.
요즘 나의 "내구도" 라는 것에 대해 생각하고 있다. 두 가지 시도를 해 보았다. 월요일에 업무를 미친 듯이 달리고 화수목금을 칼퇴하며 보내보기도 하고, 수요일 운동을 쉰 다음 업무를 미친듯이 달린 뒤 나머지 날은 칼퇴하며 보내보기도 해 보았다. 결론은 둘 다 체력의 한계를 경험했다.
이런 체력의 한계는 고스란히 주말에도 영향을 끼친다. 주말에 아무것도 못하는데 사실 주말을 잘 이용해야 하는 입장에서 참 고민이 아닐 수 없다.
그래서 이번엔 세 번째 시도다. 그것은 인강을 이용하는 것이다. 우선 출퇴근 3시간이 통째로 날라가고 있는데 여기서 책을 보는 것도 좋겠지만 몸이 축나서 뭔가 집중해서 읽기 어려운 상황이다. 인강은 "잘 버무려진 음식을 떠먹여주는 느낌"이기 때문에 인강만 계속 들으며 이용해 보려고 한다. 인강은 주로 CS 관련 인강이다.
집에 와서는 코딩테스트도 좋지만 서버 개발을 좀 해볼까 생각중이다. 코딩테스트는 주말에만 집중해서 하고 말이다. 어차피 개발 폼은 올라와 있으니 뭐라도 개발을 하는 것이 더 효율이 나오지 않을까 싶다.
적고 보니 가성비만 얘기하는 사람처럼 보이는 것 같다. 언제나 더 좋은 방법을 찾기 위해 노력중이다.
프로젝트는 순항 중
하루하루 새로운 이슈가 있지만 그래도 잘 진행되는 중이다.
우선 출근을 하고 있으니 백엔드 개발자와 협업은 순조롭다. 영어를 잘 하는 몽골인인데 한글을 모두 알아듣는다(?). 생각보다 이런 사람이 많다. 나 정도 되는 사람은 잘 한다는 생각도 하면 안되겠다.
기술 스택은 이제 거의 잡혀가는 느낌이다.
- SwiftUI
- TCA
- Apollo
- AWS Amplify
- KeychainSwift(검토 중)
이 상태에서 탄소중립과 관련된 사업자와 고객을 연결하는 iOS 앱만 개발해주면 되는 것이다.
처음 사용해보는 GraphQL 이지만 구글링 해서 문서 읽고 예제 코드 찾아보며 해보고 있다.
앱을 계속 혼자 만들면서 느껴지는 것은 배운 걸 실제로 써먹는게 진짜 중요하다는 것과, 회사에서 일하는 방향과 비슷하게 성장해 나가면 유리하다는 조언이 사실이었다는 것이다.
의존성 주입과 환경변수 중 어떤 방식으로 관리해야 하는지 골라야 하는 두 인스턴스가 있었다.
- SessionManager = 상태값에 따라 로그인 상태를 관리함
- CalculatorAnswer = 사용자가 작성한 답안을 기록하는 객체, 연속되는 여러 뷰의 상태값을 저장해야 한다.
처음에는 둘 다 환경변수로 관리했다. 그게 편해서 였다. 그리고 CalculatorAnswer 는 의존성 주입으로 변경하는 리팩토링을 진행했다.
예컨대 이런 문제가 있다.
- 사용자가 답안 작성 창에서 답안을 모두 작성함.
- 답안이 제출됨.
- 사용자가 다시 답안 작성 창으로 이동함.
- 사용자가 이전에 작성한 답안이 그대로 남아있음.
그래서 결국 답안 작성 화면으로 넘어갈 때 작성 인스턴스를 새로 의존성 주입하는 것으로 변경하였다.
사실 둘 다 환경변수로 써도 된다. 답안과 관련된 인스턴스에 특정 조건이 만족된다면 답안 작성 환경변수 인스턴스를 초기화 하면 된다.
사실 TCA 에서는 Dependency 객체를 통해 의존성을 관리하는 것은 재미있는 경험이었다. 나는 모든 화면에서 사용하는 객체의 가장 중요한 점이 "Thread-Safe 하지 않으면 어쩌지?" 이다. 화면이 오작동.... 이라기 보다는 기괴한 화면 동작을 보여줄 것만 같기 때문이다.
https://github.com/pointfreeco/swift-composable-architecture/discussions/1182
"DependencyValue(TCA 에서 사용하는 의존성과 관련된 구조체 타입)은 Thread safe 한가요?" 에 대한 질문에 라이브러리 제작자의 말로는 "응 그럴꺼야" 이다. 이렇게 얘기할 수 있는 이유는 내부적으로 @TaskLocal 을 사용하기 때문에 그렇다고 한다.
/// swift-dependencies 라이브러리 DependencyValue.swift 의 일부
public struct DependencyValues: Sendable {
@TaskLocal public static var _current = Self()
#if DEBUG
@TaskLocal static var isSetting = false
#endif
@TaskLocal static var currentDependency = CurrentDependency()
...TaskLocal 은 특정 Task 에서만 읽을 수 있는 Local 상태값이다. (Task 는 비동기 작업을 수행하기 위해 정의한 작업의 단위. swift-concurrency 에서 사용된다) 즉, 특정 TCA 의존성 값을 사용하는 EffectTask 내부에서 참조하는 상태값은 Local 의 상태값이기 때문에 "주의만 한다면" Thread-Safe 에 대한 오류 가능성을 좀 덜 수 있다.
개인적으로 좋았던 점은 SwiftUI 의 Environment 던 TCA 의 Dependency 던 내부 모델에서 사용할 것인데 Environment 는 SwiftUI 를 모델에서 import 해야 한다는 것이다. 최대한 로직과 관련된 부분은 SwiftUI, UIKit 등과 멀어지게 하고 싶은데 Dependency 가 그런 부분을 해결해 주었다.
공식 문서에 가보면 해당 Dependency 를 TestStore 에 정의하고 테스트 코드를 작성하는 방법이 상세히 나와있다. 해본 적은 없지만 SwiftUI 의 Environment 는 사용하긴 쉬운데 테스트가 좀 어렵다는 의견이 있다.
Composable Architecture 사용하면 할수록 새로운 것이 많다.
