어떤 개발자가 되고 싶으니❓❗️

최근 책을 하나 읽게 되었습니다. 바로 박동기 저자님의 "어떤 개발자가 되고 싶니?"라는 책 입니다. 일의 본질과 취업 고민의 해결책을 알려주는 25년 차 현실판 개발자 이야기를 담고 있습니다. 이 책에서 말하고 있는 개발자로서 어떤 마인드를 가져야 하는지, 일을 할 때 어떤 개발 프로세스를 거쳐야 하는지, 어떤 것을 공부해야 하는지를 나누고, 제가 느낀 점을 나누려고 합니다!

개발자의 마인드

개발은 사람을 전제로 하여야 합니다. 개발자는 사람을 존중하는 사랑 기술 이 필요합니다. 디지털 세상에서 펼칠 이 사랑 기술 의 핵심은 아날로그 입자와 디지털 파동을 연결하는 인터페이스가 됩니다. 사랑 기술 과 함께 필요한 것은 배움 기술 입니다.

⬆️ 어떤 개발자가 되고 싶니? 중에서

개발이 사람을 전제로 하여야 한다는 점은 완전 동의합니다. 결국 서비스를 사용하는 유저는 사람이기 때문입니다. 아무리 번지르르하고 멋진 서비스를 만들더라도 사람을 존중하지 않는다면, 위대한 서비스가 될 수 없습니다.

‼️ 디지털 세상에서 펼칠 사랑 기술의 핵심이 아날로그 입자와 디지털 파동을 연결하는 인터페이스가 된다.

정말 멋진 말이라고 생각합니다. 디지털 세계에서 개발되는 우리의 서비스들은 결국 현실 세계를 사는 사람들에게 영향을 주게 됩니다. 사람을 존중하는 사랑 기술 이 베이스로서 디지털과 아날로그의 중간 다리 역할을 할 때, 비로소 그 가치가 빛을 보게 되는 것입니다.

✅ 개발자의 개발 단계는 총 3단계로 구성됩니다. 바로 설계하기 , 구현하기 , 배포와 유지보수하기 입니다.

설계하기

설계는 소프트웨어 요구 명세서(SRS) 작성으로부터 시작됩니다.

SRS (Software Requirements Specification) - 소프트웨어 요구 명세서

1. SRS 작성을 위해 먼저 어떤 부분을 소프트웨어로 개발할지 명확하게 정리할 필요가 있습니다. 소프트웨어로 개발할 필요 없이 더 잘 해결되는 문제라면 당연히 시간과 돈을 투자해서 개발할 필요가 없다는 말과 같습니다. 전체 문제 해결 과정에서 소프트웨어가 개입할 부분을 명확하게 구분지어야 합니다.
2. 그런 다음 클라이언트의 요구사항을 충분히 듣고 파악해야 합니다. 이 요구사항은 몇 번이고 번복되기 때문에 SRS 문서에 반드시 작성해야 합니다. SRS 문서는 건축의 설계 도면과 같습니다. 위의 과정을 거치며 개발 내용을 파악하고 어떻게 구현할 것인지 SRS 문서에 업데이트 해야 합니다. 번복된 요구사항 역시 반영하여 업데이트 하고 버전을 나누어 관리해야 합니다.
3. SRS 문서는 나침반과 같은 존재입니다. 이 나침반이 없으면 배가 산으로 가게 됩니다. 아무리 애자일 방식이어도 설계는 필요합니다. 설계 없이 개발하는 것은 기둥도 세우지 않고 벽돌을 쌓는 것과 같습니다. 그렇지만 SRS를 작성하느라 프로젝트 일정을 맞추지 못한다면, 작성하지 않는 것만 못합니다. 형식적으로 만들지 않는 것이 중요합니다.

장점

SRS 작성은 팀 모두가 행복해지는 길입니다. 프로젝트를 체계적으로 관리할 수 있고, 프로젝트 종결 후 유지 보수가 매우매우 쉬워집니다.

구현하기

실제 코딩에 들어가게 되면, SRS 문서에 기반하여 라이브러리, 엔진, 서버, 클라이언트, 모듈 등의 기능으로 나누어 시작하고, 일정에 맞춰 빠르게 개발하는 것이 관건입니다. 조금만 늦어도 시장에서 성공하지 못할 수도 있습니다. 그래서 소프트웨어 공학이 중요합니다.

소프트웨어 공학의 목적: 최소 비용으로 최단 기간에 개발

볼트와 너트처럼 가져다가 끼워 맞추기만 하면 되는 형태가 가장 이상적입니다. 이 말은 생산성을 항상 고민해야 한다는 것과 같습니다.

프로젝트 규모가 크고, 참여 인원이 많을수록 개발 분야를 나눠 병렬로 개발해야 속도가 빠릅니다. 병렬로 개발할 때는 컴포넌트를 잘 나누고, 인터페이스를 정교하게 정의해야 합니다. 어느 한 쪽이 이 인터페이스를 지키지 않으면 소프트웨어는 거대한 괴물이 됩니다. 그러다 결국 멈추게 되고, 신뢰를 잃게 됩니다. 한 번 신뢰를 잃은 소프트웨어는 회복이 불가능에 가깝습니다.

배포와 유지보수하기

버그를 최소화 해야 합니다. 배포를 하면 SRS 문서와 소스 코드를 버전별로 잘 관리해야 합니다. 배포를 하고 나면 유지 보수는 당연히 필수입니다. 기능 구현에 드는 수고보다 유지 보수에 드는 수고를 줄이는 것이 더 중요합니다. 유지 보수에 드는 수고는 시스템의 복잡성에 비례하므로, 개발은 단순하게 설계하고 구현하는 것이 가장 좋습니다.

개발자가 배워야 할 핵심 기술

위에서 말했던 개발자에게 필요한 2가지 기술 중 다른 하나인 배움 기술 이 필요한 시점입니다.

1. 프로그래밍 언어
2. Data Structure, Algorithms
3. Database
4. 프레임워크, 라이브러리
5. 오픈 소스 프로그램
6. OS
7. 리눅스/유닉스 명령어
8. 테스트
9. 디버깅 스킬
10. 버전 관리 시스템 VCS(Git)
11. 코딩 스타일 가이드
12. 도메인 지식

(참 많기도 하네요..ㅠ)

그래서 나는?

지금까지는 프로젝트를 하면서, 구체적인 설계 없이 개발했습니다. 프로젝트의 규모가 그리 크지 않았기도 했지만, 빨리 코딩하고 싶다는 마음이 많이 앞섰기 때문인 것 같습니다. 책에서는 이런 마음을 경계하고 잘 절제할 줄 알아야 한다고도 했습니다. 앞으로 더 큰 규모의 개발을 하게 될텐데 지금부터 잘 준비하고, 대비해야겠다는 생각이 들었습니다.

개발자는 배워야 할 게 참 많은 것 같습니다. 학교에서 배우는 것도 있지만, 학교에서 가르쳐주지 않는 것들은 실제로 프로젝트를 진행하면서 직접 부딪쳐야 배울 수 있는 것 같습니다. PARD에 들어와서 놀이톤, 0기 해커톤, 숏커톤, 새싹톤 등 여러 프로젝트를 경험했고, 그 과정에서 많이 배울 수 있었습니다. 정말 감사한 한 학기였습니다..!