COMMUNITY

커뮤니티

좋은 글은 작성자의 프로필로 연결되고 협업 기회로 이어집니다.

BUILD YOUR ASSETS

당신의 경험은 자산이 될 수 있습니다.

작성자의 프로필을 통해 새로운 협업과 프로젝트 기회를 발견할 수 있습니다.

예

예나이야기

젠슨 황이 서울대에서 진짜 하고 간 말 (2026.06)

1. 엔비디아 CEO가 대학생한테 "부럽다"고 했다 젠슨 황이 서울대에 왔어. 강당에 학생들 꽉 찼고 다들 폰 들고 찍고 있는데 걔네한테 첫 마디가 "너희가 딱 지금 이 시기에 졸업해서 나 진짜 부러워." 세계 1등 AI 칩 회사 CEO가. 시가총액 3조 달러 회사 만든 사람이. 부럽다고. 근데 들으면서 웃어야 할지 소름 돋아야 할지 모르겠는 게 이 사람이 1990년대에 똑같은 말 들었거든. "컴퓨터가 처음 나왔을 때 딱 그 타이밍에 있었다. 나는 그 기회를 잡았다. 너희는 지금 그 자리에 있다." 그리고 지금 우리가 아는 젠슨 황이 됐음. AI 원년 졸업생들한테 부럽다고 하는 사람이 PC 원년 졸업생이었다는 거. 이거 소름 아님? ***** 2. K젠슨 탄생 현장 강연 중에 학생이 말을 끊었어. "K팝, K뷰티, K드라마… K 붙이면 다 잘 되잖아요." 젠슨 황이 딱 멈추더니 "K젠슨…" 혼자 중얼거림. 그러다가 진지하게 "마음에 드네요." 강당 폭발함. 그러더니 이렇게 말함. "오늘 밤 집에 가면 아내한테 말할 거야. 아침에 나갈 때는 그냥 젠슨이었는데 이제 K젠슨이 됐다고." 근데 이게 웃기면서 씁쓸한 게 K팝, K뷰티, K드라마 다 된 나라에서 K AI는 아직 없잖아. 이 사람이 한국에 직접 와서 "너희 이 타이밍 놓치면 안 된다"고 말하는 맥락이 여기 있는 거임. ***** 3. AI를 30초 만에 이해하는 법 강연 듣다가 이 비유에서 멈췄음. 젠슨 황이 이렇게 말함. 우리 세대는 코드를 직접 씀. 코드 + OS = 앱. 근데 그게 전부였어. 코드만 있으면 안 됨. OS 없으면 그냥 쓰레기. 코드랑 OS가 합쳐져야 비로소 뭔가 됨. 지금은 달라. LLM이 코드야. LLM + 활용법 = AI. 그러니까 지금 "AI 잘 못 써요"라는 사람은 90년대에 코딩은 할 줄 아는데 OS 개념을 모르는 거랑 같음. 모델이 아무리 좋아도 어디에 어떻게 끼워넣는지 모르면 의미 없음. 반대로 말하면 LLM 원리 몰라도 됨. 활용법만 제대로 알면 그게 AI 전문가임. 이게 지금 제일 중요한 거 아님? ***** 4. 왜 하필 한국인가 젠슨 황이 한국 칭찬하는 게 그냥 립서비스가 아니었어. 로봇 만들려면 뭐가 필요하냐고. 전자 기술 기계공학 클라우드 제조 AI 이걸 동시에 다 잘하는 나라가 전 세계에 거의 없다는 거야. 미국은 소프트웨어/AI 강함. 제조 약함. 중국은 제조 강함. 클라우드 AI 분리됨. 일본은 기계공학 강함. AI 느림. 한국은? 삼성, 하이닉스, 현대, LG, SK, 카카오, 네이버 얘네가 다 한 나라 안에 있잖아. 젠슨 황이 이걸 보고 "어떻게 된 건지 모르겠어. 지난 20년 동안 이 한 나라에서 이 모든 기술을 한 곳에 모았어." 라고 한 거임. 로봇 시대의 주도권 경쟁에서 한국이 갖고 있는 패가 이만큼인 거. 근데 우리가 그걸 모름. 5. GPT의 시작은 젠슨 황의 믿음이었다 2016년. 젠슨 황이 DGX1을 만들었어. 고객 없었음. 시장 없었음. 아무도 필요하다고 안 했음. 그래서 어떻게 했냐. 엔비디아 직원들한테 먼저 줌. 그리고 두 번째로 준 곳이 'OpenAI'라는 작은 스타트업이었음. 그 스타트업이 DGX1으로 GPT를 훈련시켰어. 2016년 당시 OpenAI가 지금의 OpenAI가 될 거라고 아무도 몰랐음. 젠슨 황도. 근데 줬어. 믿었으니까. 지금 이 장면에서 젠슨 황이 뭘 말하고 싶었던 건 "나도 처음엔 몰랐어. 그냥 될 거라고 믿고 만들었을 뿐이야." 혁신가가 미래를 예측하는 게 아님. 예측 안 되는 걸 그냥 믿고 만드는 거임. ***** 6. 지난 40년은 소프트웨어, 다음 40년은 이거다 젠슨 황이 기계공학과 학생한테 DGX Spark 선물하면서 한 말. "지난 40년은 소프트웨어 엔지니어 전성시대였어. 이제 기계공학자들 차례야." 왜? 로봇의 제일 어려운 부분이 뭔 줄 알아? 소프트웨어 아님. AI 아님. 손이야. 강해야 함 가벼워야 함 정밀해야 함 빨라야 함 지금 로봇 손이 이게 다 안 됨. "우리가 만드는 기계 시스템은 너무 무겁고, 너무 약하고, 너무 느려." AI는 이미 준비됐음. 몸통이 문제임. 새로운 재료, 새로운 구조, 새로운 설계. 그게 다음 40년을 먹여살릴 거라는 말임. 문과 의대만 바라보는 사이에 기계공학이 다시 시대를 먹으려 하고 있어. ***** 7. 마지막에 한 말이 제일 무서웠음 강연 끝에 젠슨 황이 이렇게 말했어. "너희 중 많은 사람이 AI가 가능해지기 훨씬 전부터 AI를 공부했잖아. 누가 시켜서 한 게 아니잖아. 시장이 있어서 한 게 아니잖아. 믿었기 때문에. 좋아했기 때문에." 이 말이 무서운 이유가 이 사람도 똑같이 살았거든. 아무도 없는 시장에 아무도 원하지 않는 칩을 만들면서 그게 언젠가 세상을 바꿀 거라고 믿으면서. 지금 그냥 좋아서 하고 있는 사람들 있잖아. 시장도 없고, 돈도 안 되고, 주변에 인정도 못 받지만 그냥 믿고 하는 사람들. 젠슨 황이 그 사람들한테 한 말임. "그게 맞는 거야."

슬

슬로모션이야기

플랫폼에 없는 사람이 제일 바빴다

어느 날 SI 업체 대표에게 연락이 왔다. "개발자 한 명만 구해줄 수 있어요?" 납기 3주. 공공 프로젝트. 예산은 크지 않았지만 급했다. 조건이 하나 있었다. "그냥 아무 플랫폼에서 찾은 사람은 말고요." 왜냐고 물었다. "두 번 당했습니다." 아는 사람 몇 명에게 돌렸다. 3일 만에 한 명이 나왔다. 이력서 없었다. 포트폴리오 링크도 없었다. 카카오톡으로 짧게 답이 왔다. "공공 쪽 유지보수 화면이면 구조는 익숙합니다. 일정만 확인하면 가능할 것 같습니다." 솔직히 처음엔 반신반의했다. 그런데 소개해준 사람이 말했다. "내가 10년 넘게 본 사람이야. 믿어도 돼." 첫 미팅 날. 기획서를 한참 보던 그 사람이 말했다. "우선 이 범위까지는 4월 25일까지 개발 반영 가능할 것 같습니다." 그리고 잠깐 멈추더니 덧붙였다. "다만 이 기능은 데이터 구조가 먼저 확정돼야 해서, 1차 오픈에는 조회 중심으로 넣고 수정 기능은 2차로 빼면 안전할 수 있습니다. 어떻게 하시겠어요?" 또 다른 화면을 보면서 말했다. "이 화면은 지금 설계대로도 개발은 가능합니다. 다만 처리 기준을 먼저 정리하고 가면, 나중에 수정할 일이 훨씬 줄어들 것 같습니다. 어떻게 진행할까요?" 말투는 세지 않았다. 단정하지도 않았다. 대신 일정, 범위, 리스크를 정확히 나눠서 말했다. PM이 결정해야 할 건 PM에게 남겨두고, 개발자는 판단에 필요한 근거를 정확히 줬다. 그게 실력이었다. 납기 3주. 18일 만에 끝났다. 클라이언트가 물었다. "이 사람 다음에도 가능합니까?" 궁금해서 물어봤다. "왜 플랫폼에 없으세요?" 그 사람이 말했다. "귀찮아서요." 링크드인은요? "계정은 있는데 4년째 안 들어갔어요." 그럼 일은 어떻게 받냐고 물었다. "그냥 아는 사람들이 연락 줘요." 시장에서 제일 바쁜 사람이 정작 시장에는 없을 수 있다. 좋은 전문가는 검색으로만 찾기 어렵다. 결국 누가 알고 있고, 누가 검증했고, 누가 책임지고 연결하느냐가 중요하다.

아이언.J이야기

스페이스X가 파산 직전 살아난 이유

2008년. 스페이스X는 파산 직전이었다. 로켓 발사 3번 연속 실패. 회사는 현금이 거의 바닥났다. 한 번만 더 실패하면 끝이었다. 당시 일론 머스크의 개인 자산도 대부분 사라진 상태였다. 테슬라도 적자. 스페이스X도 적자. 언론은 머스크를 실패한 사업가로 보기 시작했다. 보통 사람이라면 여기서 포기한다. 투자자를 찾는다. 회사를 판다. 사업을 접는다. 그런데 머스크는 다른 선택을 했다. "한 번 더 쏜다." 4번째 발사. 성공. 그리고 몇 달 뒤. NASA는 스페이스X와 16억 달러 계약을 체결한다. 파산 직전 회사가 세계 우주 산업의 판도를 바꾸기 시작한 순간이었다. 흥미로운 건 성공이 아니다. 실패했을 때의 태도다. 대부분 사람은 실패를 증거로 생각한다. "안 되는 사업이네." "내가 틀렸네." "그만해야겠다." 하지만 머스크는 실패를 데이터로 본다. 왜 실패했는지 분석한다. 어느 부품이 문제였는지 본다. 무엇을 수정해야 하는지 본다. 그리고 다시 시도한다. AI 시대에도 똑같다. 많은 사람들이 AI를 써보다가 며칠 만에 포기한다. 생각보다 원하는 결과가 안 나온다. 자동화가 안 된다. 수익도 안 난다. 그리고 결론을 내린다. "AI 별거 없네." 그런데 실제로 성과를 내는 사람들은 다르다. 프롬프트를 수정한다. 워크플로우를 바꾼다. 도구를 바꾼다. 다시 시도한다. 성공한 사람들의 특징은 실패를 적게 하는 것이 아니다. 실패를 빨리 학습하는 것이다. 2008년 스페이스X를 살린 것은 천재적인 아이디어가 아니었다. 4번째 도전을 할 수 있을 만큼 실패를 데이터로 보는 태도였다. 어쩌면 사람의 인생을 바꾸는 것은 한 번의 성공이 아닐지도 모른다. 대부분이 포기한 다음에도 한 번 더 시도하는 습관인지 모른다.

아이언.J이야기

퇴근 후에도 로켓을 만들던 엔지니어, 20년 뒤 억만장자가 되다

차고에서 취미로 로켓을 만들던 엔지니어. 일론 머스크는 그를 스페이스X의 첫 핵심 멤버로 영입했다. 그리고 20여 년 뒤. 그 엔지니어는 억만장자가 됐다. 많은 사람들이 성공한 사람을 보고 묻는다. "저 사람은 원래 천재였나요?" "운이 좋았던 건가요?" 그런데 일론 머스크가 처음 만난 톰 뮬러는 억만장자도 아니었고 유명인도 아니었다. 그는 항공우주 기업에서 일하는 평범한 엔지니어였다. 다만 한 가지가 달랐다. 퇴근 후에도 로켓을 만들었다. 누가 시켜서가 아니었다. 승진 때문도 아니었다. 취미였다. 집 차고에서 직접 액체연료 로켓 엔진을 만들 정도로 로켓에 미쳐 있었다. 머스크는 그걸 봤다. 그리고 스페이스X를 시작하면서 그를 핵심 엔지니어로 데려왔다. 흥미로운 건 여기서부터다. 많은 기업은 경력을 채용한다. 머스크는 집착을 채용한다. 그 사람이 지금 얼마나 유명한지보다 무엇에 미쳐 있는지를 본다. 왜냐하면 정말 어려운 문제는 월급만으로 해결되지 않기 때문이다. 생각해보자. 2002년 당시 스페이스X는 지금의 스페이스X가 아니었다. 사무실도 없었다. 성공 사례도 없었다. 누구도 민간 기업이 로켓을 우주로 보낼 수 있다고 믿지 않았다. 그런데도 톰 뮬러는 합류했다. 안정적인 회사를 떠나서. 결과는 우리가 알고 있다. 스페이스X는 세계에서 가장 가치 있는 우주기업이 됐고 톰 뮬러 역시 억만장자 반열에 올랐다. 여기서 대부분은 결과만 본다. 억만장자. 스톡옵션. 수조 원 기업. 하지만 머스크가 처음 봤던 것은 돈이 아니었다. 퇴근 후에도 계속하던 행동이었다. AI 시대가 되면서 이 이야기는 더 중요해졌다. 이제는 누구나 AI로 이력서를 쓸 수 있다. 자기소개서도 만들 수 있다. 포트폴리오 문구도 생성할 수 있다. 겉으로 보이는 능력은 점점 평준화된다. 그렇다면 결국 무엇이 남을까. 실제로 문제를 해결해본 경험. 누가 시키지 않아도 계속 파고드는 집착. 그리고 결과가 나올 때까지 포기하지 않는 사람. 일론 머스크는 한 인터뷰에서 사람들에게 가장 어려웠던 문제를 어떻게 해결했는지 설명해보라고 한다. 진짜 해결한 사람은 디테일을 기억하기 때문이다. 어떤 문제가 있었고 어떤 가설을 세웠고 어디서 실패했고 어떻게 해결했는지. 반대로 직접 해보지 않은 사람은 설명이 점점 흐려진다. 생각해보면 당연하다. 로켓을 만드는 회사든 AI를 만드는 회사든 결국 필요한 사람은 비슷하다. 정답을 외운 사람보다 문제를 끝까지 물고 늘어지는 사람. 어쩌면 성공한 사람들의 공통점은 남들보다 똑똑한 것이 아닐지도 모른다. 남들이 퇴근한 뒤에도 계속 붙잡고 있는 무언가가 있다는 것이다. 일론 머스크가 스페이스X 첫 핵심 멤버에게서 본 것도 바로 그것이었다.

JDot이야기

솔직히 이제 디자이너 안 뽑아도 되는 거 아냐? 개발자가 말했다.

개발자가 말했다. "솔직히 이제 디자이너 안 뽑아도 되는 거 아냐?" 회의실 화면에는 ChatGPT로 만든 시안이 떠 있었다. 기획자가 말했다. "어? 생각보다 괜찮은데요?" 대표가 말했다. "이 정도면 초안은 AI로 하면 되겠네." 디자이너는 웃었다. 그런데 기분은 하나도 안 좋았다. 속으로 생각했다. '남의 결과물 보고 판단하는 건 쉽지.' '고객 만나서 취향 맞추고 수십 번 수정하면서 결론 만드는 건 누가 하는데?' '그걸 진짜 AI가 한다고 생각하는 건가?' 회의가 끝났다. 그날 저녁 디자이너는 클로드를 켰다. 몇 분 뒤. React 화면이 완성됐다. 디자이너가 피식 웃었다. "뭐야. "이 정도면 개발도 별거 없네." 옆자리 디자이너가 말했다. "그러니까." "답이 정해진 일은 AI가 다 해주는데 별것도 아닌 것들이.." 속이 시원했다. 그동안 개발자와 부딪혔던 순간들이 떠올랐다. '안 된다고 하더니, '시간 걸린다더니.' 'AI는 몇 초네.' 며칠 뒤. 대표가 회의를 열었다. "좋네. 앞으로는 이렇게 하자." 기획자를 보며 말했다. "기획서 쓰지 말고 피그마 프로토타입까지 만들어." 디자이너를 보며 말했다. "디자인만 하지 말고 퍼블리싱 코드도 뽑아." 개발자를 보며 말했다. "화면 설계도 네가 같이 하고." 회의실이 조용해졌다. 대표는 신이 나 있었다. AI 덕분에 다 할 수 있잖아!! 아무도 대답하지 않았다. '결국 기획 일을 늘리는구나.' '결국 개발 일을 떠넘기는구나.' '결국 디자인 일도 해야 되는구나.' AI 때문에 싸웠던 이유는 기술 때문이 아니었다. 개발자는 디자이너 일이 쉬워 보였고. 디자이너는 개발자 일이 쉬워 보였고. 기획자는 둘 다 쉬워 보였다. AI는 그 착각을 더 크게 만들었다. 왜냐하면 결과물만 보여주니까. 그 과정에서 무엇을 고민했고 무엇을 버렸고, 왜 그렇게 결정했는지는 보여주지 않는다. 그래서 요즘 회의실에서 가장 자주 나오는 말은 이것이다. "AI가 해주던데?" 그리고 가장 위험한 말도 이것이다. "그럼 네가 하면 되겠네."

픽셀노트이야기

팀장이 말했다. "AI가 알아서 하잖아!!"

"이 회의록 화면, AI 요약 붙이면 좋겠는데?" 개발자가 고개를 끄덕였다. "가능합니다." 팀장이 바로 이어 말했다. "단순 요약 말고. 결정사항, 액션아이템, 담당자, 마감일까지." 개발자는 속으로 생각했다. '방향이 맞다. 그래서 더 어렵다.' 무능한 요청이면 대충 쳐낼 수 있다. 이건 그게 안 된다. 팀장이 말했다. "어차피 AI가 본문 읽잖아. 버튼 하나로 가자." 개발자가 멈췄다. '버튼 하나? 아오.. 담배나 피러 갈까..' 버튼 뒤에 숨은 건? 결정사항과 의견, 어떻게 구분하지. 담당자가 명시 안 된 액션아이템은. 마감일이 "다음 주 중"이면 날짜로 바꿔야 하나. AI가 없는 담당자를 만들어내면. 회의록에 고객사 기밀이 있으면. 팀장이 말했다. "일단 빠르게 붙이고, 쓰면서 다듬자." 개발자는 속으로 생각했다. '그 다듬는 동안 이슈 생기면 내가 떠안아야 하는데.' 커뮤니케이션 못하는 사람은 여기서 말한다. "AI가 알아서 하겠죠." 개발자는 그 말을 들으면 혼자 밤을 샌다. "좋습니다. 그럼 AI가 바로 확정해도 되는 항목과 사람이 확인해야 하는 항목을 먼저 나눠보죠." "결정사항은 회의록 본문에 근거가 있을 때만 뽑고, 애매한 내용은 '확인 필요'로 표시하는 게 좋겠습니다." "담당자나 마감일이 명확하지 않은 항목은 AI가 임의로 만들지 않고, 사용자가 확인 후 저장하게 하면 어떨까요?" 이렇게 말하면 공기가 바뀐다. 팀장의 방향은 살아있고 개발자는 사고를 막을 수 있다. AI 시대에 가장 필요한 한 마디는 "됩니다"도 "안 됩니다"도 아니다. "AI가 뽑은 내용을 그대로 결과로 보낼건지, 사람이 확인하고 책임질 구조로 만들 건지부터 정해볼까요?" 이 질문 하나가 버튼 뒤에 숨은 열 개의 사고를 막는다.

픽셀노트이야기

디자이너와 개발자가 싸우는 진짜 이유

디자이너가 말했다. "여기 왜 이렇게 답답해 보이죠?" 개발자가 말했다. "padding 24px 들어가 있습니다." 둘 사이에 3초의 침묵이 흘렀다. 그 침묵 안에 각자 하고 싶은 말이 가득 차 있었다. '픽셀 맞추는 건 기본 아닌가. 내가 수치를 모르는 것처럼 말하네.' '데이터 넣어보고 말하지. 시안에 글자 예쁘게 쳐놓은 대로 되는 줄 아나.' 디자이너가 다시 말했다. "숫자가 틀렸다는 게 아니라, 화면에서 좁아 보인다는 거예요." 개발자가 개발자 도구를 열며 말했다. "여기 보시면 24px 맞아요. 부모 영역이 줄어서 그렇게 보이는 거예요." 디자이너 표정이 살짝 굳었다. '사용자가 부모 영역을 알아야 하나.' 개발자도 방어 모드로 들어갔다. '그럼 처음부터 유형별로 정해줬어야지.' 둘 다 틀린 말을 하지 않았다. 근데 서로에게는 이렇게 들렸다. "기본도 못 맞췄네." "운영 데이터 들어가면 깨지는 건 생각 안 하네." 여기서 커뮤니케이션을 못하는 사람은 계속 자기 언어로만 말한다. "그냥 시안처럼 해주세요." "실제 데이터 넣으면 그렇게 안 된다니까요." 커뮤니케이션을 잘하는 사람은 한 번 번역한다. "이 화면에서 꼭 지켜야 하는 기준이 뭔지 먼저 정해볼까요?" 이 한 마디가 나오면 싸움이 작업으로 바뀐다. 디자이너의 "답답해 보여요"는 "주요 버튼이 더 빨리 눈에 들어와야 한다"가 된다. 개발자의 "데이터 넣으면 달라져요"는 "실제 운영 케이스까지 버틸 기준이 필요하다"가 된다. 좋은 커뮤니케이션은 기분 좋게 말하는 기술이 아니다. 서로 다른 언어로 싸우기 전에, 무엇을 기준으로 판단할지 먼저 잡아주는 것이다. 현장에서 같이 일하고 싶은 사람은 말로 이기는 사람이 아니다. 서로 다른 기준으로 부딪히기 전에, 무엇을 기준으로 볼지 먼저 정리해주는 사람이다. 그 사람이 있는 현장은 공기가 다르다.

더제이 TheJ.노하우

클라이언트가 "빠르게"라고 할 때 진짜 의미

"빠르게 부탁드려요." 이 말을 들었을 때 그냥 넘어가면 안 된다. 빠르게라는 말 안에는 보통 세 가지가 동시에 들어있다. *지금 당장 시작해줬으면 좋겠다는 것 *납기는 절대 못 바꾼다는 것 *예산은 그대로라는 것 여기서 어떻게 말하느냐가 프로젝트 전체의 흐름을 결정한다. 이 상황에서 전략적으로 생각하고 해야 할 말들을 정리해보자. ------------ 1. 요구사항을 쪼개고 일정을 단계별로 합의해야 한다. 빠르게 해달라는 말에 바로 일정부터 잡으면 안 된다. 먼저 전체 요구사항을 꺼내놓고 이번 납기 안에 반드시 들어가야 하는 것과 다음 단계로 넘겨도 되는 것을 구분해야 한다. 이렇게 말하면 된다. "전체 요구사항 중에서 이번 납기 안에 꼭 필요한 것부터 먼저 정해볼까요? 나머지는 다음 단계에서 순차적으로 진행하면 일정 안에 완성도 있게 마무리할 수 있을 것 같습니다." 이 한 마디가 생각보다 많은 걸 정리해준다. 클라이언트 입장에서도 전부를 빠르게 하는 것보다 중요한 것부터 제대로 받는 게 낫다는 걸 알게 된다. ------------ 2. 급한 일에는 단가를 조정해야 한다. 급하다는 건 준비가 덜 됐다는 신호이기도 하다. 준비가 덜 된 프로젝트일수록 중간에 변수가 생기고 범위가 흔들린다. 그 리스크를 고스란히 감수하는 건 작업자다. 이렇게 말하면 된다. "일정이 촉박한 만큼 리스크 관리를 위해 단가를 조정해서 진행하고 싶습니다." 급할수록 단가를 올려야 하는 이유가 거기 있고 처음 견적을 낼 때부터 그걸 반영해야 한다. ------------ 3. 자료 준비 여부를 가장 먼저 확인해야 한다. "빠르게"를 외치는 클라이언트 중 정작 넘겨줘야 할 자료가 준비된 경우는 생각보다 많지 않다. 이렇게 먼저 물어야 한다. "작업에 필요한 자료는 언제 전달해주실 수 있으세요? 그 시점을 기준으로 일정을 잡아야 현실적인 납기를 말씀드릴 수 있을 것 같습니다." 납기가 빠듯한 상황에서 자료가 늦게 들어오면 결국 작업자만 밤을 새운다. 자료 전달 일정이 확정되기 전에는 납기를 확답하지 않는 게 맞다.

더제이 TheJ.노하우

SI 현장에서 첫날을 버티는 법

처음 SI 상주를 시작하면 누구나 당황하는 순간이 온다. 첫날, 아무것도 알려주지 않는다. 자리 안내가 전부고, 개발 환경 세팅도 없고, 프로젝트 설명도 없고, 말 거는 사람도 없다. 이상한 게 아니다. 대부분의 SI 현장이 그렇게 돌아간다. 여기서 하루를 멍하니 보내는 사람이 있고 스스로 파악하기 시작하는 사람이 있다. 첫날의 태도가 첫인상을 결정하고 SI 현장에서 첫인상은 생각보다 오래간다. 첫날 해야 할 말 한 마디, 첫 주 안에 반드시 끝내야 할 것, 퇴근할 때 절대 그냥 나가면 안 되는 이유는..? --------------------- 1. 첫날 해야 할 말 한 마디 "뭐부터 하면 되나요?"는 안 된다. 멍하니 기다리는 것도 안 된다. 이렇게 물어야 한다. "현재 진행 중인 작업 목록이나 담당 업무 정리된 게 있으면 공유해주실 수 있을까요?" 스스로 파악하려는 사람이라는 인상을 주는 순간 팀장이 먼저 말을 걸기 시작하고 그때부터 정보가 흐른다. --------------------- 2. 첫 주 안에 반드시 끝낼 것 문서가 없어도 파악하는 순서는 있다. 실제 운영 중인 화면을 직접 눌러보면서 어떤 버튼을 누르면 어떤 결과가 나오는지, 그 흐름 뒤에 어떤 처리가 연결되는지를 먼저 본다. 이 방식으로 움직이면 일주일 안에 전체 윤곽이 나온다. 물어볼 사람이 있다면 첫 주에 전부 물어야 한다. 두 번째 주부터는 속으로 "그것도 몰라요?"가 된다. --------------------- 3. 퇴근할 때 절대 그냥 나가면 안 되는 이유 SI 상주에서 존재감은 신뢰와 직결된다. 말없이 자리를 비우는 순간 팀 전체가 인식하고 그 인식은 생각보다 빠르게 굳어진다. 퇴근할 때 한 마디면 충분하다. "오늘 로그인 쪽 흐름 분석했고 내일 오전 중으로 관련 내용 정리해서 공유드릴게요." 어색해도 해야 한다. 그 한 마디가 매일 쌓여서 한 달 뒤 재계약으로 돌아온다.

더제이 TheJ.노하우

프리랜서가 견적 낼 때 절대 하면 안 되는 말

"일단 해보고 조율해요." 이 말 한 순간 협상은 끝난다. 범위가 애매한 채로 시작하면 결과물이 나왔을 때 기준이 없다. 클라이언트는 이렇게 말한다. "생각보다 작네요." "이 금액은 좀 그렇지 않나요." 명확하게 정하지 않았으니 반박할 근거가 없다. 견적에는 반드시 세 가지가 들어가야 한다. 범위 / 기간 / 수정 횟수 이 세 가지 없이 나온 숫자는 견적이 아니라 희망사항이다. -------------- 1. 범위 범위는 "무엇을 만드는가"가 아니라 "무엇을 만들지 않는가"까지 명시해야 한다. [포함] 메인페이지 / 소개페이지 / 문의폼 [미포함] 모바일 대응 / 관리자 페이지 / 다국어 처리 구두로 합의한 범위는 범위가 아니다. 문서에 없으면 존재하지 않는 것과 같다. -------------- 2. 기간 납기일만 정하는 건 절반짜리 일정이다. 중간 확인 시점을 함께 잡아야 한다. 1주차 — 초안 공유 및 방향 확인 2주차 — 피드백 반영 3주차 — 최종 납품 중간 확인 없이 납기만 있으면 마지막 날에 이 말이 나온다. "저는 완전히 다른 방향을 생각했는데요." -------------- 3. 수정 횟수 영상 편집, AI 생성물, 디자인 시안처럼 한 번 수정에 시간이 많이 소요되는 작업일수록 수정 횟수는 계약 전에 반드시 명시해야 한다. 수정 2회 포함 이후 추가 수정은 건당 협의 이 한 줄이 없으면 "조금만 더요" "이것도 같이요" "아 그리고요"가 납품일까지 이어진다. 수정 횟수는 나를 지키는 가장 단순한 장치다.

예

예나이야기