11월 개발 일기

최근 회사 일이 너무 바빠서 포스팅을 거의 못했는데...기억나는 일이나 생각들을 적어보고자 한다.

 

1. 앱 개발이 만만하니?

 

 

SI회사 특성 상 자연스럽게 React-Native에 손을 대게 되었다. (사실 입사 때부터...)

 

React-Native에 입문하면서 당환스러웠던 점은 초기 세팅부터 복잡하다는 점이었다. 

 

이상과 현실

 

웹 개발은 CRA던 Vite던 다양한 빌드 도구들을 통해 기본적인 구성을 한 번에 마칠 수 있고, 이를 통해 정상적으로 웹 브라우저에서 구동되기 때문에 초기 세팅에 리소스가 드는 것은 상상하기 어려운 일이었다.

 

하지만 앱 개발은 앱을 구동시키기 위한 시뮬레이터(웹으로 치면 브라우저)를 구동시키는 것부터 문제가 발생해 세상 일에는 다양한 어려움이 있음을 상기시켜준다.

 

너네 둘 다 싫어...

 

Android와 IOS 환경을 테스트 하기 위한 시뮬레이터 구동 프로그램도 달라 Android Studio와 Xcode를 모두 준비해야한다.

 

각각의 시뮬레이터는 가상 기기, 앱 빌드 도구를 모두 프로젝트 개발 환경에 맞게 적용해야 한다.

 

여기에 Xcode 버전에 따른 오류, Android Studio 내 프로젝트 싱크에 따른 문제 등...시뮬레이터가 구동되어도 앱 구동이 안 되는 일이 빈번하게 일어나 마치 여름철에 아무리 뽑아도 자꾸 생기는 잡초들을 떠올리게 한다.

 

심지어 각각의 시뮬레이터는 개발 기기의 메모리를 잡아먹어 구동되기 때문에 기기 성능 저하까지 일으킨다. 단, 성능이 좋은 맥북은 빌드와 컴파일링이 상대적으로 빠르기 때문에 스트레스가 덜한데, 개인 기기를 사용하는 개발자들은 맥북을 구매하던 과거의 자신을 돌아볼 수 있는 계기가 된다.

 

2.  화가 많은 Xcode

 

IOS를 기반으로 한 맥북으로 개발을 해서일까?

 

나는 IOS 기기를 우선적으로 고려한 퍼블리싱을 작업한 후 Android 환경에서 스타일링 등을 추가적으로 확인하는 방식으로 작업하는데...그러다보니 Xcode에서 유독 에러가 많이 나는 것 같다는 생각이 든다.

 

Android Studio의 경우 안드로이드 환경에 따른 스타일이 반영되지 않거나 ios 기반의 기능들이 실행되지 않아 조건문을 추가하고 다른 Android 환경에서 지원하는 기능을 구현해야 하는 경험들이 있었지만, 앱을 구동하는 부분 자체는 크게 어려움이 없었다. 

 

이걸 친절하다고 해야할지...그만큼 구동이 잘 안되는 Xcode의 성능을 저주해야할지...잘 모르겠다

 

하지만 Xcode는...Linker command failed with exit code 1, PhaseScriptExecution failed with a nonzero exit code, NSCocoaErrorDomain Code=4 등 다양한 에러 코드로 개발자에게 예절을 주입시켜준다.

 

에러 코드에 대한 원인 분석을 위해 검색해보아도 Stackoverflow를 비롯한 다양한 구글 검색 결과는 Xcode 버전과 시기, 심지어 같은 시기여도 기기 환경(M1 맥북 vs 인텔 맥북)에 따라 원인이 다르다. 만약 본인과 다른 기기/프로젝트 환경을 기반으로 한 솔루션을 적용했다면,  오히려 일이 커질 수 있어 왜 텍스트를 꼼꼼히 읽어야하는지 알게되는 계기였다.

 

심지어 Xcode는 애플의 정책에 따라 업데이트가 자동으로 이루어지는데...업데이트가 이뤄지면 빌드 과정에서 새로운 에러가 발생하기도 한다.

 

2023년 11월 25일 기준으로 M1 맥북 환경에서 RN기반의 프로젝트를 Xcode 15.0 버전으로 빌드하면 아래와 같은 오류가 발생한다.

No template named 'unary_function' in namespace 'std'; did you mean '__unary_function'?

 

해결 방법은 간단하다.

 

출처: 스택오버플로우

 

아래와 같이 Xcode가 제안했던 방식을 통해 Fix를 하면 되는데...문제는 pod 빌드 환경이 변하거나 여러 이유로 문제가 발생하면 Derived data나 projcet cache를 삭제하면 이 부분도 초기화되어 같은 에러를 다시 해결해야 한다.

 

즉, 이 문제는 새 프로젝트를 열거나, 빌드 과정에서 캐싱이 꼬이면 삭제했을 때 반드시 마주해야 할 에러라는 것이다...이게 맞나

 

3. You, 1 month ago

 

아직 많이 부족하지만 다양한 프로젝트를 맡아 개발하다 보니 나날이 실력이 느는게 느껴진다.

 

특히 퍼블리싱 속도, 아키택처/컨벤션을 고려한 구조 및 문법 등 능률적인 측면에서 손이 점점 빨라졌다.

 

덕분에 여유가 생기고 눈에 안 보이던 코드 효율성이나 가독성들이 신경쓰이며 내가 진행하는 파일 내 다른 코드의 품질도 더더욱 신경쓰이게 되었다. 프로젝트에 투입된 지 얼마 안되었던 때는 '그냥 생각이 있었겠지~'하고 넘어가던 부분들도 '이건 도대체 왜 이렇게 짠 거야?' 라는 의문들이 들었다.

 

 

 

다른 사람이 코드를 작성한 부분들도 있었지만, 의외로 가장 큰 적은 나 자신이었다.

 

코드를 살펴보니 거지같은 코드가 있어서 뜯어보니, 쓴 사람이 나였더라. 라는 얘기는 개발 공부를 하면서 더러 들었지만, 직접 겪어보니 생각보다 오묘한 기분이 들었다.

 

이전에는 없었던 여유가 생기고 코딩 실력이 나날이 성장하는 것을 느끼는 경험이면서도, "진짜 이런 생각으로 코드를 짰다고?" 싶은 나 자신에게 의문이 드는 순간이었다.

 

한 편으로는 "미래의 나는 또 현재의 나를 욕하겠지."라는 생각도 들었다.

 

아마 개발자로서 살아간다면 평생 마주해야할 현실이 아닐까 싶어 웃픈 기분이었다.

 

4. Bun 맛 좀 볼래?

 

이 몸 등장

 

지난 9월 8일, 자바스크립트와 타입스크립트 프로젝트에서 실행, 개발, 테스트, 디버깅 과정을 한 번에 수행이 가능한 올인원 런타임 툴킷 번(Bun)을 출시했다. 

 

개발자는 늘 시간과 싸우기 때문에 "속도"가 매우 중요한데, 이번에 출시된 번은 이 포인트를 잘 잡은 것 같다.

 

마침 새롭게 시작하는 프로젝트에서 컨벤션 및 아키택쳐 논의 과정에서 번을 사용하자고 했고, 현재 적용하여 개발 중이다.

 

출처: 번 공식 블로그

 

확실히 빠르다.

 

빌드, 스크립트 런 모두 체감이 확 될 정도로 빠르다. 아직은 개발 초기 단계이기 때문에 프로젝트가 가벼워 엄청 체감이 안 될텐데도 이 정도니, 앞으로 프로젝트 규모가 더 커지면 체감이 더 커질 것 같다. 역시 채신기술...!