어제 진행했던 아티클 카타에서 ‘왜 개발자는 안 된다는 말부터 할까?’라는 이야기가 나왔다.
나 역시 디자인 출신 비전공자였기에 공감이 됐다.
처음에는 나도 개발자들의 반응이 꽤 답답하게 느껴졌던 기억이 있다(전문 용어가 많으니 외계어로 들리던...).
하지만 이후 직접 간단한 기능 구현을 경험해 보고, 개발 강사님과 현업 개발자 지인들에게 여러 이야기를 들으면서
‘왜 그런 반응이 나오는지’를 조금은 이해하게 됐다.
(풀스택(프론트엔드+백엔드) 과정을 우수하게 수료하긴 했으나 백엔드에 흥미가 너무 없었다...
프론트엔드로 전향하려 했지만, 수료 시점에 이미 비전공 신입 개발자는 살아남기 힘든 강자존의 세계가 펼쳐져 있었다.
어쩌다 코딩도 해봤고 강사 경험(공예 관련 대략 1년 반)도 있다 보니, 코딩 강사 한 번 해보라며 캐스팅(?)되어 약 6개월 정도 코딩 강사로 활동했다.)
그래서 이번 글은, 비전공자이면서도 약간의 구현 경험을 해본 입장에서
개발자들이 왜 우선 '어렵다', '안 된다'는 이야기를 먼저 하게 되는지 최대한 쉽게 풀어서 정리해보려 한다.
모쪼록 PM을 준비하는 분들에게 조금이라도 도움이 되길 바라며...
- 해당 아티클 출처 : 오늘도 개발자가 안 된다고 말했다.
오늘도 개발자가 안 된다고 말했다.
오늘도 개발자가 안 된다고 말했다.
velog.io
오늘의 답변
-
사실적인 느낌+쉽게 풀어 설명한 부분이 어색하지 않게
답변의 문체 그대로 내용만 다듬었다.
보통 기능 구현은 단순히 코드 한 줄 수정으로 끝나는 경우가 많지 않습니다.
기존의 방대한 코드와 충돌하지 않아야 하고
(여러 개발자가 장기간 작업해 온 프로젝트의 경우, 담당자라도 전체 구조를 모두 파악하지 못한 경우가 많음),
DB 연동 과정에서 예상치 못한 문제가 발생할 수도 있으며,
버튼 하나를 수정하더라도 연결된 로직이나 화면 흐름까지 함께 수정해야 하는 경우도 있습니다.
대표적으로 MVC 패턴이라는 구조가 있는데, 딥하게 들어가면 복잡하니 간단히 설명하자면
- M(Model) : 데이터와 비즈니스 로직 처리(데이터 상태 변경 및 처리 담당)
- V(View) : 실제 사용자에게 보이는 화면(저희에게 친숙한 브라우저 화면)
- C(Controller) : 사용자의 입력을 받아 Model과 View를 연결(사용자 요청 처리 및 화면 흐름 제어)
(MVC 외에도 MVVM, Clean Architecture, Hexagonal, MSA 등 다양한 구조와 설계 방식이 존재함)
즉, 화면 하나를 수정하더라도 단순 UI 수정인지, 데이터·로직까지
연결된 기능 수정인지에 따라 구현 난이도가 크게 달라질 수 있습니다.
• 예를 들어서
- 로그인 버튼 크기/색상 변경(단순 디자인 변경)
→ CSS(스타일) 수정 수준에서 끝날 수도 있음
• 반면 기능 로직의 경우에는 예를 들어
- 로그인 실패 횟수 초과 시 접근 제한 팝업 표시 → 특정 페이지로 이동
같은 기능도 실제로는,
- 실패 횟수 저장 로직 → DB 처리(실패 횟수 저장 및 조건 비교) → 조건 분기(실패 횟수 조건과 부합하면 이후 로직 진행) → 팝업 처리 → 페이지 이동 → 예외 상황 대응(ex. 페이지를 찾을 수 없음(404)) 등...
위와 같이 여러 작업이 복합적으로 연결될 수 있습니다.
또한 위에 언급했듯, 구현 도중 기존 코드와 충돌하거나,
보안·성능·운영 정책 문제까지 연결될 수도 있어서
겉보기에는 간단해 보이는 기능도,
실제 운영 환경에서는 구현 난이도나 리스크가 크게 달라질 수 있습니다.
그래서 개발자 입장에서는 이 모든 배경을 하나하나 설명하기보다(한 차례 머리속으로 시뮬레이션 돌려 본 뒤),
우선 '가능/불가능' 또는 '우선순위상 어려움'(성수기에는 특히 우선순위가 높은 업무를 먼저 처리해야 함/일정상 반영이 어려운 이슈(구현하는 데 너무나 많은 시간이 소요될 경우 등))부터 이야기하게 되는 겁니다.
특히 비개발 직군에게 기술 구조를 전부 설명해도 전달이 어려운 경우가 많고,
(개발자들이 당연하게 구사하는 전문 용어들이 마구마구 쏟아져 나올 가능성이 큼)
설명 자체에도 많은 시간과 커뮤니케이션 비용이 필요하기 때문입니다.
(내용을 장황하게 설명할 시간에 기능을 하나 더 구현하는 게 낫다고 생각하는 편)
그래서 실무에서는 단순 질문보다는 조금 더 구체적으로
왜 어려운지, 어떤 리스크가 있는지, 어느 부분이 가장 큰 문제인지를 짚어보고,
→ '그렇다면 현재 조건에서 현실적으로 가능한 대안은 무엇인지' 의견을 여쭤봄
이렇게 물어보는 방식이 더 효율적으로 대답을 도출해 낼 수 있습니다.
(물론 다른 이해관계자의 의견도 들어보고 통합하여 최선의 결론을 도출해야 하죠(개발자의 의견만 반영할 수 없기 때문에...))
뭐, 개인적으로 생각하기엔 거의 GPT에게 프롬프트를 입력하고
원하는 답을 도출해내는 과정과 비슷한데,
아무래도 사람 대 사람이다 보니 사회적인 매너를 갖춰 의견을 전달하고
답을 주고받는 형식에 가깝다고 생각합니다.