핵심 역량 목표
문제해결: basic, 백준하, 백준 중 (성공)
설계: 팀프로젝트 설계시 확장성을 고려하면 어떤 구조가 필요한지 생각하고 적용해보기 (실패)
구현: 알고리즘, 수요 코딩회에 설계 이후 구현으로 들어가기 / 어려웠던 것 기록 (완료)
품질: 커피챗을 통해 테스트를 어떻게 하는지, 어떤 테스트가 좋은건지 (월요일 4시 ~ 4시반) 피드백 받기 (실패)
협업: 모든 팀원들이 성장할 수 있도록 조율해보기 (성공)
태도: 수요일까지 알고리즘만 신경쓰기, 수요코딩회는 목요일에만 신경쓰기 (성공)
AI활용: 면접이나 실무에서 어떤 능력이 필요하고, 어떤 팁이 있는지 조사해보기 (성공)
Greedy/DP
DP: 결과를 저장해 중복계산비용을 줄이는 방법
Greedy: 하위 문제의 최선택이 상위 문제에 활용되는 방법
두 알고리즘을 정확히 구분하기 어렵다. 교수님께서도 경험이라 말씀하신걸 보면, 내 수준에서 명확히 구별할 실력은 안될 것 같다.
DP 풀이 방법
- 저장할 배열을 정의한다.
- 배열을 기반으로 점화식을 도출한다.
- 점화식을 이용해 배열을 채운다.
교수님께서 알려주신 방법이고, 실로 유용했다. 문제에서 점화식을 드러내는 재귀구조를 발견하는게 중요하다. brute-force 재귀구조를 발견했다고 점화식을 유도할 수 있는건 아니였다.
알고리즘 풀이 소감
DP는 재귀구조에서 점화식을 도출하는게 핵심이다. 설계는 재귀로 작성하면 편하고, 구현시에는 최적화를 위해 반복문으로 변경할 필요가 있었다.
그리디는 특수한 상황에 사용할 수 있다. 하위 문제의 최선이 상위 문제 최선을 구하는데 사용될 수 있어야한다. 내 솔루션이 최선이라 확인하는것이 어려웠다.
팀 프로젝트
새로운 시도
지난주 KPT와 커피챗을 참고해 새로운 시도
- 프로세스 적용
- 기능별 데모 만들기
프로세스 적용
- 요구사항 분석
- 기획
- 아키텍처 설계
- 로직 작성
- 코드 구현
기능별 데모 만들기
Hook 별로 데모 만들기
- useState 데모
- useEffect 데모
- useMemo 데모
결과물
쇼핑몰 데모
-
메인 페이지
-
상품 바구니 (useState)
-
일정 금액 이상 시 배송비 무료 (useEffect)
후기
프로세스 적용
- 절차적으로 진행 가능
- 애매한 느낌
- 상황에 맞게 개량 필요
기능별 데모
- 데모를 분석하고 모호함이 줄었다.
- 시간 대비 빠르게 이해할 수 있다.
쇼핑몰 데모
useState
- 컴포넌트가 기억할 값을 저장할 때 사용 (클릭 횟수, 입력창에 적은 글자, 상태 여부 등등)
- 값 변화에 따라 화면도 같이 변화할 때 사용
- 예) 장바구니에 담은 물건, 검색창에 적은 글자, 카테고리 정보
useEffect
- 랜더링 이후 DOM을 수정하는 기능
- React 외부와 동기화할 때 사용 (서버 요청, DB 요청, 타이머 등)
- 정확한 이유는 이해하지 못했고, 용도가 정해져있다 정도만 이해함
- 예) 할인 상품 타이머, 무료 배송비 등등
커피챗
프로젝트, Redis
코치님은 경험이 쌓이면서 이해하게 되었다.
돌아보니 hashmap 구조가 캐시처럼 쓰인다는걸 느낌.
알고리즘 문제를 풀기 위한 과정과 비슷하다.
잘 안되는건 경험이 부족한 상태에서 설계하기 때문.
면접질문
정답을 말하라는 의도는 아니다.
정답은 인터넷이나 책에 있는데, 굳이 사람에게 물어볼 이유는 없다.
면접관이 본인 기준으로 신입때 주변에서 이정도는 알던데라는 것들을 물어보고, 정규분포 상 어디쯤에 속하는지 판단해보는것
정답을 몰라도, 역질문하여 정보를 얻고, 논리를 전개해 어떨것 같다라고 말하게 된다면 그걸로 점수를 딸 수도 있다.
시니어가 AI를 사용하면 신입보다 나을텐데, 신입을 채용하는 이유는?
시니어가 은퇴하고 나면, 대체할 사람이 없다.
회사가 갖고 있는 소스 코드를 AI가 관리할 순 없다. 결국 은퇴한 사람을 다른 사람이 대체해야한다.
자리는 줄지만, 대기업은 대체할 신입을 뽑아 키워야한다.
AI가 나오면서 프로그래머의 정의도 변한다
컴퓨터 언어는 명확하고, 기계가 다르게 해석할 여지가 없다.
자연어는 모호하여 해석이 다를 수 있다.
LLM은 확률 기반이며 비결정적이다.
AI를 이용해 프롬프트(자연어, 모호함)을 LLM(확률)을 이용해 결과(매번 다음)을 만들어야한다.
우리에게 필요한 능력은 프롬프트를 이용해, 거의 결정적이게끔 만드는것.
프롬프트 작성에 설계, 컴퓨터 구조, 알고리즘 등등이 필요하다.
직접 구현하지 않을 뿐, 프롬프트 속에서 코딩하게 된다.
KPT
Keep
- 기능별 데모 만들기
- 주제보단 기능 우선
- 발표 준비 시간 따로 정해두기
Problem
- 분업을 안해서 재미가 조금 덜었다
Try
- UI 스타일 변경 (claude 같은 외부 AI 툴, 스킬 이용)
- 과정을 문서로 남기기
- 알고리즘 아이디어를 모른다면, 정답보고 배우기
