책을 읽게된 이유
코딩의 신 아샬 님께서 진행해주시는 모임에 참석하기 위해서, 미리 책을 읽었다. 예전에 쏙쏙 들어오는 함수형 코딩 이라는 모임에도 참여했었는데, 정말 재미있고 자극도 많이 받아서 이번에 또 참석신청 했다.
책 좋아함 + 개발자 = 왜 아직도 안감?
이 책을 이 모임을 알기 전에도 알고 있었다. 책이 나오자마자, 여러 곳에서 소개했었다. "커리어리" 에서 봤어서 관심이 있었다. 이 책이 그리고 딱 나를 타켓으로 만든 책이라고 느껴졌다. 만 3년을 향해 달려가는 개발자 그래서 읽었다.
코드 작성이 특기인, 000 입니다.
p20
사회 초년생일 때는 구현 기술을 사용해서 코드를 작성하는 것이 개발이라고 생각했다. 이 외에 다른 활동은 개발이라 여기지 않았다. 그만큼 개발을 좁게만 바라봤다.
p21
개발은 회사와 나에게 돈을 벌어주는 기능을 만드는 과정이기도 했다.
이 문장을 보고 프로그래밍을 시작했던 순간이 떠올랐다. 코드를 작성하는 것이 나의 책임이고 역할이라고 생각했었다. 심지어 여러 언어와 여러 개발 파트 중 오직 iOS 개발만 나의 업무라고 생각했다. 그 당시 나에게는 다른 일은 관심 대상도 아니였고, 신경쓰지 않아도 되는 줄 알았다.
이 글을 작성하는 23.09.21 기준으로 나에게 "개발" 은 가장 잘 다룰 수 있는 문제해결 방법이다. 그렇다고 오직 개발만을 이용해서 문제를 해결하는 것은 아니다. 예를 들어, "사용자가 우리 앱에 머무는 시간을 늘리자" 라는 문제가 주어졌다고 가정해보자. 그러면, 내가 개발을 통해 기여할 수 있는 부분은 높은 퀄리티의 앱을 구성하여 버그로 이탈퇴는 것을 막는 것이다. 하지만 마케팅의 관점에서 생각한다면 GA 를 도입하여 유저 행동 패턴을 파악하고 데이터 기반의 의사결정을 내릴 수 있다.
이 둘 중 무엇이 더 임펙트 있는 일일까? 상황마다 다르겠지만, 일반적으로는 마케팅 관점이라고 생각한다.
지금은 "그로스 해킹" 이라는 책을 읽어보기도하고, GA 를 도입하고, 데이터 로깅 설계도 해보고 있다. 그러면서 느끼는 것은 내가 푸는 문제에 따라서 가장 적합한 도구를 사용하는 것이 중요하다고 느끼고 있다.
성장하지 못하면 불안
p22
회사업무를 하면서 성장한다는 느낌을 받지 못한 이유 중 하나는 개발과 성장을 동일시했기 때문이다. 코드를 작성하고 새로운 기술을 써야 개발 능력이 향상된다고 여겼기 때문에 어느 정도 익숙해진 회사의 개발 업무로는 더 이상 성장할 수 없다고 생각했다.
p22
새로운 구현 != 성장
구현 기술 외적으로도 성장시켜야 할 역량이 많다. 그러니 어떤 구현 기술을 사용하고 싶다는 욕망에 너무 사로잡히지 말자.
최근에 가장 많이 느꼈던 감정이다. 회사에서 업무를 하면서, "이전에 했던 개발을 반복하는 것이 아닌가?", "그렇다면, 나는 성장하고 있는 것인가?", "작년의 나와 지금의 나가 싸우면 누가 이길까?" 이런 생각들을 했다. 그런 고민속에서 지금은 나름의 돌파구를 찾아나가고 있다.
사실 자세히 따지고 보면 기술적 성장이 없는 것은 아닐 지도
나의 돌파구는 이 책에서 말한 것처럼 단순히 개발 역량 말고 "소프트 스킬" 의 영역이다. 업무를 관리하고, 협업하는 프로세스를 구축하려고 노력한다. 이 과정이 정말 쉽지 않다고 느낀다. 왜냐하면, 다른 사람들에게 무언가 강제한다는 것은 정말 어렵기 떄문이다. 이 책에서도 후반부에 "프로세스" 파트에서 나온다.
프로세스를 도입시키기 위해서, 각 구성원들의 니즈를 파악하는데 집중했다. 기획자들은 자기 상사들 혹은 다른 사용자들에게 완성도 높은 앱을 전달하고 싶을 것이다. 그래서 완성도 있는 앱을 구성하기 위해서는 테스트 시나리오 그리고 명확한 기능 명세서가 있어야 한다고 설득했다. 같은 동료들에게는 이후에 이직을 위해서 문서화를 해두는 것이 좋다 혹은 지금 하고 있는 업무가 명확히 보여야 다른 업무를 안받을 수 있다 라고 설득했다. 그래야 야근안함
어째든 성장하는 방법이 여러가지이다. 정 성장을 못느낀다면 이직하는 것도 방법이다. 하지만 이직 전에 일단 최대한 성장할 수 있는지 돌아보고 찾아나서는 활동 자체는 어떤 환경에서도 살아남는 적응력을 길러주는 것이라고 믿는다.
일하면서 공부 방법
학습전략
일단 주력 기술을 집중적으로 학습해야 한다. 주력기술이라 하면 당장 또는 가까운 미래에 경제적 이익을 얻는 데 필요한 기술을 말한다.
...(중략)...
다른 기술은 그다음이다.
p45
유행에 상관없는 구현 기술
(앞에 두 개의 사고사례를 보여줌)
두 사례는 동시성 처리 기초 지식이 얼마나 중요한지를 보여준다.
...(중략)...
주니어 개발자라면 유행과 상관없는 지식을 1년에 1개 이상 학습하자. HTTP 프로토콜, 네트워크 프로그래밍 기초, 동시성 처리, 프로그래밍 등...
일하면서 공부하려면, 엄청난 내적동기가 필요하다. 특히, 따로 시간을 내서 공부한다는 것은 힘들다. 경쟁자로, 디즈니의 무빙, 넷플릭스 나는솔로 등 너무 막강한 상대들을 대상으로 이겨내야한다. 그래도 이겨내고 하면된다. 하지만, 좀더 쉬운 방법으로 일하면서 공부를 하는게 편하긴하다.
그래서 일하는 방향과 공부하는 방향을 정조준해두는 것이 가장 효율적으로 시간을 보내는 방법이라고 생각한다. 내가 만약 지금 Flutter 프로젝트를 하면서 Provider 를 회사에서 적용하고 있다고 가정하자. 그러면 애초에 나의 공부 방향이 Provider 이면 편하다. 일하는 것 자체가 공부니까. 만약 딥다이브하게 공부하고 싶다면, 다른 상태관리인 RiverPod 혹은 bloc 에 대해서 공부해볼 수도 있다. 이 떄 공통점과 차이점에 대해서 공부하면, 신기하게 Provider 에 대해 더 잘 이해된다.
같은 부분을 공부할 수도 있지만, 그 근간 기술을 공부하는 방법도 있다. Provider 와 연관있는 InheritedWidget 에 대해서 공부할 수도 있다. 더 깊게는 Service Locator Pattern 을 익히면서 동시에 여러 가지 의존성 주입에 대해서 공부할 수도 있다. 이렇게 공부하면, 다른 장점이 많겠지만 가장 와닿는 것은 기억이 오래 남는다.
회사에서 내가 배운 기술 적용하기
p46~47
구현 기술 적용
공부한 구현 기술을 업무에 적용하는 것은 즐거운 일이다.
...(중략)...
어떤 기술을 학습하면 당장 쓰고 싶다는 마음이 생기기 마련이다. 하지만 상황과 조건에 맞게 사용해야 한다. 그렇지 않으면 앞에서 언급한 것처럼 모두에게 부담이 생길 수 있다. 따라서 어떤 기술을 도입할 때는 보수적으로 고민하고 다음과 같은 내용을 신경 써야 한다.
- 신뢰 구축
- 함께 할 동료
- 타당성
- 점진적 적용
- 시장상황
책에서 나온 것처럼, 내가 배우고 싶은 것을 익히고, 그것을 그대로 적용할 때 정말 기쁘다. 왜 기쁠까? 아마도 무엇인가 성장한다는 느낌도 있을거고, 자기 효능감도 있지 않을까?
하지만 회사에서 혹은 공동체에서 프로그래밍을 한다는 것은 혼자서 일하는 환경이 아니다. 주변 사람들과 함께 해야 의미가 있다. 나혼자 잘난 맛에 코딩을 한다면, 그냥 혼자하면 된다. 조금 비효율이 있더라도 팀에서 합의했다면 따르는 것이 조직생활하기엔 좋다. 마치 악법도 법이다 라는 문구가 떠오른다.
나도 이것에 대해서 고민이 많았던 적이 있다. 효율적으로 혹은 트랜디한 라이브러리를 적용하고 싶어서 안달이 났었고, 어찌해서라도 적용하고 싶었다. 하지만 동료들이 모두 나처럼 새로운걸 배우고 싶어하진 않았다. 지금 상태보다 더 나아져야할 이유를 찾지 못했던 동료였다. 그럴 때 어쩔 수 없이 이전스타일로 코딩을 할 수밖에 없었다.
다음 회사에서는 함께 새로운 것을 해보자는 마음이 맞는 개발자를 만났다. 둘이 성향이 새로운 것을 하고 싶어하니, 새로운 걸 서로에게 알려주고 서로가 서로에게 득이 되는 관계였다.
이런 경험 이후, 회사에서 단순히 누군가를 잘한다고 뽑는 것이 아니라 지금 팀과 성향이 맞는지 본다고 느꼈다. 회사가 면접장에서 하는 질문들이 이전에는 나의 단순 지식 유무로 느꼈다면, 지금은 나의 스타일을 볼라고 하는 걸로 느껴진달까?
이왕 겪어야 하는거라면, 빨리 겪고 부끄러워보자: 우월주의 Feat. 2~3 년 개발자
p52
특정 기술을 사용해야 우월하다는 생각을 가진 개발자를 마주칠 때가 있다. 우월함을 느끼다 못해 다른 기술을 사용하면 무시하거나 경멸하는 모습을 볼 때도 있다.
영웅주의도 경계해야 한다. 면접을 하다 보면 모든 문제를 해결할 수 있는 개발자가 되고 싶다는 말을 들을 때가 있다.
마지막으로 잘해야 하는 게 구현 기술만은 아니라는 점을 말하고 싶다.
iOS 개발 시장 이야기를 많이하게 되는데, iOS 에서는 Rx + MVVM 이 기본으로 자리잡고 있다. 이것에 대해서 모른다면, 사실 자격요건에서 많은 부분 결격사유가 된다. 물론 신입이라면, 어느정도 예외로 둘 수도 있겠다. 그래도 준비하는 입장에서는 그렇다고 불안감이 해소되진 않는다. 여전히 Rx 를 배우고 MVVM 을 적용한다.
Rx의 단점으로는 Map 을 사용했을 떄 발생하는 단점이 당장 눈에 들어온다. 타입추론이 자동으로 되지 않아서, 코드 작성에 상대적으로 더 큰 집중력이 소비된다. 그리고 그렇게 구성한 코드가 다른 비동기 처리보다 더 좋다고 증명된 것을 본 적이 아직 없다. 만약 그런 글이 있다면 추천 부탁드려요. 꼭 보고싶네요ㅠㅠ
난 iOS 진입 당시에 무지성으로 일단 배웠다. 그러다가 스스로 개발하면서 계속 회의감이 들었다. 아무리 생각해도, 남이 시켜서 이렇게 하는게 도저히 납득이 되지 않았다. 내가 스스로 그 문제해결방법이 필요해서 적용하지 않다보니, 면접에서 물어보면 막히기 일쑤였다. 대답할 이유가 뭐 겪어보지도 못한 언젠가 도움될 "테스터블한" 이라는 용어를 쓰기도하고, "유지보수성" 이라는 구체적으로 그려지지않는 이득을 설명했다. 일단 다른 사람들이 그렇다니까 나도 그랬다.
시간이 지나고 UI 와 비즈니스로직을 분리하고 싶다는 니즈가 생겼다. UI 는 변하더라도, 비즈니스 로직은 공통으로 사용했으면 좋겠다는 니즈가 있었다. 그 때, MVVM 에 장점이 내게 마음을 울렸다. 동시에 MVVM 구조를 구현하기 위해서는 Binding 이라는 과정이 중요했다. 이 과정을 용이하게 해주는 도구가 Rx 라는 라이브러리인 것이다.
말하다보니, 다른 길로 가버렸는데, Rx 에 대해서 기술적으로 우월함을 느끼는 분을 봐서 쓴 글이다. 모든 Rx 유저를 폄하하려고 쓴 글은 절대 아니다. 할 이유도 없음 그래서 어떤 기술이든 우월함을 따지는 사람 그리고 그런 순간이 누구나 한 번쯤은 있지 않을까?
유지보수하다보면 불안이 생긴다. 그 불안이 테스트를 하게 한다.
개발 비용
p60
개발자가 흔히 "기존 코드를 바꾸는 것보다 다시 만드는 게 더 빨라요"란 말을 한다.
...(중략)...
하지만 개발자가 이렇게 말하는 이유는 유지보수 비용과 관련이 있다.
p62
유지보수만 하다 보면 실력이 안 늘고 신규 프로젝트를 해야 실력이 향상된다고 생각하는 개발자를 만날 때가 있다.
...(중략)...
유지보수를 하면서 얻는 역량과 신규 프로젝트를 할 때 얻는 역량이 다르다고 본다.
...(중략)...
예를 들어
오류를 수정하면서 자신만의 문제 해결 노하우가 쌓인다.
...(중략)...
유연한 구조와 코드 품질
...(중략)...
이러한 과정을 거치다보면 테스트 코드를 만드는 역량과 리팩터링 능력을 키울 수 있다.
유지보수를 하면, 불안한 감정이 발생한다. '불확실성' 에 의한 불안이다. 원래는 외부적인 요인(남의 코드) 였던 코드가 나에게 오면서 내부적인 요인(나의 코드) 로 바뀌는 순간이기 때문에 불안이 발생한다.
그래서 보수적인 관점으로 코드를 바라본다. 누군가가 유지보수 작업을 다 했다고 해도, 내가 막상 최종 책임자라면, 불안하다. 그러면 어찌 이 불안감을 줄일 수 있을까? "테스트" 이다. 나의 경우는 그랬다.
테스트 코드, 즉 유닛 테스트를 작성하면서 어느정도 안심할 수 있었다. 유닛테스트도 제일 중요하게 봤던 부분은 Input 단과 Output 단 이다. Input의 값이 만약 Int 라면 그리고 나이라면, 1 ~ 200 이하로 규정한다. 만약 200 이상을 간다면, 에러를 뱉도록 구현되어있는지 케이스를 작성한다. 이런식으로 들어오는 값 나가는 값을 가장 먼저 통제한다. 이후에는 내부 로직을 테스트해야한다. 이건 케바케가 심하다.
유지보수에서는 이렇게 테스트 코드에 필요성을 내적요인으로 발생된다. 그래서 유지보수를 해보는 경험은 중요하다고 생각이 된다.
코드 품질이 비즈니스에 미치는 영향
유지보수 비용을 낮추려면
p64
품질이 개발 시간에 어떤 영향을 주는지 소개한
<The Bunsiness Impact of Code Quaility>논문이 있다. 이 논문에 따르면 코드 품질이 좋을 때보다 코드 품질이 나쁠 때 평군적으로 개발 시간이 1.2배 더 걸린다고 한다. 또한 최대 개발시간은 코드 품질에 따라 9배 가까이 차이 난다. 코드 품질은 결함과도 연결된다. 품질이 좋은 코드에 비해 품질이 나쁜 코드는 결함이 15배 많다. 결함이 많으면 재작업도 많아지고 개발 비용이 증가한다.
위 논문에서는 코드품질이 결함 발생 수 / 문제 해결까지 걸리는 시간 / 문제 해결 가능성 이 세 가지에 어떤 영향을 주는지 정리한 논문이다. 내용을 보면, JIRA 의 문제해결된 시간을 통해서 개발 시간을 측정하기도 한다. 또 주로 분석된 언어는 C++ > Swift > C > Go >Python 순으로 분석을 했다고 한다.
이런 내용이 중요한 것이 아니다. 그래서 해야할 일은 좋은 코드를 작성하는 것이다. 그러면 제일먼저 해야하는 것이 좋은 코드가 무엇인지를 알아야 하는데 그것은 4 장부터 설명이 되는 것 같다.
3 단계로 구성된 코드
p99
길지 않은 코드와 메서드 추출
메서드나 함수를 길지 않게 만들려면 모든 구현을 한 메서드에 넣으면 안 된다. 대신 구현의 일부를 별도 메서드나 객체로 분리해야 한다.
...(중략)...
길지 않은 코드는 결국 추상화 수준을 맞추는 것과 연결된다.
최총적인 코드 모습
void svae(SaveRequest req) {
// 1. 유효성 검사
validate(req);
// 2. 메서드의 주된 로직
Member member = create(req);
// 3. 리턴 값 검증
// Return 값이 있다면, return 전 값의 범위를 한정하는 유효성검사콛, 추가
// 없다면, 최종 동작 로직 호출
repository.save(member);
}이렇게 3 개의 구조로 작성한 이유는 내가 QA 관련된 책을 본 이후로, 이렇게 작성해봤다. 책 중에서 개발자를 위한 시프트 레프트 테스트 책을 읽으면서, QA의 마음으로 코드를 구성한다. 그리고 테스트가 용이하게 구성하게 되었다.
1 번은 Input 값의 범위를 결정한다. 경계를 결정하는 것이다. 2 번을 거쳐서 함수에 들어가는 것이다. 어떤 연산이든 뭐든 이뤄지겠지. 그리고 3 번에서 결과값이 나오는데, 마지막 값의 범위를 통제한다. 내가 2 번에서 아무리 이상한 값이 나오더라도 어차피 3 번에서 막고 있다. 사용자에게 불쾌한 경험이 갈 가능성을 이미 범위를 정해두었기 때문에, 상대적으로 안심된다.
내용이 길어져서 다음 글에서 마저 작성...
참고자료
