개발자에게 필요한 능력, 기본기는 무엇일까?

이 글은 내가 개발자로서 기본기나 능력이 탄탄하다고 생각해서 쓰는 게 아니다. 나 자신도 항상 많이 부족하다고 생각되서 더 잘 하는 개발자가 되고 싶은데, 매번 찾아보긴 귀찮아서 써 두고 필요할 때마다 보려고 적는다.

주기적으로 찾아보고 업데이트할 예정이다.

 

https://goldenrabbit.co.kr/2022/01/05/%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%A1%9C-%EA%B1%B0%EB%93%AD%EB%82%98%EA%B8%B0%E2%8B%AF-%EB%84%A4-%EA%B0%80%EC%A7%80-%EA%B8%B0%EB%B3%B8-%EC%86%8C%EC%96%91%EC%9D%84-%EA%B8%B0%EC%96%B5%ED%95%98%EC%84%B8/

개발자로 거듭나기⋯ 네 가지 기본 소양을 기억하세요 - 골든래빗

크리티컬 싱킹
- 왜 이 일을 해야 하는가?
- 이걸 하다 말면 어떻게 되는가?
- 어떤 방식으로 일하는 게 최선인가?

문제의 상하좌우까지 고민하는 사고방식을 들이면 모든 일을 더 깊게 들여다볼 수 있다.

삽을 가져가서 10번 땅을 파고 독을 묻고 돌아오라고 시켰을 때 그대로 하면 숙련도는 오른다. 하지만 지식, 경험은 잘 쌓이지 않는다. '왜 10번만 파야 하지?', '왜 삽으로 파야 하지?', '곡괭이는 안 되나?', '꼭 해야 되나?', '독을 왜 묻지' 같은 질문을 하고 더 좋은 방법을 고민하면 어떻게 될까?
관리자 입장에선 시키는 대로 하는 전자가 편하다. 후자는 뭐 하나 시키면 맨날 물어봐서 귀찮다. 그러나 1년 뒤에도 전자한테는 여전히 '동쪽으로 10보 가서 땅을 10번 파고 독을 묻어라' 라고 설명을 길게 해야 한다. 그러나 후자한테는 '독을 잘 묻어봐' 라고 하면 끝이다. 땅 파는 대신 김치 냉장고를 가져올지도 모른다. 크리티컬 싱킹 습관이 들어 있다면 그 사람이 감당하는 업무 스케일이 계속 커지게 된다

소프트웨어를 출시하면서 왜, 어떻게, 뭘, 누가, 언제까지 출시해야 하는지를 종합적으로 고려해야 한다. '어떻게'에 매몰되면 좁은 영역에서 해결책을 얻을 순 있지만 종합적 관점에서 최고 or 최선의 해결책은 얻지 못한다. 크리티컬 싱킹은 종합적 관점에서 해법을 구하는 습관이다. 같은 시간을 투자해도 상대적으로 더 큰 성장을 이끌어낸다. 주인의식의 다른 말이 아니냐고 할 수 있다. 회사에 대해 주인의식을 가질 필요는 없지만 나에 대한 주인의식을 가져라. 이직을 하든 창업하든 과거에 내가 한 일이 오늘의 나를 만든다. 개발자를 채용하며 어떤 프로젝트에 참여했는지가 아닌 어떤 기여를 했는지 확인하는 시대다. '그냥 시킨 거만 했어요' 라고 대답하지 않으려면 나에 대한 주인의식(크리티컬 싱킹)이 필요하다. 주인의식은 부차적인 것이다

 

https://okky.kr/articles/674111

OKKY - 개발자라면 반드시 알아야하는 기본기

- API 문서를 읽는 능력, 습관 : 기본 문서를 통해 개요를 파악하고 API 문서를 통해 클래스, 메서드의 구체적 의미, 용도를 알아야 함
- 에러 트레이스를 읽는 능력, 습관 : 메시지를 읽어보고 트레이스를 분석하고, 필요하면 예외 클래스를 API 문서에서 찾아 정확한 의미를 이해해야 함

 

https://www.quora.com/What-are-some-of-the-most-basic-things-every-programmer-should-know

What are some of the most basic things every programmer should know?

- 테스트하지 않으면 작동하지 않는다. 충분히 테스트되지 않은 기능은 절대 프로덕션에 푸시하지 마라
- 내가 작성했다고 소유권이 내게 있진 않다. 다른 팀원이 코드를 바꿔야 한다고 해서 기분 나빠하지 마라. 코드에 감정적으로 집착하지 마라
- 처음부터 다시 만들지 마라. 라이브러리가 도움을 줄 수 있다
- 가장 빠른 코드는 한 번도 실행되지 않는 코드다. early out을 찾아라
- 직접 작성하지 않았다고 쓰레기가 되는 건 아니다
- 이해하기 어려운 코드는 유지보수도 어렵다. 유지보수가 어려운 코드는 거의 쓸모없다
- 코드 레이아웃이 깔끔할수록 읽기 쉽다. 읽기 쉬울수록 이해하고 유지보수하기도 쉽다
- 코드는 스스로 문서화되지 않는다. 주석을 추가해서 다른 사람과 수 년 후의 나를 도와라
- 나쁜 코드는 다시 돌아와서 너를 괴롭힐 수 있다
- 코드 리뷰는 비판이 아니다. 자존심을 갖고 참여하지 말고, 긍정적으로 검토 및 개선하는 방법을 배워라
- 중요한 것은 코드 양이 아닌 품질이다
- 잘못 작성된 코드의 진정한 비용은 유지보수에 있다
- 요청하지 않은 기능은 추가하지 마라
- 기능에 대한 견적을 요청받으면 항상 20% 여유를 두고 과대 추정하라
- 구현 시작 전, 다른 프로그래머와 솔루션을 논의하는 게 좋다
- 문제 뿐 아니라 해결책도 같이 갖고 회의에 참여하라

 

https://f-lab.kr/blog/problem-defining-ability

개발자는 문제 해결 능력에 앞서 문제 정의 능력이 중요하다.

문제를 잘 해결하려면 내가 풀어야 할 문제가 뭔지부터 잘 정의해야 한다. 결제 모듈을 구현해달란 요구사항을 받으면 이것 자체를 문제로 인지하는 경우가 많다. 하지만 부가적으로 발생할 수 있는 추가 요구사항이 뭔지를 개발자 관점에서 스스로 도출해야 한다. 외부 결제 모듈 API를 호출하려면 네트워크 통신이 필요하다. 어떻게 해야 이 IO 작업을 성능에 지장을 주지 않을 수 있게 처리할지, 결제 모듈에 장애가 발생하면 어떻게 처리해야 할지 등이 될 수 있다
위 예시에선 결제를 구현해 달라는 1차원적 문제에서 한 단계 더 깊이 들어가 결제 모듈 통신이 성능에 영향을 주는 영향을 덜자는 추가 문제를 정의했다. 즉 문제 정의 능력을 활용한 것이다...(중략)

트래픽이 많은 회사에 다니면 어쩔 수 없이 문제에 당면해서 자연스럽게 인지하는 경우도 있다. 하지만 굳이 경험하지 않아도 창의력을 활용해 정의할 수 있다. 그리고 창의력을 발휘하려면 기본기가 탄탄해야 한다. 여러 대기업들이 CS 지식이 탄탄한 개발자를 선호하는 이유도 이 때문이다. 처음 언급한 IO 문제는 쓰레드, IO를 공부했다면 떠올릴 수 있는 문제다. 결제수단 별 다른 로직들의 공통화는 객체지향 이론을 공부했다면 떠올릴 수 있다...(중략)

 

https://f-lab.kr/blog/5ways-tobe-good-developer

좋은 개발자가 되고 싶다면 다음 5가지 소양을 갖추세요.

1. 항상 의문을 제기하라 : 모든 일에 의문을 제기하고 그 의문을 해결하기 위해 지식을 구하고 공부하고 노력하라. 훌륭한 엔지니어들은 의문을 제기하는 데 두려워하지 않는다. 소프트웨어는 방대한 분야고 기술은 습득하는 속도보다 빠르게 진화한다. 모르는 건 잘못된 게 아니며 계속해서 알려고 노력하는 자세가 중요하다. 항상 의문을 제기하고 모르는 부분은 확실히 이해한다. 세상 어디에도 바보같은 질문은 없다는 걸 명심하라

2. 긍정적 생각 : 기술적으로 프로젝트 방향을 잡아주는 건 개발자의 중요한 역할 중 하나다. 주의해야 할 건 지나치게 냉소적으로 변하는 것이다. 문제를 냉철하게 분석하고 시니컬해지는 건 엔지니어의 좋은 자세지만 결국 가치를 만들어내야 한다. 문제가 해결되지 않으면 결국 얻을 수 있는 건 없다. 기획자 또는 동료 엔지니어가 바보같거나 허황된 아이디어를 갖고 조언을 구할 때가 있을 것이다. 항상 상대방의 입장에서 이해하고 도움을 줘라. 무작정 비난하거나 요청을 거절하기보단 좋은 개발자, 좋은 사람이 되기 위해 노력해야 한다. 우린 팀으로 일하고 커뮤니케이션에서 많은 어려움을 겪게 된다. 그럼에도 긍정하고 결국 팀의 일원으로 문제를 해결할 방법을 찾아야 한다

3. 의사소통은 말로 하라 : 개발자는 코드로 말한다고 믿는 엔지니어들이 있다. 일리 있지만 좋은 개발자는 말로 의사소통한다고 생각한다. 정말 자기 코드가 소설처럼 깔끔하고 논리가 누구나 이해할 수 있다고 생각하는가? 물론 그런 경우도 많지만 대부분의 경우 말로 전하면 더 효과적이다. 맥락 없이 코드만 던지고 이해를 바라는 건 이기적이다. 최대한 자세하게 의사를 전달하고 가능하면 직접 커뮤니케이션하는 게 좋다

4. 중요한 건 아이디어 : 많은 주니어 개발자들은 코드를 먼저 치는 경우가 있다. 막연한 아이디어를 코드로 옮기다 보면 해결책이 구체화되는 경우가 많지만 보다 발전하고 싶다면 먼저 생각하고 코드의 우선순위를 미루는 게 좋다. 지금은 작은 관점에서 코드를 개발하게 되겠지만 결국 더 큰 관점에서 서비스를 설계하고, 팀 리딩도 하게 될 것이다. 작업 규모가 커지고 복잡해지면 먼저 개발하는 건 성급한 자세다. 설계가 미리 안 돼 있고 할당된 작업이 없다면 쉬는 게 나을 수 있다. 성급한 코드화는 작업에서 의존성을 만들어내고, 생각이 구현에 갇히는 주객전도의 상황이 될 수 있다. 필자는 개발 자체가 재밌어서 늘 기능 개발에 성급히 뛰어들어 구현했지만 종종 코드 전체를 다시 리팩토링하거나 설계를 바꾸는 등 실수가 있었다. 팀의 입장에선 전혀 좋지 않다. 먼저 충분히 팀과 커뮤니케이션해서 요구사항을 명확하게 한다. 그 후 설계하고 코드는 나중이라도 상관없다

 

https://sassun.tistory.com/35

[일상]프로그래머의 기본기란?

- 반복되는 과정은 추상화할 생각, 반복되는 로직은 함수화 및 클래스화할 생각, 반복되는 계산은 따로 저장해 두고 빠르게 꺼내기, 반복되는 개념들은 따로 머릿속에 통암기하기
- 이 코드가 하루 뒤, 1주일 뒤, 1달 뒤, 1년 뒤 쓰일 수 있는가? 이 코드가 남이 알아보기 쉬운가? 내일 이 코드를 남에게 설명할 수 있는가?
- 속도를 줄이는 생각을 습관화하라 (유지보수의 속도, 실제 코드의 속도)
- 모른다는 말을 함부로 하지 말기, 찾아보고 따라하면 구현할 수 있다는 마인드셋 갖기, 이해가 안되면 내일은 이해할 수 있다 생가하고 일단 눈에 익히기
- 이 모든 자동화, 리팩토링들이 자연스럽고 당연한 거라고 받아들이는 게 프로그래머의 기본기
- 항상 이슈를 보면 더 간단하고 간명한 해결책이 있을 거라고 생각하라. 그리고 그 과정은 반복되는 일, 계산을 줄이려는 사고에서부터 출발하라