With so many false-starts, they need the right, new entry point...

Google's XR Re-Entry Point

Google이 XR 하드웨어를 위해 Android XR 플랫폼을 개발 중이며, 관련 하드웨어를 삼성전자와 Moohan 프로젝트 명으로 협력 중이라고 합니다.

관련 하드웨어 출시가 구글 리더들이 아직 출시가 충분하지 않다고 판단하여 기존 출시 일정 보다 미뤄진 내년 1분기로 연기되었다고 하네요.

XR 시장에서 구글은 Meta와의 경쟁에서 독자적인 소프트웨어 플랫폼을 구축하려 하고 있으며, Meta와 협력보다는 독립적인 전략을 선택하고 있습니다.

Meta 주요 제품(레이밴 협업, 퀘스트)과 Apple의 Vision Pro 시장 반응이 구글의 전략 결정에 영향을 미치고 있는데요. 구글은 이러한 시장 상황을 고려하여 디바이스 출시를 조정하고 있으며, 보다 준비된 제품을 출시하려는 노력으로 볼 수 있습니다(물론 애초 계획했던 출시 일정 대비 많이 미뤄지지 않아서 제품 개발 관점에서 그 차이가 얼마나 클지 잘 모르겠습니다).

MG Siegler는 구글이 XR 시장에 재진입하기 위해 신중한 접근 방식을 취하고 있으며, 이는 이전 실패로부터 얻은 교훈을 반영한 전략적 결정임을 강조하고 있습니다.

https://spyglass.org/google-glasses-xr/?ref=the-outer-ring-newsletter

Google이 XR 하드웨어를 위해 Android XR 플랫폼을 개발 중이며, 관련 하드웨어를 삼성전자와 Moohan 프로젝트 명으로 협력 중이라고 합니다. 관련 하드웨어 출시가 구글 리더들이 아직 출시가 충분하지 않다고 판단하여 기존 출시 일정 보다 미뤄진 내년 1분기로 연기되었다고 하네요. XR 시장에서 구글은 Meta와의 경쟁에서 독자적인 소프트웨어 플랫폼을 구축하려 하고 있으며, Meta와 협력보다는 독립적인 전략을 선택하고 있습니다. Meta 주요 제품(레이밴 협업, 퀘스트)과 Apple의 Vision Pro 시장 반응이 구글의 전략 결정에 영향을 미치고 있는데요. 구글은 이러한 시장 상황을 고려하여 디바이스 출시를 조정하고 있으며, 보다 준비된 제품을 출시하려는 노력으로 볼 수 있습니다(물론 애초 계획했던 출시 일정 대비 많이 미뤄지지 않아서 제품 개발 관점에서 그 차이가 얼마나 클지 잘 모르겠습니다). MG Siegler는 구글이 XR 시장에 재진입하기 위해 신중한 접근 방식을 취하고 있으며, 이는 이전 실패로부터 얻은 교훈을 반영한 전략적 결정임을 강조하고 있습니다. https://spyglass.org/google-glasses-xr/?ref=the-outer-ring-newsletter

Spyglass

Google의 Android XR 플랫폼

Mistral Large 2 123B이 발표되었네요. Llama 3.1 이 발표된지 하루만인데요. 이번주는 고맙게도 도파민 주간으로 정했나봅니다. ㅋㅋ 아무튼 면면을 살펴보면,

우선 오픈 소스로 발표됐으나 연구용으로만 사용 할 수 있습니다. Llama 3.1 405B의 1/3.2배 수준이지만 코딩, 수학 테스트에서 더 뛰어난 성능을 보입니다. GPT-4o에 비해서는 살짝 떨어지고요.

이런 결과를 살펴봤을 때, Mistral도 이제 성능 향상 경쟁보다는 실제로 사용할 수 있는 기능성 목표에 더 집중하는 것 같습니다. 코딩과 이를 이용한 함수 호출 등이 ✌️현재✌️실제 세계에 영향을 미칠 수 있는 가장 중요한 기능이니까요.

LLM의 성능이 약간 정체기에 있는 지금 많은 회사들이 이를 따를 것 같습니다. 간밤에 발표한 Cohere의 Rerank 신규 버전도 그렇고요.

과연 조만간 OpenAI나 Anthropic이 이를 뛰어 넘는 또 다른 진보를 보여 줄 수 있을까요? 지금까지와는 차원이 다른 도파민 수급을 기다려봅니다. 😎🍿🥤

Mistral Large 2 123B이 발표되었네요. Llama 3.1 이 발표된지 하루만인데요. 이번주는 고맙게도 도파민 주간으로 정했나봅니다. ㅋㅋ 아무튼 면면을 살펴보면, 우선 오픈 소스로 발표됐으나 연구용으로만 사용 할 수 있습니다. Llama 3.1 405B의 1/3.2배 수준이지만 코딩, 수학 테스트에서 더 뛰어난 성능을 보입니다. GPT-4o에 비해서는 살짝 떨어지고요. 이런 결과를 살펴봤을 때, Mistral도 이제 성능 향상 경쟁보다는 실제로 사용할 수 있는 기능성 목표에 더 집중하는 것 같습니다. 코딩과 이를 이용한 함수 호출 등이 ✌️현재✌️실제 세계에 영향을 미칠 수 있는 가장 중요한 기능이니까요. LLM의 성능이 약간 정체기에 있는 지금 많은 회사들이 이를 따를 것 같습니다. 간밤에 발표한 Cohere의 Rerank 신규 버전도 그렇고요. 과연 조만간 OpenAI나 Anthropic이 이를 뛰어 넘는 또 다른 진보를 보여 줄 수 있을까요? 지금까지와는 차원이 다른 도파민 수급을 기다려봅니다. 😎🍿🥤

OpenAI의 올해 손실이 약 50억 달러, 약 7조원 정도 된다고 하네요. 모델 학습에 약 1조원, 인재 유치에 2조원 든다고 합니다. 증자하지 않으면 약 1년 정도 후에는 자금이 소진하게 되는데요. 이는 경쟁자인 Anthropic도 비슷합니다. (OpenAI의 절반 정도)

AI 경쟁은 이제 자본, 즉 어른의 싸움이 되어버렸는데요. AI의 성능 향상의 여지가 더 남았을지, 아니면 이제 진짜 수익화를 위해 달려갈지, 과연 각 회사들의 미래 방향을 어떻게 잡을지 궁금해지지 않을 수 없네요.

OpenAI의 올해 손실이 약 50억 달러, 약 7조원 정도 된다고 하네요. 모델 학습에 약 1조원, 인재 유치에 2조원 든다고 합니다. 증자하지 않으면 약 1년 정도 후에는 자금이 소진하게 되는데요. 이는 경쟁자인 Anthropic도 비슷합니다. (OpenAI의 절반 정도) AI 경쟁은 이제 자본, 즉 어른의 싸움이 되어버렸는데요. AI의 성능 향상의 여지가 더 남았을지, 아니면 이제 진짜 수익화를 위해 달려갈지, 과연 각 회사들의 미래 방향을 어떻게 잡을지 궁금해지지 않을 수 없네요.

For the last four months I've been developing a custom container image builder, collaborating with Outerbounds1. The technical details of the builder itself might be the topic of a future article, but there's something surprising I wanted to share already

Using S3 as a container registry

AWS에서 Docker Hub같은 컨테이너 레지스트리 서비스가 ECR인데 이러한 레지스트리를 쓰는 대신 S3를 레지스트리로 대신 써서 테스트 했을 때 ECR보다 최대 8배까지 빨랐다고 실험한 내용을 설명한 글입니다.

컨테이너 레지스트리도 결국은 HTTP로 레이어를 주고 받는 것이기 때문에 인증 문제만 따로 해결하면 S3도 레지스트리로 사용할 수 있는데 찾아본 결과 이 속도 차이는 OCI 표준에 따라 레이어 푸시가 순차적으로 이뤄지는데 S3를 사용했을때는 레이어 푸시가 병렬로 이뤄져서 발생한 결과입니다.

회사 내부에서 테스트 중인거 같은데 해커뉴스의 논의에서도 OCI 표준에서 왜 레이어를 순차적으로 하는지 여러번 질문을 하지만 명확한 답변을 찾지 못하고 있습니다. 일단 테스트에서는 큰 문제가 없었지만 표준에서 또 그렇게 한 어떤 배경이 있을거기때문에 예상치 못한 문제가 있는지 찾고 있는 것 같은데 규모가 커질수록 꽤 용량이 큰 컨테이너 이미지를 받아오는 것도 서버가 뜨는데 영향을 끼치는데 재미있는 실험이라고 생각하고 있습니다.

https://ochagavia.nl/blog/using-s3-as-a-container-registry/

AWS에서 Docker Hub같은 컨테이너 레지스트리 서비스가 ECR인데 이러한 레지스트리를 쓰는 대신 S3를 레지스트리로 대신 써서 테스트 했을 때 ECR보다 최대 8배까지 빨랐다고 실험한 내용을 설명한 글입니다. 컨테이너 레지스트리도 결국은 HTTP로 레이어를 주고 받는 것이기 때문에 인증 문제만 따로 해결하면 S3도 레지스트리로 사용할 수 있는데 찾아본 결과 이 속도 차이는 OCI 표준에 따라 레이어 푸시가 순차적으로 이뤄지는데 S3를 사용했을때는 레이어 푸시가 병렬로 이뤄져서 발생한 결과입니다. 회사 내부에서 테스트 중인거 같은데 해커뉴스의 논의에서도 OCI 표준에서 왜 레이어를 순차적으로 하는지 여러번 질문을 하지만 명확한 답변을 찾지 못하고 있습니다. 일단 테스트에서는 큰 문제가 없었지만 표준에서 또 그렇게 한 어떤 배경이 있을거기때문에 예상치 못한 문제가 있는지 찾고 있는 것 같은데 규모가 커질수록 꽤 용량이 큰 컨테이너 이미지를 받아오는 것도 서버가 뜨는데 영향을 끼치는데 재미있는 실험이라고 생각하고 있습니다. https://ochagavia.nl/blog/using-s3-as-a-container-registry/

Adolfo Ochagavía

Only 23% of devs are satisfied with DevEx improvements. Download our free report to learn what causes misalignments and what your organization can do.

State of Developer Experience Report 2024 | Atlassian

지라, 위키 등으로 유명한 아틀라시안 2024 State of Developer Experience Report 2024가 나왔습니다 :)
https://www.atlassian.com/software/compass/resources/state-of-developer-2024

개발자에게 있어서 우리의 업무 환경이 어떻게 이루어져 있는지에 대한 정량적 지표를 볼 수 있는데요. 생각보다 아직 개발자의 생산성을 어떻게 증대 시켜야 하는지, 또 얼마나 중요한지에 대해서는 아직 아쉬운 점들이 많아 보입니다. 불필요한 일을 덜 하고, 귀찮은 일은 AI 에게, 자동화와 다양한 실험으로 더 즐거운 환경. 말은 쉽지만 역시 실천은 어려운 것 같습니다 ^_ㅠ

 1. 복잡성과 비효율성: 세 명 중 두 명의 개발자가 비효율성으로 인해 주당 8시간 이상을 낭비하고 있으며, 주요 원인으로는 인력 부족, 역할 확장, 도구 간의 빈번한 전환 등이 포함됩니다.
 2. 개발자 경험(DX): 절반 이하의 개발자만이 조직이 개발자 경험을 우선시한다고 느끼고 있습니다. 개발자 경험을 개선하려는 노력이 증가하고 있지만 아직 효과적이지 않습니다.
 3. AI 도구: AI 도구에 대한 관심에도 불구하고, 두 명 중 한 명의 개발자는 이러한 도구가 생산성을 크게 향상시키지 않았다고 보고하고 있습니다. 단 12%만이 향후 2년 내에 AI가 생산성을 향상시킬 것이라고 믿고 있습니다.
 4. 시간 손실의 주요 원인: 기술 부채, 불충분한 문서화, 번거로운 빌드 프로세스, 깊은 작업 시간 부족, 불명확한 방향성 등이 주요한 방해 요인으로 지목되었습니다.
 5. 생산성 향상을 위한 방안: 리더들은 AI 자동화, 새로운 협업 도구 제공, 위험 감수 및 실험 장려, 의사 결정 간소화, 해커톤 개최 등이 생산성과 만족도를 높일 수 있는 방안으로 제안되고 있습니다.
 6. 생산성 측정: 조직들은 생산성 측정과 만족도 측정에 대해 의견이 나뉘어 있으며, 51%의 조직이 개발자 생산성을 측정하는 데 초점을 맞추고 있는 반면, 49%는 개발자 만족도에 초점을 맞추고 있습니다. 그러나 여전히 38%는 근무 시간으로 생산성을 측정하고 있습니다.

지라, 위키 등으로 유명한 아틀라시안 2024 State of Developer Experience Report 2024가 나왔습니다 :) https://www.atlassian.com/software/compass/resources/state-of-developer-2024 개발자에게 있어서 우리의 업무 환경이 어떻게 이루어져 있는지에 대한 정량적 지표를 볼 수 있는데요. 생각보다 아직 개발자의 생산성을 어떻게 증대 시켜야 하는지, 또 얼마나 중요한지에 대해서는 아직 아쉬운 점들이 많아 보입니다. 불필요한 일을 덜 하고, 귀찮은 일은 AI 에게, 자동화와 다양한 실험으로 더 즐거운 환경. 말은 쉽지만 역시 실천은 어려운 것 같습니다 ^_ㅠ <ol ><li>복잡성과 비효율성: 세 명 중 두 명의 개발자가 비효율성으로 인해 주당 8시간 이상을 낭비하고 있으며, 주요 원인으로는 인력 부족, 역할 확장, 도구 간의 빈번한 전환 등이 포함됩니다.</li><li>개발자 경험(DX): 절반 이하의 개발자만이 조직이 개발자 경험을 우선시한다고 느끼고 있습니다. 개발자 경험을 개선하려는 노력이 증가하고 있지만 아직 효과적이지 않습니다.</li><li>AI 도구: AI 도구에 대한 관심에도 불구하고, 두 명 중 한 명의 개발자는 이러한 도구가 생산성을 크게 향상시키지 않았다고 보고하고 있습니다. 단 12%만이 향후 2년 내에 AI가 생산성을 향상시킬 것이라고 믿고 있습니다.</li><li>시간 손실의 주요 원인: 기술 부채, 불충분한 문서화, 번거로운 빌드 프로세스, 깊은 작업 시간 부족, 불명확한 방향성 등이 주요한 방해 요인으로 지목되었습니다.</li><li>생산성 향상을 위한 방안: 리더들은 AI 자동화, 새로운 협업 도구 제공, 위험 감수 및 실험 장려, 의사 결정 간소화, 해커톤 개최 등이 생산성과 만족도를 높일 수 있는 방안으로 제안되고 있습니다.</li><li>생산성 측정: 조직들은 생산성 측정과 만족도 측정에 대해 의견이 나뉘어 있으며, 51%의 조직이 개발자 생산성을 측정하는 데 초점을 맞추고 있는 반면, 49%는 개발자 만족도에 초점을 맞추고 있습니다. 그러나 여전히 38%는 근무 시간으로 생산성을 측정하고 있습니다.</li></ol>

Atlassian

개발자 생산성은 아직도 충분히 이해받지 못하고 있다.

메타의 Llama 3.1가 공식 출시되었네요. 성능이 뛰어나긴 하지만, 지금 시점에서는 오픈소스 모델이 프론티어 모델을 따라잡았다 수준이라서 역시 조금 아쉽긴 합니다. 물론 대단한 일임엔 틀림없지만요.

기능적으로는 128K 컨텍스트를 지원하고 다국어와 Tool Use를 정식으로 지원합니다.

훈련(학습) 방식에 있어서는 아주 특별한 브뤡스루는 없지만, 사전 훈련을 위해 LLM을 이용한 데이터 필터링과, 사후 훈련에 LLM으로 생성한 합성 데이터를 많이 사용했다는 것이 중요했다고 합니다.

이미 알려진 사실이긴 하지만, LLM의 성능이 일정 수준 이상에 도달함에 따라, LLM을 재귀적으로 사용하여 자연 발전시킬 수 있게 되었다는 것이 공식화된 느낌입니다.

무엇보다 발표하면서 거의 모든 클라우드 업체와의 협력을 발표했는데요. 왠지 메타답지 않은 행보라서 신선하기도하고 그만큼 대단하다는 생각도 듭니다.

메타의 Llama 3.1가 공식 출시되었네요. 성능이 뛰어나긴 하지만, 지금 시점에서는 오픈소스 모델이 프론티어 모델을 따라잡았다 수준이라서 역시 조금 아쉽긴 합니다. 물론 대단한 일임엔 틀림없지만요. 기능적으로는 128K 컨텍스트를 지원하고 다국어와 Tool Use를 정식으로 지원합니다. 훈련(학습) 방식에 있어서는 아주 특별한 브뤡스루는 없지만, 사전 훈련을 위해 LLM을 이용한 데이터 필터링과, 사후 훈련에 LLM으로 생성한 합성 데이터를 많이 사용했다는 것이 중요했다고 합니다. 이미 알려진 사실이긴 하지만, LLM의 성능이 일정 수준 이상에 도달함에 따라, LLM을 재귀적으로 사용하여 자연 발전시킬 수 있게 되었다는 것이 공식화된 느낌입니다. 무엇보다 발표하면서 거의 모든 클라우드 업체와의 협력을 발표했는데요. 왠지 메타답지 않은 행보라서 신선하기도하고 그만큼 대단하다는 생각도 듭니다.

Spring I/O 2024 - 30-31 May, Barcelona In the last decade, much emphasis has been placed on decomposing monoliths into microservices. While this practice has important benefits, including increased agility for development teams and independent lifecycle m

The Modern Monolith, with Spring Modulith by Cora Iberkleid @ Spring I/O 2024

예전엔 서비스가 커지면 MSA가 답이라는 글을 많이 읽었는데, 요즘은 MMA 이야기가 많더라구요. 상황에 따라 맞는 아키텍처를 가져가야겠죠? 특징을 살펴보세요!

👨🏻‍💻 이유
 1. 복잡성 관리: MSA는 서비스 간의 통신, 데이터 일관성 유지, 배포 파이프라인 등에서 복잡성을 증가시킵니다. 이 복잡성을 줄이기 위해 Modular Monolithic Architecture를 선택할 수 있습니다.
 2. 성능 최적화: 마이크로서비스 간의 통신 오버헤드가 문제될 수 있습니다. 모놀리식 아키텍처는 동일 프로세스 내에서의 호출로 성능을 최적화할 수 있습니다.
 3. 비용 절감: 마이크로서비스는 각각의 서비스가 독립적으로 배포되고 운영되어야 하기 때문에 인프라 및 운영 비용이 증가할 수 있습니다. 이를 줄이기 위해 모놀리식 아키텍처가 다시 주목받고 있습니다.
 4. 개발 및 디버깅 용이성: 모놀리식 아키텍처는 하나의 코드베이스에서 작업하기 때문에 디버깅 및 개발이 더 용이할 수 있습니다.

👨🏻‍💻 장점
 1. 단순성: 단일 애플리케이션으로 개발, 테스트, 배포가 단순해집니다.
 2. 일관성: 데이터 일관성 관리가 쉬워지고, 트랜잭션 관리가 용이합니다.
 3. 성능: 서비스 간의 네트워크 통신이 없으므로 성능 최적화가 가능합니다.
 4. 비용 절감: 인프라 및 운영 비용을 절감할 수 있습니다.

👨🏻‍💻 단점
 1. 스케일링 문제: 모놀리식 아키텍처는 특정 부분만을 스케일링하는 것이 어렵습니다.
 2. 배포 주기: 하나의 작은 변경 사항이 전체 애플리케이션의 재배포를 필요로 할 수 있습니다.
 3. 기술 채택 제한: 전체 애플리케이션이 동일한 기술 스택을 사용해야 하므로, 새로운 기술을 부분적으로 도입하기 어렵습니다.
 4. 팀 협업: 대규모 팀이 동시에 작업할 경우 충돌이 발생할 수 있습니다.

결론적으로, Modular Monolithic Architecture로의 전환은 특정 상황에서 MSA의 복잡성을 줄이고 효율성을 높이기 위해 선택될 수 있습니다. 하지만, 이는 조직의 특정 요구와 환경에 따라 다를 수 있으며, 어느 아키텍처가 더 적합한지는 상황에 따라 달라질 수 있습니다.

https://www.youtube.com/watch?v=Pae2D4XcEIg

예전엔 서비스가 커지면 MSA가 답이라는 글을 많이 읽었는데, 요즘은 MMA 이야기가 많더라구요. 상황에 따라 맞는 아키텍처를 가져가야겠죠? 특징을 살펴보세요! 👨🏻‍💻 이유<ol ><li>복잡성 관리: MSA는 서비스 간의 통신, 데이터 일관성 유지, 배포 파이프라인 등에서 복잡성을 증가시킵니다. 이 복잡성을 줄이기 위해 Modular Monolithic Architecture를 선택할 수 있습니다.</li><li>성능 최적화: 마이크로서비스 간의 통신 오버헤드가 문제될 수 있습니다. 모놀리식 아키텍처는 동일 프로세스 내에서의 호출로 성능을 최적화할 수 있습니다.</li><li>비용 절감: 마이크로서비스는 각각의 서비스가 독립적으로 배포되고 운영되어야 하기 때문에 인프라 및 운영 비용이 증가할 수 있습니다. 이를 줄이기 위해 모놀리식 아키텍처가 다시 주목받고 있습니다.</li><li>개발 및 디버깅 용이성: 모놀리식 아키텍처는 하나의 코드베이스에서 작업하기 때문에 디버깅 및 개발이 더 용이할 수 있습니다.</li></ol> 👨🏻‍💻 장점<ol ><li>단순성: 단일 애플리케이션으로 개발, 테스트, 배포가 단순해집니다.</li><li>일관성: 데이터 일관성 관리가 쉬워지고, 트랜잭션 관리가 용이합니다.</li><li>성능: 서비스 간의 네트워크 통신이 없으므로 성능 최적화가 가능합니다.</li><li>비용 절감: 인프라 및 운영 비용을 절감할 수 있습니다.</li></ol> 👨🏻‍💻 단점<ol ><li>스케일링 문제: 모놀리식 아키텍처는 특정 부분만을 스케일링하는 것이 어렵습니다.</li><li>배포 주기: 하나의 작은 변경 사항이 전체 애플리케이션의 재배포를 필요로 할 수 있습니다.</li><li>기술 채택 제한: 전체 애플리케이션이 동일한 기술 스택을 사용해야 하므로, 새로운 기술을 부분적으로 도입하기 어렵습니다.</li><li>팀 협업: 대규모 팀이 동시에 작업할 경우 충돌이 발생할 수 있습니다.</li></ol> 결론적으로, Modular Monolithic Architecture로의 전환은 특정 상황에서 MSA의 복잡성을 줄이고 효율성을 높이기 위해 선택될 수 있습니다. 하지만, 이는 조직의 특정 요구와 환경에 따라 다를 수 있으며, 어느 아키텍처가 더 적합한지는 상황에 따라 달라질 수 있습니다. https://www.youtube.com/watch?v=Pae2D4XcEIg

YouTube

Modular Monolithic Architecture

🗞️ OpenAI, GPT-4o mini 발표!

성능은 GPT-4o에 육박하고 ChatBot Arena에서 GPT-4보다 좋은 점수를 보였으며, 가격은 GPT-3.5 Turbo 보다도 60% 저렴합니다. 당연히(?) 멀티 모달이고 128K 컨텍스트를 지원합니다.

역시 OpenAI 답게 가격으로 후려치는군요! 🤣 자 이제 다음타자 나와주세요. 😎🍿🥤

🗞️ OpenAI, GPT-4o mini 발표! 성능은 GPT-4o에 육박하고 ChatBot Arena에서 GPT-4보다 좋은 점수를 보였으며, 가격은 GPT-3.5 Turbo 보다도 60% 저렴합니다. 당연히(?) 멀티 모달이고 128K 컨텍스트를 지원합니다. 역시 OpenAI 답게 가격으로 후려치는군요! 🤣 자 이제 다음타자 나와주세요. 😎🍿🥤

We're on a journey to advance and democratize artificial intelligence through open source and open science.

Hugging Face - The AI community building the future.

모두의연구소는 지식을 나누며 함께 성장하는 국내 최대 SW/AI 커뮤니티입니다.

🤵‍♂️ 빠르다 빨라 AI 세상
 1. Chameleon: 멀티 모달 작업을 위한 초기 융합 토큰 기반 모델의 개발 및 성능 평가
카멜레온은 이미지와 텍스트를 포함한 임의의 시퀀스를 이해하고 생성할 수 있는 초기 융합 토큰 기반의 혼합 모달 모델 제품군입니다. 이 모델은 안정적인 훈련 접근법과 아키텍처 매개변수화를 채택하여 다양한 혼합 모달 작업에서 최첨단 성능을 달성했습니다. 특히, 이미지 캡션과 긴 형식의 혼합 모달 생성에서 뛰어난 결과를 보였으며, 기존 모델들과 경쟁하면서 텍스트 전용 작업에서는 Llama-2를 능가하는 성능을 보였습니다. 카멜레온은 멀티모달 문서의 통합 모델링 분야에서 중요한 진전을 이루었으며, 사람의 직접 평가에서도 큰 모델들과 동등하거나 그 이상의 성능을 입증했습니다.
Paper page - Chameleon: Mixed-Modal Early-Fusion Foundation Models (huggingface.co)

2. 더 적게 배우고 더 적게 잊어버리는 LoRA에 대한 추가 연구
낮은 순위 적응(LoRA)은 대규모 언어 모델의 매개변수 효율적인 미세 조정 방법으로, 메모리 절감을 위해 선택된 가중치 행렬에 낮은 순위의 섭동만을 훈련합니다. 프로그래밍과 수학 도메인에서의 실험을 통해 LoRA는 전체 미세 조정 방법에 비해 일반적으로 성능이 낮은 것으로 나타났지만, 목표 도메인 외의 작업에서 기본 모델의 성능을 더 잘 유지하는 강력한 정규화 혜택을 제공합니다. 또한, LoRA는 가중치 붕괴와 드롭아웃에 비해 다양한 생성을 더 잘 유지하는 데 도움이 됩니다. 이 연구는 LoRA를 사용한 미세 조정의 모범 사례를 제시하며, 이는 미세 조정에서 격차를 줄이는 데 기여할 수 있습니다.
Paper page - LoRA Learns Less and Forgets Less (huggingface.co)
-
🦸‍♂️ 오늘의 SW 스피드웨건
 1. Flutter 3.22의 새로운 기능
Flutter 3.22에서는 WebAssembly의 안정 채널 도입과 함께 Vulkan 백엔드를 완성하여 안드로이드에서 더 부드러운 그래픽과 성능 향상을 제공합니다. 새로운 위젯 상태 속성, 동적 뷰 크기 조정, 향상된 폼 유효성 검사 기능도 추가되었습니다. 다양한 기능들이 포함된 이번 업데이트를 통해 Flutter 개발자들은 더 강력하고 유연한 앱을 제작할 수 있게 되었습니다. 최신 버전으로 업그레이드하여 새로운 기능들을 경험해 보시기 바랍니다.
https://medium.com/flutter/whats-new-in-flutter-3-22-fbde6c164fe3

2. Flutter, React Native, Ionic으로 동일한 앱을 빌드 경험.
Flutter, React Native, Ionic 세 가지 프레임워크를 비교한 결과, Flutter는 빠른 Hot Reload와 네이티브 성능을 제공하지만 코드 중첩이 복잡했습니다. React Native는 간결한 코드와 모듈화가 장점이지만 설정이 까다로웠고, 이미지 표시 문제도 있었습니다. Ionic은 익숙한 웹 기술로 빠르게 개발할 수 있었고, UI 컴포넌트가 풍부하며 문서화도 잘 되어 있었습니다. 앱 크기와 성능 면에서 Flutter가 우세했고, React Native는 설치된 상위 앱에서 높은 비율을 차지했습니다. 각 프레임워크는 장단점이 있어 프로젝트에 맞는 선택이 중요합니다.
https://news.hada.io/topic?id=14893
-
💻 오름캠프 Django 백엔드 개발 온라인 과정 ► https://bit.ly/3UdtWej

모두의연구소는 지식을 나누며 함께 성장하는 국내 최대 SW/AI 커뮤니티입니다. 🤵‍♂️ 빠르다 빨라 AI 세상<ol ><li>Chameleon: 멀티 모달 작업을 위한 초기 융합 토큰 기반 모델의 개발 및 성능 평가</li></ol>카멜레온은 이미지와 텍스트를 포함한 임의의 시퀀스를 이해하고 생성할 수 있는 초기 융합 토큰 기반의 혼합 모달 모델 제품군입니다. 이 모델은 안정적인 훈련 접근법과 아키텍처 매개변수화를 채택하여 다양한 혼합 모달 작업에서 최첨단 성능을 달성했습니다. 특히, 이미지 캡션과 긴 형식의 혼합 모달 생성에서 뛰어난 결과를 보였으며, 기존 모델들과 경쟁하면서 텍스트 전용 작업에서는 Llama-2를 능가하는 성능을 보였습니다. 카멜레온은 멀티모달 문서의 통합 모델링 분야에서 중요한 진전을 이루었으며, 사람의 직접 평가에서도 큰 모델들과 동등하거나 그 이상의 성능을 입증했습니다. Paper page - Chameleon: Mixed-Modal Early-Fusion Foundation Models (huggingface.co) 2. 더 적게 배우고 더 적게 잊어버리는 LoRA에 대한 추가 연구 낮은 순위 적응(LoRA)은 대규모 언어 모델의 매개변수 효율적인 미세 조정 방법으로, 메모리 절감을 위해 선택된 가중치 행렬에 낮은 순위의 섭동만을 훈련합니다. 프로그래밍과 수학 도메인에서의 실험을 통해 LoRA는 전체 미세 조정 방법에 비해 일반적으로 성능이 낮은 것으로 나타났지만, 목표 도메인 외의 작업에서 기본 모델의 성능을 더 잘 유지하는 강력한 정규화 혜택을 제공합니다. 또한, LoRA는 가중치 붕괴와 드롭아웃에 비해 다양한 생성을 더 잘 유지하는 데 도움이 됩니다. 이 연구는 LoRA를 사용한 미세 조정의 모범 사례를 제시하며, 이는 미세 조정에서 격차를 줄이는 데 기여할 수 있습니다. Paper page - LoRA Learns Less and Forgets Less (huggingface.co)- 🦸‍♂️ 오늘의 SW 스피드웨건<ol ><li>Flutter 3.22의 새로운 기능</li></ol>Flutter 3.22에서는 WebAssembly의 안정 채널 도입과 함께 Vulkan 백엔드를 완성하여 안드로이드에서 더 부드러운 그래픽과 성능 향상을 제공합니다. 새로운 위젯 상태 속성, 동적 뷰 크기 조정, 향상된 폼 유효성 검사 기능도 추가되었습니다. 다양한 기능들이 포함된 이번 업데이트를 통해 Flutter 개발자들은 더 강력하고 유연한 앱을 제작할 수 있게 되었습니다. 최신 버전으로 업그레이드하여 새로운 기능들을 경험해 보시기 바랍니다. https://medium.com/flutter/whats-new-in-flutter-3-22-fbde6c164fe3 2. Flutter, React Native, Ionic으로 동일한 앱을 빌드 경험. Flutter, React Native, Ionic 세 가지 프레임워크를 비교한 결과, Flutter는 빠른 Hot Reload와 네이티브 성능을 제공하지만 코드 중첩이 복잡했습니다. React Native는 간결한 코드와 모듈화가 장점이지만 설정이 까다로웠고, 이미지 표시 문제도 있었습니다. Ionic은 익숙한 웹 기술로 빠르게 개발할 수 있었고, UI 컴포넌트가 풍부하며 문서화도 잘 되어 있었습니다. 앱 크기와 성능 면에서 Flutter가 우세했고, React Native는 설치된 상위 앱에서 높은 비율을 차지했습니다. 각 프레임워크는 장단점이 있어 프로젝트에 맞는 선택이 중요합니다. https://news.hada.io/topic?id=14893- 💻 오름캠프 Django 백엔드 개발 온라인 과정 ► https://bit.ly/3UdtWej&nbsp;

Huggingface

[240520] 모두의연구소가 전하는 “모두를 위한 SW/AI 뉴스”

Uncover the 11 major barriers to AI adoption and learn effective strategies to overcome them, enhancing efficiency and innovation in your organization.

11 Barriers To Effective AI Adoption And How To Overcome Them

오늘날의 디지털 시대에 인공지능(AI)은 다양한 분야에서 혁신의 힘으로 부상하고 있습니다. 그러나 AI의 엄청난 잠재력에도 불구하고 많은 조직이 AI 기술을 효과적으로 도입하고 통합하는 데 어려움을 겪고 있습니다.

이 글에서는 기업이 AI의 잠재력을 최대한 활용하는 데 방해가 되는 11가지 장애물을 살펴보고 이러한 장애물을 극복하여 성공적인 구현과 통합을 위한 실용적인 전략을 제시합니다.

1. 리더십 관성
AI 기반 운영으로의 전환은 기업의 리더십에서 시작되어야 합니다. 그러나 경영진이 기존 관행에서 벗어나기를 꺼려하고 디지털 혁신을 회의적으로 바라볼 때 상당한 장벽이 발생합니다. 이러한 관성은 조직의 디지털 트랜스포메이션 여정을 지연시킬 수 있습니다.
 * 이를 극복하기 위해서는 리더가 미래 지향적인 사고방식을 채택하는 것이 필수적입니다.
 * 성공적인 AI 구현 사례를 접하고 디지털 변화를 수용한 동료들과 교류하면 주저하는 리더가 자신의 입장을 재평가하고 조직 내에서 AI 이니셔티브를 옹호하도록 영감을 줄 수 있습니다.

2. 미지에 대한 두려움
AI 기술은 종종 미지의 영역으로의 도약을 의미하며, 이러한 불확실성은 특히 일자리 이동과 조직 혁신에 대한 두려움을 유발할 수 있습니다.
 * 이러한 우려를 해소하기 위해서는 투명한 환경을 조성하는 것이 중요합니다.
 * AI가 인간의 업무를 대체하는 것이 아니라 보완할 수 있다는 점을 직원들에게 교육하고 의사 결정 및 운영 효율성을 향상시키는 데 있어 AI의 역할을 입증하면 두려움을 완화하고 AI 기술에 대한 조직의 신뢰를 구축할 수 있습니다.

3. AI의 잠재력에 대한 이해 부족
많은 사람들에게 AI는 현재 사용할 수 있는 실용적인 도구라기보다는 미래형 애플리케이션과 관련된 유행어로 남아 있습니다. 이러한 단절은 AI 도입을 방해합니다.
 * 조직은 AI의 실질적인 이점을 강조하고 실제 적용 사례를 보여주는 워크샵과 세미나를 개최하여 이러한 격차를 해소할 수 있습니다.
 * 이러한 이니셔티브는 AI를 이해하고 일상적인 비즈니스 문제를 해결하는 데 있어 AI의 가치를 설명함으로써 AI의 잠재력에 대한 더 깊은 이해와 열정을 촉진하는 데 도움이 됩니다.

4. 데이터 가용성 및 품질
AI 시스템은 데이터를 기반으로 작동하지만, 데이터의 가용성과 품질이 제한 요소가 될 수 있습니다. 부정확하거나 액세스하기 어려운 데이터는 가장 진보된 AI 모델도 약화시킬 수 있습니다.
 * 포괄적인 데이터 거버넌스 전략을 수립하는 것이 중요합니다.
 * 엄격한 데이터 품질 관리를 구현하고 데이터 정리 및 보강을 강화하는 기술에 투자함으로써 기업은 AI 이니셔티브의 성공에 필요한 고품질 데이터를 제공할 수 있습니다.

5. 기술 부족
AI 기술에 대한 수요가 공급을 초과하는 경우가 많기 때문에 기업은 경쟁에서 불리한 위치에 놓이게 됩니다.
 * 이를 극복하기 위해 기업은 기존 인력을 양성하기 위한 사내 교육 프로그램을 개발하는 동시에 교육 기관과 파트너십을 맺는 것도 고려해야 합니다.
 * 또한 특정 AI 기능을 아웃소싱하면 단기간에 필요한 기술을 확보할 수 있어 내부 전문성 부족으로 인해 AI 프로젝트가 지연되는 것을 방지할 수 있습니다.

6. 레거시 시스템과의 통합 과제
오래된 레거시 시스템에 AI를 통합하는 것은 상당한 기술적 문제를 야기할 수 있습니다.
 * 이러한 문제는 보다 원활하고 점진적인 통합 프로세스를 촉진하는 API와 미들웨어의 전략적 사용을 통해 해결할 수 있습니다.
 * 이러한 접근 방식을 통해 조직은 많은 비용과 혼란을 초래하는 IT 인프라를 전면 개편할 필요 없이 AI의 이점을 활용할 수 있습니다.

7. 윤리적 및 법적 고려 사항
AI는 개인정보 보호, 데이터 보안, 의사 결정 편향에 대한 우려 등 고유한 윤리적, 법적 과제를 안고 있습니다.
 * 이러한 문제를 해결하기 위해 기업은 엄격한 AI 윤리 정책을 수립하고 준수하며 모든 관련 법률과 규정을 준수해야 합니다.
 * 이러한 사전 예방적 자세는 AI 배포와 관련된 잠재적인 법적 및 평판 위험을 예방하는 데 도움이 됩니다.

8. 비용
AI 도입의 초기 비용은 기술, 인재, 교육에 대한 지출을 포함하여 막대한 비용이 소요될 수 있습니다.
 * 단계적 투자 방식을 채택하면 이러한 비용을 줄일 수 있습니다.
 * 소규모 파일럿 프로젝트부터 시작하면 AI의 투자 수익을 입증하고 입증된 이점과 습득한 학습을 바탕으로 전략적으로 지출을 확장할 수 있습니다.

9. 전략적 접근의 부재
일관된 전략 없이 AI에 접근하는 것은 지도 없이 길을 찾는 것과 같습니다.
 * AI를 효과적으로 구현하려면 조직은 AI 이니셔티브를 보다 광범위한 비즈니스 목표와 연계하는 명확하고 전략적인 계획을 개발해야 합니다.
 * 이 전략에는 정의된 목표, 성과 지표, 지속적인 평가 및 적응을 위한 프레임워크가 포함되어야 합니다.

10. AI 이니셔티브 확장의 어려움
파일럿 프로그램에서 더 광범위한 조직 적용으로 AI를 확장하는 것은 여전히 어려운 과제입니다.
 * 확장성을 보장하려면 전사적으로 AI 도구와 방법론을 표준화하는 동시에 다양한 부서의 요구 사항을 충족할 수 있도록 커스터마이징하는 것이 중요합니다.
 * 이러한 균형 잡힌 접근 방식은 더 광범위한 채택을 촉진하고 조직 전반에 걸쳐 AI 기술의 영향력을 극대화합니다.

11. 혁신 문화 부족
혁신에 저항하는 조직 문화는 AI 이니셔티브를 크게 방해할 수 있습니다.
 * 실험을 중시하고 실패를 용인하는 문화를 조성하는 것은 혁신을 촉진하고 AI의 이점을 수용하는 데 필수적입니다.
 * 이러한 문화적 변화는 직원들이 주도권을 갖고 새로운 아이디어를 탐색할 수 있도록 지원하여 조직의 전반적인 디지털 트랜스포메이션 역량을 강화할 수 있습니다.

 * source: https://www.forbes.com/sites/bernardmarr/2024/05/10/11-barriers-to-effective-ai-adoption-and-how-to-overcome-them/?sh=788f819e27d3

오늘날의 디지털 시대에 인공지능(AI)은 다양한 분야에서 혁신의 힘으로 부상하고 있습니다. 그러나 AI의 엄청난 잠재력에도 불구하고 많은 조직이 AI 기술을 효과적으로 도입하고 통합하는 데 어려움을 겪고 있습니다. 이 글에서는 기업이 AI의 잠재력을 최대한 활용하는 데 방해가 되는 11가지 장애물을 살펴보고 이러한 장애물을 극복하여 성공적인 구현과 통합을 위한 실용적인 전략을 제시합니다. 1. 리더십 관성AI 기반 운영으로의 전환은 기업의 리더십에서 시작되어야 합니다. 그러나 경영진이 기존 관행에서 벗어나기를 꺼려하고 디지털 혁신을 회의적으로 바라볼 때 상당한 장벽이 발생합니다. 이러한 관성은 조직의 디지털 트랜스포메이션 여정을 지연시킬 수 있습니다. <ul ><li>이를 극복하기 위해서는 리더가 미래 지향적인 사고방식을 채택하는 것이 필수적입니다. </li><li>성공적인 AI 구현 사례를 접하고 디지털 변화를 수용한 동료들과 교류하면 주저하는 리더가 자신의 입장을 재평가하고 조직 내에서 AI 이니셔티브를 옹호하도록 영감을 줄 수 있습니다.</li></ul> 2. 미지에 대한 두려움AI 기술은 종종 미지의 영역으로의 도약을 의미하며, 이러한 불확실성은 특히 일자리 이동과 조직 혁신에 대한 두려움을 유발할 수 있습니다. <ul ><li>이러한 우려를 해소하기 위해서는 투명한 환경을 조성하는 것이 중요합니다. </li><li>AI가 인간의 업무를 대체하는 것이 아니라 보완할 수 있다는 점을 직원들에게 교육하고 의사 결정 및 운영 효율성을 향상시키는 데 있어 AI의 역할을 입증하면 두려움을 완화하고 AI 기술에 대한 조직의 신뢰를 구축할 수 있습니다.</li></ul> 3. AI의 잠재력에 대한 이해 부족많은 사람들에게 AI는 현재 사용할 수 있는 실용적인 도구라기보다는 미래형 애플리케이션과 관련된 유행어로 남아 있습니다. 이러한 단절은 AI 도입을 방해합니다. <ul ><li>조직은 AI의 실질적인 이점을 강조하고 실제 적용 사례를 보여주는 워크샵과 세미나를 개최하여 이러한 격차를 해소할 수 있습니다. </li><li>이러한 이니셔티브는 AI를 이해하고 일상적인 비즈니스 문제를 해결하는 데 있어 AI의 가치를 설명함으로써 AI의 잠재력에 대한 더 깊은 이해와 열정을 촉진하는 데 도움이 됩니다.</li></ul> 4. 데이터 가용성 및 품질AI 시스템은 데이터를 기반으로 작동하지만, 데이터의 가용성과 품질이 제한 요소가 될 수 있습니다. 부정확하거나 액세스하기 어려운 데이터는 가장 진보된 AI 모델도 약화시킬 수 있습니다. <ul ><li>포괄적인 데이터 거버넌스 전략을 수립하는 것이 중요합니다. </li><li>엄격한 데이터 품질 관리를 구현하고 데이터 정리 및 보강을 강화하는 기술에 투자함으로써 기업은 AI 이니셔티브의 성공에 필요한 고품질 데이터를 제공할 수 있습니다.</li></ul> 5. 기술 부족AI 기술에 대한 수요가 공급을 초과하는 경우가 많기 때문에 기업은 경쟁에서 불리한 위치에 놓이게 됩니다. <ul ><li>이를 극복하기 위해 기업은 기존 인력을 양성하기 위한 사내 교육 프로그램을 개발하는 동시에 교육 기관과 파트너십을 맺는 것도 고려해야 합니다. </li><li>또한 특정 AI 기능을 아웃소싱하면 단기간에 필요한 기술을 확보할 수 있어 내부 전문성 부족으로 인해 AI 프로젝트가 지연되는 것을 방지할 수 있습니다.</li></ul> 6. 레거시 시스템과의 통합 과제오래된 레거시 시스템에 AI를 통합하는 것은 상당한 기술적 문제를 야기할 수 있습니다. <ul ><li>이러한 문제는 보다 원활하고 점진적인 통합 프로세스를 촉진하는 API와 미들웨어의 전략적 사용을 통해 해결할 수 있습니다. </li><li>이러한 접근 방식을 통해 조직은 많은 비용과 혼란을 초래하는 IT 인프라를 전면 개편할 필요 없이 AI의 이점을 활용할 수 있습니다.</li></ul> 7. 윤리적 및 법적 고려 사항AI는 개인정보 보호, 데이터 보안, 의사 결정 편향에 대한 우려 등 고유한 윤리적, 법적 과제를 안고 있습니다. <ul ><li>이러한 문제를 해결하기 위해 기업은 엄격한 AI 윤리 정책을 수립하고 준수하며 모든 관련 법률과 규정을 준수해야 합니다. </li><li>이러한 사전 예방적 자세는 AI 배포와 관련된 잠재적인 법적 및 평판 위험을 예방하는 데 도움이 됩니다.</li></ul> 8. 비용AI 도입의 초기 비용은 기술, 인재, 교육에 대한 지출을 포함하여 막대한 비용이 소요될 수 있습니다. <ul ><li>단계적 투자 방식을 채택하면 이러한 비용을 줄일 수 있습니다. </li><li>소규모 파일럿 프로젝트부터 시작하면 AI의 투자 수익을 입증하고 입증된 이점과 습득한 학습을 바탕으로 전략적으로 지출을 확장할 수 있습니다.</li></ul> 9. 전략적 접근의 부재일관된 전략 없이 AI에 접근하는 것은 지도 없이 길을 찾는 것과 같습니다. <ul ><li>AI를 효과적으로 구현하려면 조직은 AI 이니셔티브를 보다 광범위한 비즈니스 목표와 연계하는 명확하고 전략적인 계획을 개발해야 합니다. </li><li>이 전략에는 정의된 목표, 성과 지표, 지속적인 평가 및 적응을 위한 프레임워크가 포함되어야 합니다.</li></ul> 10. AI 이니셔티브 확장의 어려움파일럿 프로그램에서 더 광범위한 조직 적용으로 AI를 확장하는 것은 여전히 어려운 과제입니다. <ul ><li>확장성을 보장하려면 전사적으로 AI 도구와 방법론을 표준화하는 동시에 다양한 부서의 요구 사항을 충족할 수 있도록 커스터마이징하는 것이 중요합니다. </li><li>이러한 균형 잡힌 접근 방식은 더 광범위한 채택을 촉진하고 조직 전반에 걸쳐 AI 기술의 영향력을 극대화합니다.</li></ul> 11. 혁신 문화 부족혁신에 저항하는 조직 문화는 AI 이니셔티브를 크게 방해할 수 있습니다. <ul ><li>실험을 중시하고 실패를 용인하는 문화를 조성하는 것은 혁신을 촉진하고 AI의 이점을 수용하는 데 필수적입니다. </li><li>이러한 문화적 변화는 직원들이 주도권을 갖고 새로운 아이디어를 탐색할 수 있도록 지원하여 조직의 전반적인 디지털 트랜스포메이션 역량을 강화할 수 있습니다.</li></ul> <ul ><li>source: https://www.forbes.com/sites/bernardmarr/2024/05/10/11-barriers-to-effective-ai-adoption-and-how-to-overcome-them/?sh=788f819e27d3</li></ul>

Forbes

효과적인 AI 도입을 가로막는 11가지 장벽과 이를 극복하는 방법

인프런이 만드는 IT인의 축제, 인프콘에 초대합니다

인프콘 2024 - INFCON 2024

1. INFCON
- https://www.inflearn.com/conf/infcon-2024/
- ‘인프런’에서 주최하는 IT 컨퍼런스. 개발자, PM/PO, 디자이너 분야 등
- 2024년 8월 2일(금)
- 유료 / 참가 신청 마감. 추후 인프콘 다시보기 서비스 제공 예정

2. UbuCon Korea 2024
- https://2024.ubuntu-kr.org/ko/
- Ubuntu 코리아 컨퍼런스
- 2024년 8월 10일(토)
- 유료

3. FEConf24
- https://2024.feconf.kr/
- 국내 최대 프론트엔드 컨퍼런스
- 2024년 8월 24일(토)
- 유료

4. Kubernetes Korea Community Day 2024
- https://kcd-korea.net/
- 쿠버네티스에서 주최하는 국내 클라우드 네이티브 기술 컨퍼런스
- 2024년 9월 24일(화)
- 유료

5. OpenInfra Summit Asia 2024
- https://2024.openinfraasia.org/
- 클라우드 네이티브 오픈소스 기술 재단 ‘오픈인프라’ 컨퍼런스
- 2024년 9월 3일(화) ~ 9월 4일(수)
- 유료

6. KWDC 2024
- https://kwdc.dev/2024/
- 국내 애플 개발자 커뮤니티 3곳이 주최하는 한국 Apple 생태계 컨퍼런스
- 2024년 10월 24일(목)
- 유료

7. PyCon KR 2024
- https://2024.pycon.kr/
- 세계 각국의 파이썬 프로그래밍 언어 커뮤니티에서 주관하는 컨퍼런스
- 2024년 10월 25일(금) ~ 10월 27일(일)
- 유료

8. DebConf24
- https://debconf24.debconf.org/
- 데비안 운영체제, 소프트웨어 개발과 관련한 세미나
- 2024년 7월 28일(일) ~ 8월 4일(일)
- 유·무료(일반 무료, 전문가/기업 유료)

9. GopherCon Korea 2024
- https://festa.io/events/5098
- 한국의 Go 언어 사용자 모임 커뮤니티에서 주최하는 컨퍼런스
- 2024년 10월 12일(토) ~ 10월 13일(일)
- 유료

해외 컨퍼런스
1. GitHub Universe 2024
- https://githubuniverse.com/
- 2024년 10월 29일(화) ~ 10월 30일(수) / 미국 샌프란시스코
- 유료 / 온라인 라이브 스트리밍 무료

2. KubeCon + CloudNativeCon North America
- https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/
- 2024년 11월 12일(화) ~ 11월 15일(금) / 미국 유타주 솔트레이크시티
- 유료 / 키노트 라이브 스트리밍 무료

3. AWS re:Invent 2024
- https://reinvent.awsevents.com/
- 2024년 12월 2일(월) ~ 12월 6일(금) / 미국 라스베가스
- 유료 / 온라인 라이브 스트리밍 무료

1. INFCON- https://www.inflearn.com/conf/infcon-2024/- ‘인프런’에서 주최하는 IT 컨퍼런스. 개발자, PM/PO, 디자이너 분야 등- 2024년 8월 2일(금)- 유료 / 참가 신청 마감. 추후 인프콘 다시보기 서비스 제공 예정 2. UbuCon Korea 2024- https://2024.ubuntu-kr.org/ko/- Ubuntu 코리아 컨퍼런스- 2024년 8월 10일(토)- 유료 3. FEConf24- https://2024.feconf.kr/- 국내 최대 프론트엔드 컨퍼런스- 2024년 8월 24일(토)- 유료 4. Kubernetes Korea Community Day 2024- https://kcd-korea.net/- 쿠버네티스에서 주최하는 국내 클라우드 네이티브 기술 컨퍼런스- 2024년 9월 24일(화)- 유료 5. OpenInfra Summit Asia 2024- https://2024.openinfraasia.org/- 클라우드 네이티브 오픈소스 기술 재단 ‘오픈인프라’ 컨퍼런스- 2024년 9월 3일(화) ~ 9월 4일(수)- 유료 6. KWDC 2024- https://kwdc.dev/2024/- 국내 애플 개발자 커뮤니티 3곳이 주최하는 한국 Apple 생태계 컨퍼런스- 2024년 10월 24일(목)- 유료 7. PyCon KR 2024- https://2024.pycon.kr/- 세계 각국의 파이썬 프로그래밍 언어 커뮤니티에서 주관하는 컨퍼런스- 2024년 10월 25일(금) ~ 10월 27일(일)- 유료 8. DebConf24- https://debconf24.debconf.org/- 데비안 운영체제, 소프트웨어 개발과 관련한 세미나- 2024년 7월 28일(일) ~ 8월 4일(일)- 유·무료(일반 무료, 전문가/기업 유료) 9. GopherCon Korea 2024- https://festa.io/events/5098- 한국의 Go 언어 사용자 모임 커뮤니티에서 주최하는 컨퍼런스- 2024년 10월 12일(토) ~ 10월 13일(일)- 유료 해외 컨퍼런스1. GitHub Universe 2024- https://githubuniverse.com/- 2024년 10월 29일(화) ~ 10월 30일(수) / 미국 샌프란시스코- 유료 / 온라인 라이브 스트리밍 무료 2. KubeCon + CloudNativeCon North America- https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/- 2024년 11월 12일(화) ~ 11월 15일(금) / 미국 유타주 솔트레이크시티- 유료 / 키노트 라이브 스트리밍 무료 3. AWS re:Invent 2024- https://reinvent.awsevents.com/- 2024년 12월 2일(월) ~ 12월 6일(금) / 미국 라스베가스- 유료 / 온라인 라이브 스트리밍 무료

인프런

2024 하반기 IT 컨퍼런스

이력서는 중요합니다.
면접관에게는 지원자를 파악하기 위한 첫번째 장소이기 때문입니다.

이런 이력서 작성을 편리하게 도와주는 사이트가 있어서 소개드립니다.
resumemaker.online 인데요.

기존에 작성한 이력서가 있다면 업로드해서 AI가 초안을 작성해주기도 합니다.
컬러나 템플릿등을 설정할 수 도 있고, 꽤 정돈된 형태로 이력서가 나오게 됩니다.

한가지 단점은 한글 폰트를 지원하지 않습니다.
그래도 이력서 작성을 별로 해보시지 않았다면 툴의 도움을 받아서 채워보시는
것도 좋을 것 같습니다.

제가 기존에 써둔 이력서를 업로드 해서 만들어봤는데 퀄리티가 나쁘지 않네요.

이력서는 중요합니다.면접관에게는 지원자를 파악하기 위한 첫번째 장소이기 때문입니다. 이런 이력서 작성을 편리하게 도와주는 사이트가 있어서 소개드립니다.resumemaker.online 인데요. 기존에 작성한 이력서가 있다면 업로드해서 AI가 초안을 작성해주기도 합니다.컬러나 템플릿등을 설정할 수 도 있고, 꽤 정돈된 형태로 이력서가 나오게 됩니다. 한가지 단점은 한글 폰트를 지원하지 않습니다.그래도 이력서 작성을 별로 해보시지 않았다면 툴의 도움을 받아서 채워보시는것도 좋을 것 같습니다. 제가 기존에 써둔 이력서를 업로드 해서 만들어봤는데 퀄리티가 나쁘지 않네요.

이력서를 편하게 만듭시다 - resumemaker

I finally have the feeling that I&rsquo;m a decent programmer, so I thought it would be fun to write some advice with the idea of &ldquo;what would have gotten me to this point faster?&rdquo; I&rsquo;m not claiming this is great advice for everyone, just 

Marcus' Blog


한 개발자가 과거의 나에게 개발자로써 조언을 해준다면? 에 대해 작성해주신 글입니다.
몇 가지는 직접적으로 저에게 도움이 되는 부분도 있어, 일부 저에게 도움되는 부분만 요약해서 공유드립니다.

🤔 계속 발에 총을 쏘고 있다면, 총을 고쳐야한다.
팀에서 시스템에 대해 자주 실수 하는 부분이 있지만, 그 실수를 줄일 방법에 대해 생각하지 않는 경우가 많습니다. 이런 경우 시스템을 개선하여 실수를 줄이는 것이 중요합니다.
이러한 문제들은 해결할 자연스러운 시기가 없었기에 오래 지속되는 경우가 많으니, 생각보다 몇 분 동안만 고민하면 해결 할 수 있는게 많습니다. 이런 문제가 있을 때 자신과 팀의 삶을 더 쉽게 만들 수 있다는 것을 상기시키고 마음가짐을 갖는게 중요합니다.

🪠 품질과 속도 사이의 균형을 맞춰야한다.
구현 속도와 정확성에 대한 자신감 사이에는 항상 트레이드오프가 존재합니다. 현재 상황에서 버그를 출시하는 것이 얼마나 괜찮은지 자문해보고, 이에 대한 답변이 작업 방식에 영향을 미치지 않는다면 지나치게 경직된 것으로 생각하세요.

🪭 톱을 갈고 있는 시간은 거의 항상 가치가 있는 시간이다.
도구를 잘 다루는 것이 중요합니다. 코드를 빠르게 작성하고, 주요 단축키를 알고, 운영체제와 셀에 능숙해야 합니다. 새로운 엔지니어에게서 보이는 가장 큰 그린 플래그 중 하나는 도구 선택과 능숙한 사용에 대한 관심입니다.

🧘🏻‍♂️버그를 한 층 더 깊이 해결하려고 노력해야 한다.
버그를 표면적으로 해결하는 대신, 근본적인 원인을 찾아 해결하는 것이 중요합니다. 최대한 어떤 컴포넌트도 이 버그를 다시 겪지 않도록 해결하려고 노력해보세요.

🏃🏻‍♀️ 버그 조사 시 히스토리를 활용해야 한다.
이상한 버그를 조사할 때, git 히스토리를 활용하는 것이 중요합니다. 예를 들어 메모리 누수 문제를 조사할 때, 특정 커밋 이후에 문제가 발생한 경우가 많으니 참고하세요.

🎆 가끔은 나쁜 코드로 작성하는 쪽으로 오류를 범해봐라.
끔찍한 코드를 작성하는 것도 쉽고, 모든 모범사례를 절대적으로 따르는 코드를 작성하는 것도 정말 쉽습니다. 하지만 이런 코드 작성은 스타트업에 돈이 바닥 날 가능성이 큽니다.
또한 빨리 코드를 작성하게 되면 추후 나쁜 기술 부채로 인해 곤란을 겪게 될 수도 있습니다.
'나쁜' 코드의 의미를 명확하게 하고, 시간과 노력의 균형을 찾아 코드를 작성해보세요.

🏋️ 디버깅 하기 쉽게 만들어야 한다.
디버깅을 쉽게 하기 위한 노력을 하지 않으면, 소프트웨어가 점점 더 복잡해짐에 따라 각 이슈를 디버깅 하는데 엄청난 시간을 소비하게 될 것 입니다. 그렇게 되면 결국 변경 하는 것이 두려워지게 됩니다. 디버깅 시간 중 설정, 재현, 사후 정리에 소요되는 시간을 추적하는 데 주의를 기울이세요.

💁‍♂️ 팀에서 일할 때는 보통 질문을 해야 한다.
경력 초반자들은 '사소한 질문으로 동료를 귀찮게 하는 것' 보다 '모든 것을 스스로 알아내려고 노력하는 것'에 너무 치우쳐 있습니다. 한 시간 넘게 무언가를 알아내기 위해 시간을 허비하지말고 몇 분 만에 답을 찾을 수 있게 항상 질문하세요. 누군가에게 귀찮은 경우는 몇 분 안에 스스로 답을 찾을 수 있었다는 것이 분명할 때 뿐입니다.

👁️ 배포 주기는 매우 중요, 빠르고 자주 배포할 수 있는 방법 고민 필요
프로젝트 배포 속도는 시간이 지남에 따라 복리로 증가해서, 상상할 수 있는 것보다 빠르게 기능을 배포할 수 있게 됩니다. 스타트업은 런웨이가 제한적이고, 프로젝트에는 마감일이 항상 있으니 빠르게 배포하기 위해 여러가지 시도를 해보세요.

한 개발자가 과거의 나에게 개발자로써 조언을 해준다면? 에 대해 작성해주신 글입니다. 몇 가지는 직접적으로 저에게 도움이 되는 부분도 있어, 일부 저에게 도움되는 부분만 요약해서 공유드립니다. 🤔 계속 발에 총을 쏘고 있다면, 총을 고쳐야한다. 팀에서 시스템에 대해 자주 실수 하는 부분이 있지만, 그 실수를 줄일 방법에 대해 생각하지 않는 경우가 많습니다. 이런 경우 시스템을 개선하여 실수를 줄이는 것이 중요합니다. 이러한 문제들은 해결할 자연스러운 시기가 없었기에 오래 지속되는 경우가 많으니, 생각보다 몇 분 동안만 고민하면 해결 할 수 있는게 많습니다. 이런 문제가 있을 때 자신과 팀의 삶을 더 쉽게 만들 수 있다는 것을 상기시키고 마음가짐을 갖는게 중요합니다. 🪠 품질과 속도 사이의 균형을 맞춰야한다.구현 속도와 정확성에 대한 자신감 사이에는 항상 트레이드오프가 존재합니다. 현재 상황에서 버그를 출시하는 것이 얼마나 괜찮은지 자문해보고, 이에 대한 답변이 작업 방식에 영향을 미치지 않는다면 지나치게 경직된 것으로 생각하세요. 🪭 톱을 갈고 있는 시간은 거의 항상 가치가 있는 시간이다.도구를 잘 다루는 것이 중요합니다. 코드를 빠르게 작성하고, 주요 단축키를 알고, 운영체제와 셀에 능숙해야 합니다. 새로운 엔지니어에게서 보이는 가장 큰 그린 플래그 중 하나는 도구 선택과 능숙한 사용에 대한 관심입니다. 🧘🏻‍♂️버그를 한 층 더 깊이 해결하려고 노력해야 한다.버그를 표면적으로 해결하는 대신, 근본적인 원인을 찾아 해결하는 것이 중요합니다. 최대한 어떤 컴포넌트도 이 버그를 다시 겪지 않도록 해결하려고 노력해보세요. 🏃🏻‍♀️ 버그 조사 시 히스토리를 활용해야 한다.이상한 버그를 조사할 때, git 히스토리를 활용하는 것이 중요합니다. 예를 들어 메모리 누수 문제를 조사할 때, 특정 커밋 이후에 문제가 발생한 경우가 많으니 참고하세요. 🎆 가끔은 나쁜 코드로 작성하는 쪽으로 오류를 범해봐라.끔찍한 코드를 작성하는 것도 쉽고, 모든 모범사례를 절대적으로 따르는 코드를 작성하는 것도 정말 쉽습니다. 하지만 이런 코드 작성은 스타트업에 돈이 바닥 날 가능성이 큽니다. 또한 빨리 코드를 작성하게 되면 추후 나쁜 기술 부채로 인해 곤란을 겪게 될 수도 있습니다.'나쁜' 코드의 의미를 명확하게 하고, 시간과 노력의 균형을 찾아 코드를 작성해보세요. 🏋️ 디버깅 하기 쉽게 만들어야 한다.디버깅을 쉽게 하기 위한 노력을 하지 않으면, 소프트웨어가 점점 더 복잡해짐에 따라 각 이슈를 디버깅 하는데 엄청난 시간을 소비하게 될 것 입니다. 그렇게 되면 결국 변경 하는 것이 두려워지게 됩니다. 디버깅 시간 중 설정, 재현, 사후 정리에 소요되는 시간을 추적하는 데 주의를 기울이세요. 💁‍♂️ 팀에서 일할 때는 보통 질문을 해야 한다.경력 초반자들은 '사소한 질문으로 동료를 귀찮게 하는 것' 보다 '모든 것을 스스로 알아내려고 노력하는 것'에 너무 치우쳐 있습니다. 한 시간 넘게 무언가를 알아내기 위해 시간을 허비하지말고 몇 분 만에 답을 찾을 수 있게 항상 질문하세요. 누군가에게 귀찮은 경우는 몇 분 안에 스스로 답을 찾을 수 있었다는 것이 분명할 때 뿐입니다. 👁️ 배포 주기는 매우 중요, 빠르고 자주 배포할 수 있는 방법 고민 필요프로젝트 배포 속도는 시간이 지남에 따라 복리로 증가해서, 상상할 수 있는 것보다 빠르게 기능을 배포할 수 있게 됩니다. 스타트업은 런웨이가 제한적이고, 프로젝트에는 마감일이 항상 있으니 빠르게 배포하기 위해 여러가지 시도를 해보세요.

mbuffett.com

15년 전 나에게 해주고 싶은 프로그래밍 조언

컴퓨터 공부를 처음 시작한 날이 2004년 8월 25일. 이제 20년이 지났습니다.

죽을 만큼 힘든 날은 없었다

컴퓨터 공부를 처음 시작한 날이 2004년 8월 25일.
이제 20년이 지났습니다.

돌아보면 그렇게 쉽진 않았지만 또 그렇게 어렵지도 않았던 것 같습니다.

매일 조금씩 힘들고 피곤하긴 했지만..
죽을 만큼 힘들다고 생각해 본 날은 없습니다.

마라톤 금메달리스트 황영조 선수가 훈련 중에 자동차가 지나가면 그 바퀴 밑으로 뛰어들어 죽고 싶었다고 말했던 걸 기억합니다. 도대체 어느 정도 힘들어야 죽어버리는 게 낫겠다는 생각을 할 수 있을까?

저에게는 그런 날은 하루도 없었던 것입니다.
이 정도면 뭐 할만한 것 아닌가?

죽을 만큼 힘들게 훈련하진 않더라도,
(그렇게 해야 세계 챔피언이 될 수 있나 봅니다)
적당한 훈련을 매일 오랫동안 해나가면 인생을 편안하게 살 만큼의 성취 정도는 이룰 수 있다는 걸 나중에야 알게 됐습니다.
왜냐면 그것조차 할 수 있는 사람이 별로 없으니까.

이걸 알고 나서 마음이 참 편해졌습니다.
난 분명히 잘될 거야.
더 즐기면서 일할 수 있게 되었습니다.

https://jeho.page/essay/2024/07/17/not-easy-but-not-hard-either.html

컴퓨터 공부를 처음 시작한 날이 2004년 8월 25일. 이제 20년이 지났습니다. 돌아보면 그렇게 쉽진 않았지만 또 그렇게 어렵지도 않았던 것 같습니다. 매일 조금씩 힘들고 피곤하긴 했지만.. 죽을 만큼 힘들다고 생각해 본 날은 없습니다. 마라톤 금메달리스트 황영조 선수가 훈련 중에 자동차가 지나가면 그 바퀴 밑으로 뛰어들어 죽고 싶었다고 말했던 걸 기억합니다. 도대체 어느 정도 힘들어야 죽어버리는 게 낫겠다는 생각을 할 수 있을까? 저에게는 그런 날은 하루도 없었던 것입니다. 이 정도면 뭐 할만한 것 아닌가? 죽을 만큼 힘들게 훈련하진 않더라도, (그렇게 해야 세계 챔피언이 될 수 있나 봅니다) 적당한 훈련을 매일 오랫동안 해나가면 인생을 편안하게 살 만큼의 성취 정도는 이룰 수 있다는 걸 나중에야 알게 됐습니다. 왜냐면 그것조차 할 수 있는 사람이 별로 없으니까. 이걸 알고 나서 마음이 참 편해졌습니다. 난 분명히 잘될 거야. 더 즐기면서 일할 수 있게 되었습니다. https://jeho.page/essay/2024/07/17/not-easy-but-not-hard-either.html

K리그 프로그래머

회계는 지난 수백 년 동안 크게 변하지 않았음그럼에도 불구하고, 금융 시스템을 위한 소프트웨어를 구축하는 올바른 방법에 대해 많은 혼란이 있음이 글에서는 대기업에서 금융 시스템을 구축한 경험을 바탕으로 한 교훈을 공유회계 시스템 구축에 초점을 맞추겠지만, 이 원칙들은 더 일반적인 금융 시스템에도 적용됨기본 금융 용어 정의일반 원장 (General Ledge

금융 시스템 구축을 위한 엔지니어링 원칙 | GeekNews

예전에 회계 시스템 만들때, "아 정말 나는 금융을 하나도 모르는 구나" 하면서 참 고생했던 기억이 있습니다.

숫자 계산을 좋아하는 개발자들이지만, 역사가 긴 금융, 회계 시스템, 환율, 정책, 원리에 대해서 이해하지 않으면 설계에서부터 시작해서, 멱등성 유지, 트랜잭션 등 자칫 고려하지 못하면 큰일 나는 구석들도 많은 아주 흥미로우면서 후덜덜한 영역일 것 같습니다.

news.hada.io/topic?id=15794

블로그 글 뿐만 아니라 저도 설계에 도움 많이 받았던 글들 공유드려봅니다!

 * Martin Fowler - Accounting Patterns : https://martinfowler.com/apsupp/accounting.pdf
   
 * 실제 서비스 API로 만들면 이런 모양이 될꺼다!로 제일 참고하기 좋았던 Twisp Doc (GraphQL) : https://t.co/m78EFpYX7w

예전에 회계 시스템 만들때, "아 정말 나는 금융을 하나도 모르는 구나" 하면서 참 고생했던 기억이 있습니다. 숫자 계산을 좋아하는 개발자들이지만, 역사가 긴 금융, 회계 시스템, 환율, 정책, 원리에 대해서 이해하지 않으면 설계에서부터 시작해서, 멱등성 유지, 트랜잭션 등 자칫 고려하지 못하면 큰일 나는 구석들도 많은 아주 흥미로우면서 후덜덜한 영역일 것 같습니다. news.hada.io/topic?id=15794 블로그 글 뿐만 아니라 저도 설계에 도움 많이 받았던 글들 공유드려봅니다! <ul ><li>Martin Fowler - Accounting Patterns : https://martinfowler.com/apsupp/accounting.pdf </li><li>실제 서비스 API로 만들면 이런 모양이 될꺼다!로 제일 참고하기 좋았던 Twisp Doc (GraphQL) : https://t.co/m78EFpYX7w </li></ul>

GeekNews

금융 시스템 구축을 위한 엔지니어링 원칙

테스트 코드는 왜 써야 할까요? 테스트 코드가 가져오는 베네핏들에는 어떤 것이 있을까요?

모닥불 | EP.3 프론트엔드 개발에서 테스트 자동화, 꼭 해야 할까?

프론트엔드 개발 영역에서 테스트 코드의 필요성은 지속적인 논의의 대상입니다. 사용자 인터페이스와 직접적으로 연결되는 프론트엔드 코드의 특성상, 빈번하고 다양한 변화에 직면하게 되기 때문인데요. 이러한 환경에서 개발자들은 때때로 시간적 제약으로 인해 테스트 코드 작성을 생략하고 즉각적인 개발에 집중하게 되는데요. 이는 단기적으로 생산성 향상으로 느껴질 수 있습니다.
그러나 이러한 접근은 '단기적 효율'과 '장기적 지속가능성' 사이의 균형에 대한 문제를 제기합니다. 테스트 코드 없이 진행되는 개발이 당장은 빠른 결과물 도출로 이어질 수 있지만, 장기적 관점에서는 오히려 생산성 저하와 품질 문제로 이어질 수 있기 때문인데요.
그렇다면 테스트 코드가 어떻게 장기적인 생산성 향상에 기여하는 것일까요? 다음은 테스트 코드가 가져다주는 주요 이점들입니다:
 1. 신속한 피드백 루프: 테스트 코드는 개발자가 변경사항을 즉각적으로 검증할 수 있게 해줍니다. 이는 수동 테스트 과정을 최소화하고, 버그를 조기에 발견하여 수정 비용을 절감시킵니다.
 2. 리팩토링 자신감: 잘 작성된 테스트 코드는 개발자에게 코드 개선에 대한 자신감을 부여합니다. 기존 기능의 정상 작동을 보장하면서 새로운 기능을 추가하거나 라이브러리 업데이트를 할 수 있습니다.
 3. 문서화 효과: 테스트 코드는 실행 가능한 명세서 역할을 합니다. 특히 빠르게 변화하는 스타트업 환경에서, 테스트 코드는 최신 상태의 신뢰할 수 있는 문서가 됩니다.

그렇다면 테스트 코드는 어떻게 작성해야 할까요? 아마 많은 개발자 분들이 실질적으로 궁금해하는 내용일텐데요. 전통적인 테스트 피라미드 접근법은 유닛 테스트를 기반으로, 통합 테스트, 그리고 E2E(End-to-End) 테스트 순으로 구성됩니다. 그러나 실제 개발 에서는 이론과 실제 적용 사이의 간극이 존재하기 마련인데요. 토스의 테스트 전략은 아래와 같은 개념 으로 구성되어 있습니다:
 1. 전략적 선별: 복잡성이 높고 비즈니스에 중요한 기능에 테스트 역량을 집중합니다. 단순한 UI 요소보다는 핵심 비즈니스 로직과 주요 사용자 시나리오에 초점을 맞춤으로써, 테스트의 투자 대비 생산성을 극대화합니다.
 2. 통합 테스트 중심 접근: 페이지 단위의 통합 테스트로 실제 사용자 경험에 더 가까운 테스트 시나리오를 구성합니다. 이러한 방식은 개별 컴포넌트의 기능성뿐만 아니라, 상호작용하여 전체 시스템을 구성하는지 검증할 수 있게 해줍니다.
 3. 생산성과 효율성의 균형: 너무 단순한 테스트는 작성하지 않습니다. 예를 들어, 즉시 확인 가능한 단순 UI 변경사항에 대해서는 별도의 자동화된 테스트를 작성하지 않습니다.

결론적으로, 토스의 프론트엔드 테스트는 기존의 이론적 모델을 맹목적으로 따르기보다는 실질적인 가치를 제공하는 방향으로 접근하고 있습니다. 통합테스트 중심의 실용적 접근을 통해 개발 생산성과 품질 사이의 적절한 균형을 맞추는게 인상적이었습니다.

https://toss.tech/article/firesidechat_frontend_3

프론트엔드 개발 영역에서 테스트 코드의 필요성은 지속적인 논의의 대상입니다. 사용자 인터페이스와 직접적으로 연결되는 프론트엔드 코드의 특성상, 빈번하고 다양한 변화에 직면하게 되기 때문인데요. 이러한 환경에서 개발자들은 때때로 시간적 제약으로 인해 테스트 코드 작성을 생략하고 즉각적인 개발에 집중하게 되는데요. 이는 단기적으로 생산성 향상으로 느껴질 수 있습니다.그러나 이러한 접근은 '단기적 효율'과 '장기적 지속가능성' 사이의 균형에 대한 문제를 제기합니다. 테스트 코드 없이 진행되는 개발이 당장은 빠른 결과물 도출로 이어질 수 있지만, 장기적 관점에서는 오히려 생산성 저하와 품질 문제로 이어질 수 있기 때문인데요.그렇다면 테스트 코드가 어떻게 장기적인 생산성 향상에 기여하는 것일까요? 다음은 테스트 코드가 가져다주는 주요 이점들입니다:<ol ><li>신속한 피드백 루프: 테스트 코드는 개발자가 변경사항을 즉각적으로 검증할 수 있게 해줍니다. 이는 수동 테스트 과정을 최소화하고, 버그를 조기에 발견하여 수정 비용을 절감시킵니다.</li><li>리팩토링 자신감: 잘 작성된 테스트 코드는 개발자에게 코드 개선에 대한 자신감을 부여합니다. 기존 기능의 정상 작동을 보장하면서 새로운 기능을 추가하거나 라이브러리 업데이트를 할 수 있습니다.</li><li>문서화 효과: 테스트 코드는 실행 가능한 명세서 역할을 합니다. 특히 빠르게 변화하는 스타트업 환경에서, 테스트 코드는 최신 상태의 신뢰할 수 있는 문서가 됩니다.</li></ol> 그렇다면 테스트 코드는 어떻게 작성해야 할까요? 아마 많은 개발자 분들이 실질적으로 궁금해하는 내용일텐데요. 전통적인 테스트 피라미드 접근법은 유닛 테스트를 기반으로, 통합 테스트, 그리고 E2E(End-to-End) 테스트 순으로 구성됩니다. 그러나 실제 개발 에서는 이론과 실제 적용 사이의 간극이 존재하기 마련인데요. 토스의 테스트 전략은 아래와 같은 개념 으로 구성되어 있습니다:<ol ><li>전략적 선별: 복잡성이 높고 비즈니스에 중요한 기능에 테스트 역량을 집중합니다. 단순한 UI 요소보다는 핵심 비즈니스 로직과 주요 사용자 시나리오에 초점을 맞춤으로써, 테스트의 투자 대비 생산성을 극대화합니다.</li><li>통합 테스트 중심 접근: 페이지 단위의 통합 테스트로 실제 사용자 경험에 더 가까운 테스트 시나리오를 구성합니다. 이러한 방식은 개별 컴포넌트의 기능성뿐만 아니라, 상호작용하여 전체 시스템을 구성하는지 검증할 수 있게 해줍니다.</li><li>생산성과 효율성의 균형: 너무 단순한 테스트는 작성하지 않습니다. 예를 들어, 즉시 확인 가능한 단순 UI 변경사항에 대해서는 별도의 자동화된 테스트를 작성하지 않습니다.</li></ol> 결론적으로, 토스의 프론트엔드 테스트는 기존의 이론적 모델을 맹목적으로 따르기보다는 실질적인 가치를 제공하는 방향으로 접근하고 있습니다. 통합테스트 중심의 실용적 접근을 통해 개발 생산성과 품질 사이의 적절한 균형을 맞추는게 인상적이었습니다. https://toss.tech/article/firesidechat_frontend_3

Toss

변화하는 UI, 변하지 않는 품질: 토스의 프론트엔드 테스트 전략

원문 : https&#x3A;//dev.to/yoskutik/extremely-reducing-the-size-of-npm-package-3420

[번역] NPM 패키지 크기 대폭 축소하기

오늘 소개해드릴 글은 라인플러스의 손수림님이 번역해주신 글입니다.

이 글에서는 테스트 커버리지, 문서 작성, 유효한 버전 관리, 변경 로그 관리 등 패키지 개발의 다양한 측면을 다루고 있으며 특히 패키지의 크기를 최소화하는 방법에 초점을 맞추고 있습니다.

글은 크게 두 가지 부분로 나뉘어지며 첫 번째 부분에서는 의존성 설정과 빌드 프로세스와 같은 일반적인 팁을, 두 번째 부분에서는 개발자 경험(DX)을 약간 희생하면서도 패키지 크기를 더 작게 만드는 구체적인 코드 작성 방법을 설명합니다.

각종 최적화 팁과 더불어 코드 예제와 설명이 포함되어 있어 패키지 배포에 관심이 있으신 분들은 가볍게 읽어보시는 것을 추천드립니다. :)

> 글 링크 : https://velog.io/@surim014/extremely-reducing-the-size-of-npm-packages

오늘 소개해드릴 글은 라인플러스의 손수림님이 번역해주신 글입니다. 이 글에서는 테스트 커버리지, 문서 작성, 유효한 버전 관리, 변경 로그 관리 등 패키지 개발의 다양한 측면을 다루고 있으며 특히 패키지의 크기를 최소화하는 방법에 초점을 맞추고 있습니다. 글은 크게 두 가지 부분로 나뉘어지며 첫 번째 부분에서는 의존성 설정과 빌드 프로세스와 같은 일반적인 팁을, 두 번째 부분에서는 개발자 경험(DX)을 약간 희생하면서도 패키지 크기를 더 작게 만드는 구체적인 코드 작성 방법을 설명합니다. 각종 최적화 팁과 더불어 코드 예제와 설명이 포함되어 있어 패키지 배포에 관심이 있으신 분들은 가볍게 읽어보시는 것을 추천드립니다. :) &gt; 글 링크 : https://velog.io/@surim014/extremely-reducing-the-size-of-npm-packages

Velog

NPM 패키지 크기 대폭 축소하기

테니스 황제라고 불리는 로저 페더러의 최근 다트머스 졸업 연설. 모든 내용 하나하나가 주옥같았다. 일등 하는 사람들은 항상 배울 것이 있다. 그것도 전 세계 1등이니까. 그 사람이 거기까지 가는 데 있어서 내면적으로 겪은 경험들은... 아주 값진 지혜들을 담고 있다. 모든 내용들이 다 좋았지만, 나는 캡처한 부분이 제일 좋았다.

로저 페더러 다트머스 졸업연설

테니스 황제라고 불리는 로저 페더러의 최근 다트머스 졸업 연설이 인상적이다. 그가 이제 대학을 졸업하고 사회로 나가는 졸업생들과 나눈 세 가지 메시지에 내 생각을 얹어본다.

1) Effortless is a myth. (공짜는 없다)
우린 모두 타고난 각자의 재능이 있다. 기가 막힌 음색을 가지고 태어난 사람도 있고, 숫자에 능한 사람도 있고, 동물적으로 운동감각이 뛰어난 사람도 있다. 성공하려면 타고난 재능을 가지고 있어야 한다는 말도 맞을지 모르겠다. 그래서일까? 우리는 종종 성공한 사람들을 보며 타고난 재능이라고 치부해 버리기도 하고, 쉽게 해내는 (것처럼 보이는) 결과물을 보며 그 자리까지 가기 위해 흘린 피 땀 눈물을 외면해 버리기도 한다.

로저 페더러는 자신이 테니스 선수에게 필요한 재능을 타고났음을 인정하면서(타고난 재능을 커리어와 연결시키는 건 매우 중요하다), 타고난 재능만으로는 성공할 수 없음을 강조한다. "Believe in yourself has to be earned."라며 자신에 대한 믿음은 경기를 승리로 이끄는데 꼭 필요한 재능인데, 이는 타고난 재능이 아니라 각고의 노력으로 얻어내야 하는 재능이라고 말한다. 인내심과 끈기, 과정을 즐길 수 있는 여유, 자기 관리... 이 모든 게 치열한 자신과의 싸움으로 만들어낸 재능이라는 것이다. 나는 개인적으로 "to be earned"라는 말을 좋아한다. 우리의 성공이 타고난 재능으로 결정된다면 억울하고 재미없는 삶이 되겠지만, 내가 노력해서 얻어낸 재능으로 성공을 만들 수 있다면 살아볼 만한 인생이라는 에너지가 생긴다.

나는 최근 일적으로 폭풍 속을 걷는 것 같은 시기를 보내고 있는데, 자기 확신, 회복력, 긍정적 마인드 이 세 재능을 바닥내지 않고 든든하게 키우기 위해 노력 중이다. 새로운 프로젝트를 리딩하고 팀을 매니징하고 의사결정을 내리는데 자기 확신은 필수이다. 그렇지 않으면 매사 불안감이 커져서 잘못된 판단을 내리거나, 결정을 미루거나, 책임을 전가해 버리는 결과를 내기 쉽다. 새로운 일을 시도할 때는 (특히 제로투원을 만들어 낼 때는) 실수나 실패를 했을 때 빠르게 인정하고 회복할 수 있어야 한다. 한 번에 성공하는 게 목표가 아니라 빠르게 실패하고 그걸 발판으로 또다시 시도하거나 피벗을 하면서 방향을 잡아 가는게 중요하기 때문이다. 실수나 실패에 타격이 큰 사람은 오래 버틸 수가 없다. 자기 확신과 회복력은 긍정적 마인드를 베이스로 한다. 괜찮다는 마음, 할 수 있다는 마음, 까짓것 일단 한번 해보지 뭐, 아님 말고! 하는 초긍정 마인드가 성공에 꼭 필요한 재능이고, 이건 타고난 재능이 아니라 치열한 노력으로 만들어진다. "Belive in yourself has to be earned."

각자 가진 재능을 잘 살펴보고 어떤 재능을 더 키워야 하는지 적어보면 어떨까. 성실한 것도, 잘 웃는 것도, 친화력 있는 것도, 책임감이 있는 것도 모두 노력으로 얻어야 하는 재능들이다.

2) It's only a point. (그저 1 포인트일 뿐이다)
테니스의 황제라고 불리는 로저 페더러의 한 세트 평균 승률은 54%. 세계 최고 탑 플레이어이지만 승률은 50% 정도라는 것이다. (야구도 3할이면 최강 타자라고 불린다). 한 포인트는 승부사에게 매우 중요한 순간이지만(그래서 한 포인트를 얻기 위해 최선을 다해야 하지만), 졌을 땐 그저 한 포인트로 진거 일뿐이라는 거다. 진 포인트에 연연하면 다음 포인트를 놓치게 된다. 인생을 살다 보면 1 포인트를 잃게 되는 경우가 흔히 생기는데, 1 포인트는 그저 1 포인트일 뿐. It's OK. It's only a point. 인생 최고의 샷을 만들었다면? 그 또한 1 포인트일 뿐이다.

"When you're playing a point, it has to be the most important thing in the world and it is. But when it's behind you it's behind you. This mindset is really crucial because it frees you to fully commit to the next point and the next point after, with intensity, clarify, and focus. The truth is whatever game you play in life, sometimes you're going to lose; a point, a match, a season, a job.. it's a roller coaster with many ups and downs, but negative energy is wasted energy. You want to become a master at overcoming hard moments. That is a sign of a champion."

월드 챔피언은 모든 경기를 이겨서가 아니라, 자신의 패배를 다루는 법을 잘 알고 훈련한 사람이라고 강조한다.

"The best in the world are not the best because they win every point. But it's because they know they lose again and again and have learned how to deal with it."

어느 날은 일을 잘 해낸 것 같아서 뿌듯하다가, 어느 날은 다 망친 것 같아서 자괴감에 빠질 때도 있다. 동료들에게 칭찬을 듣기도 하고 비난을 받기도 한다. 내가 만든 결과물이 졸작인 것 같아서 다 버리고 싶은 날들이 이어지기도 한다. 성공도 실패도 그저 내 커리어 인생에 1 포인트일 뿐이다. 1포인트로 게임에서 진 것보다, 더 위험한 게 '난 역시 안 되나 봐', '자존심 상해서 그만뒀어', '다시 도전한 엄두가 안 나' 이런 마음으로 이어지는 패배감이다. 그저 1 포인트라는 걸 상기하자. 세계 최강 선수도 승률이 50%이고, 최강 타자도 3할인데, 평범한 내가 매번 성공한다면 그게 더 이상한 거다. 일희일비하지 말자. 그저 1 포인트씩 쌓아가는 거다.

3) Life is bigger than a court.
16살에 테니스 커리어를 시작해서 24년 동안 테니스 코트에서 살았고 테니스에서 인생을 배웠다고 생각했는데, 2022년에 은퇴를 하고 보니 자신이 몰랐던 큰 세상이 있더라는 깨달음.

내가 처한 상황이 절망적이라고 느껴질 때, 내가 손에 쥐고 있는 걸 놓으면 세상이 무너질 것 같은 두려움이 생길 때, 나만 뒤처지고 억울한 것 같다는 생각이 밀려올 때.. 내 눈에 가림막을 하고 무작정 달리고 있는 건 아닌지 멈춰서 살펴봐야 한다. 생각해 보면 내가 만나는 사람들의 숫자도 지극히 제한적이고, 내가 속한 커리어 분야도 매우 협소하고 (게다가 나는 내가 하는 일 외엔 모르는 게 너무 많다), 내가 경험한 세계도 고작 몇몇 나라와 도시들뿐이다. 여행을 하면 내가 모르는 세상과 만나게 되는 게 가장 큰 인생 배움이 된다. 세상은 넓고, 사람들은 다양하고, 삶은 다 각자 다른 모습으로 꽃을 피운다. 인생을 내 커리어 코트에 묶어 놓는다면 경기가 끝났을 때 멘붕이 올 것이다. 커리어는 커리어일 뿐, 인생 전부가 아니다. 꼭 명심하자.

https://www.youtube.com/watch?v=t8v0cHn_LRc

테니스 황제라고 불리는 로저 페더러의 최근 다트머스 졸업 연설이 인상적이다. 그가 이제 대학을 졸업하고 사회로 나가는 졸업생들과 나눈 세 가지 메시지에 내 생각을 얹어본다.​1) Effortless is a myth. (공짜는 없다)우린 모두 타고난 각자의 재능이 있다. 기가 막힌 음색을 가지고 태어난 사람도 있고, 숫자에 능한 사람도 있고, 동물적으로 운동감각이 뛰어난 사람도 있다. 성공하려면 타고난 재능을 가지고 있어야 한다는 말도 맞을지 모르겠다. 그래서일까? 우리는 종종 성공한 사람들을 보며 타고난 재능이라고 치부해 버리기도 하고, 쉽게 해내는 (것처럼 보이는) 결과물을 보며 그 자리까지 가기 위해 흘린 피 땀 눈물을 외면해 버리기도 한다.​로저 페더러는 자신이 테니스 선수에게 필요한 재능을 타고났음을 인정하면서(타고난 재능을 커리어와 연결시키는 건 매우 중요하다), 타고난 재능만으로는 성공할 수 없음을 강조한다. "Believe in yourself has to be earned."라며 자신에 대한 믿음은 경기를 승리로 이끄는데 꼭 필요한 재능인데, 이는 타고난 재능이 아니라 각고의 노력으로 얻어내야 하는 재능이라고 말한다. 인내심과 끈기, 과정을 즐길 수 있는 여유, 자기 관리... 이 모든 게 치열한 자신과의 싸움으로 만들어낸 재능이라는 것이다. 나는 개인적으로 "to be earned"라는 말을 좋아한다. 우리의 성공이 타고난 재능으로 결정된다면 억울하고 재미없는 삶이 되겠지만, 내가 노력해서 얻어낸 재능으로 성공을 만들 수 있다면 살아볼 만한 인생이라는 에너지가 생긴다.​나는 최근 일적으로 폭풍 속을 걷는 것 같은 시기를 보내고 있는데, 자기 확신, 회복력, 긍정적 마인드 이 세 재능을 바닥내지 않고 든든하게 키우기 위해 노력 중이다. 새로운 프로젝트를 리딩하고 팀을 매니징하고 의사결정을 내리는데 자기 확신은 필수이다. 그렇지 않으면 매사 불안감이 커져서 잘못된 판단을 내리거나, 결정을 미루거나, 책임을 전가해 버리는 결과를 내기 쉽다. 새로운 일을 시도할 때는 (특히 제로투원을 만들어 낼 때는) 실수나 실패를 했을 때 빠르게 인정하고 회복할 수 있어야 한다. 한 번에 성공하는 게 목표가 아니라 빠르게 실패하고 그걸 발판으로 또다시 시도하거나 피벗을 하면서 방향을 잡아 가는게 중요하기 때문이다. 실수나 실패에 타격이 큰 사람은 오래 버틸 수가 없다. 자기 확신과 회복력은 긍정적 마인드를 베이스로 한다. 괜찮다는 마음, 할 수 있다는 마음, 까짓것 일단 한번 해보지 뭐, 아님 말고! 하는 초긍정 마인드가 성공에 꼭 필요한 재능이고, 이건 타고난 재능이 아니라 치열한 노력으로 만들어진다. "Belive in yourself has to be earned."​각자 가진 재능을 잘 살펴보고 어떤 재능을 더 키워야 하는지 적어보면 어떨까. 성실한 것도, 잘 웃는 것도, 친화력 있는 것도, 책임감이 있는 것도 모두 노력으로 얻어야 하는 재능들이다.​2) It's only a point. (그저 1 포인트일 뿐이다)테니스의 황제라고 불리는 로저 페더러의 한 세트 평균 승률은 54%. 세계 최고 탑 플레이어이지만 승률은 50% 정도라는 것이다. (야구도 3할이면 최강 타자라고 불린다). 한 포인트는 승부사에게 매우 중요한 순간이지만(그래서 한 포인트를 얻기 위해 최선을 다해야 하지만), 졌을 땐 그저 한 포인트로 진거 일뿐이라는 거다. 진 포인트에 연연하면 다음 포인트를 놓치게 된다. 인생을 살다 보면 1 포인트를 잃게 되는 경우가 흔히 생기는데, 1 포인트는 그저 1 포인트일 뿐. It's OK. It's only a point. 인생 최고의 샷을 만들었다면? 그 또한 1 포인트일 뿐이다.​"When you're playing a point, it has to be the most important thing in the world and it is. But when it's behind you it's behind you. This mindset is really crucial because it frees you to fully commit to the next point and the next point after, with intensity, clarify, and focus. The truth is whatever game you play in life, sometimes you're going to lose; a point, a match, a season, a job.. it's a roller coaster with many ups and downs, but negative energy is wasted energy. You want to become a master at overcoming hard moments. That is a sign of a champion."​월드 챔피언은 모든 경기를 이겨서가 아니라, 자신의 패배를 다루는 법을 잘 알고 훈련한 사람이라고 강조한다.​"The best in the world are not the best because they win every point. But it's because they know they lose again and again and have learned how to deal with it." 어느 날은 일을 잘 해낸 것 같아서 뿌듯하다가, 어느 날은 다 망친 것 같아서 자괴감에 빠질 때도 있다. 동료들에게 칭찬을 듣기도 하고 비난을 받기도 한다. 내가 만든 결과물이 졸작인 것 같아서 다 버리고 싶은 날들이 이어지기도 한다. 성공도 실패도 그저 내 커리어 인생에 1 포인트일 뿐이다. 1포인트로 게임에서 진 것보다, 더 위험한 게 '난 역시 안 되나 봐', '자존심 상해서 그만뒀어', '다시 도전한 엄두가 안 나' 이런 마음으로 이어지는 패배감이다. 그저 1 포인트라는 걸 상기하자. 세계 최강 선수도 승률이 50%이고, 최강 타자도 3할인데, 평범한 내가 매번 성공한다면 그게 더 이상한 거다. 일희일비하지 말자. 그저 1 포인트씩 쌓아가는 거다.​3) Life is bigger than a court.16살에 테니스 커리어를 시작해서 24년 동안 테니스 코트에서 살았고 테니스에서 인생을 배웠다고 생각했는데, 2022년에 은퇴를 하고 보니 자신이 몰랐던 큰 세상이 있더라는 깨달음.​내가 처한 상황이 절망적이라고 느껴질 때, 내가 손에 쥐고 있는 걸 놓으면 세상이 무너질 것 같은 두려움이 생길 때, 나만 뒤처지고 억울한 것 같다는 생각이 밀려올 때.. 내 눈에 가림막을 하고 무작정 달리고 있는 건 아닌지 멈춰서 살펴봐야 한다. 생각해 보면 내가 만나는 사람들의 숫자도 지극히 제한적이고, 내가 속한 커리어 분야도 매우 협소하고 (게다가 나는 내가 하는 일 외엔 모르는 게 너무 많다), 내가 경험한 세계도 고작 몇몇 나라와 도시들뿐이다. 여행을 하면 내가 모르는 세상과 만나게 되는 게 가장 큰 인생 배움이 된다. 세상은 넓고, 사람들은 다양하고, 삶은 다 각자 다른 모습으로 꽃을 피운다. 인생을 내 커리어 코트에 묶어 놓는다면 경기가 끝났을 때 멘붕이 올 것이다. 커리어는 커리어일 뿐, 인생 전부가 아니다. 꼭 명심하자.​https://www.youtube.com/watch?v=t8v0cHn_LRc

로저 페더러에게 배우는 성공의 비결

리눅스의 창시자인 리누스 토발즈의 유명한 말 중에 다음과 같은 명언이 있다.

“Talk is cheap, show me the code.”

AI가 대신 코딩해주는 시대에, 이제 이 말은 다음처럼 바뀌어야 하지 않을까 싶다.

“Code is cheap, talk about value.”

리눅스의 창시자인 리누스 토발즈의 유명한 말 중에 다음과 같은 명언이 있다. “Talk is cheap, show me the code.” AI가 대신 코딩해주는 시대에, 이제 이 말은 다음처럼 바뀌어야 하지 않을까 싶다. “Code is cheap, talk about value.”

리눅스의 창시자인 리누스 토발즈의 유명한 말 중에 다음과 같은 명

SCAMPER는 아이디어 발상을 도와주는 창의적 사고도구입니다. 각각의 알파벳은 아이디어를 발전시키기 위한 구체적인 질문을 나타냅니다.

1. Substitute (대체하기): 어떤 요소를 다른 것으로 바꿀 수 있을까?
- 예시: 플라스틱 빨대를 종이 빨대로 대체하기.

2. Combine (결합하기): 두 가지 요소를 결합하면 새로운 것이 나올까?
- 예시: 스마트폰과 카메라 기능 결합.

3. Adapt (적용하기): 다른 분야에서 성공한 아이디어를 적용할 수 있을까?
- 예시: 자동차 좌석의 열선 기능을 사무실 의자에 적용.

4. Modify (변형하기): 기존 아이디어를 어떻게 변형할 수 있을까?
- 예시: 기존 제품의 색상이나 크기 변경.

5. Put to another use (다른 용도로 사용하기): 다른 방식으로 활용할 수 있을까?
- 예시: 와인병을 꽃병으로 사용.

6. Eliminate (제거하기): 불필요한 요소를 제거할 수 있을까?
- 예시: 제품의 복잡한 기능을 제거하고 단순화.

7. Reverse (반대로 생각하기): 순서를 뒤집거나 반대로 해볼 수 있을까?
- 예시: 패키지 배송을 고객이 직접 픽업하게 하기.

SCAMPER는 아이디어 발상을 도와주는 창의적 사고도구입니다. 각각의 알파벳은 아이디어를 발전시키기 위한 구체적인 질문을 나타냅니다. 1. Substitute (대체하기): 어떤 요소를 다른 것으로 바꿀 수 있을까? - 예시: 플라스틱 빨대를 종이 빨대로 대체하기. 2. Combine (결합하기): 두 가지 요소를 결합하면 새로운 것이 나올까? - 예시: 스마트폰과 카메라 기능 결합. 3. Adapt (적용하기): 다른 분야에서 성공한 아이디어를 적용할 수 있을까? - 예시: 자동차 좌석의 열선 기능을 사무실 의자에 적용. 4. Modify (변형하기): 기존 아이디어를 어떻게 변형할 수 있을까? - 예시: 기존 제품의 색상이나 크기 변경. 5. Put to another use (다른 용도로 사용하기): 다른 방식으로 활용할 수 있을까? - 예시: 와인병을 꽃병으로 사용. 6. Eliminate (제거하기): 불필요한 요소를 제거할 수 있을까? - 예시: 제품의 복잡한 기능을 제거하고 단순화. 7. Reverse (반대로 생각하기): 순서를 뒤집거나 반대로 해볼 수 있을까? - 예시: 패키지 배송을 고객이 직접 픽업하게 하기.

아이디어가 잘 안생길 때 쓸 수 있는 프레임워크 SCAMPER 💡

개발자 비급(祕笈) - 5. 스타트업의 개발자 채용 비법 :: Channy's Blog

< 스타트업의 개발자 채용 비법>
스타트업에서 개발자 잘 뽑으려면 어떻게 해야 하는가 하는 글입니다. :)

1. 스타트업 DNA에 잘 맞고, 창업자와 유사한 DNA를 가진 사람 채용하기
2. 채용된 사람들은 강점을 발휘할 수 있는 자리로 위치시키기
3. 파격적인 보상과 기회 주기
4. 개발자 관계 활동에 대한 장기적이면서도 적극적인 후원

이런 내용인데요.
1/3/4까지는 정말 공감됩니다.

특히나 개발자 관계 활동에 대한 스폰서십 및 관계를 장시간 맺어가는 것은..
저도 생각하지 못했던 부분인데..
향후에 다른 팀에 가게 되면 꼭 써먹어 봐야겠네요.

Channy's Blog

서동환

Product Manager

근정

그루빈(groovin) Co-Founder

김담인

‘나만의 스타일을 구제하다’ - 빈티지 패션 쇼핑플랫폼 그루빈(groovin)을 운영하고 있습니다.
@iamgroovin

대학생 창업자로서 스타트업 관련 글들을 읽고 느낀점을 공유합니다. 감사합니다.

CEO & co-founder

Product Owner

Senior Product Owner

기계항공공학부

서울대 기계항공공학부 재학 중, 에스엔유프리시젼이란 LCD 검사장비 회사에서 소프트웨어 엔지니어로 일했습니다. 학교로 복학한 다음에도 졸업은 하지 않고 선배가 창업한 공신이란 교육스타트업에서 PM을 했고, 힘들게 졸업한 후 네오위즈인터넷을 거쳐 프라이베리라는 회사를 창업했습니다. 여러 커리어를 거치면서 마케팅 업무가 가능한 Product Manager로 성장해서 현재 푸른밤에서 Product Manager와 Product Marketer를 겸임하고 있습니다.

안창영

여러 스타트업과 산업 분야에서 제품을 관리하는 일을 해왔습니다. 어떻게 하면 더 좋은 제품을 만들고, 서비스할 수 있는지에 대해서 관심이 많고, 이를 더 적은 리소스와 리스크로 구현하는 것에 관심이 많습니다.

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필