iOS Safari에서 새 창이 열리지 않은 이유와 해결 방법실무에서 마주친 iOS Safari의 예외 상황과 브라우저 정책를 사용해 새 창 열기 기능을 구현하던 중, 특정 기기/페이지에서만 해당 기능이 동작하지 않는 이슈가 있었습니다.이 이슈의 원인을 파악하고 해결해 나간 과정에 대해서 공유드리려합니다.iOS Safari에서만 코드가 동작하지 않았던 이유제휴 서비스에 연결 및 제휴 페이지로 이동하는 기능을 개발하던 중, 새 창을 여는 코드가 일부 iOS 기기에서만 동작하지 않는 문제가 발생하였습니다.같은 링크 이동 공통 코드를 사용하는 다른 페이지에서는 정상적으로 새 창이 열렸고, 동일한 페이지도 Android나 데스크탑에서는 문제가 없었습니다.심지어 같은 OS인 다른 iOS 기기에서는 또 정상 동작하였습니다.이슈 상황이 한정적이 었기 때문에, 원인 파악이 굉장히 까다로웠습니다.위 케이스 분석을 통해, 문제가 된 페이지의 동작 방식과 문제가 발생한 iOS 기기의 설정이 동시에 작용할 때만 이슈가 발생한다는 점을 유추할 수 있었습니다.문제를 해결하기 위해 다양한 시도와 디버깅을 진행하였고, Safari 브라우저에서 사용자 상호작용과 팝업 생성 시점 사이의 타이밍에 민감하게 반응한다는 점을 확인하게 되었습니다.Safari가 팝업을 차단하는 조건Safari는 팝업(새 창)이 열리는 시점이 사용자의 명시적인 상호작용과 연결되어 있지 않으면 해당 팝업을 차단하는 정책을 가지고 있습니다.이번 이슈에서 문제가 된 페이지는 사용자가 버튼을 클릭한 뒤, API 요청을 보내고 그 응답을 기다린 후에 을 실행하도록 구현되어 있었습니다.이처럼 사용자 인터랙션 직후에 팝업이 동작하지 않으면, Safari는 해당 팝업을 비의도성 광고성 팝업으로 간주하여 자동으로 차단합니다.API 호출 과정에서 문제가 발생하는 것인지 알아보기 위해 사용자 클릭 이벤트 직후 으로 창을 여는 시도하며 어느 시점부터 동작을 차단하는지 확인해보았습니다.Safari는 클릭 이후 1초만 지나도 새 창 열기 동작을 차단하였고, API 호출 및 후처리 로직을 1초 이내로 완료하는 것은 현실적으로 불가능하였습니다.지연 시간을 줄일 수 없으니 클릭 이벤트 트리거를 생성해보기로 하였습니다.히든 버튼을 생성하고 버튼에 팝업 열기 이벤트를 할당해두었습니다. API호출 후 로직이 완료되면 생성해둔 버튼을 클릭하여 이벤트가 발생하도록 시도해보았습니다.하지만 이 방법 또한 사용자의 직접적인 클릭 이벤트가 아니기 때문에 동일하게 차단되었습니다.이 과정을 통해 Safari가 단순히 이벤트 핸들러와의 지연시간을 확인하는 것이 아니라,사용자의 직접적인 클릭 행위와 창 생성의 타이밍이 얼마나 즉각적으로 연결되어 있는지를 판단한다는 점을 알게 되었습니다.빈 창을 먼저 열고, 나중에 URL을 설정하기결국 Safari의 팝업 차단 정책을 우회하지 않고, 만족하는 방식으로 문제를 해결하기로 했습니다.사용자가 버튼을 클릭하는 시점에 으로 빈 새 창을 먼저 열어두고, 이후 API 응답이 도착하면 해당 창의 를 변경하여 랜딩시키는 방식입니다.이렇게 하면 Safari는 "사용자의 상호작용으로 열린 창"이라고 판단하여 이를 차단하지 않으며, 보안 정책을 준수하면서도 기능을 정상적으로 수행할 수 있게 됩니다.사용자 경험 개선을 위한 로딩 페이지 도입이러한 구조로 새 창을 열게 되면, 사용자는 새 창에 주소가 할당될 때까지 빈 페이지를 보게 됩니다.이 상태에서는 아무런 안내가 없기 때문에 사용자 입장에서 혼란스러울 수 있습니다.이를 보완하기 위해 사용자를 빈 페이지가 아닌 공통 로딩 페이지로 랜딩시켜 사용자에게 현재 처리가 진행 중임을 명확히 전달하도록 개선했습니다.처리가 끝나고 나면 주소를 새로 할당해 제휴사 페이지로 이동시켰습니다.위와 같은 개선 사항을 통해,사용자는 팝업 차단 설정을 해제하거나 빈페이지를 보고있지 않고도 서비스 플로우를 따라갈 수 있게 되었고 사용자 경험을 크게 개선 시킬 수 있었습니다.사용자 환경을 이해하고 설계하는 개발자이번 문제를 해결하며 사용자 경험을 제공하는 서비스를 개발하기 위해서는 단순히 개발 역량만으로는 충분하지 않다는 점을 체감하였습니다.사용자의 기기 환경이나 설정 상태에 따라 예외 케이스가 얼마든지 발생할 수 있기 때문에,실무에서는 기술 스펙뿐 아니라 서비스가 제공되는 환경에 대한 이해와 고찰을 충분히 해야할 필요가 있습니다.

소프트웨어 개발에서 테스트는 선택이 아닌 필수입니다.개발을 하던 중에, 어딘가의 코드 한 부분을 수정했는데 예상치 못한 곳에서 에러가 발생하는 경우를 모두 한번씩은 경험해 보셨을 겁니다.그럴때 마다, 테스트 코드가 잘 구현된 코드가 얼마나 안전하고 오류를 줄일 수 있는지 깨닫게 됩니다.그렇기에 많은 언어 환경에서 테스트를 잘 할 수 있도록 라이브러리를 많이 제공하는 편인데요.특히 Go 언어는 간결함과 효율성을 철학으로 삼는 만큼, 테스트 또한 내장 도구로 간편하게 작성할 수 있도록 설계되어 있습니다.이번 포스트에서는 Go의 테스트 문화와 철학부터 시작해서 Unit Test 작성 방법 부터 Integration Test 구성 방법까지 폭넓게 다뤄보겠습니다.마지막으로, CI를 활용한 테스트 자동화와 테스트 베스트 프랙티스 및 유지보수 전략도 살펴볼 텐데요.예제 코드를 곁들여 설명하니, Go로 테스트를 처음 작성해보는 분들도 쉽게 따라오실 수 있을 것입니다.• None 테스트의 편리함을 더하는 Testify• None Mocking 기법으로 외부 의존성 다루기• None 여러 조각을 하나로: Integration Test 구성Go 언어는 태생부터 테스트를 중요시해 왔고, 표준 라이브러리에서 바로 테스트 프레임워크를 제공합니다.Go 개발자들은 “테스트도 결국 코드다”라는 철학 아래, 추가 DSL이나 거창한 프레임워크 없이 표준 testing 패키지와 평범한 Go 코드만으로 테스트를 작성하는 미니멀리즘을 지향합니다.실제로 Go의 테스트는 함수 앞에 Test라는 접두사를 붙이고 *testing.T를 인자로 받아서, 그 안에 일반적인 조건문과 함수 호출로 검증하는 식으로 작성되지요.다른 언어처럼 어노테이션이나 복잡한 설정이 필요 없고, 테스트 초기화/정리(setup/teardown)를 위한 별도 문법도 최소한으로 줄여 두었습니다.이런 단순함 덕분에 Go 개발자는 익숙한 Go 문법으로 곧바로 테스트를 작성할 수 있고, 새로운 테스트 전용 언어를 배우지 않아도 됩니다.Go의 기본 테스트는 별도 프레임워크 없이 표준 라이브러리만으로 구현됩니다.Go는 go test 명령과 testing 패키지를 통해 테스트를 자동으로 탐지하고 실행합니다.테스트 코드는 다음 규칙을 따르면 자동 인식됩니다:테스트 파일 이름은 _test.go로 끝나야 합니다 (예: math_test.go)테스트 코드는 일반 코드와 같은 패키지에 두는 것이 관례입니다.테스트 함수는 Test로 시작하고 *testing.T를 인자로 받습니다.예를 들어, 형식입니다. 반환값은 없어야 하며, 등 testing.T의 메서드를 호출해 실패를 보고합니다.동일한 패키지 내의 여러 테스트 함수들은 기본적으로 순차 실행되지만, 패키지 간 테스트는 CPU 코어 수만큼 병렬 실행됩니다.작성한 테스트는 go test 명령 하나로 쉽게 실행할 수 있습니다.기본적으로 성공한 테스트는 조용히 지나가고, 실패한 테스트만 출력됩니다. 자세한 로그를 보고 싶다면 -v 옵션을 사용하시면 됩니다:: 정규식에 매치되는 특정 테스트들만 실행 (go test -run TestAdd 등).아래는 간단한 Add 함수와 그에 대한 유닛테스트 예시입니다:Unit Test에서는 여러 시나리오를 하나의 테스트에 넣기 보다는 하나의 논리만을 검증하는 것이 좋습니다.또한, 테스트 함수의 이름은 무엇을 테스트하는지 명시적으로 드러나게 지어야 디버깅과 협업에 용이할 수 있을 것입니다.외부 자원 접근이나 환경에 의존하는 코드는 유닛테스트에서 최대한 격리하는 것이 좋습니다.Unit Test의 장점은 실행이 매우 빠르고 특정 메서드(함수)의 문제를 정확히 찾아낼 수 있다는 점입니다.다만, 시스템 전체의 관점에서 발생하는 이슈는 찾을 수 없고 다른 모듈과의 상호작용에서 발생하는 문제는 해당 테스트로는 검출하기 어렵다는 한계가 있습니다.따라서, Unit Test로는 메서드 단위의 동작을 탄탄히 검증한 뒤, Integration Test로 보완하는 전략을 사용하는 것이 일반적입니다.3. 테스트의 편리함을 더하는 Testify당연히 Go의 기본 내장 testing 패키지는 테스트를 작성할때 아주 직관적이고 간단하지만, 때로는 여러 번의 반복적인 코드를 작성하는데 있어 불편함이 있습니다.이런 문제를 보완하여 더욱 간편하게 테스트 코드를 작성할 수 있게 해주는 것이 바로 Testify입니다.실제로 개발하다 보면 거의 대부분의 상황에서 이 testify 라이브러리를 사용하는 것 같습니다. (특히, assert 기능..!)Testify는 Go 언어용 테스트 라이브러리로, 기본 내장된 testing 패키지보다 더 편리하고 간결한 테스트 작성을 지원합니다.특히 다음과 같은 기능을 제공합니다:: 보다 직관적이고 명확하게 값을 검증하는 메서드를 제공: 모의 객체를 쉽게 생성하고 관리하는 기능 제공: 관련된 여러 테스트들을 묶어서 관리 가능Testify의 가장 큰 장점 중 하나는 강력한 Assertion 기능입니다.기존 Go 기본 내장 테스트와 비교하여 아래와 같이 더 깔끔한 문법으로 테스트를 작성할 수 있습니다.그 외에도 테스팅에 있어 편리함을 주는 다양한 기능들이 있으니,관심이 있으신 분들은 Testify 공식 문서(https://pkg.go.dev/github.com/stretchr/testify)을 통해 살펴보기면 좋겠습니다.4. Mocking 기법으로 외부 의존성 다루기테스트할 코드가 외부 시스템이나 DB, 네트워크 호출 등에 의존한다면 Mocking 기법이 필요합니다.Mock(모의 객체)은 실제 구현 대신 동작을 흉내 내는 객체로, 해당 의존성을 대체하여 테스트 대상 로직만 검증할 수 있게 도와줍니다.Go는 언어 차원에서 Mock을 지원하지는 않지만, 몇 가지 대표적인 서드 파티 라이브러리가 널리 쓰이고 있습니다: testify/mock과 Mockery가 그 예입니다.testify의 mock 패키지를 이용하면 인터페이스에 대한 모의 객체를 쉽게 만들 수 있으며, 사용 방법의 개요는 다음과 같습니다:• None 인터페이스 정의: 먼저 모킹 대상이 되는 인터페이스를 정의합니다. 예를 들어 메시지를 보내는 인

C++ 개발자는 멀티 스레드 환경에서 mutex나 atomic 같은 동기화 도구를 익숙하게 사용합니다. 하지만 이런 도구를 잘 활용해도 동시성 문제가 발생할 수 있으며 이 경우 디버깅에 많은 시간과 노력이 필요합니다.데이터 레이스(data race)의 개념을 정확히 이해하면 동기화 도구가 어떤 문제를 해결하는지 어떤 상황에서 계속 데이터 레이스가 발생하는지 알 수 있습니다. 이 글에서는 C++의 동시성(concurrency) 문제와 이를 방지하기 위한 스레드 안전성의 주요 개념을 관련 이론 및 사례와 함께 공유합니다. 안정적인 멀티 스레드 코드 작성에 도움이 되기를 바랍니다.관련 발표 영상은 Thread-safety in C++에서 이어보실 수 있습니다.데이터 레이스멀티 스레드 환경에서는 서로 다른 스레드가 동시에 같은 데이터에 접근하는데, 이때 접근 방식이 적절하지 않으면 데이터 레이스가 발생할 수 있습니다. 데이터 레이스는 다음 조건을 모두 충족할 때 발생합니다.두 개 이상의 스레드가 하나의 메모리 위치(memory location)에 동시에 접근하나 이상이 쓰기 연산을 수행하나 이상이 atomic 연산이 아님여기서 '메모리 위치'는 int나 bool 같은 기본 타입(primitive type)의 하나로 이해하면 됩니다.(표준에서는 더 엄밀하게 정의하고 있습니다.) '동시에 접근'은 단순히 시간이 겹친다는 의미가 아니라 C++ 메모리 모델에서 연산 간 선후 관계(happens-before)가 정의되지 않았다는 의미입니다.C++에서는 데이터 레이스가 발생하면 이를 미정의 행동(undefined behavior)으로 간주합니다. 미정의 행동은 어떤 결과가 나올지 예측할 수 없으며, 코드가 정상 작동할 수도 있고 심각한 오류가 발생할 수도 있으므로 절대로 발생하지 않아야 합니다.연산 간 선후 관계순차 실행 관계(sequenced-before)C++에서는 같은 스레드 안에서 실행되는 두 연산 사이에 명확한 순서가 존재하면 이 관계를 순차 실행 관계라고 부릅니다. 이 관계는 연산 간 선후 관계의 전제 조건입니다.다음 코드를 보겠습니다.a = 1; b = a; 여기서 a = 1 연산이 먼저 실행되고, 그 다음 줄(b = a)에서 값을 읽습니다. 이 두 연산은 순차 실행 관계에 있습니다. a = 1이 반드시 먼저 실행되고, 그 다음에 b = a가 실행된다는 것이 언어 차원에서 보장됩니다.비결정적인 순서(indeterminately-sequenced)코드에 적힌 순서대로 실행이 보장되지 않는 경우도 있습니다.f(a = 1, b = a); 이런 표현식에서는 a = 1이 먼저 실행될지 b = a가 먼저 실행될지 정해져 있지 않습니다. 이런 경우에 순서가 비결정적이라고 합니다. 순서는 있지만 어떤 것이 먼저인지는 알 수 없습니다.순서 보장 없음(unsequenced)다음과 같은 경우도 있습니다.(a = 1) + (b = a);이 경우 두 연산 사이에 순서를 보장하지 않습니다. 실제로 동시에 실행될 수도 있고 컴파일러가 임의로 순서를 정할 수도 있습니다. 이는 데이터 레이스로 분류되지는 않지만 미정의 행동입니다.멀티 스레드 안전성과의 관계이런 순서 보장은 멀티 스레드 환경에서 안전성을 확보하기 위한 기초 개념입니다. 같은 스레드 내에서는 순차 실행 관계가 있어야만 그 순서가 연산 간 선후 관계로 이어질 수 있습니다. 코드에 순서가 있다고 해도 그것이 명확한 순차 실행 관계가 아니면, 여러 스레드 실행 시 순서를 정하는 데 문제가 될 수 있습니다.스레드 간 동기화 관계(synchronized-with)같은 스레드 내에서는 코드 상의 순서대로 실행되는 연산 간에 순차 실행 관계가 있습니다. 서로 다른 스레드 간에도 특정한 조건이 만족되면 동기화 관계(synchronizes-with)가 성립하고, 이것이 순차 실행 관계와 합쳐져서 연산 간 선후 관계로 확장될 수 있습니다.동기화 관계는 C++ 표준에서 특정한 라이브러리 호출 쌍에서 명시적으로 정의합니다. atomic이 대표적인 예입니다.한 스레드에서 std::atomic 변수에 대해 store(value, memory_order::release)를 수행다른 스레드에서 같은 변수에 대해 load(memory_order::acquire)를 수행하여 해당 값을 읽음이 두 연산 사이에는 동기화 관계가 형성됩니다.동기화 관계가 생기면, 각 스레드 내의 순차 실행 관계를 이어 붙여서, 결국 하나의 스레드에서 먼저 일어난 일이 다른 스레드에서 나중에 일어난 것처럼 순서를 보장합니다. 이것이 바로 연산 간 선후 관계입니다.동기화 관계는 atomic 연산에만 국한되지 않습니다. 예를 들어 한 스레드가 mutex.unlock()을 호출하고, 다른 스레드가 같은 mutex에 대해 mutex.lock()을 성공적으로 수행하면 이 두 연산 사이에도 동기화 관계가 성립합니다.연산 간 선후 관계는 멀티 스레드 환경에서 안전한 실행 순서를 정의하기 위한 핵심 메커니즘입니다. 이 관계를 통해 어떤 연산의 결과가 다른 스레드에 반영되는 것을 보장할 수 있고 데이터 레이스를 막을 수 있습니다. 멀티 스레드 프로그래밍에서는 동기화 관계를 어떻게 만들고 연결하느냐가 매우 중요합니다.연산 간 선후 관계의 시각적 이해연산 간 선후 관계가 어떤 원리로 형성되는지 시각적으로 정리해보겠습니다.두 개의 스레드가 나란히 표시되어 있고, 각 스레드 내에서의 연산은 위에서 아래로 흐른다고 가정합니다.Thread 1의 연산들은 순차 실행 관계atomic-store-release와 atomic-load-acquire는 동기화 관계Thread 2의 연산들은 순차 실행 관계이 모든 관계가 이어져서 Thread 1 처음의 'A에 3을 쓰기'와 Thread 2 마지막의 'A에서 3을 읽기' 간에 연산 간 선후 관계가 완성됩니다.이것이 C++에서 여러 스레드에서 접근하는 동일 메모리 위치에 대한 연산 간 순서를 정하는 방식입니다. 이런 순서 관계가 명확히 성립하지 않으면, 값이 제대로 전달되지 않거나 동기화가 되지 않아서 데이터 레이스, 즉 미정의 행동이 발생할 수 있습니다.퀴즈: 다음 연산은 데이터 레이스

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. C++에서 안정적인 멀티 스레드 코드를 위한 스레드 안전성 개념 정리 에서도 살펴보실 수 있습니다. 발표 내용C++ 에서 thread safe 한 프로그램을 만들기 위해 알아야 할 기본 개념인 data race 와 basic thread safety, 연산 간 순서 관계에 대해 설명합니다.발표 대상동시성 프로그래밍 업무를 수행하는 C++ 개발자목차Data raceData race연산 간의 선후 관계(Sequenced-before)연산 간의 선후 관계(Synchronizes-with)연산 간의 선후 관계(happens-before)Basic thread safetyBasic thread safetyStandard library 의 thread safetystd::shared_ptr T 의 basic thread safetyBasic thread safety 보장하지 않는 타입의 예Basic thread safety 를 왜 보장해 줘야 하나?External synchronizationExternal sychronizationExternal sychronization w/ std::mutexExternal sychronization w/ std::atomicSynchronizes-with 관계를 제공하는 함수들Internally synchronized typesInternally synchronized typesInternally synchronized type 만들기 시도Synchronization primitivesSynchronization primitive 사용한 internally synchronized typestd::atomic 으로 구현하는 mutex NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

안녕하세요, SK플래닛 DevRel 담당자입니다! SK그룹 테크블로그가 궁금하신 분들을 위해, 작년에 이어 SK ICT 테크블로그 2025년 버전을 업데이트해 보았어요~ (참고: SK ICT 테크블로그 2024년 버전 - https://techtopic.skplanet.com/skict-techblog24/ )1년이 지났을 뿐인데 업데이트할 내용들이 제법 있었어요. SK ICT를 대표하는 SK데보션 블로그, 지금 보고 계시는 SK플래닛 Tech Topic 등은 계속 잘 운영되고 있구요, 올해 변경된 주요 내용은• SK C&C의 사명 변경(SK AX)과 인사이트 메뉴 소개• 원스토어의 개발자 스타일 블로그 오픈 이야기• SK쉴더스의 정보보안/물리보안 블로그 내용을 추가했어요~올해로 4주년을 맞은 데보션은 SK텔레콤이 운영하는 SK그룹의 대표 개발자 커뮤니티 플랫폼으로, SK ICT 패밀리사의 개발 전문가들과 외부 인재간 소통 및 기술 공유를 위한 개발자 활동(DevRel) 채널 역할을 겸하고 있습니다. 블로그뿐만 아니라 AI 개발 생태계를 지원하는 '데보션 오픈랩', 실무형 AI 인재 성장을 지원하는 '데보션 AI 펠로우십' 등 다양한 외부 프로그램을 함께 진행합니다.2025년 6월 1일부터 SK(주) C&C의 회사명이 SK(주) AX로 변경되었습니다! ('AX'는 'AI Transformation' 이라는 의미입니다)SK AX 테크 블로그는 2024년 C&C 때부터 회사 대표 웹사이트에 포함되었으며, 'Insights' 메뉴 내에 기술 인사이트 및 트렌드 메뉴를 별도로 운영하고 있습니다.판교에 있는 SK플래닛에서 운영 중인 기술 블로그입니다. 2023년 1월부터 월 평균 1회 수준으로 블로그를 운영 중이며, OK 캐쉬백, 시럽(Syrup) 등 SK플래닛에서 개발한 프로덕트의 기술과 개발 회고 내용을 소개합니다(초기에는 UX, 솔루션을 포함하였으나 개발 내용 중심으로 변화 중!). 위에서 소개드린 SK데보션 및 T Academy, 외부 개발자 포털(코드너리, TechBlogPosts)와도 연계되어 있구요. 블로그와 함께 개발자 페이스북을 함께 운영 중입니다(SK플래닛 개발자 활동, 팔로워 약 4.6천). 덧. SK플래닛 초기에는 'README'라는 블로그를 2012년 오픈하여 2018년 11번가 분사 전까지 운영했습니다.• SK플래닛 구 블로그(아카이브): https://web.archive.org/web/20190116065552/http://readme.skplanet.com/11번가에서 운영 중인 테크 블로그입니다. 2021년 오픈하였으며 Java, Spring, AWS 개발 및 배포 사례 등 서버 및 클라우드 기술 중심으로 포스팅합니다.음악 서비스 FLO를 개발하는 드림어스컴퍼니에서 운영하는 블로그입니다. 기술뿐만 아니라 회사 컬처 등을 함께 외부에 소개하고 있으며, 기술 카테고리에서 커버하는 내용은 앱 개발, 서버, 추천 기술 등 다양한 카테고리를 포함합니다.TMAP을 개발 및 서비스하는 티맵모빌리티의 블로그입니다. 브런치를 활용하고 있으며, TMAP 개발자들이 직접 쓰는 테크노트 중심의 글들을 포스팅한다는 컨셉으로 외부에 기술을 공유합니다.2024년 12월 모던한 분위기의 원스토어 기술블로그를 새롭게 오픈하였습니다. 많은 관심과 참고 부탁드립니다! (회사 사이트 메뉴에 블로그 메뉴가 포함되어 있습니다)SK쉴더스 회사 사이트에 블로그 메뉴가 포함되어 있습니다. 독특한 것은 정보보안 블로그와 물리보안 블로그가 별도로 운영된다는 점입니다(참고로 SK쉴더스는 예전에 SK인포섹과 ADT캡스라는 두 개의 회사가 하나로 합쳐진 회사여서, 각각의 사업 영역에 맞는 블로그를 운영하는 것 같습니다).지금까지 SK ICT 패밀리사 중심으로 운영되었거나 운영 중인 다양한 기술 블로그들을 소개하였습니다(작년보다 더 많아졌네요!). 혹시 빠진 내용이나 보완할 부분이 있다면 알려주시면 감사하겠습니다. 이들 블로그들이 SK그룹 내 개발자뿐만 아니라 외부의 개발자들과도 공유 및 소통하며 서로가 성장하는 도구로 잘 활용되기를 바랍니다. 읽어 주셔서 감사합니다.

ChatGPT가 출시된 이후 계속해서 생성형 AI 기술을 활용한 서비스 개발 고도화뿐만 아니라, 각 기업 내 구성원들의 AI 활용을 높이기 위한 노력 또한 더욱 커지고 있는데요.따라서 AI를 잘 활용하기 위한 기업의 환경 조성 및 활용 문화의 확산 또한 중요해지고 있습니다.SK플래닛에서는 이미 2024년 여름, 사내 구성원들이 다양한 LLM(Large Language Model)을 실제로 체험할 수 있는 LLM 플레이그라운드를 사내에 시범 오픈하고,이를 활용한 프롬프톤(프롬프트 + 해커톤) 이벤트를 사내 개발팀과 지원팀의 콜라보레이션으로 진행한 사례를 공유드리오니 참고하시기 바랍니다.ChatGPT 기반 서비스에서 활용하는 LLM Playground (이하 '플레이그라운드')는 서비스에 적용되는 GPT 모델을 테스트해 볼 수 있는 웹 기반 인터페이스로,http://chatgpt.com/ 의 채팅 인터페이스와 유사한 구성으로 사용자가 익숙하고 편리하게 사용할 수 있습니다.또한 여러 가지 파라미터 변경 기능을 함께 제공하기 때문에, 사용자는 GPT의 답변 스타일을 직접 바꿔볼 수 있습니다.예를 들어 'Temperature(온도)'라는 파라미터 값을 낮게 설정하면 일반적인 문장의 답변을, 높게 설정하면 무작위성이 증가해 보다 창의적인 답변을 생성하게 되며,이를 활용해 생성형 AI 기반 서비스의 페르소나를 설계하고 테스트할 수 있습니다.여러분이 아시는 OpenAI에서 제공하는 Playground 뿐만 아니라, Amazon Bedrock, SKT A.X, 네이버 HyperClovaX 등LLM을 제공하는 기업 중심으로 플레이그라운드를 제공하고 있습니다(최근에는 각각의 활용 목적에 따라 원티드 LaaS, SK mySUNI의 교육용 Playground 등 다양한 모습의 플레이그라운드가 출시되고 있습니다).B. Pain Point와 멀티 LLM 플레이그라운드의 시작그런데 플레이그라운드의 '출시' 뒤에는 실은 개발자 등 실무자 관점에서의 Pain point가 있었는데요,AI엔지니어 및 개발자가 업무를 위해 LLM 모델을 테스트하기 위해서는 각 LLM 제공 회사의 사이트를 돌아다녀야 하였으며(Context Switching 발생),LLM 모델 별로 비용이나 속도를 비교해 보고 싶은데 그러한 기능을 제공하지 않는 곳도 있어 불편했다고 합니다.그래서 저희 개발팀에서는 '우리 회사가 자주 사용하는 LLM 모델을 한 곳에서 테스트해 볼 수 있도록 직접 만들어 사용하자!' 는 아이디어를 제안하였고,이것이 바로 '멀티 LLM Playground'의 시작이었습니다! : )C. 플레이그라운드의 주요 기능플레이그라운드의 화면 구성은 다음과 같습니다.• None 사내 인트라넷으로 접속 가능 (외부망 불가능)플레이그라운드는 다음 LLM 모델을 지원하도록 만들었습니다(현재는 제공하지 않는 모델도 있음).원래는 개발팀 등에서 업무 용도로만 사용하고자 해서 UI 등은 크게 신경을 쓰지 않고 빠르게 개발하여 사내에만 사용하고 있었는데 ,그래도 여러 모델을 한 화면에서 테스트할 수 있어 좋았고, 오른쪽 패널에서 입출력 토큰 비용 및 답변 속도값을 제공하고 있어서 모델별 조건을 바로바로 비교할 수 있었습니다.그러던 중 누군가가, '사내 구성원 전체에게 이 도구를 활용하여 프롬프트 엔지니어링을 경험해 볼 수 있는 기회를 제공하면 어떨까?' 하는 생각을 제안하였고,마침 담당 임원도 이 아이디어에 동의해 주셨습니다. 따라서 이 도구를 전사에 공개하고 개발팀과 지원팀 콜라보레이션의 '프롬프톤' 공동 이벤트 를 진행하게 되었답니다.(2) 지원팀: '프롬프톤' 이벤트를 통해 우리회사 서비스의 캐릭터를 경험케 하다!SK플래닛에서는 아시는 것처럼 OK캐쉬백(이하 OCB) 과 시럽(이하 Syrup) 서비스를 운영하고 있는데, 여기에서 사용되는 다양한 귀여운 캐릭터 '판타스틱4' 들이 존재합니다.오글오글/오글봇 , 래키(OCB) , 러비(Syrup) 및 최근 출시된 OLOCK: (오락: )의 로키 가 바로 그것이죠(아래 참조).처음에는 (1)에서 언급한 LLM Playground의 단순 활용 방안을 고민하고 있었는데,사내 다양한 분들의 이벤트와 캐릭터 활용 아이디어, 그리고 사내에서 공유해 주신 캐릭터 마케팅 관련 글에서 인사이트를 얻어"우리 회사 서비스 캐릭터들이 AI를 만나면 어떤 아이들이 될까?" 라는 테마의 프롬프톤 사내 이벤트가 탄생하게 되었습니다.요약하자면 Prompt Engineering을 통해, 내가 선택한 캐릭터의 페르소나를 정하는 즉 'AI Characterization' 을 진행하는 것이었죠.아래는 사내 인터뷰 일부이며, 사진과 이름 등은 익명 처리하였습니다.프롬프톤 1~3위 수상자의 회고(소감 인터뷰)를 함께 공유드립니다사내 데이터 분석가, UX 디자이너, 소프트웨어 엔지니어 가 골고루 선정되셨는데요!이들의 회고를 통해 프롬프톤이 어떻게 진행되었고 어떤 모델과 프롬프트, 생각으로 결과물을 작성하였는지 아이디어와 느낌을 간접 경험해 보시기 바랍니다.최근 그리고 계속해서 LLM 모델의 성능이 너무나 좋아지면서,프롬프트 엔지니어링을 강조하던 기조가 조금은(?) 줄어드는 것 같기는 하지만(웬지 수고 대비 효과를 찾는 휴먼의 관점일까요),오히려 Agentic AI 등이 떠오르고 있는 요즘 Agent에게 정확한 지시를 하기 위해 아직도 잘 짜여진 프롬프트의 중요성 은 아직도 그 위상을 지키고 있다고 생각합니다.또한 이 글에서는 언급하지 않았지만, '코드 기반 프롬프트' 도 'LLM에게 명확한 지시를 내린다' 는 관점에서 개발 업무, 자동화 코드 생성뿐만 아니라일반 기획업무 등에서도 유용하게 활용될 수 있을 것으로 기대됩니다

안녕하세요, SK플래닛에서 프론트엔드 개발을 담당하고 있는 김찬민이라고 합니다.작년 이맘때까지만 해도 프론트엔드 개발자가 AI를 사용하는 용도는 새로운 기술을 습득하거나 코드를 리팩터링하는 등 프롬프트를 기반으로 하는 코드 생성 작업이 대부분이었던 것 같은데요,MCP와 코딩 에이전트의 등장 후로는 훨씬 더 다양한 방식으로 AI를 활용할 수 있게 된 것 같습니다.AI의 활용 방법들 중 하나로, 이번 글에서는 Framelink Figma MCP를 사용해 프론트엔드 개발자의 숙제 중 하나인 UI 컴포넌트를 효율적으로 개발하는 방법을 소개해보려 합니다.Framelink Figma MCP는 Cursor, Copilot 등의 코딩 에이전트와 figma를 이어주는 MCP로, 피그마 노드(≈ UI 요소)의 주소를 프롬프트에 추가하면 UI를 인식해 코드로 전환할 수 있습니다.Framelink Figma MCP를 사용하기 위해서는 먼저 피그마 액세스 토큰이 필요합니다.• None 토큰 권한은 모두 Read-only로 부여했습니다.다음으로 Cursor 에디터에 MCP를 추가하기 위해 Cursor 설정에 진입합니다.MCP 설정에 진입했다면 "New MCP Server" 버튼을 눌러 MCP 서버를 추가할 수 있습니다.MCP 서버를 추가한 뒤 MCP Tools에 Framelink Figma MCP에 초록불이 들어와 있다면 성공입니다.이제 프롬프트에 Figma 노드 정보를 포함시키면 MCP 서버가 Figma API를 통해 해당 노드의 정보를 불러올 수 있고, 코딩 에이전트는 이를 코드로 변환할 수 있게 됩니다.MCP 설정이 끝났다면 테스트를 위해 구글에서 유지보수하는 UI 컴포넌트 라이브러리인 Material UI의 피그마 시안을 코드로 옮겨 보겠습니다.Figma에서 개발하고자 하는 UI 컴포넌트를 선택하고 해당 요소의 URL을 복사합니다.Figma Dev Mode를 사용한다면 조금이나마 더 쉽게 요소를 선택할 수도 있습니다.2-b. 코딩 에이전트에 프롬프트 작성하기이제 Cursor 에디터에 다음과 같이 프롬프트를 작성하면 LLM이 피그마 파일을 읽을 수 있게 됩니다.프롬프팅의 결과로 Figma Material UI 중 UI에 대응하는 컴포넌트와 스토리북 문서가 생성된 모습입니다.개인적으로는 LLM에게 수동적으로 코드 개선을 요청하는 단계를 넘어, 피그마 파일을 읽고 마크업을 생성해주는 모습에 큰 인상을 받았습니다.그래서 React 기반의 OK캐시백 서비스에 사용되는 일부 컴포넌트를 Vue로 재작업하는 과정에 MCP를 실제로 사용해 보았습니다.• None MCP 기반으로 생성된 컴포넌트를 튜닝해 완성한 모습MCP가 성공적으로 컴포넌트를 생성해 주었고, 스위치가 더 자연스럽게 움직일 수 있도록 라이브러리를 사용해 애니메이션을 다듬으니 만족스러운 결과물을 얻을 수 있었습니다.제가 직접 처음부터 구현해야 했다면 4시간 정도 걸렸을 것 같은 작업이었는데, 수 분 내에 작업을 마치고 작은 디테일들을 보완하는 데에 사용할 수 있는 시간이 늘었던 만족스러운 경험이었습니다.화면 전체 UI를 코드로 옮기려 시도하면 유지보수가 어려운 코드가 생성되는 등 아직은 AI가 완벽하지 않은 모습을 보이기도 하지만,단위 컴포넌트를 구현하고 스토리북 문서를 관리하는 목적만으로도 프론트엔드 개발자의 부하를 크게 줄여줄 수 있게 되었습니다.수동적으로 코드 생성, 개선을 요청하는 용도를 넘어 프론트엔드 개발에서 중요한 과정인 디자인을 코드로 옮기는 데에 들이는 시간을 크게 단축할 수 있게 되었다는 점에는 만족하지만,앞으로 프론트엔드 개발자들이 일하는 모습은 어떻게 변화해야 할지, 어떤 식으로 경쟁력을 갖춰야 할지에 대해서는 어려운 고민거리를 던져준 것 같습니다.UI 구현에 어려움을 겪을 수 있는 타 직군이나 주니어 개발자들에게 이 글이 도움이 되셨길 바라며, 더 좋은 글로 다시 찾아뵙겠습니다.

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 서비스 조직에서 Kafka를 사용할 때 알아 두어야 할 것들 (4)에서 이어집니다.Kafka Client는 어떻게 클러스터의 전체 상태를 알 수 있는가? 서비스를 개발하는 입장에서 관련 옵션을 어떻게 잡아 주면 좋은가? 에 대해 설명합니다.• 동작 매커니즘• 브로커 - 클라이언트 간 metadata 교환NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 서비스 조직에서 Kafka를 사용할 때 알아 두어야 할 것들 (3)을 보고 오시면 좋습니다. 발표 내용Kafka 프로듀서 최적화하기 + 압축 기능 활용하기목차배경: Kafka 자료 구조Kafka 자료 구조는 어떻게 생겼는가?프로듀서 동작 방식 및 최적화 방법프로듀서와 브로커는 어떻게 메시지를 주고받는가? linger.ms, batch.size, buffer.memory 사용법압축 동작 방식 및 최적화 방법(재)압축은 어떻게 이루어지는가?compression.type, compression.{type}.level 사용법 NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

글. 방동민/ UX Researcher“이거 괜찮아 보이는데… 어때요?”서비스를 만들다 보면 자연스럽게 하게되는 말이에요. UX 리서처인 저 조차도 동료가 건내는 “이 문구 어때 보여요?”, “아이콘 바꿔봤는데 괜찮을까요?” 라는 질문을 들을 때면 무심코 고개를 끄덕이며 답변을 하기도 합니다. 편리함과 익숙함 때문에 고객보다는 동료에게 묻는 상황을 자연스럽게 받아들이게 되는거죠.디자이너, 기획자, 개발자 등 제품을 만드는 사람이라면 누구나 ‘지금 내가 만들고 있는 것이 고객에게 어떻게 보일지’에 대한 불확실성을 가지게되고 이 불확실성을 해소하기 위해 가장 빠르고 편한 방법은 바로 옆에 있는 동료나 지인에게 묻는 것입니다. 짧은 시간 안에 피드백을 받을 수 있고, 커뮤니케이션 비용도 낮으니까요.그런데 어느 순간부터 그 피드백이 ‘불편할 정도로 편하다’는 생각이 들기 시작했습니다.피드백의 편리함이 만든 편향동료나 지인에게 의견을 묻는 건 분명 빠르고 효율적인 방식입니다. 문제는, 이 효율이 반복되다 보면 우리가 놓치게 되는 시선이 생긴다는 거예요.내부 동료는 이미 그 제품이 어떤 배경에서 만들어졌는지 알고 있습니다. 설사 맥락을 모른다고 해도, 동일한 업무 환경과 유사한 문제 의식을 공유하고 있다는 점에서 사용자가 아니라 ‘메이커’의 시선으로 답변하게 됩니다. 지인의 경우도 마찬가지예요. 몇 번만 반복해도 학습이 이루어지면서 점점 ‘비전문가 사용자’와는 다른 방식으로 반응하게 됩니다.이런 구조에서는, 마치 거울 앞에서 계속 같은 표정을 연습하듯이 ‘정제된 반응’만 들을 위험이 생깁니다. 우리는 점점 ‘진짜 고객’의 언어와 경험에서 멀어지게 되죠. 그렇다면 질문은 간단해집니다.리서치의 접근성은 왜 여전히 높지 않은가우리는 왜 고객에게는 묻기 어려웠을까요? UX 리서처로서 오랜 기간 리서치 프로젝트를 진행해 오면서 한 가지 패턴을 자주 마주합니다.바로 리서치는 항상 일정과 리소스에 쫓기고, 접근하기 어려운 것처럼 여겨진다는 점입니다. 기획 초기에는 “이건 고객에게 물어봐야 해요”라는 공감대가 있지만, 현실적인 리크루팅, 가이드 설계, 일정 조율 등의 벽에 부딪히면 금세 대안은 ‘내부에서 빠르게 정리하자’로 기울게 됩니다.이건 리서치 방법론이 부족해서라기보단, 리서치 구조가 실무 흐름에 스며들어 있지 않기 때문입니다. 바로 이 지점을 개선하고 싶었습니다. 정교하게 설계된 리서치가 아니더라도 필요한 순간에 빠르게 활용할 수 있는 고객 피드백 구조를 만들 수는 없을까라는 고민을요.고객을 팀 안으로 초대해보기우리가 고객에게 알고 싶은 건 간단한 것들이었습니다. 예를 들어 “이 버튼의 기능이 예상되나요?”, “이 화면은 어떻게 이해되나요?”, “이건 복잡하거나 불편하지 않나요?”와 같이 복잡하지 않고, 그냥 짧고, 빠르게 의견이 필요한 질문들이었죠. 이런 질문은 대부분 리서치 타이밍을 놓치거나 우선순위에서 밀려나곤 합니다.하지만 제품의 완성도나 방향성에 실제로 결정적인 영향을 주는 미세한 순간이기도 하죠.작지만 중요한 질문들을 옆 자리 동료에게 가볍게