아스

✅ 오늘 배운 것

오늘의 할 일은 다음과 같다. 

완성 단계에 있는 디자인을 적용해주면 되고, 위에가 여러 화면과 컴포넌트 디자인 이슈들 중 내가 맡은 것들이다. 차근히 하나씩 해 보자. 위의 이슈들이 컴포넌트 반영 이슈들이고, 아래의 이슈들이 스크린(화면)을 만드는 이슈들이다. 컴포넌트를 만들고 화면을 만드는 것이 우선순위이니 차례대로 해 보자. 

우선 맨 위의 '카테고리바 컴포넌트 디자인 반영' 이슈를 보자. 

다음은 기존의 코드이다.

const renderItem = ({ item, handlePress }) => (
  <ListItem
    title={item.title}
    accessoryLeft={renderItemIcon}
    onPress={() => handlePress(item)}
  />
);

UI Kitten에서 제공하는 라이브러리 덕분에 ListItem이라는 컴포넌트만 쓰면 이런 예쁜 화면이 나왔었다. 

이제 이걸 뜯어내 보면, 다시 제로부터 돌아간 태초의 화면이 보인다. 이제 이 화면을 예쁘게 만들어줘야 한다.

이제는 외부 라이브러리에서 제공하는 아이콘을 사용하는 게 아니라 SVG 아이콘을 직접 사용해야 한다. 그러므로 피그마에서 아이콘을 직접 다운받고 .svg 파일의 포맷을 사용하기 위해서 필요한 별도 라이브러리를 다운받아 주자. 

npm install react-native-svg react-native-svg-transformer

그리고 피그마에 맞게 padding, margin 등의 값을 잘 입력해 주면, 다음과 같은 화면을 볼 수 있다. 

이번주의 나의 활동은 어땠는지를 점검하고 이를 KPT(keep-problem-try) 회고로 작성해 보자.

✅ 뭘 했는가

프로젝트 관련해서는 11월 2일, 애플로그인을 드디어 드디어 해결했다!! 당시 회식에 갔다가 팀원들끼리 해결해야 할 것들이 있어서(광고 및 iOS 출시 관련) 다시 몸을 이끌고 선릉으로 향했었다. 되었으면 좋겠지만 설마 되려나? 싶었는데, 며칠 간 발목을 잡던 이슈도 해결되면서 ios 에뮬레이터에서 처음으로 메인 투두 화면을 볼 수 있었다. (캡처를 못 한게 한이다...)

Djangonaut 관련해서는 드디어 조금의 진전이 있었다! 우선 드디어 첫 기여를 했다. 팀 navigator 분의 도움을 정말 많이 받았다. 어떻게 이런 뉴비가 해결 가능한 이슈를 들고 오시는지 의문이다... 너무 감사하면서도, 나도 나중에 djangonaut이 끝나고도 계속 기여할 수 있도록 노하우를 익혀 두어야겠다는 생각을 했다. 

그래서 냅다 Djangonaut 팀 채널에 질문을 올려 보았는데, 감사하게도 답변을 해 주셨다..! 적절한 이슈를 찾기 위해서 알려주신 유튜브 영상의 노하우를 참고해 봐야겠다. 

그리고 같은 팀의 Djangonaut인 Tai와 pair programming도 했다. 두 번째 이슈(정확한 해결 방법인지 확신을 못 해서 아직 PR은 안 올렸다)를 해결하기 위한 온라인 미팅이었는데, 첫 페어프로그래밍을 모국어가 아닌 영어로 하려니 처음에 좀 긴장을 했다. 그런데 Tai도 나도 둘 다 영어가 모국어가 아니라서, 모르는 단어를 서로 잘 풀어가며 페어프로그래밍을 했었다..! 암튼 이번 주에 진전이 좀 많았다. 

취준 관련해서는 늘 그렇듯 조금씩 잔잔바리로 원서를 넣는 중이다. 안 좋은 걸 알지만 나는 아직은 FOMO가 원동력인 사람이기에, 원서를 안 넣어서라기보다는 완급 조절을 못 하는게 주로 문제가 되었었다. 그런데 이번주는 나름 잘 자제하고 몇 개만 원서를 넣은 것 같아 잘 절제해서 뿌듯하다. 아닌가?

그런데 문제는 아직 원서를 넣을 예정인 것들도 꽤 많다는 것이다... 어차피 이제 하반기 공채도 끝물이라 이 시즌이 지나가면 상반기를 기약해야 한다. 그래서 조오금만 더 욕심을 내 보고, 소마 발표도 잘 마치고, 12월에 짧게 여행도 가면 취준의 결과가 어떻게 되든 올해도 무사히, 나름 잘 마무리하게 될 것 같다. 

그리고 어제(11월 2일) 멘토님께서 알려주신 오픈소스 커뮤니티 기여(정확한 명칭이 헷갈린다) 프로그램에 참여했었는데, 거기서 영문->한글로 번역도 하고, django에서 이슈를 발견하신 다른 개발자분도 만나고, 소마 내년 모집에 관심이 있으신 개발자분도 만나서 신기했다. 그리고 초면인 분들과 회식을 따라가게 되었는데 낯설고 신기하면서도 재밌었던 경험이었다. 

모임에 계신 대부분의 분들은 직장인 개발자 분들이셨다. 그분들을 보면서 나도 내 한 몸을 건사할 수 있는 직장인이 되고 조금의 여유를 갖게 된다면, 남게 될 나의 퇴근 후의 시간을 어떻게 쓸지 고민해보게 되었다. 성취감을 느끼면서도 미래의 나와 내 커리어에도 도움이 되고, 또 여러 사람들을 만나볼 수 있는 활동을 찾아보고 싶었다. 

✅ Keep - 이번 주에 잘 해온 것

Djangonaut 이슈에 기여한 것과, 프로젝트에서 애플로그인을 끝낸 것을 잘 했다고 생각한다. 그리고 이번 주는 오늘의 가족 여행으로 일에 스며든 마음을 제법 많이 회복했다! 가서 거의 산행을 했는데, 역시 잡다한 생각을 날려주는 데는 운동과 걷기만한 게 없었다. LGTM인 여행이었고, 오랜만에 가족들과 하루를 온전히 보낸 것도 좋았다. 

✅ Problem - 문제점

프로젝트 중 내가 맡은 부분의 성취율이 좀 지지부진했다는 점이 마음에 들지는 않는다. 근데 또 막상 지금 와서 타파할 방법은 생각이 안 나는게, 며칠간 거의 억까 이슈(expo 설정 관련이라 알아차리기 매우 까다로웠던 이슈)에 잡혀 있었기 때문이다. 그래서 '그래도 틈틈이 방법을 찾아보았으니 이건 어쩔 수 없다'고 결론을 내렸다.

그리고 저번 주에 Try로 뽑았던 스위치를 키고 끄는 시간을 잘 정하는 것도 도움이 되었다. 이게 막 성취율을 엄청 올려 주지는 않았는데, 에너지의 누수는 좀 막아 주었다. 그리고 일주일에 반나절이나 하루 쯤은 일을 머릿속에서 잠시 내보내는 시간도 꼭 필요함을 이번 여행으로도 느낄 수 있었다. 

✅ Try - 시도할 것

놀랍게도... 없음! 내가 보기엔 나름 잘 하고 있다. 11월 3주차까지가 소마 프로젝트 + 취준 + 여행 계획 세우기로 무지무지 바쁠텐데, 그 때 동안만 멘탈을 잘 유지해 보자. 

✅ 오늘 배운 것

오늘의 이슈를 시작하기 전에, 작게나마 기여한 것이 있어서 뿌듯한 마음에 사진으로 남겨본다.

바로 오늘 warehouse라는 사이트를 통해 문서나 관련 표현을 번역하여 기여하는 활동을 했는데, 내가 총 87개의 문장을 번역했다고 나와 있었다. 물론 1차 번역은 GPT가 하고 나는 첨삭만 했지만 그래도 한 게 어디인가. 

암튼 좀 뿌듯해서 올려봤다.

이제 이슈로 돌아가자. 어제까지 장장 며칠간 우리 팀의 발을 묶어놓았던 이슈가 어제 드디어 해결되었다는 소식이 들려왔다. 발단은 동적으로 환경변수를 주입하거나 세팅하는 것과 관련된 파일(정확한 코드의 역할은 다른 팀원에게 물어봐야 하겠다. 암튼!)에서 난 오류였다. GPT에게 물어보니 Expo의 플러그인을 사용해서 ios 빌드에 사용되는 Podfile을 동적으로 런타임 시 변환시키는 코드라고 한다. 

해당 파일에는 'return config'라는 부분이 있는데, 해당 부분을 'return innerConfig'로 바꿔 주었더니 해결되었다. 해당 파일에는 'withStaticFrameworks'라는 함수가 있는데, 여기서의 리턴값을 config 대신에 innerConfig로 바꿔 준 것이다. 그리고 인자로 주어지는 config는 expo 프로젝트의 전체 설정값을 담고 있는 객체라고 한다. 

즉 기존의 withStaticFrameworks에서는 전체 설정 파일을 수정해서 그대로 리턴하고 있었다면, 이 중 하위 객체인 innerConfig만 리턴하도록 바꿔준 것이다. 내가 해결한 것은 아니었지만, 왜 이렇게 했더니 오류가 해결되었는지 궁금했다. 

녀석(GPT)의 추론이 꽤 그럴듯하다. 역시 LLM 모델이다. 녀석은 expo의 전체 설정 파일(config)를 리턴할 경우 의도치 않은 다른 설정까지 덮어쓸 가능성을 제시해주었다. 그래서 innerConfig로 바꿨어야 하는구나. 그렇군! 하고 다시 문제의 그 명령어를 실행했다. 

npm run ios:dev

이번에는 빌드가 5초 컷 당하지 않았다. 대신에 다른 에러가 났다. 아마도 설정 정보가 중복되어서 나는 에러로 보였다.

이번에 처리 중인 이슈는 Python 3.14에서 parser의 메소드 중 하나인 'add_argument_group'에 사용되는 prefix_chars 옵션이 deprecated된 것과 관련이 있다. 우리 팀의 navigator 분이 관련 이슈를 보내주셨다. 

해당 이슈는 Python의 CPython 레포의 이슈로, 해당 prefix_chars를 deprecate 시키는 커밋이 들어있었다. 

처음에는 그래서 어떻게 하면 된다는 것인가 싶어서 모호했는데, 위의 코드를 보니 '_ArgumentGroup'(아마도 add_argument_group의 클래스를 말하는 것 같았다)이 초기화될 때 'prefix_chars'라는 옵션을 사용하면 warning을 제시하도록 하는 코드라고 이해했다. 

해당 prefix_chars 옵션은 Python 3.14부터 deprecated 되고, Python 3.16부터 아예 사용이 금지된다. 

즉 이러한 상황에서 django에서 사용하는 'dbshell'이라는 커맨드에서 이 add_argument_group 메소드에 대해 prefix_chars를 사용하는 코드가 있다는 것이 문제 상황이다. 

dbshell은 처음 들어보는 명령어였는데, 공식문서에서 찾을 수 있었다. 이 명령어는 settings.py의 DATABASE 값으로 설정된 값에 대해서 DB client를 실행시키는 것이라고 이해했다. 

django.core.management.commands 파일에는 django-admin 커맨드로 사용되는 모든 커맨드들이 파이썬 파일로 모여 있다. 이 중 dbshell.py 파일의 코드에서 'prefix_char' 옵션이 사용되는 것을 볼 수 있었다. 

# dbshell.py
import subprocess

from django.core.management.base import BaseCommand, CommandError
from django.db import DEFAULT_DB_ALIAS, connections


class Command(BaseCommand):
    help = (
        "Runs the command-line client for specified database, or the "
        "default database if none is provided."
    )

    requires_system_checks = []

    def add_arguments(self, parser):
        parser.add_argument(
            "--database",
            default=DEFAULT_DB_ALIAS,
            choices=tuple(connections),
            help=(
                "Nominates a database onto which to open a shell. Defaults to the "
                '"default" database.'
            ),
        )
        parameters = parser.add_argument_group("parameters", prefix_chars="--")
        parameters.add_argument("parameters", nargs="*")

아래에서 두 번째 줄에서 add_argument_group이 prefix_chars를 옵션으로 받고 있었다. 해당 줄을 지우고, 대신 다음과 같은 코드로 대체해 보았다. 결국엔 기존 코드에서 'prefix_chars' 옵션만 뺀 코드였다. 

parameters = parser.add_argument_group("parameters")
parameters.add_argument("parameters", nargs="*")

그리고 테스트를 돌렸는데(관련된 dbshell 테스트만 돌렸다), 테스트가 다 통과하는 게 아닌가.

cd tests
python -Wall ./runtests.py dbshell

prefix_chars 옵션이 없이도 다른 arguments들이 적재적소에 잘 들어간 것인지가 불분명했다. 그래서 일단은 이 찜찜한 상황에서 코드를 멈춰두고, 팀의 navigator 분께 다음과 같이 조언을 구하기로 했다.

1. 이렇게 코드를 바꿔 보았고 테스트가 잘 되는데 여기서 어떻게 하면 이슈가 일단 우리가 할 수 있는 만큼은 핸들링 되었는지를 알 수 있을까?
2. pair programming을 더 잘 하는 팁이 있을까?

✅ 오늘 배운 것

어제의 상황에서 아직 멈춰있다. GPT에게 도움을 요청했을 때도 sentry 관련 패키지 에러, expo와 sentry의 호환성(?)문제, 캐시 삭제 등의 방법을 알려주었지만, 다 해 봤는데도 똑같은 오류가 났다. 

깃허브 관련 이슈를 찾아보니 해당 이슈에서는 expo를 prebuild했을 때 나는 이슈에 초점을 두고 있는 것 같았다. 사람들의 조언에 따라 우선 expo-cli를 최신 버전으로 업데이트 해 주었다. 아직 되지 않는다.

다만 패키지 호환성보다도 expo prebuild 문제인 것은 거의 확실해진 것이, 'expo prebuild' 명령어만 실행해도 관련 에러가 난다. 즉 prebuild 이후의 과정에서 나는 문제는 아니었던 것 같다. 해당 글에서는 다른 해결방법들도 제시해 주고 있었다. 문제는 그 방법이 좀 많이 번거로워서... 저걸 따라해야 한다는 데서 엄두가 잘 안 났다. 

MacOS 업데이트, XCode 지웠다 깔기, 컴퓨터 다시 켜기, expo-cli 업데이트 하기 등등.... 할 수 있는 것은 다 해보신 것 같았다. 생각해보니 만약 ios 관련이라면 xcode나 pods 관련 오류일 수도 있지 않을까? 싶어서 xcode 관련 파일까지는 한번 제거해봐야 할 것 같다. ios 폴더와 xcode 관련 캐시를 제거해주었다. 

rm -rf ios
rm -rf ~/Library/Developer/Xcode/DerivedData

역시나 되지 않는다... 뭐가 문제인 것일까? 생각해보니 안드로이드 에뮬레이터에서는 이 문제가 일어나지 않았다. 그렇다면 ios 설정이 잘못되었거나, expo와 ios 사이의 설정 등의 문제일 수 있겠다. 질문을 바꿔 해 보니 GPT도 아까와는 다른 방법을 알려주었다. 

관련해서는 ios 환경을 초기화하고, CocoaPods(Swift 언어에 대한 의존성 관리 툴으로 보인다) 설정을 초기화해 주었다. 

rm -rf ~/Library/Developer/Xcode/DerivedData
cd ios
pod install
cd ..

그리고 'npx expo-doctor' 라는 명령어를 이용해서 현재 expo의 설정 상에서 문제가 없는지를 확인해보았다. 그랬더니 이처럼 패키지 간의 의존관계에 문제가 있다는 답변이 나왔다. 

아래와 같은 명령어를 시도하니 다음과 같은 에러가 났다. 

npx expo install --check

typescript를 설치해볼 것을 권장하기에 그렇다고 했는데, 다음과 같은 에러가 났다. 알고보니 typescript 관련해서도 다른 패키지와 의존성 충돌이 있는 모양이었다. 

npm install typescript --save-dev

친절히 오류 메시지를 알려 주길래 따라해 보았다. 

sudo chown -R 501:20 "/Users/soyoung/.npm"

'chown'은 'change owner'의 약자인 듯 했다. 즉 해당 디렉토리 안에 있는 모든 파일에 대한 소유 권한을 그룹 ID 20, 사용자 ID 501에 할당한다는 의미였다. .npm 디렉토리 안에는 아마도 관련 캐시나 설정 파일이 들어있을 것 같아서 소유권 변경이 필요한가? 싶어서 일단 명령어를 입력했는데, 문제는 입력해도 오류가 난다는 것이었다. 특정 버전의 라이브러리를 설치하려고 해도 의존성 충돌이 계속 발생했다. 

npm install @typescript-eslint/eslint-plugin@5.30.5 @typescript-eslint/parser@5.30.5 --save-dev

그래서 결국 node_modules 파일과 package-lock.json 파일을 지우고 처음부터 시작해 보았다. 

rm -rf node_modules package-lock.json
npm install

그런데 npm install 부분에서 또 막히는 게 아닌가.

이렇게 계속 막히다가, 결국에는 --legacy-peer-deps 옵션을 사용해보기로 했다. 이 옵션을 사용하면 패키지 간의 의존관계를 무시하고 일단 설치를 진행한다고 한다. 

npm install --legacy-peer-deps

✅ 오늘 배운 것

현재 상황에 대해서 간략히 정리해 보자. 애플 로그인 프론트 작업은 1차적으로 완료되었다. 다만 서버와 통신할 때 콘솔에 찍히는 응답이 null인 문제를 해결하면 되겠다. 

그런데 오늘 추가적인 문제가 발생했다. 다른 팀원이 알려준 이슈인데, 앱을 지웠다가 다시 깔았을 때 messaging().getToken() 메소드에서 오류가 발생한다는 문제였다. (이 messaging은 RnFirebase 라이브러리의 기능이다.) 그리고 이 이슈는 아마도 내 apple developer 계정에 '프로비저닝 프로파일(Profile)'이 없는 것과 연관이 있다고 말해주었다. 

결론은 '프로비저닝 프로파일'을 새로 만들어줘야 했다. 문제는 이 프로파일을 만들기 위해서는 '새 디바이스'를 등록해야 한다는 점이었다. 그런데 이 새 디바이스의 경우, 이미 기존 apple developer 계정에 연동되어 있던 내 아이패드나 팀원의 아이폰은 '이미 등록된 디바이스'로 간주되어 새 디바이스로 간주하지 않는다는 문제가 있었다. 

그렇게 프로비저닝 프로파일 생성하는 난관에 부딪히고 있던 때, 다시 Device 탭에 들어가 봤더니 웬일로 잘 되는 것이 아닌가. 

이 Device(다른 팀원의 iphone 디바이스다)를 사용해서 apple developer 계정에서 프로비저닝 프로파일을 생성할 수 있었고, 생성한 프로파일을 XCode에 적용할 수 있었다. 

그렇게 프로파일을 무사히 적용하고, dev 브랜치와 rebase도 했다. 그리고 다시 'npm run ios:dev' 명령어를 실행하니, 다음과 같은 에러가 뜨는 게 아닌가. 

GPT의 조언과 다양한 블로그 글들을 참고해봤는데, GPT가 제시한 원인과는 달리 RN 환경이 아닌 곳에서도 많은 github issue들을 볼 수 있었다. 그에 비해 GPT는 다음과 같은 원인들을 제시했는데, 과연 이 원인들이 정말이었을지는 조금 의문스럽다. 

1. Sentry 설정 문제
2. Expo와 Sentry의 연동 문제
3. Sentry 관련 패키지(@sentry/react-native) 설정 문제

3번의 경우 npm i 명령어로 버전 업그레이드를 해 주었다. 여전히 되지 않아서 1-2번 아니면 다른 github issue(찾아봤는데 내 경우와 완벽히 일치하는 issue는 잘 보이지 않았다)를 찾아서 공통점을 파악해봐야 할 것 같다. 

1번의 경우 sentry.properties 파일이 다른 경로에 있을 가능성을 제시해 주었는데, 문제는 나는 애초에 sentry.properties 파일이 없었다는 거였다. 

2번의 경우도 마찬가지로 설정 파일(app.config.js)에서 expo 관련 설정에서 특정 파라미터(ios.dangerous)의 경로 설정이 잘못되었을 가능성을 제시해 주는데, 문제는 애초에 해당 파라미터와 관련된 설정은 없었다. 아직 여기에서 막히고 있다... 내일 다시 해 봐야겠다. 

오픈 소스에 첫 PR을 남긴 기념으로 이를 기록하고자 한다. 나는 #34900번 티켓을 작업했다. 정확히는 #34900번 티켓을 참조하는 티켓을 작업했다. 무슨 말이냐면, #34900번 티켓의 주제는 'django와 python 3.13 버전의 호환성'이다. 호환성이 맞지 않는 경우는 무수히 많고 한 번에 해결되는 것이 아니니 #34900번 티켓과 관련된 이슈는 계속 나올 수밖에 없다. 

티켓 작업 순서는 처음이라 헷갈렸었는데, 앞으로 헷갈리지 않도록 정리해 보려고 한다. 

우선 django 공식 레포에 대해서 forked repository를 만들어 준다. django는 오픈 소스 레포지토리이기 때문에 일반 사용자들은 직접 브랜치를 만들거나 레포에 직접 push를 날릴 권한이 없다. 이럴 때는 git fork를 사용한다. 반면 특정 레포지토리에서 협업 프로젝트를 하고 있고, 해당 레포에 대해 브랜치를 만들거나 직접 로컬에서 변경 사항을 push할 권한이 있다면 git clone을 사용하는 것으로 알고 있다. 

즉 git fork는 원본을 그대로 복사해서 만든, 하지만 원본과 엄연히 다른 복사된 레포지토리를 만든다. 반면 원본을 그대로 로컬에 가져오는 것은 git clone이다. 마치 shallow copy와 deep copy와 유사하다는 생각도 든다. 

어쨌든 git fork를 만들어 주고, 해당 fork된 레포에서 또 브랜치를 따로 판다. 다른 사람들의 PR들을 봤을 때 브랜치 이름에 대한 특별한 규칙은 없는 것 같다. 

오늘 작업한 이슈는 deprecated warning과 관련된 이슈였다. django 레포에는 tests라는 디렉토리가 있고, 해당 디렉토리 하위에는 무수한 test 패키지들이 있다. 다 돌려보면 실제로 제법 시간이 많이 든다. 이 중에서 pyenv를 통해 python 3.14(아직 정식 릴리즈 버전은 아니다)를 사용하는 가상환경을 실행하고, 이 환경에서 cache 테스트를 돌려보면 다음과 같이 deprecation warning이 뜨는 것을 볼 수 있다. 

pyenv install 3.14-dev
pyenv virtualenv 3.14-dev django-3.14
pyenv activate django-3.14

python -Wall ./runtests.py cache

즉 python 3.13, python 3.14 버전에서 해당 함수가 deprecated 되었음을 알 수 있다. 

glob 모듈에서 glob1() 메소드를 사용하는 부분이 있는데, 해당 glob1 메소드는 deprecated 처리 되었고 이후 python 3.15 버전부터는 사용이 불가능하기 때문에 경고 메시지가 뜨는 것이었다. 

전체 검색으로 glob1()의 사용처를 찾아보니 딱 한 군데였다. 물론 이 오류를 내가 처음부터 바로 딱 찾아낸 것은 아니고, djangonaut의 navigator님의 도움을 받았다. 해당 glob1() 메소드의 호출부를 glob()으로 변환시켜 주면 되는 문제였다. 기존 코드는 다음과 같았다. 

그렇다고 단순히 함수 이름만 바꿔서는 안 되겠다. glob1()은 2개의 인자를 받는 반면, glob()은 1개의 인자만을 받고 있었다. 찾아보니 glob()와 glob1()의 역할은 거의 비슷했다. 두 메소드 모두 특정 디렉토리의 모든 하위 디렉토리에서 특정 패턴을 가진 파일들을 찾아주는 역할을 했다. 그리고 두 함수 모두 리스트를 리턴했다. 

glob1(a, b)의 경우 a라는 디렉토리의 하위 디렉토리에서 b라는 패턴으로 시작하는 파일들(문자열들)을 찾아냈다. 반면 glob(a)의 경우 인자를 하나만 받는데, 이때 인자 a는 디렉토리와 패턴을 모두 포함하는 문자열이다. 

그래서 위의 함수와 같은 역할을 하도록 glob1() 대신 glob()을 사용하여 함수를 고쳐주면 이런 식으로 바꿀 수 있다. 

이렇게 바꾸고, 반드시 테스트를 돌려서 위에서 나던 deprecation warning이 사라졌는지를 확인해야 하겠다. 

warning이 사라진 것을 볼 수 있다! 이제 forked된 브랜치에 git push를 하고, 해당 forked된 레포에서 django 레포로 PR을 올려보았다. 

code patch(수정한 코드 커밋들)도 무사히 잘 반영되었다!! 첫 PR을 무사히 마쳤으니, 앞으로 다른 이슈도 열심히 작업해봐야겠다ㅎㅎ

이번주의 나의 활동은 어땠는지를 점검하고 이를 KPT(keep-problem-try) 회고로 작성해 보자. 

✅ 뭘 했는가

애플 소셜로그인에서 막히던 것을 겨우겨우 해결한 한 주였다. 프로젝트 기준으로는 내가 한 게 애플 소셜로그인만 있었다. 생각해 보면 이슈가 참 많았는데 말이다. 

물론 가장 중요한 이슈는 애플 소셜로그인이 맞았다. 그리고 생각해 보면 프로젝트 외에서도 다양한 곳에서 interrupt가 들어왔어서 프로젝트를 잘 하지 못한 것인가도 싶었다. 실제로 방해되는 작업들은 아니고 모두 중요한 작업들이지만(Djangonaut과 취준 활동), 순수 프로젝트 입장으로만 보자면 interrupt가 맞았다. 

✅ Keep - 이번 주에 잘 해온 것

모든 일을 100% 쳐내지는 못했지만, 우선순위 기반으로 다른 것들이 조금 밀리더라도 가장 중요한 것들에만 집중했다. 프로젝트 면에서는 가장 중요한 애플로그인만 잡고 있었고, 취준 면에서는 팔랑귀 때문에 여러 채용 공고에 솔깃하더라도 딱 두 개만 집중해서 원서를 썼다. (하나는 제출했고, 나머지 하나는 아직 쓰는 중이다.)

프로젝트와 취준에 비해 약간 우선순위가 밀린 것이 Djangonaut이다. 오픈 소스 컨트리뷰트를 하고 싶은데, 주에 겨우 최소 시간인 4시간만 할애하는 것 같아서 죄책감이 든다. 어떻게 하면 좋을까? (절대 그만두고 싶지는 않고, 균형 잡기가 필요한데 어떻게 할 수 있을지를 고민하게 되었다.) 즉 잘한 것은 어느 하나에만 몰빵하지 않고 나름 균형을 추구한 것, 그리고 각각의 영역 중에서도 가장 중요한 것에만 선택과 집중을 한 것 같다. 

✅ Problem - 문제점

문제점은 프로젝트와 Djangonaut에만 있다. 취준은 선택과 집중을 하는 현 상태가 맞다고 느끼고, 아예 원서를 안 넣는 상황도, 너무 많이 넣어서 허덕이는 상황도 아니었기 때문에 만족 상태에 있다고 보았다. 그렇다면 취준에 그렇게 많은 시간을 쓴 것 같지는 않은데, 왜 남은 시간들이 프로젝트와 Djangonaut에 온전히 쓰일 수 없었는가에 대해 생각해봐야 하겠다. 

지금 현 상황은 고3 입시 상황과 비슷하다. 취준이 입시는 아니지만, 나는 종종 묘한 데자뷰를 느낀다. 항상 일 모드에 대한 스위치가 켜져 있고, 소마 센터에서 집까지 왔다갔다 하는 것도 하루에 2시간 이상이 걸리며, 집에서조차 잘 회복하고 있다는 생각은 잘 들지 않았다. (관심사가 제한되고, 뭔가 충분히 리프레시되는 느낌이 잘 없었다.) 

그리고 이러한 상황에서는 일을 추가적으로 늘리는 것보다 범위를 조금 줄여서라도 '어떻게 성취율을 높일 수 있을까'를 고민하는 것이 맞다고 보았다. 일을 늘린다고 완성하는 일이 그만큼 비례해서 늘지는 않기 때문이다.

즉 시간을 효율적으로 쓰고 있지 않고, 그럭저럭 큰 문제는 없지만 잘 회복하고 있지는 않으며, 현재 목표로 한 것들에 비해 성취율은 다소 낮다는 것이 현재 상황의 문제점인 것 같다. 

✅ Try - 시도할 것

Problem을 참고해서 시도할 점을 정해보자. 시간을 효율적으로 써야 하지만, 헤르미온느의 시간표처럼 빈 시간 없이 빡빡한 시간표를 쓰면 안 되겠다. 하루에 필수적으로 쉬는 시간과 잠 자는 시간을 정해두자. 그리고 그 나머지 시간에서만 효율을 찾아보자. 아무래도 10시 넘어서는 본격적으로 쉬고, 오전 8시에는 일어나는 삶이 제일 바람직하겠다. 그리고 10시에 쉬려면 적어도 8시 반에는 센터에서 집으로 돌아와야 하겠다. 

이렇게 된다면 쉬는 시간에는 일 스위치를 꺼서 회복에 집중할 수 있고, 나머지 시간에서는 조금 더 추진력을 얻어볼 수 있겠다. 나의 원인은 이도 저도 아닌 상태에서 에너지를 뺏겼던 것이었기 때문이다. 마치 고3 때 시험이 얼마 남지 않았어도 자기들의 멘탈 회복을 위해 짧게라도 코노를 가던 친구들처럼, 나도 매일 조금씩은 그런 시간을 내야 하겠다. 

그리고 프로젝트의 범위도 너무 무리해서 잡지 말자. 우선순위를 정하고, 11월 최종발표를 위해서 해야 할 최소한의 것을 정해보자. 그리고 그것을 낱낱이 주간별로 쪼개보자. 당연히 해야 할 것은 많은데, 어차피 11월 이후에도 어떻게든 이 프로젝트는 계속 이어나갈 것이기 때문에 굳이 완성을 11월 전까지 해야 할 필요는 없겠다. 그래야 프로젝트를 하면서 취준과 Djangonaut도 병행할 수 있겠다. 

Djangonaut의 경우도 마찬가지다. 프로젝트와 취준이 아무리 중요해도, 나는 여기에 컨트리뷰터로 참여하는 만큼 최소한의 시간은 내야 할 의무가 있다. 오늘부터 매일 한 시간씩 Djangonaut에 할당하자. 가령 7시에서 8시는 누가 뭐래도 Djangonaut에 기여하는 시간으로 빼 두자. 그래야 나머지 취준과 프로젝트에 우선순위를 아예 뺏기지 않을 것 같다.