안녕하세요. 스튜디오 킹덤 클라이언트 개발자 이한나입니다. 이 글은 제가 신입으로 입사하여 3년 차인 지금까지 일하며 실수한 것들을 돌아보고 되새겨 보는 글입니다. 이 글이 저처럼 신입 또는 주니어 클라이언트 개발자분들께 작게나마 도움이 되기를 바라며 저의 경험을 나누고자 합니다.일하다 보면 종종 내가 이해한 것과 기획자가 의도하는 방향이 다른 경우가 생깁니다. 확신이 가지 않는 부분은 당연히 물어봐야 합니다. 설계를 하고 있을 때, 작업을 진행하고 있을 때, 작업을 완료 했을 때까지, 늦었다고 생각할 때가 가장 빠른 질문 타이밍입니다."10번 뽑기 기능"을 만드는 상황을 예시로 들어보겠습니다.여기서 질문을 하지 않는 개발자가 1번 뽑기를 10번 반복하는 것으로 이해하고 (음! 전부 이해했어!) 작업을 진행합니다.그리고 마감날이 되어 테스트를 돌려본 기획자가 물어봅니다.기획자 : 이거 뽑기 10번을 전부 보여주고 있네요? 뽑기는 1번만 보여주고 보상을 10개를 줘야 하는데 다르게 나오는 것 같아요. 확인 부탁드립니다.그동안의 시간과 노력을 지우고 다시 작업을 하는 상황이 되어버렸습니다. 눈물을 머금고 다시 작업을 하고 싶지 않다면 자신이 이해한 것 그리고 작업 방향이 기획자가 의도하는 방향과 맞는지 물어보고, 기록하고, 작업을 진행하도록 합시다.추가로 작업하면서 중간중간 결과물을 영상으로 찍거나 스크린샷으로 캡쳐해 공유합시다. 구현 방향을 공유하는 의미도 있고, 나중에 리팩터링하거나 기능이 추가될 때 원본 기능이 어땠는지 참고하기 좋아서 기록 차원에서라도 남겨두는 게 좋습니다. 그리고 귀여운 작업물을 만들었다면 자랑할 수 있다는 장점도 있습니다.다른 프로그래머의 코드를 수정할 때도 비슷합니다. 코드에는 의도와 맥락이 있습니다. 왜 이런 코드가 있는지 물어보고 의도에 맞는 방향으로 작업해 야 합니다. 그리고 수정 방향에 대해 얘기하다 보면 생각지 못한 더 좋은 코드가 떠오르거나 어딘가에 있는 동일한 코드를 가져다 쓸 수 있음을 알게 될 수 있어서, 어떤 코드에 대해 수정이 고민이 된다면 담당 프로그래머와 얘기해 보는 것이 좋습니다.데이터 수정은 기획자에게 요청하자"쿠키런: 킹덤"에서는 기획자가 퀘스트 내용이나 쿠키의 능력치 같은 게임 데이터를 작업합니다. 적은 양의 데이터 수정일지라도 어떤 데이터는 서로 연결되어 있어 규칙에 맞게 입력해야 하고, 또 그 데이터를 수정하고 번역 요청을 하는 등 관리가 필요합니다. 따라서 데이터 수정은 담당 기획자에게 요청하는 것이 가장 안전합니다. (담당자한테 물어보자는 위 문단의 내용과도 유사합니다.)네트워크 환경이 항상 최선의 상태가 아닐 수 있음을 고려하자예를 들어서, 클라이언트는 서버와 통신을 할 때, 클라이언트가 서버에 보내는 모든 요청이 실패할 수 있음을 고려해야 합니다. 유저의 네트워크 환경이 다양하기 때문입니다. 요청이 실패하면 경우에 따라 유저가 말을 걸어도 NPC 가 반응을 하지 않는 등 의도하지 않게 게임에 갇힐 수 있습니다. 그래서, 요청이 실패했을 때 화면이 어떻게 나와야 하는지, 다

안녕하세요, 테크블로그 구독자 여러분! 토스 콘텐츠 프로듀서 김태성입니다.혹시 유튜브 시리즈 〈언더커버 사일로〉를 보신 적 있나요? 토스 안팎에서 벌어진 실제 문제를 예능 포맷으로 풀어낸, 토스의 첫 도전이었습니다. 시작 전엔 “과연 통할까?” 하는 두려움이 컸지만, 다행히 많은 분이 토스가 진정성 있게 러닝 쉐어를 나누고 싶어 한다는 마음을 알아봐 주셨어요. 덕분에 “더 깊이 고민하고, 더 많이 실패하고, 결국 더 크게 성공해 보자”는 우리의 바람도 힘을 얻었습니다.〈언더커버 사일로〉는 토스 밖 여섯 명의 메이커가 ‘사일로원’이 되어, 토스가 실제로 직면했던 과제를 해결해 보는 두뇌 서바이벌 예능입니다. 기획 초반엔 팀원들을 설득하려고 “토스판 〈크라임씬〉을 만들겠다”고 선언하고 다녔는데, 그땐 진짜 아무것도 없는 상태였어요. 그래도 “직무와 상관없이 누구나 이 콘텐츠를 통해 토스의 일하는 방식을 고해상도로 들여다볼 수 있어야 한다”는 목표만은 확고했습니다.사실 토스는 그동안 컨퍼런스, 밋업, 그리고 바로 이 테크블로그를 통해 제품 개발 과정에서 얻은 러닝과 인사이트를 꾸준히 공개해 왔어요. 그런데도 “성공담만 내보내는 거 아니냐”, “실패는 숨기는 거 아니냐”, “토스니까 가능하지, 우리는 환경이 달라서 안 된다” 같은 반응이 종종 이어졌죠.제 생각은 달랐습니다. 치열한 논의와 문제 해결 의지만 있다면, 누구라도 토스 사일로처럼 일할 수 있다고 믿었어요. 그래서 외부 메이커들이 같은 조건에서 같은 문제를 풀어 보는 실험을 해 보고 싶었습니다. 먼저 비공개로 여러 소규모 스타트업 메이커분들을 모셔 사전 리허설을 진행했고, PO·개발자·창업자·디자이너·마케터 등 다양한 참여자들이 문제를 해결하는 과정에서 배워 가는 것을 보며 확신을 얻었습니다.바로 그 확신이 “토스 사일로에 외부 메이커가 잠입한다”는 콘셉트로 〈언더커버 사일로〉를 제작하게 된 배경입니다.도메인이 뭐든, 경력이 얼마든, 직무가 달라도 문제 해결에 열정만 있다면 누구나 토스가 겪었던 비즈니스 과제를 풀어낼 수 있다고 믿어요. 그래서 외부 메이커들이 흥미를 가질 만한 토스 프로덕트 다섯 개를 골랐습니다.언더커버 사일로에 출연한 챌린저스는 물론, 시청자 여러분도 이 다섯 가지 과제를 함께 고민하며 풀어 보길 바랍니다. 아직 시리즈를 못 보신 분이라면, 토스가 어떻게 고민하고 결정하며 실패와 성공을 반복하는지를 생생하게 체험하실 수 있을 거예요. 앞으로도 더 많은 러닝 쉐어를 통해, 여러분이 자신의 자리에서 새로운 도전을 이어 갈 용기를 얻어가셨으면 합니다.이번 글을 읽고 ‘언더커버 사일로’가 궁금해지셨다면, 지금 바로 본편을 확인해 보세요!그리고 테크블로그에서는 본편에서 다 전하지 못한 비하인드 스토리를 차례로 풀어갈 예정이니, 놓치지 않으려면 꼭 구독해 주세요.

접근성 지원을 한다고 하면, 사람들은 뭘 더 해야 한다고 생각합니다. 뭘 더 하는 만큼 개발기간도 더 늘어난다고 생각합니다. 하지만 이런 생각은, 보안성을 챙기면 개발기간이 늘어난다 는 주장만큼이나 틀린 말입니다. 보안성을 고려하며 개발하는 것이지, 개발 다 끝내놓고 그 다음에 보안성을 따로 높이는 사람이 어디있나요? 접근성을 고려하는 일은, 사실 우리가 더 좋은 제품을 만들기 위해 늘 하는 고민들의 다른 측면일 뿐입니다.하지만 평소에 접근성을 높이는 일에 관심이 없던 사람 입장에선, 이런 얘기도 뜬구름 잡는 얘기처럼 들립니다. 접근성 지원이 어떻게 우리가 늘 하는 고민 의 다른 측면일 수 있을까요? 나는 그런 고민을 한 적이 없는데 말이죠.관점을 바꿔, 이렇게 여쭤보겠습니다. 당신은 프로그래머로써 일반 텍스트(plain text)의 힘을 충분히 활용하고 있습니까?『실용주의 프로그래머』는 일반텍스트(plain text)의 힘을 다음과 같이 강조합니다.…우리는 지식을 다루기 가장 좋은 형식이 일반 텍스트라고 믿습니다. 일반 텍스트를 사용하면, 우리는 손으로든 프로그램으로든 거의 모든 도구를 사용해 지식을 조작할 수 있는 능력을 얻게 됩니다. 대부분의 바이너리 형식의 문제는, 데이터를 이해하는 데 필요한 문맥이 데이터 자체와 분리되어 있다는 점입니다. …(중략) 애플리케이션 없이 해석할 수 없다면, 그 데이터는 암호화된 것이나 다름없으며 전혀 의미를 지니지 못합니다. 사람이 읽을 수 있는 형태의 데이터, 그리고 자기 기술적(self-describing) 데이터는 그 데이터를 생성한 애플리케이션이나 그 외 모든 형식의 데이터를 뛰어넘어 더 오래 살아남을 것입니다. 단언컨대 그렇습니다. 데이터만 살아남는다면, 그것을 사용할 기회는 여전히 존재합니다 — 비록 그 데이터를 작성한 원래의 애플리케이션이 사라진 이후라도 말입니다.접근성 높은 제품을 만든다는 것은, 더 다양한 환경에서 동작하는 제품을 만든다는 것과 정확히 같은 뜻입니다. 손이 없는 유저가 음성이나 눈으로 접근할 수 있는 환경, 눈이 없는 유저가 시각적 요소 없이 정보에 접근해야 하는 환경, 손과 눈이 모두 없는 컴퓨터가 어떻게든 정보에 접근해 단위테스트를 실행시켜야하는 환경에서 모두 동작하는 제품이 접근성 높은 제품입니다. 이 때 다양한 환경이 같은 출력물을 일관되게 해석할 수 있게 하기 위해선, 그 출력물은 반드시 텍스트여야 합니다. 오직 텍스트만이 특정 환경에 의존하지 않고 그 자체적으로 해석될 수 있기 때문입니다.그래서 유능한 프로그래머는 언제나 ‘입력과 출력을 어떻게 텍스트로 다룰 수 있을까’를 고민합니다. 텍스트로만 만든다면, 그것이 무엇이든 분석하고 조작할 수 있기 때문입니다. 우리가 API와 CLI로 개발하는 이유, 가장 강력한 AI가 대형언어모델의 형태인 이유에는, 모두 같은 배경이 있는 것입니다.접근성을 지원할 때, 우리가 하는 대부분의 일이 UI에 텍스트 형태의 정보를 추가하는 일인 것도, 결코 우연이 아닌 방금 말한 배경에서 나온 의도적 디자인입니다. 실제로,

Terraform과 Ansible를 들어보신 적 있으신가요? 클러스터를 구성하다보면 자주 마주치게 되는 이름들입니다.IaC(Infrastructure As Code)의 대표적인 도구들로 서버, 네트워크, 스토리지 등 IT 인프라를 사람이 직접 클릭 하거나 명령어를 입력해 수동으로 설정하는 대신,코드로 정의하고 자동화된 방식으로 관리/프로비저닝하는 도구입니다.현재 On-Prem 환경에서 Kubernetes 인프라를 프로비저닝하는 작업을 진행하고 있는 현재에 IaC는 매우 편리하고 일관성을 가지는 도구입니다.그렇다면 On-Prem의 K8S 환경을 제공하는 입장에서 더 필요한 내용은 무엇이 있을까요?구성된 클러스터를 IaC 코드를 모르는 사용자들에게도 알기 쉽게 전달할 수 있어야 합니다.여러 방법이 있을 수 있겠지만 개인적으로 가장 선호하는 방식은 그래프를 통해 나타내는 것입니다.다음은 직접 경험해본 툴들을 비교한 내용입니다. 결국 손에 잘 익은 도구가 좋습니다.사용법도 큰 차이가 없어서 디자인적인 선호도가 중요할 것 같습니다.본론으로 들어와 이 툴들 중에서도 제가 리뷰 할 도구는 Mermaid Chart 입니다.Mermaid Chart의 가장 큰 장점은 Code로 표현된다는 점입니다.조금 의아하실 수 도 있겠지만 Graph를 Code로 나타내는 것이 더 어렵지 않을까? 생각 할 수도 있습니다.네, 물론 어렵습니다. 그럼에도 이를 가장 큰 장점으로 뽑은 이유는 이 어려운 일을 저희가 하지 않을 수 있기 때문입니다.LLM을 활용한다면 이 Code를 쉽게 작성 할 수 있습니다.개인적으로 저는 Cursor AI를 사용할 예정입니다.예제는 KubeSpray를 사용해볼 예정입니다.kubernetes는 기본 클러스터 구성외에도 정말 많은 Third Party를 가지고 있습니다.여러 Third Party를 활용하여 Sample 클러스터 구성을 준비했습니다.현재 클러스터 현황을 Cursor AI에게 Mermaid Chart Code로 만들어달라는 요청을 받은 결과 값입니다.해당 결과를 코드로 복사하여 Mermaid Chart 홈페이지에서 편집해보겠습니다.1. 먼저 Meremaid Chart 홈페이지를 이동하고 구글 계정으로 로그인합니다.• None Free Trial의 경우 3개 정도의 chart를 저장 할 수 있습니다.2. 편집기에 코드를 복사합니다.3. 현재는 다이어그램이 보기 쉽지 않습니다.- 디자인 컨셉을 변경하여 diagram을 변경 할 수 있습니다.4. 스타일을 편집하고 Adaptive 모드로 배치를 변경했습니다.이제 SVG 혹은 PNG 형식으로 Export까지 진행하면 발표 자료 혹은 시스템을 전달 할 수 있는 최종본 추출이 가능해집니다.이제 머리속에 있는 아키텍쳐를 IaC 코드를 기반으로 만든 Mermaid Chart 코드를 통해 편하게 편집하고 보여주시기 바랍니다.

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 발표 내용AI/ML 분산 처리 프레임워크인 Ray를 활용하여 GPU Util 100%를 달성한 배치처리 기법과 확장 가능한 모델 서빙 아키텍처를 소개합니다.발표 대상배치 파이프라인 설계와 모델 서빙 자동화를 담당하는 분Ray 기반 인프라 운영 및 GPU 클러스터 관리 업무를 수행하는 분Ray Serve를 활용해 고성능 모델 서빙 API를 설계·배포·운영하는 분Ray LLM(vLLM) 기반 LLM 추론 파이프라인을 구성·확장하고, 내부 모델 레지스트리를 연동하는 분목차Introduction to Ray Ray에 대한 소개 및 Core Architecture에 대한 이해Ray Data: GPU Util 100% Bach Inference를 위한 수난기 기존 구조와 도입된 구조 비교TroubleShooting 4건PipelineStep 추상 클래스 소개Ray Serve: 배치 + 서빙, 두 마리 토끼를 잡다 Offline Serving UseCaseGPU 자원 효율성 실험ModelInference, BaseDeployment 인터페이스 소개Ray LLM: ServeManager를 활용한 LLM 배포 (with vLLM) ServeManager 구조 소개TroubleShooting 4건Conclusion NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

Data Ontology 구축을 위한 기획 및 개발 진행 중이며 Engineering 관점에서 초기 데이터 구성 방법에 대해 공유하려고 합니다.Mart 데이터를 대상으로 했으며 여러 방법 중 Data Lineage 생성에 대해 말씀드리겠습니다.Data Ontology의 정의는 "특정 도메인(분야)에 존재하는 개체들, 그 개체들이 속한 개념(클래스), 속성, 그리고 개념 간의 관계들을 형식적이고 명시적으로 정의한 지식 표현 구조"입니다.정의를 정리해보면 도메인을 설명할 수 있는 모든 메타 데이터의 세계로 이해할 수 있습니다.데이터 메타화의 기준은 아래와 같이 표현할 수 있습니다.• None• None ex) '강민우'는 사람이라는 클래스의 인스턴스• None• None ex) A는 B의 자식이다, C는 D의 부분이다• None• None ex) 모든 고양이는 포유류다ETL 과정을 거치는 Mart Data 속성을 반영하여 Data Ontology를 생성을 위해 Data Description, Relationship, Lineage가 필요하다고 판단했으며해당 메타를 조합하여 도메인에 대한 새로운 속성을 생성과 insight를 발굴할 수 있을 것으로 보입니다.Data Lineage의 정의는 "데이터를 생성한 시점부터 소비되는 시점까지의 전체 흐름과 변화를 추적하는 정보"입니다.데이터 계보라고도 하며 정리하면 데이터의 출처, 변환 및 가공 과정, 목적지를 보여주는 데이터 흐름의 이력 추적 체계로 이해할 수 있습니다.Mart 데이터는 사용자가 요청을 위해 수많은 ETL 과정을 거칩니다.이때, 명확한 사용자 요청, ETL 쿼리가 존재한다면 Data Ontology의 속성 및 관계 생성 가능성이 높아집니다.Mart 데이터가 생성되는 과정을 간단한 예시로 표현한 것이며Mart 데이터 결과 값 (명확한 사용자 요청) "고객 서비스 내 주문량", "고객 서비스 접근 경로", ETL 과정에 대한 Data Lineage 만 주어진 상황입니다.• None 1번과 2번 과정을 서로 다른 Mart 데이터 생성 과정이며 결과적으로 서로 고객, 서비스 테이블을 이용한다는 것을 확인할 수 있습니다.• None 공통적으로 Table B, C를 이용한다면 B와 C는 고객과 서비스 중 하나이며 고객, 서비스가 연관되는 Mart 데이터를 생성해야하는 경우 B, C를 이용할 확률이 높다는 것을 알 수 있습니다.• None Table B, C는 1번과 2번 과정에 모두 사용되었기 때문에 주로 함께 사용될 확률이 높다고 할 수 있습니다.• None 1번 과정의 ETL 노드들은 "주문량" 관계로 볼 수 있습니다.• None 2번 과정에서 Table D를 사용했으며 결과에 "접근 경로"가 있는 것으로 보아 D에는 경로에 대한 데이터가 포함되어 있을 확률이 존재하며 D의 속성이 "이용 내역"이 아닌 "사용자 이력"이 될 수도 있습니다.본 데이터를 활용하여 ETL 최적화, 업무 속도, 마케팅 및 AI 사업 향상을 기대할 수 있을 것으로 예상합니다.Data Lineage는 Table, Column 레벨로 나누어집니다.• None 본 블로그에서는 Table Lineage 추출 방법에 대해 다루겠습니다.Data Lineage 생성 도구들 중 JsqlParser, Open Lineage, Apache Atlas 에 대해 설명 드리겠습니다.• None 수 많은 쿼리가 이미 존재• None 누락 없어야하며 Job 재실행 시 영향도 큼• None 활용 방향성에 따라 Data Lineage 추출 및 변환 사항 변경 가능• None 쿼리 수정 후 Lineage 추출을 위해 연관된 모든 Job 실행하는 경우 없어야함위 사항을 고려하여 JsqlParser 사용하는 것으로 결정했으며 Big Data 파싱 가능하도록 추가 로직 생성했습니다.LLM을 활용하여 예시 쿼리를 준비했으며 해당 코드는 Table Level Lineage 추출을 위한 Spark의 Insert Overwrite Table 샘플 코드입니다.해당 코드는 Java 21을 사용했습니다.• None JsqlParser은 쿼리를 AST로 변경하며 쿼리의 세부사항을 모두 담고 있습니다.• None insertStatement에 디버깅했으며 위 이미지는 Insert Overwrite 하위 Select 문에 대한 AST입니다.• None JsqlParser 이용 시 sql을 지원하는 형식으로 변환해야 합니다(MySQL, Oracle, Big Query, Redshift, Snowflake 등).• None Spark 쿼리 파싱 경우 (java 로직 개발로 해결해야 합니다)• None SELECT문보다 FROM문이 먼저 나온 경우 -> WITH문이나 SELECT문 이후로 변경• None ".숫자" 명을 가진 테이블 및 컬럼 경우 -> backtick 추가• None ParseStatement 클래스에서 INSERT문의 target 테이블, InsertStatementParser 클래스에서 WITH문의 target 테이블과 FROM문의 source 테이블을 추출합니다.• None Result는 결과 DTO를 출력한 것이며 쿼리 내 source, target 테이블 리스트입니다.이상으로 Ontology 생성 과정 중 Table Level Lineage 생성 과정에 대해 알아보았습니다.해당 결과를 여러 방향으로 활용할 수 있을 것을 기대합니다.

**Processing-In-Memory(PIM)**은 메모리 내부에 연산 기능(프로세싱 기능)을 탑재하여, 데이터를 이동시키지 않고 메모리 안에서 직접 처리하는 기술입니다.즉, CPU나 GPU가 아닌 메모리 자체가 연산을 수행함으로써, 데이터 이동을 줄이고 처리 속도를 극대화하는 혁신적인 반도체 아키텍처입니다.여기서 먼저 알아야 할 내용이 바로지금까지 대부분의 컴퓨터는 폰 노이만 구조라는 구조를 사용해 왔습니다.이 구조는 프로세서(CPU)와 메모리(DRAM)가 분리되어 있고, 데이터는 메모리에서 CPU로 오가며 처리되는 구조입니다.이런 구조에서는 데이터가 증가할 때 큰 세가지 문제가 발생 할 수 있습니다.• None 병목 현상: 데이터를 메모리에서 CPU로 가져오는 데 시간이 증가• None 전력 소모: 데이터 이동에 많은 전력 소모• None 속도 제한: 연산보다 데이터 전송 속도 저하로 전체 시스템 속도 제약위와 같은 폰 노이만 구조는 요즘 같은 인공지능, 빅데이터 분석, 머신러닝 등 데이터를 실시간으로 많이 처리 해야하는 상황에서 심각한 성능 저하와 전력 소모가 발생하게 됩니다.이러한 문제를 해결하기 위해 PIM 반도체가 등장합니다.PIM은 말 그대로 메모리 내부에서 연산을 수행한다(Processing In Memory)는 개념입니다.기존에는 기존에는 메모리는 데이터를 저장하는 역할만 하고, 연산은 CPU가 담당했습니다.하지만 PIM은 메모리 칩 내부에 연산 기능을 통합하여, 데이터를 CPU로 보내지 않고도 메모리 자체에서 직접 계산을 수행할 수 있도록 작동하는 반도체입니다.PIM은 구현 방식은 크게 두 가지 방식으로 나눌 수 있습니다.• None 기존 메모리 칩 내부에 간단한 연산 유닛(ALU: Arithmetic Logic Unit)을 추가하는 방식입니다. DRAM과 같은 범용 메모리 칩에 작은 프로세서를 넣어 데이터를 읽고 쓰는 과정에서 간단한 연산을 수행합니다.*ALU(산술 논리 연산 장치, Arithmetic Logic Unit)는 컴퓨터나 반도체 시스템에서 덧셈, 뺄셈 같은 산술 연산과 AND, OR 같은 논리 연산을 수행하는 부품연산 로직을 메모리 셀 자체에 통합(In-Memory Computing):• None 더 나아가 메모리 셀 자체의 물리적 특성을 활용하여 연산을 수행하는 방식입니다. 예를 들어, 저항성 메모리(ReRAM)나 상변화 메모리(PRAM)와 같은 차세대 비휘발성 메모리(NVM)는 데이터를 저장하는 동시에 논리 연산을 수행할 수 있는 잠재력을 가지고 있습니다. 이 기술이 최종 PIM의 지향점이라고 할 수 있습니다.삼성전자, SK하이닉스와 같은 기업들도 HBM-PIM, GDDR6-AIM 등 독자적인 PIM 솔루션을 선보이며 기술을 선도하고 있습니다.또한 PIM은 메모리나 프로세서의 성능 개선과 컴퓨터 아키텍처의 근본적인 변화를 가져올 수 있습니다.

안녕하세요. 29CM QA팀 Lead 박현준입니다.팀 내에서는 주로 테스트 자동화 환경과 프레임워크 개선의 업무를 주로 수행하고 있으며 팀원들의 자동화 업무와 엔지니어링 업무를 돕고 있습니다.전 인원이 QA Engineer로 구성된 팀이기 때문에 팀 내에서 기술교류가 활발하고 다양한 시도가 진행되고 있습니다 :)이번 내용은 기존에 구현되어 있지 않았지만 요청에 의해 테스트 자동화가 구현된 과정에 대한 이야기입니다.QA팀에 테스트 자동화 구현 요청이 오다.29CM 애플리케이션의 홈 화면은 카테고리별로 여러 개의 탭으로 구성되며, 각 탭에는 다양한 배너가 노출됩니다.이 배너들은 이벤트, 특가 상품, 기획전을 안내하는 중요한 기능을 담당하고 있습니다. 그래서 전략적으로 운영되어 수시로 변경, 추가가 이루어지며 운영되고 있는데, 이러한 배너는 평균적으로 100여 개 정도 노출되고 있고 많은 경우는 총 150여 개 정도까지 노출되기도 합니다.이렇게 배너에 사용할 수 있는 기능과 양이 많아짐으로써 자연스럽게 나타나는 현상이 있었습니다. 바로 휴먼에러(Human Error)입니다.사용자가 많아지고 배너 종류도 많아짐에 따라 관리 비용이 증가하게 되면서 휴먼에러의 발생 가능성도 높아졌습니다. 이러한 부분을 해소하고자 해당 배너를 관리하고 운영하는 조직에서 전문가 조직을 찾아오시게 됩니다.바로 QA팀 이죠  자동화 구축을 위한 사전 커뮤니케이션 진행 하기.29CM QA팀은 애플리케이션 및 API 테스트 자동화를 적극적으로 활용하여 운영 환경의 기능을 주기적으로 점검합니다. 하지만 배너는 테스트 자동화 대상에서 제외되어 있었는데, 여기에는 두 가지 이유가 있습니다.첫 번째는 배너의 수가 너무 많아 기존 애플리케이션 자동화 방식으로는 효율성이 떨어진다는 것입니다. 그리고 두 번째로는 자동으로 전환(Rolling) 되는 특성상 특정 배너를 제어하고 결과를 확인하기가 어렵다는 것이었습니다.따라서 새로운 접근 방식이 필요했고, 정확한 요구사항을 파악하기 위해 유관 부서와 논의를 진행했습니다. 그 결과, 자동화의 목표는 다음 세 가지로 정의되었습니다.홈배너의 Target Link로 이동했을 때 정상 이동되는지 확인한다.이동한 화면에 요소들이 잘 나오는지 확인한다.운영중인 모든 배너 Link를 검증 대상에 포함 한다.이렇게 구현할 항목이 정해졌고 QA팀은 작업에 착수하게 됩니다.MVP 버전 제작 하기.배너의 Target Link는 API 응답을 통해 쉽게 확보할 수 있었지만, 링크 이동 후 콘텐츠가 정상적으로 노출되는지 확인하는 과정은 UI(사용자 인터페이스)를 통해 검증해야 했습니다.사실 이 부분은 커뮤니케이션 미스였습니다. 밑에서 확인하실 수 있습니다.하지만 화면을 자주 이동해야 하기 때문에 Selenium보다 WEB에서의 수행 속도가 더 빠른 Playwright를 사용하여 WEB + Playwright의 조합으로 결정합니다.MVP의 자동화 로직은 다음과 같이 5단계로 설계했습니다.API로 받아온 Target Link를 List로 만들고 순차적으로 해당 링크에 이동하도록 합니다.링크 이동 후에는 화면을 하단으로 스크롤 하며 현재 화면에 있는 상품 이미지의 element 값을 수집합니다.수집된 element에 .click()을 바로 수행하지 않고 새 탭을 오픈합니다.오픈된 탭에서 수집된 element의 .click() 동작이 수행되도록 합니다.새 탭에서 상품 상세화면 이동을 검증하고 PASS일 경우 탭을 닫습니다.이렇게 Target Link내에 상품 이미지 Link가 모두 확인되면, 다음 Target Link 에서 테스트가 수행되도록 구성하였습니다.3번에서 페이지 내에서 직접 이동(.click()) 하지 않고 새 탭을 활용한 데에는 두 가지 이유가 있었습니다.1️ 첫번째. 페이지 이동 후 뒤로 가기 로 원래 페이지에 복귀하면 스크롤 위치가 초기화됩니다. 이 경우 다음 항목을 검증하기 위해 불필요한 스크롤을 다시 수행해야 합니다. 새 탭 방식은 기존 페이지의 상태를 그대로 유지하므로 테스트 흐름이 끊기지 않습니다.2️ 두번째. 뒤로 가기 로 이전 페이지로 이동하면 해당 페이지를 다시 로딩해야 하기때문에 시간이 추가로 소요됩니다. 반면, 필요한 페이지만 새 탭으로 열고 닫는 방식이라면 상품을 검증할 때마다 기존 페이지를 반복적으로 로딩하는 과정이 없기때문에 전체적인 검증 속도 면에서 훨씬 유리합니다.새 탭을 비동기적으로 열어 링크를 검증하는 과정에서 간혹 타이밍 문제가 발생했지만, 최적의 시간대를 찾는 것은 어렵지 않았습니다.이렇게 MVP 버전을 만들고 나서 지금 만들어진 것이 요청해 주신 그 자동화의 구성이 맞는지 확인하기 위해 바로 유관부서 분들을 찾아갔습니다.하지만 돌아온 대답은 저를 당황하게 했습니다.요청을 주신 건 이런 UI 자동화가 아니었다는 말이었거든요.이 이게 아니라구요?커뮤니케이션이 이렇게 중요합니다.빠르게 시연을 한 덕분에 방향이 잘못되었다는 것을 알고 다시 디테일한 사항을 다시 논의하게 됩니다.홈 배너의 Target Link로 이동했을 때 정상 이동되는지 확인한다. (문제가 발생한다면 잘못 입력된 Link에 의한 접근 불가이므로 이동의 가/불 여부만 체크된다면 충분하다.)운영 중인 모든 배너 Link를 검증 대상으로 한다.해당 논의 내용을 토대로 구현 방법을 다시 찾게 됩니다.하지만 이제는 UI 자동화로는 구현하지 않기로 합니다.앞서 MVP 버전을 만들 때 상품 링크 1개를 검증하는 데 약 1초가 소요되었습니다. 배너 하나에 포함된 상품이 30개, 전체 배너가 100개라고 가정하면, 모든 링크를 검증하는 데 최소 3,000초, 즉 50분이라는 긴 시간이 필요했습니다. 이는 빠른 검증 이라는 저희의 목표와는 거리가 멀었습니다.이렇게 시간이 오래 걸리기 때문에 초기 계획은 일단 시간을 투자하여 모든 배너를 전수 테스트하고, 테스트 당시의 배너 데이터를 가지고 있으면서 시간별로 추가되는 배너에 한해서 추가 테스트를 수행하려고 했었습니다.하지만 이제 상품까지 이동되는 과정을 검증하지 않는 것으로 하였기에 URL의 유효성만 확인하면 되는 것이었습니다. 그래서 UI로 진행할 이유가 없고 더

안녕하세요, 토스뱅크 Loan Tech Platform 팀에서 백엔드 개발 인턴으로 근무하고 있는 이경민, 문홍윤입니다.벌써 토스뱅크에 인턴으로 입사한 지 3개월이 지났습니다. 그동안 경험했던 토스뱅크의 개발 문화와 각자 진행한 프로젝트를 소개하고, 그 과정에서 느꼈던 고민과 배움들을 이 글에 정리해보려 해요.저희는 ‘금융’이라는 다소 낯선 도메인 위에서, 빠르게 움직이는 팀의 일원으로 각자의 역할과 프로젝트를 수행하며 조금씩 성장해 나갈 수 있었습니다. 처음 접하는 기술과 환경 속에서 어려움도 있었지만, 그 모든 순간이 저희에겐 좋은 자극이 되었고, 앞으로 어떤 개발자가 되고 싶은지 진지하게 고민할 수 있는 계기가 되었어요.그 결과, 인턴 최초로 서버 챕터 발표 무대에 설 수 있었던 특별한 경험까지 할 수 있었고, 이 과정에서 배운 것들을 기록으로 남기고자 합니다. 이 글이 토스에 관심 있는 분들이나 인턴십을 고민 중이신 분들께 조금이나마 도움이 되길 바랍니다.저희가 속한 Loan Tech Platform Team은 대출 도메인의 시스템을 효율적인 구조로 재설계하여 개발 생산성을 올리는 팀입니다.저는 “비효율적인 요소를 발굴 및 제거합니다”라는 팀의 목표에 맞게 플러그인을 개발했습니다.처음 은행 도메인을 접하면서 가장 어려웠던 점은 변수명을 보고도 무슨 의미인지 직관적으로 이해하기 어려운 경우가 많다는 점이었어요. 특히 도메인 특성상 복잡한 개념을 다루다 보니, 변수명은 길어지고, 사용하는 단어들도 낯설었죠.• None 같은 단어는 한눈에 파악하기 어려움또한 새로운 변수명을 만들 때 어떤 표현이 더 자연스러운지, 또 기존에 사용된 변수명이 있는지를 확인하고 중복되거나 어색한 이름을 피하는 것이 쉽지 않았어요.• None 이자계산 같은 단어도 → / 등 다양한 표현 중 어떤것을 사용하는지를 파악하기 어려움IDE에서 드래그 하고 단축키를 누르기만 하면 됩니다.기본적으로 DB에는 단어별로 뜻이 저장되어 있습니다. ex) 원금→principle, 상환→repayment하지만 보통 검색하는 단어는 합성단어인 경우이기 때문에 단어를 자동으로 분리하는 기능이 필요해요.• None NLP(OpenKoreanTextProcessorJava)를 사용해서 합성 단어를 단어로 분리해서 DB를 조회합니다• None 보통 변수명은 CamelCase(단어가 합쳐진 부분마다 맨 처음 글자를 대문자로 표기)로 만들어져 있기 때문에 대문자를 기준으로 단어를 분리해서 단어를 조회합니다.하지만 검색한 단어가 DB에 없을수도, 오타로 인해 원하는 단어를 검색 못할 가능성도 있습니다. 이럴 경우를 대비하여 새로운 단어의 추천, 오타 검증을 토스뱅크 내부에서 자체 구축된 LLM를 통해 지원했습니다.• None 검색한 단어들 중 DB에 존재하는 단어는 지원합니다.• None DB에 없는 단어는 앞뒤 문맥을 통해 LLM이 단어를 추천합니다.이처럼 똑같은 단어를 번역해도 앞 뒤 문맥을 보고 문맥상 더 적합한 단어를 추천해요.• None 오타는 앞 뒤 문맥을 보고 조정 후 단어를 검

안녕하세요 SK플래닛 DevRel 담당자입니다. 여러 곳에서 열리는 국내외 기술 세미나 & 컨퍼런스 주요 정보를 한 곳에 정리해 보았습니다. 저희 업무에도 활용할 겸 최신 정보를 정리하면서, 개발자 여러분들도 함께 참고하실 수 있도록 현재까지 공개된 주요 기술 행사 일정들을 공유드리오니 참고하시기 바랍니다.• 7월: TOSS MAKERS CONFERENCE 25 | Google I/O Extended Incheon 2025 | 한빛미디어 북토크('코드 너머' DevRel 세미나) | OKKY 7월 세미나: '개발자의 문장력'• 한줄설명: 올해 'Every Maker, Every Tech' 라는 주제로, 토스에서 프로덕트/디자인/개발 '통합' 컨퍼런스를 3일간 진행합니다 - 종전에는 SLASH(개발), Simplicity(디자인) 등으로 나누어 진행.• 참가자 신청: 7월 13일(일)까지 접수를 받습니다(무료, 추첨 후 7/16 결과발표) => https://toss.im/tmc-25• 참고사항(7/13 기준): 날짜별 주제가 상이하며, 편의를 위해 한 날짜만 신청 가능합니다.(예: Day3 - Engineering Day)• 한줄설명: Google I/O 현재 참관기 등 5개 트랙, 총 27개 세션 + Hands-on 워크숍 - Google 개발 생태계의 최신 기술과 현장의 목소리를 인천에서 만나세요!• 한줄설명: 삼성전자, 우아한형제들, SKT, 카카오페이, (전)토스 DevRel 실무자의 생생한 이야기를 소개합니다!• 참고사항: '코드 너머, 회사보다 오래 남을 개발자' 도서 출간 기념 북토크 행사입니다.• 한줄설명: 제목이 설명 그대로를 말해줍니다 : )• 참고사항(7/13 기준): CJ올리브영 DevRel Specialist 최가인 님께서 발표해 주십니다.• 한줄설명: 국내 최대 파이썬 컨퍼런스로 AI개발부터 파이썬 사용기까지 다양한 발표를 진행합니다(올해 주제: 'Weave with Python').• 참가자 신청: 7/13 현재 접수중(유료), 튜토리얼 티켓 판매(7/7-8/1), 일반 참가자/개인 후원자 티켓 판매(6/15-8/17, 소진시까지)• 기타: 파이콘 한국은 커뮤니티 주관으로 이루어지는 비영리 개발자 대상 행사로, 오픈 소스인 파이썬의 저변 확대 및 커뮤니티의 활성화를 목표로 합니다.• 한줄설명: FEConf는 국내외 프론트엔드 개발자들이 한자리에 모여 경험을 나누고, 기술의 흐름을 함께 만들어 가는 행사입니다(국내 최대 프론트엔드 개발자 행사).• 기타: 7/13 현재 위 링크를 통해 스피커(연사) 및 라이트닝 톡 발표자 모집을 받고 있습니다(후원사도...).(참고) 아쉽게도 매년 8월 열렸던 인프콘은, 올해는 열리지 않는다고 합니다(내년에...).• 한줄설명: KWDC(Koreawide Developer Conference) 주관 한국 애플 생태계 컨퍼런스(개발자, 기획자, 디자이너를 모두 아우르는 행사)• 한줄설명: 국내 최대 블록체인 행사로, 메인 컨퍼런스(IMPACT)와 다양한 사이드 이벤트를 진행합니다.• 참가자 신청: 7/13 현재 접수중 - https://tickets.koreablockchainweek.com/ (유료) (7/31까지 Early Bird 접수중, 이후 Regular & On-site Pass 접수)• 참고사항(7/13 기준): 최근 이슈가 되는 스테이블코인 이야기는 얼마나 나올까요? 관전 포인트 중 하나입니다.• 한줄설명: 래블업이 주최하는 기술 컨퍼런스 lab | up > /conf가 올해로 5회째를 맞이합니다. AI, HPC, 오픈소스 분야의 개발자와 엔지니어들이 모이는 래블업 컨퍼런스에서 경험과 인사이트를 얻어가세요!• 참고사항(7/13 기준): 발표자 신청을 받기 시작했습니다(7/14-8/3, 결과발표 8/8) - https://www.backend.ai/ko/event/lablup-conf-5th• 한줄설명: 국제 음악기술 컨퍼런스이나 올해는 국내에서 개최합니다(대전 카이스트).• 신청: https://ismir2025.ismir.net/Registration (유료) (Basic & General 기준으로 Early Bird: ~Aug 4, Regular: Aug 5 ~ Sep 20, On-site: Sep 21 ~ 25, 1day Pass도 있음)• 참고사항: ISMIR = International Society for Music Information Retrieval Conference (음악검색 테마를 중심으로 AI기술 내용/발표를 포함합니다)• 한줄설명: OpenAI에서 세 번째 개최하는 개발자 컨퍼런스입니다.• 신청: 7/13 현재 등록 알림메일 신청이 가능합니다 => https://www.devday.openai.com/• 참고사항: 2024년에는 샌프란, 런던, 싱가폴 세 곳에서 컨퍼런스를 진행했었습니다.• 참고사항: 샌프란에서 발표되는 내용을 중심으로, 2개월 전후로 국가별로 내용을 보강하여 매년 리캡 세미나를 진행하고 있습니다(예: UNIVERSE24 Recap Seoul, Tokyo 등).• 한줄설명: SK의 대표 기술 컨퍼런스인 SK TECH SUMMIT이 '24년부터 SK AI SUMMIT으로 새롭게 개최하였습니다.• 일시/장소: 11월 예정, 서울 코엑스 예정 (2024년에는 11/4 - 11/5, 코엑스에서 진행)• 참고사항(7/13 기준): Youtube에서 지난 AI SUMMIT & TECH SUMMIT 발표내용을 보실 수 있습니다 - https://www.youtube.com/@skaisummit2024• 참고사항(7/13 기준): (1)과는 별도의 행사로, MIT Technology Review를 발간하는 DMK Global에서 행사를 주관합니다.국내 주요 연례 컨퍼런스 중, 7/13 현재 일정 미공개 행사들입니다. 일정이 확정되면 상단으로 배치 예정입니다. (아래 이미지는 2024년 메인 페이지 스크린샷입니다)• 한줄설명: 네이버 연례 개발자 컨퍼런스로, 2024년에는 Deview와 통합하여 코엑스에서 2일간 진행하였습니다.• 참고사항(7/13 현재): 위 웹사이트에서