Jinyoung Hong

Journal of building things, business and life

[카테고리:] Build

What I’m making and why — product, design, and the decisions behind them.

  • Day 06 · 실행하기 (1)

    약 6개월 전, 구글 로그인 오류에 헤매다 현생을 핑계로 덮어뒀던
    우월의 코드 성적표란… 뜯어볼수록 내 마음을 아프게 한다 ㅠㅠㅠㅠㅠㅠㅠ
    아무리 급했다 해도 너무 탈이 많이 나서 속상하다.

    현재 상황은…
    며칠 전에 안드로이드 에뮬레이터 이상이라고 종결짓기로 하고
    오늘은 남편 폰으로 debug 모드 실기기 테스트를 해보려던 참이었는데
    내가 debug와 release의 차이에 대한 개념이 부족한 것 같아서 다시 들여다봤다.

    구글 플레이 콘솔, Firebase 콘솔, 구글 클라우드 콘솔에서 쓰이는
    SHA-1 지문 키… 서명 키… 용도도 각각 달랐던…
    세 군데에서나 키를 관리해야 하고, 왔다 갔다 키 매칭하는 것도
    예전부터 너무 헷갈렸다 ㅠㅠ (난 본 투 비 서버 개발자다 ^ㅁ^)

    며칠이나 삽질을 한 건지 모르겠지만
    암튼 이제 debug와 release의 차이는 서명 키 차이라는 것을 확실히 알았다!

    개념을 바로잡고 생각해보니
    서명 키 차이인데 그럼 충돌 나는 키를 정리하고 에뮬레이터에서 release 모드로
    빌드해도 로그인이 되어야 하는 거 아닌가? 싶어서 시도해봤는데
    release 모드로는 역시 안 되는 거 아닌가 ㅠ

    더군다나 서명 키 충돌을 해결했다는 게,
    충돌 나는 클라이언트가 다른 프로젝트에 있어서 그 클라이언트를 삭제한 거였는데
    충돌 해결 후 release 빌드 버전에서도 로그인이 안 되고
    운영 앱에서도 로그인이 안 되는 사태가 발생했다…
    더 꼬였다 생각했지만 원리를 알고 나니 당황스럽지 않았다.
    30일 이내 복구가 가능했기에 삭제한 클라이언트를 복구하고 운영을 되돌려놨다.

    프로젝트 매칭이 안 됐던 클라이언트 키로 운영에서 로그인이 된다는 것은…
    코드 어딘가에서 분명 매칭해주고 있을 것…
    코드를 정리하고 release 모드로 테스트 배포를 진행했다.
    (로컬에서는 충돌을 해결하기 전까진 당분간 release 모드로 테스트가 불가할 듯 ^^)

    기존 앱에서도, release 모드로 배포한 앱에서도 구글 로그인은 잘된다 ^^
    (FCM null 문제도 해결…!!)

    이렇게 불안정한 상태로 약 2년 가까이 운영해오고 있었던,
    칼날 위를 걷는 듯한 처참하고 위태로운 나의 운영 상태를 돌아보게 되는 계기가 되었다…

    요즘 다시 우월에 애정을 쏟으면서 반성도 많이 되고…
    미안한 게 한두 가지가 아니다 ㅠ

    테스트 버전으로 AOS, iOS 배포 완료!! (이게 얼마만에 배포인지 ^,,^)


    오늘부터는 본격적인 실행 단계다.
    주말 내내 테스트 돌리고, 월요일에 운영 반영하고,
    앞으로는 주기적으로 점검 및 업데이트를 해야겠다.

    많이 아껴줄게, 다시 나랑 잘해보자 우월아 ❤️

  • Day 04 · 실행하기 위한 준비 (2)

    ‘우월’에 몰입하기 위한 순서로 가까이에 있는 굵직한 계획은 대충 이렇다.

    1. 명함 만들기
    2. 가입자 늘리기 활동을 위한 자동화 시스템 1개 만들어보기
    3. 자동화 시스템 돌아가는 동안 비즈니스 창업 미팅 다니기
    4. 변화된 bm에 따른 시스템 설계 변경
    5. 클라이언트, 백엔드 리팩터링

    위의 5번까지의 계획도 역시 ‘실행’해야 한다.
    모든 일은 역시 거저 되는 것이 없다 ㅎ

    일단 명함은 만들었으니
    스레드에 매일매일 가입자를 늘리기 위한 게시글을 작성하는 시스템을
    만들려고 하는데…

    우월 코드를 안 들여다본 지 너무 오래됐고
    현재 활성화된 사용자도 너무 없어서
    오늘 아침 갑자기!!!!
    구글 플레이 콘솔에 안 쓰는 프로젝트 삭제된다는 경고 메일이 왔다.

    덕분에 오늘 내가 해야 하는 일 우선순위가 바뀌었다.

    하지만 어차피 꼭 했어야 하는 일…
    마지막 배포 후 새로운 환경에서
    개발 환경 세팅만 해놓고 리팩터링을 하지 못한 채
    미루고 미뤄왔던 구글 세팅 문제를 우선 해결하기로 했다.

    6개월 전에 firebase, google cloud, google play console 등
    sha1 지문 키, 테스트 프로젝트와의 충돌…
    fcm 연동 등 꽤 복잡하게 꼬여 있는 설정들을 해결하지 못한 채
    방치해 뒀던 내 우월 프로젝트를 뜯어고칠 순간이 온 것이었다.

    회피하고 나태했던 나 자신을 반성하며
    최종 배포일에 쓰였을 main 브랜치로 시점을 되돌려
    거기서부터 차근차근 다시 풀어나가기 시작했다.
    (git도 혼자 개발한다고 너무 체계도 없고.. 어디까지 관리가 된 branch인지 모르겠다. 너무 오래 방치해 놓은 듯하다…. 난 창업자이기 전에 개발자인데 ^^ 정신 차려)

    일단 첫 번째 문제로는
    구글 클라우드 콘솔에 있는 여러 개의 프로젝트 중에서
    내 flutter 코드상 실제 운영에 어떤 sha1 지문을 쓰고 있는지를 분별하였는데,
    골 때리게도 android랑 ios가 쓰고 있는 sha 지문 키가 달랐다
    여기서 한 번 꼬였던 것…

    그래서 ios 설정 키와 aos 설정 키를 하나의 프로젝트에서 관리할 수 있도록
    통일되도록 먼저 수정하였고

    두 번째 문제로는
    fcm 키가 null이 반환되는 문제였다. (그래서 구글 로그인이 안 됐던 것, 그래서 구글 클라우드 콘솔, 플레이 콘솔, firebase 등 설정 키들을 여기저기서 재발급하고 끼워 맞추고.. 6개월 전에 헤매다가 현생 이슈로 덮어둔 기억이 가물가물하게 있다.)
    일단 코드에서는 fcm 키가 null이라서 구글 로그인이 안 되게 막혀 있어서
    구글 로그인이 안 되는 이슈로 착각했었던 거고
    fcm 키가 null이어도 google 로그인이 정상 200 반환을 한다면
    구글 로그인은 통과되도록 코드를 수정하였다.
    로그인은 잘된다. 이 문제는 해결했는데 그럼 fcm null은?
    이건 테스트에 시간을 많이 들였는데 일단 결론은 안드로이드 에뮬레이터 문제일 확률이 크다고 한다.
    왜냐하면 aos 운영에서는 fcm 키가 잘 들어오고,
    ios도 에뮬레이터 개발 환경 그리고 운영에서 전부 fcm 키가 잘 들어오기 때문이다.

    그래서 debug 모드로 apk 파일을 빌드한 다음
    남편 폰으로 설치해서 구글 로그인을 테스트해 볼 생각이다.
    (여기서 debug 모드로 테스트하는 이유는 debug 모드에서 쓰는 sha 지문 키가 한 달 내 삭제될 예정이라서! 오늘 아침에 구글로부터 받은 경고에 대부분은 걱정할 내용이 아니었는데 debug 모드에서 쓰던 지문 키는 로그인으로 업데이트 한 번 시켜 줘야 한다더라)

    그래서 debug 모드로 로그인도 성공하고, fcm도 null이 아니면
    에뮬레이터 문제인 것으로 종결할 예정이다!

    그리고 세 번째 문제…
    Apple, Google 스토어에 배포하기 전에 리팩터링하고 싶었던 부분이 있었는데,
    현재는 이벤트 페이지는 이미지를 앱에 포함시켜서 로딩하는 구조로 되어 있다.
    그런데 이벤트 페이지 디자인만 바뀌는데도 스토어에 늘 배포해야만 반영되는 게,
    그럴 때마다 배포를 해야 하는 게 너무 불편했다.

    그래서 s3 스토리지에 이미지를 올리고 그 URL을 서버에서 받아오는 로직으로
    수정할 것이었다. (DB에서 image url만 업데이트 치면 되도록)
    그러려면 db도 바뀌어야 되고 서버 코드도 바꿔서 배포해야 했고,
    클라이언트 코드도 api를 호출하는 로직으로 수정했어야 했다.

    이 내용을 수정하는 중에.. 치명적인 정말 믿기지 않는 대사건 발생!!!
    aws s3 스토리지를 사용하고 있는데
    s3에 접근 가능한 key가 public으로 노출되어 있었다……….. 오마이갓
    노출된 경로는………….
    git은 private 저장소였는데 docker image 저장소인 docker hub repository가 public이었던 것……. 오마이갓……….. 오마이갓!!!!!!!!!!!!!!
    누가 내 거 보겠어~ 하고 public으로 생각 없이 설정해 놨던 것 같은데
    그리고 소스에서도 .gitignore에 추가하지 않고 배포에 급급해서 그대로 docker image를 빌드했던 나 자신 똥멍청이……………..
    다행히 aws에서 s3 권한밖에 없었기 때문에 과금된 것은 없었고
    user들에게 피해 간 것도 없어 보인다. (jwt secret 토큰도 털렸다 ㅠㅠ)
    무서웠던 것은… 12일 전? 프랑크푸르트에서 접속 시도가 있었던 것…. (너 누구야)
    클로드에게 물어보니까 해킹 시도는 채굴식으로 계속 시도되고 있다고 한다…………….

    그래서 더 큰일 나기 전에 기본적인 보안 설정도 다 개선하였다.

    1. 사용 중인 전체 키 다시 받기
    2. 키 절대 저장소에 올리지 않기!!
    3. 키는 환경변수로만 취급한다!!!
    4. 아무리 테스트 프로젝트여도 이젠 저장소는 무조건 private!!!!!!!!!

    나.. 그래도 꽤 경력 있는 개발자인데
    이런 초보 같은 실수를……
    많은 배움과 깨달음이 있었던 하루였다.

    그렇게 우여곡절 끝에 여러 트러블슈팅을 마치고 무사히 운영 서버 배포와 테스트도 마쳤다.
    그리고 이벤트 페이지도 디자인을 새로이 단장하였다 ^ㅁ^

    Before
    After

    클로드 짱 ㅎㅅㅎ

  • Day 02 · 블로그 세팅하기 (1)

    Day 02 · 블로그 세팅하기 (1)

    오늘은 내 인생을 기록할 워드프레스 블로그를 세팅하는 날이다.
    일기를 매일 써본 적도 없는데, 인생을 기록하겠다는 다소 거창한 꿈을 가지고 짧더라도 꾸준히 한 번 작성해 보려고 한다.

    네이버냐, 워드프레스냐

    내 인생을 기록할 블로그를 두고 네이버와 워드프레스 중 어떤 걸로 시작할지 꽤 깊게 고민했다.
    (내가 애정하는 책 『세이노의 가르침』에서는 고민은 10분 안에 끝내라고 했는데…)

    처음엔 가벼운 일기로 생각해서 나만 보려고 네이버를 고려했다. 접근성이 좋고 세팅도 편리하니까.
    그런데 네이버 블로그에는 어제 산 jinyounghong.com 도메인을 연결할 수가 없었다.

    • 네이버: 접근성 좋고 세팅이 쉽다. 대신 내 도메인을 쓸 수 없다.
    • 워드프레스: 세팅이 까다롭다. 대신 내 이름으로 된 도메인 위에, 내 방식대로 쌓아갈 수 있다.

    ‘우월’과 함께 내 이름을 브랜딩하겠다고 도메인까지 샀는데, 그 이름을 두고 다른 곳에 기록을 쌓는 건 앞뒤가 맞지 않았다.
    마침 작년에 시작해 올해 말아먹은(애드센스 30번 탈락의 그) 워드프레스 호스팅이 만료까지 한 달 남아 있었다.
    미련 없이 초기화하고, 내 이름으로 된 도메인을 연결했다.

    오늘 세팅한 것

    1. 기존 경제 블로그 워드프레스 초기화
    2. jinyounghong.com 도메인 연결
    3. 메뉴 구성: Journal(Build · Business · Life), Product, About

    기록은 세 갈래로 나눴다. 우월을 만드는 이야기는 Build, 사업에 대한 고민은 Business, 그 사이의 일상과 생각은 Life.

    역시 워드프레스는 세팅하는 데 까다롭고 어려웠다. 그래도 한 번 틀을 잡아두면, 앞으로는 쓰는 일에만 집중할 수 있을 거라 믿는다.


    미미한 시작의 첫걸음

    오늘도 작게나마 내 인생 설계도를 따라 미미한 시작의 첫걸음을 디뎠다.
    확실히 지난주 월요일보다 낭비하는 시간이 줄었다.

    거창한 목표보다 중요한 건, 매일 한 줄이라도 남기는 것.
    기특하고 뿌듯하다. 내일도 화이팅.