조준장 개발자 생존기

서버를 되돌리는 데 20분쯤 걸렸고, 앱은 스토어 심사를 거쳐야 했기 때문에 바로 대응할 수가 없었다. 그래서 서버만 배포 전으로 돌아가고, 앱은 배포되었던 버전으로 사용자가 이용할 수밖에 없었다.그런데 아무 일도 일어나지 않았다. 서버에서는 관련 API가 404와 500을 내려주기 시작했는데 사용자에게 발생한 이슈는 없었다. 폴백 코드를 따로 짠 적이 없는데도.이 글은 지금까지 클라이언트가 들고 있던 상태를 서버로 옮기려는 개발자를 위해 작성했다.무엇을 바꾸고 있었나우리 서비스는 담은 메뉴가 오래 남아 있지 않았다. 매장을 벗어나거나 앱을 종료하면 담았던 메뉴를 제거했다. 즉, 장바구니가 비워졌다.메뉴 정보를 화면 사이에서 Intent로 넘기는 구조였기 때문이다.미리 밝혀두면 이 글에 나오는 코드는 전..

취업 전 다양한 프로젝트와 프리랜서 활동, 그리고 네이버 부스트캠프와 우아한테크코스를 거치며 나만의 개발 철학을 차곡차곡 쌓아왔다고 자부했다. 하지만 현업의 문을 열고 마주한 가장 큰 변화는 내가 배운 '코딩' 그 자체가 아니라, 바로 AI 주도 개발(AI-Driven Development)이라는 거대한 흐름이었다.이번 글에서는 신입 개발자로서 AI와 함께 협업하며 느낀 당혹감과 깨달음, 그리고 우리가 앞으로 가져야 할 태도에 대해 이야기해보려 한다. 정답을 제시하기보다는, "아, 이 사람은 요즘 이런 생각을 하며 개발하고 있구나" 하는 마음으로 편하게 읽으면 좋을 것 같다.AI, '정답지'에서 '파트너'로대학생 시절부터 ChatGPT나 뤼튼 같은 AI를 종종 활용해왔다. 하지만 당시의 나에게 AI는 '..

여러 개발자들에게 테스트 코드에 대해 물어보면, 의외로 비슷한 대답이 돌아온다.“우리 회사에는 테스트 코드가 없다”는 말이다.이유는 제각각이다.필요성을 느끼지 못해서라는 사람도 있고, 바쁘다 보니 작성할 여유가 없었다는 사람도 있다.솔직히 말하자면, 나 역시 한동안은 후자에 가까웠다.입사 초기에 팀에는 안드로이드 개발자 한 분만이 중요하다고 판단되는 로직에 한해서 테스트 코드를 작성해두고 있었다. 다만 내가 담당했던 Feature 영역에서는 Repository, UseCase, ViewModel 등 중 어느 것도 “반드시 테스트가 필요하다”고 느껴지지 않았다. 그 당시의 나는 그렇게 판단했다.생각이 바뀌게 된 계기는, 기존에 작성된 코드를 기반으로 새로운 기능을 구현하게 되었을 때였다.Feature 하나..

사라진 결제의 행방을 추적하라사건은 이러하다.그날도 평소처럼 평화로운 오후였다.사용자는 결제 화면에서 신중하게 결제 수단을 고르고, 한껏 기대에 부풀어 ‘결제하기’ 버튼을 눌렀다.이제 곧 결제가 완료되고, 상품권이 발송될 터였다.그런데, 그때였다.은행 앱으로 연결된 순간, 우리의 앱은 잠시 무대 뒤로 퇴장했다.잠시면 돌아올 줄 알았다. 하지만 그것은 그의 마지막 기억이었다.사용자는 은행 앱에서 오랜 시간 머물렀다.카드를 선택하고, 비밀번호를 입력하고, 그러나 마지막 순간에 결제를 취소했다.그리고 돌아왔을 때, 앱은 여전히 그 자리에 있었다.하지만 무언가 달랐다.화면은 익숙했지만, 기억은 사라져 있었다.결제 금액도, 선택한 선물 정보도, 입력했던 메시지도 모두 흔적이 없었다.마치 새로 설치한 앱처럼, 모든..

Jetpack Compose로 동영상 UI를 만들기 시작했을 때는 단순히 화면에 영상만 잘 나오면 된다고 생각했다. 그러나 구현을 조금씩 구체화할수록, 예상하지 못했던 문제들이 하나둘씩 고개를 들기 시작했다.특히 요즘 유행하는 세로형 숏폼 콘텐츠 앱을 만들다 보면 이 어려움을 누구나 실감할 것이다. 사용자는 화면을 끊김 없이 스크롤하고 싶어 하고, 개발자는 각 화면마다 ExoPlayer를 안정적으로 관리해야 한다. 동시에 메모리 누수 없이 플레이어를 재활용하는 과제까지 따라붙는다.결국 세 가지 조건이 충돌한다.스크롤은 매끄러워야 하고, 영상은 자연스럽게 재생돼야 하며, 앱은 절대 크래시가 나면 안 된다. 문제는 이 세 가지가 서로 얽혀 있다는 점이다. 하나를 잡으면 다른 하나가 삐걱거리는 식으로 개발자를..

안드로이드 개발을 하다 보면, UI에서 단 한 번만 실행되어야 하는 이벤트를 처리해야 하는 상황이 종종 발생한다.예를 들어, 사용자에게 Toast 메시지를 한 번만 띄우거나, 특정 조건이 충족되었을 때 화면 이동을 한 번만 수행해야 하는 경우가 그렇다.하지만 안드로이드의 생명주기(Lifecycle) 특성과 ViewModel, LiveData의 동작 방식 때문에, 이 단순해 보이는 요구조차 쉽게 구현하기 어렵다.이번 글에서는 안드로이드에서 일회성 이벤트를 처리하는 다양한 방법을 살펴보고, 각각의 장단점을 정리하려고 한다.또한 어떤 상황에서 어떤 방법이 적절한지 함께 고민해보자.1. LiveData일반적으로 LiveData는 데이터가 변경될 때, 활성화된 옵저버에게만 업데이트를 전달한다.하지만 옵저버가 비활..

개요Compose를 사용하다 보면, 어떤 Composable은 일반 함수로, 또 어떤 Composable은 inline 함수로 정의된 것을 확인할 수 있다.예를 들어 Box 컴포저블도 다음과 같이 두 가지 형태로 제공된다.@Composablefun Box(modifier: Modifier) { Layout(measurePolicy = EmptyBoxMeasurePolicy, modifier = modifier)}@Composableinline fun Box( modifier: Modifier = Modifier, contentAlignment: Alignment = Alignment.TopStart, propagateMinConstraints: Boolean = false, c..

사건의 발단 🕵️백그라운드 스레드에서 Room DB를 통해 Reservation(예약 정보)이라는 데이터를 받아오고, 해당 데이터를 UI에 렌더링하기 위해 데이터 바인딩을 사용했다. 이 과정에서 BindingAdapter를 활용하여 UI를 업데이트했다.그러나 10번에 3번 꼴로 데이터 바인딩 프로퍼티가 null인 경우가 발생하여 앱이 크래시되는 문제가 있었다. 이러한 문제는 바인딩 프로퍼티가 누락되어 발생한 것으로 보인다. (아마 7번은 운 좋게 데이터 바인딩이 성공된 것으로 보인다)코드는 다음과 같다.// presenter 코드override fun loadReservation(id: Long) { thread { reservationRepository.findReservation(..

탐험 개요고차함수를 활용하기 위해 컬렉션 함수 내부 코드를 보던 중 inline을 발견!inline이 뭐지 코드 줄을 안으로 뭐 하는건가???.. 일단 코틀린에서 제공하는 고차함수 API에서 쓰이는 것으로 확인되니 장점이 있겠지??그래서 inline이 뭔데?코틀린 공식문서를 보면 다음과 같이 설명한다."고차함수를 사용하면, 부가적인 메모리 할당으로 인해 메모리 효율이 안 좋아지고, 함수 호출로 인한 런타임 오버헤드가 발생하게된다. 그러나 람다식을 inline으로 처리하면 이러한 종류의 오버헤드를 제거할 수 있다."런타임 오버헤드가 뭔데?런타임 오버헤드는 프로그램이 실행되는 동안 추가적으로 발생하는 비용이나 부담을 의미한다. 이는 프로그램이 실행되는 동안 발생하는 여러 가지 작업들에 대한 처리 시간이나 자..

💡 코틀린이란? 코틀린은 intellj, pycharm 등 IDE 툴을 만든 젯브레인(jetbrains)에서 개발한 언어이다. 2011년에 발표되었고, 코틀린섬 이름으로부터 지어졌다. Google I/O 2017에서 안드로이드의 공식 언어로 채택되다. 더 자세한 내용은 다음 링크를 통해 알아보자. [kotlin] 코틀린이란 무엇인가? 💡 코틀린이란? 코틀린은 intellj, pycharm 등 IDE 툴을 만든 젯 브레인(jetbrains)에서 개발한 언어이다. 2011년에 발표되었고, 코틀린섬 이름으로부터 지어졌다. Google I/O 2017에서 안드로이드의 공식 언 fre2-dom.tistory.com 그럼 이번에는 코틀린의 기본적인 문법에 대해서 알아보자. 💡 기본 문법1 : val, var // ..