예전에 소프트웨어의 중요성이 한창 부각되던 시절이 있었습니다. 자연스럽게 회사의 경영층에서는 개발 중인 소프트웨어의 수준이 어떤지, 그 품질을 직접 확인하고 싶다는 요구가 증가했습니다. 제가 속한 팀은 오랜 고민 끝에 몇 가지 지표를 선정해서 소프트웨어의 품질을 가시화했습니다. 비전문가의 눈높이에 맞춘 지표였기 때문에 소프트웨어 개발자들이나 실무자들은 완전히 동의하지 않았습니다. 그런데도 그 지표는 얼마 전까지 사내 표준으로 채택되어 오랜 … 더 읽기
얼마 전 아내가 아이 친구 엄마와 아이들 학교 공부에 관해 이야기하던 중에, ‘정보’ 과목을 어떻게 준비하는지 물었다고 합니다. 그때 들은 답은 “초등학교 때 파이썬 한 번 뗐어요. 그때 잘했고요. 더 준비 안 해도 될 것 같아요.”였습니다. 당연히 그분이 완전히 마스터했다고 주장한 것은 아닐 것입니다. 아마 어떤 과정이나 단계를 마쳤다는 뜻일 텐데, 그 구체적인 단계가 문장에서 … 더 읽기
얼마 전 SNS에서 AI의 발전으로 인해 달라질 모습들을 소개한 글을 봤습니다. 그중 몇년만 지나면 지금의 대치동 학원가를 AI 에이전트로 구성된 온라인 학원가가 대신할 수도 있지 않을까 하는 이야기를 보았습니다. 만약 학생의 수준에 따라 각기 다른 진도와 약점에 맞춰 24시간 대응하는 AI가 등장한다면, 굳이 아이를 차에 태워 대치동까지 데려갈 이유가 없어진다는 이야기로 읽혔습니다. 그런데 제 생각에는 … 더 읽기
연말이나 연초, 혹은 새 과제를 시작할 때면 과제의 목표를 설정해야 합니다. 그럴 때 자주 듣는 이야기가 숫자로 정리해 오라는 말입니다. 그러면 대개 “성능 10% 개선”과 같은 큼직한 숫자 하나가 올라옵니다. 리더 입장에서는 이때부터 스무고개가 시작됩니다. 어떤 성능입니까? 속도? 메모리? 소모전력? 10%의 기준은 무엇입니까? SOTA? 경쟁사? 아니면 자체 기준? 만약 SOTA(State of the Art)라고 답이 오면 … 더 읽기
최근 인터넷 커뮤니티에서 ‘딸깍’이라는 표현이 쓰입니다. AI 에이전트에게 요청 한 번, 클릭 한 번으로 산출물이 만들어지는 시대를 가리키는 자조 섞인 말입니다. 저는 이 표현이 가리키는 방향이 중요하다고 생각합니다. 결과물이 나쁘다는 조롱이 아닙니다. 어쩌면 결과물은 그럴듯하게 나올 수 있습니다. 핵심은 만든 사람 안에 남는 것이 없다는 데 있습니다. 이와 관련한 다양한 연구가 있었습니다. MIT의 에세이 작성 … 더 읽기
얼마 전 세 번째 바이브 코딩 프로젝트를 완료했습니다. 첫 번째 프로젝트에서는 AI를 이용해서 얼마나 빠르게 앱을 만들 수 있는지 보았습니다. 아이의 학습 습관을 기록하는 웹앱을 만들면서, 구현 방향을 정하고 결과를 확인하는 시간이 훨씬 길고 중요하다는 사실을 알게 되었습니다. 두 번째 프로젝트인 주식 거래 관리 앱에서는 장기간 개발을 하면서 개발 속도와 맥락을 유지하려면 테스트와 각종 문서, … 더 읽기
회사 생활을 하다 보면 다양한 보고를 하게 됩니다. 그리고 처음 관리자가 되고 나니 보고의 성격이 달라졌습니다. 그 전까지는 제가 만든 보고서를 직접 보고하는 일이 많았다면, 관리자 입장에서는 팀원들이 만든 보고자료로 팀원들과 함께 보고를 이끌어야 했습니다. 이때, 보고가 끝나고 나면 이 보고를 어떻게 마무리 지어야 할지 고민이 되었고, 그때 택한 방법이 보고를 복기하는 것이었습니다. 중요한 보고가 … 더 읽기
지난 글 「엔지니어의 리더십: 오탐과 미탐, 기술의 판단 기준」에서 실체와 뷰를 언급했습니다. 업무의 뷰는 필요에 의해 설계하고 만들어 갑니다. 하지만 일상의 뷰는 다릅니다. 별도로 설계하지 않아도, 살아온 경험을 통해 알아서 만들어집니다. 3차원 물체는 보는 방향에 따라 다르게 보입니다. 원기둥을 정면에서 보면 사각형이고, 위에서 내려다보면 원입니다. 같은 실체라도 어느 축에서 보느냐가 뷰를 정합니다. 사람은 아는 만큼 … 더 읽기
대학원 시절, 연구를 하거나 논문을 읽을 때 가장 중요한 기준은 제안하는 시스템의 안전성(soundness)과 완전성(completeness)이었습니다. 그리고 이 두 가지를 이야기하려면 반드시 필요한 개념이 두 가지 있었습니다. 바로 오탐(false positive)과 미탐(false negative)입니다. 처음 두 개념을 배울 때는 시스템을 평가하는 지표로만 이해했습니다. 그런데 회사에 취업하고, 다양한 연구를 접하게 되면서 이 개념은 단순히 지표가 아니라 생각의 틀로 확장되었습니다. 외부 … 더 읽기
AI가 빠르게 보급되면서 일상 곳곳이 달라지고 있습니다. 그중에서도 가장 큰 영향을 받은 분야 하나를 꼽으라면 여행이 아닐까 싶습니다. 지난번 「AI시대: 생활밀착형 AX — AI는 어떻게 내 일상이 되었나」에서는 카드 명세서 계산이나 발표 자료 작성처럼 일상생활에서의 변화를 다뤘습니다. 이번에는 해외여행이라는 조금 더 구체적인 상황으로 들어가, 준비 과정부터 여행 중, 그리고 복귀 후 마무리까지 AI를 어떻게 활용했는지 … 더 읽기
MIT Tech Review에 「Why do South Koreans love AI so much?」라는 제목의 흥미로운 기사가 하나 올라왔습니다. 그러니까, “한국인은 왜 이렇게 AI를 좋아할까”입니다. 기사에 따르면, 한국이 세계에서 AI에 가장 호의적인 나라라고 합니다. 퓨리서치가 조사한 25개국 중, AI를 기대보다 걱정한다고 답한 사람이 한국은 16%로 가장 적었습니다. 같은 질문에 미국은 50% 수준이었고요. 한국인 대다수가 일상에서든 직장에서든 매일 AI를 … 더 읽기
얼마 전, 차량 통행량이 적은 교외 지역을 지나가다가 라운드어바웃을 발견했습니다. 우리나라에도 최근 도로를 새로 정비하는 과정에서 교통량이 많지 않은 지역에 라운드어바웃, 곧 회전교차로를 적용하는 사례가 늘고 있습니다. 정부가 2010년 본격 도입한 이후 2020년 말 기준 전국에 1,500개가 넘는 회전교차로가 운영되고 있고, 앞으로도 계속 늘려간다고 합니다. 영국에서 주재원 생활을 할 때는 매일 수많은 라운드어바웃을 이용했습니다. 영국은 … 더 읽기
해외연구소장으로 있던 시절, 한 주재원이 본사에 보낼 불만 메일을 쓰고 있는 것을 본 적이 있습니다. 내용을 들여다보니 “본사 지원팀에서는 왜 이걸 이렇게 처리하느냐”는 이슈제기였습니다. 저는 상황을 정리해서 문제를 제기하는 것 자체는 좋지만, 그 전에 요청을 받는 쪽의 입장에서 한 번 더 생각해 보고 우리가 무엇을 원하는지를 명확하게 전달하는 게 먼저라고 일러 주었습니다. 회사나 큰 조직에서 … 더 읽기
영국과 러시아 해외연구소장 시절, 현지 엔지니어들로부터 가장 많이 받은 질문이 있습니다. “엔지니어에서 매니지먼트 트랙으로 옮긴 이유가 무엇인가요?” 생각해보면, 국내 기업 문화에서는 엔지니어가 경력이 쌓이고 매니저가 되는 것을 비교적 자연스럽게 보는 편입니다. 제 경우도 소프트웨어 엔지니어로 입사를 해서, 파트장, 랩장 등 관리자 트랙을 거쳐서 연구소장까지 되었습니다. 하지만 해외, 특히 서구권에서는 기술 전문가 트랙과 매니지먼트 트랙이 비교적 … 더 읽기
AX(AI Transformation)라는 말을 들으면 보통 큰 그림이 먼저 떠오릅니다. AI 도구를 잘 활용할 수 있는 플랫폼을 깔고, 각 업무에 맞는 에이전트를 도입하고, 전사 데이터를 통합하는 일들 말입니다. 회사 차원에서는 분명 중요한 과제이고, 저 역시 그런 큰 그림을 고민하는 자리에 있었습니다. 그런데 제가 AI를 쓰면서 실제로 변화를 가장 크게 느낀 곳은 그렇게 거창한 자리가 아니었습니다. 오히려 … 더 읽기
지난번 「바이브 코딩으로 웹앱 만들기」에서 아이의 학습 습관을 기록하는 웹앱 My Lesson Log를 만든 이야기를 했습니다. 다행히 아이가 지금도 잘 쓰고 있습니다. 이번에는 저와 아내가 쓸 프로그램을 만들었습니다. 우리 가족의 주식 계좌 거래내역을 한곳에서 관리하는 TradeLog입니다. 기존에 수동으로 하던 작업을 엑셀 기반 자동화 스크립트로 만들고, 이를 데스크톱 앱 형태로 개선하고, 이후 웹서비스까지, 수차례 버전을 올리며 … 더 읽기
2022년 프롬프트 엔지니어링이 주목받기 시작했습니다. 2024년에는 컨텍스트 엔지니어링이 그 자리를 이어받았고, 2026년에는 하네스 엔지니어링이라는 개념이 업계에 자리 잡고 있습니다. 3~5년 사이에 핵심 관심사가 세 번 바뀌었습니다. 이 흐름을 새로운 현상으로 볼 수도 있지만, 소프트웨어 엔지니어링의 역사를 알고 있다면 익숙한 패턴입니다. AI 엔지니어링은 소프트웨어 엔지니어링 60년이 걸어온 길을 압축해서 따라가고 있는 것 처럼 보입니다. 그 계단을 … 더 읽기
얼마 전 선배들과 만난 자리에서 바이브 코딩 이야기가 나왔습니다. 요즘 실제로 써보고 있냐는 질문에, 다들 각자 최근 경험을 꺼내놓았습니다. 저는 채팅 AI와 대화하면서 요구사항과 스펙을 정리하고, 이를 바탕으로 코딩 AI에게 구현을 맡기되 코드는 최대한 직접 보지 않는게 좋다고 설명했고, 그 말에 반응이 엇갈렸습니다. 또, 바이브 코딩으로 만든 코드가 리펙토링이 필요한가에 대해서도 기능 추가 용이성, 유지보수 … 더 읽기
이전 글 「AI시대: AI-native 조직구조는? 더 낮고 더 넓게」에서 AI 시대의 조직은 더 낮고 더 넓게 변할 것이라는 이야기를 했습니다. 관리자의 역할은 더 중요해지고, 조직 구조는 수평화됩니다. 그런데 AI-native 조직은 저절로 만들어지지 않습니다. 컨텍스트 공유, AI 리터러시, 모니터링과 가시성, 권한·평가·책임의 재설계, 그리고 관계와 피드백 설계 등 함께 풀어야 할 이슈들이 있습니다. 이 글에서는 앞서 제시한 … 더 읽기
AI가 일하는 방식을 바꾸고 있다는 이야기는 이제 익숙합니다. 그런데 일하는 방식이 바뀌면, 그 일을 담는 그릇인 조직 구조도 같이 바뀔 수밖에 없습니다. AI 도입(AI Adoption)을 넘어 AI-native 조직으로 간다면, 그 형태는 어떤 모습일까요? 흔히 “중간 관리자가 사라진다”거나 “인력을 줄인다”는 식으로 단순화됩니다. 그러나 실제 변화는 그렇게 단순하지는 않을 것 같습니다. 제가 바라보는 관점에서는, 조직은 낮고 넓어지는 … 더 읽기
