As a developer, I'm sure many of you want to grow quickly, especially if you are a junior. I believe that the growth during the junior phase is crucial as it can shape a developer's lifelong career. Today, I want to share five important soft skills that can be beneficial during this critical time.

Now, let me explain why I am giving this presentation. Over the past few years, I have conducted many important presentations and mentoring sessions. However, I noticed that most lead developers tend to focus on urgent tasks, which is why they quickly grasp hard skills like programming, architecture design, and troubleshooting. On the other hand, they often question whether soft skills such as communication, time management, and metacognitive abilities are also necessary for developers.

So, to be honest, I was quite surprised at first, but ultimately, in the case of hard skills, they are survival skills for us. If we can't work at events, then soft skills are not survival skills. However, I believe they are really important weapons for us to think more creatively and to create our own uniqueness. Among those who are here, there might be some who are busy developing and might think they need to learn such things. Let me explain why they are necessary. I tell scholars that the first priority is, of course, development, and the second is the importance of growth. I emphasize that hard skills contribute to growth. The hard skills you use, like Java, Kotlin, Spring, Redis, and Kafka, all come together to create what I...

이제 소프트 스킬의 중요성이 점점 더 부각되고 있습니다. 저는 소프트 스킬이 더하기가 아니라 곱하기 역할을 한다고 생각합니다. 그렇기 때문에 이 시절에 일찍 익혀 두면, 마치 우리가 빨간 면에서 만났듯이 복리 효과를 누릴 수 있다고 믿습니다. 심지어 개발자를 그만둬도, 저는 이 소프트 스킬이 평생 유용하다고 생각합니다. 저도 사실 개발이 잘 되지 않았지만, 지금도 예전에 익혔던 소프트 스킬을 여전히 많이 사용하고 있습니다. 아래 그래프는 아주 작은 습관의 힘이라는 유명한 책에서 가져온 그래프인데요. 매일 1% 성장하면 1년이 지나면 무려 37.8배 성장한다고 합니다. 2% 성장하면 무려 137.7배 성장합니다. 이렇게 복리 효과는 성장에 매우 중요한 영향을 주기 때문에, 조금이라도 소프트 스킬을 빨리 익혀 두고 숙지하는 것이 중요합니다.

I believe that we will return to greater growth. Now, what is this presenter doing that warrants such a presentation? Let me introduce myself a bit. I used to work as a server developer at Toss, and about two to three years ago, I changed my career to become a Technical Product Owner. So now, I am a Product Owner. Fortunately, I have two YouTube videos set up at the company, so if anyone is curious about who I am, please refer to those videos. Today, I will share five important skills with you. I must admit that I didn’t possess all these skills from the beginning. Ultimately, as I grew, I encountered various barriers to my development, and each time I faced one of these walls, I contemplated and gradually learned these skills to break through those barriers. In fact,

제가 주요할 때는 채지 패티가 없었죠. 그렇기 때문에 지금 채지 피티가 아는 상황에서는 이게 소위 말하는 라데 마리아가 좀 될 수 있는데, 아마 여러분들이 그런 것들은 잘 걸러 들으리라 생각을 하고요. 또 한편으로는 채치 PT, 우리의 하드 스킬은 대체할 수 있더라도 과연 소프트 스킬은 대체할 수 있을까라는 생각도 좀 듭니다. 그래서 AI 시대에 더 중요한 것이 결국 소프트 스킬이 아닌가 저는 생각해요. 

그럼 이제 하나씩 설명을 들어볼게요. 우선 첫 번째입니다. 말씀을 잘 못한다고 생각하는 분들이 되게 많아요. 혹시 오늘 오신 분 중에 내가 말을 잘 못해서 일하는데 힘들어 본 적이 있다면, 한번 손 들어보시겠어요? 생각보다 별로 없네요. 사실 저는 개발자분들이 말을 못해서 힘들어하시는 경우를 좀 종종 보는데요. 아무래도 기획자, 아니면 피디, 세일즈 등 다양한 분야에서 그런 경우가 발생하곤 합니다.

I think that when it comes to desire, there are cases where people find it quite difficult to express themselves. However, I believe that communication is not just about speaking. The essence of communication, in my view, is syncing thoughts between the other person and myself. Therefore, even if someone is not good at speaking, if they can sync their thoughts well, I consider them to be good at communication. 

When we usually talk about API design or database design, these topics are indeed very challenging. If the other person does not share the same context or background, it can be honestly difficult to explain things verbally. So, I think it's not that developers can't speak; rather, the topics they need to discuss are too complex to convey through words alone. For this reason, I recommend communicating through visuals rather than words, especially when dealing with complex thoughts in one's mind.

When thoughts or energy are conveyed through slogans or sentences, a significant loss of information occurs during that process. Therefore, I find that communication does not go very well. This is because the thoughts in our heads are not organized neatly like text but are represented as very abstract images. So, when I convert the images in my mind into words, and you listen to those words, your mind transforms them back into images. This results in two transformations occurring, leading to a considerable loss of information. Let me test this out. I will speak spontaneously, and I would like you to visualize what I say. First, there are three servers: Server A, Server B, and Server C. When Server A communicates with Server B, it must do so through a gateway.

In addition, since server B communicates with server C, we need to include Kakao. If Kakao fails at any point, it will be marked as dead. There is a separate process for handling that dead data. This process runs every morning, and the operations manager needs to verify it every day. I wonder if this content makes sense in your mind. Maybe I'm not expressing myself well, but each of you likely has different interpretations. My depiction might have varied greatly from yours. If I had simply drawn the image in my mind without interpreting it into words and shown it to you, then you would have been able to store a similar image in your mind without going through that interpretation process. Communication is something I truly wanted to achieve.

I have experience, and I've also read in books that text often leaves a stronger impression than just what we see. There are many books that discuss this. However, I'm not saying that you should diligently draw diagrams or create visuals. Trends are ultimately just tools, and what matters is developing a habit of conveying my thoughts more effectively through images. So, to summarize, I would like to emphasize the importance of cultivating a habit of communicating through drawings. Additionally, it would be great if you could show a diagram. In the past, I used to use Draw.io a lot, but nowadays I often use Miro, which has become quite popular. If there are any of you here who draw diagrams using Paint or PowerPoint, I recommend finding even better tools. Ultimately, it's about expressing the thoughts in my brain.

In drawing, the time spent thinking and the time spent drawing should be very quick. If the tools are a bit slow, there will ultimately be a loss in conveying my thoughts or ideas. Therefore, I recommend looking for better tools. Before moving on to the second skill, let me share something with all of you. There is something that we all have in common. Can anyone guess what that is? That's right, it's time. The second point is creating a to-do list. Some of you may wonder why I am talking about a to-do list when discussing time. I believe that our to-do lists are the results of what we have accomplished throughout our lives. If we have about ten tasks to do in a day, over ten years, that would amount to about 30,000 tasks. Therefore, with those 30,000 tasks, we need to consider how much better we can perform them within the given time.

I believe that the to-do list is a way to assess what you can do and how much more you can achieve. However, there are many people who don't have a list, or they may manage their tasks in a different way. Nowadays, many people use apps like Todoist, which are great for to-do lists. I also use Todoist quite well, but I still find it somewhat lacking for my needs. 

Now, let me share three important characteristics of a good to-do list. First and foremost, the list should center around me. It shouldn't be focused on the team or the project. On the right, I have an example of a list I've created. It includes not only tasks related to work but also things I need to study and personal errands I have to take care of. For instance, I have daily reminders to take care of my health, and even scheduling company dinners is on the list. In fact, this is also a reflection of my personal responsibilities.

As a team member, it's my responsibility to manage tasks. However, I can't register issues while I'm in the middle of a project. Therefore, I need to have a central to-do list to keep track of everything. I believe that I should create a central to-do list that functions like an extension of my brain. 

Secondly, my backup system needs to be accessible from anywhere. I sometimes see people managing their to-do lists only on their laptops. If they leave their laptop behind when they go home or travel, they lose access to their backup and to-do list. So, I think it's essential to have an environment where I can easily access my list, regardless of where I am or what device I'm using.

Thirdly, I need to create a continuously beneficial to-do list. When I first heard about to-do lists, I thought they were extremely complicated and sophisticated.

Some people bring a to-do list and start using it right away, and at first, they feel really excited. However, as they continue to use it, they often feel overwhelmed by its features and end up not using the to-do list as much. Therefore, I recommend simpler tools rather than complex ones. When creating a to-do list, many people tend to categorize tasks by themes, such as projects, study, travel, and so on. However, this can lead to an overwhelming number of tasks, making it difficult to manage. When the list grows to 30 or even 100 items, it can become so cluttered that you don't want to look at it anymore. Ultimately, this means the to-do list fails to serve its purpose, and you stop looking at it altogether. I believe it's important to create a to-do list that encourages continual engagement. Based on my personal research over the past ten years, I have identified three key attributes to consider.

I'll share my thoughts. I think this isn't something I created myself; rather, I adapted it from a book to fit my style. First of all, I used Google Tasks. This might seem trivial, but over the past ten years, many companies have failed in between. If suddenly a service I rely on were to shut down, it would be quite shocking. However, Google hasn't failed in the last ten years, and I don't think it will in the future, so I continue to use Google. Additionally, Google Tasks has surprisingly few limitations, allowing me to add tasks without feeling burdened. I can easily access it from any platform or device. Secondly, I don't create a to-do list by theme; instead, I make to-do lists based on periods like daily, weekly, or monthly. So usually, I only focus on the day.

As I watch, I start registering tasks for the day. For example, I might add five tasks to my to-do list. However, if I can't complete those tasks on that day, they end up piling up. This means that as the week goes on, certain tasks remain, which, in a way, are not necessarily urgent. So, I move those tasks to my weekly list. If tasks accumulate there, I transfer them to my monthly list, and then to my yearly list. This is the method I use. Even if there aren’t many tasks, some have a longer cycle, like weekly or monthly tasks. For example, I might put have lunch with someone in my weekly list because it's something I want to do. I also wanted to create a workout plan, but I couldn't do it today, and I won’t be able to do it during the week either.

I just put it in the alcohol and managed it like that. And also, studying English has always been this way for me. I've been enrolled there since February, now for three years, and I always feel the need to submit something, thinking that I have to do it someday, and I keep reflecting on that. So, I hope you can create a to-do list that suits your style using the characteristics of the to-do list I mentioned. 

The third point is about having an eye for modern art. When you look at modern art, there are a lot of pieces that might seem simple, but if you actually go to see them, you'll find many modern artworks. The truth is, because we don't know much about it, it's hard to distinguish whether a piece was created by a child or a master artist. When you look at the price tags, there are paintings worth hundreds of millions, which is why our ability to appreciate art is still lacking compared to experts.

If we have an eye for art, visiting that art museum would be really enjoyable, and we would understand better what value this painting holds. The same goes for code. When we have that kind of insight, our ability to evaluate code improves significantly, and consequently, the quality of the code I write myself also increases. However, there are times when we mistakenly think that the code written by our seniors or predecessors is the only correct answer. Of course, if the seniors around us are world-class developers, it might be reasonable to think that way, but in reality, the code we encounter daily is often filled with very practical considerations, such as historical context and business exceptions. Ultimately, it becomes a situation where the code is heavily layered.

You often see a lot of code, and because of that, if you keep looking at the same code, it becomes difficult to develop your own perspective. Eventually, you reach a point where no matter what code you look at, you don't feel a sense of universality. However, I believe that developing an eye for code is really important. So, how do we cultivate this perspective? If I explain my approach, I use something like IntelliJ. When you dig deep into the code, there are moments when the quality of the code suddenly changes, especially when you enter a library or framework. At that point, some developers might be surprised and step back, but I encourage you not to do that. Instead, keep digging into the code to see what is there, and I hope you learn and absorb from it. When you become familiar with such code, your own code may seem relatively lacking, which will motivate you to improve more.

I started wanting to do that. After that, I recommend downloading the libraries or open-source projects that I had seen and taking a thorough look at them. There's a significant difference between viewing them in fragments and viewing them in their entirety. In my case, I studied a lot by downloading the entire Spring framework, Apache libraries, and Google projects and reviewing them. Additionally, I recommend learning about not only code but also books on code readability, refactoring, and design patterns. However, all of this is theoretical, and just watching YouTube videos won't be enough; we need to practice and embody the knowledge. Ultimately, I believe we need to practice because we have to ensure our own security. I usually don't distinguish between coding and refactoring; I always...

I recommend starting with a ratio based on actual performance. At first, you might not have time to code or refactor, but once you start doing it, the boundaries of refactoring and coding will eventually blur. This will actually speed up your coding in the long run. That's how I've experienced it. Lastly, I want to mention that many people don't look at the code they've written in the past. If you take a look at your old code after a year, it can be really fun to see how you used to code. You might find it amusing and realize how much you've grown. I encourage you to go home and open up your old code and try refactoring it.

I would like to recommend the fourth skill, which is why. I believe that developers are not just builders; they are problem solvers. I think that the worst developers are those who can build but cannot solve problems. The best developers are those who understand the problem and can resolve it without necessarily building something new. Therefore, since we are problem solvers, it is crucial to grasp the essence of the problem, and to do that, we need to develop the habit of asking why. 

For instance, if someone asks, Could you tell me about the API we should be careful with? we could simply respond, You can use our transaction API. Similarly, when a project manager asks for an API to be created, we might take about two days to put something together.

I'm really glad to meet you. You always meet with the gods, right? Now, let me add an external factor. Earlier, when I asked if you could tell me about the API to be cautious with, I cautiously inquired, Is there a specific issue you need help with? I wanted to see if there might be a better direction we could consider together. So, I subtly approached the topic. Then, this person explained the legal issues they are facing. They mentioned that they want to provide benefits through a transaction in the marketplace. However, if they use an API, and if the number of recipients is, say, 100,000 or 1 million, there could be issues. First, traffic would be a concern, and since you can't pull 100,000 people at once, pagination would be necessary. If our API doesn't support pagination, then development would need to be done. Therefore, considering these issues, the developer...

이렇게 얘기합니다. API는 그냥 인라인에서 빅데이터 플랫폼 같은 데서 추출해서 지급 대상을 말하고 지급하는 게 더 나을 것 같아요. 이분은 개발도 하지 않고 별도의 API를 쓰지 않고 바로 이 문제로 해결할 수 있는 거죠. 

그리고 두 번째 케이스, 아까 P사람에게 주 달라고 했죠? 동일하게 이제 문제를 물어봅니다. 그분은 휴대폰 번호가 필요한 게 아니었어요. 휴대폰을 가지고 메시지를 보내고 싶었던 거예요. 사실 저희는 아까 개발을 해 줬잖아요. 그런 걸 보면 문자 메시지를 보낼 때 휴대폰 번호가 아니라 사용자 아이디로 보낼 수 있는 방법이 있었던 거예요. 그래서 실제로 하지 않고 이렇게 사용자 아이디로 보낼 수 있는 방법이 있으니 이거 쓰시면 됩니다라고 하면, 아까 개발할 때 필요했던 시간도 안 쓰고 문제를 해결할 수 있는 정말 좋은 사례라고 볼 수 있을 것 같아요. 실제로 아마 여러분들도 이런 경험을 해보신 적이 있을 겁니다.

I think there are people who feel the same way. I believe that those in the zero group have many such experiences. When it comes to requests from others, it's not just about the external requests; my own requests are similar. For example, even if I make a request casually, if the other person is skilled at asking why, then it's fine if they ask me. However, if they simply agree without any thought, that could also lead to problems. So, I often approach it this way. It's somewhat like a proposal. First, when I present my request, I explain the background of the problem I want to solve. Then, I write down the solutions I have in mind as points one and two. What's important here is point one. If we move to point one, the other person might just choose that option. However, even if there might be a better solution, I try to encourage them to think more by adding a little bit of pressure.

Let's create a scenario where the other person is looking at the background and considering the wealth of their superior. They might think, Oh, I have a better method than the first academy, so how about trying this? This leads to a better solution. Therefore, when I ask questions, I recommend using this type of question to guide the conversation. To summarize, when someone makes a request, it would be good to first ask why? Additionally, when I make a request, I should incorporate explanations to develop the habit of providing context.

Now, moving on to the fifth point about finding effective study methods for developers. In mentoring developers, there are generally two main approaches: the theoretical approach, which involves studying books, and the practical approach, which focuses on hands-on experience. Is there anyone here who identifies with the theoretical approach? Everyone seems a bit shy.

You seem to be quite shy. Are you perhaps part of the theoretical group? It seems that the practical group has about ten times more members. I think those in the theoretical group tend to be a bit shyer. Yes, I am actually part of the practical group, so when I was a beginner, I read books as much as I could. However, after editing, I found that my skills didn’t improve as much as I expected. So, I found a study method for development that suits me perfectly and doesn’t involve picky eating. In a way, it’s quite strong, but it took me a year and a half to discover this. To explain, first, in order to know what I don’t know, I started by reading books. People tend to be most confident when they are unaware of what they don’t know. So, if I don’t know something, I often just don’t study further. Therefore, I need to understand why I don’t know something and what it is.

To understand whether one is unaware, we first look at such thin books. For example, nowadays, when people talk about messaging, they might think of Kafka. Therefore, many study Kafka. When you ask those who have studied Kafka about its advantages, they usually say that it handles stream processing well and is good at handling various tasks. However, being able to handle stream processing well is quite common in today's era. So, is that really an advantage? Isn't it something that should be taken for granted? An advantage can only be considered as such when compared to existing technologies. I believe that basic stream processing is a given with the latest technologies. When I was developing something important, Kafka had just been released. At that time, I wondered how to study it, and I'm not sure how many people are familiar with something called Leviathan, but I was looking into Leviathan and Kafka.

I studied. At that time, handling Telphy was really difficult for Levi. Therefore, when I looked at Kafka, I realized that Kafka has advantages in processing large amounts of data compared to RabbitMQ. The way messages are handled in Kafka and how it differs from RabbitMQ allows for better performance. By comparing these, you can learn more quickly. If you study why this technology was created and why it is better than existing technologies, you will be able to acquire knowledge more rapidly. After mastering this, I look at tutorial codes and try to write them together. Then, through the tutorial codes, I gain experience and revisit the book to deepen my understanding. After going through this general cycle, I change the book and try different methods. This is somewhat my own approach.

It's a skill of mine. I really enjoy reading multiple books on the same topic by different authors. This is because each author has a different perspective and way of thinking. Their ideas come into my mind and debate with each other, almost like they're having a discussion or argument. While listening to this debate in my head, I process and interpret their thoughts in a way that helps me gain comprehensive knowledge. So, I keep switching between books as I read. After gaining a certain level of confidence, I explore related open-source materials and, if I get the opportunity while working at a company, I try to apply what I've learned. I attempted to illustrate this study method with a diagram. Initially, at the bottom, there is the stage of ignorance. Ultimately, we move back and forth between theory and experience until we reach a state of understanding.

I believe we need to reach our goals. If we only focus on theory or technical skills, I think we will eventually hit a wall at some point. So, I recommend that you all try to find your own study methods. Now, we are already at the end of the presentation. Today, I talked about five skills. First, to communicate effectively, let's try to express ourselves through images rather than just words. Second, to make better use of our precious time, let's create a to-do list. Third, let's develop the ability to analyze code so that when we look at it, we can see how we can improve it. Fourth, since we are problem solvers, we should cultivate the habit of asking why to solve problems effectively. Finally, since we need to grow faster, we should...

I mentioned that I hope to find my own growth and study methods for development. I believe that if you all take the time to learn one thing at a time, it will truly be beneficial for you. So, let's slowly wrap up the highlights. As I mentioned earlier, while having important conversations is essential, I also believe that personal growth is incredibly important; I consider it to be the core of our work. I think that changing the slope of the growth curve in the first three years can make a tremendous difference in your mindset. Don't you want to become the purple line on the graph? 

And this is a slightly different topic, but there is something strange about the graph. I heard from a designer that originally, the growth was supposed to be gradual, but suddenly, at the fourth point, there is no growth. So, this is where...

I missed that, and I just discovered it the day before yesterday, so I couldn't accept it. But I will never stop working hard; I will be a lifelong saint. However, this year is really important because it determines the slope of the curve. Additionally, I want to add that when you look at the developers, sometimes you hear people say, I think I've been working for three years now, so I'm proud of it. But I feel like saying, Well, it's natural for someone with three years of experience to be doing three years' worth of work. A developer with three years of experience should be doing the work expected of them at that level. In fact, a developer with three years of experience should be doing the work of someone with five or ten years of experience to be considered good in a company. It is truly a sign of a good developer when someone with five years of experience is doing the work of someone with ten years of experience, as they are doing the work that suits them.

If you think about it, the level we expect is almost the same as what we have. So, for those who are here, I hope you will judge the five soft skills I will share, considering whether you can work as a developer in your third or tenth year. Thank you for your presentation today. Now, I will take your questions. Do we have a microphone? If you could just pass it forward. 

So, the question is about the differences between two concepts, which are both correct, but when a conflict arises and a debate occurs, how do we resolve it? In my case, before speaking, I first draw a picture. I start by sketching it on the whiteboard. Then, when the other person sees the drawing on the whiteboard and we both look at it together, eventually...

We're going in a similar direction, but what's really important here is that this is a previous point. The person who draws on the board first has a much higher chance of winning. Why? Because I can convey my thoughts onto the board, and then I tell my opponent to put their thoughts here as well. This board represents our collective thoughts, so what is discussed here ultimately reflects both of our ideas. That's how I often resolve issues. 

Now, regarding the question you asked earlier about finding a development study method, you mentioned two examples: studying through books and theory versus practical experience. I have a habit of studying based on practical experience, which I've developed over the years. However, I've always thought that it would be better to first study books and theory before moving on to development. But in reality, the examples...

It seems that you provided a detailed example regarding studying based on books and theories. When I said I was looking for my study method, you mentioned theories. I'm curious whether I should change my approach to focus more on practical methods or if it's better to find a method that fits theory. If I summarize my question, I need to find a study method that aligns with theory, but I'm wondering if I should find a method that fits practical situations instead. You mentioned that I shouldn't change my approach drastically. In reality, it can be quite challenging to become practical, and it’s difficult to find a method that fits theoretical learning. There’s something essential about this. So, I advise those who are more practical to find a study method that suits their real-world situations. For those focused on practical applications, rather than just focusing on theory, it’s better to engage in practice.

Just dive into the code. For example, with Kakao, take all the properties and study what each of those properties does. While doing that, you can search for references, and as you search, you'll find problems related to those references, which will help you learn. In my case, I first read the documentation thoroughly and then look at the settings. Ultimately, regardless of the approach I take, I hope that the fundamental explanations do not change. I would like to ask another question about my study method. When I study books or theories and then try to apply them in practice, I often find a gap between theory and practice.

I have been wondering how to connect that part to pricing, so I wanted to ask you. Honestly, it's really difficult. To be honest, I have also been thinking about how to apply what I learned during an important time. They say that when you're holding a hammer, everything looks like a nail. During that crucial period, I was just trying to apply what I learned everywhere, and I received a lot of criticism for it. People would ask why I used it in certain places. However, I did gain a lot of experience. So, first of all, if you think about where to apply what you have studied for 23 hours, it can be really beneficial. Of course, I think it’s important to listen to feedback from team leaders and mentors. Also, it’s essential to keep studying, as I often faced many challenges. I also think it's important to share that content through blogs or other publications.

I think I published something because when others see it, they seem to study really hard and actually write the code for real. So, I initially used that approach. In fact, I don't think this is the standard way, but it might be good for the person who asked the question to try something like this. 

Hello! It would be great if I could only communicate with the nice people at the company, but sometimes there are villains in the company. Is there a wise way to communicate with those kinds of people? To be honest, I wasn't very good at that during my early days; when I encountered such people, I would just handle everything myself. However, these days, I can't do that anymore, so I've recently learned some skills. First, I eat with them. By having a meal, I try to understand why they think the way they do and whether they are busy.

Now, let's slowly explore why they are unable to do this. If I can support them and bring them to my side, they tend to perform better. Of course, this is somewhat related to my relationship with them, but their skills don’t actually improve in such cases. Honestly, I think we need to escalate the situation. I would need to express that it's very difficult to work with them due to the quality not meeting expectations. By the way, do you think this is related to the relationship, or is it about the quality? I believe that engaging a bit more, even casually chatting while passing by, can really help. Yes, the quality is something I often ponder about. Well then, since our time is up, I will conclude the questions here. Thank you very much for listening to my lecture for the past 40 minutes.

Then, please give a round of applause for another interesting lecture.

토스ㅣSLASH 24 - 빠르게 성장하고 싶은 주니어 개발자를 위한 소프트 스킬 5가지

금융의 모든 것, 토스에서 쉽고 간편하게


토스

주니어 개발자의 빠른 성장을 위해 다섯 가지 소프트 스킬, 즉 시각적 소통, 개인 중심의 To-Do 리스트 작성, 코드 분석 능력, 문제 해결을 위한 '왜'라는 질문 습관화, 그리고 자신만의 학습 방법 찾기를 강조한다.

소프트 스킬은 개발자의 창의성과 고유성을 높이는 데 기여하며, AI 시대에 하드 스킬을 대체할 수 없는 중요한 역량이 될 수 있다.

소프트 스킬은 복리 효과를 통해 꾸준한 성장을 이끌며, 개발자로서의 커리어를 넘어 평생 유용하게 활용될 수 있다.

🚀 주니어 개발자의 빠른 성장을 위한 소프트 스킬

주니어 개발자 시기의 성장은 매우 중요하며, **다양한 소프트 스킬을 익히는 것이 커리어에 큰 영향을 미칠 수 있습니다**. 이 시기에 소프트 스킬을 일찍 익혀두면 복리 효과를 누릴 수 있으며, 개발자를 그만두더라도 평생 유용하게 사용할 수 있습니다.

소프트 스킬은 단순히 더하기가 아닌 곱하기의 역할을 합니다. 매일 1%씩 성장하면 1년 후에는 무려 37.8배 성장하며, 2% 성장 시에는 137.7배 성장합니다. **복리 효과를 통해 꾸준한 성장을 이루는 것이 중요합니다**.

🗣️ 효과적인 의사소통: 시각적인 표현의 중요성

많은 개발자들이 말하기 어려움을 느끼지만, 의사소통의 본질은 **상대방과 생각을 일치시키는 것**입니다. 복잡한 내용을 말로 설명하기 어려울 때는 시각적인 자료를 활용하는 것이 효과적입니다.

생각을 문장으로 전달하는 과정에서 정보 손실이 발생할 수 있습니다. **머릿속의 추상적인 이미지를 그대로 전달하는 것이 더 효과적입니다**. 그림을 통해 생각을 전달하는 습관을 기르는 것이 중요하며, Draw.io나 Miro와 같은 도구를 활용하는 것을 추천합니다.

 📝 효율적인 시간 관리: 나를 중심으로 한 To-Do 리스트

To-Do 리스트는 **자신이 할 수 있는 일과 얼마나 더 많은 것을 성취할 수 있는지 평가하는 방법**입니다. 좋은 To-Do 리스트는 나를 중심으로 구성되어야 하며, 어디서든 접근 가능해야 하고, 지속적으로 유용해야 합니다.

To-Do 리스트를 만들 때 테마별로 분류하면 관리가 어려워질 수 있습니다. **일별, 주별, 월별과 같이 기간별로 To-Do 리스트를 작성하는 것이 효과적입니다**. Google Tasks와 같이 간단하고 접근성이 좋은 도구를 사용하는 것을 추천합니다.

🎨 코드 감상 능력 키우기: 라이브러리 및 오픈 소스 프로젝트 탐구

코드에 대한 안목을 키우면 **코드 평가 능력이 향상되고, 자신이 작성하는 코드의 품질 또한 높아집니다**. 선배 개발자의 코드가 항상 정답이라고 생각하지 말고, 다양한 코드를 접하며 자신만의 관점을 개발하는 것이 중요합니다.

IntelliJ와 같은 도구를 사용하여 코드 깊숙이 파고들어 보고, 라이브러리나 오픈 소스 프로젝트를 다운로드하여 전체적으로 살펴보는 것을 추천합니다. **코드 가독성, 리팩토링, 디자인 패턴 관련 서적을 학습하는 것도 도움이 됩니다**.

🤔 문제 해결 능력 향상: '왜?'라는 질문을 습관화하기

개발자는 단순한 빌더가 아닌 문제 해결사입니다. **문제의 본질을 파악하고 해결하기 위해 '왜?'라는 질문을 습관화해야 합니다**. 다른 사람의 요청에 대해 단순히 응답하는 것이 아니라, 문제의 배경과 맥락을 이해하려고 노력해야 합니다.

요청을 받을 때 먼저 '왜?'라는 질문을 던지고, 자신이 요청할 때도 문제의 배경을 설명하는 습관을 들여야 합니다. **문제를 명확히 이해하면 개발 없이도 해결할 수 있는 경우가 있습니다**.

 📚 효과적인 학습 방법 찾기: 이론과 경험의 조화

자신에게 맞는 학습 방법을 찾는 것이 중요합니다. **이론적인 학습과 실제 경험을 병행하며, 모르는 것을 명확히 인지하는 것부터 시작해야 합니다**. 여러 권의 책을 통해 다양한 관점을 접하고, 오픈 소스 자료를 탐구하며, 실제 업무에 적용해 보는 것이 좋습니다.

하나의 주제에 대해 여러 저자의 책을 읽으며 다양한 관점을 접하는 것이 도움이 됩니다. **이론과 경험을 반복하며 목표를 향해 나아가야 합니다**. 이론이나 기술적인 스킬에만 집중하면 한계에 부딪힐 수 있습니다.

🌱 꾸준한 성장: 개발자로서의 마인드셋

개인의 성장은 업무의 핵심이며, **초반 3년 동안 성장 곡선의 기울기를 바꾸는 것이 중요합니다**. 3년차 개발자는 3년차에 맞는 일을 하는 것이 당연하며, 5년차, 10년차 개발자 수준의 역량을 보여줘야 좋은 개발자라고 할 수 있습니다.

주니어 개발자의 빠른 성장을 위한 소프트 스킬 소개

주니어 시기의 성장이 개발자 커리어에 중요하며, 소프트 스킬이 필요함을 강조.

하드 스킬은 생존 기술이지만, 소프트 스킬은 창의적 사고와 고유성을 위한 무기.

소프트 스킬의 중요성과 복리 효과

소프트 스킬은 더하기가 아닌 곱하기의 역할을 하며, 개발자를 그만둬도 유용.

작은 습관의 힘을 인용한 그래프를 통해 꾸준한 성장의 중요성을 강조.

발표자 소개 및 소프트 스킬 습득 계기

토스 서버 개발자에서 Technical Product Owner로 커리어 전환.

개발 과정에서 겪은 어려움을 극복하기 위해 소프트 스킬을 습득하게 됨.

소프트 스킬의 중요성 및 첫 번째 스킬: 효과적인 의사소통

AI 시대에 소프트 스킬의 중요성이 더욱 부각됨.

의사소통은 단순히 말을 잘하는 것이 아닌, 생각의 동기화가 중요.

복잡한 내용을 전달할 때는 시각 자료를 활용하여 정보 손실을 줄여야 함.

말로만 설명하는 것보다 그림을 통해 생각을 전달하는 것이 효과적.

사고 시간을 단축시키는 효과적인 도구를 사용하여 그림으로 소통하는 습관을 강조.

두 번째 스킬: To-Do 리스트 작성

To-Do 리스트는 시간 관리와 성과 측정을 위한 도구.

좋은 To-Do 리스트는 자신에게 집중되어야 하며, 어디서든 접근 가능해야 함.

지속적으로 활용 가능한 To-Do 리스트를 만들기 위해 단순한 도구를 사용할 것을 권장.

테마별 분류보다 기간별(매일, 매주, 매월) To-Do 리스트 작성을 추천.

Google Tasks를 활용하여 기간별 To-Do 리스트를 관리하는 방법 소개.

코드에 대한 안목을 키우면 코드 평가 능력이 향상되고, 자신이 작성하는 코드 품질도 향상됨.

선배 개발자의 코드가 항상 정답이라고 생각하지 않고, 자신만의 관점을 개발해야 함.

라이브러리나 프레임워크 코드를 깊이 파고들어 학습하고, 코드 가독성, 리팩토링, 디자인 패턴 관련 서적을 학습할 것을 권장.

이론 학습 후 실제 코딩 및 리팩토링 연습을 통해 지식을 체화해야 함.

과거에 작성한 코드를 다시 살펴보며 자신의 성장을 확인하고 리팩토링하는 것을 추천.

개발자는 단순한 빌더가 아닌 문제 해결사이며, 문제의 본질을 파악하기 위해 '왜?'라는 질문을 던지는 습관을 길러야 함.

API 사용 시 발생할 수 있는 문제점을 파악하고, 더 나은 해결 방안을 모색하는 사례 제시.

휴대폰 번호가 아닌 사용자 아이디로 메시지를 보낼 수 있는 방법을 찾아 개발 시간을 절약한 사례.

요청에 대한 배경을 설명하고, 다양한 해결책을 제시하여 더 나은 해결책을 찾도록 유도해야 함.

요청을 받을 때 '왜?'라는 질문을 먼저 하고, 요청 시에는 배경 설명을 포함하는 습관을 강조.

다섯 번째 스킬: 효과적인 개발 학습 방법

이론 학습과 실무 경험 중 자신에게 맞는 학습 방법을 찾아야 함.

자신이 모르는 것을 알기 위해 책을 읽고, Kafka와 같은 기술의 장점을 기존 기술과 비교하여 학습해야 함.

튜토리얼 코드를 따라하며 경험을 쌓고, 책을 다시 보며 이해를 심화시키는 방법 제시.

다양한 저자의 책을 읽고, 오픈 소스 자료를 탐색하며, 실무에 적용하는 학습 방법 소개.

이론과 경험을 반복하며 이해 수준을 높여 목표에 도달해야 함.

효과적인 의사소통, To-Do 리스트 작성, 코드 분석 능력, 문제 해결 능력, 효과적인 개발 학습 방법의 중요성 재강조.

개인의 성장이 업무의 핵심이며, 초기 3년간의 성장 기울기를 바꾸는 것이 중요.

3년차 개발자는 3년차 수준의 업무를 하는 것이 당연하며, 더 높은 수준의 업무를 수행해야 좋은 개발자라고 할 수 있음.

질의응답: 개념 충돌 해결 및 개발 학습 방법

개념 충돌 시 그림을 활용하여 시각적으로 설명하고, 공동의 생각을 도출하는 방법 제시.

실무 중심 학습자는 이론에 치중하기보다 실제 코드에 몰두하는 것이 좋음.

이론과 실제의 괴리를 좁히기 위해 꾸준히 학습하고, 팀 리더나 멘토의 피드백을 경청해야 함.

학습한 내용을 블로그 등에 공유하여 다른 사람들과 함께 학습하는 것이 도움이 됨.

질의응답: 회사 내 빌런과의 소통 방법

빌런과의 관계를 개선하기 위해 함께 식사하고, 어려움을 파악하여 지원해야 함.

관계 개선이 어렵다면, 품질 문제를 제기하고 상황을 개선해야 함.