The Kotlin 2.2.20 release is out! This version delivers important changes for web development and other improvements. Learn more!

Kotlin 2.2.20 Released | The Kotlin Blog

며칠 전, Kotlin 2.2.20이 출시되었다. 여러 개선 사항 중에서도 가장 눈에 띄는 것은, Kotlin/Wasm이 드디어 베타 단계에 접어들었다는 소식이다.

이번 릴리스는 새로운 기능을 추가하기보다, 개발자 경험을 현실적인 수준으로 크게 개선하는 데 중점을 두었다고 한다. 자바스크립트와의 예외 처리 개선, 브라우저에서의 디버깅 지원 강화, npm 의존성 관리 향상 등은 이제 Kotlin/Wasm이 실험 수준을 넘어, 운영에 조심스럽게 고려할 수 있는 시점이 다가온듯 하다.

반년 전쯤 kotlinx.rpc 기술을 소개하는 발표를 준비하며 컴포즈 멀티플랫폼으로 작은 예제를 만들 때, 웹(Web) 타겟을 함께 시도했었다. 하지만 당시 웹 타겟과 Kotlin/Wasm은 알파 단계였고, 알 수 없는 오류에 디버깅이 너무 어려웠다. 여러 제약에 부딪히며 결국 웹 타겟은 아쉬움을 뒤로한 채 포기하고 Desktop, Android, iOS에서 동일하게 동작하는 앱을 만드는 수준에서 마무리지어야 했다.

Kotlin/Wasm의 베타 출시는 결국 컴포즈 멀티플랫폼의 웹 지원이 다음 단계로 나아갈 수 있는 발판이 될 것으로 기대된다. 언젠가 Compose for Web 역시 베타에 들어서면, 접어두었던 예제를 다시 꺼내 완성시켜보고 싶다.

최근 젯브레인의 행보를 보면, 코틀린 언어 자체의 변화 속도는 과거에 비해 다소 느려진 듯한 느낌이다. 하지만 멀티플랫폼이라는 큰 전략 안에서는 매 릴리스마다 의미 있는 전진을 멈추지 않고 있다. Android와 Server-side, Native, JavaScript를 넘어 이제 Wasm까지. 하나의 언어로 다양한 플랫폼을 아우르려는 그들의 담대한 도전이 한 걸음 더 현실에 다가온 것으로 보인다.

앞으로 이 기술을 바탕으로 업계에서 어떤 창의적인 사례들이 등장하게 될지, 꽤나 흥미진진한 마음으로 지켜보려 한다.


https://blog.jetbrains.com/kotlin/2025/09/kotlin-2-2-20-released/

며칠 전, Kotlin 2.2.20이 출시되었다. 여러 개선 사항 중에서도 가장 눈에 띄는 것은, Kotlin/Wasm이 드디어 베타 단계에 접어들었다는 소식이다. 이번 릴리스는 새로운 기능을 추가하기보다, 개발자 경험을 현실적인 수준으로 크게 개선하는 데 중점을 두었다고 한다. 자바스크립트와의 예외 처리 개선, 브라우저에서의 디버깅 지원 강화, npm 의존성 관리 향상 등은 이제 Kotlin/Wasm이 실험 수준을 넘어, 운영에 조심스럽게 고려할 수 있는 시점이 다가온듯 하다. 반년 전쯤 kotlinx.rpc 기술을 소개하는 발표를 준비하며 컴포즈 멀티플랫폼으로 작은 예제를 만들 때, 웹(Web) 타겟을 함께 시도했었다. 하지만 당시 웹 타겟과 Kotlin/Wasm은 알파 단계였고, 알 수 없는 오류에 디버깅이 너무 어려웠다. 여러 제약에 부딪히며 결국 웹 타겟은 아쉬움을 뒤로한 채 포기하고 Desktop, Android, iOS에서 동일하게 동작하는 앱을 만드는 수준에서 마무리지어야 했다. Kotlin/Wasm의 베타 출시는 결국 컴포즈 멀티플랫폼의 웹 지원이 다음 단계로 나아갈 수 있는 발판이 될 것으로 기대된다. 언젠가 Compose for Web 역시 베타에 들어서면, 접어두었던 예제를 다시 꺼내 완성시켜보고 싶다. 최근 젯브레인의 행보를 보면, 코틀린 언어 자체의 변화 속도는 과거에 비해 다소 느려진 듯한 느낌이다. 하지만 멀티플랫폼이라는 큰 전략 안에서는 매 릴리스마다 의미 있는 전진을 멈추지 않고 있다. Android와 Server-side, Native, JavaScript를 넘어 이제 Wasm까지. 하나의 언어로 다양한 플랫폼을 아우르려는 그들의 담대한 도전이 한 걸음 더 현실에 다가온 것으로 보인다. 앞으로 이 기술을 바탕으로 업계에서 어떤 창의적인 사례들이 등장하게 될지, 꽤나 흥미진진한 마음으로 지켜보려 한다. https://blog.jetbrains.com/kotlin/2025/09/kotlin-2-2-20-released/

The JetBrains Blog

베타 단계에 접어든 Kotlin/Wasm

사람이 조직을 떠나는 가장 큰 이유는 인간관계입니다. 관계가 틀어졌을 때 받는 스트레스는 무엇보다 큽니다. 아무리 관계 지향적이지 않은 사람이라도, 날카로운 대립 속에서 조직 생활을 편안하게 이어가기는 어렵습니다.


일보다 어려운 것이 인간관계입니다. 일은 열심히 하면 성과가 따라올 가능성이 높지만, 인간관계는 일방적인 노력에 비례해서 좋아지지 않기 때문입니다. 물론 노력하면 긍정적인 관계를 유지할 확률은 높아지지만, 어떻게 해도 맞지 않는 관계가 있는 것도 사실입니다. 이것이 인간관계의 묘한 속성입니다.


관계는 나이를 먹어도 여전히 어렵고 힘든 과제입니다. 상사와 부하, 동료와 동료, 관계의 종류에 따라 난이도가 달라집니다. 특히 각자의 고유한 성향이 관계에 큰 영향을 미칩니다. 성격이 원만한 사람, 각진 사람, 독특한 사람 등 저마다 다른 특성을 가진 만큼, 함께 지내기 쉬운 유형과 그렇지 않은 유형이 있습니다.


저는 비교적 다양한 유형의 사람들과 잘 지내려고 노력하는 편입니다. 오랜 직장 생활 동안 다양한 성격의 사람들을 만나며 인고의 세월을 보내다 보니, 관계에 어느 정도 내공이 생겼습니다. 그리고 관계가 나빠지면 결국 힘든 사람은 자신이라는 것을 깨달으면서, 화가 나고 억울한 일이 있어도 관계를 악화시키지 않으려고 애씁니다.
제 방법은 간단합니다. 항상 웃으려고 노력하는 것입니다. 이래도 허허, 저래도 허허, 바보처럼 웃으면 관계가 나빠지기 어렵습니다. 물론 이 방법이 최선이라고 생각하지는 않습니다. 때로는 과감하게 맞서고 자신의 입장을 분명히 하는 것도 필요합니다. 그런 대립도 감당할 수 있는 내공이 있다면 그래도 됩니다. 다만 저에게는 냉전을 견딜 용기와 굳은 의지가 없어서 대립을 피하는 편입니다. 손해를 봐도 그러려니, 억울한 일이 있어도 이 또한 지나가리라 하며 마음을 평온하게 유지하려고 노력합니다.


그런데 마음이 어디 쉽게 컨트롤 되나요? 저도 가끔 '욱'하는 순간이 있습니다. 열심히 일했는데 상사가 인정해주지 않거나 오히려 질책할 때는, 참을 '인'자를 떠올리기도 전에 화가 치밀어 오르기도 합니다. 그래서 관계 유형 중에서도 상사와는 특히 어색한 편입니다. 말수가 줄어들고 부드러운 관계가 되기 어려운 것 같습니다. 특히 상사가 보수적이거나 일방적인 소통을 하는 스타일이라면 더욱 그렇습니다.


관계가 어려워질 때 제가 주로 사용하는 방법은 회피입니다. 껄끄러운 상황을 피하는 것이죠. 피하고 또 피해서 최소한의 접촉만 어쩔 수 없이 짧게 하고 빠지는 겁니다. 그럼 마찰이 없을까요? 그럴 리가요. 관계에서 신기한 사실은 어렵다고 피할수록 더 깊고 어두운 함정에 빠진다는 것입니다. 회피는 순간적으로 편하자고 하는 모면책일 뿐, 근본적인 해결책이 아닙니다.


그럼에도 불구하고 저는 마흔이 넘도록 어려운 관계를 회피로 넘기고 있습니다. 더 정확히 말하면, 관계를 피함으로써 불편한 상황을 외면하고 있습니다. 그런다고 해결되는 것도 아니고 저절로 나아지는 것도 아닌데 말이죠. 참 답답한 노릇입니다. 그러다 관계가 곪아 터지면 결국 문제가 생깁니다. 직접 표현하지는 못하지만 '저 사람과는 더 이상 함께 일할 수 없다'고 생각하며 조직을 떠날 결심을 하게 되는 것이죠.


조직을 떠나서 해결되는 문제라면 100번이라도 이별해도 괜찮습니다. 안타깝게도 관계는 회피하거나 이별한다고 해서 다음에 더 좋은 관계를 만들 수 있는 것이 아닙니다. 다음에도 똑같이 어려운 관계를 만날 확률이 매우 높습니다. 왜냐하면 세상에는 다양한 유형의 사람이 있고, 어디를 가나 자신과 맞지 않는 유형의 사람은 반드시 존재한다는 법칙이 적용되기 때문입니다. 회피하고 도망치다 보면 갈 곳은 집 안뿐입니다.


하지만 사람은 혼자 살 수 없도록 설계된 존재입니다. 혼자서도 행복하다고 말하는 사람의 마음 깊은 곳에도 외로움이 스며있습니다. 다른 사람과 대화하고 부대끼며 느끼는 행복도 필요하게 만들어졌습니다. 관계만으로는 살 수 없고, 관계 없이도 살 수 없는 것이 인간입니다.
오늘 마음에 들지 않는 사람을 위해 긍정적인 마음으로 기도해보세요. 그 사람의 마음이 평안하고, 그 사람이 하는 일이 잘 되어서, 결국 나와의 관계도 부드러워지기를 바라는 것입니다. 이것이 가장 현명한 방법이라고 믿습니다. 싫다고 싸우고, 회피하고, 도망치는 것은 근본적인 해결책이 될 수 없습니다.
오늘도 어려운 관계를 뚫고 살아가기 위해 고군분투하는 모든 분들을 진심으로 응원합니다.

﻿사람이 조직을 떠나는 가장 큰 이유는 인간관계입니다. 관계가 틀어졌을 때 받는 스트레스는 무엇보다 큽니다. 아무리 관계 지향적이지 않은 사람이라도, 날카로운 대립 속에서 조직 생활을 편안하게 이어가기는 어렵습니다. 일보다 어려운 것이 인간관계입니다. 일은 열심히 하면 성과가 따라올 가능성이 높지만, 인간관계는 일방적인 노력에 비례해서 좋아지지 않기 때문입니다. 물론 노력하면 긍정적인 관계를 유지할 확률은 높아지지만, 어떻게 해도 맞지 않는 관계가 있는 것도 사실입니다. 이것이 인간관계의 묘한 속성입니다. 관계는 나이를 먹어도 여전히 어렵고 힘든 과제입니다. 상사와 부하, 동료와 동료, 관계의 종류에 따라 난이도가 달라집니다. 특히 각자의 고유한 성향이 관계에 큰 영향을 미칩니다. 성격이 원만한 사람, 각진 사람, 독특한 사람 등 저마다 다른 특성을 가진 만큼, 함께 지내기 쉬운 유형과 그렇지 않은 유형이 있습니다. 저는 비교적 다양한 유형의 사람들과 잘 지내려고 노력하는 편입니다. 오랜 직장 생활 동안 다양한 성격의 사람들을 만나며 인고의 세월을 보내다 보니, 관계에 어느 정도 내공이 생겼습니다. 그리고 관계가 나빠지면 결국 힘든 사람은 자신이라는 것을 깨달으면서, 화가 나고 억울한 일이 있어도 관계를 악화시키지 않으려고 애씁니다.제 방법은 간단합니다. 항상 웃으려고 노력하는 것입니다. 이래도 허허, 저래도 허허, 바보처럼 웃으면 관계가 나빠지기 어렵습니다. 물론 이 방법이 최선이라고 생각하지는 않습니다. 때로는 과감하게 맞서고 자신의 입장을 분명히 하는 것도 필요합니다. 그런 대립도 감당할 수 있는 내공이 있다면 그래도 됩니다. 다만 저에게는 냉전을 견딜 용기와 굳은 의지가 없어서 대립을 피하는 편입니다. 손해를 봐도 그러려니, 억울한 일이 있어도 이 또한 지나가리라 하며 마음을 평온하게 유지하려고 노력합니다. 그런데 마음이 어디 쉽게 컨트롤 되나요? 저도 가끔 '욱'하는 순간이 있습니다. 열심히 일했는데 상사가 인정해주지 않거나 오히려 질책할 때는, 참을 '인'자를 떠올리기도 전에 화가 치밀어 오르기도 합니다. 그래서 관계 유형 중에서도 상사와는 특히 어색한 편입니다. 말수가 줄어들고 부드러운 관계가 되기 어려운 것 같습니다. 특히 상사가 보수적이거나 일방적인 소통을 하는 스타일이라면 더욱 그렇습니다. 관계가 어려워질 때 제가 주로 사용하는 방법은 회피입니다. 껄끄러운 상황을 피하는 것이죠. 피하고 또 피해서 최소한의 접촉만 어쩔 수 없이 짧게 하고 빠지는 겁니다. 그럼 마찰이 없을까요? 그럴 리가요. 관계에서 신기한 사실은 어렵다고 피할수록 더 깊고 어두운 함정에 빠진다는 것입니다. 회피는 순간적으로 편하자고 하는 모면책일 뿐, 근본적인 해결책이 아닙니다. 그럼에도 불구하고 저는 마흔이 넘도록 어려운 관계를 회피로 넘기고 있습니다. 더 정확히 말하면, 관계를 피함으로써 불편한 상황을 외면하고 있습니다. 그런다고 해결되는 것도 아니고 저절로 나아지는 것도 아닌데 말이죠. 참 답답한 노릇입니다. 그러다 관계가 곪아 터지면 결국 문제가 생깁니다. 직접 표현하지는 못하지만 '저 사람과는 더 이상 함께 일할 수 없다'고 생각하며 조직을 떠날 결심을 하게 되는 것이죠. 조직을 떠나서 해결되는 문제라면 100번이라도 이별해도 괜찮습니다. 안타깝게도 관계는 회피하거나 이별한다고 해서 다음에 더 좋은 관계를 만들 수 있는 것이 아닙니다. 다음에도 똑같이 어려운 관계를 만날 확률이 매우 높습니다. 왜냐하면 세상에는 다양한 유형의 사람이 있고, 어디를 가나 자신과 맞지 않는 유형의 사람은 반드시 존재한다는 법칙이 적용되기 때문입니다. 회피하고 도망치다 보면 갈 곳은 집 안뿐입니다. 하지만 사람은 혼자 살 수 없도록 설계된 존재입니다. 혼자서도 행복하다고 말하는 사람의 마음 깊은 곳에도 외로움이 스며있습니다. 다른 사람과 대화하고 부대끼며 느끼는 행복도 필요하게 만들어졌습니다. 관계만으로는 살 수 없고, 관계 없이도 살 수 없는 것이 인간입니다.오늘 마음에 들지 않는 사람을 위해 긍정적인 마음으로 기도해보세요. 그 사람의 마음이 평안하고, 그 사람이 하는 일이 잘 되어서, 결국 나와의 관계도 부드러워지기를 바라는 것입니다. 이것이 가장 현명한 방법이라고 믿습니다. 싫다고 싸우고, 회피하고, 도망치는 것은 근본적인 해결책이 될 수 없습니다.오늘도 어려운 관계를 뚫고 살아가기 위해 고군분투하는 모든 분들을 진심으로 응원합니다.﻿

어려운 관계

과거 개인화 기술을 개발하던 때입니다. 고객에게 어떤 ‘서비스‘를 하고자 하는지, 서비스 철학과 그것이 만들어내는 경제적 가치(구매자, 판매자, 플랫폼 관점)와 편익은 무엇인지, 그래서 무엇을 지향해야 하는지 정의되어 있지 않았습니다. ’개인화 하면 좋아질거야‘라는 경영진의 막연한 기대가 있었고, 좋아진다라 함은 역시나 ‘매출’이었죠.

서비스 지향점을 위에서 정해주지 않는다면, 우리팀에서라도 찾아보고자 했습니다. 그 지향점 또는 가치는 부서마다 다른 관점을 갖고 있을 것이기에 조직간 협의가 선행되지 않는다면 결코 성공할 수 없고, 표면적으로/단기적으로 성공한 것처럼 보이더라도 반쪽짜리 성공이거나 오히려 장기적 악수가 될거라 봤습니다.

지속적으로 실험해가며 그걸 찾아내고자 했고, 여러 부서들의 문을 두드리며 토론을 이끌어내려 노력했습니다. 주변의 반응은 어땠을까요.

 * ”비즈니스의 목표는 돈을 버는 것이지, 왜 그 가치를 당신들이 정의하냐”
 * ”기술조직은 기술만 개발하면 된다. 너무 큰 얘기는 안했으면 좋겠다“
 * “매출 만드는 것이 중요한데, 너무 천천히 가는 것 아니냐”
 * “매출 지표로만 평가하면 되었지, 왜 클릭을 보냐. 결국 매출이 모든 것을 말하는 것 아니냐”
실험과 지표체계에 관심을 갖게된 건, 이 때 부터였습니다. 그 전까지만해도 그저 잘 정리된 체계를 갖춰야 하지 않을까 정도의 느낌이었다면, 그 체계가 비즈니스에 어떤 영향을 미치는지 온몸으로 체감했었습니다.

AI 기술이 하루가 다르게 발전하고 있지만, ‘서비스’의 본질은 다르지 않습니다. 지금은 AI 키워드가 화려해보이지만, 너무나 당연하게도 결국 그 키워드를 떼어내고 서비스 가치를 증명해내는 기업이 살아남을 겁니다.

”AI 서비스의 목표는 돈을 버는거니까, 답변 토큰을 늘리자”라는 식의 1차원적 사고는 결국 그 서비스를 망하게 합니다. 비즈니스의 목표는 돈을 버는 것이 아니라, 부가가치를 창출하는 것을 목표로 활동하면서 그 결과로 돈을 버는 것이죠. 이 차이를 이해하지 못하는 기업은 도태되고 말겁니다.

이런 맥락에서, “AI Product 팀” 이라는 과거 팀명에서 AI 키워드를 떼어내고, 이제는 “User Behavior팀” 에서 데이터 분석을 이끌고 있습니다. 그리고 그 분석이 비즈니스를 바꾸는 결과를 만들어내고자 고군분투하고 있구요 (어느새 반년이 되었네요).

——
(결국은 채용 메시지를 ㅎㅎ..)

이 변화를 만들어가는 과정에 가슴이 뛰는, 시니어 또는 리드급 데이터 분석가 팀동료를 구하고 있습니다 (채용 사이트에서의 포지션 오픈은 9월 말 정도가 될 것 같네요). 지원의사가 명확치 않으시다면 커피챗도 환영입니다. 부담없이 연락 주시기 바랍니다 :)

과거 개인화 기술을 개발하던 때입니다. 고객에게 어떤 ‘서비스‘를 하고자 하는지, 서비스 철학과 그것이 만들어내는 경제적 가치(구매자, 판매자, 플랫폼 관점)와 편익은 무엇인지, 그래서 무엇을 지향해야 하는지 정의되어 있지 않았습니다. ’개인화 하면 좋아질거야‘라는 경영진의 막연한 기대가 있었고, 좋아진다라 함은 역시나 ‘매출’이었죠. 서비스 지향점을 위에서 정해주지 않는다면, 우리팀에서라도 찾아보고자 했습니다. 그 지향점 또는 가치는 부서마다 다른 관점을 갖고 있을 것이기에 조직간 협의가 선행되지 않는다면 결코 성공할 수 없고, 표면적으로/단기적으로 성공한 것처럼 보이더라도 반쪽짜리 성공이거나 오히려 장기적 악수가 될거라 봤습니다. 지속적으로 실험해가며 그걸 찾아내고자 했고, 여러 부서들의 문을 두드리며 토론을 이끌어내려 노력했습니다. 주변의 반응은 어땠을까요. <ul><li>”비즈니스의 목표는 돈을 버는 것이지, 왜 그 가치를 당신들이 정의하냐”</li><li>”기술조직은 기술만 개발하면 된다. 너무 큰 얘기는 안했으면 좋겠다“</li><li>“매출 만드는 것이 중요한데, 너무 천천히 가는 것 아니냐”</li><li>“매출 지표로만 평가하면 되었지, 왜 클릭을 보냐. 결국 매출이 모든 것을 말하는 것 아니냐”</li></ul>실험과 지표체계에 관심을 갖게된 건, 이 때 부터였습니다. 그 전까지만해도 그저 잘 정리된 체계를 갖춰야 하지 않을까 정도의 느낌이었다면, 그 체계가 비즈니스에 어떤 영향을 미치는지 온몸으로 체감했었습니다. AI 기술이 하루가 다르게 발전하고 있지만, ‘서비스’의 본질은 다르지 않습니다. 지금은 AI 키워드가 화려해보이지만, 너무나 당연하게도 결국 그 키워드를 떼어내고 서비스 가치를 증명해내는 기업이 살아남을 겁니다. ”AI 서비스의 목표는 돈을 버는거니까, 답변 토큰을 늘리자”라는 식의 1차원적 사고는 결국 그 서비스를 망하게 합니다. 비즈니스의 목표는 돈을 버는 것이 아니라, 부가가치를 창출하는 것을 목표로 활동하면서 그 결과로 돈을 버는 것이죠. 이 차이를 이해하지 못하는 기업은 도태되고 말겁니다. 이런 맥락에서, “AI Product 팀” 이라는 과거 팀명에서 AI 키워드를 떼어내고, 이제는 “User Behavior팀” 에서 데이터 분석을 이끌고 있습니다. 그리고 그 분석이 비즈니스를 바꾸는 결과를 만들어내고자 고군분투하고 있구요 (어느새 반년이 되었네요). ——(결국은 채용 메시지를 ㅎㅎ..) 이 변화를 만들어가는 과정에 가슴이 뛰는, 시니어 또는 리드급 데이터 분석가 팀동료를 구하고 있습니다 (채용 사이트에서의 포지션 오픈은 9월 말 정도가 될 것 같네요). 지원의사가 명확치 않으시다면 커피챗도 환영입니다. 부담없이 연락 주시기 바랍니다&nbsp;:)

비즈니스가 돈만 벌려고 하면, 결국은 실패합니다.

성장을 도식화할 때는 보통 직선에 가까운 형태로 많이 그린다. 특정 방향(주로 오른쪽 위)을 향하는 직선이나 곡선, 혹은 계단 모양의 선으로 많이 그린다. 그런데 문득, 성장은 나선형으로 이루어지는 것이 아닐까 하는 생각이 들었다. 나선은 원을 반복해서 그리지만, 그 원의 크기를 조금씩 키우게 된다. 그러면서 점차 중심에서 먼 곳을 향해 나아간다. 만약 나선이 원의 크기를 키우지 못한다면, 같은 크기의 원만 계속 그리고 있게 된다.


때때로, 분명 전진하고 있는 것 같은데도 왠지 계속 제자리인 것 같은 느낌이 들 때가 있다. 성장을 위해 무언가 하고 있는 데도 나아진 것 같지 않을 때가 있다. 그럴 때면 혹시, 동일한 지름의 원을 계속 그리고 있는 것이 아닐까 생각해 볼 필요가 있다. 원의 크기를 키우는 활동은 하지 않고, 원을 그리는 것에만 집중하는 것은 아닐까 돌아볼 필요가 있다.


나선은 중심(나)으로부터 시작하지만 꾸준히 밖(타인)을 향하고 있다. 내가 아닌 것에 관심을 갖고, 내가 아닌 것을 이해하고자 하는 힘이 나선을 밖으로 향하게 한다. 그리고 그 크기를 키울 수 있게 한다. 사람의 성장도 마찬가지가 아닐까. 나에게 속박되어 있고, 내가 옳다고 믿는 것에만 머물러 있으면 계속 동일한 원을 그릴 수밖에 없다. 다른 사람의 생각에 관심을 갖고, 옳지 않다고 생각했던 것들까지 이해하려고 노력해야 우리는 이전보다 더 큰 원을 그릴 수 있게 된다. 나를 이해하는 것은 중요하지만, 나에게 묶여있지 않으려는 노력이 나를 더 큰 존재로 성장시켜 주는 것이다.


#성장 #얽매임 #관심

성장을 도식화할 때는 보통 직선에 가까운 형태로 많이 그린다. 특정 방향(주로 오른쪽 위)을 향하는 직선이나 곡선, 혹은 계단 모양의 선으로 많이 그린다. 그런데 문득, 성장은 나선형으로 이루어지는 것이 아닐까 하는 생각이 들었다. 나선은 원을 반복해서 그리지만, 그 원의 크기를 조금씩 키우게 된다. 그러면서 점차 중심에서 먼 곳을 향해 나아간다. 만약 나선이 원의 크기를 키우지 못한다면, 같은 크기의 원만 계속 그리고 있게 된다. 때때로, 분명 전진하고 있는 것 같은데도 왠지 계속 제자리인 것 같은 느낌이 들 때가 있다. 성장을 위해 무언가 하고 있는 데도 나아진 것 같지 않을 때가 있다. 그럴 때면 혹시, 동일한 지름의 원을 계속 그리고 있는 것이 아닐까 생각해 볼 필요가 있다. 원의 크기를 키우는 활동은 하지 않고, 원을 그리는 것에만 집중하는 것은 아닐까 돌아볼 필요가 있다. 나선은 중심(나)으로부터 시작하지만 꾸준히 밖(타인)을 향하고 있다. 내가 아닌 것에 관심을 갖고, 내가 아닌 것을 이해하고자 하는 힘이 나선을 밖으로 향하게 한다. 그리고 그 크기를 키울 수 있게 한다. 사람의 성장도 마찬가지가 아닐까. 나에게 속박되어 있고, 내가 옳다고 믿는 것에만 머물러 있으면 계속 동일한 원을 그릴 수밖에 없다. 다른 사람의 생각에 관심을 갖고, 옳지 않다고 생각했던 것들까지 이해하려고 노력해야 우리는 이전보다 더 큰 원을 그릴 수 있게 된다. 나를 이해하는 것은 중요하지만, 나에게 묶여있지 않으려는 노력이 나를 더 큰 존재로 성장시켜 주는 것이다. #성장 #얽매임 #관심

나선형의 성장

“OO기업, 고객정보 대규모 유출” 요즘 뉴스에서 이런 헤드라인 자주 보셨을 겁니다. 해커에 의해 수많은 고객정보 데이터가 유출됐다는 소식 말이죠. 이런 사고가 계속 반복되다 보니, “우리 회사는 괜찮을 거야”라고 더는 안심할 수 없게 됐습니다. 이제 우리가 가장 먼저 지켜야 할 자산은 바로 ‘데이터’입니다. 그렇다면 해커들은 왜 이렇게 집요하게 데이터를 노릴까요? 이번 글에서는 그들의 목적부터 이에 대응하는 데이터 보안 방법을 짚어보고자 합니다. 특히 데이터를 안전하게 지킬 수 있는 ‘암호화’와 ‘키 관리’의 중요성을 살펴보고, 실제 암호화 도입 전에 반드시 확인해야 할 6가지 체크리스트도 함께 정리했습니다.

기업 해킹 막으려면? 암호화 도입 전 챙겨야 할 6가지 | 요즘IT

해커는 회사를 가리지 않습니다. 누구든, 어떤 곳이든 해커의 표적이 될 수 있죠. 그렇다면 우리 회사의 데이터를 지키는 '보안'은 어떻게 준비해야 하는지, 암호화란 무엇이고, 왜 도입해야 하는지 등 기초적인 개념과 Q&A 등을 최대한 알기 쉽게, 필요한 내용들만 골라 정리해 봤습니다. 브랜디드로 준비했지만, 많은 분들께 도움이 될 만한 글이라 공유해봅니다. 🙂


https://yozm.wishket.com/magazine/detail/3348/

해커는 회사를 가리지 않습니다. 누구든, 어떤 곳이든 해커의 표적이 될 수 있죠. 그렇다면 우리 회사의 데이터를 지키는 '보안'은 어떻게 준비해야 하는지, 암호화란 무엇이고, 왜 도입해야 하는지 등 기초적인 개념과 Q&amp;A 등을 최대한 알기 쉽게, 필요한 내용들만 골라 정리해 봤습니다. 브랜디드로 준비했지만, 많은 분들께 도움이 될 만한 글이라 공유해봅니다. 🙂 https://yozm.wishket.com/magazine/detail/3348/

요즘IT

기업 해킹 막으려면? 암호화 도입 전 챙겨야 할 6가지

리액티브,액터모델,분산처리를 다루는 나만의 MCP메모리에 챗봇기능 탑재 - gpt-oss 온디바이스라 60토크 작동
액터모델을 이용한 분산처리 컨텐츠를 챗봇을 이용해서 정리된 정보를 탐색할수 있습니다.

링크 : https://mcp.webnori.com/ui/askbot

리액티브,액터모델,분산처리를 다루는 나만의 MCP메모리에 챗봇기능 탑재 - gpt-oss 온디바이스라 60토크 작동액터모델을 이용한 분산처리 컨텐츠를 챗봇을 이용해서 정리된 정보를 탐색할수 있습니다. 링크 : https://mcp.webnori.com/ui/askbot

나만의 메모리 챗봇

직장인을 위한 이솝우화 | 재능이 부족한 키타라 연주자가 있었다. 그는 벽에 회반죽을 두껍게 칠한 집에서 낮밤을 가리지 않고 노래를 불렀다. 벽이 그의 소리에 에코를 더하자, 그는 자신의 목소리가 매우 아름답다고 생각하게 되었다. 그래서 자신의 목소리를 과대평가한 그는, 극장에서 공연을 하기로 결심했다. 하지만, 무대에 선 그의 노래는 형편없었고, 사람들은 돌을 던져 그를 쫓아냈다.

기타라 연주자

좋은 말에 취하지 말자.
#직장인 #에세이 #자기객관화


https://brunch.co.kr/@drunkensky/792

좋은 말에 취하지 말자.#직장인 #에세이 #자기객관화 https://brunch.co.kr/@drunkensky/792

브런치

[직장인을 위한 이솝우화] 기타라 연주자

AI 도구를 활용한 코딩이 늘어나면서 팀원들에게서 흥미로운 변화를 목격하고 있습니다.

예전에는 테스트 작성이나 문서 업데이트를 부탁하면 온갖 핑계를 대며 피하던 동료들이, 이제는 누구보다 꼼꼼하게 이런 부분에 신경을 쓰는 거 있죠?

왜일까요?

코딩 에이전트에게 일을 맡기려면 명확한 스펙과 테스트가 필수라는 걸 체감했기 때문입니다. AI가 생성한 코드를 마음 놓고 배포하려면 철저한 검증이 필수이고, 모델에게 충분한 컨텍스트를 제공하려면 정확한 문서화가 중요하다는 것도 깨닫게 된 거죠.

솔직히 저는 이런 현상을 보면서 조금 서운한 마음이 들기도 합니다. 과거에 사람들끼리만 협업할 때도 이렇게 동료를 배려해줬다면 얼마나 좋았을까 싶거든요. 예전에 테스트도 없이 작성한 코드를 리뷰 요청하던 그 자신감은 도대체 다들 어디서 왔었을까 싶고요 ㅎㅎ

뭐, 어찌됐든 결과적으로는 긍정적입니다. 코드 커버리지가 개선되고, 리팩토링과 기능 추가도 훨씬 수월해졌습니다. 예전처럼 유닛 테스트나 문서화의 중요성을 강조하지 않아도 됩니다. 결국 AI가 개발 문화 개선의 촉매제 역할을 하고 있는 셈입니다.

여러분의 개발 팀은 어떠신가요? AI 도입 후 겪은 재미있는 변화가 있다면 공유해주세요!

AI 도구를 활용한 코딩이 늘어나면서 팀원들에게서 흥미로운 변화를 목격하고 있습니다. 예전에는 테스트 작성이나 문서 업데이트를 부탁하면 온갖 핑계를 대며 피하던 동료들이, 이제는 누구보다 꼼꼼하게 이런 부분에 신경을 쓰는 거 있죠? 왜일까요? 코딩 에이전트에게 일을 맡기려면 명확한 스펙과 테스트가 필수라는 걸 체감했기 때문입니다. AI가 생성한 코드를 마음 놓고 배포하려면 철저한 검증이 필수이고, 모델에게 충분한 컨텍스트를 제공하려면 정확한 문서화가 중요하다는 것도 깨닫게 된 거죠. 솔직히 저는 이런 현상을 보면서 조금 서운한 마음이 들기도 합니다. 과거에 사람들끼리만 협업할 때도 이렇게 동료를 배려해줬다면 얼마나 좋았을까 싶거든요. 예전에 테스트도 없이 작성한 코드를 리뷰 요청하던 그 자신감은 도대체 다들 어디서 왔었을까 싶고요 ㅎㅎ 뭐, 어찌됐든 결과적으로는 긍정적입니다. 코드 커버리지가 개선되고, 리팩토링과 기능 추가도 훨씬 수월해졌습니다. 예전처럼 유닛 테스트나 문서화의 중요성을 강조하지 않아도 됩니다. 결국 AI가 개발 문화 개선의 촉매제 역할을 하고 있는 셈입니다. 여러분의 개발 팀은 어떠신가요? AI 도입 후 겪은 재미있는 변화가 있다면 공유해주세요!

AI 덕분에 달라진 동료 개발자들

어제 게임 개발자를 꿈꾸는 분과 커리어 고민에 대해 이야기를 나누었습니다. 가장 큰 고민은 서류 전형 통과율이 낮다는 것이었습니다. 객관적인 피드백을 드리기 전에, 먼저 취업 준비 과정에서 받는 불합격 통보가 얼마나 마음을 힘들게 할지 마음이 아팠습니다. 빨리 취업해서 열심히 일하고 싶은데 기회가 주어지지 않는 답답함을 충분히 이해하고 있기 때문입니다.


사실 코칭을 시작하기 전에 깜짝 놀랐습니다. 미리 받아본 이력서의 내용이 정말 훌륭했거든요. 컴퓨터공학 전공에 두 번의 게임 개발자 인턴 경험, 개인 프로젝트까지, 그리고 이를 설명하는 내용도 신입이나 주니어 레벨에서는 보기 드문 수준이었습니다. 그런데도 채용 전형에서 계속 좋은 결과를 얻지 못하고 있다니, 요즘 취업 시장이 얼마나 어려운지 실감할 수 있었습니다.


이런 스펙과 경험을 가진 인재가 왜 서류 전형에서 좋은 평가를 받지 못할까 생각해보았습니다. 최근 30개 기업에 지원해서 서류 합격률이 약 10%, 즉 3개 기업에서만 합격했다고 하더군요. 수치상으로는 10%가 결코 낮은 확률은 아니지만, 게임 업계로 범위를 좁히면 채용 공고 자체가 적고 앞으로도 무한정 늘어나는 게 아니라서 지원자 입장에서는 더욱 답답할 수밖에 없습니다.


흥미로운 점은 상대적으로 지원자가 많은 대기업이나 중견기업에서는 서류 합격을 받았는데, 중소기업에서는 전부 탈락했다는 것입니다. 아마도 대기업에서는 서류 전형에서 눈에 띄는 스펙을 중요하게 보는 반면, 중소기업에서는 초기 단계부터 이력서의 기술 역량을 꼼꼼히 검토해서 자신들이 원하는 경험과 맞지 않다고 판단한 것 같습니다.


분명 두 번의 인턴과 개인 프로젝트가 괜찮아 보였는데 뭐가 부족하다는 걸까요? 두 가지 이유를 추측해봅니다.
첫 번째는 브랜드 인지도가 높은 큰 회사에서의 인턴 경험이 작은 기업 입장에서는 와닿지 않을 수 있다는 점입니다. 일하는 환경과 여건이 다르면 경험의 온도차도 달라서, 함께 일할 때 잘 적응할 수 있을지 의문이 들 수 있거든요. 예를 들어 큰 회사는 많은 동료와의 협업으로 시간과 자원을 확보할 수 있지만, 작은 회사는 한 사람이 감당해야 할 업무량이 훨씬 많을 수 있습니다.


두 번째는 개발한 게임을 실제로 출시한 경험이 부족하다는 점입니다. 다양한 기술로 기능을 구현해본 경험은 정말 훌륭하지만, 구현한 결과물을 대중에게 선보이지 않았다면 그 프로젝트의 의미가 반감됩니다. 개발한 게임이 실제로 사람들에게 사용되고, 그 피드백을 받아본 경험이 훨씬 높은 평가를 받거든요. 아쉽게도 이 멘티분은 게임 출시 경험이 부족해서 프로젝트가 단순히 이력서용으로만 느껴졌을 수 있습니다.


사소해 보이지만 큰 차이를 만드는 건 바로 지원동기입니다. 이 분은 그동안 지원동기를 작성하지 않고 지원했다고 하더군요. 이것도 서류 합격률이 낮았던 원인 중 하나일 겁니다. 채용 기업은 자신의 회사에 관심을 갖고 지원한 사람을 더 선호합니다. 반대로 말하면 회사에 대한 관심 없이 지원한 사람에게는 좋은 평가를 주기 어렵죠. 지원동기만큼 회사에 대한 관심을 잘 표현할 수 있는 방법도 없으니까요.


비슷한 맥락에서, 각 회사가 요구하는 채용 조건에 맞춰 이력서를 커스터마이징하지 않은 것도 아쉬운 부분입니다. 같은 게임 개발자 채용이라도 기업마다 중요하게 생각하는 포인트가 조금씩 다릅니다. 기술, 경험, 가치, 태도 등 각 기업이 강조하는 부분을 채용 공고를 통해 파악할 수 있어요. 기업이 선호하는 인재상을 이력서에 반영해서 어필하는 게 서류 합격 확률을 높이는 가장 효과적인 방법입니다.


물론 채용은 주관적인 판단이라 제 분석이 정답은 아닐 수 있습니다. 하지만 채용 기업이 어떤 인재를 원할지 상상해보고 준비하는 자세는 필요하다고 생각합니다. 그냥 내가 준비한 내용만 열심히 이야기하는 것보다 상대방이 듣고 싶어하는 이야기를 하는 게 누구에게나 더 매력적인 메시지가 되니까요.
하고 싶은 말보다 상대방이 듣고 싶은 이야기를 할 수 있는 공감의 자세를 가진 우리가 되길 진심으로 응원합니다.

﻿ 어제 게임 개발자를 꿈꾸는 분과 커리어 고민에 대해 이야기를 나누었습니다. 가장 큰 고민은 서류 전형 통과율이 낮다는 것이었습니다. 객관적인 피드백을 드리기 전에, 먼저 취업 준비 과정에서 받는 불합격 통보가 얼마나 마음을 힘들게 할지 마음이 아팠습니다. 빨리 취업해서 열심히 일하고 싶은데 기회가 주어지지 않는 답답함을 충분히 이해하고 있기 때문입니다. 사실 코칭을 시작하기 전에 깜짝 놀랐습니다. 미리 받아본 이력서의 내용이 정말 훌륭했거든요. 컴퓨터공학 전공에 두 번의 게임 개발자 인턴 경험, 개인 프로젝트까지, 그리고 이를 설명하는 내용도 신입이나 주니어 레벨에서는 보기 드문 수준이었습니다. 그런데도 채용 전형에서 계속 좋은 결과를 얻지 못하고 있다니, 요즘 취업 시장이 얼마나 어려운지 실감할 수 있었습니다. 이런 스펙과 경험을 가진 인재가 왜 서류 전형에서 좋은 평가를 받지 못할까 생각해보았습니다. 최근 30개 기업에 지원해서 서류 합격률이 약 10%, 즉 3개 기업에서만 합격했다고 하더군요. 수치상으로는 10%가 결코 낮은 확률은 아니지만, 게임 업계로 범위를 좁히면 채용 공고 자체가 적고 앞으로도 무한정 늘어나는 게 아니라서 지원자 입장에서는 더욱 답답할 수밖에 없습니다. 흥미로운 점은 상대적으로 지원자가 많은 대기업이나 중견기업에서는 서류 합격을 받았는데, 중소기업에서는 전부 탈락했다는 것입니다. 아마도 대기업에서는 서류 전형에서 눈에 띄는 스펙을 중요하게 보는 반면, 중소기업에서는 초기 단계부터 이력서의 기술 역량을 꼼꼼히 검토해서 자신들이 원하는 경험과 맞지 않다고 판단한 것 같습니다. 분명 두 번의 인턴과 개인 프로젝트가 괜찮아 보였는데 뭐가 부족하다는 걸까요? 두 가지 이유를 추측해봅니다.첫 번째는 브랜드 인지도가 높은 큰 회사에서의 인턴 경험이 작은 기업 입장에서는 와닿지 않을 수 있다는 점입니다. 일하는 환경과 여건이 다르면 경험의 온도차도 달라서, 함께 일할 때 잘 적응할 수 있을지 의문이 들 수 있거든요. 예를 들어 큰 회사는 많은 동료와의 협업으로 시간과 자원을 확보할 수 있지만, 작은 회사는 한 사람이 감당해야 할 업무량이 훨씬 많을 수 있습니다. 두 번째는 개발한 게임을 실제로 출시한 경험이 부족하다는 점입니다. 다양한 기술로 기능을 구현해본 경험은 정말 훌륭하지만, 구현한 결과물을 대중에게 선보이지 않았다면 그 프로젝트의 의미가 반감됩니다. 개발한 게임이 실제로 사람들에게 사용되고, 그 피드백을 받아본 경험이 훨씬 높은 평가를 받거든요. 아쉽게도 이 멘티분은 게임 출시 경험이 부족해서 프로젝트가 단순히 이력서용으로만 느껴졌을 수 있습니다. 사소해 보이지만 큰 차이를 만드는 건 바로 지원동기입니다. 이 분은 그동안 지원동기를 작성하지 않고 지원했다고 하더군요. 이것도 서류 합격률이 낮았던 원인 중 하나일 겁니다. 채용 기업은 자신의 회사에 관심을 갖고 지원한 사람을 더 선호합니다. 반대로 말하면 회사에 대한 관심 없이 지원한 사람에게는 좋은 평가를 주기 어렵죠. 지원동기만큼 회사에 대한 관심을 잘 표현할 수 있는 방법도 없으니까요. 비슷한 맥락에서, 각 회사가 요구하는 채용 조건에 맞춰 이력서를 커스터마이징하지 않은 것도 아쉬운 부분입니다. 같은 게임 개발자 채용이라도 기업마다 중요하게 생각하는 포인트가 조금씩 다릅니다. 기술, 경험, 가치, 태도 등 각 기업이 강조하는 부분을 채용 공고를 통해 파악할 수 있어요. 기업이 선호하는 인재상을 이력서에 반영해서 어필하는 게 서류 합격 확률을 높이는 가장 효과적인 방법입니다. 물론 채용은 주관적인 판단이라 제 분석이 정답은 아닐 수 있습니다. 하지만 채용 기업이 어떤 인재를 원할지 상상해보고 준비하는 자세는 필요하다고 생각합니다. 그냥 내가 준비한 내용만 열심히 이야기하는 것보다 상대방이 듣고 싶어하는 이야기를 하는 게 누구에게나 더 매력적인 메시지가 되니까요.하고 싶은 말보다 상대방이 듣고 싶은 이야기를 할 수 있는 공감의 자세를 가진 우리가 되길 진심으로 응원합니다.﻿

완벽한 이력서

안녕하세요. 한국 스프링 사용자 모임 (KSUG)에서 큰일꾼으로 활동하고 있는 김석현입니다. 😊

Spring Camp가 끝난 지 3개월이 되어가는 지금, 저는 10월 26일(일)에 있을 Spring AI Meetup을 준비하고 있습니다.

(행사를 기획하고 준비하는 과정이 저에게 즐거운 일일 줄은 몰랐는데, 한국 스프링 사용자 모임의 일꾼단에 지원했던 것이 정말 좋은 선택이었다고 생각합니다.)

Spring AI는 2025년 5월 20일 1.0.0 버전이 정식 릴리스된 지 4개월이 채 안 된 시점에서 스프링 팀과 커뮤니티의 활발한 기여에 힘입어 Streamable HTTP, MCP 관련 통합 및 각 모델별 지원 기능(e.g. Claude Prompt Caching) 등 다양한 개선 사항이 포함된 1.1.0-M1 버전이 (지난 9일) 공개되었습니다.
- https://lnkd.in/gSPx5dVg

이를 보면 Spring AI가 (아직 가야할 길은 남았지만) 빠른 속도로 발전하고 있다는 인상을 받습니다. 이런 흐름에 발맞춰 한국 스프링 사용자 모임에서 Spring AI를 집중적으로 다루는 자리를 마련하면 좋겠다고 생각하였고, 적극적으로 기여하시고 실무에서 사용하고 계신 연사님들을 모시고 실질적인 인사이트를 얻을 수 있는 자리를 마련하기 위해 열심히 준비하고 있습니다.

이번 행사는 선릉에서 진행될 예정이며, 홈페이지가 준비되는 대로 바로 공식 계정을 통해 공유해드리도록 하겠습니다. 

Spring AI Meetup에 많

Spring AI 1.1.0-M1 Available Now | SeokHyeon Kim

Spring AI는 스프링 생태계의 철학을 AI 도메인으로 확장하고자 등장한 프레임워크다. 그동안 AI 개발 도구와 라이브러리는 주로 파이썬 생태계를 중심으로 발전해왔다. 이 때문에 기업 환경에서 널리 쓰이는 자바는, 생성형 AI를 통합하기 위해 각 서비스의 SDK를 직접 사용하거나 원시적인 API 호출에 의존해야 하는 불편함이 있었다. Spring AI는 바로 이 지점에서, 스프링 사용자들이 기존의 친숙한 방식을 그대로 유지하면서 최신 AI 기능을 손쉽게 활용할 수 있도록 다리를 놓아준다.

Spring AI는 생성형 AI 통합의 복잡성을 단순화하고, 자주 사용되는 패턴들을 정립한다. 그 설계 철학의 핵심은 추상화와 이식성으로 보인다. ChatClient 나 VectorStore 같은 표준 인터페이스를 통해 OpenAI, Anthropic 등 각기 다른 LLM 제공자를 동일한 방식으로 다룰 수 있게 하고, 개발자가 특정 벤더의 세부사항에 얽매이지 않고 비즈니스 로직에 집중하도록 돕는다. 나아가, RAG(Retrieval-augmented generation)나 대화 메모리 같은 공통 기능을 Advisor 라는 개념으로 모듈화하여 횡단 관심사를 깔끔하게 처리한다.

특히 인상적인 부분은 AI에 익숙하지 않은 개발자를 위한 배려다. Spring AI 공식 문서에는 AI 모델의 작동 원리부터 다양한 모델 유형에 대한 설명까지, AI 입문자를 위한 내용이 충실하게 담겨 있다. 효과적인 프롬프트 작성법, 텍스트의 의미를 벡터로 표현하는 임베딩, 비용과 직결되는 토큰의 개념 등 AI 애플리케이션 개발에 필수적인 기초 지식을 체계적으로 안내한다. 더불어, AI 모델에서 구조화된 출력을 얻는 방법이나 RAG 및 도구 호출(Tool Calling)을 통해 외부 데이터와 기능을 연동하는 고급 기법까지 상세히 다룬다. AI 분야가 낯선 분들이라면 꼭 한번 읽어보길 권하고 싶다.

마침 한국 스프링 사용자 모임에서 Spring AI 밋업을 준비하고 있다. 이번 기회를 통해 많은 분들이 이 새로운 기술에 관심을 갖고 함께 이야기를 나눠보는 자리가 되었으면 한다.


https://www.linkedin.com/posts/seokhyeon-kim-6674501b2_spring-ai-110-m1-available-now-activity-7372620269003345920-glaB?utm_source=social_share_send&utm_medium=member_desktop_web&rcm=ACoAABvezLwBBEWVnGUkIY_xxm2aE3-sGtVHt0g

Spring AI는 스프링 생태계의 철학을 AI 도메인으로 확장하고자 등장한 프레임워크다. 그동안 AI 개발 도구와 라이브러리는 주로 파이썬 생태계를 중심으로 발전해왔다. 이 때문에 기업 환경에서 널리 쓰이는 자바는, 생성형 AI를 통합하기 위해 각 서비스의 SDK를 직접 사용하거나 원시적인 API 호출에 의존해야 하는 불편함이 있었다. Spring AI는 바로 이 지점에서, 스프링 사용자들이 기존의 친숙한 방식을 그대로 유지하면서 최신 AI 기능을 손쉽게 활용할 수 있도록 다리를 놓아준다. Spring AI는 생성형 AI 통합의 복잡성을 단순화하고, 자주 사용되는 패턴들을 정립한다. 그 설계 철학의 핵심은 추상화와 이식성으로 보인다. ChatClient 나 VectorStore 같은 표준 인터페이스를 통해 OpenAI, Anthropic 등 각기 다른 LLM 제공자를 동일한 방식으로 다룰 수 있게 하고, 개발자가 특정 벤더의 세부사항에 얽매이지 않고 비즈니스 로직에 집중하도록 돕는다. 나아가, RAG(Retrieval-augmented generation)나 대화 메모리 같은 공통 기능을 Advisor 라는 개념으로 모듈화하여 횡단 관심사를 깔끔하게 처리한다. 특히 인상적인 부분은 AI에 익숙하지 않은 개발자를 위한 배려다. Spring AI 공식 문서에는 AI 모델의 작동 원리부터 다양한 모델 유형에 대한 설명까지, AI 입문자를 위한 내용이 충실하게 담겨 있다. 효과적인 프롬프트 작성법, 텍스트의 의미를 벡터로 표현하는 임베딩, 비용과 직결되는 토큰의 개념 등 AI 애플리케이션 개발에 필수적인 기초 지식을 체계적으로 안내한다. 더불어, AI 모델에서 구조화된 출력을 얻는 방법이나 RAG 및 도구 호출(Tool Calling)을 통해 외부 데이터와 기능을 연동하는 고급 기법까지 상세히 다룬다. AI 분야가 낯선 분들이라면 꼭 한번 읽어보길 권하고 싶다. 마침 한국 스프링 사용자 모임에서 Spring AI 밋업을 준비하고 있다. 이번 기회를 통해 많은 분들이 이 새로운 기술에 관심을 갖고 함께 이야기를 나눠보는 자리가 되었으면 한다. https://www.linkedin.com/posts/seokhyeon-kim-6674501b2_spring-ai-110-m1-available-now-activity-7372620269003345920-glaB?utm_source=social_share_send&amp;utm_medium=member_desktop_web&amp;rcm=ACoAABvezLwBBEWVnGUkIY_xxm2aE3-sGtVHt0g

kr.linkedin.com

Spring AI는 생성형 AI 통합을 단순화하고 패턴을 정립한다

이제 처음 개발에 뛰어드는 사람들이 AI를 통해 뭔가를 만들 때 버셀, 수파베이스 같은 걸로 서비스 하는 사람들이 대부분 아닐까요?

호구 개발자를 위한 비즈니스

이제 처음 개발에 뛰어드는 사람들이 AI를 통해 뭔가를 만들 때 버셀, 수파베이스 같은 걸로 서비스 하는 사람들이 대부분 아닐까요?

하지만 서비스가 커지기 시작했을 때 이들에게 지불해야 하는 가격은 잘 계산해보지 않는 것 같습니다.
그건 그때가서 생각해보자는 마음으로.

버셀이나 수파베이스 창업자는 “맞아 맞아, 그때가서 생각해보면 돼!” 하고 함박웃음을 지으며 맞장구를 쳐줄 것 같네요.

물론 그때가서 생각해봐도 됩니다. 빨리 빠져나올 수 있는 실력이 있다면요.
하지만 컴퓨터공학에 대한 지식 없이는 쉽지 않을 겁니다.
겨우 벌기 시작한 돈을 그들에게 다 갖다 바치는 꼴이 될 수 있습니다.

사실 이게 지금 일어나고 있는 일들입니다.
그러니깐… 컴퓨터공학을 하나도 모르고 뛰어드는 뉴비들의 돈을 받아 먹는 커다란 비즈니스가 열리고 있습니다.

계속 컴퓨터 공학을 깊이 파고 들어야 하는 이유가 여기있습니다.
어떤 사람은 겨우 수익이 나기 시작한 서비스에 월 100만 원을 쓰는데, 어떤 사람은 돈을 전혀 내지 않고 서비스를 운영합니다.
운영 비용을 절감하는 것도 실력입니다. 엄청난 경쟁 우위 아닌가요?
AI로 코딩을 하면서 뭔가를 만들어 보고 즐거움을 느끼는 것은 좋지만, 더 깊숙한 곳으로 들어가려고 노력하지 않는다면 결국에는 차이를 만들어 낼 수 없습니다.


https://jeho.page/essay/2025/09/08/sucker-developer.html

이제 처음 개발에 뛰어드는 사람들이 AI를 통해 뭔가를 만들 때 버셀, 수파베이스 같은 걸로 서비스 하는 사람들이 대부분 아닐까요? 하지만 서비스가 커지기 시작했을 때 이들에게 지불해야 하는 가격은 잘 계산해보지 않는 것 같습니다. 그건 그때가서 생각해보자는 마음으로. 버셀이나 수파베이스 창업자는 “맞아 맞아, 그때가서 생각해보면 돼!” 하고 함박웃음을 지으며 맞장구를 쳐줄 것 같네요. 물론 그때가서 생각해봐도 됩니다. 빨리 빠져나올 수 있는 실력이 있다면요. 하지만 컴퓨터공학에 대한 지식 없이는 쉽지 않을 겁니다. 겨우 벌기 시작한 돈을 그들에게 다 갖다 바치는 꼴이 될 수 있습니다. 사실 이게 지금 일어나고 있는 일들입니다. 그러니깐… 컴퓨터공학을 하나도 모르고 뛰어드는 뉴비들의 돈을 받아 먹는 커다란 비즈니스가 열리고 있습니다. 계속 컴퓨터 공학을 깊이 파고 들어야 하는 이유가 여기있습니다. 어떤 사람은 겨우 수익이 나기 시작한 서비스에 월 100만 원을 쓰는데, 어떤 사람은 돈을 전혀 내지 않고 서비스를 운영합니다. 운영 비용을 절감하는 것도 실력입니다. 엄청난 경쟁 우위 아닌가요? AI로 코딩을 하면서 뭔가를 만들어 보고 즐거움을 느끼는 것은 좋지만, 더 깊숙한 곳으로 들어가려고 노력하지 않는다면 결국에는 차이를 만들어 낼 수 없습니다. https://jeho.page/essay/2025/09/08/sucker-developer.html

K리그 프로그래머

AI시대에도 컴퓨터 공학을 공부해야 하는 이유

유지보수성과 확장성을 동시에 잡는 설계 원칙
많은 프로젝트가 초반에는 잘 돌아갑니다.
하지만 몇 달만 지나도 코드가 복잡해지고,
작은 수정 하나에도 전체가 흔들리기 시작합니다.

왜 그럴까요?
유지보수성과 확장성 사이에는
트레이드 오프가 숨어있기 때문입니다.

유지보수만 고려하면
때로는 과도한 설계가 필요 없어지고
간단하게 만드는게 좋습니다.
다만 이후 기능 추가시에는
점점더 복잡도가 올라가게 됩니다.

반대로 확장성만 고려하면
처음부터 과도한 설계를 할 확률이 커집니다.

Product Engineer는 이 균형을 잡아야 합니다.
제가 중요하게 생각하는 원칙은 세 가지입니다.

1. 경계를 먼저 설계하기
읽기와 쓰기, 서버와 클라이언트, 도메인과 인프라.
경계가 명확해야 유지보수성과 확장성 사이
균형을 잡을 수 있습니다.

2. 의도를 코드 구조에 드러내기
“이 컴포넌트는 절대 상태를 갖지 않는다”
“여기는 반드시 사용자 이벤트를 포함한다”
이런 설계 의도를 구조로 남겨야 수정이 쉽습니다.

3. 변경 가능성과 안정성을 분리하기
자주 바뀌는 영역과
절대 바뀌지 말아야 하는 영역을 구분하세요.
안정된 부분은 Entities로,
변경이 일어나는 부분을 mapper 로 감싸서
안정된 부분을 변경으로부터 격리합니다.

AI 시대에도 이 원칙은 그대로 유효합니다.
AI가 구현을 대신해줄수록,
우리는 설계의 균형을 잡는 일에 집중해야 합니다.

혹시 여러분은
지금 하고 있는 프로젝트가
유지보수성과 확장성 사이의 균형을
잘 잡고 있다고 느끼시나요?

유지보수성과 확장성을 동시에 잡는 설계 원칙 많은 프로젝트가 초반에는 잘 돌아갑니다. 하지만 몇 달만 지나도 코드가 복잡해지고, 작은 수정 하나에도 전체가 흔들리기 시작합니다. 왜 그럴까요? 유지보수성과 확장성 사이에는 트레이드 오프가 숨어있기 때문입니다. 유지보수만 고려하면 때로는 과도한 설계가 필요 없어지고 간단하게 만드는게 좋습니다. 다만 이후 기능 추가시에는 점점더 복잡도가 올라가게 됩니다. 반대로 확장성만 고려하면 처음부터 과도한 설계를 할 확률이 커집니다. Product Engineer는 이 균형을 잡아야 합니다. 제가 중요하게 생각하는 원칙은 세 가지입니다. 1. 경계를 먼저 설계하기 읽기와 쓰기, 서버와 클라이언트, 도메인과 인프라. 경계가 명확해야 유지보수성과 확장성 사이 균형을 잡을 수 있습니다. 2. 의도를 코드 구조에 드러내기 “이 컴포넌트는 절대 상태를 갖지 않는다” “여기는 반드시 사용자 이벤트를 포함한다” 이런 설계 의도를 구조로 남겨야 수정이 쉽습니다. 3. 변경 가능성과 안정성을 분리하기 자주 바뀌는 영역과 절대 바뀌지 말아야 하는 영역을 구분하세요. 안정된 부분은 Entities로, 변경이 일어나는 부분을 mapper 로 감싸서 안정된 부분을 변경으로부터 격리합니다. AI 시대에도 이 원칙은 그대로 유효합니다. AI가 구현을 대신해줄수록, 우리는 설계의 균형을 잡는 일에 집중해야 합니다. 혹시 여러분은 지금 하고 있는 프로젝트가 유지보수성과 확장성 사이의 균형을 잘 잡고 있다고 느끼시나요?

유지보수성과 확장성을 동시에 잡는 설계 원칙
많은 프로젝트가 초반

1. 찰리 멍거의 커리어에 관한 3가지 조언은 선물과 같습니다.

2. 네가 사지 않을 것을 팔지 마라. 존중하고 존경하지 않는 사람 밑에서 일하지 마라. 좋아하는 사람하고만 같이 일하라.

3. 왜 자기가 사지 않을 물건을 팔면 안 될까요? 무언가를 파는 것에 관해 쓴 어떤 책이든 제품을 좋아하지 않거나, 이해하기 힘들거나, 믿지 않는다면, 그 제품을 파는 건 재앙이 될 것이라 말하기 때문입니다.

4. 위대한 영업자는 자기 상품을 믿습니다. 그게 성공의 비결 중 하나입니다.

5. 왜 존경하지 않는 사람과 일을 하면 안 될까요? 그가 가르쳐 줄 것이 없고, 지성과 삶이 나아가도록 돕지 못하기 때문입니다.

6. 왜 좋아하지 않는 사람과 같이 일하면 안 될까요? 일은 삶이고, 부유한 삶의 척도 중 하나는 자기 일을 좋아하고 함께 시간을 보내는 사람을 좋아하는 것이기 때문입니다.

7. 일터에서 일하면서 비참함을 느낀다면, 아무리 많은 돈을 벌어도 그건 너무나 안타까운 삶입니다.


#찰리멍거의말들

1. 찰리 멍거의 커리어에 관한 3가지 조언은 선물과 같습니다. ​2. 네가 사지 않을 것을 팔지 마라. 존중하고 존경하지 않는 사람 밑에서 일하지 마라. 좋아하는 사람하고만 같이 일하라. ​3. 왜 자기가 사지 않을 물건을 팔면 안 될까요? 무언가를 파는 것에 관해 쓴 어떤 책이든 제품을 좋아하지 않거나, 이해하기 힘들거나, 믿지 않는다면, 그 제품을 파는 건 재앙이 될 것이라 말하기 때문입니다. ​4. 위대한 영업자는 자기 상품을 믿습니다. 그게 성공의 비결 중 하나입니다. ​5. 왜 존경하지 않는 사람과 일을 하면 안 될까요? 그가 가르쳐 줄 것이 없고, 지성과 삶이 나아가도록 돕지 못하기 때문입니다. ​6. 왜 좋아하지 않는 사람과 같이 일하면 안 될까요? 일은 삶이고, 부유한 삶의 척도 중 하나는 자기 일을 좋아하고 함께 시간을 보내는 사람을 좋아하는 것이기 때문입니다. ​7. 일터에서 일하면서 비참함을 느낀다면, 아무리 많은 돈을 벌어도 그건 너무나 안타까운 삶입니다. #찰리멍거의말들

< 찰리 멍거가 말하는 커리어의 3가지 규칙 >

다정함은 자존감에서 나온다.
다정한 사람이 되려면
나를 먼저 아껴야 한다.
나를 아끼는 마음에서
자존감이 피어나고,
그 자존감이 사람과의 관계를
따뜻하게 만든다.
⠀
이해인, 『다정한 사람이 이긴다』

다정함은 자존감에서 나온다.다정한 사람이 되려면나를 먼저 아껴야 한다.나를 아끼는 마음에서자존감이 피어나고,그 자존감이 사람과의 관계를따뜻하게 만든다.⠀이해인, 『다정한 사람이 이긴다』

《다정함은 나를 아끼는 마음에서 온다》  ⠀

늘 "더 열심히 해라"라는 말을 들으면서 한국에서 직장 생활을 했습니다. 주변에 워낙 치열하게 일하는 분들이 많다 보니, 웬만큼 노력해서는 명함도 못 내미는 경우가 많았죠.

해외에서도 "난 열심히 해"라고 말하는 사람들이 많습니다. 그런데 막상 함께 일해보면, 한국에서 제가 생각했던 "열심히"와는 거리가 있는 경우가 많아요. 여기서 열심히 한다는 건 그냥 평소보다 조금 더 신경 쓰는 수준일 때가 많습니다. 그런데도 본인은 엄청 열심히 했다며 호들갑을 떱니다. 😅 (물론 이곳의 기준에서는 맞을 겁니다.)

그래서 세계 각지에서 커리어를 쌓고 계신 한국인 분들과 얘기하다 보면, "한국에서 하던 거 반도 안 했는데, 일 잘 한다고 칭찬받아서 놀랬어요!"라며 공감대가 형성되곤 합니다.

어렸을 때 부터 몸에 밴 한국인의 근면함은 세계 어디서든 빛을 발합니다. 어렸을 때 부터 몸에 밴 한국인의 근면함은 세계 어디서든 빛을 발합니다. 앞으로 더 많은 분들이 이 글로벌 경쟁력을 국내에서만 썩히지 마시고 해외에서 마음껏 펼치셨으면 좋겠어요!

늘 "더 열심히 해라"라는 말을 들으면서 한국에서 직장 생활을 했습니다. 주변에 워낙 치열하게 일하는 분들이 많다 보니, 웬만큼 노력해서는 명함도 못 내미는 경우가 많았죠. 해외에서도 "난 열심히 해"라고 말하는 사람들이 많습니다. 그런데 막상 함께 일해보면, 한국에서 제가 생각했던 "열심히"와는 거리가 있는 경우가 많아요. 여기서 열심히 한다는 건 그냥 평소보다 조금 더 신경 쓰는 수준일 때가 많습니다. 그런데도 본인은 엄청 열심히 했다며 호들갑을 떱니다. 😅 (물론 이곳의 기준에서는 맞을 겁니다.) 그래서 세계 각지에서 커리어를 쌓고 계신 한국인 분들과 얘기하다 보면, "한국에서 하던 거 반도 안 했는데, 일 잘 한다고&nbsp;칭찬받아서 놀랬어요!"라며 공감대가 형성되곤 합니다. 어렸을 때 부터 몸에 밴 한국인의 근면함은 세계 어디서든 빛을 발합니다. 어렸을 때 부터 몸에 밴 한국인의 근면함은 세계 어디서든 빛을 발합니다. 앞으로 더 많은 분들이 이 글로벌 경쟁력을 국내에서만 썩히지 마시고 해외에서 마음껏 펼치셨으면 좋겠어요!

해외에서는 덜 열심히 해도 인정받는 이유

최근에 누군가 내게 "기술을 어떻게 학습하시나요?"라는 질문을 한 적이 있다. 머릿속에는 정말 다양한 생각들이 스쳤지만, 나는 그중에서도 가장 중요하다고 생각하는 한 가지를 답했다. 기술을 배우는 데 필요한 것은 딱 하나, 충분한 관심이라고 생각한다. 여기서 말하는 관심은 그저 흥미로 끝나는 것이 아니라, 끊임없이 관찰하고 확인하고 왜를 고민해보는 적극적인 호기심을 의미한다.


내 경험상 어떤 기술을 깊이 있게 배우기 위해서는 그 대상에 대한 충분한 관심이 있어야 했다. 관심은 단순한 흥미를 넘어서 지속적인 탐구심과 동기부여로 이어진다. 내가 어떤 주제에 강한 관심을 갖게 되면, 문제를 끝까지 풀어보고자 하는 인내심이 생기고, 모르는 것을 즐겁게 파고들 수 있는 열의가 생겨났다. 결국 관심이 커야 기술 지식을 깊게 파고들 수 있는 힘이 생긴다. 진정으로 관심이 있을 때 비로소 새로운 개념을 찾아보고 배우는 과정 자체를 즐기게 되었다.


관찰은 내 학습의 첫걸음이었다. 주변의 좋은 코드나 뛰어난 동료의 작업 방식을 유심히 살펴보는 것만으로도 많은 것을 배울 수 있다. 나 역시 과거 스프링 프레임워크의 코드를 한 줄 한 줄 따라 읽으며, 책으로는 얻기 어려웠던 객체 지향 설계의 살아있는 지혜를 얻었던 경험이 있다. 코드 리뷰를 할 때도 마찬가지다. 단순히 코드를 훑어보는 것을 넘어, 이 코드가 왜 이렇게 작성되었을지 그 의도를 헤아려보며 관찰하고, 궁금한 점은 동료에게 직접 물어보며 내가 놓쳤던 배경과 맥락을 배운다.


확인은 배움의 깊이를 더하는 필수적인 과정이다. 나는 어설픈 짐작으로 아는 척 넘어가는 것을 경계한다. 새로운 API를 공부할 때면, 문서만 읽고 끝내는 대신 작은 테스트 코드를 작성해 내 예상이 맞는지 직접 확인해 본다. 이 간단한 검증 과정이 내가 무엇을 알고 무엇을 모르는지를 명확하게 해준다. 직접 확인하는 습관을 가진 개발자와 그렇지 않은 개발자 사이의 실력 차이는 시간이 지날수록 크게 벌어질 수밖에 없다.


마지막으로 '왜?'라는 질문을 던지는 습관은 얕은 지식을 깊은 지혜로 바꾸는 비결이다. 어떤 기술을 접할 때 그저 사용법만 익히는 것이 아니라, "왜 이런 구조를 선택했을까?", "다른 방식이 아닌 이 방법의 장점은 무엇일까?" 하고 근본적인 이유를 파고드는 것이다. 이런 질문은 기술의 철학을 이해하게 하고, 실무에서 마주하는 문제의 본질을 꿰뚫어 볼 수 있는 힘을 길러준다. 또한, 동료들과 '왜?'라는 질문을 주고받는 문화는 개인을 넘어 팀 전체의 기술적 깊이를 더하는 가장 좋은 방법이기도 하다.


돌아보면, 기술은 시대에 따라 계속 변했지만 그것을 배우는 나의 자세는 아직 그대로다. 오늘도 충분한 관심을 바탕으로 관찰하고, 확인하고, 끊임없이 '왜'를 묻는 내가 있다면, 내일 어떤 새로운 기술이 나타나더라도 단단해진 실력으로 그것을 온전히 내 것으로 만들 수 있으리라 믿는다.

최근에 누군가 내게 "기술을 어떻게 학습하시나요?"라는 질문을 한 적이 있다. 머릿속에는 정말 다양한 생각들이 스쳤지만, 나는 그중에서도 가장 중요하다고 생각하는 한 가지를 답했다. 기술을 배우는 데 필요한 것은 딱 하나, 충분한 관심이라고 생각한다. 여기서 말하는 관심은 그저 흥미로 끝나는 것이 아니라, 끊임없이 관찰하고 확인하고 왜를 고민해보는 적극적인 호기심을 의미한다. 내 경험상 어떤 기술을 깊이 있게 배우기 위해서는 그 대상에 대한 충분한 관심이 있어야 했다. 관심은 단순한 흥미를 넘어서 지속적인 탐구심과 동기부여로 이어진다. 내가 어떤 주제에 강한 관심을 갖게 되면, 문제를 끝까지 풀어보고자 하는 인내심이 생기고, 모르는 것을 즐겁게 파고들 수 있는 열의가 생겨났다. 결국 관심이 커야 기술 지식을 깊게 파고들 수 있는 힘이 생긴다. 진정으로 관심이 있을 때 비로소 새로운 개념을 찾아보고 배우는 과정 자체를 즐기게 되었다. 관찰은 내 학습의 첫걸음이었다. 주변의 좋은 코드나 뛰어난 동료의 작업 방식을 유심히 살펴보는 것만으로도 많은 것을 배울 수 있다. 나 역시 과거 스프링 프레임워크의 코드를 한 줄 한 줄 따라 읽으며, 책으로는 얻기 어려웠던 객체 지향 설계의 살아있는 지혜를 얻었던 경험이 있다. 코드 리뷰를 할 때도 마찬가지다. 단순히 코드를 훑어보는 것을 넘어, 이 코드가 왜 이렇게 작성되었을지 그 의도를 헤아려보며 관찰하고, 궁금한 점은 동료에게 직접 물어보며 내가 놓쳤던 배경과 맥락을 배운다. 확인은 배움의 깊이를 더하는 필수적인 과정이다. 나는 어설픈 짐작으로 아는 척 넘어가는 것을 경계한다. 새로운 API를 공부할 때면, 문서만 읽고 끝내는 대신 작은 테스트 코드를 작성해 내 예상이 맞는지 직접 확인해 본다. 이 간단한 검증 과정이 내가 무엇을 알고 무엇을 모르는지를 명확하게 해준다. 직접 확인하는 습관을 가진 개발자와 그렇지 않은 개발자 사이의 실력 차이는 시간이 지날수록 크게 벌어질 수밖에 없다. 마지막으로 '왜?'라는 질문을 던지는 습관은 얕은 지식을 깊은 지혜로 바꾸는 비결이다. 어떤 기술을 접할 때 그저 사용법만 익히는 것이 아니라, "왜 이런 구조를 선택했을까?", "다른 방식이 아닌 이 방법의 장점은 무엇일까?" 하고 근본적인 이유를 파고드는 것이다. 이런 질문은 기술의 철학을 이해하게 하고, 실무에서 마주하는 문제의 본질을 꿰뚫어 볼 수 있는 힘을 길러준다. 또한, 동료들과 '왜?'라는 질문을 주고받는 문화는 개인을 넘어 팀 전체의 기술적 깊이를 더하는 가장 좋은 방법이기도 하다. 돌아보면, 기술은 시대에 따라 계속 변했지만 그것을 배우는 나의 자세는 아직 그대로다. 오늘도 충분한 관심을 바탕으로 관찰하고, 확인하고, 끊임없이 '왜'를 묻는 내가 있다면, 내일 어떤 새로운 기술이 나타나더라도 단단해진 실력으로 그것을 온전히 내 것으로 만들 수 있으리라 믿는다.

기술을 어떻게 학습하시나요?

1 자기소개는 생략하세요
포트폴리오가 곧 자기소개입니다. 바로 프로젝트 얘기 들어가세요

2 면접관은 정답 몰라요
데이터와 맥락으로 설득하는 게 훨씬 먹힙니다

3 UI 스샷 덜어내세요
결과물보다 과정이 보여야 포트폴리오입니다

4 “왜”를 준비하세요
열 질문 중 일곱은 “왜 그렇게 했나요?”입니다

5 성과=수치+맥락
숫자만 말하지 말고 스토리까지 붙여야 기억에 남습니다

6 협업은 숨기지 마세요
혼자 다 했다, 실무에선 마이너스입니다

7 AI는 치트키가 아니라 부스터
“썼다”보다 “시간 50% 줄였다”가 훨씬 설득력 있어요

8 디자인 시스템=룰
툴 자랑 말고 실제 협업, 운영 경험을 강조하세요

9 지원시 저자세는 금물
“내가 기여할 문제”로 지원 동기를 말하세요

10 불합격=피드백
루프 돌리면 확률은 결국 올라갑니다

1 자기소개는 생략하세요포트폴리오가 곧 자기소개입니다. 바로 프로젝트 얘기 들어가세요 2 면접관은 정답 몰라요데이터와 맥락으로 설득하는 게 훨씬 먹힙니다 3 UI 스샷 덜어내세요결과물보다 과정이 보여야 포트폴리오입니다 4 “왜”를 준비하세요열 질문 중 일곱은 “왜 그렇게 했나요?”입니다 5 성과=수치+맥락숫자만 말하지 말고 스토리까지 붙여야 기억에 남습니다 6 협업은 숨기지 마세요혼자 다 했다, 실무에선 마이너스입니다 7 AI는 치트키가 아니라 부스터“썼다”보다 “시간 50% 줄였다”가 훨씬 설득력 있어요 8 디자인 시스템=룰툴 자랑 말고 실제 협업, 운영 경험을 강조하세요 9 지원시 저자세는 금물“내가 기여할 문제”로 지원 동기를 말하세요 10 불합격=피드백루프 돌리면 확률은 결국 올라갑니다

UX 취업 치트키 10

오늘은 뱅크샐러드의 테크 리드, 이영창님을 모시고 바이브 코딩 실무 사례를 배워봤어요.


LLM, AI를 활용해서 개발하다 보면 오히려 번거롭다는 생각이 들곤 하는데요. 영창님은 이 생각을 어떻게 바라보고 계신지도 배울 수 있었어요.


실무에서 AI를 어떻게 사용할지 고민하셨던 분들에게 도움되는 영상이 되었으면 좋겠어요!


📌 챕터
00:00 미리보기
00:17 뱅크샐러드 테크 리드 이영창님
01:19 국내외 전문가들에게서 배운 LLM 활용법
06:35 프롬프트 초안은 이렇게 작성하세요
09:42 커서 AI는 이렇게 활용하세요
12:37 그렇게까지 AI를 꼭 써야하는 이유가 뭔가요?
16:10 프롬프트는 이렇게 하면 쉽게 작성할 수 있어요
18:58 2부에서 계속됩니다


https://youtu.be/Dja8fqyaFqQ?si=c5XB1op_cBH0LSUW

오늘은 뱅크샐러드의 테크 리드, 이영창님을 모시고 바이브 코딩 실무 사례를 배워봤어요. LLM, AI를 활용해서 개발하다 보면 오히려 번거롭다는 생각이 들곤 하는데요. 영창님은 이 생각을 어떻게 바라보고 계신지도 배울 수 있었어요. 실무에서 AI를 어떻게 사용할지 고민하셨던 분들에게 도움되는 영상이 되었으면 좋겠어요! 📌 챕터00:00 미리보기00:17 뱅크샐러드 테크 리드 이영창님01:19 국내외 전문가들에게서 배운 LLM 활용법06:35 프롬프트 초안은 이렇게 작성하세요09:42 커서 AI는 이렇게 활용하세요12:37 그렇게까지 AI를 꼭 써야하는 이유가 뭔가요?16:10 프롬프트는 이렇게 하면 쉽게 작성할 수 있어요18:58 2부에서 계속됩니다 https://youtu.be/Dja8fqyaFqQ?si=c5XB1op_cBH0LSUW

바이브 코딩, 실무에서 하려면 테크 리드에게 배우세요 [1부]

최근 인재 프로필을 검토하여 기업과 연결하는 업무를 하면서, 이력서 작성 방식에 대한 관점이 크게 바뀌었습니다. '기업 입장에서는 이런 부분을 중요하게 보겠구나!'라고 새롭게 깨닫게 된 점들이 많았습니다. 마치 인하우스 채용 담당자 경험이 없는 사람처럼, 현재 채용 업무를 담당하는 분들의 관점을 이해하려고 노력하고 있습니다.


인재 프로필을 처음 검토할 때 가장 먼저 하는 작업은 기업이 요구하는 조건으로 필터링하는 것입니다. 경력 연차, 학력, 보유 기술 등 명확하게 확인 가능한 기준으로 필요한 프로필 리스트를 먼저 확보합니다.
그 다음 단계가 더 까다로운 작업입니다. 바로 경험 내용을 면밀히 확인하는 것입니다. 같은 직무 타이틀이라도 실제 경험한 업무 내용은 천차만별입니다. 예를 들어, '백엔드 개발자'라는 같은 타이틀이어도 각자가 경험한 회사에서 담당한 업무와 설명하는 수준이 모두 다릅니다. 결국 경험 설명 안에서 채용 기업이 원하는 업무 키워드를 찾아내는 작업이 핵심이 됩니다.
서류 전형에서 검증할 수 있는 범위는 여기까지입니다. 기업이 원하는 역량 키워드가 있는지, 관련 경험 키워드가 포함되어 있는지를 확인하는 것입니다. 물론 경험을 자세히 기술한 지원자의 경우 어느 정도 역량을 가늠할 수 있지만, 실제 얼마나 뛰어난 역량을 보유했는지 100% 파악하는 것은 거의 불가능합니다.


눈치채셨겠지만, 기업이 원하는 키워드가 지원 서류에 포함되어 있는지 여부가 당락을 좌우합니다. 특히 기업이 중요하게 생각하는 경험과 역량 키워드가 눈에 잘 띄도록 서류를 작성하는 것이 관건입니다.
따라서 취업과 이직을 준비하는 분들이 해야 할 일은 두 가지입니다.
1. 핵심 키워드를 전략적으로 배치하기
지원하는 기업이 원하는 경험과 역량을 키워드로 정리하여 이력서와 포트폴리오 곳곳에 눈에 띄도록 작성해야 합니다. 서류를 검토하는 담당자는 한 명의 지원자 서류에 많은 시간을 할애하기 어렵습니다. 지원자가 많고 처리해야 할 업무가 많아 서류 전형은 가급적 신속하게 처리해야 하는 업무이기 때문입니다.
따라서 이력서나 포트폴리오를 꼼꼼하게 읽지 않더라도 중요한 키워드가 한눈에 들어오도록 서류 곳곳에 전략적으로 배치하는 것이 중요합니다.
2. 기업 용어와 일치하는 표현 사용하기
같은 경험을 설명하더라도 기업이 사용하는 표현과 유사한 방식으로 작성하는 것이 좋습니다. 예를 들어, '방대한 데이터를 다뤄봤다'는 표현을 '대규모 트래픽 처리 경험', '대용량 데이터 핸들링' 등 기업이 선호하는 표현으로 바꿔 작성할 수 있습니다.
이는 사소해 보이지만, 서류 검토 시 키워드 중심으로 내용을 확인하는 것이 가장 효율적인 방법이므로 중요하게 작용합니다.


지금까지 말씀드린 내용은 서류 전형 통과를 위한 노하우일 뿐, 면접이라는 실전에서 실제 역량을 검증받는 것은 완전히 다른 차원의 문제입니다. 따라서 서류 합격만을 위해 미숙한 분야를 마치 전문 영역인 것처럼 과장하여 키워드로 넣는 것은 면접에서 실력이 드러나게 되어 있습니다.
가급적 이력서와 포트폴리오에는 진정으로 자신 있는 강점 위주로 내용을 구성하는 것이 좋습니다. 이것이 최종 합격에 이르는 유일한 지름길입니다.


이력서나 포트폴리오를 효과적으로 작성하고 최종 합격하기 위해 가장 중요한 자료는 바로 채용공고입니다. 채용공고를 제대로 이해하고 분석하는 것이 정말 중요하며, 아무리 강조해도 지나치지 않습니다.
채용공고는 단순히 읽고 표면적으로 이해하는 것으로는 충분하지 않습니다. 분석해야 합니다. 분석한다는 것은 단어와 문장의 이해를 넘어 맥락 속에 숨어 있는 기업의 진정한 니즈를 파악하는 것입니다.
'어떻게 채용 담당자의 마음을 읽을 수 있을까요?' 특별한 능력이 필요한 것은 아닙니다. 반복해서 읽고 또 읽으면 처음에는 보이지 않던 내용들이 비로소 보이기 시작합니다. 가장 중요한 것은 관심입니다.
관심이 있는 분야에 집중하기
관심을 가지면 감춰진 것들도 보이기 시작합니다. 따라서 본인이 관심 있는 직무, 기업, 산업, 비즈니스 모델 등의 조건에 부합하는 채용공고를 선택하는 것이 중요합니다.
잘 알지 못하는 분야는 아무리 좋은 조건이어도 채용공고를 읽어봐도 제대로 이해하기 어렵습니다. 이해하지 못한 상태에서 '일단 지원해보자'는 마음으로 접근하면 무응답이나 불합격 결과를 받을 가능성이 높습니다.
그러고 나서 계속 불합격한다고 자괴감에 빠지지 마세요. 철저히 이해가 되는 채용공고 위주로 지원하시길 추천합니다. 그리고 채용공고를 완전히 이해했다면, 본인의 이력서와 포트폴리오를 해당 기업이 원하는 맞춤형 내용으로 재구성해보세요.
이전보다 서류 합격률이 몇 배는 높아질 것입니다.

﻿최근 인재 프로필을 검토하여 기업과 연결하는 업무를 하면서, 이력서 작성 방식에 대한 관점이 크게 바뀌었습니다. '기업 입장에서는 이런 부분을 중요하게 보겠구나!'라고 새롭게 깨닫게 된 점들이 많았습니다. 마치 인하우스 채용 담당자 경험이 없는 사람처럼, 현재 채용 업무를 담당하는 분들의 관점을 이해하려고 노력하고 있습니다. 인재 프로필을 처음 검토할 때 가장 먼저 하는 작업은 기업이 요구하는 조건으로 필터링하는 것입니다. 경력 연차, 학력, 보유 기술 등 명확하게 확인 가능한 기준으로 필요한 프로필 리스트를 먼저 확보합니다.그 다음 단계가 더 까다로운 작업입니다. 바로 경험 내용을 면밀히 확인하는 것입니다. 같은 직무 타이틀이라도 실제 경험한 업무 내용은 천차만별입니다. 예를 들어, '백엔드 개발자'라는 같은 타이틀이어도 각자가 경험한 회사에서 담당한 업무와 설명하는 수준이 모두 다릅니다. 결국 경험 설명 안에서 채용 기업이 원하는 업무 키워드를 찾아내는 작업이 핵심이 됩니다.서류 전형에서 검증할 수 있는 범위는 여기까지입니다. 기업이 원하는 역량 키워드가 있는지, 관련 경험 키워드가 포함되어 있는지를 확인하는 것입니다. 물론 경험을 자세히 기술한 지원자의 경우 어느 정도 역량을 가늠할 수 있지만, 실제 얼마나 뛰어난 역량을 보유했는지 100% 파악하는 것은 거의 불가능합니다. 눈치채셨겠지만, 기업이 원하는 키워드가 지원 서류에 포함되어 있는지 여부가 당락을 좌우합니다. 특히 기업이 중요하게 생각하는 경험과 역량 키워드가 눈에 잘 띄도록 서류를 작성하는 것이 관건입니다.따라서 취업과 이직을 준비하는 분들이 해야 할 일은 두 가지입니다.1. 핵심 키워드를 전략적으로 배치하기지원하는 기업이 원하는 경험과 역량을 키워드로 정리하여 이력서와 포트폴리오 곳곳에 눈에 띄도록 작성해야 합니다. 서류를 검토하는 담당자는 한 명의 지원자 서류에 많은 시간을 할애하기 어렵습니다. 지원자가 많고 처리해야 할 업무가 많아 서류 전형은 가급적 신속하게 처리해야 하는 업무이기 때문입니다.따라서 이력서나 포트폴리오를 꼼꼼하게 읽지 않더라도 중요한 키워드가 한눈에 들어오도록 서류 곳곳에 전략적으로 배치하는 것이 중요합니다.2. 기업 용어와 일치하는 표현 사용하기같은 경험을 설명하더라도 기업이 사용하는 표현과 유사한 방식으로 작성하는 것이 좋습니다. 예를 들어, '방대한 데이터를 다뤄봤다'는 표현을 '대규모 트래픽 처리 경험', '대용량 데이터 핸들링' 등 기업이 선호하는 표현으로 바꿔 작성할 수 있습니다.이는 사소해 보이지만, 서류 검토 시 키워드 중심으로 내용을 확인하는 것이 가장 효율적인 방법이므로 중요하게 작용합니다. 지금까지 말씀드린 내용은 서류 전형 통과를 위한 노하우일 뿐, 면접이라는 실전에서 실제 역량을 검증받는 것은 완전히 다른 차원의 문제입니다. 따라서 서류 합격만을 위해 미숙한 분야를 마치 전문 영역인 것처럼 과장하여 키워드로 넣는 것은 면접에서 실력이 드러나게 되어 있습니다.가급적 이력서와 포트폴리오에는 진정으로 자신 있는 강점 위주로 내용을 구성하는 것이 좋습니다. 이것이 최종 합격에 이르는 유일한 지름길입니다. 이력서나 포트폴리오를 효과적으로 작성하고 최종 합격하기 위해 가장 중요한 자료는 바로 채용공고입니다. 채용공고를 제대로 이해하고 분석하는 것이 정말 중요하며, 아무리 강조해도 지나치지 않습니다.채용공고는 단순히 읽고 표면적으로 이해하는 것으로는 충분하지 않습니다. 분석해야 합니다. 분석한다는 것은 단어와 문장의 이해를 넘어 맥락 속에 숨어 있는 기업의 진정한 니즈를 파악하는 것입니다.'어떻게 채용 담당자의 마음을 읽을 수 있을까요?' 특별한 능력이 필요한 것은 아닙니다. 반복해서 읽고 또 읽으면 처음에는 보이지 않던 내용들이 비로소 보이기 시작합니다. 가장 중요한 것은 관심입니다.관심이 있는 분야에 집중하기관심을 가지면 감춰진 것들도 보이기 시작합니다. 따라서 본인이 관심 있는 직무, 기업, 산업, 비즈니스 모델 등의 조건에 부합하는 채용공고를 선택하는 것이 중요합니다.잘 알지 못하는 분야는 아무리 좋은 조건이어도 채용공고를 읽어봐도 제대로 이해하기 어렵습니다. 이해하지 못한 상태에서 '일단 지원해보자'는 마음으로 접근하면 무응답이나 불합격 결과를 받을 가능성이 높습니다.그러고 나서 계속 불합격한다고 자괴감에 빠지지 마세요. 철저히 이해가 되는 채용공고 위주로 지원하시길 추천합니다. 그리고 채용공고를 완전히 이해했다면, 본인의 이력서와 포트폴리오를 해당 기업이 원하는 맞춤형 내용으로 재구성해보세요.이전보다 서류 합격률이 몇 배는 높아질 것입니다.﻿

서류 합격 tag

📝 언어모델의 환각(hallucination)은 왜 일어나는가?

OpenAI가 언어모델(LLM)의 가장 어려운 문제 중 하나인 환각의 원인을 규명한 최신 논문을 발표했습니다.

환각은 언어 모델이 그럴듯하지만 거짓인 문장을 생성하는, 자신있게 잘못된 답변을 생성하는 현상인데요.

문제의 원인은 크게 두가지라고 합니다.

우선 사전 학습 과정에서는 다음에 올 단어를 예측하는 방식으로만 학습하는데요. 여기에는 정답/오답에 대한 레이블이 없기 때문에, 모델은 단지 문장 흐름에 기반해 학습할 뿐입니다.

따라서 문맥상 빈도가 낮게 나타나는 사실은 잘못 예측될 수 있고, 이것이 환각으로 이어진다고 합니다.

두번째는 사후 학습 과정에서 발생하는 문제인데요.

현재 사후 학습을 훈련시키는 대부분의 평가 방식은 정확도(accuracy) 중심입니다. 즉, 사전 학습과 달리 정답/오답 레이블을 가지고 가장 정확도가 높은쪽으로 생성하도록 훈련을 하는데요.

이 방식은 모델이 답을 몰라도 추측해서라도 맞추는 편이 유리하기 때문에, 모델은 모르겠다고 답하기보다, 틀릴 가능성이 있더라도 추측하는 쪽을 선택한다고 합니다.

마치 객관식 시험에서 모르는 답을 공백으로 남겨두는 것 보다, 아무렇게나라도 찍는 것이 점수를 얻기 쉬운 것과 마찬가지라는 것이죠.

환각을 없애려면 모른다거나 불확실하다는 답변을 할 수 있게 해야하는데, 현재 학습 방식은 모른다는 답변을 하는게 불리한 평가 방식이라는겁니다. (어쩜 이것도 인간이랑 똑같니 어휴..)

이것이 바로 RAG 등으로도 완전히 해결하지 못하는 이유인 것 같습니다.

따라서 이는 단순히 패널티나 보상의 방식을 조금 바꾸는 정도로는 한계가 있기때문에, 크게 개선하려면 현재의 평가 방식을 아예 완전히 바꿔야 할 수도 있다고 하네요.

OpenAI가 이 논문을 발표했다는 것은 이미 그 해결책도 어느정도 가지고 있다는 것이겠죠? GPT-5가 환각이 크게 줄어든 것도 이미 어느정도는 반영된 것일테고요.

아무튼 그렇다면 GPT-6에서는 더이상 환각을 걱정하지 않게 될 수도 있겠네요. 뭐.. 이미 대개의 인간보다 환각이 적긴하지만요. 😏

📝 언어모델의 환각(hallucination)은 왜 일어나는가? OpenAI가 언어모델(LLM)의 가장 어려운 문제 중 하나인 환각의 원인을 규명한 최신 논문을 발표했습니다. 환각은 언어 모델이 그럴듯하지만 거짓인 문장을 생성하는, 자신있게 잘못된 답변을 생성하는 현상인데요. 문제의 원인은 크게 두가지라고 합니다. 우선 사전 학습 과정에서는 다음에 올 단어를 예측하는 방식으로만 학습하는데요. 여기에는 정답/오답에 대한 레이블이 없기 때문에, 모델은 단지 문장 흐름에 기반해 학습할 뿐입니다. 따라서 문맥상 빈도가 낮게 나타나는 사실은 잘못 예측될 수 있고, 이것이 환각으로 이어진다고 합니다. 두번째는 사후 학습 과정에서 발생하는 문제인데요. 현재 사후 학습을 훈련시키는 대부분의 평가 방식은 정확도(accuracy) 중심입니다. 즉, 사전 학습과 달리 정답/오답 레이블을 가지고 가장 정확도가 높은쪽으로 생성하도록 훈련을 하는데요. 이 방식은 모델이 답을 몰라도 추측해서라도 맞추는 편이 유리하기 때문에, 모델은 모르겠다고 답하기보다, 틀릴 가능성이 있더라도 추측하는 쪽을 선택한다고 합니다. 마치 객관식 시험에서 모르는 답을 공백으로 남겨두는 것 보다, 아무렇게나라도 찍는 것이 점수를 얻기 쉬운 것과 마찬가지라는 것이죠. 환각을 없애려면 모른다거나 불확실하다는 답변을 할 수 있게 해야하는데, 현재 학습 방식은 모른다는 답변을 하는게 불리한 평가 방식이라는겁니다. (어쩜 이것도 인간이랑 똑같니 어휴..) 이것이 바로 RAG 등으로도 완전히 해결하지 못하는 이유인 것 같습니다. 따라서 이는 단순히 패널티나 보상의 방식을 조금 바꾸는 정도로는 한계가 있기때문에, 크게 개선하려면 현재의 평가 방식을 아예 완전히 바꿔야 할 수도 있다고 하네요. OpenAI가 이 논문을 발표했다는 것은 이미 그 해결책도 어느정도 가지고 있다는 것이겠죠? GPT-5가 환각이 크게 줄어든 것도 이미 어느정도는 반영된 것일테고요. 아무튼 그렇다면 GPT-6에서는 더이상 환각을 걱정하지 않게 될 수도 있겠네요. 뭐.. 이미 대개의 인간보다 환각이 적긴하지만요. 😏

📝 언어모델의 환각(hallucination)은 왜 일어나는가?


정성 데이터는 수치적 정보를 제공해 주는 정량 데이터에 비해, 사용자와 그들을 둘러싼 환경에 대한 풍부한 맥락적 정보를 제공해 주는데요. 이러한 정성 데이터 분석을 통해 우리는 사용자를 깊이 이해하고 공감할 수 있으며, 이를 통해 더 나은 서비스를 만들 수 있게 됩니다. 이번 글에는 텍스트로 이루어진 정성 데이터를 어떻게 분석하고 시각화할 수 있는지에 대해 살펴보겠습니다.

사용자 정성 데이터는 어떻게 시각화할 수 있을까? | 요즘IT

콘텐츠 매니저

Sohee

"함께 성장하는 요즘IT인의 실무 라이브러리" 요즘IT에서 콘텐츠를 만들고 있습니다. 작가 신청, 콘텐츠 제안, 기술블로그 제휴 건은 편하게 DM 주세요!

종합소득세 환급 도움 서비스 <삼쩜삼>을 알리고 있습니다. 가치 있는 제품을 마케팅 할 수 있다는 사실에 높은 만족감과 자부심을 갖고 일하고 있습니다. 데이터 드리븐의 본질은 커스터머 드리븐이라고 생각하고 있습니다.

삼쩜삼 마케팅 챕터 리드

황승욱

종합소득세 환급 도움 서비스 <삼쩜삼>을 알리고 있습니다. 가치 있는 제품을 마케팅 할 수 있다는 사실에 높은 만족감과 자부심을 갖고 일하고 있습니다. 데이터 드리븐의 본질은 커스터머 드리븐이라고 생각하고 있습니다.
#CRM #퍼포먼스마케팅 #브랜딩퍼포먼스

사용자 정성 데이터는 어떻게 시각화할 수 있을까?

댓글 0

함께 읽은 게시물

< 감정을 없애려 하지 말고, 흘려보내라 >

PM을 위한 Cursor 활용법

주간 인기 TOP 10

추천 프로필