반디앤루니스 인터넷서점
전체

로고이미지

검색

  • ▼
HOT ISSUE

네비게이션 실시간 인기 책

    나는 왜 개발자 말이 어려울까?

    예약판매 베스트

    [예약판매] 나는 왜 개발자 말이 어려울까? 외계어 같은 개발 용어 사이에서 살아남기 위한 생존 소통 가이드

    • 이프로 저
    • 경이로움
    • 2026년 05월 25일
    • 정가
      22,000원
    • 판매가
      19,800원 [10% 할인]
    • 결제 혜택
      무이자
    • 적립금
      1,100원 적립 [5%P]

      NAVER Pay 결제 시 네이버페이 포인트 5% 적립 ?

    • 배송구분
      업체배송(반디북)
    • 배송료
      무료배송
    • 출고예상일
      2026년 05월 26일 이후

      ※ 출고예정일은 도서 재고상황에 따라 변동될 수 있습니다.

    수량
    바로 구매 쇼핑카트 담기 위시리스트
    회원리뷰
    - [0]
    ISBN: 9791194508953 392쪽 510g 145 x 225 (㎜)

    지금 이책은

    이 분야의 베스트셀러

    이 책이 속한 분야

    책 소개

    상품문의 / 정보수정 요청 >

    이 책은

    “말이 통해야 일도 술술 풀린다!”

    외계어 같은 개발 용어 사이에서 길을 잃은
    기획자를 위한 생존 소통 가이드

    “이건 안 됩니다.” 개발자와 협업하며 가장 자주 듣는 말이자, 기획자의 가슴을 답답하게 만드는 문장이다. 기획자의 눈에는 그저 오타 하나 고치는 일이고, 버튼 위치를 위에서 아래로 옮기는 ‘사소한’ 수정인데 돌아오는 대답은 늘 거절이다. 별거 아닌 일이 ‘왜 안 되는지’ 설명하는 개발자의 말을 듣고 있자면, 분명 한국말인데도 외계어를 듣고 있는 것 같은 아득한 기분마저 든다.
    문제는 그다음이다. 왜 안 되는지, 무엇이 문제인지 이해되지 않는 순간부터 소통은 단절되고 프로젝트라는 수레바퀴는 삐걱거리며 멈춰 서기 시작한다. 많은 기획자가 이 거대한 벽을 넘기 위해 ‘파이썬이라도 배워야 하나’ 고민하지만, 협업의 해결책은 기획자가 코드를 한 줄 더 읽는 능력에 있지 않다.
    진정한 협업의 핵심은 기술 그 자체가 아니라, 기술이 작동하는 ‘사고방식’을 이해하는 것에 있다. 개발자가 왜 안 된다고 말할 수밖에 없는지, 그들이 무엇을 우려하고 어떤 우선순위로 시스템을 바라보는지 그 메커니즘을 이해하는 순간, 꽉 막혔던 대화의 물꼬가 트이고 일이 술술 풀리기 시작한다.

    다행히 개발자를 이해하는 일은 진짜 외계인과 대화하는 것보다 훨씬 쉬운 일이다. 이 책은 기획자가 반드시 알아야 할 개발의 기본 구조와 언어를 다루지만 딱딱한 이론에만 머물지 않는다. “버튼 하나 바꾸는데 왜 다음 주까지 기다려야 하는지”, “복사 붙여넣기만 하면 될 것 같은 페이지가 왜 새로 만드는 것보다 어려운지”와 같은 실무 현장의 생생한 갈등 사례를 통해 현실적인 실마리를 제공한다. 그리고 개발자가 “안 됩니다”라고 말할 때 그 이면에 숨겨진 ‘데이터 구조의 한계’, ‘기존 코드와의 충돌 가능성’, ‘예상치 못한 사이드 이펙트의 공포’ 등을 입체적으로 읽어내는 힘을 길러준다.
    나아가 막연하게 “언제 끝나요?”라고 재촉하는 대신 개발자의 방어 기제를 낮추는 질문법부터, 개발자가 신나서 키보드를 두드리게 만드는 피드백 전략, 개발 범위와 일정을 조율하는 기획자만의 생존 가이드까지 아낌없이 담았다. 그동안 개발자와의 소통에서 반복적으로 벽을 느껴왔다면, 이 책이 그 벽을 허물고 개발자를 든든한 아군으로 만드는 확실한 가이드가 될 것이다.


     


     


    출판사 리뷰

    기획자의 요구와 개발자의 현실을
    모두 만족시키는 소통의 기술

    개발자와 기획자, 한 배를 탔지만 서로 다른 언어를 쓰는 이들의 갈등은 어제오늘 일이 아니다. 분명 일하고 있는데 프로젝트는 제자리걸음이라면, 이제 소통의 방식을 점검해야 할 때다. 8년의 개발 경력과 5년의 기획 실무를 거치며 양쪽의 언어를 모두 섭렵한 저자의 경험에 따르면, 갈등을 풀 수 있는 실마리는 아주 높은 확률로 ‘기획자’에게 달렸다. 기획자가 개발 과정을 이해해야 비로소 협업의 병목 구간을 정확히 파악하고 절충해 프로젝트를 완수할 수 있는 실질적인 해법을 찾을 수 있기 때문이다. 따라서 이 책은 현업에서 발생하는 수많은 문제 상황에 대해 개발자의 입장을 ‘기획자의 시선’에서 풀어낸다.
    1부 ‘화성에서 온 기획자, 금성에서 온 개발자’에서는 함께 일하는 개발자가 어떤 사람인지에 대해 알아본다. 개발자가 어떤 태도로 일을 대하고 어떻게 문제를 해결하는지 등 그들만의 고유한 특성을 파헤친다. 이를 통해 기획자가 흔히 겪는 소통의 벽이 사실은 서로를 향한 불신이 아니라 ’일‘을 바라보는 시각 차이에서 온다는 점을 깨닫고, 개발자의 사고방식을 입체적으로 이해하는 기초를 다진다.
    2부 ‘개발자와의 흔한 갈등 사례’에서는 현장에서 가장 빈번하게 발생하는 생생한 갈등 사례를 중심으로 기획자가 한 번쯤 품었을 법한 의문들에 대해 개발자의 속사정을 들려준다. 그동안 ‘왜 안 된다는 거지?’라며 답답함을 느꼈던 근본적인 원인을 짚어보고, 갈등의 벽을 넘기 위한 대응책을 찾는다.

    3부 ‘협업을 위한 개발 기초 지식’에서는 기획자로서 개발자와 원활히 소통하는 데 필요한 개발 지식을 살펴본다. 클라이언트와 서버의 관계부터 데이터베이스의 작동 원리, 그리고 Git이나 JSON 같은 협업 도구의 개념까지 폭넓게 다루며, 비개발자가 기술적 장벽을 넘어 데이터와 논리에 기반한 의사결정을 내릴 수 있도록 한다.
    4부 ‘개발자와 함께 완벽한 기획자로 성장하는 법’에서는 앞서 배운 이해와 지식을 바탕으로 개발자와 함께 성장하는 구체적인 실천 전략을 제시한다. 개발자가 선호하는 기획서 작성법부터 기획자의 치트키가 될 API 검토 노하우, 그리고 질문 하나로 개발자의 방어 기제를 허무는 질문법까지, 기획자의 전문성을 증명하고 프로젝트의 성공을 이끄는 실무 생존 기술을 아낌없이 공개한다.
    만약 개발자를 이해하기 위해 이 책을 집어 들었다면 이미 절반은 성공한 셈이다. 상대방을 이해하고자 하는 마음은 협업의 가장 강력한 무기가 되기 때문이다. 이 책을 통해 그들의 세계를 들여다보고 이해의 접점을 찾는 순간, 당신이 겪는 업무 스트레스의 대부분이 눈 녹듯 사라질 것이다.

    책 속에서

    개발자들에게 ‘된다’는 ‘모든 사항이 100% 작동함’을 의미한다. 따라서 이들은 업무 가능 여부에 관한 질문을 받으면 대부분 이 일이 수행 가능한 일인지, 또 불가능한지에 대해 답변해야 하고, 또 수행 가능하다면 언제까지 할 수 있는지, 어느 정도의 시간이 소요되는지도 이야기해야 한다. 그래서 질문을 듣는 동안 요청 내용이 실현 가능한지, 불가능한 요청은 없는지 꼼꼼히 따진다. 마치 조금이라도 끊어지면 열차가 달릴 수 없는 기찻길처럼, 중간에 무언가 하나라도 구현이 불가하다면 전체 개발이 불가능해진다. 그러다 보니 불가능한 부분을 찾는 그들의 태도는 종종 공격적이라고 오해를 사기도 한다. 이럴 때는 최대 속도로 달리고 있어 주변을 보지 못하는 경주마처럼 그저 목표 지점(실행 가능 여부)을 향해 전력 질주하고 있을 뿐이라고 이해하면 좋다. (65쪽)

    기획자가 개발자에게 기능 구현 가능 여부를 물을 때, 자연스럽게 “언제까지 가능한가요?”라는 질문을 함께 던지곤 한다. 빠듯한 일정과 성과에 대한 압박 속에서, 어떻게든 빠르게 결과를 만들어 내고 싶은 마음은 기획자나 개발자나 마찬가지일 것이다. 그런데 종종 개발자로부터 이런 답변을 듣게 된다. “이거 지금 당장 하려면 하드코딩 해야 해요” 얼핏 들으면 ‘하드코딩’이라는 낯선 단어 뒤에 ‘된다’라는 긍정의 메시지가 숨어 있는 것처럼 느껴질 수 있다. ‘아, 뭔가 어려운 방법이긴 하지만 어쨌든 된다는 거구나! 그럼 일단 그렇게 하고, 나중에 시간 될 때 제대로 고치면 되지 않을까?’ 하는 안도감이 들 수도 있다. (중략) 하드코딩이란 특정 값이나 로직을 코드 안에 ‘직접 박아 넣어서’ 변경이나 확장이 어렵게 만드는 것을 말한다. 우스갯소리로 “고수들은 귀찮게 머리 쓰며 로직을 짜지 않고 그냥 돌아가게만 한다”라고도 표현하지만, 사실 하드코딩은 결코 ‘고수’의 방식이 아니다. 오히려 당장의 편의를 위해 미래의 불편함을 예약하는 것에 가깝다. 이렇게 하드코딩이 된 부분은 종종 잊히며 잠재적인 위협이 된다. 유연성이 없어 매번 수정 때마다 영향이 있는지 직접 챙겨야 하는 대상이 되기도 한다. (115-116쪽)

    예쁘게 디자인된 버튼, 잘 정리된 텍스트, 사용자를 편리하게 이끄는 인터페이스. 눈에 보이는 화면은 말 그대로 ‘빙산의 일각’이다. 그 화면 뒤에는 수많은 코드와 로직, DB와의 복잡한 상호작용 그리고 알 수 없는 외부 시스템과의 연동까지 거대한 시스템이 있다. 마치 거실에 조명 하나 위치를 바꾸려고 봤더니, 그 전기선을 통해 다른 조명들이 릴레이처럼 엮여 있어서 전체 배선을 건드려야 수정이 가능한 상황과 같다. 겉으로 보기엔 간단한 수정 요청 같아도, 개발자에게는 이 거대한 시스템의 어느 부분을 건드려야 할지, 그 파장이 어디까지 미칠지 가늠해야 하는 복잡한 문제로 다가온다. 특히 골치 아픈 건, 내가 직접 짜지 않은 ‘남의 코드’를 수정해야 할 때다. 운 좋게 잘 짜이고 문서화까지 완벽한 코드를 만난다면 정말 큰 짐을 던 기분이 들지만, 현실은 시궁창일 때가 더 많다. 주석 하나 없이 수수께끼처럼 꼬여 있는 스파게티 코드, 왜 이렇게 만들었는지 도무지 이해할 수 없는 로직, 심지어 작성자는 이미 퇴사하고 없어서 물어볼 사람조차 없는 상황이라면? 개발자는 그야말로 맨땅에 헤딩하는 심정으로 코드 해독 작업에 들어가야 한다. (중략) 더 큰 문제는, 이런 복잡하게 얽힌 시스템과 해독 불가능한 코드 속에 ‘사이드 이펙트’라는 언제 어디서 터질지 모르는 시한폭탄이 숨어 있다는 것이다. 분명 버튼 A의 문구만 살짝 바꿨는데, 갑자기 관련 없는 페이지 B에서 데이터가 꼬이거나, 잘되던 결제 시스템에서 오류가 뿜어져 나올 수도 있다. (124-125쪽)

    데이터 규격은 컴퓨터와 개발자들 사이에서, 혹은 시스템끼리 데이터를 주고받기 위해 만든 것이다. 즉 복잡한 데이터(정보)를 누구나 이해할 수 있도록 ‘규칙에 맞게’ 정리하기로 ‘약속’한 것으로 개발자들에겐 없어서는 안 될 중요한 매개체다. 서로 다른 시스템, 다양한 플랫폼이 공존하는 인터넷과 앱 서비스 환경(웹서버, 모바일앱, DB 외부 API 등)에서 데이터를 주고받는 데 표준화된 규격이 필요하다. 표준화된 규격이 없으면 데이터를 주고받을 때마다 데이터 구분을 콤마로 할지, 탭으로 할지, 어떤 값들을 보낼지 등을 매번 정해야 한다. 또 규격 없이 데이터를 주고받으면 서로 보낸 데이터를 해석하지 못하거나 오작동이 발생할 수 있고, 복잡한 서비스에서는 이런 문제로 큰 장애가 발생하기도 한다. 대표적으로 가장 많이 사용하는 데이터 규격이 JSON과 XML이다. (214쪽)

    개발 과정에서는 큰 아키텍처 결정 외에도 수많은 작은 기술적 결정들이 이루어진다. 이러한 일상적인 결정들이 모여 프로젝트의 성공 여부를 결정한다. 예를 들어 서비스에서 간헐적으로 에러가 발생한다는 유저들의 민원이 어젯밤부터 리포팅 된 상황을 생각해 보자. 개발팀에 문의해 보니 “CPU가 피크를 찍어서 증설이 필요하다”라는 기술자로서의 의견을 냈다면, 기획자는 이 결정이 추가 비용이 발생할 수 있고, 상황에 따라 서비스 중단 시간이 발생할 수 있다는 점을 이해해야 한다. 왜 CPU가 피크를 찍었는지, 다른 해결책은 없는지 파악하고 의사결정에 고려하는 것 역시 중요하다. 또 다른 상황으로, “요청이 있을 때마다 처리하면 될 거라고 예상했던 개발 방향을 배치 작업을 만들어서 커버하겠다”라는 개발자의 제안을 들었다고 가정해 보자. 기획자는 이 결정이 왜 필요한지 이해해야 한다. 배치 처리는 시스템 부하를 분산시키고 효율성을 높일 수 있지만, 실시간성이 떨어질 수 있다. 이러한 트레이드오프를 이해하고 비즈니스 요구 사항과 맞는지 판단해야 한다. (351쪽)

    저자 소개

    이프로

    개발자로 8년, 기획자로 5년 이상 근무 중인 직장인으로, 개발자와 기획자의 두 언어를 모두 해석하는 희귀한 이력을 가졌다. 게임업계에서 개발자로 일하며 코드를 짤 때는 미처 몰랐다. 이토록 기획자들이 개발자들을 원망하고 있을 줄은. 기획자의 자리에서 바라본 세상은 개발자와 기획자 사이의 깊은 간극이 존재했다. 이 지독한 오해를 줄이고 싶다는 간절함으로 ‘이프로’라는 필명으로 글을 쓰기 시작했다. 단순히 효율적인 협업 방법을 설명하기 위함이 아니다. “개발자들을 미워하지 마세요”라는 진심 어린 당부와 함께, 서로의 언어를 이해하지 못해 발생하는 불필요한 감정 소모를 멈추길 바라는 마음을 담았다.
    무엇보다 이 책을 펼친 독자들이 이미 ‘개발자를 이해해 보려는 선한 의도’를 가졌음에 주목한다. 타인의 영역을 공부하고 이해하려는 그 마음이 얼마나 아름답고 절실한지 알기에, 그리고 그 노력이 결국 프로젝트의 성공을 이끄는 가장 강력한 무기가 될 것임을 확신하기에 13년의 경험과 노하우를 아낌없이 쏟아부었다.

    목차

    프롤로그: 기획자와 개발자의 원활한 소통을 위해

    1부: 화성에서 온 기획자, 금성에서 온 개발자

    1장. 나는 ‘누구’와 일하고 있나
    개발자는 어떤 사람일까?
    개발자가 말하는 ‘일 잘하는 개발자’
    개발자는 문제 해결을 즐긴다
    개발자가 말하는 ‘완성’의 의미
    AI 시대, 개발자는 대체될까?

    2장. 개발자와의 협업은 왜 힘들까?
    개발자도 기획자가 어렵다
    개발자가 기획자를 불신하게 되는 과정
    개발자가 쉬운 수정도 안 된다고 하는 이유
    확정 짓고 싶은 개발자, 감히 최종이라 말 못 하는 기획자
    개발자가 좋아하는 기획자
    대화할수록 왜 더 멀어질까?
    [별면] 외주 개발과 가내수공업 개발의 차이

    2부: 개발자와의 흔한 갈등 사례

    1장. 시간 없어요! 좀 빨리빨리 안 될까요?
    저기, 버튼 하나 바꾸는 건데, 다음 주까지 기다리라고요?
    말씀하신 거랑 다르잖아요, 왜 갑자기 일정이 늘어나요?
    리소스가 부족한 거면, 개발자 한 분 더 투입하면 안 돼요?
    제가 책임질 테니까 운영 DB 데이터 직접 수정합시다!
    기획서 나왔다고 치고, 얼마나 걸려요?

    2장. 일단 이렇게 좀 해주세요, 제발요
    하드코딩이 뭔지는 모르겠는데, 되는 거면 일단 하고 나중에 수정하면 안 될까요?
    문구 조금만 바꾸고 버튼 위치 살짝만 왼쪽으로 옮겨주세요!
    전에 썼던 페이지 있죠, 똑같이 복붙만 해주세요!
    테스트는 저희가 알아서 할 테니, 일단 개발부터 쭉쭉 해주세요!

    3장. 좀 알아듣게 설명해 주시겠어요?
    제 자리에선 안 되던데요, 되는 거 맞아요?
    기술적인 문제가 정확히 뭐죠? vs 설명하면 알아들으세요?
    다 말씀드렸는데 무슨 스펙을 더 정해달라는 거예요?
    [별면] 장애가 발생하면 개발자들은 뭘 하나요?

    3부: 협업을 위한 개발 기초 지식

    1장. 내 서비스는 어떻게 움직이는 걸까?
    클라이언트와 서버 그리고 과부하
    데이터는 어디에, 어떻게 저장되는 걸까?
    DB와 성능

    2장. 개발자들은 일할 때 어떤 도구를 쓸까?
    너무 많은 프로그래밍 언어, 다 배워야 하나요?
    JSON으로 주세요
    라이브러리와 프레임워크 그리고 의존성
    ‘최종.pptx’, ‘최최종.pptx’ 대신 Git
    [별면] 개발 도구의 진화로 개발자는 편해졌을까?

    4부: 개발자와 함께 완벽한 기획자로 성장하는 법

    1장. 일 잘하는 기획자는 무엇이 다를까?
    기획자가 갖춰야 할 필수 역량
    개발자가 좋아하는 기획 문서 작성법
    기획자의 치트키, API 검토
    우선순위 조정과 타협점 찾기
    변경 요청에 대처하는 생존 기술

    2장. 개발자와 웃으며 일하는 협업 센스
    개발자의 몰입을 지켜주는 회의 시간 관리
    야근 없는 프로젝트 일정 만들기
    마음 상하지 않게 의견 전하는 방법
    일정 지연에 대응하는 위기관리 전략

    3장. 기술의 벽을 뛰어넘는 기획자의 소통법
    어려운 개발 용어를 대하는 자세
    기술 회의에서 기획자가 해야 하는 일
    질문만 바꿔도 일의 결과가 달라진다
    기술 결정 시 고려해야 할 요소

    4장. 협업의 완성, 최상의 시너지 만들기
    협업을 유지하게 하는 회고의 힘
    오늘의 실수가 내일의 성공이 되도록
    개발자에게 기획과 비즈니스를 알려주는 방법
    [별면] 기획자와 개발자가 친해지면 발생하는 일

    에필로그: 개발자와 기획자가 서로 이해할 때

    배송 시 유의사항

    - 반디앤루니스에서 구매하신 도서는 물류 대행 위탁업체 웅진 북센을 통해 배송됩니다.
     (배송 포장에 "웅진 북센"으로 표기될 수 있습니다.)

    - 구매한 상품의 품질과 배송 관련 문의는 반디앤루니스로 문의 바랍니다.

    - 천재지변 및 택배사의 사정에 따라 배송이 지연될 수 있습니다.

    - 결제(입금) 완료 후 출판사 및 유통사의 사정으로 품절 또는 절판 되어 상품 구입이 어려울 수 있습니다. (별도 안내 예정)

    - 도서산간지역의 경우 추가 배송비가 발생될 수 있습니다.

    반품/교환

    상품 설명에 반품/ 교환 관련한 안내가 있는 경우 그 내용을 우선으로 합니다. (업체 사정에 따라 달라질 수 있습니다)

    반품/교환

    반품/교환
    반품/교환 방법 홈 > 고객센터 > 자주찾는질문 “반품/교환/환불” 안내 참고 또는 1:1상담게시판
    반품/교환 가능 기간 반품,교환은 배송완료 후 7일 이내, 상품의 결함 및 계약내용과 다를 경우 문제발견 후 30일 이내에 신청가능
    반품/교환 비용 변심 혹은 구매착오의 경우에만 반송료 고객 부담(별도 지정 택배사 없음)
    반품/교환 불가 사유
    • 소비자의 책임 사유로 상품 등이 손실 또는 훼손된 경우
    • 소비자의 사용, 포장 개봉에 의해 상품 등의 가치가 현저히 감소한 경우
    • 복제가 가능한 상품 등의 포장을 훼손한 경우 : 예)만화책, 잡지, 화보집 등
    • 시간의 경과에 의해 재판매가 곤란한 정도로 가치가 현저히 감소한 경우
    • 전자상거래등에서의 소비자보호에 관한 법률이 정하는 소비자 청약철회 제한 내용에 해당되는 경우
    • 해외주문 상품(해외 원서)의 경우(파본/훼손/오발송 상품을 제외)
    소비자 피해보상
    환불지연에 따른 배상
    • 상품의 불량에 의한 반품, 교환, A/S, 환불, 품질보증 및 피해보상 등에 관한 사항은
      소비자 분쟁해결 기준(공정거래위원회고시)에 준하여 처리됨
    • 대금 환불 및 환불지연에 따른 배상금 지급 조건, 절차 등은 전자상거래 등에서의
      소비자 보호에 관한 법률에 따라 처리함
    반품/교환 주소 경기도 파주시 문발로 77, 웅진북센(반디앤루니스)
    • 회사명 : (주)서울문고
    • 대표이사 : 김홍구
    • 개인정보 보호책임자 : 김홍구
    • E-mail : bandi_cs@bnl.co.kr
    • 소재지 : (06168) 서울 강남구 삼성로 96길 6
    • 사업자 등록번호 : 120-81-02543
    • 통신판매업 신고번호 : 제2023-서울강남-03728호
    • 물류센터 : (10881) 경기도 파주시 문발로 77 반디앤루니스
    copyright (c) 2016 BANDI&LUNI'S All Rights Reserved