토스 개발 블로그

https://toss.tech/ 에 있는 글들을 보고 정리한 내용입니다.

목차

• 모닥불 시리즈

모닥불 시리즈

• 모닥불 시리즈 1편 - 가독성 좋은 코드
• 모닥불 시리즈 2편 - 함수형 프로그래밍
• 모닥불 시리즈 3편 - 테스트 자동화

모닥불 시리즈 1편 - 가독성 좋은 코드

가독성 좋은 코드를 작성하는 방법과 이유 대해 설명합니다.

1. 코드 퀄리티를 지켜야하는 이유

• 코드는 컴퓨터만을 위한 것이 아닌 동료 개발자를 위한 것이다. 그렇기에 퀄리티를 지켜야한다.

• 반대로 생각해서, 안 좋은 퀄리티의 코드 작성시, 코드를 이해하는데 시간이 오래걸리고, 버그가 발생할 확률이 높아진다.

• 예시, window 함수의 경우 사이드 이펙트 발생 가능성이 높은데 이를 방지해야 코드 오해를 줄일 수 있다.

• reusability를 고려하여, 코드를 작성했을 경우 같은 문제를 해결하는 다른 부분에서도 사용할 수 있어서 효율적이다. (습관화하면 평소에도 코드 퀄리티를 지킬 수 있다.)

2. 코드 퀄리티에서 가독성이라는 의미

• 눈이 편하다. (일관성, 들여쓰기, 네이밍, 주석),

  눈이 편한 코드 퀄리티는 최대한 린터나 포매터를 사용하여 일관성을 유지하는 것이 중요하다.

• 머리가 편하다. (아키텍쳐, 추상화, 모듈화)

  머리가 편한 코드 퀄리티는 코드를 작성할 때, 코드를 작성하는 사람이 이해하기 쉽게 작성하는 것이 중요하다.

3. 주니어 입장에서 훈련하는 법:

• 코드에 맥락을 덜어내고, 심플하게 작성하기
• 리팩토링은 수시로 해보는 것도 도움이 된다.(tidy code)
• 수시로 리팩토링 하는 것은 빠르게 코드를 작성하더라도 퀄리티를 유지할 수 있게 도와준다.

4. 마지막 팁

• 코드에 규칙을 정해두고, 이를 지키도록 노력해보자.
• 코드퀄리티가 좋은 오픈소스 프로젝트를 찾아보고, 이를 분석해보는 것도 도움이 된다.
• 내가 해야하는 작업의 베스트 프랙티스를 찾아보고, 이를 참고해보자. needs-based learning이 가장 큰 도움이 된다.

5. 내 생각을 정리.

• 코드 퀄리티를 장기적으로 디버깅과 유지보수에 도움이 된다. 즉, 비즈니스에 도움이 된다.
• 습관이 반이다. 평소에 코드 퀄리티를 지키는 습관을 들여야 한다.
• 리팩토링, 코드 리뷰, 코드 스타일 가이드를 통해 코드 퀄리티를 지키는 것이 중요하다.
• 개발은 혼자 하는 것이 아니다. 동료 개발자와 협업을 위해 코드 퀄리티를 지키는 것이 중요하다.

모닥불 시리즈 2편 - 함수형 프로그래밍?

FE개발에서 함수형 프로그래밍이 왜 중요한지, 어떻게 적용할 수 있는지 설명합니다.

1. OOP vs FP

• OOP: 객체지향 프로그래밍, 객체를 중심으로 프로그래밍하는 방식

  • 장점: 객체를 중심으로 프로그래밍하기 때문에, 객체의 상태를 변경하는 것이 쉽다.

  • 단점: 객체의 상태를 변경하는 것이 쉽다는 것은, 사이드 이펙트를 발생시킬 수 있다.

• FP: 함수형 프로그래밍, 함수를 중심으로 프로그래밍하는 방식

  • 장점: 사이드 이펙트를 줄일 수 있다.

  • 단점: 객체지향 프로그래밍에 비해, 상태를 변경하는 것이 어렵다.

거시적 관점은 OOP, 미시적 관점은 FP를 사용하는 것이 중요하는 의견

어떻게 보면 취향차이라고 볼 수 있다. 다만 페러다임을 잘 이해하고 적용하는 것이 중요하다.

프로그래밍은 현실의 어떠한 상황을 코드로 옮기는 행위이다. 이 행위가 결과적으로 어떤 이펙트를 발생시킬지 고민해보는 것이 중요하다. 그 과정에서 FP와 OOP를 적절히 사용하는 것이 중요하다.

2. 좋은 프로그래밍이란?

• SRP(Single Responsibility Principle): 한 가지 일만 하는 함수를 작성하는 것이 중요하다.

• DRY(Don't Repeat Yourself): 중복을 제거하는 것이 중요하다.

• 모듈화: 코드를 작성할 때, 모듈화를 고려하여 작성하는 것이 중요하다.

위와 같은 원칙을 지키면서, FP와 OOP를 적절히 사용하는 것이 중요하다.

3. 함수형 프로그래밍을 적용하는 방법

프론트엔드 관점에서 FP기반으로 생각하는 것은 좋은 아키텍쳐를 만들 수 있게 도와준다.

다만, 컴포넌트와 hook은 어떻게 보면 객체지향에서 말하는 객체와 메소드와 비슷하다. 이처럼 두 가지 관점을 잘 이해하고 적용하는 것이 중요하다.

4. 생각 정리

• FP와 OOP는 취향차이라고 볼 수 있다. 다만, 두 가지 패러다임을 잘 이해하고 적용하는 것이 중요하다.
• 좋은 프로그래밍은 SRP, DRY, 모듈화등 기본 원칙을 잘 지키는 것이 중요하다.
• 구조는 OOP, 세부 구현은 FP로 생각하는 것도 좋은 방법이 될 것 같다.

모닥불 시리즈 3편 - 테스트 자동화

테스트 자동화의 중요성과 테스트 코드 작성 방법에 대해 설명합니다.

1. 테스트 자동화의 중요성

• 테스트 자동화는 코드의 퀄리티를 높이는데 도움이 된다. 그리고 결국 생산성에도 도움이 된다.

• 코드가 자주 변경되는데 테스트 코드가 필요한가? 라는 의문이 들 수 있다. 하지만, 테스트 코드가 없다면, 코드를 변경할 때마다 테스트를 수동으로 해야한다. 이는 시간이 많이 소요되는 작업이다.

2. 테스트 코드의 장점

• 피드백이 빠르다 > 생산성을 높일 수 있다. (TDD도 활용해볼 수 있다.)
• A/B 테스트의 경우, 테스트 코드를 작성하면, 테스트 코드를 작성하지 않았을 때보다 더 빠르게 테스트를 진행할 수 있다.
• 외부 의존성을 격리할 수 있다. > 나는 비즈니스 로직에만 집중할 수 있다.
• 안정성: 테스트 코드를 작성하면, 코드의 안정성을 높일 수 있다. > 배포할 때도 안정적으로 배포할 수 있다. (refactoring, 특정 라이브러리 버전 업데이트)
• 잘 작성된 테스트 코드는 문서로 사용할 수 있다. > 다른 개발자가 코드를 이해하는데 도움이 된다. > 테스트 코드는 강제적으로 문서를 작성하게 만들기도 한다.

3. 생산성을 분리해서 생각해보기 (초단기적 생산성 vs 장기적 생산성)

• 테스트 코드를 작성하지 않는 이유: 초단기적인 생산성만 보게 되고, 그냥 내가 손으로 테스트를 해도 되지 않을까? 라는 생각이 들 수 있다.
• QA를 진행할때도, 테스트 코드를 작성하면, 기능에 대한 확신을 갖고 진행할 수 있다.
• 위의 내용들을 포함해서, 이터레이터를 빠르게 돌리고 절약된 시간을 코드 퀄리티 혹은 비즈니스 로직에 투자하는 것이 중요하다. > 선순환을 통해 장기적 생산성을 높일 수 있다.

4. 옵셔널한 테스트 코드

• 프로그래머의 역량 및 스킬에 아키텍쳐와 성능최적화 등등은 항상 포함이 되지만 테스트 코드는 옵셔널한 것으로 생각하는 경우가 있다.

• 하지만, 테스트 코드는 코드의 안정성을 높이는데 도움이 된다. 그리고 테스트 코드를 작성하면, 코드를 이해하는데 도움이 된다. > 테스트 코드를 습관화 하자

5. 어떤 것을 테스트 해야할까?

• 복잡한 스펙, 퍼널 등등을 테스트 하는 것이 중요하다. > 테스트 또한 복잡한데, 이를 빼먹지 않도록 도와준다.
• 통합테스트를 많이하려고 하고 있다. > 사용자 관점에서의 테스트를 중요하게 생각하고 있다.
• 안쓰는 테스트 코드: 너무 간단하거나, 코드의 생명이 매우 짧은 경우는 테스트 코드를 작성하지 않는다.

6. 생각 정리

• 테스트 코드는 코드의 퀄리티를 높이는데 도움이 된다. 그리고 결국 생산성에도 도움이 된다.
• 습관이 반이다. 테스트 코드를 작성하는 습관을 들여야 한다.
• 무엇을 테스트 해야할지, 어떤 테스트 코드를 작성해야할지 고민해보자.

모닥불 시리즈 4편 - 오픈소스

오픈소스에 기여하는 방법과 이를 통해 토스에 합격한 이야기 등을 공유합니다.

1. 오픈소스에 기여하는 이유

• FE 생태계의 선한 영향력을 끼치기 위해
• 개발자로서 성장하기 위해, 더 좋은 코드 설계 및 품질을 위해
• contributor 라는 타이틀을 얻기 위해 (개인 동기부여)
• 토스 개발자에게 code review를 받기 위해

2. 오픈소스를 만들고 관리하는 방법

• 내가 만드는 오픈소스가 무엇을 해결하는지, 어떤 문제를 해결하는지 명확하게 정의해야 한다.
• Contributor들과 소통이 중요하다. > 이슈, PR 등을 통해 소통을 하자. > 커뮤니티의 중요성

3. 요약 정리

• 오픈소스에 기여하는 것은 개발자로서 성장하는데 도움이 된다.
• 오픈소스를 만들고 관리하는 것은 커뮤니티와 소통하는 것이 중요하다.
• 오픈소스에 기여하는 것은 개인의 동기부여에도 도움이 된다.

모닥불 시리즈 5편 - 개발자는 개발만 잘하면 될까?

개발자는 개발만 잘하면 되는가? 잘하는 개발자란 무엇인가에 대해 고민해봅니다.

1. 좋은 코드 vs 좋은 서비스

• 좋은 코드가 중요하긴 하지만, 회사의 비즈니스에 도움이 되는 서비스를 만드는 것이 중요하다.
• 우리의 목표는 사용자에게 좋은 서비스를 제공하는 것이다.

2. 요구사항을 모두 개발하는 개발자 vs 요구 사항을 잘 정의하는 개발자

• 요구사항을 모두 개발하는 것도 중요하지만, 요구사항의 목적이 무엇인지 이해하고, 이를 잘 정의하는 것이 중요하다.
• 결국에는 사용자에게 좋은 서비스를 제공하는 것이 중요하다. 그러기 위해서는 요구사항의 근본을 파악하는 것이 중요하다.

3. 업무에 적용할 팁

• 코드를 안 짜고 문제를 해결하는 방법을 고민해보자.
• 위의 내용을 위해서는, 히스토리를 잘 기록하고 단순하게 개발하는 것이 아닌 이 개발이 무엇 때문에 이루어지는지 고민해보자.
• 때로는 빠르게 배포하고 피드백을 받는 것이 중요하다.

4. 생각 정리

• 좋은 개발자는 한 문장으로 요약하면, 좋은 서비스를 만드는 개발자이다.
• 이때 필요한 능력은 코딩 능력 뿐만 아니라 기획적인 능력 또한 중요하다.
• 그냥 좋은 서비스를 만드는 것에 집중하자. 코딩과 소통, 기획도 목적은 사용자에게 좋은 서비스를 제공하는 것이다.

모닥불 시리즈 6편 - nextjs를 꼭 배워야 하나요?

nextjs를 꼭 배워야 하는가? 채용관점에서 특정 라이브러리나 프레임워크 사용 경험을 어떻게 생각하는지에 대해 고민해봅니다.

1. 프레임워크란 무엇인가? (프레임워크 vs 라이브러리)

• 경계를 명확해서 나누는 것이 쉽지 않아지는 것 같다.
• 기본적으로는, 프레임워크는 개발자가 따라야할 규칙을 정해주는 것이고, 라이브러리는 개발자가 필요할 때 사용하는 것이다.

2. nextjs를 꼭 배워야 하는가?

• 서비스 마다 다르다. > SSR 기능이 필요한 서비스라면 nextjs를 배워보는 것도 좋다. > 다만, SSR이 필요하지 않은 서비스라면, nextjs를 적용할 필요가 없을 수 있다.
• 즉, 프레임워크의 이점을 잘 이해하고 서비스에 적용할 수 있는지 고민해보는 것이 중요하다.
• 프레임워크를 택시에 비유하자면, 거리에 따라 걷는게 빠를 수도 있고, 택시를 타는게 빠를 수도 있다. > 서비스에 따라 다르다. > nextjs를 배워보는 것도 좋지만, 서비스에 적용할 수 있는지 고민해보자.

3. 다양한 프레임워크 경험의 장점

• 다양한 프레임워크 경험을 가지는 것은, 다양한 프레임워크의 장단점을 이해하는데 도움이 된다.
• 이는 결국 서비스에 적합한 프레임워크를 선택하는데 도움이 된다.

4. 생각 정리

• 역시 항상 이유와 근거가 중요하다. > 그냥 남들이 쓰니까 쓰는 것은 좋지 않다. > 현재 내 상황을 잘 정의하고 이에 맞는 프레임워크를 선택하는 것이 중요하다.

모닥불 시리즈 7편 - 리드 개발자와 리더십

리드 개발자와 리더쉽에 대해 고민해봅니다. 이를 통해 성장한 경험을 공유합니다.

1. 리드 개발자가 말하는 리더십과 성장

• 내가 리딩하고 있는 팀이 모두 하나의 목표를 향해 나아갈 수 있도록 하는 것.
• 위의 내용을 위해 하나의 목표를 잘 정의하고, 이를 통해 팀원들이 성장할 수 있도록 도와주는 것이 중요하다.
• 팀원 한분한분에게 관심을 갖고, 이를 통해 성장할 수 있도록 도와주는 것이 중요하다.
• 결국 위의 내용을 바탕으로 팀 전체의 퍼포먼스를 높일 수 있도록 하는 것이 리드 개발자의 역할이다.

2. FE 리드로 성장 당한 경험

• 조직이 성장을 이끈다. 빠른 회사 성장으로 인해 조직에 항상 트러블이 있었다. 이를 위기 상황이라고 생각하지 않고, 기회로 생각하고, 이를 통해 성장할 수 있었다.
• 위의 내용은 나 혼자 해결하는 것이 아니라, 팀원들 혹은 다른 리드들과 함꼐 상의해보고 최선의 방법을 찾아보는 것이 중요하다.

3. 리더십은 학습 가능한가?

• 학습은 가능하다고 생각하지만, 난이도는 사람마다 너무 다를 것 같다.
• 피드백 받을 수 있는 환경, 리더십을 발휘할 수 있는 환경이 중요하다.
• 리더는 외향적이다. 유머러스하다. 등의 편견은 없어야 한다. 리더십은 다양한 방식으로 발휘할 수 있다. > 나만의 리더십을 찾아보자.

4. 생각 정리

• 환경의 중요성: 리더십을 발휘할 수 있는 환경이 중요하다.
• 다양한 형태의 리더십: 좋은 리더십이라는 것은 하나의 정답이 없다. 나만의 리더십을 찾아보자.

모닥불 시리즈 8편 - 면접관이 뽑고싶은 개발자

면접관이 뽑고싶은 개발자에 대해 고민해봅니다. 대표적인 예시인 Next.js를 예시로 들어 설명합니다.

1. 면접관이 뽑고싶은 개발자(서류)

• ~써봤다 정도로는 부족하다. > 왜 써봤는지, 어떤 문제를 해결하기 위해 썼는지 등을 설명할 수 있어야 한다.
• 예를 들어, React query를 써봤다고 하면, 캐싱 이라던가, 서버 상태 관리 등을 설명할 수 있어야 한다.

2. 있어빌리티에 대한 고민

• 있어빌리티: 있어보이는 느낌 (깃헙 잔디) > 이는 개발자의 능력을 나타내는 것이 아니다. > 크게 중요하다고 생각하지 않는다.
• github 링크를 많이보려고 한다. > PR과 commit 메세지를 많이 보려고 한다. > PR의 경우에는 코드 리뷰를 받은 내용이 있는지, commit 메세지의 경우에는 어떤 이슈를 해결하기 위해 커밋했는지 등을 확인한다. > 추가로 소통하는 스타일도 엿볼 수 있다.

3. 면접관이 뽑고싶은 개발자(면접)

• 과제에 대한 설명 관점 > 왜 이렇게 했는지, 어떤 문제를 해결하기 위해 이렇게 했는지 등을 설명할 수 있어야 한다. > 생각이 다를 수 있지만, 이를 설명할 수 있어야 한다.

• 어떤 마음으로 설계하고 개발했는지, 어떤 문제를 해결하기 위해 이렇게 했는지 등을 설명할 수 있어야 한다.

• 사일로에서 A to Z 까지 다 할 수 있는 개발자가 필요하다. > 특정 부분만 잘하는 개발자는 필요하지 않다.

• 어떤 작업의 근거가 기술적인 부분에만 있는 것이 아니라, 비즈니스적인 부분에도 근거가 있어야 한다.

4. 자주 오해하는 부분

• 블로그: 단순하게 글의 숫자가 많다고 좋은 개발자가 아니다. > 글의 내용이 중요하다. > 글의 내용이 어떤 문제를 해결하기 위한 것인지, 어떤 근거가 있는지 등을 확인한다.

• 재지원: 이전에 떨어졌다고 해서, 다시 지원하는 것이 나쁜 것은 아니다. > 오히려 성장한 부분을 보여줄 수 있는 기회이다.

5. 생각 정리

• 채용에 대해 이렇게 솔직하게 말할 수 있는 환경이 좋아보인다.
• 좋은 개발 채용 문화를 통해 좋은 개발자를 뽑으려고 하는 모습이 보인다.
• 뽑고 싶은 개발자는 한 줄로 요약하면, 문제를 해결하기 위해 노력하는 개발자이다.