JetBrains가 IntelliJ IDEA Java 및 Kotlin IDE에 Workspaces 기능을 도입했습니다. 이 기능은 여러 프로젝트를 별도의 저장소에서 함께 관리할 수 있게 해주며, 13년 전부터 사용자들이 요청해온 기능입니다. 현재 Multi-Project Workspace라는 플러그인 형태로 제공되며, PyCharm이나 Android Studio와 같은 다른 IntelliJ 기반 IDE에서는 아직 사용할 수 없습니다. JetBrains는 이 기능을 핵심 IDE의 일부로 통합할 계획입니다. Workspaces 기능은 모노레포의 장점을 제공하면서도 단점을 피할 수 있는 방법으로 설명됩니다. 모노레포는 모든 프로젝트를 하나의 저장소에 포함시키는 방식으로, 코드베이스 탐색과 참조 찾기를 쉽게 해줍니다. 그러나 대규모 모노레포는 성능 저하, 세밀한 권한 설정의 어려움, 릴리스 주기 조정 문제 등의 문제를 야기할 수 있습니다. Workspaces는 각 프로젝트를 독립적으로 유지하면서도 여러 Workspace에 포함될 수 있도록 합니다. 현재 Workspace 플러그인은 프로젝트 가져오기 후 새로운 실행 구성을 만들어야 하고, 프로젝트 이름 변경을 지원하지 않으며, 설정 동기화 기능이 부족합니다. JetBrains는 향후 모든 IDE에서 Workspaces를 완전하게 지원하고, 프로젝트 간 디버깅을 원활하게 하며, 버전 관리 시스템에서 Workspaces를 저장하고 공유할 수 있도록 할 계획입니다. 이 플러그인은 이미 긍정적인 평가를 받고 있으며, 다른 IDE로의 확장을 기대하는 목소리도 높습니다.

System Design School의 새로운 연구에 따르면, SQL, Python, Java가 여전히 고용주들이 가장 많이 찾는 프로그래밍 기술로 나타났다. 이 연구는 Glassdoor의 구인 공고를 분석하여 가장 자주 요구되는 언어들을 밝혀냈다. System Design School의 창립자이자 전 Google 엔지니어인 Sheldon Chi는 "오늘날의 경쟁적인 취업 시장에서 올바른 기술을 갖추는 것이 그 어느 때보다 중요하다"고 강조했다. 연구 결과에 따르면, SQL은 2,291개의 구인 공고에서 요구되며 가장 높은 수요를 보였다. 데이터베이스 관리에 주로 사용되는 SQL은 데이터 분석이 점점 더 중요해짐에 따라 다양한 분야에서 높은 가치를 지닌다. Python은 1,488개의 구인 공고로 두 번째로 많이 요구되는 언어로, 그 단순함과 다재다능함 덕분에 웹 개발부터 데이터 과학, 머신 러닝까지 다양한 응용 분야에서 인기를 끌고 있다. Java는 856개의 구인 공고로 세 번째를 차지하며, 그 신뢰성과 플랫폼 독립성 덕분에 금융부터 안드로이드 앱 개발까지 다양한 산업에서 널리 사용된다. JavaScript는 674개의 구인 공고로 네 번째로 많이 요구되는 언어로, 프론트엔드 웹 개발의 핵심 역할을 한다. HTML5는 572개의 구인 공고로 다섯 번째를 차지하며, 풍부한 멀티미디어 경험과 반응형 디자인을 제공하는 능력 덕분에 현대 웹 개발에서 필수적이다. Chi는 "전문가들이 이러한 기술을 적극적으로 습득하여 고용 가능성과 경력 성장을 향상시키기를 권장한다"고 말했다. 디지털 트랜스포메이션 전략을 재정비하고자 한다면, Amsterdam, California, London에서 열리는 Digital Transformation Week에 참여해보길 권한다.

Veracode의 "State of Software Security 2024" 보고서에 따르면, 애플리케이션 코드의 63%가 자체 코드에서, 70%가 서드파티 코드에서 결함을 가지고 있으며, 42%의 애플리케이션에서는 결함이 1년 이상 수정되지 않아 보안 부채가 되고 있습니다. 특히 Visual Basic 6 (VB6), Perl, COBOL과 같은 오래된 프로그래밍 언어가 보안 문제에서 가장 취약한 것으로 나타났습니다. 반면, Python 애플리케이션은 보안 부채가 발생할 가능성이 상대적으로 낮지만, 이는 Python이 주로 가벼운 애플리케이션에 사용되기 때문입니다. Java 애플리케이션의 경우 보안 부채가 될 확률이 46%인 반면, Python 애플리케이션은 그 확률이 절반으로 줄어듭니다. AI 생성 코드의 보안성은 인간이 작성한 코드와 큰 차이가 없지만, 특정 소프트웨어 약점(CWEs)에 대해 훈련된 AI는 코드 수정 속도를 가속화할 수 있습니다. Veracode는 AI가 코드 수정의 꿈을 현실로 만들 수 있다고 강하게 믿고 있습니다. 그러나 Veracode는 예방 도구를 판매하는 회사로서 위험을 과장할 가능성이 있으며, 이론적인 취약점이 실제 위험으로 이어지지 않을 수도 있다고 보고서는 인정합니다. 실제로, 결함의 약 3%만이 높은 심각도를 가지며, 16%는 공격자에 의해 악용될 가능성이 높습니다. 서드파티 코드의 취약한 구성 요소는 보안 부채가 될 가능성이 더 높습니다. Veracode에 따르면, 절반 이상의 애플리케이션이 10명 미만의 기여자가 있는 오픈 소스 라이브러리를 사용하고 있으며, 이는 취약한 구성 요소를 제거하기 어렵게 만듭니다. 기여자가 많은 라이브러리는 보안 점수가 더 좋으며, 자주 업데이트되는 라이브러리는 일반적으로 더 나은 보안을 제공합니다. 개발자들은 소프트웨어 개발 생명 주기에 보안을 통합하고, 자주 업데이트하여 빠르게 수정 사항을 적용하는 것이 중요합니다.

Veracode는 최근 Universal Connector와 Application Security Heatmap이라는 두 가지 새로운 플랫폼 혁신을 발표했다. 이 두 기능은 Longbow 기술을 기반으로 하여 기업들이 애플리케이션 전반에 걸쳐 보안 위험을 신속하게 식별하고 우선순위를 정할 수 있도록 돕는다. 이는 보안 경고의 압도적인 양과 생성형 AI로 인해 더욱 취약해진 공격 표면을 관리하는 데 어려움을 겪는 조직들에게 중요한 시점에 제공된다. Veracode의 Chief Research Officer인 Chris Eng는 "보안 부채와 확장된 공격 표면, 그리고 압도적인 보안 경고의 조합이 조직들이 어떤 애플리케이션 위험을 우선시해야 할지 알기 어렵게 만든다"고 말했다. Veracode의 2024년 소프트웨어 보안 상태 보고서에 따르면, 대부분의 보안 부채는 내부 개발자가 작성한 1차 코드에 존재하지만, 가장 중요한 보안 부채는 오픈 소스 소프트웨어와 같은 3차 코드에 있다. 예를 들어, Java 애플리케이션의 80%와 JavaScript 애플리케이션의 63%의 중요한 부채가 3차 코드에서 발견된다. 보고서는 또한 개발자들이 수정 우선순위를 잘못 설정하는 경향이 있음을 강조했다. Eng는 "비중요한 결함에 집중하는 대신, 개발자들은 제한된 역량을 사용하여 보안에 가장 큰 영향을 미칠 수 있는 중요한 결함을 수정하는 데 집중해야 한다"고 강조했다. Universal Connector는 조직들이 이전에 Longbow 플랫폼에 통합할 수 없었던 다양한 소스 데이터를 신속하게 접근할 수 있게 해준다. Application Security Heatmap은 애플리케이션의 위험을 시각적으로 표현하여 각 애플리케이션을 소유자와 연결하고 90일간의 위험 추세를 보여준다. 이 기능은 조직 정책에 맞게 위험 임계값을 사용자 정의할 수 있어 보안 팀과 개발자들이 애플리케이션을 분석하고, 위험 분포를 확인하며, 가장 효과적인 수정 조치를 구현할 수 있도록 돕는다. Veracode의 제품 관리 부사장인 Derek Maki는 "새로운 기능은 조직의 가장 위험한 애플리케이션을 깊이 이해하고, 개선을 위한 가장 영향력 있는 솔루션을 식별할 수 있는 독특한 능력을 제공한다"고 말했다.

안녕하세요!여기어때 검색플랫폼개발팀의 레미입니다. OpenSearch의 이상탐지 기능이 흥미로워, 이를 직접 테스트해 본 경험을 여러분과 공유하려 합니다.개요OpenSearch는 Random Cut Forest (RCF) 알고리즘을 기반으로 시계열 데이터의 이상치를 실시간으로 감지하는 Anomaly Detection 기능을 제공합니다. RCF는 비지도 학습 알고리즘으로, 데이터 패턴을 모델링하여 비정상적인 변화를 감지하고, 이를 알림(Notification) 기능과 연계해 신속히 대응할 수 있습니다.이 가이드는 OpenSearch 설정, 데이터 이상 탐지, 알림 설정 과정을 단계별로 다룹니다환경 설정OpenSearch가 설치되어 있다는 가정하에 진행했습니다. 설치는 docker-compose.yml 파일을 활용해 OpenSearch와 OpenSearch Dashboards를 구성하였습니다.Docker Compose를 이용한 설치 예제docker-compose.ymlversion: '3'services: opensearch: image: opensearchproject/opensearch:2.17.0 container_name: opensearch environment: - discovery.type=single-node - node.name=opensearch - bootstrap.memory_lock=true # along with the memlock settings below, disables swapping - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # minimum and maximum Java heap size, recommend setting both to 50% of system RAM - OPENSEARCH_INITIAL_ADMIN_PASSWORD=password - TZ=Asia/Seoul - network.host=0.0.0.0 ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65536 # maximum number of open files for the OpenSearch user, set to at least 65536 on modern systems hard: 65536 volumes: - opensearch-data:/usr/share/opensearch/data - opensearch-config:/usr/share/opensearch/config ports: - 9200:9200 - 9300:9300 # required for Performance Analyzer networks: - opensearch-net opensearch-dashboards: image: opensearchproject/opensearch-

지난 2편에서는 가상 스레드(virtual thread)의 컨텍스트 스위칭(context switching)이 구체적으로 어떤 과정으로 진행되는지 알아봤습니다. 마지막 3편에서는 가상 스레드의 중요한 이슈인 고정(pinned) 이슈와 함께 가상 스레드의 한계에 대해서 알아보겠습니다.• 고정 이슈와 한계3편은 다음과 같은 순서로 진행합니다.• 소스 코드와 함께 살펴보는 고정 이슈 발생 과정• 고정 이슈로 인한 가상 스레드의 한계와 미래가상 스레드가 블로킹 I/O 작업을 만날 때 모종의 이유로 캐리어 스레드(carrier thread)와 연결된 가상 스레드가 교체되지 않고 고정되는 현상이 발생할 때가 있습니다. 이를 고정(pinned) 이슈라고 합니다. 이 현상이 발생하면 해당 캐리어 스레드는 더 이상 작업을 진행하지 않고 CPU와 격리되는데 이때 전체 시스템의 성능이 저하되거나 데드락(deadlock) 같은 치명적인 이슈가 발생할 수 있습니다. 따라서 가상 스레드를 사용하기 전에 고정 이슈가 발생할 수 있는 곳을 미리 확인해야 합니다.아래 그림은 고정 이슈가 발생하는 상황을 나타낸 것입니다. Task 1, 2가 가상 스레드를 통해서 실행되다가(그림 1), Task 1에서 블로킹 I/O 작업을 만나 컨텍스트 스위칭될 때(그림 2) 고정 이슈가 발생합니다. 고정 이슈가 발생하면 가상 스레드는 상태로 변경되고, 마운트된 플랫폼 스레드는 상태로 변경돼 OS 레벨에서 CPU와 격리됩니다(그림 3). 원래대로라면 Task 1에서 컨텍스트 스위칭될 때 캐리어 스레드 A가 스케줄러(scheduler)에 반환돼 가상 스레드 C와 연결돼야 하 지만, 캐리어 스레드 A가 가상 스레드 A와 고정돼 버리면서 성능 저하가 발생합니다.소스 코드와 함께 살펴보는 고정 이슈 발생 과정고정 이슈가 발생하는 과정을 JDK 코드를 기반으로 자세히 알아보겠습니다. 1편 및 2편과 마찬가지로 소스 코드는 OpenJDK 21+35가 기준이며, 글 중간에 등장하는 괄호 속 숫자는 함께 첨부한 소스 코드에서 각 설명에 해당하는 위치에 주석으로 남겨 놓은 숫자를 의미합니다.가상 스레드에서 메서드를 통해 컨텍스트 스위칭을 진행할 때, 앞서 2편에서 확인한 것과 같이 클래스의 메서드를 호출합니다(1). 이때 네이티브 메서드를 통해 스택의 메서드 프레임이 힙의 객체로 저장됩니다. 의 결괏값은 타입의 숫자인데요. 클래스의 메서드는 네이티브 메서드를 호출해 그 결과가 0인 경우 , 그렇지 않으면 를 리턴합니다(2).를 통해 호출하는 네이티브 메서드의 일부를 조금 더 자세히 살펴보겠습니다.메서드는 실질적인 작업을 수행하는 메서드입니다. 이 메서드(1) 내부에서 메서드를 호출해 현재 작업 수행 위치가 JVM의 크리티컬 섹션 내부에 있는지 확인하고, 메서드를 호출해 현재 보유 중인 모니터의 개수를 확인합니다(2)(크리티컬 섹션이란 JVM의 핵심 데이터 구조나 자원을 보호하기 위해 내부 락(lock)이나 뮤텍스(mutex)를 사용하는 코드 영역을 말합니다). 확인 결과 고정 이슈가 발생한 원인이 둘

지난 1편에서는 가상 스레드(virtual thread)의 장점을 살펴보고 가상 스레드를 어떻게 생성하고 시작하는지 알아봤습니다. 이어서 이번 글에서는 컨텍스트 스위칭(context switching)의 작동 방식을 살펴보려고 합니다. 1편에서 살펴본 VirtualThread 클래스의 멤버 변수와 가상 스레드 시작 시 수행하는 사전 작업을 어떻게 활용하는지 참고하면서 2편을 읽어보시면 조금 더 쉽게 이해하실 수 있을 것 같습니다.• 고정(pinned) 이슈와 한계2편은 다음과 같은 순서로 진행합니다.가상 스레드가 시작된 후 블로킹 I/O 작업을 만나면 컨텍스트 스위칭이 발생합니다. 이때 해당 가상 스레드는 실행 중이던 캐리어 스레드(carrier thread)와의 매핑이 끊어지며, 이후 블로킹 I/O 작업이 완료됐을 때 다시 캐리어 스레드에서 작업이 재개됩니다. 이 작업은 가상 스레드의 와 메서드가 수행하는데 요. 각 메서드가 어떤 방식으로 작동하는지 소스 코드와 함께 자세히 알아보겠습니다.1편과 마찬가지로 소스 코드는 OpenJDK 21+35가 기준이며, 글 중간에 등장하는 괄호 속 숫자는 함께 첨부한 소스 코드에서 각 설명에 해당하는 위치에 주석으로 남겨 놓은 숫자를 의미합니다. 가상 스레드의 작동을 보다 깊이 이해할 수 있도록 소스 코드와 함께 읽기를 권장합니다.VirtualThread클래스의 메서드는 작업 중 블로킹 I/O 작업을 만나 해당 가상 스레드를 잠시 멈추고 캐리어 스레드에 다른 가상 스레드를 매핑하기 위해서 호출합니다. 메서드에서는 가상 스레드의 상태를 'PARK' 상태로 변환하는 중이라는 의미인 으로 변환(1)한 후 메서드를 호출합니다.메서드는 (3)와 메서드(4)를 차례로 실행해 현재 캐리어 스레드에서 가상 스레드와의 연관 관계를 제거하고 캐리어 스레드를 다른 가상 스레드에게 양보합니다.클래스의 메서드(1)는 현재 실행 중인 작업을 중단하는 역할을 하며, 내부적으로 네이티브 메서드(2)를 호출합니다. 네이티브 메서드는 현재 실행 중인 작업을 중단한 뒤 이후 다시 재개하기 위해 메모리의 스택 영역에 쌓인 프레임을 힙 영역에 객체로 저장한 후 스택에서 해당 프레임을 제거해 실행 중이던 작업을 빠져나오게 합니다.아래 그림은 메서드 실행 시 메모리 변화를 나타낸 그림입니다. 캐리어 스레드에서 메서드를 실행한 후 메서드에서 가상 스레드를 생성합니다. 가상 스레드에 포함된 작업은 클래스의 메소드를 통해 실행됩니다. 이후 가상 스레드 내에서 메서드를 실행한 뒤 메서드 내부의 블로킹 I/O 작업을 만나 클래스의 메서드가 호출됩니다. 이때 메서드 이후에 실행돼 쌓인 스택 프레임은 힙 영역에 저장됩니다.스택에서 힙 영역으로 옮겨지는 메서드 프레임의 범위는 이후에 실행된 작업부터 네이티브 메서드를 호출한 메서드 프레임까지입니다. 아래 OpenJDK C++ 소스 코드(continuationFreezeThaw.cpp)는 네이티브 메서드를 통해 실행되는 코드 중 힙에 저장되는 스택 범위에 대한 내용입니다. 여기서 스택 프레임의 주소는 높은

Java의 가상 스레드(virtual thread)는 효율적인 동시성 애플리케이션을 개발하기 위해 설계된 경량 스레드입니다. 기존의 Java 스레드 모델과 비교해 더 적은 자원으로 더 많은 수의 스레드를 효율적으로 관리할 수 있으며, 이를 통해 높은 동시성 처리 성능을 제공합니다. 이는 특히 많은 수의 블로킹 I/O 작업을 효율적으로 처리하는 데 큰 이점을 제공합니다.이런 장점이 있는 가상 스레드가 구체적으로 어떤 방식으로 구현되어 있고 어떻게 작동하는지 소스 코드와 함께 알아보려고 합니다. 총 세 편에 걸쳐 아래와 같은 주제로 전달할 예정입니다.• 고정(pinned) 이슈와 한계1편은 다음과 같은 순서로 진행합니다.먼저 용어를 정리하자면, 기존 Java 스레드는 플랫폼 스레드(platform thread)라고 부릅니다. 가상 스레드는 이 플랫폼 스레드 내부에서 실행되며, 이렇게 플랫폼 스레드가 가상 스레드를 실행해 주는 역할을 할 때는 '캐리어 스레드(carrier thread)'라고 합니다.가상 스레드는 플랫폼 스레드와 비교해 크게 아래와 같은 두 가지 장점이 있습니다.• 블로킹 I/O 작업 시 발생하는 컨텍스트 스위칭 비용을 줄일 수 있습니다.각 장점을 하나씩 살펴보겠습니다.Java의 스레드 모델은 OS의 스레드(커널 스레드)와 1대1로 매핑됩니다. 따라서 블로킹 I/O 작업이 발생하면 해당 스레드의 상태가 변경되며, 이로 인해 OS 레벨에서 컨텍스트 스위칭이 발생합니다.아래는 기존 스레드 모델에서 컨텍스트 스위칭이 발생하는 과정을 나타낸 그림입니다.위 그림 1과 같이 플랫폼 스레드 A에서 Task 1이 수행되다가 그림 2와 같이 블로킹 I/O 작업이 수행되면 플랫폼 스레드 A는 작업을 멈추고 대기 상태가 됩니다. 이때 그림 3과 같이 플랫폼 스레드 B가 CPU를 선점해 새로운 Task 2를 실행합니다. 이 과정에서 발생하는 OS 레벨의 컨텍스트 스위칭, 즉 실행 중인 스레드의 레지스터 상태를 저장하고 새로운 스레드의 메모리 매핑을 설 정 후 레지스터 상태를 복원하는 과정은 시간과 자원을 상대적으로 많이 소모할 수 있습니다.이어서 가상 스레드의 케이스를 확인해 보겠습니다. 아래는 가상 스레드를 사용했을 때의 모습을 나타낸 그림입니다.가상 스레드를 사용하면 그림 4와 같이 플랫폼 스레드 내부에서 스케줄러를 통해 여러 개의 가상 스레드가 매핑되어 작업을 수행합니다. 이때 그림 5와 같이 가상 스레드 내부에서 블로킹 I/O 작업을 만나 컨텍스트 스위칭이 발생하면, 그림 6과 같이 플랫폼 스레드와 연결된 가상 스레드만 교체됩니다. 즉, 컨텍스트 스위칭 과정에서 CPU를 선점하는 플랫폼 스레드는 교체되지 않습니다. 이와 같이 가상 스레드를 사용하면 컨텍스트 스위칭이 OS 레벨이 아닌 애플리케이션 레벨에서 일어나기 때문에 메모리 매핑과 같이 자원과 시간을 상대적으로 많이 소모하는 작업이 없어지면서 기존 OS 레벨의 컨텍스트 스위칭보다 적은 비 용이 듭니다.기존 스레드는 새로 생성될 때마다 JVM 메모리 영역에서 스레드별로 필요한 영역(PC 레

자바 모듈 시스템의 변화로 인한 직렬화 문제를 분석하면서 알게된 내용을 공유합니다.• 3. 자바 9부터 자바 17까지의 모듈 시스템 변화안녕하세요. 딜리버리 프로덕트에서 간선 서비스를 개발하고 있는 고산하입니다.지난 상반기, 컬리에서는 전사적으로 AWS MSK의 버전업이 진행되었는데요. 이에 따라 Kafka 클라이언트와의 호환성을 유지하기 위해서 Spring Boot의 버전업이 필요하게 되었습니다.이번 포스팅에서는 Spring Boot 버전업 과정에서 마주했던 문제를 해결하면서 알게 된 내용에 대해 공유드리고자 합니다.제가 담당한 프로젝트의 기존 스팩과 업그레이드 대상 버전은 다음과 같습니다:모든 버전업을 마무리하고 나서 주요 기능에 대한 테스트를 진행하였고, 로그인 과정에서 문제가 발생하는것을 확인할 수 있었습니다.문제 지점을 디버깅을 통해 확인한 결과, 로그인 시 생성된 ValidToken 객체를 Redis에 직렬화하여 저장하는 과정에서 에러가 발생한 것을 알 수 있었습니다.로그를 살펴보니, 직렬화 과정에서 리플렉션을 사용하여 LocalDateTime의 date 필드에 접근하려 했으나 java.time 패키지가 외부 모듈에 공개되어 있지 않아 문제가 발생한 것으로 파악되었습니다.에러 메시지의 상단을 보면 필드의 가시성을 높이거나 를 등록하여 문제를 해결하라는 두 가지 방법을 제안하고 있습니다.제안된 두 가지 방법 중 필드의 가시성을 높이는 것은 캡슐화 및 보안성 측면에서 바람직하지 않기 때문에, LocalDateTime에 대한 Custom TypeAdapter를 작성하였습니다. 이후 로그인 과정을 다시 테스트해본 결과 문제가 해결된 것을 확인할 수 있었습니다.지금까지 Gson의 InaccessibleObjectException 에러에 대한 해결 방법을 알아보았습니다.그러나 현상이 해결되었으니 끝인 걸까요?문제는 해결되었지만 에러의 근본적인 원인을 이해하지 못한 상태였고, Gson 라이브러리의 직렬화 내부 동작이 에러와 어떤 연관이 있는지, Custom TypeAdapter를 등록하는 것이 왜 문제 해결에 효과적이었는지에 대한 궁금증이 남아있었습니다.이러한 호기심을 풀기 위해 Gson의 내부 직렬화 동작 과정을 분석해 보기로 했습니다.에러 메시지의 Stack Trace를 따라가며 문제가 발생한 지점을 위주로 살펴보았습니다.주요 부분을 추려보면 다음과 같습니다.메서드는 객체의 타입에 맞는 TypeAdapter를 선택하거나 생성하는 역할을 합니다.• Gson은 먼저 캐시(typeTokenCache)에서 요청된 타입의 TypeAdapter를 찾습니다.• 캐시에 없는 경우, 등록된 리스트를 순회하며 요청된 타입에 적합한 TypeAdapter를 생성하거나 반환합니다.• 생성된 TypeAdapter는 캐시에 저장되어 동일한 타입에 대한 후속 요청 시 재사용됩니다.는 Gson에 등록된 여러 중 하나로, 커스텀 TypeAdapter가 등록되지 않은 타입에 대해 기본적으로 동작합니다.• ReflectiveTypeAdapterFactory는 리플렉션을

안녕하세요. 커뮤니케이션 앱 LINE의 모바일 클라이언트를 개발하고 있는 Ishikawa입니다. 저희 회사는 높은 개발 생산성을 유지하기 위해 코드 품질 및 개발 문화 개선에 힘쓰고 있습니다. 이를 위해 다양한 노력을 하고 있는데요. 그 중 하나가 Review Committee 활동입니다.Review Committee에서는 머지된 코드를 다시 리뷰해 리뷰어와 작성자에게 피드백을 주고, 리뷰하면서 얻은 지식과 인사이트를 Weekly Report라는 이름으로 매주 공유하고 있습니다. Weekly Report에는 Android나 iOS 같은 특정 플랫폼이나 Kotlin, Swift 같은 특정 언어에 한정되는 내용도 있지만, 대부분 프로그래밍 전반에 적용할 수 있는 주제로 작성해 공유하고 있습니다(단, 설명을 위해 사용하는 코드는 Kotlin을 사용하는 경우가 많습니다).이번에 블로그로 공유할 Weekly Report의 제목은 '한 번 엎지른 는 다시 주워 담지 못한다'입니다.한 번 엎지른 는 다시 주워 담지 못한다다음은 라는 함수로 로 시작하는 문자열에서 1~6자리 정수를 조회하는 함수입니다.이 코드의 문제점은 무엇일까요?에러를 전파하는 방법은 호출자가 해당 에러를 어떻게 처리하는지에 따라 달라집니다. 위 예시 코드는 두 가지 에러를 전파하고 있습니다.• 인수로 입력된 문자열의 형식이 잘못됨일반적으로 '호출자가 제공한 인수는 신뢰할 수 없다'고 생각해야 더 견고한 코드를 작성할 수 있습니다. 해당 인수는 사용자가 입력하거나 외부 시스템에서 제공 받은 것일 수도 있기 때문입니다. '잘못된 인수가 입력되는 것은 흔한 일이다'라고 전제하고 에러 처리를 구현해야 합니다. 한편, 정규 표현식 구현 실수는 함수에 국한된 에러입니다. 호출자는 이 에러를 신경 쓸 필요가 없으며, '복구할 수 없는' 에러여야 합니다.위 사실을 염두에 두고 각 에러의 표현 방법을 확인해 봅시다. 인수 형식 에러는 으로 표현하고 있으며, 정규 표현식 구현 실수는 클래스의 객체로 표현하고 있습니다. 과 같은 로직 에러는 대부분의 경우 해서는 안됩니다. 로직 자체를 수정해야 합니다. 반면, 정규 표현식 실수는 실제로는 로직 에러이지만 클래스를 사용해서 호출자가 처리하도록 강제하고 있습니다. 즉, 현재 에러를 처리하는 방법과 에러를 표현하는 방법이 서로 맞지 않습니다.프로그래밍 언어와 처리 시스템에 따라 다르지만 에러를 표현하는 방법은 매우 다양합니다. 그중 어떤 표 현을 사용할지는 해당 에러가 어느 정도로 복구할 수 있는 것인지를 참고하면 좋습니다.기본값은 호출자가 에러 발생 여부를 파악하지 않아도 되는 경우에 사용합니다.단순 도메인 에러는 에러가 발생했다는 사실은 알아야 하지만 에러의 내용까지는 알 필요가 없을 때 사용합니다. 대표적인 예로 조기 반환을 적용하는 경우가 있습니다.만약 정상적인 상태에서는 반환값이 없는 경우라면 에러 발생 여부를 나타내는 진위값을 반환값으로 자주 사용하며, 이때 대부분의 경우 가 에러 발생을 나타냅니다(단, C 언어에서는 이 정상 상태를 나타내는 경