본문 바로가기

전체 글

 (169)
[실무에서 만나는 AI·AX 이야기] #12, 마치며 AI 실무 활용 열두 편을 다시 읽고 알게 된 것. 편마다 AI로 하는 일은 전부 달랐지만, 무엇을 풀지 정하고 결과를 거를지 판단하는 일은 매번 사람이 했습니다.: AI 시대에도 판단은 사람의 일입니다문제는 풀었는데, 전달에서 막힌 편들시리즈를 마무리하면서,작성했던 글들을 처음부터 다시 읽어보았습니다. 읽는 도중에 "막혔던 순간"의 문장들이 계속 눈에 밟혔습니다.열흘 만에 분석을 끝내고도 보고서에 다 담지 못하고,상황에 맞는 설계와 방향을 정했음에도 반응이 좋지 않을 때가 있었습니다. 지금 와서 생각해 보면,문제를 해결한다는 건 문제 자체를 푸는 데서 끝나지 않았습니다.그 해결책을 잘 전달하고 설득해서,옳은 선택에 이르게 하는 일까지가 해결이 아니었나 생각했습니다.열두 편을 나란히 놓으니 공통점이 하나..
[실무에서 만나는 AI·AX 이야기] #11, AI 전환, 무엇부터 시작할지 로드맵으로 정합니다 AI 도입 로드맵을 어떻게 그렸는지 정리했습니다. 수요예측을 요구받았지만 데이터가 부족했고, 안 된다는 말 대신 조직이 데이터로 갈 수 있는 순서를 단계별로 전달한 과정입니다.:당장의 수요예측보다는 로드맵이 중요했습니다DX 프로젝트는 AI 전환 프로젝트의 시작점이었습니다.경쟁사들도 수요예측을 필두로, 너나 할 것 없이 AI를 외치던 시기였습니다.그래서 DX 프로젝트를 어떻게 AI로 연착륙시킬지가 중요했습니다. 그리고 가장 중요한 변수는 수요예측이 꼭 필요하다는 최고의사결정권자의 의견이었습니다.수요예측이라는 말은 비즈니스적으로도, 마케팅 측면에서도 매우 좋은 단어입니다.얼마나 팔릴지 예상이 되고 재고 관리도 쉬워집니다. 하지만 구현하기는 굉장히 까다롭습니다. 데이터의 양은 물론이거니와 품질이 매우 중요합니..
[실무에서 만나는 AI·AX 이야기] #10, 데이터 분석 환경 구축, 검증할 사람이 없을 때 데이터 분석 환경을 처음 구축할 때, 설계를 검증해 줄 경험자가 없다면 어떻게 할까요. 확신 없이 넘어갔던 저장소와 처리 계층의 역할 경계를, 지금은 AI로 후보 구조를 비교하고 설계 약점을 확인하며 다시 짚습니다.: 가본 적 없는 길은, 혼자 정답을 정할 수 없습니다데이터 분석 환경을 처음부터 구축해야 하는 상황이었습니다.정식 구축은 아니었습니다.일단 작게 만들어 가능성부터 보는 단계였고, 그래서 더 애매했습니다. 크게 만들면 차라리 답이 정해져 있습니다.작게, 그러나 틀리지 않게 만들어야 할 때가 제일 어렵습니다.이 프로젝트를 진행하는데 가장 큰 문제는 인력자원 이었습니다.데이터를 전담하는 팀이 따로 없어서 비슷한 경험을 해본 시니어 개발자 한 명과 진행했습니다. 후보는 AWS를 기준으로 하여 부족한..
[실무에서 만나는 AI·AX 이야기] #9, AI 도입 전에 데이터부터 확인해야 합니다 데이터 분석 AI 프로젝트는 모델보다 데이터 확인이 먼저입니다. EDA로 발견한 데이터 공백을 전달하지 못했던 경험과, 지금이라면 AI로 그 문제를 화면으로 보여주는 네 단계를 정리했습니다.: 데이터가 없다는 말을, 보여줄 수가 없었습니다프로젝트가 끝날 무렵 최종 의사결정권자의 호출이 있었습니다.AI를 본격적으로 해보겠다고, 그동안 회사에 쌓인 데이터를 한번 전부 훑어봐 달라고 했습니다.큰 프로젝트의 시작이었습니다.EDA에서 발견한 것 — 핵심 컬럼이 비어 있었습니다여러 회사의 제품 데이터를 한데 모으는 작업이 포함되어 있었고, 저는 그 데이터부터 탐색을 시작했습니다.그런데 가격과 구매처정보 같은 핵심 컬럼이 비어 있었습니다.이 항목들은 예측모형을 만들려면 반드시 있어야 하는 값이었습니다. 처음엔 입력을..
[실무에서 만나는 AI·AX 이야기] #8, 바이브 코딩 시대 개발자의 역할 바이브 코딩으로 혼자 AI 프로젝트를 진행하며 겪은 일을 정리했습니다. 코드를 AI로 짜는 시대에 개발자가 봐야 할 곳이 어디로 옮겨가는지, 완전히 믿었다가 겪은 함정까지 실제 경험으로 이야기합니다.: 코드를 몰라도 개발을 할 수 있는 세상이 왔습니다AI 에이전트 프로젝트를 진행할 예정이었습니다.익숙한 Vus.js 프론트 기반으로 개발 환경 설정을 추천해 달라고 AI와 대화를 하고 있었습니다.한 번도 해 본 지 않은 환경위에서 진행하면 문제가 될 것 같았습니다. 그런데 AI는 다른 걸 제안했습니다.이번에는 React.js가 더 잘 맞으니, 일단 한번 보고 결정하자는 것이었습니다. 저는 잠깐 멈칫했습니다.Vue.js가 편한데, 굳이 안 써본 쪽으로 가야 하나 싶었습니다.마음을 정한 건 AI가 짜놓은 코드를..
[실무에서 만나는 AI·AX 이야기] #7, 아키텍처 설계에 AI를 쓰는 법 AI로 코드를 짜는 데서 멈추지 않고 아키텍처 설계까지 잡는 방법입니다. 요구사항 정리, 반대 의견 검증, 레퍼런스 비교, 과적합 점검, 코드와 기준 문서화까지 다섯 단계로 정리했습니다.: 코드를 넘어, 구조까지 잡습니다DX 프로젝트에서 아키텍트를 맡았을 때 겪은 일입니다.전체 프로젝트의 구조를 잡는 역할이었고, 그중 프론트 부문을 팀에 설명하던 때의 상황입니다. 처음엔 와이어프레임을 기준으로 스펙을 정의하고, 컴포넌트 구조를 만들어 설명했습니다.PPT에 화면을 올리고, 개발 기획 문서를 같이 넘겼습니다.컴포넌트를 나누는 기준, 문서만으로는 전달되지 않았습니다그런데 팀원들이 좀 버거워했습니다.컴포넌트는 작은 단위에서 시작해 화면 전체까지 쌓여 올라가는 구조인데, 그걸 어떤 기준으로 나눌지를 몰랐습니다. ..
[실무에서 만나는 AI·AX 이야기] #6, 팀이 새 기술을 따라오지 못할 때 새 기술을 도입해도 팀이 예전 방식 그대로 개발한다면, 설명을 반복하는 대신 AI로 학습을 나누고 코드 검사를 자동화합니다. GraphQL 도입 현장에서 겪은 이야기입니다.: 설명만 하지 말고, 스스로 부딪히게 하세요새 기술을 도입한 프로젝트였습니다.회의실에 개발 리더들이 모였습니다.주제는 데이터를 주고받는 방식을 통째로 바꾸는 일, GraphQL이었습니다. 그런데 입에서 나오는 말은 전부 예전 방식이었습니다.이 기능은 따로 빼고,저 화면은 이렇게 나누고.분명 새로운 프레임워크를 이야기하는 회의인데,머릿속 이해는 옛날 그대로였습니다.새 기술을 도입해도 개발은 예전 방식 그대로였습니다이 제품은 화면에서 상태가 쉴 새 없이 바뀝니다.실시간 재고가 걸려 있어서, 데이터가 한 방향으로만 흐르면 안 됩니다.화면 ..
[실무에서 만나는 AI·AX 이야기] #5, 기획서 쓰기 전에 기능 범위부터 확인합니다 서비스 기획에서 기능 범위를 어떻게 정할까요. 재고 질문 하나에 기획서가 멈췄던 날, 도메인 경험 없이도 AI로 기능의 연결 범위를 기획 전에 확인하는 방법을 정리했습니다.: 도메인은 몰라도, 범위는 알아야 합니다.재고 질문 하나에 기획서가 멈췄습니다기능 테스트를 하던 날이었습니다.기획자와 함께 기능을 하나씩 눌러보는 중이었습니다.재고 관련 케이스가 나왔을 때, 시니어 백엔드 개발자가 물었습니다."사용자가 클릭하는 순간 재고를 잡는 건가요, 장바구니에 담을 때인가요?" 기획자가 멈췄습니다.기본 룰은 있었습니다.클릭하는 순간 임시로 재고를 잡는다. 그런데 그 임시 재고가 실시간 전체 재고를 잡는 건지,예외는 어떻게 되는지,재고관리 화면에서는 그걸 어떻게 보여줄 건지. 연계된 기능들과 어떻게 맞물리는지가 기..

티스토리툴바