티스토리 뷰
신입 개발자로 취업하는 것은 분명 쉽지 않습니다. 한편으로는 기업들이 인재가 없다고 말하기도 하지요. 하지만 이 상황을 단순히 기업의 탓으로만 돌리거나, 신입 개발자만의 문제로 보는 것은 적절하지 않습니다. 무엇이 근본적인 문제인지 함께 고민하고, 해결해보려는 적극적인 자세가 우리 모두에게 필요하다고 생각합니다.
저는 이 문제에 대해 오랫동안 고민해 왔습니다. 그러던 중 오늘 『모던 소프트웨어 엔지니어링』(데이비드 팔리, 2025)을 읽다가 그 개념을 명확히 정리해 준 내용을 보고 "바로 이거다!" 싶어 이렇게 포스트를 남깁니다.
이번에 소개할 내용은 사실 그렇게 '모던'한 개념은 아닙니다. 과장 조금 보태면 호랑이 담배피던 시절부터 내려오던 이야기 입니다.하지만 오늘날 모던한 소프트웨어를 만들때에도 쓰이는 개념입니다.
저는 ‘안정성’을 고려하는지를 기준으로 신입과 주니어를 구분할 수 있다고 생각합니다. 이때 말하는 안정성이란 다음의 요소 입니다.
안정성
변경 실패율 change failure rate: 코드 수정했는데 문제 생긴 비율
복구 실패 시간 recovery failure time: 실패한 뒤 복구까지의 시간
코드는 한 번 만들었다고 끝나는 것이 아닙니다, 피드백을 받아 수정해야 하는 상황이 자주 생깁니다. 이럴 때 중요한 것은 "코드를 수정했을 때 문제를 일으키는 비율이 낮아야 한다"는 점입니다.
코드 변경에서 문제가 생기는 주된 이유는 한번 돌아가는데에만 집중해서 만들기 때문입니다. 바꾸어 말하면 원칙을 지키지 않고 개발했다는 의미입니다.
지켜야 할 원칙은 여러 가지가 있겠지만, 그중 하나를 꼽자면 바로 단일 책임 원칙(SRP: Single Responsibility Principle) 입니다.
함수 하나가 파싱도 하고, 비즈니스 로직도 수행하고, DB 입출력까지 처리하는 식으로 코드를 작성하는 경우가 많습니다. 하지만 이러한 역할들은 Parser, Service, Repository로 분리하여 각각의 책임을 적절히 나누어야 합니다.
저는 이러한 책임 분리를 제대로 할 수 있다면, 신입 개발자라도 취업해서 일하는 데 큰 문제가 없다고 생각합니다. 물론, 결코 쉬운 일은 아닙니다.
간호사에 비유하자면, 주사를 놓는 일과 비슷하다고 볼 수 있습니다. 쉬워 보일 수 있지만, 실제로는 혈관을 찾고, 정확하게 바늘을 꽂아야 하며, 압력도 고려해야 하고, 경우에 따라 환자의 혈압도 확인해야 하죠. 또한 투여하는 약물이 어떤 것인지도 잘 알고 있어야 합니다. 이처럼 단순해 보이는 일도 실제로는 많은 전문성과 주의가 필요한 작업입니다.
개발자 일은 이런 전문성을 요구 하기 때문에 신입은 자리가 없다고 하고 기업은 인재가 없다고 하는 것 같네요.
- Total
- Today
- Yesterday
- docker container case
- 도커컨테이너
- 도커티슈박스
- docker container
- shellscript
- 개발자
- 도커티슈케이스
- 싱가폴
- 도커각티슈박스
- docker container tissue box
- docker container tissue
- 이직
- docker container whale
- Sh
- 2017 티스토리 결산
- Linux
- 도커각티슈케이스
- vim
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |