팟캐스트는 여러 핵심 주제를 통해 소프트웨어 개발의 다면적인 특성을 조명합니다.
1. 개발자 직책의 재정의
-
전통적인 직책의 한계: ‘엔지니어’, ‘아키텍트’와 같은 많은 소프트웨어 개발 직책은 다른 산업에서 차용되었으며, 소프트웨어 개발의 고유한 맥락을 완전히 포착하지 못한다는 점이 논의됩니다.
-
‘엔지니어’에 대한 관점: 힐렐 웨인(Hillel Wayne)의 연구 ‘코더는 엔지니어인가?’를 언급하며, 소프트웨어 엔지니어링이 전통적인 엔지니어링과 공유하는 어려움과 차이점에 대해 탐구합니다. ‘다이어그램 그리기’, ‘계획 수립’, ‘시스템 통합’ 등이 ‘엔지니어링’처럼 느껴진다는 의견이 제시됩니다.
-
‘코더’/’프로그래머’의 부적절함: ‘코더’나 ‘프로그래머’는 실제 업무의 작은 부분만을 나타내며, 외과 의사를 ‘자르고 꿰매는 사람’으로 부르는 것과 같이 전문성을 제대로 담지 못한다고 지적합니다. 코드 작성 외에 ‘생각하고, 토론하고, 연구하는’ 시간이 훨씬 더 중요하다고 강조됩니다.
2. 소프트웨어 개발과 불완전함의 수용
-
수작업 공예품 비유: 진행자 중 한 명은 미완성 퀼트를 완성하는 경험을 통해, 원작자의 인간적인 실수와 불완전함을 이해하고 받아들이는 것이 프로젝트에 대한 스트레스를 줄이는 데 도움이 되었다고 말합니다.
-
코드에 대한 연민: 이러한 통찰은 ‘끔찍한 코드’를 만났을 때 다른 개발자들의 상황과 최선을 다했음을 이해하는 ‘연민’으로 확장될 수 있다고 제안합니다.
-
MVP(Minimum Viable Product) 접근 방식: 소프트웨어 개발은 물리적인 건축과 달리 ‘스케이트보드를 자동차로’ 진화시키는 MVP 접근 방식이 가능하며, 이는 지속적인 개선과 리팩토링을 용이하게 하지만 동시에 복잡성을 증가시킬 수 있다고 언급됩니다.
3. 컨설팅 개발자의 역할과 가치
-
클라이언트 자립 지원: Thoughtbot과 같은 컨설팅 개발자의 궁극적인 목표는 클라이언트가 스스로 비즈니스와 애플리케이션을 운영할 수 있도록 돕는 것입니다.
-
기술 이전 및 멘토링: 클라이언트 팀(개발자, 창업자, 제품 관리자 등)에게 자신의 프로세스를 공유하고, 새로운 기술(예: Ruby on Rails)을 가르치며, 학습 방법을 학습하도록 돕는 역할을 수행합니다.
-
문제 해결 및 비즈니스 통찰: 단순히 기능 구현을 넘어, 클라이언트의 비즈니스 목표에 기여할 최적의 솔루션을 함께 찾고, 외부 전문성(성능, 아키텍처, 애자일 프로세스 등)을 제공하여 팀의 역량을 강화합니다.
-
‘질문하는 능력’의 중요성: 컨설팅을 통해 배운 가장 중요한 기술 중 하나는 ‘좋은 질문’을 던지고, ‘왜?’라는 본질적인 질문을 통해 더 나은 해결책을 모색하는 능력입니다.
4. AI 개발 도구에 대한 관점
-
AI의 역할과 한계: AI에 대한 회의적인 시각과 함께, 계획 모드를 가진 LLM 도구를 활용하여 개발 프로세스를 개선하려는 시도도 언급됩니다.
-
인간의 참여 중요성: 코드 작성은 비록 작은 부분이지만 즐거운 과정이자 깊은 사고가 일어나는 중요한 부분이며, 이를 완전히 AI에 위임하는 것에 대한 거부감을 표합니다. 설계와 구현이 긴밀하게 연결된 피드백 루프의 가치를 강조합니다.