COMMUNITY

커뮤니티

경험을 공유하고 수익 기회를 만들어보세요.

BUILD YOUR ASSETS

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

노하우, 템플릿, 자료를 공유하고 판매해보세요.

픽셀노트·23시간 전이야기

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

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

픽셀노트·23시간 전이야기

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

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

더

더제이 TheJ.·2일 전노하우

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

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

더

더제이 TheJ.·2일 전노하우

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

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

더

더제이 TheJ.·2일 전노하우

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

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

더

더제이 TheJ.·2일 전노하우