1.2. 개발자 업무 이해

앞서 '1.1. 취업 준비의 출발점'에서 우리는 학생의 관점에서 벗어나, 실무자의 관점으로 취업 준비를 바라봐야 한다는 점을 확인했습니다. 그렇다면 이제 그 관점을 바탕으로, 소프트웨어 개발자가 실제로 어떤 흐름으로 일을 하는지 구체적으로 살펴보겠습니다.

 

1. 소프트웨어 개발자의 업무

 

흔히 개발자라고 하면 검은 화면에 코드를 빠르게 입력하는 모습만 떠올리기 쉽습니다.

하지만 실제 현업에서 소프트웨어가 만들어지는 과정은 생각보다 훨씬 체계적이며, 코딩은 전체 과정 중 하나의 단계일 뿐입니다.

개발자의 업무는 일반적으로 소프트웨어 개발 생명주기(SDLC)라는 흐름 안에서 진행됩니다.

• 1️⃣ 계획 (Planning): 왜 필요한가? 범위는 어디까지인가?
• 2️⃣ 분석 (Analysis): 누가 쓰는가? 어떤 요구사항이 있는가?
• 3️⃣ 설계 (Design): 시스템 구조, DB, 화면 흐름을 어떻게 만들 것인가?
• 4️⃣ 구현 (Implementation): 설계를 바탕으로 실제 코드를 작성한다.
• 5️⃣ 테스트 (Testing): 제대로 동작하는가? 실제 환경에서도 문제없는가?
• 6️⃣ 유지보수 (Maintenance): 운영 중 문제를 해결하고 기능을 개선·확장한다.

⚠️ 자주 하는 오해

“개발자는 코딩만 잘하면 된다”라고 생각하기 쉽지만, 실제 업무에서는 계획·분석·설계·테스트·운영까지 함께 이해해야 합니다.

즉, 개발자의 일은 코딩 자체가 아니라, 소프트웨어가 만들어지고 운영되는 전체 흐름을 다루는 일입니다.

2. 실전 예시: 카페 앱 개발

이 흐름이 아직 추상적으로 느껴진다면, 여러분이 직접 카페 창업 프로젝트에 투입된 개발자라고 상상해 봅시다.

“키오스크와 모바일 주문 앱을 만들어주세요”라는 요청을 받았습니다.

이때 곧바로 키보드에 손을 올리고 코딩부터 시작하면 될까요? 아닙니다.

 

 

1️⃣ 계획 단계 (Planning)

먼저 프로젝트의 목적과 범위를 분명히 해야 합니다. “꼭 필요한 핵심 기능(MVP)은 무엇인가요?”, “언제까지, 얼마의 예산으로 만들어야 하나요?” 같은 질문을 통해 방향을 확정합니다.

 

🎯 산출물 → 포트폴리오

프로젝트 개요서, 범위 정의서, 일정표, 리스크 목록

2️⃣ 분석 단계 (Analysis)

현장의 업무 흐름을 구체적으로 파악해야 합니다. “손님은 어떤 순서로 주문하고 결제하나요?”, “직원은 어떤 화면으로 주문을 확인하나요?”, “환불이나 주문 취소는 어떻게 처리하나요?” 같은 질문을 통해 실제 요구사항을 정리합니다.

💡 왜 중요한가?

현장을 제대로 이해하지 못하면, 기능은 만들어도 실제로는 쓰기 어려운 서비스가 될 수 있습니다.

🎯 산출물 → 포트폴리오

요구사항 명세서(SRS), 업무 프로세스 다이어그램, 유스케이스 목록

3️⃣ 설계 단계 (Design)

분석 결과를 바탕으로 시스템의 뼈대를 설계합니다. 프론트엔드와 백엔드가 어떤 API로 통신할지, 주문·결제·메뉴 데이터는 어떤 구조로 저장할지, 사용자는 어떤 화면 흐름으로 앱을 쓰게 될지를 정리합니다.

💡 왜 중요한가?

설계가 없으면 구현 단계에서 코드가 쉽게 꼬이고, 나중에 수정 비용도 크게 늘어납니다.

🎯 산출물 → 포트폴리오

아키텍처 다이어그램, ERD, API 명세서, 화면 설계서(UI/UX)

4️⃣ 구현 단계 (Implementation)

이제 설계를 바탕으로 실제 코드를 작성합니다. 로그인, 장바구니, 주문 생성, 결제 연동, 관리자 화면 등 필요한 기능을 프론트엔드와 백엔드 코드로 구현합니다.

💡 왜 중요한가?

학생들이 가장 익숙한 단계이지만, 현업에서는 코딩이 전체 과정의 전부가 아니라 일부라는 점을 분명히 알아야 합니다.

🎯 산출물 → 포트폴리오

소스 코드(GitHub), 빌드 결과물, 배포 자동화 스크립트

5️⃣ 테스트 단계 (Testing)

코드가 완성되었다고 끝이 아닙니다. 주문이 몰릴 때도 안정적으로 동작하는지, 결제와 환불이 정상 처리되는지, 예외 상황에서 오류가 없는지 검증하고 버그를 수정해야 합니다.

💡 왜 중요한가?

“내 컴퓨터에서는 잘 된다”와 “실제 사용자가 문제없이 쓴다”는 전혀 다른 이야기이기 때문입니다.

🎯 산출물 → 포트폴리오

테스트 케이스 문서, 테스트 결과서, 결함(버그) 조치 이력

6️⃣ 유지보수 단계 (Maintenance)

앱이 실제 매장에 배포되고 손님들이 사용하기 시작하면, 그때부터 또 다른 실무가 이어집니다. 장애 대응, 성능 개선, 기능 추가, 운영 데이터 분석, OS 및 브라우저 환경 변화 대응 등 지속적인 관리와 개선이 필요합니다.

💡 왜 중요한가?

서비스는 한 번 만들고 끝나는 것이 아닙니다. 운영하며 발생하는 문제를 해결하고 계속 개선해야 실제 비즈니스 가치가 생깁니다.

🎯 산출물 → 포트폴리오

운영 매뉴얼, 장애 대응 이력, 트러블슈팅 기록, 버전 릴리즈 노트

📌 핵심 정리
좋은 개발자는 단순히 코드를 작성하는 사람이 아니라,

문제를 이해하고 구조를 만들고 검증하고 운영까지 생각하는 사람입니다.

3. 현업의 일하는 방식: 애자일(Agile)과 협업

 

앞에서 살펴본 1~6단계는 개발 업무를 이루는 구성 요소입니다.

실제 현업에서는 이 단계를 한 번에 길게 끝내기보다, 작은 단위로 반복하며 점진적으로 개선하는 경우가 많습니다.

과거에는 위 1~6단계를 몇 달에 걸쳐 순차적으로 길게 진행하는 워터폴 방식이 많았습니다.

 

오늘날 많은 IT 조직은 애자일(Agile) 방식으로 일합니다.

거대한 서비스를 한 번에 완벽하게 만드는 대신, 1~2주 단위의 짧은 스프린트(Sprint)를 반복하며 계획·설계·구현·테스트를 빠르게 순환시키고 기능을 조금씩 개선해 나갑니다.

• 기획자(PM): Jira, Notion 등의 도구를 통해 우선순위와 요구사항을 정리합니다.
• 디자이너: Figma 같은 툴로 화면 구조와 사용자 경험(UI/UX)을 설계합니다.
• 동료 개발자: Git, GitHub를 사용해 각자 작성한 코드를 합치고, 코드 리뷰(Code Review)를 통해 품질을 함께 관리합니다.

💡 현업 신입 개발자의 하루 일과 (예시)

• 10:00 AM: 데일리 스크럼으로 어제 한 일, 오늘 할 일, 이슈를 공유
• 10:30 AM: 기획자·디자이너와 신규 기능 요구사항 논의
• 11:30 AM: 동료가 올린 PR을 확인하고 코드 리뷰 피드백 남기기
• 01:00 PM: 설계 내용을 바탕으로 본격 구현
• 04:00 PM: 테스트 수행 및 버그 수정
• 06:00 PM: GitHub에 작업 내용 반영 후 마무리

📌 핵심 정리
현업 개발은 혼자 조용히 코딩만 하는 일이 아니라, 짧은 반복 주기 안에서 협업·설계·구현·검증을 함께 수행하는 일입니다.

4. 핵심 요약: 코딩은 전체 과정의 일부일 뿐이다

• 개발자의 일은 오직 코딩만이 아닙니다.
• 코딩은 소프트웨어 생명주기 중 일부에 불과합니다.
• 분석·설계·테스트·운영 관리가 뒷받침되지 않으면 서비스는 제대로 동작하기 어렵습니다.
• 개발자는 단순히 프로그램만 만드는 사람이 아니라, 서비스가 실제로 동작하고 운영될 수 있도록 책임지는 사람이라는 관점이 필요합니다.
• 여러분은 이 전체 업무 흐름을 이해하고 따라갈 준비가 되어 있다는 것을 포트폴리오를 통해 보여줄 수 있어야 합니다.

💡 학생이 꼭 기억할 것
좋은 포트폴리오는 “기능을 만들었다”를 넘어서, 문제를 어떻게 이해했고 어떤 구조로 풀어냈는가를 보여줘야 합니다.

5. 면접관이 신입 개발자를 평가하는 관점

현업의 면접관은 신입 개발자에게 입사 첫날부터 완벽한 실무 수행을 기대하지 않습니다.

처음에는 회사의 도메인, 협업 방식, 레거시 시스템을 새롭게 익혀야 한다는 점을 선배들도 잘 알고 있습니다.

출처: https://youtu.be/Pt9-SXAJPlU?si=KXsbitpJQuvHpR2_

 

그래서 면접관은 단순히 “문법을 얼마나 외웠는가”만 보지 않습니다. 그보다 기초 지식을 실무 문제 해결과 연결할 수 있는 사람인가, 그리고 현장에서 함께 일해 나갈 수 있는 사람인가를 더 중요하게 봅니다.

• 문제를 논리적으로 분해하는 사고 과정이 있는가?
• 무작정 키보드부터 두드리기 전에 먼저 설계하려는 태도를 갖추고 있는가?
• 동료의 리뷰를 수용하고 소통할 준비가 되어 있는가?

면접관의 머릿속에는 이런 질문이 있습니다.

“이 지원자는 단순히 코드를 외워서 치는 사람인가?”
“아니면 현장의 문제를 이해하고, 소프트웨어와 협업을 통해 해결해 갈 수 있는 사람인가?”

즉, 신입에게 필요한 것은 “이미 모든 것을 할 수 있다”는 허세가 아니라, 실무의 흐름을 이해하고 빠르게 적응하며 함께 성장할 준비가 되어 있다는 신뢰를 주는 것입니다. 여러분의 이력서와 포트폴리오는 바로 그 점을 증명하는 제안서가 되어야 합니다.

6. 정리: 이제 무엇을 기준으로 준비해야 하는가?

이제 우리는 소프트웨어 개발자의 일이 단순히 코드를 작성하는 것에 그치지 않는다는 점을 확인했습니다.

현장의 개발자는 문제를 이해하고, 요구사항을 분석하고, 구조를 설계하고, 구현하고, 테스트하고, 운영과 개선까지 이어지는 전체 흐름 속에서 일하는 사람입니다.

 

따라서 신입 개발자의 취업 준비 역시 단순히 언어 문법을 더 많이 외우는 방향으로 흘러가서는 안 됩니다.

오히려 소프트웨어가 어떤 흐름으로 만들어지고 운영되는지 이해하고, 이를 기준으로 준비해야 합니다.

 

• 나는 단순히 코드를 배우는 사람이 아니라, 실제 업무 흐름 속에서 일할 준비를 하는 사람인가?
• 내 포트폴리오는 기능 나열이 아니라, 문제를 이해하고 해결한 과정을 보여주고 있는가?
• 나는 혼자 만드는 연습만 한 것이 아니라, 협업과 운영까지 고려하는 관점을 갖추고 있는가?