이거 제대로된 개인 프로젝트 쪼금이라도 해보면 바로 알 수 있음
첫째로 존나 어렵고 복잡한 알고리즘 직접 짤 일 많이 없음
진짜 필요하면 갖다 쓰면 됨 아니 오히려 무조건 가져다 써야 함
혼자서 만든 네다씹 구현보다 오랫동안 수많은 사용자에게 검증된 라이브러리가 훨씬 믿을만 함
직접 짜는 것보다 남이 만든 게 어디 있는지 어떻게 쓰는지 내 문제엔 어떻게 적용할 수 있는지 아는 게 더 중요함
두번째는 더 심각한데 현실의 문제는 알고리즘 문제처럼 명확하지를 않음
불확실하고 불명확하고 계속 변하고 아주 개같음.
문제를 해결한 건지 해결을 위해선 어떤 품질을 높여야 하는지도 알기 힘들 수 있음
그런 현실의 문제를 프로그래밍할 수 있는 스펙으로 바꾸는 것도 플머가 하는 일인데
남이 다 떠먹여주는 알고리즘 문제로는 이런 걸 절대로 배울 수 없음.
세번째는 전체 규모의 설계를 배울 수 없다는 것도 있는데 귀찮으니 여기까지만
코테의 목적은 그냥 똥오줌도 못가리는 쌉뉴비 거르는 수준만 되어야 한다 생각함
Customization이 중요해서 라이브러리로 구현하기 어려운 경우들 빼면, 알고리즘 때문에 고민 하는 시간 보다는 프로젝트 전체적인 설계, 구조에 시간 더 많이 쓴 것 같음.. 아직 프로덕트 수준 프로젝트는 해보지 못해서 뭐라 하긴 어렵겠지만. 소프트웨어 아키텍쳐나 거기에 있는 개발론들만 봐도 설계에 대해서 얼마나 고심을 했는지 엿볼 수 있는 것 같음
그렇다고 알고리즘 설계를 통한 문제 해결능력이 필요한 것도 분명한 것 같음. 아무리 많은 사람들에 의해 검증되었다고 하더라도, 새로운 기술들은 계속 나오고, 그 안에서 충분히 검증되지 못한 알고리즘이 제대로 동작하지 않고, 제품을 만드는 이상 고쳐야 할 사람은 당장 급한 나 자신이 될 수 있으니까 ㅋㅋ..
물론 필요한 부분이고 앱에 따라 핵심 중에 핵심일 수도 잇지만 거기에만 올인 하기에는 너무 작은 부분이라 생각함.. 그리고 구현체 없으면 논문 보고 직접 구현할 수도 있는데 그런 코테도 하는지는 모루겟다
맞아 내가 말하고 싶었던게 딱 그거임, 논문 보고 구현해야 하는경우
근데 두 번째의 경우는 조금 다르게 보는게, 정제된 알고리즘 문제를 많이 접해보는 만큼, 현실의 문제를 알고리즘 문제처럼 명확하게 모델링 할 수 있는 능력도 늘어나지 않을까 싶긴해. 물리에서 연습 문제를 계속 풀어보고 익숙해짐으로써, 여러 현실적인 상황에 특정 모델을 적용해서 현실적인 문제들을 제한된 상황(주어진 조건내)에서 풀릴 수 있도록 하는 것 처럼.
일정 레벨까진 그럴 수 있는데 어느 정도 익숙해진 다음에는 알고리즘 문제는 너무 규모가 작고 보통 성능이라는 명확한 평가 지표가 있는 게 비현실적이기도 하고 늅존 벗어날 때는 나름 괜찮을지도 모름
알고리즘은 생물로 치면 약간 뇌 같은 느낌인데 뇌만으로는 생존이 불가능한 그런 느끼
뭐 뇌로 생각한다면, 뇌 만으론 생존은 불가능 하겠지만, 주어진 것들로 생존이 가능하게 만드는것도 뇌니까
어떤 앱들은 알고리즘 없이는 아예 못 만드는 게 있는데 그냥 뇌 없이 사는 해파리 같은 애들도 있음 ㅋㅋ
분산처리나 DB 쪽이 이런 능력이 좀 중요할거 같긴한데
그래도 게임이라면 패스 플래닝같은 PS 스킬을 사용 할 일도 있긴함. 게임 외에는 PS를 통해서 컨테이너들의 적절한 활용 능력을 배양 할 수 있단 정도일려나?
근데 게임도 결국 다른사람들이 구현 해둔 것들(엔진)위에서 대부분 하니까. 개인이 직접 다 구현하는 경우는 드물지..
솔직히 어지간한 문제에 대한 솔루션이 잘 알려져 있긴한데, 그것도 똑바로 못하는 애들이 많아서...
게임 플젝하면서 알고리즘 보다는 설계 능력이 더 중요하고 많이 필요한 것 같다고 느꼈음. 시시각각 변하는 기획사양에 어떻게 잘 대응하게끔 설계하는가... 같은거 말임 알고리즘은 그냥 일반적인 경우에는 STL 어떤게 빠르고 어떤게 느리고 이럴때는 저렇게 써야하고 하는거? 이외엔 막 어려운 거 요구하는 건 대체로 없는 것 같음
알고리즘 가장 어려운거 구현해본게 Z-order 최적화 + 복셀화 인데 이것도 걍 국한된 얘기고 (애초에 짠 시스템이 이러저러 사정으로 폐기된 것도 있고) 뭐 모르겠지만 그래도 키워드는 알아둘 필요는 있지 않을까 싶음 이러저러한 상황에서 어떻게 로직 짜지 싶을 때는 특정 알고리즘이 필요할 때도 있으니
나도 복셀화.. 복셀화 자체는 시웠는데, 복셀들 octree 만들어서 순회하게 하고 그건 아직도 못해봤네..
z-order 최적화는 뭐야? CPU단에서 draw할 오브젝트들 camera space 기준으로 depth 기준으로 정렬시키는건가? z-pre pass?
내가 알기론, N*N 크기의 정수 좌표 평면에서 (x, y) 좌표에 대한 값을 평범하게 A[y*N+x] 위치에 저장한다면, x가 비슷한 건 가까운 위치에 저장돼 있어서 괜찮지만 y는 조금만 바꿔도 위치가 N씩 휙휙 차이나서 성능 문제가 발생할 수 있음(캐시 미스, 탐색 범위 증가 등). 그래서 해당 좌표 근방을 탐색해야 할 경우 x에만 최적화된 y*N+x가 아닌 x y 모두 고려해서 비교적 가까운 위치에 배정하기 위해 쓰는 매핑 함수로 HIlbert curve나 Z order curve가 있고, 후자는 x와 y의 비트를 xyxyxy처럼 교차시키는 방법임
아 Morton order.. 컴터 비전 배울때 공부했었는데 까먹고있었네
그래서 복셀화랑 같이 나온거구나
사실 알고리즘을 상당히 잘하는, 구체적으론 지능이 높은 사람의 경우 글에서 말한 것들을 빠르게 익히는 경우가 꽤 있기에 신입은 그냥 코테로만 뽑아도 되지 않나 하는 얘기가 나오는 것 같음. 좀 더 정확히는 신입이 쌓을 수 있는 경험엔 보통 한계가 있기에 본문의 능력들을 고려하며 사람의 현재와 미래 가치를 추산하기 쉽지 않은데, 인사담당자 및 면접관 개인의 판단에 크게 의존하는 기존 방식보다 코테가 더 범용적이고 정확한 휴리스틱이라 주장하는 것으로 해석함.
즉 잠재력(지능, 컴퓨팅적 사고, ...)을 알고리즘에 얼마나 익숙한지로 확인한다는 건데, 이견이 있겠지만 난 이게 괜찮게 들어맞는다고 느껴서 일단은 생략. 내가 생각하는 이 방법의 문제는, 본문에 언급된 능력들과 저 잠재력엔 개발자로서의 적성과 재미, 그리고 협업 관련 능력이 포함되어 있지 않단 점임. 그래서 구글같은 곳은 여기에 여러 장치를 도입해서 문제를 해결하는 것 같은데... 솔직히 왜 잘 굴러가는지 모르겠어서 좀 신기함
1. 코테로 능지를 평가할 수 있다 2. 능지가 높으면 뭐든 잘 할 것이다 상식적으로는 두 전제가 참이라고 보고 그러는 거 같은데, 나는 둘 다 별로 맞는 주장은 아니라고 생각함. 2를 반박하는 연구는 교육학 쪽에서 여태 많이 나온 거 같고 1은 코테를 수능처럼 공부하는 친구들 땜에 글러 먹은 거 같음
음...... 일단 코테랑 알고리즘은 분명히 다르고 코테에서 쓰는 로직이 복잡하지도 않은데 지능을 평가할 수 있다는 부분부터 증명을 해야할거 같다. 알고리즘..... 뭐 icpc 진출하고 scpc상타고 이런 친구들은 확실히 똑똑하다 이런 말이 나오는데 고작 두세시간 푸는 코테로 그걸 알 수는 없음 기본 구현은 되는지 꼼꼼하게 엣지케이스 생각하는지 이 정도만 대충 체크하는거지
ㅇㅇ 나도 코테가 지능판별기로 기능하려면, 아래 글에서도 의견을 밝혔지만 지금 일반적인 코테 난이도보단 꽤 높게 만들어야 한다고 생각함. 실리콘밸리쪽 기업에선 종종 대회 난이도의 문제가 나오기도 한다던데, 그정돈 아니더라도 써먹으려면 적절한 상향이 필요할 것 같음.
츄럴/ 1은 난이도가 높아지면 어느정도 해소되지 않을까 하고 2는 나도 그렇게 생각했었는데, 구글을 비롯한 유명 대기업에서 알고리즘에 꽤 비중을 두는 걸 보면 적어도 개발에 관련해서는 참이거나, 보완할 방법이 있으니까 저렇게 하는 게 아닌가 싶음. 물론 내가 해당 기업들 면접을 본 적은 없어서 들리는 얘기로만 판단한 거라 반박 달게 받음... 그리고 말한 주제가 나오는 교육학 관련 글 얘기해주면 읽어보겠음
최근 코테는 충분히 그 쪽에 초점 잘 맞추고 뽑는거 같음 복잡한 알고리즘 원하는게 아니라 기초구현, 어려운 문제는 좀 복잡한 구현 이런거 물어보고 요즘은 과제전형이나 필기같은걸로 한번 더 걸러내니까
그냥 뭐 사람 뽑기 간편한거라 그렇지. 근데 "전체 규모의 설계" 이런건 어디서 배워야 함?
그건 많이해보는 수밖에 없지 엔터급이랑 오픈소스랑도 많이달라서 현업에서 많이 뛰면서 익히는 수밖엔 없음 - dc App
기업 코테는 진짜 공부 안 한 사람들 거르는 최소한의 필터 역할이지. 근데 알고리즘 재밌지 않냐? 개발자 취미로 이만한 게 없는데
짤 누구인
펀쿨섹좌 TS
코테도 못뚫어서 스타트업전전하는 놈들이 할말은 아니라고생각 적어도 네카라쿠배는 다니면서 말해리
솔직히 릿코드식의 코딩 테스트는 그냥 채용에 들어가는 비용을 줄이고 기초적인 코딩능력을 평가 하기 위해서 하는 거 라고 생각함.