드라이브 - 2부일시: 2024-05-14 10:00 - 11:00목차: 2부 4~5장4장 자율성근무시간의 15퍼센트를 자유롭게 쓰게한다?센디보다는 크고, 너무 크지는 않은 회사에서 효율적이다.예전의 구글처럼4장을 읽으면서 들었던 생각예전에는 동기2.0으로 잘 살아왔지만 시대가 변한 지금은 동기2.0으론 힘들다는게 드러났다. 그러나 한국의 대부분의 기업은 왜 동기2.0에서 바뀌지 않았는가?인간의 디폴트값은 자율성인가?애기는 뭐든지 잘 못 해도 지가 다 하고 싶어한다.엄마가 결혼할 상대는 골라온다면 어떤가? 싫다.누군가가 아무리 좋은 이상형, 아무리 좋은 무언가를 제시해주더라도 나의 선택이 아니라면 싫어진다.자율성에 대해 의심하지 말라!자율성은 내적 동기이다.성장은 고통이다성장에 대한 피드백이 빠르지않으면..
회고2024.05.10 ~ 2024.05.11. 팀 모집 학과 홈페이지 구독 서비스 MailBadara에서 해커톤 소식을 접했다. 인턴과 졸업과제를 병행하는 중이라 바쁜 상태였지만, 해커톤이라는 단어를 보자마자 참을 수 없어서 바로 팀원을 모집했다. 졸업한 타학교 컴공 친구를 부를까 했지만, 모집 대상이 재학생 한정이었다. 그래서 현재 소속된 부산대학교 인공지능 동아리 AID에서 팀원을 모집하기로 했다. 다년간의 해커톤 경험(총 7번)으로 다져진 내가 팀원을 모집할 때, 최소한으로 보는 기준은 다음과 같다.최소한 하나의 인공지능 분야를 공부했는가파이썬을 읽고 쓸 줄 아는가수상하지 못하더라도 배우고 즐기겠다는 마인드인가 "반드시 해커톤에서 수상하고 말겠다"는 마인드이면 본인이 조금 힘들 수 있다. 본..
드라이브 - 1부일시: 2024-05-02 13:00 - 14:00 목차: 1부느낀 점 1969년 "드라이브"라는 이론이 나온지도 오래 지났다. 산업혁명 때까지는 유용했던 동기 2.0(당근과 채찍)은 더 이상 유용하지 않다고 판명났다. 인간의 내재적 동기를 유도해야 한다는 "드라이브" 이론이 주목을 받기 시작했지만, 그래도 현대의 많은 사람들은 "당근과 채찍"의 방식을 고수하고 있다. 왜 그럴까? 책이 작성된 2011년과 현재 2024년도 크게 다르지 않다. 고등학생의 부모가 시험 성적을 잘 받아온다면 아이폰을 사주겠다는 약속은 흔한 이야기이다. 이는 웬만한 대기업이나 중소 기업도 마찬가지다. 지각하면 벌점을 주고 일을 잘하면 성과금을 준다. 인간의 동기를 불러일으키기에는 외적 보상과 체벌로는 더는 부족..
퇴근하자마자 동래역에 모여서 api 테스트 및 구현을 진행했다.아무리 비대면이 편해도, 직접 만나서 이야기하는 것이 훨씬 효율이 좋다. 뭐 좀 수정해줘, 구현해줘, ui좀 꾸며줘, 이거 토큰 필요한가.. 요구사항을 바로 전달하고 응답을 받을 수 있는 점이 가장 그렇다.이제 최종보고서 제출까지 한달 남짓.. 좀 더 속도를 내야한다.
배경 서비스의 기획은 지난주에 확정되었고, 이제 본격적인 디자인 및 개발 단계에 들어섰다. 디자인이라곤 평생 해본 적도 없지만, 졸업과제에서 내가 프론트엔드 개발자를 맡은 만큼 내가 해야 했다. 그래도 바로 디자인에 들어가는 것보다는 어느 정도 와이어프레임을 확립해두고 시작하면 좋을 것 같았다. 내가 사용한 툴은 다음과 같다. Excalidraw with Obsidian: 와이어프레임 및 플로우차트, 마인트맵을 그리기 좋은 툴이다. 키보드와 트랙패트 만으로 그리는 중인데, 기능이 정말 필요한 기능만 있어서 심플하다. 특히 졸업과제 도중 서로의 생각이 달라지는 지점이 있을 때마다 그림으로 그려가면서 서로의 생각의 동기화시키는 데에 잘 써먹었다. Figma로 본격적인 디자인에 앞서 간단한 와이어프레임을 그리..
육각형 개발자 - 8-11부 일시: 2024-04-18 목차: 8부 ~ 11부 느낀 점 192p: 적절한 아키텍처는 상황에 따라 다르다. 모든 시스템이 24시간 서비스를 제공할 필요는 없다. 게임 서비스는 한참 사용자가 많은 시간대에 장애가 발생하면 매출 감소와 사용자 이탈이 생길 수 있다. HR 시스템은 24시간 서비스를 유지하기 위한 아키텍처를 요구하지 않는다. 대신 HR 시스템은 매우 민감한 개인 정보를 다루기 때문에 매우 엄격한 데이터 관리 체계를 갖추어야 한다. 개발하는 모든 시스템에 획일적으로 동일한 품질을 추구해서는 안 된다. 시스템마다 추구해야 하는 품질 속성이 다르므로 아키텍처도 달라져야 한다! => 항상 성능이 중요한게 아니구나. 보안을 위해서는 어느 정도의 성능 하락을 감수해야 하는구..
배경 우리 졸업과제의 메인은 2가지이다. zk-proof와 DID 기술을 활용한 사용자의 신원을 증명하는 "프로토콜"과 해당 프로토콜의 적절한 유스케이스를 보여줄 수 있는 "서비스"이다. 최종보고서 제출을 2달 앞둔 현재, 프로토콜 부분의 구현은 거의 완료되었고 프로토콜을 적절히 활용한 실제 서비스의 사례를 보여주기 위해 기획 단계에 들어갔다. 그리고.. 여러모로 골치를 썩고 있다. 초기 기획 - 열품타 초기에는 "어차피 졸업과제에서 중요한 건 프로토콜이니까 유스케이스는 적당한걸 보여줘도 될 것 같아. 적당히 만들자!" 였다. 그래서 부산대생임을 인증한 익명의 사람들끼리 사용할 수 있는 서비스로 무엇이 적합할까 고민한 결과, "열품타"가 선정되었다. 프로토콜 인증 로직을 거친 사용자는 "부산대학교"의 "..
육각형 개발자 - 4부 일시: 2024-04-11 15:30 ~ 16:10 목차: 4부 읽고 든 생각 리팩토링과 테스트는 빠른 구현을 해야하는 스타트업에서는 맞지 않는 느낌인가? 4장: 코드 시각화 - 미로에서 프로세스를 시각화하는 것과 같은건가? 113p: "응집도가 높아지면 구성요소가 역할에 따라 알맞게 분리될 가능성이 커진다." 반대 아닌가? 리팩토링: 인턴이라 그런가, 기존 로직을 함부로 리팩토링하기가 걱정이 되긴 한다. 함부로 고쳤다가 문제가 생길까봐. 프론트에서의 테스트는 어떤 것이 있을까? 운송 예약의 경우라면, 입력을 자동으로 넣고 예약이 됐는지 안됐는지를 테스트하면 될까?4부 - 코드이해 같은 용어를 사용했지만 서로 이해하는 바가 달랐다. => 우리들은 이런 상황에서 어떻게 하는가? 각자..
육각형 개발자 - 1~3부 일시: 2024-04-04 13:30 ~ 15:00 목차: 1~3부 1~3부는 뭔가 앞서 읽었던 "헬로스타트업"과 "함께자라기"를 잘 섞은 듯한 느낌. 새로울건 없었다. 새로운 기술을 어떻게 배우는지 라이언: 기존의 기술과 무엇이 다른가를 중점적으로 본다. 빅터, 민, 보름: 공식문서의 quickstart부터 시작 주니어에게는 두려움없이 핸즈온부터 시작하는걸 추천(바텀업) 이걸 하면서 동시에 탑다운으로 지식을 정리하면 금상청화 소프트웨어 전달 성과가 높다? 지속적인 전달(CD)을 하면, 간편하고 빠르고 자주 전달할 수 있게 된다. => 피드백이 빠르다. => 쓸데없는 일을 덜 하게 된다. php 라라벨 => java spring => kotlin spring 기술이 바뀌게 된 ..
