TDD를 처음 들으면 테스트를 먼저 작성한다는 말이 가장 크게 남는다. 그래서 TDD를 단순히 테스트 개수를 늘리는 방법으로 이해하기 쉽다. 하지만 TDD의 중심은 테스트 파일을 많이 만드는 것이 아니라, 작은 기대 동작을 먼저 고정하고 그 기대를 만족하는 코드를 조금씩 자라게 만드는 개발 방식에 가깝다.예를 들어 쇼핑몰의 배송비 정책을 만든다고 해보자. 5만 원 이상이면 무료 배송, 그 미만이면 3천 원이라는 규칙은 단순해 보인다. 그런데 여기에 할인, 쿠폰, 회원 등급, 도서산간 배송비가 붙기 시작하면 조건문은 금방 커진다. 이때 테스트 없이 구현부터 시작하면 어떤 금액을 기준으로 무료 배송을 판단해야 하지 같은 정책 질문이 코드 안에 섞인다.TDD는 이 질문을 테스트로 먼저 드러낸다. 테스트가 실패..
주문 조회 API를 하나 만든다고 가정해 보자. 처음에는 빠르게 동작하는 코드가 목표라서 컨트롤러 안에 모든 처리를 몰아넣었다. 요청 파라미터를 읽고, SQL을 만들고, 권한을 대충 확인하고, 결과를 JSON으로 내려준다.문제는 이런 코드가 처음부터 크게 망가져 보이지 않는다는 점이다. 테스트 환경에서는 정상 주문 번호를 넣으면 잘 조회된다. 하지만 시간이 지나면 조건이 늘어나고, 예외가 추가되고, 권한 규칙이 바뀌면서 코드가 점점 읽기 어려워진다. 더 위험한 점은 읽기 어려운 코드가 보안 문제를 숨기기 쉽다는 것이다.@GetMapping("/orders")public ResponseEntity orders(HttpServletRequest request) throws Exception { Stri..
파일을 저장한다고 하면 보통 파일 이름과 내용이 디스크에 저장된다고 생각하기 쉽다. 그런데 운영체제 관점에서 보면 파일 이름과 파일 내용은 같은 곳에 붙어 있는 정보가 아니다. 파일 이름은 디렉터리 안의 항목으로 관리되고, 파일의 크기, 권한, 소유자, 링크 수, 데이터 위치 같은 정보는 inode 같은 메타데이터 구조가 맡는다.그래서 파일 시스템을 이해할 때는 파일 하나가 어디에 저장되는가보다 이름을 어떻게 찾아서 파일의 본체에 도달하는가를 따라가 보는 편이 좋다. 이 글에서는 파일 생성, 이름 조회, 링크 생성, 삭제 흐름을 따라가며 디렉터리 엔트리, inode, 데이터 블록의 역할을 나눠 본다.용어 정리파일 시스템: 저장 장치 위에서 파일과 디렉터리를 어떤 구조로 배치하고 찾을지 정하는 방식이다. ..
운영체제의 가상 메모리는 프로그램이 사용하는 모든 페이지를 항상 물리 메모리에 올려 두지 않는다. 메모리는 제한되어 있고, 프로그램은 그보다 큰 주소 공간을 사용할 수 있기 때문이다. 그래서 어떤 페이지에 접근했는데 그 페이지가 메모리에 없으면 페이지 폴트가 발생하고, 운영체제는 필요한 페이지를 메모리로 가져와야 한다.문제는 메모리에 빈 프레임이 없을 때다. 새 페이지를 넣으려면 기존 페이지 중 하나를 골라 내보내야 한다. 이때 누구를 내보낼 것인가를 정하는 규칙이 페이지 교체 알고리즘이다.이번 글에서는 FIFO, LRU, LFU, Optimal을 따로 외우기보다, 하나의 참조열을 끝까지 따라가며 각 알고리즘이 어떤 페이지를 희생자로 고르는지 비교한다.용어 정리페이지: 가상 메모리를 일정한 크기로 나눈 ..
프로세스는 각자 독립된 가상 주소 공간을 가진다. A 프로세스의 변수 주소 0x1000과 B 프로세스의 변수 주소 0x1000은 숫자가 같아 보여도 같은 메모리를 가리킨다고 볼 수 없다. 운영체제는 프로세스마다 주소 공간을 분리해 두고, 한 프로세스가 다른 프로세스의 메모리를 마음대로 읽거나 쓰지 못하게 막는다.이 격리는 안전하다. 한 프로세스의 버그가 다른 프로세스의 메모리를 바로 망가뜨리지 못하고, 권한이 없는 데이터 접근도 차단된다. 하지만 프로그램은 혼자만 일하지 않는다. 셸에서 ls | grep txt처럼 한 프로세스의 출력이 다른 프로세스의 입력으로 들어가기도 하고, 서버 프로세스와 워커 프로세스가 요청을 주고받기도 한다. 격리된 프로세스들이 데이터를 주고받으려면 운영체제가 중간에 통로를 만들..
Android 앱을 빌드하면 Kotlin이나 Java 소스 코드가 그대로 기기에서 실행되는 것은 아니다. 소스 코드는 JVM 바이트코드 단계를 거친 뒤 DEX 형식으로 변환되고, 기기에서는 Android Runtime, 즉 ART가 그 코드를 실행한다. 오래된 Android 버전에서는 Dalvik이 이 역할을 맡았고, 현재 Android는 ART를 사용한다.이 흐름을 모르면 "DEX 파일은 무엇인지", "d8은 왜 필요한지", "ART와 Dalvik은 어떤 관계인지", "JIT와 AOT 컴파일은 앱 실행과 무슨 관련이 있는지"가 모두 따로 논다. Android의 실행 모델은 소스 코드에서 시작해 DEX, 런타임, 컴파일 전략으로 이어지는 하나의 파이프라인으로 보는 편이 이해하기 쉽다.이미지 출처: And..
같은 앱이라도 개발 서버를 바라보는 debug APK, 운영 서버를 바라보는 release APK, 무료 버전과 유료 버전, 고객사별 로고가 다른 버전을 따로 만들어야 할 때가 있다. 이때 매번 코드를 복사해서 프로젝트를 나누면 유지보수가 빠르게 어려워진다. Android Gradle Plugin은 이런 문제를 build type, product flavor, build variant라는 모델로 다룬다.빌드 변형은 "하나의 코드베이스에서 어떤 조합의 앱 산출물을 만들 것인가"를 표현하는 Gradle의 조합 결과다. 플레이버는 그 조합을 구성하는 축 중 하나로, 앱의 제품 성격이나 배포 대상을 나누는 데 쓰인다.이미지 출처: Android Developers / Google, Build variants 문..
카메라 버튼을 눌렀는데 바로 카메라가 열리지 않고 권한 요청 창이 먼저 뜨는 순간이 있다. Android 6.0(API 23) 이후의 위험 권한은 앱 설치 시점이 아니라 실행 중 필요한 순간에 사용자에게 요청하는 흐름을 따른다. 권한 처리는 단순히 requestPermissions()를 호출하는 문제가 아니다. 사용자가 거부할 수 있고, 다시 묻지 않음을 선택할 수 있으며, Android 버전에 따라 권한 그룹과 세부 권한이 달라질 수 있다.그래서 런타임 권한은 "필요하면 요청한다"가 아니라, 기능 진입점에서 권한 상태를 확인하고, 필요한 이유를 설명하고, 결과에 따라 기능을 열거나 대체 경로를 제공하는 사용자 흐름으로 봐야 한다.용어 정리용어이 글에서의 의미런타임 권한앱 실행 중 사용자에게 요청해야 하..
화면을 세로에서 가로로 돌렸을 때 버튼 위치만 바뀌는 것처럼 보일 수 있다. 하지만 Android에게 화면 회전은 단순한 뷰 재배치가 아니라 configuration change다. 언어, 글꼴 크기, 다크 모드, 화면 크기처럼 리소스 선택에 영향을 주는 조건이 바뀌면 현재 Activity는 기본적으로 파괴되고 다시 만들어진다.이 동작을 이해하지 못하면 "왜 입력하던 값이 사라졌지?", "왜 네트워크 요청이 또 나가지?", "왜 ViewModel은 살아 있는데 View는 다시 만들어졌지?" 같은 문제가 한꺼번에 헷갈린다. 구성 변경을 공부할 때는 화면 회전 이벤트 하나가 아니라 Activity 재생성, 리소스 재선택, UI 상태 복원 흐름을 함께 봐야 한다.이미지 출처: Android Developers..
Activity와 Fragment 사이에서 데이터를 넘기는 일은 화면을 나누는 순간부터 바로 나온다. 목록 화면에서 상세 화면으로 itemId를 넘기고, 작성 화면에서 저장 결과를 돌려받고, 같은 Activity 안의 두 Fragment가 선택 상태를 공유한다. 겉으로는 모두 "값을 전달한다"로 보이지만 Android에서는 목적지와 생명주기 경계에 따라 권장 방식이 다르다.핵심은 데이터를 직접 객체 참조로 넘기는 습관을 피하고, 화면 이동 인자, 결과 콜백, 공유 상태 저장소처럼 Android가 복원할 수 있는 경로를 고르는 것이다. 그래야 프로세스가 종료됐다가 다시 살아나거나 화면이 다시 만들어져도 흐름이 덜 깨진다.이미지 출처: Android Developers / Google, Android Nav..
Android 앱에서 접근성(accessibility)을 보장한다는 말은 단순히 글자를 크게 만들거나 색을 잘 고르는 정도로 끝나지 않는다. 화면에 보이는 UI를 보조 기술도 이해할 수 있게 만들고, 손가락 터치가 어려운 사용자도 같은 흐름을 끝까지 조작할 수 있게 만드는 일에 가깝다.예를 들어 화면에는 공유 아이콘이 보인다. 눈으로 보면 공유 버튼이라는 것을 바로 알 수 있다. 하지만 TalkBack 같은 스크린 리더 입장에서는 그 아이콘이 그냥 이미지인지, 버튼인지, 눌렀을 때 무엇이 일어나는지 별도의 정보가 필요하다. 그래서 접근성은 “보이는 화면”과 “시스템이 이해하는 화면” 사이를 맞추는 작업이다.접근성 문제는 눈으로만 보면 놓치기 쉽다. 그래서 Android에서는 TalkBack, Switch..
앱에서 예외를 추적하는 상황은 보통 조용하지 않다. 로그인 버튼을 눌렀더니 앱이 바로 종료되거나, 특정 화면에 들어간 직후 “앱이 중지되었습니다” 같은 안내가 뜬다. 사용자는 “갑자기 꺼졌다”고 말하지만, 개발자가 봐야 할 것은 “어느 코드 줄에서 어떤 예외가 발생했고, 그 코드까지 어떤 호출 흐름으로 도달했는가”이다.Android에서 예외를 추적할 때 처음부터 거대한 이론을 떠올릴 필요는 없다. 흐름은 비교적 분명하다. 개발 중에는 Logcat에서 앱이 남긴 로그와 스택 트레이스를 확인한다. 그다음 문제를 다시 발생시켜 같은 경로로 재현되는지 본다. 이미 배포된 앱이라면 Android vitals, App Quality Insights, Crashlytics 같은 리포트에서 실제 사용자 환경의 크래시 ..
