DEVOCEAN

저희 조는 이번에 "커리어 스킬" 이라는 책을 읽고 각자의 후기를 남기게 되었습니다!

책이 워낙 방대한 분량(700페이지...)이었기에 각자 인상적이었던, 또는 유익했던 장을 골라 정리해보았습니다.

31장 - 지속적 통합 (김서현)

지속적 통합(CI)는 소프트웨어 빌드, 테스트, 패키징을 자동화하여 효율성을 높이고 에러를 줄여주며,

개발자들이 빠르게 코드를 병합할 수 있어 통합 문제를 해결하는 데 도움이 된다.

또한, 빠른 피드백을 통해 소프트웨어 진화와 품질 개선의 면에서 CI가 중요하다.

과거의 코드 빌드 방법

과거 소프트웨어 개발에서는 자동화 도구 없이 각 개발자가 자신만의 빌드 방법을 사용하며, 이로 인해 소프트웨어 버전과 빌드의 일관성 문제가 발생했다.

또한, 외부 라이브러리 설치, 파일 구조 차이, 소스 코드 체크인에 대한 불확실성 등으로 인한 문제가 발생했다.

이로 인해 코드 수정에 따른 문제 파악이 어려워지고, 빌드 시간이 길어지는 등의 어려움이 있었다.

그리고 빌드 서버가 등장한다

초창기 소프트웨어 개발에서는 빌드 서버 도입으로 개발자들의 빌드 방법을 통일하고 일관성을 유지하려 노력했다.

주간 빌드를 통해 주간에 작업한 개발자들의 코드를 통합하려 했으나 통합 문제와 충돌 등이 발생하여 문제가 있었다.

이후 야간 빌드가 도입되면서 더 빠른 문제 발견과 통합이 가능해졌다.

이에 개발자들은 빌드 프로세스를 자동화하려는 노력을 시작하였고, 많은 스크립트와 빌드 자동화 도구가 개발되었다.

그러나 야간 빌드로는 단순한 빌드만으로는 부족하며, 애자일과 단위 테스트의 인기 상승으로 더 짧은 피드백 주기와 코드 품질 확인이 필요하다는 문제가 제기되었다.

마침내 지속적 통합으로

지속적 통합(CI) 도입 과정은 처음에 어려움이 있었지만, CI를 통해 코드 체크인 시마다 소프트웨어를 빌드하는 방식으로 진행되었다.

초기에는 반대 의견이 많았지만 애자일과 짧은 피드백 주기의 필요성으로 CI의 필수성이 부각되었다.

CI를 실현하기 위한 핵심은 지속적 통합 서버를 도입하는 것이었으며, 이를 통해 코드 변경을 감지하고 빌드를 실행하는 능력을 구축했다.

개발자들은 빌드 시간을 최소화하고 피드백 주기를 단축하기 위해 노력했으며, CI는 코드 품질 평가와 테스트 실행까지 진화하였다.

그러나 코드 변경에 대한 빠른 체크인은 여전히 어려운 과제 중 하나로 남아 있다.

CI 도입 후 프로젝트 컴파일 문제 및 단위 테스트 실패를 신속히 감지하고 해결할 수 있게 되었으며, 이러한 자동화된 과정으로 인해 개발 환경이 크게 개선되었다.

지속적 통합 작업 흐름 샘플

지속적 통합을 활용하는 작업 흐름 샘플은 아래와 같다.

1. 코드 체크인: 체크인과 함께 작업 흐름 시작(체크인 전에 로컬 컴퓨터에서 빌드를 실행하고 모든 단위 테스트를 실행했어야 함)

2. 새 빌드 시작: CI 소프트웨어가 모니터링하던 소스 제어 브랜치에 변화가 생기면 빌드 시작

3. 코드 체크아웃: 모든 변화를 내려받고 작업 디렉터리에 저장

4. 코드 컴파일: 코드 컴파일 및 빌드

5. 정적 분석기 실행: 코드 품질 측정 및 결과 저장

6. 단위 테스트 실행: 컴파일된 코드를 대상으로 단위 테스트 실행 및 결과 기록

7. 결과 보고: 빌드 성공 여부, 실행 시간, 코드 품질 기준, 단위 테스트 등에 관한 정보 출력

8. 소프트웨어 패키징: 배포하거나 설치할 수 있는 형태로 패키징 된 소프트웨어의 모든 파일을 포함하는 파일 구조를 만든 후 전체를 합축

9. 코드의 선택적 배포(지속적 배포): 선택 사항으로, 테스트 목적으로 코드를 특정 환경에 직접 배포

10. 완료: 새 코드가 체크인될 때마다 자동으로 코드를 빌드하고 문제를 확인하고 배포 준비

CI 서버와 소프트웨어

지속적 통합에서 핵심적인 부분 중 하나는 CI 소프트웨어다. CI 소프트웨어 없이는 맞춤형 스크립트를 작성해야 하며, 이는 빌드 서버를 직접 프로그래밍해야 함을 의미한다.

다행히도, CI 소프트웨어의 가치를 인식한 똑똑한 개발자들이 많았고, 이러한 소프트웨어는 지속적 통합의 대부분 작업을 자동화해주며 일반적인 작업 흐름을 쉽게 수행할 수 있도록 해준다.

다양한 CI 소프트웨어가 시중에 있지만, 몇 가지 널리 사용되는 소프트웨어는 아래와 같다.

• 젠킨스

• 허드슨

• 트래비스 CI

• TFS

• 팀시티

느낀 점

이 장을 읽으면서 지속적 통합(CI)의 중요성과 역사에 대해 더욱 이해하게 되었다.

CI가 소프트웨어 개발 프로세스를 어떻게 혁신시켰는지, 그리고 왜 현재의 개발 환경에서 필수적인 요소인지에 대한 내용이 정말 유용하게 다가왔다.

과거의 코드 빌드 방법에 대한 설명에서는 현재와는 다른 개발 환경에서 어떤 어려움과 문제가 있었는지 잘 설명되어 있어,

개발자들이 어떻게 소프트웨어를 개발하고 배포했는지에 대한 흥미로운 통찰력을 얻을 수 있었다.

빌드 서버의 등장과 야간 빌드에 대한 내용은 팀의 협업과 효율성을 향상시키기 위한 노력이 어떻게 진행되었는지를 보여준다.

더불어, CI의 중요성이 점점 부각되면서 개발자들이 어떻게 CI를 도입하고 이를 통해 피드백 주기를 단축하려 노력했던 것도 인상적이었다.

마지막으로, CI 서버와 소프트웨어에 대한 정보도 유용하게 받아들였다. 다양한 CI 소프트웨어를 언급하면서 이들 중 어떤 것을 선택할지 고려할 때 유용한 정보를 얻게 되었다.

전체적으로 이 글은 CI의 중요성과 역사를 알기 쉽게 설명하고 있어, 개발자로서의 경험을 향상시키는 데 큰 도움이 되었다. 앞으로 CI를 더 깊게 공부하고 실무에 적용해보려고 한다.

출처 : 김서현 - 31. 지속적 통합

48장 - 좋은 평판 쌓기 (이승규)

저자는 소프트웨어 개발자라면 좋은 평판을 쌓아야한다고 말합니다. 물론 개발자는 높은 기술력을 갖춰야합니다. 하지만 이것만으로 경력을 발전시키는 데 한계가 있습니다.

이걸 깨닫게 된 경험을 소개하는데요. 개발자로서 성장하던 저자는 연봉 상승이 저조해지는 유리천장을 만났다고 합니다.

이걸 돌파하는데 자신의 개발 블로그가 큰 도움을 주었다고 합니다.

저자의 '심플 프로그래머'라는 블로그가 유명해지면서 컨퍼런스에서도 자신을 알아보는 사람이 생기고, 인터뷰 요청, 헤트헌터의 오퍼가 많이 들어왔다고 합니다.

저자가 주장하는 공식은 이러합니다.

기술 X 마케팅 = $$$

본질 X 스타일 = $$$

프로그래밍 능력 X 평판 = $$$

유명해지는 방법

그렇다면 어떻게 유명해져야 할까요? 아직 전혀 유명하지 않은 저에겐 이 부분이 핵심이었습니다ㅎㅎ

개인 브랜드를 만들어야하는데요.

1. 무엇으로 유명해질지부터 정해야 합니다.

2. 자신을 나타내는 명확, 단순, 간결한 메시지를 만들어야합니다.

브랜딩의 3요소는 메시지, 시각적 요소, 일관성이라고 합니다.

이걸 아는 것만으론 아직 부족하죠. 반복 노출이 필요합니다.

이를 위해 블로그, 유튜브, 개발자 커뮤니티, 개발자 컨퍼런스와 같은 채널을 적극적으로 사용해야합니다.

이 파트가 조금 추상적으로 느껴졌습니다. 다만 이에 대해 좀 더 자세히 적어논 자신의 책을 추천하더라구요...

중복을 줄이려는 건 이해하지만 조금 아쉬운 부분이었습니다.

가치 제공하기

추가적으로 필요한 부분이 있습니다. 가치를 제공하는 것입니다. 베푸는 사람으로 이름을 알려야합니다.

다른 사람에 베풂으로써 최고의 마케팅을 할 수 있습니다.

시간이 든다

위에 적은 모든 방법은 단기간에 성과를 보기 어렵다고합니다. 끈기있게 노력해야겠습니다.

마무리

이 책을 읽으며 개발자 커뮤니티 활동이 왜 중요한지 다시 한 번 되새길 수 있었습니다.

출처 : 이승규 - 48. 좋은 평판 쌓기

23장 - 모바일 개발이란? (강다빈)

휴대전화, 태블릿, 스마트 워치 등 모바일 OS로 구동되는 모든 웨어러블 기기용 앱 개발을 아우른다.

주요 플랫폼 = iOS, Android

iOS 🍎

현시대에 모바일 개발을 등장시킨 주역으로, 애플이 개발했고 애플 제품에만 사용된다.

• BSD 계열인 Darwin과 M을 기반으로 한다 → 근본적으로 유닉스와 유사하다.

• MacOS와 주요 프레임워크 일부를 공유한다.

• 애플리케이션을 개발할 때 MAC을 꼭 써야한다.

• 오브젝티브-C나 Swift를 써서 만드는데 요즘은 Swift가 좀 더 인기를 끌고 있다.

Android 📱

모바일 OS 시장에서 지분이 약 80%로, 가장 많이 차지하고 있다.

오픈소스

• 안드로이드 기기는 누구나 만들 수 있다. iOS는 오로지 애플 기기에서만 작동하도록 설계되었기에 지분이 안드로이드에 비해 적다.

• 리눅스 커널을 기반으로 하며, 구글이 소스코드를 오픈소스로 공개했다.

• 애플리케이션 네이티브 개발 플랫폼은 JAVA.

네이티브 개발

모바일 OS 판매사가 제공하는 툴을 써서 네이티브로 개발하는 방법이다.

iOS는 X-Code와 오브젝티브-C, 스위프트를 사용해 개발하고, Android는 자바를 선호하는 경향이 있다. 안드로이드 개발 스튜디오 IDE가 있다.

**네이티브로 개발하려면 iOS용 코드와 안드로이드용 코드를 완전히 다르게 써야한다.**

장점 : 빠른 속도, 플랫폼의 네이티브 기능을 잘 활용할 수 있음.

크로스플랫폼

크로스 플랫폼 모바일 앱을 만들 수 있게 해주는 프레임워크나 툴이 존재한다.

선택 시 중요 고려사항

• 어떤 프로그래밍 언어를 사용할 것인가?

프레임워크, 모바일 개발에 프로그래밍 언어까지 동시에 배워야 하는 부담스러운 상황을 피하는 게 좋다.

• 네이티브와 하이브리드 중 어느 쪽을 원하는가?

보통 네이티브 앱이 속도가 더 빠르고 앱이 구동되는 모바일 플랫폼과도 더욱 유사해 보인다.

네이티브와 구별하기 어려울 정도로 네이티브에 가까워 보이게하는 크로스 플랫폼 하이브리드 솔루션이 존재하기도 한다.

• 지원하고자 하는 플랫폼의 종류는 몇 가지인가?

iOS나 안드로이드는 대부분 지원한다. 게임 개발이라면 Unity를 사용해서 모든 플랫폼에서 작동되는 게임을 만들 수 있다.

• 코드를 재사용할 생각인가?

네이티브를 지원하는 크로스 플랫폼 솔루션은 네이티브 프레임워크, 라이브러리 등과 더 긴밀하게 연동되기 때문에 재사용 가능한 코드도 줄어든다.

⇒ 네이티브에 가깝게 만들 것인지, 코드를 최대한 많이 재사용할 수 있게 만들 것인지 둘 중 하나를 선택해야 한다.

모바일 웹 앱

웹 기반 모바일 앱이다. 다른 웹 애플리케이션을 만드는 것과 똑같은 방법을 따르되 모바일 기기에서 작동할 수 있게 설계하면 된다.

모바일 개발 고려 사항

진입 장벽이 낮고 성장 가능성이 높아 소프트웨어 개발 입문용으로 좋다.

태생적으로 범위가 제한적 → 혼자서도 단기간에 앱을 제작할 수 있다. 포트폴리오 용으로 👍🏻

출처 : 강다빈 - 23. 모바일 개발

45. 좋은 리더 되기 (남의서)

나쁜 팀은 없다. 나쁜 리더만 있을 뿐이다.

리더십이란?

리더십은 지위가 아니라, 먼저 나서서 무언가를 스스로 해내는 사람이다.

리더십이란, 다른이들로 하여금 자신이 품은 미래의 비전을 따르게 하는 것, 자신이 가는 길로 오게 하는 것, 그리고 자신이 펼쳐놓은 경로를 좇게 하는 것이다.

뒤에서 미는게 아니라, 새 길을 개척하며 앞에서 이끌어가는 것으로, 사람들의 마음을 얻어서 이끌어 가야한다.

이끌기 위해

사람들을 이끌기 위해서는 팀이 할 일을 솔선수범하여 해결하고, 본보기를 보이며, 하기 싫은, 어려운 일을 해야 한다.

모범을 보여라

자신의 영역뿐만 아니라 다양한 영역에서도 앞서나가야 한다.

팀이 훌륭한 업무 윤리를 갖추기 바라는지, 팀원들이 의욕있게 일하길 바라는지, 팀원들이 의사소통 능력과 소프트 스킬을 키우기 바라는지, 그 어느 부문에서든 본인이 가장 앞서 나가야할 것이다.

팀은 리더를 닮아간다.

책임감

사람들의 열정이 고무되도록 나에게 기대하는 것보다 더 높은 목표를 세운다

특별히 높은 책임감을 가진다

업무를 할 때 무슨 일이 있어도 포기하지 않고, 못할 것이라고 예상되는 분량의 업무를 해내려고 노력한다.

팀 전체의 성과를 책임져야 한다.

완전한 주인의식을 가지고 살아야 한다.

팀원들이 실수를 하게된다면 그 또한 리더의 책임이며, 팀원이 실수하지 않고 계획을 잘 이해하도록 지지하는 것이 리더의 역할이었던 것이다.

하지만 모든 이들을 끌고 가는 것이 아니라, 따라오지 못하는 팀원을 내보내며 자신을 따르는 이들을 성공으로 이끌어야 한다.

신뢰

리더 없이 돌아가지 않는 팀은 제대로 된 팀이 아니다.

임무와 의도를 최대한 명확하고 단순하게 전달하며, 업무의 목표와 명확한 작업 절차를 만들어야 한다.

다른 이들에게 업무를 잘 위임하는 것도 리더의 역할이지만, 위임과 포기는 다르다는 것을 엄연히 알고있어야 한다.