그 기술 블로그 AI로 쓴거 같던데

요즘 기술 블로그 글을 보다 보면, 어딘가 익숙한 말투가 스며든 글들을 종종 마주친다.
문장 구조, 표현 방식, 정중하면서도 기계적인 흐름까지 아, 이건 AI가 작성했구나.

익숙함이 낯섦을 만들고, 낯섦이 의심을 만든다.

물론 그 언어를 빌려올 수는 있다.
어쩌면 나보다 더 유창하게 더 논리적으로, 더 친절하게 설명해주는 도구니까
하지만 그걸 고스란히 복사해서 붙여 넣는다면 그건 ‘기술 블로그’라기보다 그냥 ‘출력 로그’가 아닐까 생각한다.

나는 기술 블로그를 내 생각의 누적이라고 여겨왔다.
서툴더라도 내가 직접 부딪히며 정리해온 언어들이 담겨 있어야 한다고 생각한다.
그래서일까,
AI가 쓴 듯한 매끄러운 글을 보면 오히려 매력보다 거리감이 느껴지곤 한다.

그런데 또 한편으로는,
“이런 생각도 언젠가는 고리타분해질까?“라는 의문이 든다.
세상이 이렇게 빠르게 변하는데 그 변화 속에서 끝까지 지키려는 건 신념일까 아집일까

나도 이런 고집을 내려놓아야 할 날이 올지도 모르겠다
내 이런 생각들도 언젠간 그런 순간들이 다가 오겠지.

뭘 만들어야 할지 모르겠다고요?

개발자라면 한 번쯤 이런 고민 해보셨을 거예요.

“독창적인 아이디어가 없는데 어떡하지?”

“남들이 다 만든 것 같은데 난 뭘 만들어야 하나?”

특히 사이드 프로젝트를 시작하려는 분들이 자주 부딪히는 벽이죠.

새로운 것? 그게 정말 필요할까요?

새로운 것을 만들어야 한다는 강박에서 벗어나세요.

혹시 이런 생각해보신적 있나요?

• “완전히 새로운 걸 만들어야 해”

• “남들이 안 만든 걸 만들어야 해”

• “획기적인 아이디어가 필요해”

사실 세상에 완전히 새로운 건 거의 없다고 생각해요.

애플의 아이폰도 기존 휴대폰을 ‘더 편하게’ 만든 거였고, 페이스북도 하버드 학생들의 소통 플랫폼을 ‘더 넓게’ 만든 거였죠.

성공적인 리빌딩 사례들

카카오톡의 시작

기존 문자메시지(SMS)의 불편함을 개선했죠.

“문자 요금이 너무 비싼데?”, “사진 보내기가 불편한데?” 이런 불편함에서 시작된 개선이 지금의 카카오톡이 되었어요.

배달의민족

기존 배달음식점 전단지를 모바일로 옮긴 것에서 시작했어요.

전단지 보관의 불편함, 가게 전화번호 찾기의 번거로움을 해결했죠.

또 다른 예시로는 넷플릭스는 DVD 대여점의 불편함을 개선했고, 에어비앤비는 숙박 예약의 새로운 방식을 제시했죠.

왜 리빌딩이 더 좋을까요?

1. 검증된 시장

• 이미 사용자가 존재함

• 시장의 크기를 예측할 수 있음

• 수익 모델이 검증되어 있음

2. 명확한 타겟

• 누가 사용할지 알 수 있음

• 어떤 문제를 해결해야 할지 분명함

• 기존 사용자의 피드백을 참고할 수 있음

3. 실현 가능성

• 기술적 구현 방법을 참고할 수 있음

• 필요한 기능을 명확히 알 수 있음

• 개발 범위를 구체적으로 정할 수 있음

일상 생활에서 불편함을 찾기

저같은 경우에는 게임을 좋아하던 시절이 있었어요.

그 중에서도 "서든어택" 이라는 FPS게임을 좋아했는데요. 문제는 이 게임에서 불법 프로그램을 사용하는 유저가 너~~무 많았단 거죠.

그런데 여기서 문제되는 점이 서든어택 측에서도 열심히 불법프로그램 사용자들을 정지한다고 하지만, 여전히 걸리지 않는 불법프로그램 사용자들이 너무 많았다는 거예요.

정지를 당하지 않는 불법프로그램 사용자들이 너무 많아지면서, 누가 봐도 저 유저는 불법프로그램 사용자인데 왜 정지를 안당하지? 하는 빡침이 가슴 깊은 곳에서 몰려오는거 있죠?

그러다 어느날 문득 그런 생각이 들었어요.

우리가 그냥 불법 프로그램 사용자를 서버에 등록해서 유저를 검색 할 때, 이 유저가 서버에 불법프로그램으로 등록되어 있는 유저인지 알려주자.

그렇게 서버 개발자분과 컨택해서 바로 뚝딱뚝딱 만들었습죠.

기능은 최대한 심플해야 했어요. 사용자 입장에서 기능이 너무 많거나 복잡하면 불편함을 느낄 수 있으니까요.

• 닉네임 검색

• 실시간 검색 순위

• 제보 하기

사실 불법프로그램 의심 사용자가 더 많은 것도 사실이라 의심되는 유저를 등록할 수는 없었어요.

그래서 이걸 다른 방법으로 접근했어요.

"실시간 검색 순위를 만들어서 자연스럽게 검색이 많이 되는 유저가 의심되게 해보자"

이렇게 심플한 기능만을 가진 MVP를 1주일만에 만들어서 배포를 했어요.

결과는

2024.10 기준 바이럴 마케팅으로만 노출수 4천회↑ 실사용자 90명↑

배포하고 1달도 안되서 일어난 일이였어요.

새삼 불편함을 느낀 유저가 생각보다 많았구나 했습죠.

근데 제가 아무래도 iOS 개발자다 보니 앱스토어에만 배포했어야 했어요.

안드로이드까지 지원했으면 더 좋은 결과를 볼 수 있었을텐데 하는 아쉬움도 존재했어요.

그래서 반응을 조금 더 지켜보고 안드로이드도 지원할 계획에 있어요.

마치며

때로는 작은 개선이 큰 혁신이 될 수 있다고 전 믿어요.

완벽하게 새로운 것을 만들겠다는 부담감은 내려놔도 괜찮다고 생각해요.

대신 여러분이 실제로 겪은 불편함, 그리고 그것을 해결할 수 있는 방법에 집중해보는건 어떨까요?

시작이 막막하시다구요? 지금 당장 사용 중인 앱을 열어보세요.

분명 “이렇게 하면 더 좋을 텐데…“ 라는 생각이 떠오를 앱이 있을 거예요.

그게 바로 여러분의 첫 프로젝트가 될 수 있답니다. 😊

팀 리더가 못미더우시다고요?

팀을 이끌다 보면, 리더가 항상 모든 결정을 옳게 내릴 수 없다는 사실을 종종 깨닫게 됩니다.

그렇다고 해서 팀 리더에 대한 신뢰가 부족하다고 느껴질 때, 팔로워로서 어떤 자세를 취해야 할까요?

요새 화제라면 화제인 흑백요리사를 보고 있던 와중, 에드워드 리 셰프가 제가 생각하는 팔로워십의 완성형이 보여서 기록해두고자 글을 쓸려고 합니다.

1. “기능에 대한 도전이 없어서는 안 된다.”

개발 프로젝트에서 리더의 결정은 종종 팀의 방향을 크게 좌우합니다.

하지만 리더의 결정이 항상 정답은 아닙니다.

기능 구현에서 뭔가 부족하다고 느낄 때, 팔로워는 침묵해서는 안 됩니다.

에드워드 리 셰프가 말했듯이, 가리비 요리가 심심하다고 생각하면서도 아무도 말하지 않았던 상황처럼 팀원들은 더 나은 방향으로 이끌 수 있는 의견을 적극적으로 제시해야 합니다.

개발에서도 작은 피드백이 큰 개선을 가져올 수 있습니다.

2. “리더가 고집스러울 때도 있지만, 괜찮아요.”

때때로 리더는 자신의 의견을 고집하며 팀의 아이디어를 받아들이지 않을 때가 있습니다.

그럴 때는 팔로워로서 한 발 물러서서, 리더의 결정을 신뢰하고 따르는 것이 중요합니다.

모든 상황에서 동의하지 않더라도, 팀의 목표를 위해 리더의 선택을 존중하고 함께 나아가는 자세가 필요합니다.

개발 프로젝트에서 진정한 팔로워십은 단순히 리더의 결정을 따르는 것이 아니라, 적극적으로 의견을 내고, 대안을 제시하며, 리더가 최종 결정을 내렸을 때 그 결정을 믿고 따르는 과정을 포함합니다.

이러한 과정은 팀의 성과를 더욱 높여주며, 리더와 팔로워 간의 신뢰를 더욱 단단하게 만들어줍니다.

개발이든 요리든, 중요한 것은 팀 리더와 팀원이 함께 소통하고 발전해 나가는 방식입니다. 리더십은 비판적이고 침묵하는 팔로워십이 아니라, 참여적이고 생각하는 팔로워십에 의해 더욱 강해진다고 믿습니다.

3. "팀 리더를 만들었다면, 팀 리더를 믿어야 합니다."

리더가 된 사람에게는 팀의 방향을 설정하고 의사결정을 할 권한이 주어집니다.

팀원들은 리더가 내리는 결정을 신뢰하고 따라야 합니다.

만약 리더가 팀의 기대를 충족시키지 못한다고 생각되어도, 일단은 리더의 판단을 존중하는 것이 필요합니다.

그를 믿고 따라주는 것이 그 역할의 중요성을 인정하는 첫 번째 단계입니다.

팀 리더가 모든 상황에서 완벽한 결정을 내리기는 어렵습니다.

하지만 그럼에도 불구하고, 리더에게 신뢰를 부여하는 것은 리더십이 제대로 발휘될 수 있는 환경을 만듭니다.

팀이 리더를 신뢰하지 않으면 리더는 자유롭게 결정을 내리지 못하고, 팀의 효율성도 떨어질 수 있습니다.

신뢰는 리더가 성공적으로 팀을 이끌어갈 수 있는 핵심 토대입니다.

• 리더의 결정은 팀의 방향을 좌우하지만, 항상 정답은 아니다.
  

• 기능 구현에 부족함을 느낀다면, 팀원은 적극적으로 의견을 제시해야 한다.
  

• 리더가 고집을 부리더라도, 팔로워는 그 결정을 신뢰하고 따르는 자세가 필요하다.
  

• 진정한 팔로워십은 의견 제시와 리더의 결정을 신뢰하는 과정을 포함한다.
  

• 리더십은 침묵이 아닌 참여적이고 생각하는 팔로워십에 의해 강화된다.
  

• 팀 리더를 만들었다면, 그의 결정을 신뢰하고 따르는 것이 중요하다.
  

• 리더가 완벽하지 않아도, 신뢰가 리더십의 핵심 토대가 된다.

요리 경연 프로그램을 보다가 제가 가져야 할 마인드셋을 배운거 같아 기분 좋은 하루가 될 거 같네요.

나도 저런 사람이 되어야겠당.

앱스토어 인기차트 10위 달성 기념 회고

어쩌다보니 운 좋게 앱스토어 개발자 부문 인기차트 10위에 들었어요 🥲

앱스토어 : https://apps.apple.com/kr/app/gitboost/id6708242399

제 개인 앱 배포를 기념하면서, 그 과정에서 얻은 배움을 조심스레 끄적여 볼게요.

너무 배포하고 싶었던 프로젝트 중 하나

GitBoost는 GitHub API를 활용하여 사용자의 GitHub 활동 데이터를 시각화하고 점수를 매겨주는 간단한 기능을 가지고 있어요.

이 아이디어는 사실 예전 팀 프로젝트에서 처음 시작했습니다.

프로젝트는 성공적으로 끝났지만, 마음 한 켠에는 항상 배포를 못한 아쉬움이 남았어요.

그래서 다짐하게 됩니다.

“나중에 내가 이걸 개인 앱으로 완성해서 꼭 배포해야지.“

앱스토어 심사 거부 9번

팀 프로젝트가 끝난 이후, 여유가 생겨 개인적으로 이 앱을 개발하기 시작했지만 예상치 못한 어려움들이 연달아 찾아왔어요.

처음에는 기술적인 문제들을 해결하는데 많은 시간이 걸렸습니다.

반년 전에 진행했던 코드가 기억이 날리 있나요.. 그냥 새로 엎고 다시 시작했어요.

코드 퀄리티는 반만 챙겨가면서 무조건 빠른 배포를 목표로 삼고 개발했던거 같아요.

그 와중에 앱스토어에 배포하려는 과정도 쉽지 않았는데요…

당일에만 7번의 심사를 진행했던 악몽의 순간..

총 리젝을 9번 정도 당했어요.

처음 리젝 3번까지는 괜찮았어요. 제가 실수하거나 빼먹은 부분이 있어서 그런거니 하면서 고치고 또 고치길 반복했어요.

하지만.. 문제는 깃허브 로그인과정에서 일어났는데요..

애플의 심사관은 회원가입을 하지 않습니다.

그래서 무조건 데모 계정이나, 테스트용 계정을 기입 해야 하는데요.

문제는 2023년도 말 부터 깃허브 정책이 새로운 기기에서 로그인 할 시에 무조건 이메일 인증을 요구하도록 변경된 것..

그래서 심사 도중에 계속 로그인 관련 인증코드를 요구한다라는 내용의 심사 메세지를 받게 되었습죠.

무조건 해결해 어떻게든 해결해!!!

앱스토어 배포는 처음이 아니지만 이런적은 처음이라 너무 당황스러웠어요 ㅠㅠ

마음을 다잡고 시도할 수 있는 방법들을 시도해보기 시작했어요.

제가 했던 시도했던 방법은 총 5가지에요

1. 무작정 재심사 요청

무한 리젝 츠쿠요미 발동해서 포기

2. CA 개발자 문의센터에 전화요청

심사중에 이메일 인증번호를 요청할 줄 알았지만.. 깃허브 계정을 우회하거나 데모모드를 만들라고 답변을 받아 포기

3. 이메일 인증 푸시알림이 도착할 때 연락을 주시면 인증 코드를 전달해 드린다는 심사 메모를 남기기

응 안돼 돌아가

4. 로그인 진행해서 앱의 전체적인 기능을 보여주는 영상을 따로 첨부

예전엔 가능했다고 하던데 요즘은 심사 정책이 빡세져서 이것마저 리젝

우여곡절 끝에 심사 통과

솔직히 4번까지 진행하면서 많이 지쳤어요.. 4일간 심사 요청을 하고 캘리포니아 애플 개발자 고객 센터에 연락도 해보면서 그냥 배포하지 말까란 생각도 내심 했던거 같아요 ㅋㅋ

자포자기 하는 심정으로 그냥 문의 했을 때 했던 전달 받았던 방법을 시도해보자 해서 마지막 시도를 했어요.

"앱스토어 리뷰를 위한 메뉴를 따로 만들어서 관련 코드번호를 입력시 더미데이터를 집어넣은 화면을 보여주게끔 화면을 제작해보자"

솔직히 더미데이터를 집어넣는 생각을 안했던건 아닌데요.

왜 안했냐 하면.. 솔직히 너무 귀찮기도 했고.. 기능이 추가될 때마다 더미데이터를 계속 생성해줘야하는 것도 일이라고 생각했었거든요.

어쨋거나 부랴부랴 더미데이터를 집어넣어서 최대한 사용자 경험을 해치지 않게끔,

깃허브 연동하는 마지막 페이지 오른쪽 상단에 쬐끄맣게 for appstore review 메뉴를 따로 만들었어요.

그래서 코드를 제출하면 더미데이터를 집어넣은 기능을 보여주는 뷰로 전환되게끔 구현했어요.

다시 한번 온 우주의 마음을 담아 심사를 제출했더니 그제서야 심사 승인을 해줬더라죠..

스릉흔드.. 애쁠..

운 좋게 앱스토어 인기차트 10위

9번의 리젝 끝에 드디어 앱이 배포되었을 때, 그 자체로도 큰 성취감을 느꼈지만 더 놀라웠던 건 제 앱이 앱스토어 개발자 부문 인기차트 10위라는 귀한 경험을 한 것이였습니다.

처음엔 이게 무슨일인가 어안이 벙벙했지만,, 이 순간이 오기까지 제가 쏟아부은 노력과 시간을 생각하면서 돌이켜보니, 그 모든 과정이 너무 보람있게 다가왔어요.

언제 또 이런 귀한 경험을 해보겠냐란 생각으로 지인분들한테 자랑 또 자랑 했어요 ㅋㅋ…

끝까지 가면 내가 다 이겨✊

이번 프로젝트를 통해 많은 것을 배운거 같아요.

가장 큰 깨달음은 지치지 않고 꾸준히 개선하려는 노력이 얼마나 중요한가 였던거 같네요.

리젝을 거듭하면서 좌절할 때도 있었지만, 그때마다 하나씩 문제를 해결하고 나아가면서 배포를 이뤄낼 수 있었습니다.

무엇보다 이번 경험이 저에게 큰 자신감을 주었기 때문에, 앞으로 더 재미있는 앱을 만들 수도 있지 않을까 라는 생각을 해봤던거 같아요.

마지막으로! 저를 믿고 응원해준 팀원, 지인분들에게 무한 감사드린다는 소리를 전하고 싶네요.

이번 성과는 제 개인적인 노력만이 아닌, 주변 사람들의 지지와 도움 덕분이라고 생각해요.

앞으로도 더 좋은 모습으로 발전해 나갈 것을 약속드리며 다음에 더 재미있는 회고로 찾아올게요!!

여러분들도 끝까지 가면 내가 다 이긴다는 마인드로 아자아자 화이팅 입니다!!

험난했던 앱스토어 심사 4일간의 여정

요즘들어 더욱이 더 험난해진 것 같은 앱스토어 심사를 마치고 배포했습니다.

이미 배포 경험은 있었기에, 이번에도 솔직히 심사 원트에 끝날 줄 알았어요..

자신 넘치게 심사를 넣어봤지만 4일동안 3번의 리젝을 당한 회고를 적어보려고 해요.

첫번째 리젝

대충 번역해보면

첫번째, 지원url이 올바르지 않다.

두번째, 미리보기에 등록된 것과 다르게 데이터가 로딩되지 않는다.

여기서 살짝 테스터 역량을 느꼈는데요..

이전 배포에 지원url에 그냥 깃허브 레포 주소를 올려서 통과되었는데, 이번엔 거절당한것..

그래서 에이 다음 심사 때는 넘어가주겠지~ 하고 데이터 로딩 관련 문제는 아카이빙이 잘못됐나? 하고 아카이브 다시 한 뒤 빌드에 추가한 후 다시 심사를 넣었습죠.

두번째 리젝

허허 제 오만함은 리젝을 피해갈 수 없었습죠..

또다시 지원url이 올바르지 않다는 소리와, 여전히 데이터가 로딩되지 않는다고 심사결과가 나온건데요.

그래서 다른 분이 올리신 지원url을 조금 찾아봤는데, 구글독스로 설문지를 만들어서 지원url에 올리셨더라구요!

오 그래서 참고해서 똑같이 제작해서 만들어서 지원url을 수정했어요.

참고한 링크 : https://forms.gle/G4pUZvjHP3gyKNe39

근데 왜 여전히 데이터 로딩이 안된다고 하는건지 여전히 의문이였어요.

아카이브 하면서 잘못됐나? 하면서 아카이브도 다시해보고, 실기기 테스트와 시뮬 테스트까지 해봤는데 정상 작동했거든요.

테스터 빌드 환경이 안좋은가..? 하면서 다시 아카이브 빌드 추가하고 심사추가를 해줬어요.

세번째 리젝

리젝을 당했지만 드디어 지원url 수정해달라는 멘션이 사라졌어요.

하지만 도통 알 수 없는 데이터 로딩이 불가하단 소식..

이게 도대체 무슨일인가 싶어 백엔드 분께 서버 로그 확인해달라고도 해보고..

자체적으로 테스트도 계속 돌려봤지만 도저히 이유를 알 수 없었습죠..

대체 왜지..? 하면서 프로젝트를 뒤적뒤적 거려보는데..

ㅋㅋㅋ ㅋㅋ ㅋㅋㅋ

바보같이 config 파일에 debug에만 hostvalue와 portnumber를 적어두고 release에는 적어두지 않았던것..!!!

진짜 이런 사소한 실수 때문에 몇일을 날려먹은건지 너무 속상했어요..

ㅋㅋ 엄청난 잔소리를 들었다고 한다..

이후 release까지 수정해주고 다시 아카이브 한 뒤 심사에 추가해줬습죠.

결과

그렇게 당당히 심사를 통과했다고 합니다..

별것도 아닌 이슈로 4일동안 끙끙 앓아댄게 너무 화딱지 났어요..

이번에 하면서 느낀건데

오만이 화를 부르는거 같았어요.. 항상 겸손겸손..해야지

다시한번 체크해보고 심사넣기..

다음부턴 이런 사소한 실수 없이 원트에 심사 통과 되길 바라면서.. 다음에도 재밌는 소식 가져올게요!