Activity notes and technical perspective

Today I attended ACC SCD, the AWS Campus Club Student Community Day. I remember seeing the promotional post and almost instinctively opening festa.io to sign up.

AWS Cloud Club is a community support program launched by AWS in 2023. This event was actually how I learned about it. Since I had already graduated, I could not join as a student member, which was a little disappointing, but it also made me more determined to stay active through AWSKRUG and through efforts to promote AWS-related activities around me.

ACC SCD 2024 was structured with a wide range of sessions: three career sessions, three architecture sessions, four DevOps sessions, two serverless sessions, and one sponsor session. I attended the introductory architecture session “Architecture Design Starting from Zero,” the advanced architecture session “There Is a Reason Behind the Cloud Native Trend,” the serverless session “Lambda and EventBridge Give You Wings,” the DevOps session “Building a Scalable 3-Tier Architecture and CI/CD with Terraform,” and the sponsor session “Exploring the Notion API with AWS.”

The architecture design session and the Terraform session were both framed around the speaker’s personal experience, which made them especially relatable because I had touched similar topics myself the previous winter. The Notion API session was also helpful because I had already felt some limitations with the currently available integrations. The session that interested me most, though, was the one on Lambda and EventBridge. The idea that Lambda triggers can connect naturally to services like S3 or SQS, and that EventBridge rules can be arranged to shape behavior exactly as needed, felt like something that could be very useful in my future work.

Overall, the event felt full and worthwhile from the keynote to the closing activities. It was a bit unfortunate that there was no separate networking session, because that meant the day focused more on knowledge than on direct interaction among students interested in AWS. Still, that feels like something the event series could improve over time. Since most AWS Cloud Club activities are limited to students from participating universities, it may be hard to witness the broader history of the community outside of events like Community Day, but I would love to someday meet ACC members again as either a speaker or a staff member at an AWS event.

The Anthropic AI team announced support for integration with LangChain.

LangChain is an SDK that helps connect LLMs with applications. In reality, once you start adding AI capabilities to a product, there are many decisions to make. You have to think about what data to use, how to manage training speed, how to choose optimization parameters, what batch sizes to use, where outputs should be stored, and, in generative AI settings, even what prompt strategy to adopt.

In practice, people usually rely on external tools to handle these tasks, but managing those tools can quickly become tedious. On AWS, some of this can be handled through SageMaker or Lambda, but if you are trying to support multiple services, searching for the right region and pricing, or working in an environment where managed cloud services are hard to use, things become much less convenient.

This is exactly the kind of problem LangChain tries to address by tying systems together into a manageable workflow. With an OpenAI ChatGPT API key, a Hugging Face access key, and now Anthropic support as well, multiple model providers can be accessed through a more unified integration layer.

LangChain is available free of charge for individual users, and it currently provides both documentation and a video related to Anthropic support, so it seems worth checking out.

Docs: https://lnkd.in/gbGiwm72
Video: youtu.be/cVEJaWgiudU

Today I attended a seminar in my Advanced AI Topics class by Denis V. Batalov, who serves as a Worldwide Technical Leader for Machine Learning and Artificial Intelligence at Amazon Web Services. The talk, titled GenAI 2024, gave a broad view of AWS, Generative AI, and Responsible AI.

The presentation drew heavily on the speaker’s own path and experience. Stories about indexing books, relocating to AWS in Luxembourg, meeting Professor Youngim Cho at a European event, and working on products such as Kindle Direct Publishing and Amazon Mobile made it easier to understand how long-term exposure to real systems builds technical judgment. Along the way, the talk also touched on themes like Gartner’s Hype Cycle for AI and the shift from traditional models to foundation models.

The later part of the talk focused on Responsible AI. Concepts such as fairness and explainability were presented not as abstract ideals, but as practical dimensions of system design. Questions around what counts as bias and how allocation should be judged opened up a more reflective conversation about what “responsible” really means in production contexts. I was also interested in the discussion around explainability methods such as Shapley Value and SHAP, especially as tools for making model predictions interpretable in practice.

The Q&A session was equally useful. When asked which AWS AI/ML service stands out most besides SageMaker, Denis pointed to Bedrock. His explanation made Bedrock sound like a service designed to cover a wider surface area while remaining easier to use, from API access to knowledge-base agents and workflow orchestration.

I also asked whether the English bias of current LLMs could eventually be reduced through technical progress. Denis answered that it could, but also emphasized that English still holds strong power as a common language, which makes region- and culture-specific model development even more important. That answer stayed with me because it connected language equity with real model strategy.

Overall, the seminar was a valuable opportunity to learn not only about GenAI and Responsible AI, but also about how experienced practitioners explain emerging technologies. It also reminded me that I would like to become someone who can eventually speak in public about AI and cloud systems with the same clarity and responsibility.

Yesterday I joined a meetup hosted by AWSKRUG Platform Engineering. The theme was how to reduce the operational burden on developers and SRE engineers in deployment environments.

The key theme of the first session was preview deployment. It began with the limitations of beta deployment, and for me it was interesting because I had mostly thought about deployment only in terms of environments. The speaker explained alpha, beta, and real environments as stages in the software deployment lifecycle. Alpha is the first deployment using synthetic or provisional data, beta comes after alpha and includes validation of data consistency, and real is the actual launch after beta. In practice, these felt similar to what we often call QA, staging, and production. Still, the talk made it clear that maintaining beta environments properly in real work is difficult. Questions pile up quickly: how many environments are needed, how long they should exist, how the infrastructure should be provisioned, how management tags should be attached, and how CI/CD pipelines should be created and connected to them.

To address this, the talk described a platform that could create and clean up environments on demand for cases such as QA testing or newly opened merge requests. The point was that these environments could be generated when needed and removed immediately after use. Another interesting idea was that these temporary resources could be used at the project level with lightweight pipeline settings, without provisioning a whole new dedicated infrastructure stack each time. In the example, temporary environments were built per branch using tools such as AWS S3, CloudFront, Lambda@Edge, and GitLab CI. Along the way, concepts such as Subject Alternative Name and Module Federation were also mentioned, which gave me new ideas to explore.

The second session was about a cloud resource platform that allows development teams to manage cloud permissions safely. Since the talk was going to appear later at AWS Summit 2024, it was difficult to describe in public detail, but it still gave me a lot of useful perspective on cloud computing and internal platform design.

This meetup was valuable not only because of the speakers, but also because I learned a lot from the people asking questions. It felt like one of those moments that makes you think, “So this is the level I need to reach.” It left such a good impression that I felt even more strongly that I should keep attending these meetups consistently.

Yesterday I attended Build With AI in Songdo hosted by GDG Incheon & Songdo. It was nice to head back to Yeonsu-gu for an event, and the venue at Incheon Startup Park INSTAR I was directly connected to the subway, which made the trip especially convenient.

The event focused mainly on LLMs, but it went beyond a basic introduction. The sessions covered how LLMs can be applied, how their limitations might be addressed, and how they should be evaluated. There was also a session on the Mamba architecture. Because I tend to be more interested in the theoretical side of LLMs than in purely practical usage, I mainly joined tech sessions such as “Can Transformers Be Replaced? (feat. Mamba),” “HAERAE: How Can We Evaluate Korean Ability in LLMs?,” “LLM Safety & Security,” and the hands-on session “Using Gemini More Intelligently with RAG.”

The Mamba session covered the limitations of Transformer models and the SSM-based alternatives that emerged in response. While Transformers achieve excellent performance, they still face issues around memory usage, compute cost, and long-term dependency. To address these limitations, techniques such as Flash-Attention and State Space Models have been proposed, and this talk focused specifically on SSMs. I learned that applying SSMs in deep learning requires discretization, and the speaker introduced several methods such as Euler, bilinear, and ZOH. The session also touched on topics like kernels in SSMs, linear time invariance, Griffin’s linear scan, and areas where Mamba still seems weaker than Transformers, such as copying, retrieval, and in-context language learning.

The LLM evaluation session introduced the motivation behind the HAERAE team and the timeline that led them to develop new evaluation datasets. Benchmarks such as MMLU already exist for measuring performance across many domains, but it is difficult to simply translate those benchmarks into Korean and assume they remain valid. To create a benchmark that works properly in a Korean-centered environment, the HAERAE team explored many kinds of data, from commonsense knowledge to specialized expertise, and carefully considered what would be most suitable. Through that process, they developed benchmarks such as KMMLU and the HAERAE Benchmark.

Beyond that, I also learned about Retrieval Augmented Generation through a hands-on session using Gemini and LangChain, and I joined a session on LLM safety and security that covered both traditional ML security issues and the new security concerns that emerge in LLM settings. It was a genuinely enjoyable event, and I would gladly join again if a similar one is held in the future.

Yesterday I attended Google Cloud Korea’s Cloud Onboard event.

By now I feel relatively familiar with AWS, but I know much less about other cloud providers, and I did not want to become the kind of MLOps engineer who only knows one ecosystem. That was the reason I decided to sign up, and I still remember how happy I was when the confirmation email arrived soon afterward.

Of course, services such as GKE, Google Cloud’s managed Kubernetes offering, and AI playground-style services like Gemini and Vertex AI were interesting. But the part that stood out most to me was the early discussion on networking. The services closer to the user layer can sometimes be replaced by SaaS products or built directly, so if I were ever in the position to choose a platform for a project, I thought networking capabilities would be one of the main factors I would use to decide.

One of the networking services that was introduced in particular was Maglev. Maglev was presented under the title “A Fast and Reliable Software Network Load Balancer.” What made it memorable was the way it provides networking services with high performance and low latency. It was amusing to see that if you ask Gemini about it, it argues quite forcefully that it corresponds to AWS CloudFront.

I also appreciated that the event was designed to make first-time GCP learners feel comfortable, with Q&A sessions, refreshments, and an overall approachable flow. I am planning to attend another event hosted by GDG Songdo next week, and I think what I learned here will help me participate with a deeper understanding.

Yesterday I attended a MODUPOP event hosted by MODULabs on the topic of “evaluating Korean language models well.” It had been about two years since I last heard speaker Gyujin Son present, and it was meaningful to listen again with a slightly different perspective shaped by my more recent interests in evaluation and systems.

Even though I had already heard a related version of the topic at another event, this session gave me a deeper understanding of the HAERAE team’s benchmark work. The talk introduced several benchmark efforts, including HAERAE Benchmark, HAERAE Benchmark 2, CSATQA, and the context that eventually led to KMMLU. One interesting point was the confidence the team gained from seeing that existing global benchmarks also rely on scalable educational test material.

The talk also shared insights from developing KMMLU. Among the evaluation settings discussed was Chain of Thought, which the speaker framed in a practical way: whether a model can genuinely understand and generate in Korean. What stood out to me was that among the models evaluated, HyperCLOVA X was the only Korean model that clearly benefited from CoT over direct prompting on Korean benchmark data.

That discussion extended into regional variance and the research direction around QARV, a QA benchmark where answers can differ depending on region. A particularly memorable point was that, without a CoT process, prompting alone often struggles to resolve region-specific response tendencies. That observation made evaluation feel less like a leaderboard exercise and more like a question of linguistic and social grounding.

The Q&A and networking sessions were also rewarding. One answer I keep thinking about was the speaker’s response to a question about motivating team members as a team lead. His answer was simple but sharp: help turn the work into meaningful career capital. That resonated with me because I have often struggled with the same question while leading study groups or projects without strong financial incentives.

This was my third visit to the MODULabs Gangnam campus, and each visit has left me with a rare mix of knowledge and lived perspective. It also made me think again that I would like to become a speaker at events like this one someday.

Yesterday I attended an AWS Korea User Group data meetup. The sessions that day were about Data Lakehouse and MeiliSearch.

The first session, on Data Lakehouse, was genuinely eye-opening for me. I had only understood the rough characteristics of databases and data warehouses, so the idea of a “data lakehouse” felt surprisingly fresh. A data lakehouse combines the strengths of a data lake and a data warehouse while aiming to become an integrated platform for storing, managing, and analyzing data. It also supports more than the relational structures we are used to, extending toward hierarchical or network-like forms of organization. I was especially struck by the idea that modern data warehouses can become more flexible and scalable when combined with a data lake. Since I had previously struggled with how to think about data warehouses in a project, this felt especially attractive. The session also covered how open table formats such as Delta Lake, Iceberg, and Hudi can be applied on top of tools like Hadoop or Spark. Hearing that they can support ACID transactions, concurrency, and versioning made them feel even more compelling. I was also glad to hear that AWS services such as Athena and Glue can be used to explore open tables and lakehouse-style workflows.

The second session, on MeiliSearch, took place around dinner time, and the point that stayed with me most was its possible role as a partial alternative to Elasticsearch. I have taken training related to the ELK stack, but I have also felt that the preparatory work needed to use Elastic effectively for monitoring can be fairly demanding. MeiliSearch sounded attractive precisely because it offers SDKs and a comparatively simple way to connect. The speaker explained that this difference comes from the fact that Elasticsearch is built for large-scale backend search and text analysis, while MeiliSearch was designed more directly for front-facing search experiences. That distinction made a lot of sense. I left thinking that I should become more fluent with both systems. Features such as sub-50 millisecond responses, prefix search with updated results on each keystroke, typo tolerance, broad language support, and faceted search all sounded especially appealing.

Since this was my first AWSKRUG small-group meetup, I was a little nervous at first. But the care and energy in the speakers’ presentations made that feeling disappear by the end, and I found myself wanting to hear even more. I hope to keep attending these gatherings and gradually become a more active part of AWSKRUG.

Today I attended Gen AI Onboarding, hosted by Wrtn Technologies and GDSC, and had the chance to listen to several excellent talks.

Wrtn Technologies runs the generative AI platform service “Wrtn,” which aims to make generative AI easy for anyone to use. I was genuinely surprised to hear that the company, founded in 2023, had reached one million users in only seven months. Since I had only tried the service briefly before, I found myself thinking, “I should have kept using it.”

The event was organized into two sessions: Prompt Specialist, which focused on prompt engineering guidance, and Gen AI Career, in which engineers from Wrtn answered questions about working in generative AI. In the Prompt Specialist session, Wrtn’s DevRel, Chedda, introduced a range of practical ideas, from Chain of Thought to broader prompting processes and a set of seven useful tips. It felt like a very good opportunity to see prompt engineering presented as a craft rather than as a vague buzzword.

The Gen AI Career session featured both a platform engineer and an ML engineer. They answered pre-submitted questions with a level of depth that stayed with me long after the event, and the live questions from other attendees also made the session especially valuable. I was particularly grateful for the answers they gave to questions related to roles I am personally interested in.

The three hours passed surprisingly quickly. I would have liked to spend more time networking with the practicing engineers and the participants who asked such sharp questions, but I had to head home, which left me a little disappointed.

When using ChatGPT, I had noticed a “Check Hallucination” button appear below the response and assumed it was simply a newly added feature. When I finally tried it, I realized that it was actually provided by Liner.

From the way it behaved, it seemed to extract keywords from the response, search for relevant material, and then perform something like sentence similarity or NLI-based verification. The performance felt better than I expected, to the point that I could imagine using it often even with limits on both usage count and the number of verifiable items.

During a practical project I worked on over the previous vacation, one of my responsibilities involved planning, designing, building, and maintaining tools for internal team use. Only later did I learn that this kind of work is often called platform engineering. Since it was the kind of task that kept me interested the entire time, I started to wonder whether it might be the kind of role I could realistically see myself continuing in the future, and how I might build deeper professional strength around it as part of the skills that represent me.

While thinking about that, I came across a blog post worth saving for reference:

https://tech.kakaopay.com/post/kakaopaysec-devops-platform/

It felt like the attendance certificate arrived almost twenty days later.

The sessions I listened to at the time included Yoon Seokchan’s opening recap of AWS re:Invent, Chae Jeonghui’s talk on design principles using the AWS Well-Architected Framework, Jo Sohyun’s session on VPC and on-premises network connectivity, Kim Jeongwon’s session on cost management through Cost Explorer, and Jeong Jaemin’s session on monitoring with CloudWatch. There were many other talks I also wanted to hear, but because I had other commitments afterward, I ended up focusing only on the ones that seemed most immediately useful to the project I was working on at the time.

Thankfully, AWS Builders Online Series makes the sessions available afterward, so I was glad to know I could come back and watch more once the project settled down. I was especially interested in future talks on serverless, data governance, Amazon Bedrock, and CDK, since all of those feel directly connected to the skills I want to strengthen in cloud, data, and MLOps-oriented work.

I hope 2024 becomes a year full of cloud and data.

Did you know that some people argue the ideal pull request is around 50 lines long? In the same way that commits are often recommended to stay small enough to revert safely when something goes wrong, pull requests are also easier to review when they stay within a manageable scope. Of course, in real implementation work it is easy to forget to stop and break a large change into smaller PRs. While thinking about that over the course of a few days, I found several concepts that seem designed to help.

One of the most commonly mentioned ideas is trunk-based development. Strictly speaking, it is not a PR methodology in itself, but it affects PR size indirectly. In Git Flow or GitHub Flow, changes can move through longer pipelines such as feature -> dev -> release -> main, which often causes pull requests to grow larger over time. In trunk-based development, because changes are merged more directly into trunk or main, the unit of change often stays smaller.

I also came across the idea of stacked PRs, or stacked diffs, as proposed by tools like graphite.dev. The idea is to manage integration at the level of change units rather than waiting for one large PR at a time. One appealing aspect is that you do not always have to wait for someone else’s PR to merge before continuing your own work. It also seems to be fairly well established in organizations that use systems like Phabricator internally.

The last concept that stood out to me was GitButler’s Virtual Branches. In this approach, you can group local changes into multiple virtual branches and choose which ones to publish. That seemed especially convenient because it lets you work more freely first and then divide your changes afterward into cleaner reviewable units.

Reference: https://graphite.com/blog/the-ideal-pr-is-50-lines-long