04 Dec 2022

INDEX

• 1. 모바일, 엣지 환경을 위한 MLops
• 2. 패널 토크 - AI researcher
• 3. 회사에서 좋은 AI 개발자가 되기 위한 몇 가지 실천적 방법
• 4. 패널 토크 - software engeineer
• 5. 네트워킹
• 6. 후기

---

festa

• AI is [ ]
• 12월 4일 일요일, 성수동 공간 와디즈에서 진행된 행사
  • 몰랐는데 왕십리랑 가까운 곳이었다.. 성수동을 처음 가봤다
• mlops, 커리어, 주니어 개발자 관련 내용들이 많았다. 정말 알찬 시간이었다

1. 모바일, 엣지 환경을 위한 MLops

• 늦어서 중간부터 들었음
• 연사자: 신정아님
  • 아티피셜 소사이어티 MLE
• 캐시 메모리: 병목을 줄이기 위한 범용 메모리
• 엣지 디바이스에서 dram 에 접근하는 것은 너무 비쌈
  • l1 에서 해야 함
  • 보통 l1 캐시만을 사용하고, 딥러닝에서 캐싱을 할 때 기억해야 함
• l1 캐시는 각 코어에 장착되어 있음
  • l2 는 2개의 코어가 하나를 공유
  • l3 는 8개가 하나를 공유
  • l1 캐시의 개수는 중요하지 않음. 일반적으로 서빙 하면 하나의 코어에서만 동작함
  • 하나의 l1 만 이용해서 한 번에 캐싱할 수 있는 수준은, 결국 64 정도임
  • 이걸 넘기 위해선 뭘 더 해야 하는데 뭔지는 모르겠음
• 레서 (어플리케이션 이름?)
  • 시선을 추적함
    • 시계열
    • gaze coordinate
    • blink series
    • head series
  • 집중 여부 판단
  • 10분 동안 잡힌 데이터를 마지막 test 완료 시점에 한 번에 서버에 보냄
  • 추론 시간이 길어져 주어진 캐시의 buffer 구간을 넘으면, sharedpreference 를 활용함
  • 테스트 완료 시 축적된 데이터를 resrful api ㄹ르 통해 RDBMS 로 보냄
• 트래픽이 적으면 이렇게도 가능.. 레서는 아직 사용자가 그리 많지 않음
  • 일일 평균 5-70명 정도이고, 아직 미미한 수준의 데이터 양
  • 카프카를 도입할 수준은 아님. 그래도 도입하려 함
    • 거대한 트래픽, 예기치 못한 장애 상황에 유연히 대응 가능
  • 카프카
    • 실시간 처리 가능
      • 동시 다발적인 데이터가 들어왔을 때 누락되는 게 있을 수도 있음
      • 실시간 로그 데이터가 집게되어있을 때 신속한 피드백을 줘야 한다면? 데이터의 양상이 이상하다면?
      • 한 번에 수십만 건의 데이터가 들어온다면?
      • 카프카는 실시간 분산 처리가 가능함
    • 임의의 타이밍에 데이터 읽기 가능
      • 실시간이 아니어도 배치 처리 가능
      • 20명이 다 차야 데이터를 보낸다고 했을 때, 카프카를 쓰면 queue 를 기다리기 전에 데이터 접근 가능 - ?
    • 다양한 제품과 시스템에 연동 가능
    • 메시지, 데이터를 잃지 않음
• TFDV
  • 엣지/모바일에서는 모델 크기가 5mb를 넘지 않음
    • sdk 로 포팅하면 20mb가 넘어감. 이걸 쓸 사람은 없음
  • 이럼 편향이 생김. 작은 모델은 이상한 데이터가 몇 개만 있어도 쉽게 편향이 생김
  • 따라서 데이터 정제가 중요하고, 이걸 도와주는 툴이 TFDV
  • train-test 데이터의 검증
  • train에 없는 양상이 test에 있따면, 그걸 train에 반영해줘야 하고
    • 그걸 검증해줌
  • 서빙할 때에도 real-world 데이터를 검증함
    • 내가 학습한 데이터는 4bit인데 8bit가 들어왔다든가.. 뭐 이런 경우에 캐스팅을 한다든지 처리 가능
  • 학습, 그리고 서빙하는 와중에도 데이터를 알아서 관리해줌
• 버전 관리
  • git, mlflow, github action, jenkins, travis CI
  • 학습하고 파생되는 파라미터 정보, metric 결과 등을 집계
  • serving support - 성능 기준이 충족된 모델들을 대상으로 서빙 가능한 평태로 모델을 조달 - tflite 등으로 전환해야 함
• 모델 패키징
  • kubeflow, tfserving, kfserving
  • 특정 플랫폼에서 서빙 가능한 형태로 바꿔줘야 함
  • 의존성을 주입하는 과정, 온디바이스는 어쩔 수 없음
    • 안드로이드에서는 tflite, torchmobile 등만 가능. quantization 필수
  • 개발 단계에서 pytorch 로 만들어진 모델을 tflite 화 시켜야 함
  • tflite, yml 등 모바일에서 추론 가능한 형태로
• 성능 평가
  • (1) 학습하고 한 번, (2) 변환하고 한 번, (3) 디바이스에 올리고 한 번
    1. tensorboard
    2. inference time / model size
       • 변환 이전과 정확도 비교. channel_first, channel_last 이슈 등..
    3. fps, inference time, cpu/gpu 사용량, 정확도, 유닛테스트 등
       • 총체적인 관점에서 평가
• 서빙 모니터링
  • operator wise benchmark
  • android profiler, sentry.io
    • 병목이 어디서 생기는지 알아서 집계해줌
• 파이프라인 매니징
  • tfx for mobile
  • 데이터 입력, 훈련, deploy 까지. 간편하게 파이프라인 설계 가능. scalable 한 deploy 환경까지 제공. 하지만 tf2.0 만 지원함
  • entry????
• 모르는 내용이 많았다

2. 패널 토크 - AI researcher

• 모더레이터: 신정아님
• 패널
  • 이정권 - Superb AI CTO
    • tbrain 이라는 회사에서 superb 로
    • computer vision 쪽 플랫폼 개발
  • 하용호 - Dable CDO
    • skt 출신
    • 음악 추천, 검색 엔진(2007..)
  • 홍다슬 - Riiid PMO
  • 이원성 - Upstage RecSys Tech Leader
• ai 를 도입할 때 생각하는 것들 (사실 질문이 잘 기억이 안 남)
  • AI 자체가 새로운 비즈니스를 창출하진 않음
  • 얼마나 비용을 절감하는가, 얼마나 돈을 버는가 등을 고민
  • 하용호님: AI를 비즈니스에 붙이기 시작하면 불행이 시작됨
    • 아무리 열심히 성능을 올려도 결국 money
    • 성능은 좋아지는데 매출은 감소하기도
  • 이정권님: 직접적인 roi 를 바로 가져오진 못하지만, 상황이 그나마 나음.
    • 고객들이 ml/dl 에 호의적이고 잘 안 돼도 그럴 수 있다고 생각함
    • 그래도 본질은 비슷함. 돈과 비용성, 가용성
    • 호의적이면서 이쪽 분야에 대한 지식이 많은 고객들
    • 돈을 냈는데 돈 값을 했는가, 등의 문제. 고객이 실패라 느꼈을 때 어떻게 보상할 것인가
  • 문제를 어떻게 정의해야 하는가가 중요함
• 리더로서의 어려움
  • 하용호님: 문제를 어떻게 발견할 것인가? 우선순위는? 우리가 모든 문제를 파악하고 있는가?
    • 최적의 광고를 보여주면 끝? 모델이 너무 결정적이라면? 비슷한 유저에게는 계속 같은 광고만 보여준다면,
    • 이런 관점을 모델에 넣었는가, 문제를 전부 정의했는가?
  • 이원성님: 리더의 고충은 다 비슷하겠지만, AI 리더의 고충은 좀 더 추가적임
    • 사람들이 기대하는 게 있다. ai 가 만능이라고 생각함
    • 커리어패스도 고민
    • 기술 수준에 비해 시장에서 기대하는 바가 너무 과도하다
    • 나도 모르는데 자꾸 해달라고 한다
  • 홍다슬님: 소통의 cost를 줄이는
    • riiid 는 다양한 직군들이 미팅을 하지 못함. 따로 분할된 미팅을 진행하고 결과만을 보고함
    • 그러다보니 문제가 생겼을 때 함께 논의하기 전에, 이미 답을 결정해 놓는 경우가 많음
    • 이걸 해결하려 노력
• 다른 팀과 협업할 때에 어떻게?
  • 데이터를 주고받을 때 low latency 를 맞추는 것이 중요함
  • 이걸 어떻게 맞출 것인가
  • 어떻게 많은 트래픽을 감당할 수 있는가? 이런 걸 같이 풀어야 함
    • 상대적으로 엔지니어링쪽 역량이 강화됨
    • 그래서 서버사이드 쪽과 많은 논의를 함
  • 이원성님: 킥오프하기 전 문서를 먼저 작성함
    • 해야할 일, 문제 상황, 솔루션 등
    • 미안해서라도 읽어 옴
    • 경쟁 poc가 있음
      • 참여 유도
  • 홍다슬님
    • 산타토익: 점수가 이미 있는 사람들이 예상 점수를 받았을 때 신뢰도가 하락하지 않을까-
    • 이런 고민들을 pm 이나 동료들에게 공유하는 것도 중요함
    • riiid 에서는 위 문제를 해결하기 위해 설문조사를 진행함

3. 회사에서 좋은 AI 개발자가 되기 위한 몇 가지 실천적 방법

• 연사자: 박규병님
  • 튜닙 대표이사
  • 튜닙은 항상 인턴이 있음. 몇 년 간 주니어 개발자들을 보며 느낀 생각들
• 개발 관련
  1. 코드는 회사 깃헙에
     • 올려라
  2. 귀찮아도 주석을
  3. 개발하는 사람 따로, 검증하는 사람 따로
     • 코드에 대한 책임을 져라, unittest 든 뭐든.. QA 에게 넘기지 마라
  4. 데이터가 100개면, 1개만 우선 생각해라
     • 조금씩 버전업
  5. 끙끙대며 혼자 하는 것은 대체로 미덕이 아니다. 주변에 물어봐라
• 소통 관련
  1. 개발자는 코드로 말하지 않는다. 사람은 언어로 말한다
  2. 묻는 말에 대답하는 것은 기본, 묻기 전에 알려줘라
     • 물어서 답하지 않으면.. 같이 일 할 수 없다. 그건 기본일 뿐이다
  3. 코딩하듯 말하라! SVO 를 지켜 얘기해라
     • 말을 한 뒤, 주어와 목적어를 생략했는지, 대명사를 썼는지 등을 확인해보고 고쳐야 함
  4. 스무고개 게임을 하지 마라
     • 한 번에 명확하게, 필요한 걸 전부
• 기록 관련
  1. 주니어는 기록만 잘 해도 50은 먹고 들어간다
     • 석사에서 가장 중요한 건, 기록과 보고이다. 학석박의 차이는 여기서 생긴다
  2. 실험이나 코딩이 끝나고 어떻게 설명해야 하는가? 코드, 보고서?
     • 뭔가는 해야 한다. 정리해서 보여주는 연습
     • 말로 하면 모른다. 난 알하도 듣는 이는 모름
     • 그럼 결국 또 스무고개이다
     • 보고서는 항상 실험 전에 써야 한다. 이 실험을 왜 하는지, 가설 설명 등
     • 실험이 끝나면 보고서도 끝나야 한다. 논문도 마찬가지이다
  3. 보고서에 결과에 대한 해석이 들어가면 안 된다?
     • 결론에는 주관적인 해석이 있어야 한다. 남에게 맡기지 마라, 직접 해야 함
  4. 해석을 읽는 사람에게, 듣는 이에게 맡기지 마라
     • 듣는 사람이 해석하게 하면 안 됨
     • 추론하게 하지 말고 이해시켜라
     • 그래야 오해가 없음
• 주니어에겐 코딩 실력이나 지식보단, 이런 기본기가 더 중요하다
• 같이 일할 수 있는가.. 등

4. 패널 토크 - software engineer

• 모더레이터: 박규병님
• 패널
  • 장영철
    • 마키나락스 mlops engineer
  • 임성현
    • Cochl backend engineer
    • 창업?
  • 장래영
    • 커먼컴퓨터 ai software eng lead
    • 블록체인?
  • 이용선
    • vessel ai software lead
• AI 모델링 외에 서비스를 만들거나 구축 및 운영하는 데 있어 가장 큰 어려움은?
  • 임성현님: 어떻게 poc를 더 빨리? b2b 에서
    • 돈은 얼마든지 줄 테니 1테라 짜리 cctv 를 분석해달라 하는 요구도..
    • 기술적인 background 가 없는 사람들
    • 접근성 개선에서 어려움이 있었고 노력 중
    • 그리고 ai를 접목해 비즈니스를 하려면 컨셉 검증을 통과해야 하고 까다로움
• mlops 주목도? dl 이 강세인가? dlops, aiops? mlops 로 근무하며 주로 하는 업무
  • 장영철님: ml 자체에 대한 연구는 이미 많이 이뤄졌음. 이제 적용의 단계인데, 이때 필요한 것이 mlops
    • 마키나락스는 산업현장의 요구를 해결하는 프로젝트를 진행중
    • 보통 정형데이터를 사용함. 그래서 ml/dl 을 혼용함. 문제를 풀기 위해 좋은 걸 사용함
    • mlops 가 커버하는 바운더리가 너무 넓다. 그래서 dlops, aiops 등의 용어가 생기는 거라 생각함. mlops 의 어떤 것에 더 포커싱하는
    • 그래서 새로운 것들이 생기는 이유는 mlops 가 너무 추상적이기 때문임. scope 를 줄이겠다는 시도
    • 주로 하는 일: 프로덕트 개발. end2end 지향
• mlops 구성 방법
  • 뭘, 그리고 어떻게?
  • 이용선님: 뭘?
    • 데이터 관리, 실험 기록 관리, gpu 관리, 모델 관리, 서빙…
    • 이런 걸 자동화함
    • 이전 회사에서는 슬랙으로 gpu 를 관리했음. 이런 불필요함, 불편함을 제거하는 일
    • 어떻게? 는.. 컨설팅을 받는 게 가장 빠르다
• 앳지디바이스, 경량화, 서빙 등
  • 임성현님: 경량화가 얼마나 어려운가
    • 성능 차이가 이슈임
    • 엣지에서 쓰려면 필수임
      • sdk 형태로 제공하고, 엣지에서 구동한다면 성능 차이는 불가피함
  • 박규병님: 요즘 트렌드는 양극단. 작게, 아니면 크게
    • 장래영님: 커먼컴퓨터는 커지는 방향을 선택함
• 리서치 팀과 일하면서 어려운 점
  • 임성현님: 커뮤니케이션 문제
    • 기획-개발 에서도 많고, 리서치-개발 에서도 많다
    • 음성 처리를 위해선 기본적인 신호처리 기법을 알아야 함
      • 백그라운드 차이
  • 장영철님: 커뮤니케이션 코스트가 크다
    • 이걸 줄이기 위해 다양한 노력을 함
    • 서로의 업무에 대한 이해. 일하는 방식에 대한 이해 -> 효과가 있었음
      • 적극적으로 사내 교육. k8s 강의 등..
      • 리서치 직무도 엔지니어적 역량을 갖출 수 있도록 하는
    • 리서치하는 사람이 엔지니어 하고 싶어하는 경우도 있고 반대도 있음
      • 이런 경우 넘어가서 융화되고, 그러는 경우가 있는데 - 마키나락스만 그런 걸 수도
    • 회사 분위기가 그래서 엄청 힘들다는 생각은 많이 들진 않음
  • 장래영님
    • 리서치는 미슐랭 식당을 찾고, 개발팀은 백종원 식당을 찾는다
      • 관점을 이해하는 게 중요함
      • 고객 입장에선 꼭 sota 가 아니어도 만족할 수 있다는 것
• 함께 일하고 싶은 동료는?
  • 이용선님: 예측 가능한 사람
    • 대화할 때 하나라도 정보를 더 주는
    • 물어보기 전에 미리 알려주는
    • 일정하게 일하려면 체력도 중요함
    • 소통과 예측 가능성
• 회사의 비전, 필요한 역량과 능력
  • 장영철님: 마키나락스는 도메인이 특별함
    • 산업 mlops 플랫폼
      • 필드의 사람들은 ml 을 모른다. 접근성 고도화
      • end2end 산업 mlops 플랫폼 분야는 아직 시장에 지배적인 회사나 제품이 없음
        • sagemaker 나 베슬ai 같은 빅테크의 mlops 플랫폼은 많지만, 산업 분야에선 딱히 없음
    • 따라서 아직 블루오션이고, 어떻게 ml 을 모르는 사람들에게 쉽게 전달할 수 있을까가 관건
    • 역량과 능력은 너무 애매함
      • 주니어 개발자라면, 입사 후 교육하기 애매한 도메인이 클라우드 지식임. 다른 건 토이플젝을 하든지 혼자 공부하든지 가능함. 근데 클라우드는 불가능
      • 대용량의 리소스를 처리해봤는가
      • 개인이 공부하긴 어렵겠지만, minikube 라도 해봤다고 하면, 인상적임. 혼자 하기 어려움
    • mlops 는 너무 넓다. 역량과 능력이 너무 많이 필요함.
      • 그 중에서도 클라우드 지식과 경험
• 일반적인 도메인에서의 백엔드 개발과 가장 큰 차이는?
  • 이용선님
    • 차이 없음
    • 비즈니스 도메인 이해는 어차피 해야 함. ml/dl 도 마찬가지
      • 큰 차이는 없다. ml inference 에서 어떤 단계를 거치는지, 이정도?
      • 구체적으로 neural network 의 작동 방식을 이해할 필요는 없음. 전반적인 이해만
  • 임성현님
    • 이하 동문
    • 내부 툴들이 많다
    • 학습은 결국 데이터 싸움임
      • 그래서 데이터 라벨링 툴이나, 외주나 그런 프로세스가 있음
      • 특히 의료 데이터처럼 독특한 도메인의 데이터는 내부 툴으로 해결해야 함
• mlops 서빙 쪽으로 커리어를 어떻게 전환했는가
  • 이용선님
    • 백엔드만 하다가 mlops 로 넘어왔음
    • 근데 이 회사에서도 백엔드만 함
    • 위에서 언급된 스타트업에서 발견한 비효율(슬랙으로 gpu 관리)을 발견하고 자연스럽게 전환
    • 그 뒤로부턴 비슷한 일을 함. 백엔드를 밑에서부터 쌓아올리는 역할
      • ai 에 대한 이해가 늘긴 했지만 주 경력은 결국 백엔드임
      • 크게 다르지 않다
• 주니어에게 해주고 싶은 말
  • 이용선님
    • 주니어는 역량을 발휘하는 단계가 아니다
      포텐셜을 내기 위한 준비 기간이다
      • 그래서 기본기를 쌓는 게 가장 중요함.
        아까 함께 일하고 싶은 동료는, 이라는 질문에 답한 것은 제너럴한 관점에서의 답변임
    • 트렌드는 계속 바뀜. 어차피 매번 따라가야 하는 입장이고, 기본기가 있다면 쉬움. (db나 컴퓨터 구조, 네트워크 등)
    • 영어 공부를 해라!
      • 베슬ai는 미국으로 자사를 옮겼고, 미국 회사가 되었음.
      • 그냥 개발 하다보면 영어를 쓸 일이 아주 많음
    • 면접도 마찬가지
      • 결국 학교에서 공부한 걸 위주로 물어본다
      • 기본기가 가장 중요
• 플젝은 큰데 혼자.. pm 밖에 없음
  • 장래영님: pm 이 있으면 그 분과 할 수 있는 것, 없는 것을 일단 정해라
    • 가능한 걸 먼저 잡는 게 가장 중요함
    • POC 나 프로토타입 정도로만 만들자, 이런 식으로 - 이게 최우선 같다
• AI 로 밥벌이를 한다는 것의 의미? 단순이 keras, 허페의 api 를 잘 쓰면 되는 건지, 아니면 적절한 알고리즘을 찾아야 하는 건지
  • 장영철님
    • AI 라는 키워드는 가려도 될 듯
    • 밥벌이를 한다는 것은 결국 문제를 푸는 것임
      • 도메인을 찾고 문제를 찾고, 그걸 푸는 것이 곧 밥벌이임
    • 문제를 찾고 정의하는 게 가장 중요함
    • 이전에 어떤 강연헤서 교수님께서 하신 말씀,
      • 어떤 질문에 대해 정답을 낼 수도 오답을 낼 수도 있지만, 질문 자체가 틀렸다면 정답은 절대 나올 수 없다.
    • 문제를 찾고 정의하고 푸는 사람이 되자
  • 임성현님
    • 개발자든 리서처든 기술이나 지식으로 밥벌이를 함
    • 필드에서 일하다보면 하는 착각 중 하나, 기술에 매몰되는 것
      • 기술에 매몰되면 안 됨
      • 사업적인 밸류를 찾고 판매해야 함. 비즈니스의 관점에서. 너무 기술만 좇다보면 이걸 놓치게 됨
      • 어떤 분야도 마찬가지인데, 비즈니스를 염두해 두고 그런 역량을 활용하는 게 중요함
  • 이용선님
    • 혼자 하는 건 없다. 사람을 대해야 함
    • 기술에 매몰되기보단 어떻게 일해야 하는지
      • 협업을 어떻게 해야 하는지, 이런 걸 고민해야 함
• 여러분에게 AI란
  • 장래영님
    • 오래 전까지는, 개발자만, 리서처만 하던 것
    • 이제는 미드저니 등의 stable diffusion 이 보급되면서 일반인들이 더 많이 사용함
    • 이처럼 누구나 사용할 수 있게 되었으면 좋겠다
      • 2030년에는 가능하게… 그런 희망을 품고 있음
    • AI는 힙한 무언가이다
  • 임성현님
    • 우리 삶을 윤택하게 하는 것
    • AI 생테계에 미약하게 기여하는 입장이지만
      이게 발전해 어느 순간엔 삶이 나아지지 않을까 생각함
  • 이용선님
    • 인간이 가질 수 있는 궁극의 도구
      • 도구는 하고 싶은 걸 하기 위해 시간과 에너지를 아껴주는 것임
      • ai 는 이런 의미에서 인류의 시간과 자원을 아껴주고 있고, 이렇게 생성된 자원들로 더 나은 사회가 될 수 있다고 생각함, 그런 원동력이 될 것이라고
    • 코딩을 처음 했을 때, 내 프로그램이 사회에 기여했으면 하는 바람이 있었는데, 그런 동기 부여가 되고 있는 존재
  • 장영철님
    • 엔진과 비슷함
      • 엔진은 자동차를, 비행기를, 배를 나아가게 하지만 엔진 혼자서는 아무것도 할 수 없음
      • mlops 의 중요도? 그것도 마찬가지임. ops 가 왜 대두되는가
      • AI 는 있는데 그걸로 뭘 하기 어렵기 때문임. 실질적인 benifit 이 없음
      • 그런 단계를 밟기 위해 mlops 가 나왔고, 그렇기 때문에 AI 는 엔진이다
    • 강력한 도구이지만, 뭔가 더 필요한 무언가이다

5. 네트워킹

• 임성현님, 이용선님과 함께 했음
• 로봇 관련 창업(로봇을 소리로 호출하면 알아서 오는?)을 생각해서 팀원을 모으시는 분, upstage 개발자분도 계셨음
• 프로젝트 주제 관련
  • 주니어라면 주제는 크게 중요하지 않음
  • 패널 토크에서 주제를 얘기한 것은 경력자들에게 하는 조언
  • 기술 위주로 토이플젝을 하는 것도 좋음
  • 노벨티가 없어도
• 영어 관련
  • 교환학생
  • 영어로 뭘 할 때가 많음
• 클라우드 공부 관련
  • 자격증보단 직접 해보는 것
  • 무슨 test..? 뭘 말씀하셨는데 기억이 안 남
• 창업 관련 질문을 했어야 했는데 못했음. 시간이 없었다. 아쉽다

6. 후기

• 같이 들으러 간 부캠 사람들을 결국 못 봤다
• 끝나고 고속터미널역 탐방을 했다. 너무 복잡해서 백화점 들어가는 데에만 30분은 걸린 듯..
• 바를 가고 싶었는데 동선도 안 맞고 그래서 그냥 바로 집에 왔다.
  근데 안 마시길 잘 한 듯. 이거 다 쓰니까 1시다..
• 이렇게 열심히 기록해도.. 솔직히 나중에 볼지 모르겠다
  • 그리고 이미 markdown 으로 다 기록해놨는데 블로그에 옮기는 데에 시간이 넘 오래 걸린다
  • 다음부턴 전부 다 옮기지 말고, 블로그엔 압축된 내용으로만 올려야겠다
    • 지금은 거의 모든 내용을 옮겨적었다…… 다음부턴 중요한 것만 요약해서 키워드만!
  • 어차피 이렇게 하면 안 보니까 키워드만 적어놓는 것도 좋을 거 같다
• 나도 주니어 개발자로서 시작할 텐데, 좋은 이야기를 많이 들은 거 같다

---

first draft: 2022.12.05 01:03